## 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 <workflow> › <stage>" 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.