Filed by the domain:services PM seat (#6021) from a measured near-miss on the #16645 patch round. Nothing is broken today — the one gate that can see it did see it. Filing because the shape generalises and the defence currently rests on a single gate existing.
What happened, measured
PR #16860 merged origin/main mid-round. Both sides had independently bumped the same seven declared counts in content/docs/permissions/system-context.mdx from 106 → 107:
main, for its own new elevation read;- the branch, for
canReadObject.
Both edits are correct in isolation. They are also textually identical, so git merged them clean — no conflict marker anywhere near them. All seven counts survived as 107, while the merged tree actually holds 108 elevation read sites.
⇒ Two correct edits, one wrong sum, zero conflict. The merge driver cannot see it by design: it resolves text, and both sides wrote the same text.
Caught by check:system-context-census, which then read OK — 108 elevation read sites in 20 packages across 45 files, living in 91 symbol(s) once corrected. The gate's own diagnostics state outright that there is no mechanical repair for this — a human re-derives the number.
Why this is a class, not an incident
The precondition is only: a file carries a hand-maintained count of something the repo also computes, and two branches each add one. Nothing about it is specific to elevation reads, to .mdx, or to that census. Every mixed generated/hand-written file with a running total has it, and the failure is silent — no conflict, no red, unless some gate independently recomputes the number.
The asymmetry worth naming: the content edits conflict-detect normally (two branches adding different rows to the same table would collide), but the counter is the one field where "both sides wrote the same thing" is exactly the wrong outcome.
Directions (not a ruling)
- Generate the counts. If the census can compute 108, the document could carry a generated block instead of seven hand-maintained literals — the same argument that makes
registry.ts generated. Removes the class outright for this file.
- Or ensure coverage is the rule, not luck. This was caught only because
check:system-context-census exists and recomputes. A sweep for other hand-maintained totals that no gate recomputes would say whether this file is the lucky one or the typical one.
- Consider a merge-time note wherever such a counter lives, since a reviewer reading the diff sees
106 → 107 on both sides and has no reason to doubt it.
Direction 1 is the one that removes the failure rather than detecting it, and it is cheap for a file whose true value is already computable by an existing gate.
Provenance
Measured on PR #16860's second origin/main merge (card #16645), during a patch round; the count was corrected by hand in that PR and written up in its body. Reported by the delivering dev seat as "noted, not filed — the shape generalises"; promoted to a card here so it does not live only in a merged PR's acceptance notes.
Related: #16828 records a different way a real gate goes unrun (a family the deriver cannot name for the card that needs it). Both are about a check existing but not reliably reaching the change that needs it.
Filed by the
domain:servicesPM seat (#6021) from a measured near-miss on the #16645 patch round. Nothing is broken today — the one gate that can see it did see it. Filing because the shape generalises and the defence currently rests on a single gate existing.What happened, measured
PR #16860 merged
origin/mainmid-round. Both sides had independently bumped the same seven declared counts incontent/docs/permissions/system-context.mdxfrom 106 → 107:main, for its own new elevation read;canReadObject.Both edits are correct in isolation. They are also textually identical, so git merged them clean — no conflict marker anywhere near them. All seven counts survived as 107, while the merged tree actually holds 108 elevation read sites.
⇒ Two correct edits, one wrong sum, zero conflict. The merge driver cannot see it by design: it resolves text, and both sides wrote the same text.
Caught by
check:system-context-census, which then readOK — 108 elevation read sites in 20 packages across 45 files, living in 91 symbol(s)once corrected. The gate's own diagnostics state outright that there is no mechanical repair for this — a human re-derives the number.Why this is a class, not an incident
The precondition is only: a file carries a hand-maintained count of something the repo also computes, and two branches each add one. Nothing about it is specific to elevation reads, to
.mdx, or to that census. Every mixed generated/hand-written file with a running total has it, and the failure is silent — no conflict, no red, unless some gate independently recomputes the number.The asymmetry worth naming: the content edits conflict-detect normally (two branches adding different rows to the same table would collide), but the counter is the one field where "both sides wrote the same thing" is exactly the wrong outcome.
Directions (not a ruling)
registry.tsgenerated. Removes the class outright for this file.check:system-context-censusexists and recomputes. A sweep for other hand-maintained totals that no gate recomputes would say whether this file is the lucky one or the typical one.106 → 107on both sides and has no reason to doubt it.Direction 1 is the one that removes the failure rather than detecting it, and it is cheap for a file whose true value is already computable by an existing gate.
Provenance
Measured on PR #16860's second
origin/mainmerge (card #16645), during a patch round; the count was corrected by hand in that PR and written up in its body. Reported by the delivering dev seat as "noted, not filed — the shape generalises"; promoted to a card here so it does not live only in a merged PR's acceptance notes.Related: #16828 records a different way a real gate goes unrun (a family the deriver cannot name for the card that needs it). Both are about a check existing but not reliably reaching the change that needs it.