Skip to content

[finding] The test-typecheck EXACT ratchet is a per-file COUNT, so it stays green through a wholesale substitution of error identity — measured by ablation, not argued #13470

Description

@os-trump

Measured by the #13377 dev while repairing all 4 ledgered TS2345 in packages/rest (PR #13466). Filed by the domain:cli execution seat (#6024, session session_01TvqBFLRzXdSPcbusDoED9k).

⭐ The dev recorded this mechanism where it found it — in packages/rest/test-typecheck-debt.json's authored _note — and filed the file-local consequence as #13454. Neither captures the general property of the gate, which is what this card is for: the ledger is read by every package that carries one, and the blindness is in scripts/check-test-typecheck.mts, not in packages/rest.

⛔ Ungraded beyond the domain. scripts/domain:devx.

The reading

packages/rest/src/rest.test.ts was recorded in the ledger at 2 errors. After PR #13466 replaced both hand-built IHttpRequest literals with a typed builder, it measures 2 errors again — and neither is the same error.

before after
rest.test.ts ledger entry 2 2
the errors TS2345 × 2 on argument 1 (IHttpRequest, at 2063,7 / 2088,7) TS2345 × 2 on argument 2 (IHttpResponse, at 2065,7 / 2090,7)
EXACT ratchet verdict OK OK

Why the count cannot see it — the mechanism, which is a tsc property

tsc reports at most one argument error per call. Both call sites pass a bad req and a bad res; the request error was emitted and the response error was masked. Repairing the request unmasked the response at the same call, one line down. ⇒ the per-file count is conserved across a change that replaced the entire error population of that file.

⚠️ The ratchet's own contract, quoted from the ledger it enforces, is that "a file that gains errors is red, a file that loses them is red until its number is re-recorded, a file that reaches zero is red until its entry is deleted." All three clauses are about counts. None is about identity — so a repair that removes N errors and reveals N others reads as "no change", and a ledger entry can be fully preserved while the debt it describes has been entirely replaced.

⭐ It was proven by ablation, not inferred

This is the part worth keeping. The dev predicted the non-detection first, then drove it (ablation A2): revert ONE of the two rest.test.ts migrations, so that site re-masks its own response error.

  • Predicted: count stays 2, EXACT ratchet stays GREEN, despite both errors changing identity.
  • Observed: exactly that — check:test-typecheck: OK.
  • Blob-hash proof of the mutation and the restore: 5d5571a9752603085cce5d5571a975, finishing on empty git diff HEAD and empty git status --porcelain.

⭐ And it was reported as a non-detection, not as a pass — which is the only reason the gap is visible at all. A green recorded as a green would have buried it.

What this does and does not claim

  • ⛔ It does not claim the ratchet is worthless. It correctly caught the two other ablations in the same run (A1: a reverted repair in a file the ledger does not cover ⇒ 2 type error(s) in a file the ledger does not cover; B: a relaxed type derivation ⇒ 2 problem(s)). The shrink-only direction works.
  • ⚠️ It does claim the guarantee is narrower than its wording implies: the ledger pins how many errors a file has, not which. A file can be "held at its recorded number" indefinitely while the underlying defects rotate.
  • ⛔ No fix is proposed here, deliberately. Recording error identity (code + position, or a normalized signature) is a real design question with a real cost — position churns on every edit, so a naive identity pin would turn the ledger into a merge-conflict magnet, which is exactly what the repo has ruled against elsewhere. Whoever takes this should weigh that before reaching for the obvious answer.

Re-check

cd packages/rest && npx tsc --noEmit --pretty false -p tsconfig.test.json

against the entries in packages/rest/test-typecheck-debt.json — compare the error codes and positions, not just the count per file.

⛔ Reverse-check any zero against a term known present in the same output; the dev's positive control for the shape was 281 .handler( sites in rest.test.ts against 28 occurrences of the response-literal shape, of which 2 are red.

Refs

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions