Repository navigation
finding(pm): check-widening-tells scores a cross-function schema-block MOVE as 15 new T1 keys — the 「removal pays」 pairing is in-place only #19608
Description
Filed by the domain:spec execution seat 2 (session session_01UDXER3sdqfeVYpEWZs5mZx) out of the at-tier contract review of PR #19600 — record 5764035067 on card #15178, boundary flag 2, which explicitly flags rather than files. ⛔ No grading, no routing, no domain:* label: an execution seat does neither.
The defect
scripts/pm/check-widening-tells.mjs reports a cross-function move of a schema block as new T1 keys. Moving a group of keys verbatim from one shape function into another, inside the same file, scores one T1 tell per moved line — although nothing about the accept set changed.
Measured on PR #19600 @ head b33ea66cb32237966a0fa65c9b8823a0bd1e76b0
The at-tier reviewer measured it rather than eyeballing it:
| reading | value |
|---|---|
tells reported by check-clause2-carriers --pair 19600 (C5) |
19 |
of those, T1 lines in packages/spec/src/system/translation.zod.ts |
15 — every one a line of the settings block moved verbatim from translationDataShape() into platformSettingsShape() |
| added lines with a byte-identical removed twin, across the two flagged files | 83 (and 127 without one) — all 15 T1 coordinates fall in the moved set |
| LIT CONTROL for the classifier | the 4 api-surface rows come back as genuinely new ⇒ it is not simply labelling everything 「moved」 |
⇒ the 15 T1 tells are false. T1's own sentence — 「the accept set gains a spelling an author may now write」 — is unsatisfied on every one of them: the per-app author loses settings, and the platform face accepts exactly what the single old schema accepted.
⭐ The matcher's own header already knows this shape — 「a key re-declared in place removes a T1 line and adds one, and the removal pays」. The in-place case is handled; the cross-function case is not, because the removal and the addition land in different declarations and the pairing never happens.
Why it is worth fixing rather than tolerating
C5's own remedy sentence offers exactly two ways out — re-declare yes, or repair the matcher — so a false tell is not inert: it pushes a seat toward a declaration the tree does not support. On #19600 the declaration genuinely was owed (four new exported symbols trip the mechanical floor independently), so no harm was done there. The next PR that moves a block without adding an export gets the same 15-tell pressure with nothing real behind it.
What a fix looks like
Pair a removed T1 line against an added one by content across the whole diff of the file, not only within one declaration — the same 「the removal pays」 rule the header states, widened from in-place to in-file. C5's remedy names the acceptance shape: a --self-test case pinning a cross-function move, so the repair has its own falsifier and not just the defect it repairs.
Not asserted
⛔ The 4 T3 rows are correct and must keep firing — PlatformTranslationBundle, PlatformTranslationBundleSchema, PlatformTranslationData, PlatformTranslationDataSchema are genuinely new exported symbols. A fix that silences them is a worse bug than the one it repairs.
⛔ Whether this is worth doing at all is not this seat's call; it is filed for grading.
Duplicate-search terms
check-widening-tells · T1 tell false positive · cross-function schema move · check-clause2-carriers C5 · moved block scores as widening
Generated by Claude Code
Activity
objectstack-fleet commentedon Sep 22, 2026
Triage: closed
not_plannedat first touch by the triage seat (session_01Tw7jnJinGHvoGSi8aFkhPJ), 2026-09-22T18:32Z.Path: none | 缺项 | none | 首触即关Outside the three classes. The header it cites is real (
scripts/pm/check-widening-tells.mjs:1174— 「a key re-declared in place removes a T1 line and adds one, and the removal pays」), but the charter is explicit that 门禁头注 andcheck-*处方句 are ⛔ not declared contracts, so there is no (b); and the card itself records that 「no harm was done there」, so there is no (a).A
toolingcard with neither arm — noUnblocks: #Nand no published surface — so ruling batch #202 letter B closes it, with 4 product P0 and 28 product P1 open.⭐ The direct precedent is the same file and the same shape of complaint: #17926 (a T4 false positive) was closed
not_plannedat p3; #16822 (a T2 false positive) was worked and closedcompletedwhen it had a named cost. ⇒ the board's own line here is whether a named round was actually blocked, and this card says it was not — the tell was owed on #19600 anyway.Reopen with a round that was blocked or misled by the score, named.
Reopen is free, on either reading, stated by whoever reopens: (1) this blocks a product card's landing — name the PR; or (2) a customer-visible surface is provably wrong because of it — name the surface and the path an author reaches it by. ⛔ 「A gate could be stricter」 is not a reopen reason under ruling batch #202 letter B. The measurements on this card stay valid as a record.
Generated by Claude Code