What happens
Open /live/view on a completed trace and the graph appears fully green, instantly. The trace holds a per-node start/end pair with real timestamps — the whole execution story — but the page only renders the final state. The running (amber) styling exists and works during a live run; for a finished run it is unreachable.
Concretely: any run whose nodes finish between two SSE polls (sub-second demo nodes, cached tools) never shows a single amber frame even live, and every run loses its animation the moment it completes. Demoing the runtime's best visual — nodes lighting amber then green, parallel branches running together — currently requires artificially slowing node bodies down, which is what we had to do to film it.
Why it matters
The amber-to-green sweep is the single most legible artifact the runtime produces — it shows ordering, parallelism, and where time went, with zero explanation needed. Locking it to wall-clock-slow live runs means the people who most need it (someone opening yesterday's incident trace) never see it.
What to consider
/live/view?trace=…&replay=1: walk the recorded events in timestamp order and emit the same SSE snapshots a live run would have produced, at recorded speed (with a speed= multiplier, and perhaps a cap so a 40-minute run replays in 40 seconds).- The server already has everything needed:
read_events gives ordered timestamped events; the mermaid class assignment already distinguishes running/done per node.
- Keep the default (no param) behaviour exactly as-is.
Acceptance criteria
Replaying a finished multi-node trace shows each node amber during its recorded window and green after, honours a speed multiplier, and a trace replayed twice renders identically.
What happens
Open
/live/viewon a completed trace and the graph appears fully green, instantly. The trace holds a per-nodestart/endpair with real timestamps — the whole execution story — but the page only renders the final state. Therunning(amber) styling exists and works during a live run; for a finished run it is unreachable.Concretely: any run whose nodes finish between two SSE polls (sub-second demo nodes, cached tools) never shows a single amber frame even live, and every run loses its animation the moment it completes. Demoing the runtime's best visual — nodes lighting amber then green, parallel branches running together — currently requires artificially slowing node bodies down, which is what we had to do to film it.
Why it matters
The amber-to-green sweep is the single most legible artifact the runtime produces — it shows ordering, parallelism, and where time went, with zero explanation needed. Locking it to wall-clock-slow live runs means the people who most need it (someone opening yesterday's incident trace) never see it.
What to consider
/live/view?trace=…&replay=1: walk the recorded events in timestamp order and emit the same SSE snapshots a live run would have produced, at recorded speed (with aspeed=multiplier, and perhaps a cap so a 40-minute run replays in 40 seconds).read_eventsgives ordered timestamped events; the mermaid class assignment already distinguishes running/done per node.Acceptance criteria
Replaying a finished multi-node trace shows each node amber during its recorded window and green after, honours a speed multiplier, and a trace replayed twice renders identically.