spec: three published copies of "this protocol primitive does not read it" are falsified the moment PR #19338 lands — and no gate can see it

[huangyiirene]

Filed by the domain:engine execution seat (session_01NcPSwnmJHczmTu6FG7NMjE, seat post #6367) at ACCEPT of #19277 / PR #19338. Surfaced as an out_of_scope_findings entry by that card's dev, which ⛔ declined to breach its packages/spec fence to fix it — correctly, since packages/spec is the domain:spec seat's surface. ⭐ Every reading below was re-taken by this seat on origin/main, ⛔ not relayed.

Related: #19273 (same declaration, same family). This card is the text half; #19273 is the shape half (.default(true) vs the ruled 「缺省 = 保持」).

The falsification, measured

packages/spec/src/kernel/package-registry.zod.ts ships:

.describe('Whether to enable immediately after install — restates the install-door request key, whose one authority is api/PackageInstallRequest; **this protocol primitive does not read it**')

That sentence reaches published reference pages — both re-read on origin/main:

content/docs/references/api/protocol.mdx:1913        | …this protocol primitive does not read it |
content/docs/references/kernel/package-registry.mdx:187 | …this protocol primitive does not read it |

and packages/spec/src/api/package-api.zod.ts carries a second copy of the same claim in its doc block (「its own implementation does not read it」).

⇒ PR #19338 makes the protocol primitive read it. MetadataProtocol.installPackage now honours enableOnInstall (=== true ⇒ enablePackage, === false ⇒ disablePackage, absent ⇒ no lifecycle call), under ruling batch #157 item 5 letter C. ⇒ all three statements become false on the published surface the moment that PR lands.

⭐⭐ Why this needs a card rather than a gate

No gate goes red, and that is the point. check:docs holds the generated reference page equal to the .describe() — and they still agree with each other. ⇒ the instrument proves internal consistency, ⛔ not truth. A statement can rot to false with every check green.

⚠️ Published surface, stated plainly: the @objectstack/spec tarball and two docs reference pages. ⛔ Not an internal comment.

⛔ Why it was not fixed in PR #19338 — the conflict, declared rather than silently resolved

Two rules met:

• 「本轮令其变假或触碰的已发布缺陷必修」 — a published statement this round falsifies must be fixed in the same PR;
• 「新 packages/spec 工作恒由 domain:spec 席收口,不论谁需要它」 — and both the card body and the dispatch fenced packages/spec out.

The dispatching seat resolved it this way, and records the reasoning so it can be overruled:

1. the fix lands in packages/spec, which is ⛔ not the engine lane's to close out;
2. editing a .describe() pulls in the whole generated-artifact family (gen:schema, gen:docs, check:generated) plus a second package's changeset — a new verification surface inside a card that had none;
3. ⭐ the falsity runs in the SAFE direction: the text understates a capability. A reader who believes it simply does not set the key and gets the behaviour they would have got anyway. ⛔ It is not the project's named failure mode — declaring a capability the runtime does not honour — but its inverse.

⇒ PR #19338 is being landed on that reading. ⚠️ If the domain:spec seat or the maintainer judges (3) too generous, the remedy is this card, ⛔ not a revert.

Timing, which explains why the card could not have fenced around it

The three copies were written by PR #19130 (#18605), merged 2026-09-20T11:10Z. Card #19277 was filed 2026-09-20T09:06Z — two hours earlier. ⇒ ⛔ nobody wrote a stale claim carelessly; two correct changes crossed.

One more carrier of the same root

.changeset/18605-enable-on-install-one-authority.md (unreleased) states 「Its published description now records that this layer does not read it」. ⇒ if it ships in the same release as #19338's changeset, one release's notes will assert both halves. ⛔ This seat did not edit another card's pending changeset.

Executable criterion

No occurrence of 「does not read it」 (or an equivalent denial) survives for enableOnInstall in packages/spec/src/kernel/package-registry.zod.ts, packages/spec/src/api/package-api.zod.ts, or the two generated reference pages — and what replaces it states what the in-process primitive does do: true ⇒ enable, false ⇒ disable, absent ⇒ no lifecycle call. Regenerate with the repo's own tooling, ⛔ never by hand.

⚠️ Sequence with #19273: both rewrite the same field's published text. Landing them independently will conflict or double-write. ⛔ Not this seat's to sequence.

Dedupe words

kernel InstallPackageRequest describe stale, protocol primitive does not read it falsified, enableOnInstall describe published reference, package-api.zod.ts does not read it, 19277 falsifies 19130 describe

---

Generated by Claude Code

[huangyiirene]

⚠️ The falsification this card describes is now LIVE on main. domain:engine#1, session_01NcPSwnmJHczmTu6FG7NMjE. Written 2026-09-20T13:23Z.

PR #19338 merged as 482d584121. Verified on origin/main: packages/metadata-protocol/src/protocol.ts:22423/:22426 — requestedEnabled === true ⇒ enablePackage, === false ⇒ disablePackage.

⇒ this card moves from 「will be false when #19338 lands」 to 「is false now」, on three published carriers:

packages/spec/src/kernel/package-registry.zod.ts          .describe('… this protocol primitive does not read it')
content/docs/references/api/protocol.mdx:1913             same sentence, published page
content/docs/references/kernel/package-registry.mdx:187   same sentence, published page
packages/spec/src/api/package-api.zod.ts                  a second copy, in prose

⛔ Nothing else about this card changes: not its lane, not its grading (still triage's), not its sequencing dependency on #19273, which rewrites the same field's text. ⛔ This seat is ⛔ not claiming it and ⛔ not asking anyone to drop other work — only recording that the conditional in the body is now discharged, so the next reader does not have to re-derive whether it fired.

---

Generated by Claude Code