# 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.