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.
69 lines
3.5 KiB
Markdown
69 lines
3.5 KiB
Markdown
# 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.
|