Release strip → active release flowchart → its table

Zone 2 answers one question — what is being worked, and what is next. It is not an inventory: zone 3’s table below already holds the detailed list of all 28. So the 21 merged CRs collapse into a single 21 merged ✓ summary row, exactly as this design already did, and the rows beneath are the top of the scheduled queue. No paging machinery — no ◀ earlier tag, because nothing to the left is hidden (it is summarised), and no pager for the remainder, because the table is the detail surface. +2 more is a static POINTER, not a control. The header count 28 and the roll-up 21 merged always state the WHOLE wave, so a trimmed view can never misreport the true size.

Why the spine is horizontal: measured on the live board, an UNCAPPED grid of all 28 CRs makes the wave box 1082 × 150, so a horizontal spine would need 1378px against the 1130px the roadmap actually has — it cannot fit, which is why the shipped build stacks vertically and drops its connectors. One CR per row, merged collapsed to the summary and only the scheduled top shown puts the box at ~300px and the budget at ~600px: the spine fits comfortably. The layout and the trim are ONE decision, not two.

Scope: zone 2 draws every wave of the FOCUSED release — one box per wave, not one box ever. Crucible shows a single Wave 5 box only because 0.2.0 spans exactly one wave; 0.1.0 spanned waves 1–4. A multi-wave ACTIVE release is therefore the case that widens this zone, and the spine budget below must be read per wave box.

Activation is a GUARANTEE, not a coincidence: the active CR is always present even when it sits outside the scheduled top, because an orchestrator may activate out of authored order. Motion stays reserved for IN_PROGRESS (§5, CR-078 AC24) — next above carries NO glyph and NO colour of its own — ▸ and ember are reserved for IN_PROGRESS, and “next” is a scheduling fact, not a state, so it is written as plain bold TEXT on a PENDING row. The two never read alike, and neither relies on colour.

Amended 2026-09-03 (user ruling). This design originally drew the active row as ▸ active · C1 RED — a cycle overlay inside the zone 2 row. It was dropped during CR-CRU-096 and the drop is accepted: the design now matches what ships, ▸ active alone. The cycle is not lost — it rides zone 3's own cycle column (below, 6/6), which is the DN's division this design already states: structure in the picture, detail in the rows. Zone 2 answers what is being worked and what is next; which cycle it is in is detail.

20 rows, not 88. Row grammar is the DN's, with one amendment: CR id + brief title + bare depends-on + status + cycle overlay. The DN forbade titles on graph nodes, which still holds — the flowchart labels carry no title. The table is where the title belongs, which is the DN's own division: structure in the picture, detail in the rows. The highlighted row is the CR selected in the flowchart; clicking a row drills to that CR's cycles in Workflow.

No wave boxes here, deliberately: the Workflow history view is enough for historical waves, so the roadmap does not duplicate it. The table keeps a wave column because this release spans four.

0.1.1 genuinely carries crs: [] with two packages — a packaging fix. Its table is empty with the same message. Not hidden, not back-filled.

The table gains a track column in this case. Crucible is single-track, so neither lanes nor that column appear — correct, not a gap. Two CRs are concurrent because they sit in different lanes; no fan-out edges needed to say so.

Two independent channels, so neither has to carry the other's meaning: shape is the kind of thing, colour is its state.

Colour never encodes anything shape already says, and no element relies on colour alone — status is also written as text, so the view survives a colour-blind reader and a greyscale screenshot.

No row reads "whatever the layout chose". Nothing here needs a layout engine, a crossing heuristic, or a compound-graph library.

Your model: a release is a super container. When a CR is planned it is the orchestrator's job to state which release it targets and which wave it belongs to; once a wave's sequence is decided, the orchestrator sends that ordered sequence of CRs with its metadata. So all three levels are declared data — nothing about the roadmap is inferred by the renderer.

This overrides my recommendation — I argued for deriving membership from the queue's release qualifier, and you are right that declaring it is correct. Checking the code before writing this section proved my suggestion was not merely weaker but impossible, which is the second finding below.

You left this to me, then gave me five constraints. The one that reshapes it most: the roadmap is built during the design phase, as each CR is authored — not snapshotted at the end. So the API is incremental and declarative, and the client's job is to ask the orchestrator for what it is missing rather than accept a half-planned CR or fail blankly.

Step 3 is one call, and that is the load-bearing decision. The order is the payload. Sending CRs one at a time makes their sequence an accident of arrival — exactly the CR-CRU-077 AC2 defect you already paid +41% crossings for, where authored order was not carried as data so the layout substituted its own. It also lands the field the app already reads: data.seq, shipped in CR-077 C2 as "numeric, distinct, strictly increasing in authored order".

Your requirement 2. A cr-plan missing its targeting must not be accepted, and must not fail with "missing argument". It answers with the live candidates, so the orchestrator never guesses or remembers:

$ python3 clients/python-crucible.py cr-plan --cr CR-CRU-092 --title "…"
cr-plan: ok=false needs=[release, wave]                       # exit 2 — usage, principle 6
releases[2]{label,status,waves}:                              # ambient context, principle 7
  0.2.0,proposed,"4,5"
  0.3.0,proposed,"—"
help[2]:                                                      # next-step templates, principle 9
  cr-plan --cr CR-CRU-092 --release 0.2.0 --wave 5 --title "…"
  release-propose --label 0.3.1        # if it targets a release that does not exist yet

It never guesses, even when only one wave is open — silent inference is the whole failure class this design removes. When no release is proposed at all, principle 5 applies: a definitive empty state that says propose one first, with the template to do it.

All three new verbs land in the shared parser clients/_crucible_axi.py so all five clients get them at once — the CR-CRU-054 DRY rule. Worth flagging: queue-file is in 1 of 5 clients today, python only, and roadmap registration is stack-agnostic orchestrator work — that is already a correctness gap, and these verbs must not repeat it.

Your requirements 3 and 4. An initial roadmap is a draft: gap analysis kills some CRs, new ones arrive, and the queue gets reordered. Two rules make that safe.

Distinguishing them is not pedantry: a superseded CR's dependants are still satisfied — by its successor — while a voided CR's dependants are now broken and must be surfaced. Collapsing both into "removed" is what makes a dependency silently rot. Neither may touch a CR that has already shipped inside a cut release: that membership is settled fact.

Your rule: dependsOn is a cue and a validation input, and the orchestrator is ultimately responsible for the sequence. That is not a new policy here — it is already law in the server: src/v2.ts:1759 says an unresolvable dependency is "flagged in unknownDependencies, never rejected", and queue-file already returns that array today. So the design extends an existing rule instead of introducing a competing one.

The consistent line: Crucible never substitutes an order of its own. That is the same commitment CR-CRU-077 AC2 makes about the render layer — authored order wins over the layout's preference — applied to the write path. A tool that silently re-sorts is a tool the orchestrator has to fight.

Your requirement. During execution the orchestrator asks Crucible what it should pick up, and that answer validates the declared sequence against live state. There is no next verb in the client fleet today — I checked all five — but the orchestrator already thinks in this vocabulary, so the verb adopts it rather than inventing one.

$ python3 clients/python-crucible.py next --track 2
next: ok=true decision=NEXT track=2
cr=CR-CRU-079 release=0.2.0 wave=5 seq=20
help[1]:
  plan-file --cr CR-CRU-079 --title "…" --cycles "…" --wave 5

$ python3 clients/python-crucible.py next            # multi-track project, no --track
next: ok=false needs=[track]  tracks=[1,2]           # exit 2 — never picks a lane for you

Single-track projects omit it — Crucible itself is single-track, so next takes no argument here and the flag would be noise. It becomes required the moment more than one track is reported, which is the same conditional-chrome rule the swimlanes follow (§7): the interface grows only when the data justifies it. Track assignment comes from the metadata that rode in with wave-sequence (§10 step 3), so nothing new has to be declared.

Your last issue, and I measured it in the running app rather than guess. The release strip is the one zone that grows without bound — a project that ships monthly adds a diamond a month forever — and it does not get the whole window: the project rail on the right takes 434 of 1576px, 27.5%, leaving the roadmap 1130px.

So Crucible's five gates fit now, and stop fitting at the seventh — well inside 0.3.x. Both fixes are needed: paging because growth is unbounded, and the collapse because 27.5% is a lot to spend on a rail while reading a timeline.

What this deleted, which is the point: no scroll container, no edge fades, no scroll-position state, and no drag affordance to teach. It also removed a defect class outright — I had to fix the scroll container slicing the diamonds' top and bottom vertices (a scroll container clips on both axes, and a rotated square hangs ~18px past its layout box). With paging, that bug cannot exist. Fewer moving parts and a stronger guarantee.

What the sliver costs, stated plainly: a 0px pane would have given 1.398×; the 34px sliver gives 1.351×. You buy back ~3.4% of body width in exchange for the re-open control living where the thing it controls lives — and for never having to answer "where did my rail go". AC11 becomes falsifiable again because of this choice: at 1024×640 the sliver takes real width, so "no pane child is squeezed below the 660px floor" is now a test that can fail, where against a 0px pane it could not. The remaining amendment is AC12's carve-out: the strip's window legitimately moves 1→5 here (6→9 on the design's 1600px figures), and tests/roadmap-release-strip.test.ts:945 already asserts exactly that under the name "the rail-collapse case (CR-093)".