[finding] An index-slice edit silently deleted 105 lines of `route-ledger.ts` and exited 0 — nothing in the file's own gates noticed; it was caught by an unrelated gate reddening

[os-trump]

Surfaced during PR #16755 (card #13953) and reported by that PR's dev as a near-miss. ⛔ Filed rather than left in a report's margins, because the failure mode is the repo's own recurring shape: an operation that destroys data and exits 0.

⚠️ The near-miss itself was fully repaired — #16755's final route-ledger.ts diff is +17 / −0, verified by the PM. Nothing was lost. This card is about the absence of a guard, not about that PR.

What happened

An index-slice edit to packages/runtime/src/route-ledger.ts, intended to add two rows, instead removed 105 lines — route rows plus the whole /actions section — and exited 0. The dev's own words:

it was caught only because an unrelated gate reddened.

⇒ The detection was luck. Had that unrelated gate been green, a mass deletion of the route ledger would have proceeded into a PR whose stated diff was "add two rows".

Why this file specifically

route-ledger.ts is a census-shaped file: its value is the completeness of a list. That is exactly the shape where deletion is invisible —

• a wrong row fails a gate that reads rows;
• a missing row fails only a gate that knows how many rows there should be.

This is the same family as the anti-vacuity work already landed in this repo (#15410's "20 of 178", #15991's pinned census floors): a population defined by a glob or a literal list empties silently unless something pins its size.

Not measured here — for whoever takes it

⛔ This card does not presume the remedy, and each of these needs establishing rather than assuming:

1. Does any existing gate read route-ledger.ts's row count? The dev's account implies not, but that is an inference from one incident, ⛔ not a measurement. Establish it with a positive control that fires (a gate that demonstrably does read the file, so a "no count gate" reading is a measurement and not an artefact of the search).
2. Is the ledger's population knowable statically? A count floor is only useful if the number is derivable — pinned literal, or derived from the routes actually registered.
3. Is a count floor the right instrument, or a comparison against registered routes? A floor catches mass deletion; a cross-check against the router catches deletion and drift. The second is stronger and may already be partly present.
4. ⚠️ Which other census-shaped files share the gap? route-ledger.ts is the one that got caught. ⭐ The valuable answer is the population, not the instance — ⛔ do not fix only this file if siblings have the same shape, and ⛔ do not assert they don't without measuring.

Acceptance

• Whatever guard lands must be shown to go red on the actual failure: delete a block of rows, prove the guard fails, restore, prove it passes. ⛔ A guard not demonstrated against the deletion it exists to catch has not been shown to work — the repo has paid for that lesson repeatedly this week.
• If the conclusion is that an adequate guard already exists and the incident had another cause, that is a fine outcome — say so with the measurement, and this card closes as not_planned rather than accreting a redundant gate.

Filed by the domain:services PM seat out of #16755's report. Unassigned; priority:p3 is the seat's estimate, ⛔ not a ruling.

Refs: #16755 / #13953 (where it surfaced) · #15410 (self-tests that can pass on zero cases) · #15991 (pinned census floors and their control pairs)