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:
+5
-2
@@ -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. |
|
||||
|
||||
Reference in New Issue
Block a user