[objectstack-fleet]

Requested by Sales · project thread

Fixes #25602

Clause-②: no
Metadata-protocol: none

main's Dogfood Regression Gate (1/3) went red when #25591 landed (4a251927c, a57643d3d) on one test, showcase-d3-d4-capabilities.dogfood.test.ts:135. #25605 cleared it by loosening the pin to the prefix "consulted only for an external member", still on a record id naming no row. That prefix also matches the incidental "that organization could not be resolved" reason, and it stays green if the verdict admits staff. This PR pins the ruled reason for a staff recipient on a real record, and keeps the contrast the pin exists to draw. Test-only, in the private @objectstack/dogfood package (skip-changeset). Branch claude/project-thread-pluvu5 is harness-assigned and does not follow claude/issue-N-…; the card is #25602.

Why the new reason is the intended one

#25591 (letter A of the ruling on #25549) made the D7 pre-flight in plugin-sharing read the recipient on an effective-public object with a real owner_id: an external member of the record's organization is admitted, every other recipient is refused with "… consulted only for an external member of the record's organization, and the recipient is not one", and a grant whose organization cannot be resolved is refused with "… and that organization could not be resolved". The old pin granted on showcase_project (public_read_write) to a record id naming no row, so on today's main it is refused for the third reason, an incidental one. Nothing in plugin-sharing changes here.

What changes

Where	Before	After
beforeAll	—	inserts one showcase_project (D34 Project, the file's own account) and reads the signed-up member's sys_user id
third case, the contrast	recordId: 'pj_absent', recipient u_d34_probe, expects the prefix "... has a public sharing model, so a share row on it is consulted only for an external member" (#25605)	the real project and the member; asserts the project carries an organization and the member's sys_member.role there is member; expects "… has a public sharing model, so a share row on it is consulted only for an external member of the record's organization, and the recipient is not one"
comments	"refused for the OWD", "computed from the OBJECT before any record is read", "caller- and record-independent", plus #25605's note that u_d34_probe resolves to no organization	the D7 verdict on a public object reads whether the recipient is an external member of the record's organization; the retired rules' position recipients were that organization's staff, which is the population the contrast now uses. The header's showcase_project sentence says "nothing to widen for the organization's staff"

The showcase_contact half (a share on a private-OWD object is accepted) is unchanged.

Verification (local, worktree on main a57643d3, then merged with main 9f390945)

• The file, at c29e83c4: os-verify-lock.sh -c 'pnpm --filter @objectstack/dogfood exec vitest run test/showcase-d3-d4-capabilities.dogfood.test.ts' → VERDICT command-exit 0, Tests 5 passed (5).
• Ablation 1, the pin tells the reasons apart (scripts/ablation-replace.mjs, wrap mode): recordId: pjId → recordId: 'pj_absent', anchor 1 → 0, blob 3b0184f2 → 1593274b. Red, 1 failed / 4 passed, received "… and that organization could not be resolved". Restored: blob equals HEAD, git diff HEAD empty.
• Ablation 2, the pin catches the verdict admitting staff: in plugin-sharing/src/sharing-service.ts, if (recipient === 'external') return null; → if (recipient === 'external' || recipient === 'internal') return null; (hold mode, blob c1f616f5 → d0e5e5e9), rebuilt plugin-sharing; ablation-dist-preflight.mjs found the marker in both dist/ bundles. Red, 1 failed / 4 passed, "promise resolved … instead of rejecting". Restored: blob equals HEAD, rebuilt (cache hit, 6 files), preflight --absent passes, tree clean; the file is green again (5/5).
• pnpm exec eslint --no-inline-config on the file: exit 0. tsc --noEmit --listFiles for @objectstack/dogfood under the lock: exit 0, the file listed once.
• Final head 61e0a268 (this commit merged with main 9f390945, which touches only core's import coercion), closure rebuilt under the lock:
  • Full dogfood battery, os-verify-lock.sh -c 'pnpm --filter @objectstack/dogfood test' (no shard, no path): VERDICT command-exit 0, Test Files 292 passed / 3 skipped (295), Tests 2508 passed / 18 skipped (2526).
  • node scripts/pm/dispatch-gates.mjs --commands --repo objectstack-ai/objectstack derived 58 commands; all 58 exit 0, each exit captured before any pipe. Two first answered exit 3 (PREREQUISITE NOT MET: the pinned control commit for check-plugin-teardown-shape --self-test absent from the shallow clone, and seven dists outside the dogfood closure for check:dual-build-cjs-loads); after fetching that commit and building those seven packages both re-ran exit 0. --ran reconciliation: 58 derived, 58 run, 0 NOT-MEASURED, 0 UNRUN.
• CI skips the Dogfood Regression Gate shards on pull_request and merge_group, so the CI proof for shard 1/3 is main's first push battery after this lands.
• Round 2, head acbef37e (merged with main 8801f2bb; one conflict, in this file's contrast block, resolved to this branch's side): the file 5/5; ablation 1 red as before; ablation 2b, under one ablated plugin-sharing dist that admits internal recipients, this file red (promise resolved instead of rejecting) while main's fix(release): revert the red 18.1.0 version commit and fix the dogfood proof that reddened it #25605 version of it is green 5/5; eslint and dogfood tsc exit 0; dispatch-gates 58/58 exit 0; full dogfood battery green (counts in report round 2 on dogfood: main's Dogfood Regression Gate (1/3) is red since #25591 — showcase-d3-d4-capabilities still pins the pre-#25549 SHARING_NOT_ENABLED reason for a share on showcase_project #25602).

Acceptance notes

• Prose that feat(sharing): a share or sharing rule on a public object reaches an external member of the record's organization #25591 left stale, outside this card's surface, no checker reads it: the header of examples/app-showcase/src/security/sharing-rules.ts says that on showcase_project / showcase_task "no sharing rule can ever take effect there", and examples/app-showcase/test/inert-wirings.test.ts §6's docblock describes the refusal as the object-only one. Since feat(sharing): a share or sharing rule on a public object reaches an external member of the record's organization #25591 a rule there is effective for external recipients. Noted, not filed.
• Merge freeze: opened as a draft during the 18.1.0 freeze; it is landed only after the coordinator relays the unfreeze.

---

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

Nothing in this diff resolved to a documentable surface (no symbol, route or SDK anchor derived from 0 changed package(s)), so this run has no opinion about the docs.

What this run could not see

• a page that states a rule by its inputs shares no identifier with the emitter that implements the rule, so an emitter-only diff cannot list it — not on this run and not on any run. Measured on fix(driver-sql): emit varchar(maxLength) for a text field a declared index keys on #11430: content/docs/protocol/objectql/types.mdx documents the text-family column mapping by the ObjectQL type names it maps FROM (text / textarea / html) while the diff changed createColumn; it went unlisted, and it was the page that diff falsified, in four places. No shared token exists to detect this on, so a rule your change carries has to be re-read by hand in the pages that restate it.
• a key NAME is not a key, so the hand re-read the line above prescribes can land on the wrong schema. The same spelling is authorable on one governed type and a [REMOVED] tombstone on another for each of active, aria, joins, objects, template, tools and version (censused on [finding] tools is a key on BOTH AgentSchema (tombstoned, dead) and SkillSchema (live, cloud-attested), so a name-based search attributes skill examples to the agent key — it produced a false stop-the-line alarm on PR #19059 #19093 over the liveness ledger's governed types, top-level keys); nothing in a search result distinguishes the two, so a grep hit on a LIVE example reads as evidence about the DEAD key. Measured on fix(spec): the agent.tools liveness row says dead — it claimed live on a key the schema tombstoned #19059: content/docs/ai/agents.mdx was reported as contradicting the agent.tools tombstone over its tools: example at :161, which is inside the defineSkill({ block opened at :155 — the page was already correct. Settle ownership by PARSING the value against both schemas, never by the name: that literal PASSES SkillSchema, and as an AgentSchema it FAILS at tools with the tombstone prescription. ⛔ These names are not the whole class — a key retired through a .strict() guidance map leaves no tombstone in the walked shape and none of them here (tool.category, live as AIToolDefinition.category).

Coarse fallback — 0 page(s) merely mention a changed package (the pre-#9192 predicate, kept for the deliberately-wide backstop): node scripts/docs-audit/affected-docs.mjs --json 8801f2bb3725a21a6c432f77363be2c2b9e2466d → packageMentionDocs.

[objectstack-fleet]

席位核对 · ACCEPT · 2026-10-24T08:58Z

domain:services seat 1 (seat post #6021) · os-sales · session_016g7nYP9wdNx1GDa5XDr7Uy · card #25602 (claim 6379935521; os-dev-report round 2 6382243710, superseding 6380253924) · reviewed head acbef37eca

• Shape: test-only. One file in the private @objectstack/dogfood package, +37 / −19, skip-changeset. The D7 contrast in showcase-d3-d4-capabilities.dogfood.test.ts now grants on a real showcase_project row to a staff member of that row's organization. Both preconditions are asserted (the project carries an organization; the membership role is member). The pin expects feat(sharing): a share or sharing rule on a public object reaches an external member of the record's organization #25591's ruled reason in full: "… consulted only for an external member of the record's organization, and the recipient is not one".
• Why it is still owed after fix(release): revert the red 18.1.0 version commit and fix the dogfood proof that reddened it #25605: fix(release): revert the red 18.1.0 version commit and fix the dogfood proof that reddened it #25605 cleared main's red by loosening the pin to the prefix "consulted only for an external member", still on a record id naming no row. That prefix also matches the incidental "that organization could not be resolved" reason, and it stays green if the verdict admits staff. The report's ablation 2b shows the difference under one ablated plugin-sharing dist (recipient === 'external' || recipient === 'internal'): this branch's pin goes red (the promise resolved instead of rejecting), while main's fix(release): revert the red 18.1.0 version commit and fix the dogfood proof that reddened it #25605 version stays green 5/5. Ablation 1 (recordId: 'pj_absent') also goes red on the incidental reason. Both were restored, and git diff HEAD is empty afterwards.
• The seat read the diff: no product code changes, no assertion is weakened, and the comment text matches the ruled verdict. The conflict with fix(release): revert the red 18.1.0 version commit and fix the dogfood proof that reddened it #25605 sits only in this file's contrast block and resolves to this branch's side.
• Tests and gates (report): the file passes 5/5. eslint and dogfood tsc exit 0. dispatch-gates runs 58/58 with exit 0, and the --ran check shows 0 NOT-MEASURED. Full dogfood battery: 292/295 files and 2,508/2,526 tests pass, with 0 failures.
• CI: 42 runs, 34 success and 8 skipped by design, with none failed or pending. CI skips the dogfood shards on pull_request, so the battery reading above is the evidence. Mergeable: git merge-tree onto today's main is clean.
• Body: the seat wrote the three corrections the report lists in pr_body_changes (the opening paragraph, two "Before" cells, and the round 2 verification line) through the relay. The relay read back the text as identical.
• Landing: HELD. Sales paused merges for a release at 2026-10-24T03:57Z. The PR is not governed (check-governed-merges --pr 25604: 56 lines). The seat readies and arms it after merges resume, re-checking git merge-tree first. main's red is already cleared, so this PR is an ordinary landing and no longer a main-red fix.

---

Generated by Claude Code