A graph of what is running

[VeryComplexAndLongName]

A Pipeline tab: every active change in the order it declares, what is running right now and whose run it is, and what can be started alongside what.

Sequential work is not a separate thing to draw — a chain of changes each blocked by the previous is a graph one lane wide, and independent changes are lanes side by side. One drawing covers both.

The three decisions, and why (ADR 0025)

The picture is derived in core, coordinates and all. layoutChanges returns each node's position and size and each edge's path, in abstract units. Nothing in the view is measured: one unit is one rem for both the cards and the SVG, so they line up without either being asked where the other ended up.

The alternative was to lay the nodes out with CSS and measure them — getBoundingClientRect per node, a ResizeObserver, a re-run after every layout pass and after fonts settle. That was the only part of this view holding state derived from a moment of rendering, the only part not checkable without a browser, and the only part with a failure mode that looks fine: an edge positioned from stale geometry is a line pointing at nothing. Edge routing is now checked by the same unit tests as the ordering.

A rem and not an em, for two reasons that both bite: a custom property holds a token rather than a computed length, so 1em would resolve against the font size of whichever element used it; and the shell fixes body at 14px, so an em would not follow the reader's browser font setting at all.

A collision is not an edge. blocked_by is an order and an arrow means exactly that. Two changes that would meet in one spec file have no precedence between them — either may go first — and a line would assert a sequence the repository does not contain. A reader would believe it, because it would look like every other line in the drawing. So a collision is stated in words on the card it affects, in the same wording openspec-ui-cli ready already uses.

No graph library. What one would contribute is the part this puts in core; what it would cost is the part that matters. A card is a <button>, already focusable and already named, which a canvas or an SVG-only drawing would each need given by hand — and this shell is held to WCAG AA by a browser suite that runs axe on every screen. The SVG carries only edges and is aria-hidden: what a line draws is already on the card it points from.

Also

• A cycle of declared blockers is named rather than placed, and so is anything waiting on one. A cycle has no depth, and there is no column one past nowhere; a picture that quietly put one somewhere would be a wrong answer that looks like a right one.
• Below 720px the picture becomes headed lanes. Four columns of cards do not fit a phone in any implementation, and shrinking until it is technically present and practically unreadable is the worse answer. Nothing is lost — that wording is what the edges illustrate.
• ChangeReadiness gains the blockers it declares (kept to those still active); the report carried them only for blocked changes, so the picture would have lost the relations of a running one.
• The report's shape and the words a collision is described in moved to a browser-safe leaf, so both surfaces describe one fact identically.
• The bridge operation for the VS Code embed was dropped deliberately, and recorded as dropped rather than quietly skipped: the embed shows one tab (ALLOWED_TABS_VSCODE_EMBED), so it would have been an operation nothing could call.

Verification

npm run verify unpiped with everything staged: typecheck, lint and test all passed — cli 107, core 1092, extension 327, server 83, webui 389; 1998 in all.

The whole browser suite, 16 of 16, including this tab's axe run at WCAG AA and a phone-width check that the page body never scrolls sideways. The two harness screenshots regenerated with it: the tab strip they show now carries this tab, so leaving them would have documented a screen that had stopped existing.

One task stays open — 6.5, delegated to claude-cli: with two changes actually running in their own working directories, check that each card names the right author and the right state. The unit tests drive the view with a written report; only real runs show that the report a live workspace produces is the one the picture draws.

🤖 Generated with Claude Code