Skip to content

finding: check-engine-double-contract.mjs hardcodes its own ledger size in 5 prose sites that go stale on every --write, with nothing to catch them #9915

Description

@os-steve

Observation only — filed unassigned, not fixed. Found while resolving the PR #9712 / #9680 merge conflict, where regenerating the pinned ledger moved the row count and made these numbers wrong in the same commit.

What

scripts/check-engine-double-contract.mjs states its own census size as a literal in explanatory prose. scripts/engine-double-contract.pinned.json is a generated artifact whose size changes whenever anyone runs --write — which the gate's own failure messages instruct authors to do — so every one of these sentences silently goes stale on a routine, sanctioned action.

After the routine regeneration in PR #9712 (308 rows / 319 doubles becomes 310 rows / 321 doubles), five sites are wrong:

linetext
1481folding 308 generated rows in would
1501doubles across 308 (file, verb) pairs, so 11 pairs carry more than one
1540for one verb (measured: 10 of 308 rows do)
1581a missing artifact reports 308 separate "not in the
2918a fresh checkout reporting 308 problems for one missing file

(Line 1501 also carries 319 pinned doubles. Its derived claim — "11 pairs carry more than one" — happens to survive, because 321 − 310 is still 11. That it stayed true by coincidence rather than by construction is the point.)

A sixth site, 308 entries today, was corrected in PR #9712 only because it sat inside the paragraph that PR was already rewriting for a different reason. The other five were deliberately left alone as out of scope.

Why it is worth a card rather than a shrug

This is the same defect class the gate itself now guards against, one level up. #9680's finding was "the pinned count is a printed number, not a checked one". These are measured numbers in prose that nothing checks — and they sit in the comment block whose stated job is to justify a merge-blocking ratchet to the next reader.

There is direct evidence of the cost: the 269 commits figure in this same header shipped wrong by ~12x, was caught only by a human reading it, and needed its own correction (#9878). A reader who spots 308 disagreeing with a run that prints 310 has no way to know which other numbers in the header are still trustworthy, so a small drift discredits sound measurements sitting next to it.

Notes toward a fix (not a decision)

Options seen while working in the file, in rough order of cost:

  1. Rephrase to remove the magnitude — "the generated rows", "a fresh checkout reports one error, not one per row". Cheapest; loses the sense of scale that makes the DEBT-ledger comparison argument land.
  2. Round and mark the numbers as illustrative ("~300 rows"), so drift cannot make them false.
  3. Derive them: have --write regenerate a small marked block in the header, the way the ledger itself is generated. Most faithful, and the most machinery for a comment.

Whether these numbers are load-bearing enough to be worth any of that is a judgement call, which is why this is filed rather than fixed.

Scope

Prose only. No invariant, no criterion, no exit code, no output string is affected — the gate's behaviour is correct at every one of these sites. check-engine-double-contract is green at PR #9712's head with all five present.

Generated by Claude Code

Metadata

Metadata

Assignees

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions