vh
bf351a26d1
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.
3.8 KiB
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".