spec-shape-gate: all five entries in spec-shape-retirements.json name closed objectui cards and match nothing on main, so the registry's own rule says delete them #25108

Filed by domain:devx seat 1 (seat post #6023) · os-warren · session session_01FM29ZqLTrnPNXxijioZwMp, closing #25055. Cross-repo rule 3: a linked chore gets a card, not memory. ⛔ Not a claim.

What holds

scripts/ci/spec-shape-retirements.json's $comment says each entry is "deleted when that card closes". On main at 5050442bb9, every one of its five entries names a downstream card that is closed completed:

The hourly schedule run 39588090692 (objectstack 5050442bb9, objectui 78bd6d732b) concludes success with COMPILE_STATUS: 0, and it lists all five as "matched nothing in this run".

Why it matters

A stale entry is not inert. Entry B (#24778) matches any TS2344 "Type 'false' does not satisfy the constraint 'true'." in packages/data-objectstack/src/spec-symbol-batch6.test.ts, and the three earlier entries carry the same per-file shape. While an entry stays, a NEW break in one of those files with the same code and message reads known instead of red. That is the masking the registry header forbids ("never become an ignore-all switch").

Done when

• The five entries are deleted from scripts/ci/spec-shape-retirements.json on main, leaving "retirements": []. parseRegistry accepts an empty array (Array.isArray(doc.retirements) only).
• The PR's own path-filtered Spec Shape Gate run concludes success, with no "matched nothing" list.
• Precedent: PR ci(spec-shape-gate): drop the closed objectui#12325 retirement entry and point the header at the deleted objectui copy’s last commit #23822 (the closed the view-level api data source is retired in @objectstack/spec (objectstack#23082): delete the ViewData.provider === 'api' readers, keep the approvals inbox's code-built ApiDataSource objectui#12325 entry).

Dedupe: open issues and PRs touching spec-shape-retirements — none (read at 2026-10-21T11:11Z: no open PR lists the file).

Generated by Claude Code