docs: the four flow rulings, compare unparked, and the beta premise superseded

All four ruled, all four taking design-dev's recommendation, relayed via Miranda
with booth-dev as sole relay. Verbatim copy committed at docs/rulings/ because
the booth holding it will sweep.

Which is the observation worth keeping: answering a pick removes the hold that
was protecting the record. A booth is held while its question is OPEN, so its
lifetime is shortest exactly when it has just become valuable — before the
answer it is a question, after it is the record of a decision, and only the
first state is protected. Both design booths hit this by different routes, one
withdrawn and one answered. Raised to design-dev as a flow question rather than
patched, since flow is his now.

Compare mode leaves the parking lot: our deferral, his overrule, recorded as his
call so nobody re-parks it by reading the older rule.

And v1.0.0b1's 'no new features' promise no longer describes the arc. The tag
stays as written — rewriting a released tag to flatter the present is how a
version stops being evidence — an alpha drop-back is illegal because 1.0.0a2
sorts below 1.0.0b1, and no further pre-release is cut until the arc lands.

persistent-memory.d/2026-09-23-the-flow-rulings-and-what-they-cost-the-beta.md

@@ -0,0 +1,68 @@
+# The flow rulings, and what they cost the beta
+
+_2026-09-23 · booth_
+
+**All four ruled, all four taking design-dev's recommendation, no notes
+attached.** Relayed via Miranda (D-0016) with the instruction that **the
+operator will not brief design-dev directly and booth-dev is the SOLE RELAY.**
+
+| question | choice | label |
+|---|---|---|
+| `direction` | `a_b` | A + B's reel as the review mode |
+| `compare` | `this_arc` | Build it in this arc, after A/B land |
+| `voice` | `plain` | Plain and direct |
+| `emblem` | `no` | No |
+
+Answered `2026-09-23T08:07:40-07:00`, `complete: true`, `unanswered: []`.
+**Verbatim copy committed at `docs/rulings/2026-09-23-flow-direction.json`** —
+see the durability note below for why that is not belt-and-braces.
+
+## ⚠ ANSWERING A PICK REMOVES THE HOLD THAT WAS PROTECTING THE RECORD
+
+U4's hold predicate is "has an open pick" — a booth waiting on the operator does
+not sweep. **The moment he answers, it stops being held**, so a booth's
+lifetime is shortest exactly when it has just become valuable: before the answer
+it is a question, after the answer it is the RECORD OF A DECISION, and only the
+first state is protected.
+
+`booth-flow-concepts` held the ratified design AND the operator's recorded
+answer, with `.forever=NO` and zero open picks — sweep-eligible within minutes
+of the ruling. Same shape as round 1, arriving by a different route:
+`booth-svos-retheme` lost its hold when design-dev WITHDREW his ask; this one
+lost it when the operator ANSWERED. Two different actions, one exposure.
+
+The durable copy now lives in git rather than in a booth. **This is not a bug
+report against U4** — an answered question genuinely is not waiting on anyone —
+but it is a real question about whether "held" is the right predicate for a
+booth that has become a record. Flow and requirements are design-dev's now, so
+it is his to weigh; raised to him rather than patched by us.
+
+## What the rulings cost the version
+
+**`v1.0.0b1` promised "feature-complete, no new features, the remaining work is
+bugs."** A flow redesign plus compare mode is not that. Three things follow:
+
+1. **The tag stays exactly as written.** It records what was believed on
+   2026-09-22, not a claim about today. Rewriting a released tag to flatter the
+   present is how a version stops being evidence.
+2. **Dropping back to an alpha is NOT available.** `1.0.0a2` sorts BELOW
+   `1.0.0b1` and versions do not go backwards. The policy's "if you are adding
+   features to a release candidate, it was never a release candidate" advice has
+   no legal expression here.
+3. **No further pre-release until the arc lands.** Commits accumulate; the next
+   tag is whatever is honest when there is something to release.
+
+**Whether `1.0.0` waits for the redesign is the operator's and is NOT YET
+MADE.** Our recommendation is that it does: he treats this as one arc (the
+standing no-announcements ruling says "until the entire arc is done"), and
+cutting the 1.0 milestone on a UI he rejected as "still looks like the booth"
+would make the milestone mean something he does not endorse.
+
+## Compare mode left the parking lot, and the deferral was OURS
+
+Parked since the v1 gate as "the only new capability rather than a fix for a
+measured defect." design-dev argued it belongs in this arc; the operator agreed.
+ROADMAP records **that it was his call that moved it**, so nobody re-parks it by
+reading the older rule. Practically: the item-record work compare needs is in
+scope for us, not deferred, and he tells us what a compare view wants from
+`booth_items` rather than working around the current shape.