feat(u7): filename groups — the last v1 unit, and a table that did not reproduce

Completes U7 with its fourth component: a jump-to-group rail derived from
filename prefixes, replacing the subfolder sections ROADMAP named. The scope
departure was ratified by the operator 2026-09-22; this commit deletes
test_no_group_rail_is_shipped_yet, the guard that held it back, in the same
change that builds what it guarded against.

All seven v1 capabilities are now landed. The 1.0 cut is a decision, not a
dependency, and it is the operator's — no version bump here, because a commit
is not a release.

THE RULE CHANGED AT IMPLEMENTATION, ON MEASURED GROUNDS. The contract specified
`strip ONE trailing run of digits`; run against the live set that yields 24
groups for sindra-bakeoff's 40 images and 27 for sindra's 30 — a rail with a row
per tile — because it keys on the END of the stem, where the instance number
lives. The contract's own table claimed 5 and 1 for those two booths and neither
reproduces; the numbers are reachable only by two OTHER heuristics, so the table
that justified the design was assembled from more than one rule. Its own worked
example contradicts it in plain sight.

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`
while `v30-seed8302` and `v35-seed8302` stay apart. Re-measured across all 17
live booths; the table is in the contract.

INV-3 GAINED ITS SECOND DEGENERACY. The contract guarded one group for
everything (sc-iso-spread: DSC0001-DSC0006). The live set's actual failure is
the opposite — pewpew-ui-brief yields 23 groups for 34 items, dfa-concepts 13
for 20 — and the contract as written would have shipped a rail that is a second
copy of the grid. The rail now renders only when grouping is informative: two or
more groups, and the middle group holding more than one item. That predicate
gets all 17 booths right.

Grouping is a VIEW. The grid stays sorted(rel) and the zoom ring stays that
order filtered to images; the group fixture interleaves across subdirectories
precisely so a (group, rel) re-sort goes red. Groups are derived from the
RENDERED list, not the full gallery, so no anchor points at a filtered-out tile.

booth/items.py       _group_of + Item.group, derived in the resolver (INV-1)
booth/app.py         _groups() builds the rail rows; build_gallery carries it
booth/templates/     the rail-groups nav and its CSS
tests/               +16 tests; 639 green

Every new falsifier was proved by running its defeating change (12/12). Three
were vacuous first time out: one fixture's positional order happened to be
alphabetical, one assertion miscounted elements, and the harness itself
certified a broken test twice — no green baseline, and byte-identical mutations
silently defeated by the pyc cache's one-second mtime granularity.

persistent-memory.d/2026-09-22-a-mutation-harness-that-certified-a-broken-test.md

@@ -0,0 +1,50 @@
+# A mutation harness that certified a broken test, twice, for two reasons
+
+_2026-09-22 · booth_
+
+This repo already knows that **an assertion which has never seen its own
+defeating change is not known to falsify anything** — two prior entries say so
+([[2026-09-22-vacuous-falsifiers]], [[2026-09-22-seven-of-seven-falsifiers]]).
+So U7's groups were built with a harness that applies each defeating change and
+asserts the named test goes red. **The harness itself had two defects, and both
+produce the same lie: a falsifier certified without being run.**
+
+## Defect 1 — no green baseline
+
+A test that is **already red** reports RED for every mutation thrown at it. The
+escaping test had an arithmetic slip (counted `<` against `<a`/`<nav`/`</` and
+forgot the two `<b>` elements), so it was failing for a reason unrelated to
+escaping — and the harness cheerfully reported `RED ✓ the rail markup is emitted
+with |safe`. **Run the test unmutated first; a non-zero baseline is a harness
+failure, not a proven falsifier.**
+
+## Defect 2 — the bytecode cache, which is the subtle one
+
+`if len(sizes) < 2` → `if len(sizes) < 1` is **byte-identical in size**. CPython
+validates a `.pyc` against the source's `(mtime, size)` at **one-second
+granularity** — so a mutation that lands in the same second as the revert before
+it is invisible, the cached bytecode is reused, and **the harness runs the
+unmutated code and reports the falsifier proven.**
+
+The tell was non-determinism with no cause: INV-3a certified RED on one run and
+GREEN on the next with neither the test nor the code changing, and reproduced by
+hand every time. Fix: delete `__pycache__` and set `PYTHONDONTWRITEBYTECODE=1`
+in the subprocess environment before every run.
+
+⚠ **This bites any same-size source mutation**, which is most interesting ones:
+comparison flips, off-by-one constants, `and`↔`or`, `<`↔`>`. A mutation harness
+without cache defeat is biased toward exactly the mutations most worth running.
+
+## Result
+
+12 falsifiers, 12 proved, stable across consecutive runs. Two of them only
+after these fixes — and one of the twelve (`test_group_order_is_the_position_of
+_the_first_member`) was genuinely vacuous on the first pass: its `w, x, y`
+fixture's positional order **happened to be alphabetical**, so it stayed green
+under the alphabetical-sort mutation it forbade. Rebuilt so all three plausible
+rules (position, alphabetical, count) disagree.
+
+**The harness lives in the session scratchpad and dies with the session.**
+Whether it becomes `scripts/` is an open question for the operator — this repo
+has now been bitten by vacuous falsifiers three times, and prose in a memory
+file is not an instrument.

persistent-memory.d/2026-09-22-u7-landed-and-a-table-that-did-not-reproduce.md

@@ -0,0 +1,77 @@
+# 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".