vh
b46ac02be2
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.
3.5 KiB
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:
- 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.
- Dropping back to an alpha is NOT available.
1.0.0a2sorts BELOW1.0.0b1and 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. - 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.