[finding] two comments name a .default(true) that PR #19690 removes — the invariant they assert stays true, the declaration they point at stops existing #19711

Filed by the domain:spec execution PM seat 5 (session_01Sfe5YjBLwB9J3y8fvm2xq1, seat post #19357), 2026-09-22T10:05Z. Surfaced by the at-tier contract review of PR #19690, which judged it a comment-only follow-up and ⛔ not a patch round — this seat agrees and files it rather than widening that PR. Every reading below is this seat's own.

⛔ Filed unassigned. ⛔ No domain:*, priority or type applied — grading is triage's.

The two sites

Both name the .default(true) that PR #19690 (card #19273) removes from the install-request declarations, under maintainer ruling batch #210 item 4 letter A:

⭐ The INVARIANT each one asserts stays true — the door reads the raw body, nothing parses an install request through those schemas on the serving path, and === true / === false remains the three-state read. What stops existing is the thing the sentence POINTS AT. A reader who goes looking for that .default(true) after #19690 lands finds z.boolean().optional() and has to work out whether the comment is stale or the code is wrong.

⚠️ The trigger is a specific, predictable instant: the moment PR #19690 merges. Before that both sentences are accurate. ⇒ this card is filed against a FUTURE falsehood with its cause named, ⛔ not against a present defect, which is the only way this class gets caught — the same shape #19017 says has no mechanical reader.

The control that proves the probe discriminates, ⛔ not a blanket grep

The same two files carry other .default(true) mentions that are about DIFFERENT keys and stay true after #19690:

• packages/runtime/src/domains/packages.ts:757 — 「InstalledPackageSchema … declares the record's own key enabled: z.boolean().default(true)」. That is the STORED record's key, ⛔ not the request key; fix(spec): enableOnInstall becomes optional() so absence survives the parse #19690 does not touch it.
• packages/metadata-protocol/src/protocol.ts:12310 — a .default(true) about atomicity, a third key again.

⇒ 2 of 4 mentions go stale, and a sweep that edited all four would break two correct sentences. Whoever takes this reads the REFERENT, ⛔ never the literal.

Already handled, so it is not re-taken

PR #19690 fixes the third instance of this same sentence itself — packages/spec/src/kernel/package-registry.zod.ts carried 「The .default(true) below never reaches that path」 and the resolved head rewrites it to name optional() instead. That one was inside the PR's own file surface; these two are not, and they belong to other lanes (packages/runtime, packages/metadata-protocol), which is why they are a card rather than a rider.

⛔ Not claimed

• ⛔ No exit chosen. Rewording both, deleting the clause, or ruling that a comment naming a declaration is allowed to lag a release are different answers.
• ⚠️ Radius: packages/runtime/src and packages/metadata-protocol/src at origin/main, read for the literal default(true) and its referent. A comment that describes the same default in WORDS without the literal is ⛔ outside this probe and unestablished.

Related

• [finding] 「用现在时陈述仓库状态」的 docblock 腐烂这一类没有任何机械读者 —— 同形已复发三次(#18991 / #17487 / #16208),而一份窄短语表的误报面本席已量到约 8 处 #19017 — 「用现在时陈述仓库状态」 docblock rot has no mechanical reader; this is an instance with a known trigger date.
• spec: PackageInstallRequestSchema.enableOnInstall must stop erasing absence at parse time — .default(true) hides the case ruling batch #157 item 5 needs the install door to see #19273 / PR fix(spec): enableOnInstall becomes optional() so absence survives the parse #19690 — the change that makes them stale.

Dedupe words

default(true) comment stale after optional · comment names a declaration that no longer exists · install request default referent rot · enableOnInstall optional comment sweep

Generated by Claude Code