Show Planner-launched workflow progress as a run card in Chat

[lavaman131]

Summary

When the atomic-harness Planner runs an Atomic workflow (#213, #215), the people in the document can't see progress. The Planner's turn ends at launch, the run's stages live inside the server, and until the document changes or a Decisions question appears, nothing tells anyone whether the run is alive, what it is doing, or whether it needs them. Terminal users get Atomic's live workflow graph; Chopin has no equivalent.

This proposes an observe-only workflow run card in Chat that extends the existing tool-run pattern.

Who and why

A document member, often not the person who started the run, glances at Chat while a Planner-launched workflow runs for 5 to 60 minutes. They need three answers without leaving the conversation: is it alive, what is it doing now, and does it need me. People own the decisions, so the card never answers, approves, or hides a question; it points to Decisions.

Design

Extend Chat's ToolRun pattern rather than adding a surface: same loader, the chrome and compact type roles, tertiary ink for finished rows, and warning reserved for "waiting on you". The focal point is the single live line under the running stage.

Planner
┌ plan-review · running · 6m ──────────┐
│ ✓ preflight                      0s  │
│ ● draft-1      drafting §3.2     4m  │
│     ↳ mcp update_document · rev 2    │
│ ○ reviewer-a-1 · reviewer-b-1        │
│ ▲ Waiting on 2 Decisions · 24m left  │
└──────────────────────────────────────┘

• Header: workflow name, status (running, waiting on Decisions, done, failed, stopped), and elapsed time.
• Stage rows in materialized order. Parallel siblings share one row. Each row has a status glyph (✓ ● ○ ✕) and a duration.
• One live action under the running stage: the current tool and its target, or the document section being drafted when that is known. Never a transcript.
• Waits row: "Waiting on N Decisions · M left", counted from the question expiry. It links to the exact Decisions cards; each card reads back "asked by › " from the workflowRunId and workflowStageId that HostInput requests already carry.
• Finished: collapses to one line such as "plan-review · planned · 3 revisions · 2 Decisions answered · 18m", with the stage list behind a disclosure, like finished tool runs.

States and ranges

• Starting (stages not known yet).
• Running with 1 to 12 stages and repeated rounds, which fold after 6 rows into "+N earlier".
• Waiting on 1 to 5 Decisions, including expired ones shown as "assumed: recommended option".
• Stalled: no activity for 5 minutes or more, shown in quiet secondary ink with the last-activity time, not an alarm.
• Finished: planned, blocked, failed, or stopped, each with a reason line.
• Server restart mid-run: replayed from the stream cursor and snapshot, and marked "reconnected".
• Several runs in one document: one card each, in start order.

Interaction and layout

• The card is attached to the Planner message that launched the run, in the chat column, and stays readable at the minimum chat pane width.
• aria-live="polite" for status changes and new waits only, not for tool ticks.
• Tool ticks update in place without motion. The finish collapse uses the existing collapse motion contract and respects reduced motion.
• The Decisions link switches to Decisions, focuses the first open card, and scrolls it into view.

Data source

Atomic's workflows extension publishes a typed activity stream: ctx.observeWorkflowActivity delivers a snapshot and then run, stage, tool, and prompt status changes with cursors, plus workflow_lifecycle, workflow_stage_completed, and workflow_heartbeat hooks. The server can subscribe inside the atomic Planner session and relay a durable run summary over the channel WebSocket, stored in the channel sidecar so reloads and restarts keep history.

Out of scope

• Pause, stop, or steer controls. People steer through Decisions and Chat.
• A DAG view or stage transcripts.
• Changes to the Plan document view or Decisions beyond the "asked by" attribution.
• Anti-goals: turning the card into a log viewer, or animating every tool call.

Open decisions

• Stage labels: show the author's stage names verbatim, or a humanized form, which would need an optional display label on workflow stages?
• Stall threshold: a fixed 5 minutes, or derived from the workflow heartbeat interval?

Acceptance

• The Impeccable design check and token checks stay clean.
• A design-audit specimen covers the running, waiting, stalled, and finished states.