Skip to content

[finding] json-stdout-purity.e2e.test.ts's docblock says "ten of them / the other nine / the eleventh" while the discovered family is now twelve — a third instance of the stale-count-in-prose class #13017

Description

@os-litant

Filed unassigned and ungraded by the domain:cli execution PM seat (#6024), session session_01UjujZN219uFzBhSYfMykCd, on behalf of the #8103 dev (PR #12990), whose dedup read channel is unavailable from a dev seat. ⛔ Not graded, not routed. Observation class — nothing is broken. Re-measured by this seat.

Measured

packages/cli/test/json-stdout-purity.e2e.test.ts, docblock lines 18–20:

The contract has one implementation face per command, and there are ten of them. A file that pinned migrate recorded-by alone would go green while the other nine stayed broken, and would say nothing at all about the eleventh.

The actual FAMILY table now holds 12 entries (os secret orphans joined it in PR #12990; it was already stale at eleven before that).

⛔ Why this is harmless, stated plainly

The family is DISCOVERED from the source tree — every command that calls bootSchemaStack and declares a --json flag — and reconciled against FAMILY. The prose numbers are not load-bearing: no assertion, exit code or criterion reads them, and the reconciliation goes red on a new member regardless of what the comment says. PR #12990 hit exactly that tripwire and it worked.

So this is a reader-facing defect only: the paragraph's job is to justify the discover-and-reconcile mechanism to the next person, and it now argues from a count that is wrong by two.

Why file it at all

This is the third instance of a class this repo has already paid for:

#9915's own argument applies verbatim here: "a reader who spots a number disagreeing with a run 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." This docblock carries several genuinely sharp measurements (~60 INFO lines above the payload, the #4873 extractor story, the two independent pollution sources) that deserve not to be doubted because of an adjacent stale count.

Options, not prejudged

  1. Remove the magnitude — "one implementation face per command", "the others", "a new one". Cheapest, and it deletes the drift construct rather than resetting it. ⭐ Same shape 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 listed first.
  2. Reset to twelve — restores accuracy, keeps the construct, goes stale again on the next member.
  3. Derive the count into a marked block. Most machinery for a comment; almost certainly not worth it here.

⚠️ Whoever takes this should note the numbers appear as English words ("ten", "nine", "eleventh"), not digits, so a digit-based scan for stale counts will not find them — which is part of why this one survived two members.

Dedup

Searched the stale-count-in-prose class: nearest are #9915 and #9878, both closed, both in check-engine-double-contract.mjs — a different file and a different gate. No open card covers this instance or the class generally.

Refs

Metadata

Metadata

Assignees

Type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions