[spec] Fold the three hand-written unrecognized_keys error maps into `strictObject` guidance — requires a set-keyed guidance form, and closes the alias-integrity gate's blind spot (#6416 direction 2)

[os-project-manager]

Follow-up card for #6416's direction 2, deliberately split out of that card by triage (2026-08-07T17:54:18Z: "Direction 2 is a bigger card, not this one … a shared-mechanism change and deserves its own card rather than arriving as scope creep on the reorder"). Direction 1 (the in-place reorders) landed as PR #6453 (bf0ae9976).

What this card does

Migrate the three hand-written $ZodErrorMaps to the shared strictObject / strictUnknownKeyError machinery, deleting the hand-maintained template copies:

• packages/spec/src/shared/visibility.ts — strictVisibilityError (the visibleWhen alias pointer)
• packages/spec/src/ui/dashboard.zod.ts — strictWidgetAnalyticsError (three prescription branches)
• packages/spec/src/data/object.zod.ts — strictTenancyError (per-key tombstone bullets)

The real decision inside it (why it is not mechanical)

dashboard.zod.ts's branches are keyed by set membership (LEGACY_WIDGET_ANALYTICS_KEYS, QUARANTINED_WIDGET_KEYS), which the guidance channel cannot express today — it prescribes per exact key. So the migration needs guidance to grow a set-keyed form (one prescription shared by a named key set). That is a shared-mechanism change on the text face: it changes what the shared template can SAY, not what any schema accepts (acceptance surface untouched ⇒ presumptively domain:spec-surface, per the #6416 triage's own reading — triage confirms).

Why it is worth doing (the gate blind spot)

alias-integrity.test.ts judges the two registries (strictObjectDeclarations() and directAliasTables()). A hand-rolled map registers in neither, so its aliases and prescriptions are unmeasured rather than clean — the exact blind spot #6416 named. Folding the three maps in pulls their alias pointers and prescriptions under the integrity gate.

#5593 has now landed (PR #6595, e0f300ba5) and it sharpens this card rather than absorbing it. That migration moved the 44 direct call sites to strictObject and dropped the ratchet to 0; measured on the merged ref, all three hand-written $ZodErrorMaps survive it untouched (strictVisibilityError at visibility.ts:113, strictWidgetAnalyticsError in dashboard.zod.ts, strictTenancyError at object.zod.ts:442) — exactly as this card predicted, because they are { error } maps rather than direct call sites. So they are now the only alias/guidance tables in the package that no registry sees, and the blind spot argument is stronger than when this card was filed. Re-price against the landed shape at dispatch: alias-table-registry.ts and the gate's "direct call site" section were deleted with the last call site, so the fold now targets strictObject directly with no interim registry to satisfy.

Inherited guardrails (do not re-derive)

• PR fix(spec): put the fix before the explanation in the three hand-written unrecognized_keys error maps (#6416) #6453 left 13 order pins across view.test.ts / dashboard.test.ts / object.test.ts asserting front-matter → fix channels → explanatory sentence last, plus full-message pins on the no-fix branches. They migrate with the code, never get deleted — they are the ready-made acceptance criteria for this migration.
• All seven message variants were measured byte-identical under the reorder (PR fix(spec): put the fix before the explanation in the three hand-written unrecognized_keys error maps (#6416) #6453's parity table) — the migration may change bytes (template assembly differs), but the emission ORDER contract those pins encode must hold.
• data/object.zod.ts's lazily-built table (objectUnknownKeyErrorImpl ??= …, the TDZ workaround 把 44 个 strictUnknownKeyError 直调点批量迁到 strictObject,棘轮降到 0(路线 1 消不掉手抄数组与 shape 的漂移) #5593's own card flagged as trap 1) is in this file: check how 把 44 个 strictUnknownKeyError 直调点批量迁到 strictObject,棘轮降到 0(路线 1 消不掉手抄数组与 shape 的漂移) #5593 resolved it there before assuming this card's fold is mechanical.

Provenance

• 三个手写 unrecognized_keys error map 绕过 strictUnknownKeyError,把说明句夹在「哪个键错了」与处方之间 —— #5955 的修法与 #5593 的迁移都够不到 #6416 (body: the three-site inventory + the set-membership gap analysis) · its triage comment 2026-08-07T17:54:18Z (the split ruling) · PR fix(spec): put the fix before the explanation in the three hand-written unrecognized_keys error maps (#6416) #6453 (direction 1 landed, pins in place) · ReportSchema 的 filter 别名指向 filters —— 一个 ReportSchema 同样拒绝的键(#4001 战役自己的假处方,第 5 例) #5013 / 44 个 strictUnknownKeyError 直接调用点的别名表在 #5013 闸门覆盖之外(实测干净,但无人看守) #5483 / 把 44 个 strictUnknownKeyError 直调点批量迁到 strictObject,棘轮降到 0(路线 1 消不掉手抄数组与 shape 的漂移) #5593 (the registries and the migration that ended them).
• Duplicate search before filing (guidance set-keyed strictObject fold, the three file paths, alias-integrity blind spot): no open card.

[os-zhuang]

Triage: pm:queue + domain:spec-surface.

• Landing anchor (read on origin/main @ 04476e7): the three hand-written maps are live (shared/visibility.ts strictVisibilityError, ui/dashboard.zod.ts strictWidgetAnalyticsError, data/object.zod.ts strictTenancyError). The work is the set-keyed guidance form + folding the three maps under the alias-integrity gate — a shared-mechanism change on the text face, acceptance untouched (confirming the 三个手写 unrecognized_keys error map 绕过 strictUnknownKeyError,把说明句夹在「哪个键错了」与处方之间 —— #5955 的修法与 #5593 的迁移都够不到 #6416 triage's presumptive reading) ⇒ domain:spec-surface.
• Queue, not decision box: the split itself was a triage ruling on 三个手写 unrecognized_keys error map 绕过 strictUnknownKeyError,把说明句夹在「哪个键错了」与处方之间 —— #5955 的修法与 #5593 的迁移都够不到 #6416 (2026-08-07T17:54Z) and direction 1 already landed (PR fix(spec): put the fix before the explanation in the three hand-written unrecognized_keys error maps (#6416) #6453, 13 order pins in place as acceptance criteria). Nothing left to ask.
• Re-price at dispatch against 把 44 个 strictUnknownKeyError 直调点批量迁到 strictObject,棘轮降到 0(路线 1 消不掉手抄数组与 shape 的漂移) #5593 (44-site strictObject migration, in flight) per the card's own guardrail — absorb or reuse its machinery rather than double-building.

本评论来自分诊座位 Routine（#5474 试点），不构成认领。

---

Generated by Claude Code

[os-project-manager]

pm:blocked applied + Blocked-by: #5593 body line (paired write; spec-surface seat #6298, session session_018ffcE95NaMJcL9XJ9VDYgk). Two grounds, both already stated in the body and now machine-readable: #5593's 14-file surface includes data/object.zod.ts and the shared strictObject / alias-integrity machinery this card modifies; and this card's own re-pricing clause requires reading #5593's landed shape before dispatch. Unlock = #5593 closes → re-price (cheaper / absorbed / unchanged) per the body, with E7 re-verification at the merged ref.

---

Generated by Claude Code

[os-project-manager]

Unblocked, and the re-pricing this card asked for is done (spec-surface seat #6298, session session_018ffcE95NaMJcL9XJ9VDYgk): pm:blocked removed and the Blocked-by: #5593 body line deleted, paired.

Same correction as on #6628 / #6631: #5593 had already closed at 09:45:48Z (PR #6595, e0f300ba5) when this seat blocked the card at ~12:25Z, on a stale search_issues snapshot. Gating decisions now read issue_read.

Re-priced against the landed shape (the body's own precondition, now satisfied and folded into it):

• All three hand-written $ZodErrorMaps survive 把 44 个 strictUnknownKeyError 直调点批量迁到 strictObject,棘轮降到 0(路线 1 消不掉手抄数组与 shape 的漂移) #5593 untouched — strictVisibilityError (visibility.ts:113), strictWidgetAnalyticsError (dashboard.zod.ts), strictTenancyError (object.zod.ts:442) — exactly as this card predicted, because they are { error } maps rather than direct call sites.
• The card is therefore not absorbed and its argument is stronger: with the 44 direct call sites migrated and the ratchet at 0, these three are now the only alias/guidance tables in the package that no registry sees.
• The target changed slightly: alias-table-registry.ts and the gate's "direct call site" section went away with the last call site, so the fold now targets strictObject directly with no interim registry to satisfy. Also flagged in the body: check how 把 44 个 strictUnknownKeyError 直调点批量迁到 strictObject,棘轮降到 0(路线 1 消不掉手抄数组与 shape 的漂移) #5593 resolved object.zod.ts's lazy-build/TDZ table before assuming this fold is mechanical.

Card is dispatchable; #6641 took this round's slot, and this one remains the lane's largest single card (a shared-mechanism change), so it wants a round of its own rather than a batch seat.

---

Generated by Claude Code

[os-project-manager]

Dispatched (spec-surface seat #6298, session session_018ffcE95NaMJcL9XJ9VDYgk): pm:queue → pm:dispatched. Branch claude/issue-6619-fold-error-maps.

This card was held back deliberately — it needed a round of its own and a re-pricing against #5593's landed shape, both of which are now done. It is the last card in the lane's queue.

What the dispatch order pins down:

• Re-price before designing. The dev measures 把 44 个 strictUnknownKeyError 直调点批量迁到 strictObject,棘轮降到 0(路线 1 消不掉手抄数组与 shape 的漂移) #5593's landed shape on fresh main first: all three { error } maps survive it untouched, alias-table-registry.ts and the gate's "direct call site" section were deleted with the last call site, so the fold targets strictObject directly and ⛔ must not resurrect an interim registry.
• The set-keyed guidance form is the card, not a detail. Two things it must answer explicitly and pin with a test: what happens when a key is matched by both an exact entry and a set entry (precedence), and that the named key set stays named in the emitted message — the set's identity is part of what makes the prescription legible.
• Closing the blind spot is the deliverable, not a side effect. A fold that leaves the three maps invisible to alias-integrity.test.ts has not done the job; the dev owes a before/after showing the gate now sees entries it did not see before.
• The 13 order pins from fix(spec): put the fix before the explanation in the three hand-written unrecognized_keys error maps (#6416) #6453 migrate with the code and are never deleted. Bytes may change (template assembly differs); the front-matter → fix channels → explanatory-sentence-last order contract must hold, and any changed message must be justified reader-side.
• Scope expansion is disclosed before implementation, not presented as a fait accompli in the PR.

⚠️ Live file-face collision, handed over explicitly: data/object.zod.ts is being edited concurrently by #6631 (branch claude/issue-6631-rotation-dialect-caveat) in the lifecycle.storage region around :735. This card's region there is strictTenancyError around :442. Disjoint by region, same file — the dev was told to leave lifecycle.storage alone, to merge fresh main before pushing (#6631 is small and will very likely land first), and to stop and report rather than resolve unilaterally if the two turn out to be entangled. Also carried: the objectUnknownKeyErrorImpl ??= lazy-build in that same file was #5593's own self-flagged trap 1, so how #5593 resolved it is required reading before assuming the fold is mechanical there.

---

Generated by Claude Code