Filed by the domain:spec execution seat (session session_01F8SRGcf2eKTK7RRpWCGxwf, R1) out of the at-tier contract review of PR #16636 (card #15624), which escalated it to the seat as an explicit fold-or-file decision. ⛔ The seat chose file, not fold: it registers a different key belonging to #14478's nested half, and widening a diff during its own contract review is the wrong trade.
⛔ No domain:* set — routing is triage's. It lands in packages/spec/src/migrations/entries/retired-keys/ + the generated registry.
What is missing
#14478 renamed two keys in MetadataManagerConfig (kernel/metadata-loader.zod.ts):
| key |
tombstone exists |
registered in RETIRED_KEYS_BY_MAJOR[18] |
outer cache.ttl → deleted |
✅ |
✅ — registered by PR #16636 |
nested cache.databaseLoader.ttl → ttlMs |
✅ |
⛔ no |
⇒ After #16636 lands, cache.databaseLoader.ttl is the one unregistered #14478 tombstone in this def, sitting beside a sibling that is registered.
Why it is worth a card rather than a shrug
The reviewer's finding, and it is the load-bearing half:
the claim is accurate, but house precedent does register nested rename tombstones, and this PR registered the sibling cache.ttl in the same def.
Precedent named in the same review: 18.kernel__MetadataManagerConfig__persistence.overlayWritable.ts, 18.system__RegistryConfig__cache.ttl.ts, 18.kernel__SandboxConfig__process.timeout.ts — nested, dotted, all registered.
⚠️ No gate will ever ask for it. Gates (b)/(b2) in packages/spec/scripts/build-schemas.ts iterate only top-level schema.properties, so a nested entry is inert to them — measured, and recorded as a standing boundary in PR #16636's ## 验收备注. ⇒ Nested-key retirements register by convention, not by enforcement. That is exactly the class where an omission survives indefinitely: nothing red, nothing to notice, and the next reader has to re-derive that the gap is deliberate-looking but accidental.
The D3 semantic entry does carry the prescription today, so ⛔ nothing is broken for an author — this is registry completeness, which is why it is p3 and not higher.
Scope
One entry file (18.kernel__MetadataManagerConfig__cache.databaseLoader.ttl.ts, dotted spelling per the precedents above) + the regenerated registry line. Same def, same major.
⚠️ Sequencing: after PR #16636 merges. It touches the same def and the same RETIRED_KEYS_BY_MAJOR[18] block, so starting before that lands puts two writers on one generated file for no gain.
⭐ Worth considering in the same breath, but ⛔ not assumed by this card: whether the top-level-only walk should be taught to see dotted rows at all. If it should, this card becomes a test case rather than a hand-registration — and that is a bigger question than one entry file, so it wants its own card if anyone wants it pursued.
Refs: #15624 (the card whose review found it) · PR #16636 · #14478 (the rename) · the contract-review verdict on #15624 (5572421551).
Filed by the
domain:specexecution seat (sessionsession_01F8SRGcf2eKTK7RRpWCGxwf, R1) out of the at-tier contract review of PR #16636 (card #15624), which escalated it to the seat as an explicit fold-or-file decision. ⛔ The seat chose file, not fold: it registers a different key belonging to #14478's nested half, and widening a diff during its own contract review is the wrong trade.⛔ No
domain:*set — routing is triage's. It lands inpackages/spec/src/migrations/entries/retired-keys/+ the generated registry.What is missing
#14478renamed two keys inMetadataManagerConfig(kernel/metadata-loader.zod.ts):RETIRED_KEYS_BY_MAJOR[18]cache.ttl→ deletedcache.databaseLoader.ttl→ttlMs⇒ After #16636 lands,
cache.databaseLoader.ttlis the one unregistered #14478 tombstone in this def, sitting beside a sibling that is registered.Why it is worth a card rather than a shrug
The reviewer's finding, and it is the load-bearing half:
Precedent named in the same review:
18.kernel__MetadataManagerConfig__persistence.overlayWritable.ts,18.system__RegistryConfig__cache.ttl.ts,18.kernel__SandboxConfig__process.timeout.ts— nested, dotted, all registered.packages/spec/scripts/build-schemas.tsiterate only top-levelschema.properties, so a nested entry is inert to them — measured, and recorded as a standing boundary in PR #16636's## 验收备注. ⇒ Nested-key retirements register by convention, not by enforcement. That is exactly the class where an omission survives indefinitely: nothing red, nothing to notice, and the next reader has to re-derive that the gap is deliberate-looking but accidental.The D3 semantic entry does carry the prescription today, so ⛔ nothing is broken for an author — this is registry completeness, which is why it is p3 and not higher.
Scope
One entry file (
18.kernel__MetadataManagerConfig__cache.databaseLoader.ttl.ts, dotted spelling per the precedents above) + the regenerated registry line. Same def, same major.RETIRED_KEYS_BY_MAJOR[18]block, so starting before that lands puts two writers on one generated file for no gain.⭐ Worth considering in the same breath, but ⛔ not assumed by this card: whether the top-level-only walk should be taught to see dotted rows at all. If it should, this card becomes a test case rather than a hand-registration — and that is a bigger question than one entry file, so it wants its own card if anyone wants it pursued.
Refs: #15624 (the card whose review found it) · PR #16636 · #14478 (the rename) · the contract-review verdict on #15624 (
5572421551).