docs(roadmap): r3 landed — the compare ring and stepping rules, compare mode off the parking lot

The stale v1.1 line for compare pairing is corrected to the 2026-09-24
ruling (pairs are picked, never detected). persistent-memory records r3
live and unpushed, and the open race note for design-dev.
This commit is contained in:
vh
2026-09-24 15:57:42 -07:00
parent f8d136a521
commit cf08ae3f33
2 changed files with 25 additions and 16 deletions
+5 -2
View File
@@ -119,6 +119,8 @@ Where it already binds, and what the rule is in each case:
| embed anchors in a verbatim report | **document order** — what `querySelectorAll` yields, so the author's markup decides (U3) |
| the embed tail (fragments the author did not place) | **payload order**, which is the marks order `(created, id)` — one rule, whether a fragment lands at an anchor or at the end (U3) |
| questions within a pick | declaration order, in the payload's `questions` LIST — carried by the format rather than by object-key insertion order (U3) |
| the compare filmstrip | **the compare ring**: the review ring (item order, media only) less any rel compare cannot open, so no strip link offers a pair that 404s (r3) |
| compare stepping | along the compare ring, modulo its length; linked moves both sides one place and keeps their distance, unlinked moves the active side only (r3) |
U3's three rows are the first case where the rule binds across a language
boundary: the order is decided in Python and honoured in JavaScript, and a
@@ -140,7 +142,8 @@ gallery booths have a subdirectory.
(section ordering among themselves, compare pairing) resolved differently:
section ordering is MOOT, because U7 renders no section rail — `Item.section`
still exists and is still derived, it simply has no ordered surface. Compare
pairing rode into v1.1 with compare mode itself. **U6's bench listing is
pairing was ruled 2026-09-24: pairs are PICKED, never detected from filenames,
and compare landed with r3 (rows above). **U6's bench listing is
settled** — the row above.
The test for any new ordered surface: *can you write the rule down in one line?*
@@ -162,7 +165,7 @@ weighed against the v1 path and lost on purpose.
| item | why parked |
|---|---|
| ~~**Compare mode**~~ — **UNPARKED 2026-09-23, IN THIS ARC** | Parked as "the only new capability rather than a fix for a measured defect", and **that deferral was ours and the operator overruled it.** design-dev argued it belongs in this arc because the ladders and bakeoffs already need it; the operator ruled `this_arc`. Lands AFTER the Desk and the reel, as a view toggle over the same item record. Recorded so nobody re-parks it by reading an older rule. |
| ~~**Compare mode**~~ — **UNPARKED 2026-09-23, LANDED 2026-09-24 (r3)** | Parked as "the only new capability rather than a fix for a measured defect", and **that deferral was ours and the operator overruled it.** design-dev argued it belongs in this arc because the ladders and bakeoffs already need it; the operator ruled `this_arc`. Lands AFTER the Desk and the reel, as a view toggle over the same item record. Recorded so nobody re-parks it by reading an older rule. |
| Virtualized / progressive grid loading | Speculative. 270 `<img loading="lazy">` may be fine. **Measure the real booth before optimising it** — if it renders inside a second, this is invented work. |
| Bench uptime history + graphs | The v1 need is "is it dead", which one flag answers. A time series is a different product. |
| Cross-booth search | No evidence of the need in the usage data. |