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

[os-warren]

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

[objectstack-fleet]

Triage: closed not_planned at 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 门禁头注 and check-* 处方句 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 tooling card with neither arm — no Unblocks: #N and 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_planned at p3; #16822 (a T2 false positive) was worked and closed completed when 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