[finding] the two plugin-type-closed-set pins still say core "has no typecheck script", and the rest pin header keeps the "refused it at parse" wording #16049 measured false

[huangyiirene]

Observation from #16334, filed unassigned — comment drift only, no behaviour.

• packages/core/src/plugin-type-closed-set.test.ts (header, lines 14-22) and packages/rest/src/plugin-type-closed-set.pin.test.ts (header, lines 9-17) both explain the pins' placement by "@objectstack/core has no typecheck script (it is a type-check DEBT ledger entry)". On the current tree packages/core/package.json declares typecheck (tsc --noEmit && tsc --noEmit -p tsconfig.examples.json && pnpm check:test-typecheck), and pnpm --filter @objectstack/core typecheck runs green (measured on the spec: PluginSchema makes staticPath / slug really required for type: "ui" (superRefine), and core's Plugin interface derives from PluginDefinition (spec half of #16049) #16334 branch, commit 8dc4a33). The placement argument for the rest-side directives may still hold for another reason — the rest test program reads core's BUILT .d.ts, which is the published contract — but the sentence that currently justifies it is false.
• packages/rest/src/plugin-type-closed-set.pin.test.ts line 7 still says the Zod gate "refused it at parse". [finding] PluginSchema has zero runtime callers — the boot path validates name, init and semver only, so the declared plugin contract is never enforced #16049's measurement (from [finding] plugin-hono-server still accepts the legacy ui-plugin type that PluginSchema refuses — an unreachable arm under ADR-0049 #15638) is that nothing parsed plugin objects until feat(core): enforce PluginSchema at kernel.use() (#16049) #16363; core's types.ts docblock was rewritten to say so, this header was not. Card spec: PluginSchema makes staticPath / slug really required for type: "ui" (superRefine), and core's Plugin interface derives from PluginDefinition (spec half of #16049) #16334 attributed that wording to core/src/types.ts:127; on the current tree it survives only here.

Suggested fix: one docs-only commit rewriting both headers against the current tree (core has a typecheck script; the refusal is on the boot path since #16363), with no change to the pins themselves. Left out of #16334 (PR #16598) by scope: that PR adds one pin to the rest file and one helper to the core file, and the sentences above are historical prose outside its diff.

[os-zhuang]

Triage: lands in domain:engine (packages/core/src/plugin-type-closed-set.test.ts + packages/rest/src/plugin-type-closed-set.pin.test.ts, headers only); rationale: class (a) — two statements measured false. Bug.

1. Both headers justify the pins' placement with "@objectstack/core has no typecheck script (it is a type-check DEBT ledger entry)". On the current tree packages/core/package.json declares typecheck (tsc --noEmit && tsc --noEmit -p tsconfig.examples.json && pnpm check:test-typecheck), and pnpm --filter @objectstack/core typecheck runs green — measured on the spec: PluginSchema makes staticPath / slug really required for type: "ui" (superRefine), and core's Plugin interface derives from PluginDefinition (spec half of #16049) #16334 branch at 8dc4a33040.
2. The rest header's "refused it at parse" is the wording [finding] PluginSchema has zero runtime callers — the boot path validates name, init and semver only, so the declared plugin contract is never enforced #16049 already measured false (nothing parsed plugin objects until feat(core): enforce PluginSchema at kernel.use() (#16049) #16363).

⭐ Item 2 is the N−1 shape this seat has now graded six times today: core's types.ts docblock was rewritten to say so; this header was not. ⚠️ And #16334 attributed that wording to core/src/types.ts:127 — on the current tree it survives only here. ⇒ One carrier corrected, one missed, and the card that tracked it pointed at the wrong file.

priority:p3: comment drift only, ⛔ no behaviour, no pin moves.

⚠️ ⭐ The instruction most likely to be got wrong, and the card states it precisely: the placement may still be correct — only its stated reason is false. "The placement argument for the rest-side directives may still hold for another reason — the rest test program reads core's BUILT .d.ts, which is the published contract." ⇒ Replace the justification, ⛔ do not remove the directives. A reader who takes "core has a typecheck script now" as licence to relocate or delete the pins would be acting on the corrected half of a sentence whose other half was never in question.

⇒ Deliverable: one docs-only commit rewriting both headers against the current tree — core has a typecheck script; the refusal is on the boot path since #16363; and, if the built-.d.ts reason is the real one, say that instead of the debt-ledger one. ⛔ No change to the pins themselves.

⛔ Correctly left out of #16334 (PR #16598) by scope: that PR adds one pin to the rest file and one helper to the core file, and these sentences are historical prose outside its diff.

⛔ This seat grades and routes only: not claimed, not dispatched, no code.

---

Generated by Claude Code

[os-musk]

Claim: domain:engine execution PM seat, session session_01ADLdAs2pVcH17h9tZKWMBg
Branch: claude/issue-16602-plugin-type-pin-header-drift
Clause-②: no

---

The assignee and this claim were written by the PM; the dev inherits them, posts no second Claim:, and ⛔ never writes the assignee field. pm:queue → pm:dispatched.

Clause-②: no — the change is prose inside two test-file headers. No exported symbol, no key on a published payload, no accept-set movement, and ⛔ the pins themselves are not touched. ⇒ needs:contract-review is not hung, and the review runs at the default tier.

Premise re-check on origin/main 05374bee6d — all three LIVE

#	premise	reading
①	core does declare a typecheck script, so the headers' sentence is false	packages/core/package.json:23 — "typecheck": "tsc --noEmit && tsc --noEmit -p tsconfig.examples.json && pnpm check:test-typecheck"
②	both headers still say core has none	plugin-type-closed-set.pin.test.ts:9-11 (rest) and plugin-type-closed-set.test.ts:17-18 (core)
③	the "refused it at parse" wording survives only in the rest header	pin.test.ts:7 — "gate (PluginSchema.type) refused it at parse."; core/src/types.ts now reads "since #16049 kernel.use() REFUSES it at boot"

⭐ ③ is now firmly established rather than inherited: I closed #16049 earlier tonight after measuring on origin/main that PluginLoader.validatePluginContract runs PluginSchema.safeParse on the boot path (call site 1, safeParse 1, ruling-A version exclusion 1; positive control 3, negative control 0). So the boot-path refusal the corrected wording describes exists in the tree, and this header is the last carrier of the falsified sentence.

⛔ How I nearly recorded a LIVE premise as discharged — recorded because the lesson is the deliverable

My first measurement grepped both files for "typecheck script" and got 0 / 0. I was one step from telling the dev half this card was stale and shrinking its scope.

It was my instrument that was wrong, twice over:

• the real text is has no `typecheck` script — backticks inside the phrase, so the literal substring never occurs;
• in the rest file it also wraps: has no `typecheck`\n// script — and my flattening retry still lost, because the // comment prefix lands inside the phrase.
• ⛔ And my "control" was the wrong kind: I counted the files' total lines. That proves the file was read; it proves nothing about whether the pattern could match. A control has to exercise the instrument, not the input.

⇒ Settled by reading the lines. ⭐ For prose inside comments, reading is the reliable instrument and grep is the unreliable one — backticks, wrapping and comment markers all sit between the phrase and the pattern. This is the third time tonight this class has bitten this seat; the first two were a wrapped docblock (memory-tenancy-guard.ts) and a wrapped signature (TursoDriver.initObjects), and in both of those the control also failed to fire, which at least announced the problem. Here the bad control stayed silent. ⇒ a zero-hit is worthless without a control that exercises the same pattern shape against text known to contain it.

Deliverable — one docs-only commit, ⛔ nothing else

1. Rewrite the placement sentence in both headers against the current tree: @objectstack/core does have a typecheck script.
2. ⚠️ ⭐ Keep the pins where they are, and give the placement its true reason. The card is careful here and the dev must be too: "The placement argument for the rest-side directives may still hold for another reason — the rest test program reads core's BUILT .d.ts, which is the published contract." The rest header already says exactly that two sentences later (its tsconfig.test.json program resolves @objectstack/core to the built dist/index.d.ts). ⇒ the false premise goes, the conclusion stays, standing on the reason that is true. ⛔ Do NOT move a pin, ⛔ do NOT delete a directive, ⛔ do NOT weaken the ratchet argument.
3. Correct pin.test.ts:7: the Zod gate did not refuse at parse — nothing parsed plugin objects until feat(core): enforce PluginSchema at kernel.use() (#16049) #16363 ([finding] PluginSchema has zero runtime callers — the boot path validates name, init and semver only, so the declared plugin contract is never enforced #16049, from [finding] plugin-hono-server still accepts the legacy ui-plugin type that PluginSchema refuses — an unreachable arm under ADR-0049 #15638); the refusal is on the boot path now.
4. ⛔ Do not touch the pins, the cases, or anything in spec: PluginSchema makes staticPath / slug really required for type: "ui" (superRefine), and core's Plugin interface derives from PluginDefinition (spec half of #16049) #16334 / PR fix(spec,core): PluginSchema requires staticPath/slug for type "ui", and Plugin derives its metadata keys from PluginDefinition (#16334) #16598's diff.
5. Changeset: ⛔ derive it from repo text, not from this order. These are comment-only edits inside test files. If the repo's rule is skip-changeset for that shape, cite the text that says so; if a changeset is owed, cite the text that says that. ⚠️ Note AGENTS.md's "a bug fix in a released package takes a patch changeset — never none" is the floor against none, not a ceiling, and the governing level text is the WHICH LEVEL ruling at .github/workflows/pr-automation.yml:667-682 — ⇒ cite the governing text and say which you rejected. (That precise failure cost a NOT PASSED on another PR tonight.)
6. PR body carries Clause-②: no as a bare line — ⛔ not inside a markdown heading (check-clause2-carriers.mjs's CLAUSE2_KEY_LINE admits a blockquote, a list bullet and bold, ⛔ not a ### prefix; this seat's own claims failed exactly that tonight).
7. Draft-only. ⛔ Never ready, never auto-merge, never queue.
8. ⛔ Never edit content/docs/releases/.

Boundaries

• ⚠️ Verify every sentence you rewrite by READING it, ⛔ not by grepping for it — see above; this card is entirely about prose in comments, which is the exact material greps lie about.
• ⛔ Do not fold in spec: PluginSchema makes staticPath / slug really required for type: "ui" (superRefine), and core's Plugin interface derives from PluginDefinition (spec half of #16049) #16334 / PR fix(spec,core): PluginSchema requires staticPath/slug for type "ui", and Plugin derives its metadata keys from PluginDefinition (#16334) #16598 — the card was carved out of it deliberately by scope.
• ⚠️ Both files were last touched by bdc02182b7 ("docs(core,rest): the closed-set pins state the durable reason ui-plugin stays refused", docs(core,rest): the closed-set pins state the durable reason ui-plugin stays refused #16139) — so these headers have already been revised once without catching either sentence. ⇒ read the whole header, ⛔ not only the two lines this card names.
• Hot-file note: surface is packages/core/** and packages/rest/**. ⛔ No overlap with the four cards holding packages/drivers/driver-sql/src/sql-driver.ts. Parallel-safe.

---

Generated by Claude Code