Filed unassigned by the dev seat implementing #9708, session session_01DdCnBGcHeufjrq7drTD3wt. Measured on origin/main @ a718ee3dd. Not a claim that any seam is currently invisible — the measurement below is a controlled zero. This is about the scope of the population, one level up from what #9708 ratchets.
No domain:* judgement intended beyond the routing label — triage's field.
The asymmetry
scripts/check-engine-double-contract.mjs holds two scans over two populations, and they disagree about which roots are in scope:
- the TEST DOUBLE side walks
SCAN_ROOTS = ['packages', 'examples']; - the CONSUMER SEAM side walks
packages/ alone — productionFiles() ends in a single walkSrc(join(ROOT, 'packages')).
Nothing states the narrower scope as a decision; the header's stated scope test is "production sources: the seams live in src, never in a test", which examples/ satisfies as much as packages/ does. An example app that performs a by-id write on a caller-supplied id and answers a success receipt is exactly the three-conjunct seam the invariant is about, and it would be judged by nothing.
Measured (2026-08-21, a718ee3dd)
The gate's own scanAllSeams, unmodified except for the walk roots, run twice:
narrow (packages only): 6 seams in 3 files
wide (+ examples, apps, skills, scripts): 6 seams in 3 files
extra rows the wider walk finds: []
positive control — the wide walk still finds all 6 narrow rows: true
So the blind spot is empty today, and the control is what makes that a measurement rather than a broken probe: the widened walk still returns every known row, so its zero is a real zero and not a walker that stopped working.
Why it is filed rather than fixed inside #9708
#9708's declared surface is the governance of the discovered population (a row that leaves names itself). Widening what the scan discovers is a different act: it changes the invariant's subject, adds verification surface for every future example app, and today buys zero rows. Under startup scope discipline that is an implementation-first decision to take when there is pull for it — but it should not stay undeclared, because a seam that lands in examples/ tomorrow is outside the population and outside #9708's ledger, so neither half reports it.
Two candidate shapes for whoever picks this up:
- A — walk
SCAN_ROOTS on the seam side too, so one constant governs both scans. Cheapest, and removes the unexplained asymmetry; cost is that an example app's handlers become gate-visible (measured cost today: zero rows). - B — leave the scope narrow and say so in the header as a decision with its reason, so the next reader does not have to re-measure to find out whether it was deliberate.
Related
#9708 (the population ratchet, where this was measured) · #8194 (the card that added the seam slice) · #8999 (the census-scoped-by-the-wrong-instrument family this belongs to)
Filed unassigned by the dev seat implementing #9708, session
session_01DdCnBGcHeufjrq7drTD3wt. Measured onorigin/main@a718ee3dd. Not a claim that any seam is currently invisible — the measurement below is a controlled zero. This is about the scope of the population, one level up from what #9708 ratchets.No
domain:*judgement intended beyond the routing label — triage's field.The asymmetry
scripts/check-engine-double-contract.mjsholds two scans over two populations, and they disagree about which roots are in scope:SCAN_ROOTS = ['packages', 'examples'];packages/alone —productionFiles()ends in a singlewalkSrc(join(ROOT, 'packages')).Nothing states the narrower scope as a decision; the header's stated scope test is "production sources: the seams live in
src, never in a test", whichexamples/satisfies as much aspackages/does. An example app that performs a by-id write on a caller-supplied id and answers a success receipt is exactly the three-conjunct seam the invariant is about, and it would be judged by nothing.Measured (2026-08-21,
a718ee3dd)The gate's own
scanAllSeams, unmodified except for the walk roots, run twice:So the blind spot is empty today, and the control is what makes that a measurement rather than a broken probe: the widened walk still returns every known row, so its zero is a real zero and not a walker that stopped working.
Why it is filed rather than fixed inside #9708
#9708's declared surface is the governance of the discovered population (a row that leaves names itself). Widening what the scan discovers is a different act: it changes the invariant's subject, adds verification surface for every future example app, and today buys zero rows. Under startup scope discipline that is an implementation-first decision to take when there is pull for it — but it should not stay undeclared, because a seam that lands in
examples/tomorrow is outside the population and outside #9708's ledger, so neither half reports it.Two candidate shapes for whoever picks this up:
SCAN_ROOTSon the seam side too, so one constant governs both scans. Cheapest, and removes the unexplained asymmetry; cost is that an example app's handlers become gate-visible (measured cost today: zero rows).Related
#9708 (the population ratchet, where this was measured) · #8194 (the card that added the seam slice) · #8999 (the census-scoped-by-the-wrong-instrument family this belongs to)