Found while implementing #12868 (the new FormSelectOptionSchema imports SELECT_OPTION_EDITABILITY_GUIDANCE into ui/view.zod.ts, which is how the string was read closely).
The live instance
SELECT_OPTION_EDITABILITY_GUIDANCE.prescription (packages/spec/src/shared/editability-boundary.ts) contains a bare internal issue id — the text reads "a deliberate boundary, not a missing key (#8201): ..." — and that string is printed verbatim at a refusing author whenever an editability spelling (disabled, readonly, ...) is written on a select option, on both the object-field face and (since #12868) the form-view face. That is exactly the population the just-widened Rule 3 holds (strictObject guidance/guidanceSets are "the SAME audience at the SAME moment as a refusal message"), and the id is mechanically strippable under Rule 3's own criterion: ADR-0049 and ADR-0068 sit beside it in the same string, so the citation does not lose its durable reference by dropping the id.
pnpm check:doc-authoring is green with this string in tree (measured on main at 0da7cd2 and on the #12868 branch), so the sweep did not deliberately escalate it — the gate cannot see it.
The mechanism
Rule 3's hoisted-const pass (collectTextSinkConsts) is deliberately name-based WITHIN ONE MODULE: a const is a sink when its text flows into a recognised sink in the same file (a strictObject(...) call, a const annotated StrictObjectOptions or named *_STRICT_OPTIONS). SELECT_OPTION_EDITABILITY_GUIDANCE is typed KeySetGuidance and is consumed ONLY cross-module — data/field.zod.ts and ui/view.zod.ts pass it via guidanceSets: — so no recognised anchor exists in its own file and the whole const walks free. The neighbouring EDITABILITY_BOUNDARY_GUIDANCE in the same file has the same shape and the same exposure; any future shared KeySetGuidance const consumed cross-module lands in the same blind spot.
Suggested direction
Either recognise a module-local const annotated/typed KeySetGuidance as a sink in its own right (the type exists precisely to be handed to guidanceSets, so the anchor is as unambiguous as *_STRICT_OPTIONS), or add exported-guidance modules to a small named-sink list — plus a --self-test case for the cross-module spelling, per the gate's own extend-the-detector rule. Stripping the one live id is then the mechanical edit the widened gate prescribes.
Filed unassigned (observation-class) from the #12868 dev run.
Found while implementing #12868 (the new
FormSelectOptionSchemaimportsSELECT_OPTION_EDITABILITY_GUIDANCEintoui/view.zod.ts, which is how the string was read closely).The live instance
SELECT_OPTION_EDITABILITY_GUIDANCE.prescription(packages/spec/src/shared/editability-boundary.ts) contains a bare internal issue id — the text reads "a deliberate boundary, not a missing key (#8201): ..." — and that string is printed verbatim at a refusing author whenever an editability spelling (disabled,readonly, ...) is written on a select option, on both the object-field face and (since #12868) the form-view face. That is exactly the population the just-widened Rule 3 holds (strictObject guidance/guidanceSets are "the SAME audience at the SAME moment as a refusal message"), and the id is mechanically strippable under Rule 3's own criterion: ADR-0049 and ADR-0068 sit beside it in the same string, so the citation does not lose its durable reference by dropping the id.pnpm check:doc-authoringis green with this string in tree (measured onmainat 0da7cd2 and on the #12868 branch), so the sweep did not deliberately escalate it — the gate cannot see it.The mechanism
Rule 3's hoisted-const pass (
collectTextSinkConsts) is deliberately name-based WITHIN ONE MODULE: a const is a sink when its text flows into a recognised sink in the same file (astrictObject(...)call, a const annotatedStrictObjectOptionsor named*_STRICT_OPTIONS).SELECT_OPTION_EDITABILITY_GUIDANCEis typedKeySetGuidanceand is consumed ONLY cross-module —data/field.zod.tsandui/view.zod.tspass it viaguidanceSets:— so no recognised anchor exists in its own file and the whole const walks free. The neighbouringEDITABILITY_BOUNDARY_GUIDANCEin the same file has the same shape and the same exposure; any future sharedKeySetGuidanceconst consumed cross-module lands in the same blind spot.Suggested direction
Either recognise a module-local const annotated/typed
KeySetGuidanceas a sink in its own right (the type exists precisely to be handed toguidanceSets, so the anchor is as unambiguous as*_STRICT_OPTIONS), or add exported-guidance modules to a small named-sink list — plus a--self-testcase for the cross-module spelling, per the gate's own extend-the-detector rule. Stripping the one live id is then the mechanical edit the widened gate prescribes.Filed unassigned (observation-class) from the #12868 dev run.