fix(plugin-sharing): a minted share link carries its organization, never NULL (ADR-0131 D9, C8 stage 8b-0h)

[objectstack-fleet]

Part of #15212
Clause-②: no

C8 stage 8b-0h (claim 6259036738, pointer 6258557956, plan amendment 11 6259028550). ShareLinkService.createLink stamps sys_share_link.organization_id, so a minted link is never a NULL row. #15212 remains open; stage 8b and the rest of C8 are not in this PR.

What changed

packages/plugins/plugin-sharing/src/share-link-service.ts: a new private resolveMintOrganization. It runs after the authority and eligibility checks and before the insert. In order:

1. The linked record's organization. One read under the system context: fields: ['id', TENANT_FIELD], with the tenant field from resolveTenantFieldName. It takes the system context so that field-level masking cannot hide the column. The record's organization wins over the session's.
2. The acting context's organization (tenantId), when the record names none: an object with no tenant column, or a row with no organization.
3. The ADR-0131 D9 predicate (resolveSystemWriteOrganization, from @objectstack/core through @objectstack/objectql's re-export of the same binding). Under single with exactly one organization, it derives the Default Organization. Otherwise it refuses with the engine's own SystemWriteOrganizationRequiredError (ERR_SYSTEM_WRITE_ORGANIZATION_REQUIRED, status 500). That covers a walled posture, and a single install with none or several organizations. Nothing is written.

The stamp rides both the row and the write context ({ ...SYSTEM_CTX, tenantId }), the shape SharingService.grant uses for sys_record_share. The mint response is still the contract's ShareLink shape, which declares no organization column. Nothing is stamped when sys_share_link has no tenant column, or when the composition registers no sys_organization; the probe answers [] without a read, like the engine's own probe.

The posture is the requested one (resolveTenancyPosture()). resolveAuthzContext's platform-anchor read and the tenancy service's defaultOrgId() read the same source in the same fail-stricter direction: a deployment that asked for a wall stays walled here even when it runs degraded.

Why the service decides (not the engine)

sys_share_link is unclassified in the #13491 ledger, so Engine.resolveSystemInsertOrganization returns early for it (isPlatformObjectOutOfTenantAuditScope, engine.ts about :7183), and today the NULL insert goes through. The service raises the engine's own refusal envelope, so a walled mint gets the same answer before and after 8b retires that exemption. This PR does not touch the engine or the ledger.

Measured (dispatch assumptions)

• A1 (one writer): holds. On 538f923cb, git grep for insert|create|upsert('sys_share_link' finds one site: share-link-service.ts:665. revokeLink and the usage stamp only update existing rows.
• A2 (record read before insert): falsified. The existing read is fields: ['id'] unless an eligibility predicate is declared. It runs under the caller's context, where field-level masking applies. So the stage adds the narrowest system read, ['id', TENANT_FIELD]. A failing read propagates, so the mint fails and nothing is written. The stage never stamps the session's organization in place of an unknown record organization.
• A3 (cross-organization link): possible under group. Layer 0 is a membership union there, so a member active in A can mint on a visible record in B. The isolated wall is equality, so both are the same. The owner and Modify-All alternative is withheld under a wall. A system caller reads under the system context. In every case the record's organization is stamped (pin 1).
• A5 / Clause-②. No in-repo caller reaches the new refusal. The only createLink callers are the two HTTP doors (share-link-routes.ts:362, runtime/src/domains/share-links.ts:433). Both require a userId. Under a wall, an organization-less API key is refused at admission (share-link-tenancy-posture-admission.test.ts). An organization-less session fails Layer 0 on any tenant-columned record, so the visibility check refuses first. No in-repo object pairs publicSharing with tenancy.enabled: false; the only publicSharing object is showcase's client-brief, which is tenant-columned. The refusal is reachable only by an external system caller that threads no tenantId, or by a third-party organization-less object. So the claim's Clause-②: no is kept as written.
• A6 (size): +281 / -1 over 3 files (the changeset, the service and a new 135-line pin), inside the 0.1–0.3k estimate.

Tests

• New share-link-organization-stamp.test.ts: a real ObjectQL and SqlDriver (better-sqlite3 :memory:), the real SysShareLink object, and rows read back off the driver. The posture is stubbed through OS_TENANCY_POSTURE.
  • (0) The registered sys_share_link carries the tenant column.
  • (1) Walled: the row gets the record's organization, even when the caller acts in another.
  • (2) Walled: a record with no organization gets the caller's.
  • (3) single: the Default Organization, and the response has no organization_id.
  • (4) Walled with neither: the refusal envelope (code and status), and zero rows.
• Ablations, through scripts/ablation-replace.mjs, on commit 36706e5e. Every anchor hit 1 → 0, and every restore showed blob == HEAD with an empty git diff HEAD. The test imports ./share-link-service.js from src, so no build or dist step is involved.
  • Drop the record-organization return: only pin 1 goes red (1 failed / 4 passed).
  • Drop the session fallback: only pin 2 goes red.
  • Drop the derived return: only pin 3 goes red.
  • Turn the refusal into return undefined: only pin 4 goes red.
• pnpm --filter @objectstack/plugin-sharing test: 49 files, 1144 tests pass. typecheck: exit 0.
• pnpm --filter @objectstack/runtime exec vitest run src/domains/share-links: 6 files, 202 tests pass. These suites construct ShareLinkService.

Gates

node scripts/pm/dispatch-gates.mjs --commands --repo objectstack-ai/objectstack derives 67 commands, plus the 53 artifact-roster families printed on STDERR (118 unique). All of them were run, and the readings are in the dev report on #15212. The first run found two real problems, both fixed in a117f81c:

• check-tenant-audit-census: a conditional insert context counted as "elevation undecidable". It is now { ...SYSTEM_CTX, tenantId }.
• check:query-options-erasure: 5 → 7 because of two as any casts on find options. Both casts are dropped.

The rest exit non-zero only because they cannot measure locally. Four need PR context (closing-target-claim, partof-closing-keyword, single-claim-paths, governed-queue-guard). One needs an unshallowed clone (check-plugin-teardown-shape --self-test). Three need a full workspace build (check:i18n, check:dual-build-cjs-loads, check:published-readme-exports). All of these are NOT MEASURED locally and are left to CI.

Acceptance notes

• The sys_share_link row in platform-object-tenancy.ts is still unclassified. With the writer now stamping, it is ready for 8b, which owns the engine-side change; that is not done here.
• The sys_share_link row in organization-ownership-inventory.ts (fate: 'attribution', subject anchor object_name / record_id) already matches this stamp. No change is needed.
• sharing-plugin.ts is not touched. The stage needs no new wiring, because the posture is the requested one and the Default Organization comes from the same D9 probe the engine uses.

---

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

This PR changes 1 package(s): @objectstack/plugin-sharing, touching 8 documentable anchor(s).

7 hand-written doc(s) NAME something this change touched and may need an implementation-accuracy re-verification:

• content/docs/automation/flows.mdx (via sys_organization (literal, a string literal in ORGANIZATION_OBJECT))
• content/docs/deployment/cli.mdx (via sys_organization (literal, a string literal in ORGANIZATION_OBJECT))
• content/docs/deployment/seed-tenancy-repair.mdx (via sys_organization (literal, a string literal in ORGANIZATION_OBJECT))
• content/docs/permissions/administrator-guide.mdx (via sys_organization (literal, a string literal in ORGANIZATION_OBJECT))
• content/docs/permissions/system-context.mdx (via createLink (symbol, a method of class ShareLinkService))
• content/docs/protocol/kernel/config-resolution.mdx (via sys_organization (literal, a string literal in ORGANIZATION_OBJECT))
• content/docs/protocol/objectql/schema.mdx (via sys_organization (literal, a string literal in ORGANIZATION_OBJECT))

⛔ 5 release-owned page(s) also name something this change touched. These are read-only:

• content/docs/releases/implementation-status.mdx (via sys_organization (literal, a string literal in ORGANIZATION_OBJECT))
• content/docs/releases/v14.mdx (via createLink (symbol, a method of class ShareLinkService))
• content/docs/releases/v17/17-1.mdx (via sys_organization (literal, a string literal in ORGANIZATION_OBJECT))
• content/docs/releases/v17/17-4.mdx (via sys_organization (literal, a string literal in ORGANIZATION_OBJECT))
• content/docs/releases/v17/17-5.mdx (via sys_organization (literal, a string literal in ORGANIZATION_OBJECT))

content/docs/releases/ is RELEASE-OWNED (AGENTS.md "Documentation Guardrails"): release
notes are written centrally at release time, and a code PR that edits them is the exact PR
that guardrail exists to stop. They are still audited — read-only. If one of them is actually
wrong, file an issue or open a dedicated docs-only PR; do not edit it here.

What this run could not see

• the SDK route bridge reached 54 of 206 client-bound route-ledger rows — the other 152 have no registrar path: tail to select them, so pages documenting THEIR client methods cannot appear above, on this or any run. Of those 152: 0 are remediable by widening that discovery convention (an in-repo file declares the path; the convention did not scan it); 55 are structural — on a ledger where NOT ONE row is declared in-repo, so no discovery change reaches them at any price; 97 are undecided (no in-repo declaration, on a ledger that has other in-repo registrars — absence and an unreadable spelling are not distinguishable here). The rows themselves: node scripts/docs-audit/affected-docs.mjs --bridge-coverage
• 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 — 9 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 725a5b1311ecc051edafcd8122ad47dfe1ccfbf8 → packageMentionDocs.

Which tree this was computed on

This run read content/docs from 9affd116663b8c86048f6fd44155c8b413f72c7e — the merge of head a117f81c431314b0dbba46c865b7393b876f6a38 into base 725a5b1311ecc051edafcd8122ad47dfe1ccfbf8, which is what actions/checkout gives a pull_request run. Not the PR head.

A worktree cut from an older main holds a different content/docs, so re-deriving there can legitimately return a different list — that is a different tree, not a wrong row. To answer on the same tree:

# while this PR is open — GitHub drops the merge commit once it closes
git fetch origin 9affd116663b8c86048f6fd44155c8b413f72c7e && git checkout 9affd116663b8c86048f6fd44155c8b413f72c7e
# afterwards, rebuild it from the two parents, which stay fetchable
git fetch origin 725a5b1311ecc051edafcd8122ad47dfe1ccfbf8 a117f81c431314b0dbba46c865b7393b876f6a38 && git checkout -B drift-repro 725a5b1311ecc051edafcd8122ad47dfe1ccfbf8 && git merge --no-ff a117f81c431314b0dbba46c865b7393b876f6a38

node scripts/docs-audit/affected-docs.mjs --json 725a5b1311ecc051edafcd8122ad47dfe1ccfbf8

⚠️ That checkout carried uncommitted changes, so the commit above does not fully identify what was read.

Advisory only, and a precision-first one (#9192): a page is listed because it names a
symbol, wire route or SDK method this diff touched — not because it mentions a changed
package. Each row says which anchor put it there, so a wrong row is reportable rather than
merely annoying. To re-verify, run the docs-accuracy-audit workflow scoped to these files:
node scripts/docs-audit/affected-docs.mjs 725a5b1311ecc051edafcd8122ad47dfe1ccfbf8 → pass the list as
args.docs, on the commit named under Which tree this was computed on.