# U7 landed — and the number that justified it did not reproduce

_2026-09-22 · booth_

**The last v1 unit is in.** The three ratified components landed at `a306e2d`;
the fourth — filename-prefix groups replacing subfolder sections — landed here,
with `test_no_group_rail_is_shipped_yet` deleted in the same commit that built
what it guarded against. **All seven v1 capabilities are now landed.**

## The part worth remembering: the contract's own measurement was wrong

The contract stated a rule and, beside it, a table of what that rule produced.
**They are not the same computation.** Implementing the stated rule and running
it against the live set:

| booth | contract claimed | stated rule actually gives |
|---|---|---|
| `sindra-corpus-v1` | 16 | 16 ✓ |
| `sindra-sfw-pool` | 10 | 10 ✓ |
| `sindra-nude-pool` | 12 | 12 ✓ |
| **`sindra-bakeoff`** | **5** | **24** |
| **`sindra`** | **1 (degenerate)** | **27** |

Three of five matched, which is what made it survive review. The two that did
not were **the two load-bearing rows**: bakeoff was the "this pays" evidence and
sindra was the degenerate case INV-3 was written for.

**The contract contradicts itself in plain sight and nobody caught it.** Its own
worked example says `00-sheet-c1-market-noon.png` has no trailing digit run and
therefore groups as its whole stem — which makes eight of bakeoff's forty images
eight singleton groups, so 5 was never reachable. And the numbers ARE
reproducible, just not by one rule: **first-two-segments gives exactly 5 on
bakeoff; first-segment gives exactly 1 on sindra.** The table was assembled from
two different heuristics and written up as one.

⚠ **A cold contract-review panel cannot catch this, and did not.** The panel
reads the artifact; the artifact is internally plausible. Only running the
stated rule against the live data falsifies it. **A measurement inside a
contract is not reviewed by reviewing the contract** — it is reviewed by
re-running it, and that is now a thing to do before implementing any contract
whose scope rests on a number.

## The degeneracy it guarded was the wrong one

INV-3 guarded **one group for everything** ("a rail with one entry cannot
navigate"). The live set's actual failure is the opposite: **one group per
item** — `pewpew-ui-brief` 23 groups for 34 items, `dfa-concepts` 13 for 20. The
contract as written would have shipped a 23-row rail that is a second copy of
the grid. INV-3 now guards both, with a live specimen each:

- **(a)** `sc-iso-spread` — `DSC0001.jpg`–`DSC0006.jpg`, one group of six.
- **(b)** `pewpew-ui-brief` — 23 groups, 19 of them singletons.

The shipped predicate, one line: **two or more groups, and the middle group
holding more than one item.** It gets all 17 booths right.

## The shipped rule, and why it differs

`strip ONE trailing run of digits` keys on the END of the stem, which is where
the *instance number* lives — so it splits `m-c1-market-noon-9401` from
`m-c2-rain-street-9403`, which are the same family. The shipped rule keys on the
**first separator-delimited segment**, where the family lives, destemming only
when the stem has no separator at all (so `ac01` → `ac`, but `v30-seed8302` and
`v35-seed8302` stay apart — that split is the axis `muse-clothed-repro` is
about).

Live result: `sindra-corpus-v1` renders `ac 12 · bu 10 · cu 12 · fb 12 · … ·
wu 8` over 66 images. `sindra-bakeoff` renders `00 · README · m · r`, which are
its three real families.

## Also true, and easy to trip on

**`miranda-is` and `sindra-voice-1` group beautifully and get no rail** — both
carry `index.html`, so they take the verbatim path and have no grid at all. A
measurement taken with `booth_items` alone predicts a rail for them; the route
does not. Measure the RENDERED surface, not the resolver, when the question is
"what will the operator see".