spec: three `sharing.zod.ts` docblock sentences go false when #15072 lands — the `field` recipient stops being "not yet authorable"

[os-warren]

Blocked-by: #15072

Filed by the domain:services execution seat (session session_01XpTx2tbq3pZRYAdoGt6E6Y, os-warren, seat post #6021) as a cross-seat request into the domain:spec queue. Unassigned; domain:*, type and priority are triage's — this card asks for the edit, it does not propose a label as a fact.

Filed as a card rather than a comment because a cross-seat request that lives only in prose is invisible to candidate queries, sweeps and ageing alerts.

Named reader: the domain:spec seat (seat post #6017) — packages/spec is a single-owner lane, which is exactly why this is a request and not a patch.

Why this exists

PR #15235 (Fixes #15072) lands the services half of the #14103 ruling: ShareRecipientType's field member becomes enforced. Its dev correctly declined to edit packages/spec — the dispatch forbids it, and that TSDoc feeds the generated content/docs/references/ tree, so touching it would widen a Clause-② PR into another lane's generated artifacts. That decline was right and is not being second-guessed; it is why the sentences need an owner.

The dev raised two of these in its report's open_questions. There are three. Measured on origin/main 1bc3c092a, 2026-09-04T07:0xZ:

packages/spec/src/security/sharing.zod.ts
 :91   executor half is #15072 (`plugin-sharing`); until it lands, the …
 :110  deliberately NOT authorable until the implementation lands.
 :262  #15072, and until that lands a `field` rule is skipped LOUDLY at seed.

CONTROL: ShareRecipientType in the same file → 4 hits, so the grep reads the file.

:110 was not in the dev's list. Recorded here because a follow-up sized from that report would have left one false sentence behind, and a docblock that says a shipped member is "NOT authorable" is the kind of thing a reader trusts and does not re-derive.

What goes false, precisely

Once #15235 merges, all three describe a state that no longer exists:

• a field rule is no longer skipped at seed — bootstrap-declared-sharing-rules.ts mapRecipientType gains case 'field': return 'field', replacing the default: return null that made it a counted skipped with a warn;
• sys_sharing_rule.recipient_type accepts field (the select gains it, pinned as a superset of ShareRecipientType.options);
• the member is authorable.

⚠️ These are TSDoc comments — no runtime effect, and no gate reads them. That is the whole risk: nothing will go red when they become false, so they will sit there until a human trips over them.

Timing — please do not land this before #15072

Blocked-by: #15072 is set deliberately. If these sentences are deleted first, the spec briefly claims the member is authorable while the executor still refuses it at seed — the same declared ≠ enforced gap in the opposite direction, which is the failure mode this lane spends most of its time on. ⛔ Land after, not before.

Not asked for

⛔ No schema change, no grammar change, no new member. The spec half already shipped (#14103 / PR #15084) and is correct: ShareRecipientType carries 'field', and sharedWith.value for that member is already refused at parse unless it matches /^[a-z_][a-z0-9_]*$/. This is comment text only. ⚠️ check:docs may want gen:docs re-run since that TSDoc feeds the generated references tree — flagged, not diagnosed from this seat.

Refs: #15072 / PR #15235 (the executor half) · #14103 / PR #15084 (the spec half, landed) · #6017 (spec seat post)