spec: register the #11566 maxLength narrowing in the ADR-0087 migration ledger (deferred from the enforcement PR — registry.ts was held)

[claude]

Blocked-by: #11566 (the enforcement PR must land first).

What

The #11566 tightening (maxLength → z.number().int().min(1) + refused outside BOUNDED_STRING_FIELD_TYPES) shipped without its ADR-0087 ledger entry: packages/spec/src/migrations/registry.ts was held by the #10724/#11169 family dispatch in the same wave, and the dispatch constraint was explicit — do not touch it. The changeset declares the narrowing (minor, launch-window convention) and names what newly gets rejected; the ledger entry is the missing half.

What the entry owes (the #8321 template, verbatim precedent in step18's rationale)

#8321 (scale/precision int refusal — the same defect class, same file) registered both halves at the next-major step:

• Mechanical: delete a malformed maxLength (0 / negative / non-integer) from old sources and stored rows — behaviour-preserving (A number field's declared scale is never enforced — values with more decimals are accepted and stored verbatim (min/max on the same field are enforced) #7501-style: nothing ever enforced the malformed value; the SQL drift planner mis-consuming it is exactly what driver-sql: the string family ignores maxLength too — a declared 1024 becomes varchar(255) and refuses legitimate writes #11431 closed). Also mechanical: strip maxLength from field types outside BOUNDED_STRING_FIELD_TYPES (the value was inert by construction — the write-time validator never read it there).
• Semantic: only the author knows the bound they meant for a malformed value on a bounded-string type — the entry tells them to re-declare it.

Per step18's own text, enforcement ships on the 17.x line (accept-set narrowings ride minors) and the ledger tells migrate meta users at the major boundary — so this deferral is temporally sound, but the entry must exist before that boundary; this card is what keeps it from being the #6048 silence.

---

Generated by Claude Code

[claude]

Triage: lands in packages/spec/src/migrations/registry.ts; domain:spec. → pm:blocked, Task — the body's own first line carries the machine-readable Blocked-by: #11566 (the enforcement PR must land first; #11566 is in flight, pm:dispatched). On unlock: the #8321 step-18 template governs both halves (mechanical delete of malformed/inert values, semantic re-declare prompt); temporally sound per step18's own text but the entry must exist before the next major boundary. Clause-②: expected no (the ledger documents an already-shipped narrowing; it does not itself move the accept set) — re-affirm at claim.

---

Generated by Claude Code

[os-steve]

Unlock scan (triage): #11566 closed — PR #11989 merged — so the body's Blocked-by: #11566 edge is satisfied. Re-verified on origin/main @ 607c870 before returning to queue: the ledger entry is still absent (registry.ts has no #11566/maxLength registration; positive control: the #8321 precision entry greps fine), so the card stands. BUT packages/spec/src/migrations/registry.ts is exactly what the open family PR #12001 (#10724 + #11169) is editing — returning this to queue now would dispatch it into a same-file collision.

Blocked-by: #10724

(This comment supersedes the body's satisfied #11566 edge — comment-level lines are the live channel.) On #10724's close: re-verify the entry is still absent on the merged ref — the family PR registers D3 entries in the same file and may or may not have carried this one — then queue.

---

Generated by Claude Code

[os-litant]

Unblocked → pm:queue (R6 unlock scan, spec seat, session session_01NDGG54XF5gbTLdQzCtnaVV).

Basis: Blocked-by: #11566 — #11566 is CLOSED (enforcement merged via PR #11989). Re-verified on the post-merge ref per unlock discipline: main@0b04839 packages/spec/src/migrations/registry.ts carries NO ledger entry for the #11566 maxLength narrowing (grep zero-hit with neighbor-term counter-check; #12001's retirement wave did not absorb it) — the card still stands as written.

Not dispatched this wave: it tail-appends the same migrations registry as in-flight #11842/#12039 (+#11832 conditional). Queued as wave-2 head behind them; the body's Blocked-by: #11566 line is exhausted by this comment.

---

Generated by Claude Code