Does the board replace the rail, or sit above it?

They are not two views of one thing. They are two zoom levels of one thing.

That distinction decides it. The board answers which step of the route are we on — four nodes and a gate. The rail answers what is happening inside that step — eight paces, the round counter, the READ–NOTES–REVISE loop marker. Those are different facts at different grain, and neither is redundant.

So “replace” is the wrong verb: A does not remove a duplicate, it nests one inside the other. That is honest — the rail genuinely is the inside of the current node — and at 300px it costs a level of containment on the busiest surface in the product, for no information gained. B keeps the shipped rail exactly as it is and adds the map above it, which is also the cheaper thing to build and the easier thing to reverse.

A is the more elegant idea and I would keep it warm. If the dock ever widens, or if the board moves to the stage, A becomes the better answer — and because both are drawn from the same state, switching later is a layout change, not a rewrite.

There is no second source to drift

The brief is explicit that the board and the rail must never become two systems — same reason the engine is one engine. I did not implement that as a promise. There is one run object {flowId, step, paused}, the board draws it, and the rail is computed from it by deriveRail() — which reads the current step out of the same template and returns the pace, the seat, the loop state and the step count.

So the rail cannot show a pace the board disagrees with, because the rail does not hold a pace — it asks. Both columns on this page are driven by that one object, which is why stepping the run moves them together. A test asserts it: the run is stepped through every position and the two columns are compared at each one.