feat(agent-org): add multi-Run timeline and complete Follow-up UX for #635

[ShiboSheng]

Parent and dependencies

• Parent issue: feat(agent-org): support post-completion chat and follow-up runs #635
• Depends on: feat(agent-org): add post-completion read-only Coordinator turns for #635 #643, feat(agent-org): persist editable Follow-up proposals for #635 #644, and feat(agent-org): launch idempotent recoverable Follow-up Runs for #635 #645
• Delivery order: 5 of 5
• Intended PR: PR 5 — complete multi-Run Conversation UI and release verification

Goal

Expose the complete #635 experience in one long-lived Agent Org Conversation: post-completion chat, editable Follow-up confirmation, truthful Starting/recovery state, bounded Run history selection, and strictly selected-Run operational views.

Locked product decisions

• Delivery uses five sequential PRs.
• Selecting historical Run 1 and asking a question makes the Coordinator answer from Run 1 persisted evidence.
• Selecting Run 1 never reopens Run 1 and never wakes its historical Workers.
• A request for more work while viewing Run 1 creates a proposal continued from Run 1.
• If another Run is Starting, Running, or Paused, the proposal may remain pending but cannot start.
• Proposal edits happen inline in the same durable card.
• Follow-up launch always requires explicit confirmation.
• Starting recovery uses bounded automatic attempts plus manual Retry.
• The first release includes the complete banner, card, Starting states, timeline, selector, and selected-Run scoping.

Required UI behavior

• Keep the Conversation input enabled after Completed, Failed, Cancelled, or Abandoned; only archived Conversation state makes it read-only.
• Show the neutral message: This work round is complete. Ask a question or start follow-up work.
• Add a bounded Run timeline/selector such as Run 1 Completed through Run 10 Running, with lineage labels such as Run 11 continued from Run 1.
• Selecting a Run scopes Tasks, Plan, Worker results, Inbox history, Kanban, Monitor, and final output to that exact Run. Never merge ids or projections across Runs.
• Historical views are visibly read-only.
• When a historical member is mentioned, label that the Coordinator answered from persisted results.
• Render the durable Follow-up card with source Run, goal, requirements, optional task outline, resource warning, inline edit, dismiss, and explicit Start action.
• Support pending, editing, revision conflict, Starting, started, launch-incomplete, recovering, live-Run conflict, stale, archived, deleted-source, dismissed, and accepted states.
• Disable duplicate Start clicks while preserving idempotent backend retries.
• After launch, keep the original card in Conversation history and provide 查看 Run N.
• Restore transcript, latest proposal revision, selected Run, live Run, and lineage after refresh or app restart.
• If the stored selection no longer exists, select the one live Run; otherwise select the newest historical Run.

Performance requirements

• Use one shared Conversation/Run store with push invalidation and a slow recovery read; no poller per Run card, member, or panel.
• Do not poll terminal historical Runs.
• Pause refresh while the document is hidden and evict unused detail caches.
• Timeline, proposals, Inbox, transcript, and outputs use keyset pagination or explicit row/byte bounds.
• Load full TaskOutput, Plan, artifact, and older history only on demand.
• No background model or Worker work is introduced by merely opening a historical Run.

Acceptance criteria

• Users can message after all four terminal Run statuses.
• Questions and Coordinator answers remain in one Conversation transcript.
• Selecting Run 1 scopes every operational panel to Run 1 and does not disturb active Run 10.
• Requesting work from Run 1 creates a proposal clearly based on Run 1.
• When Run 10 is live, that proposal cannot start and explains why.
• After Run 10 is terminal, confirming can create the next Run from Run 1 without merging Runs 2–10 automatically.
• Inline proposal edit, dismiss, duplicate click, Starting, recovery, conflict, stale, and accepted UI states match durable backend state.
• Refresh and restart restore the same transcript, proposal, selected Run, active Run, and lineage.
• Tasks, Plan, Inbox, Kanban, Monitor, Worker results, and final output never merge across Runs.
• Hidden and terminal views add no persistent polling, Worker Wake, or model work.
• Light/dark theme and constrained viewport layouts are usable and accessible.

Verification and handoff

• Extend the production rendered WebDriver Agent Org spec, using debug helpers only for seeding and inspection.
• Cover question, historical mention, proposal edit, conflict, concurrent confirm, Starting, recovery, Run switch, refresh, restart, and completion user paths.
• Assert final UI outcomes and durable DB invariants, including absence of generic hidden tool-error cards.
• Add frontend store/component tests for selection, stale response guards, cache bounds, visibility pause, and unmount eviction.
• Run typecheck, scoped lint, circular dependency check, Rust/database suites, production HTTP E2E, rendered WDIO E2E, formatting, and scoped Clippy.
• Capture screenshots or recordings for relevant themes, viewport constraints, loading, terminal, conflict, Starting, failed/recovery, empty, and accepted states.
• Run frontend UI audit, architecture audit, E2E methodology review, and Agent Org performance guard.
• Complete Fast Build, real app manual verification, and Command+5 observation before marking ready.
• Keep the PR Draft until automated and manual acceptance criteria are complete.

Out of scope

• Multiple simultaneous live Runs in one Conversation.
• Automatic launch without confirmation.
• Reopening terminal Runs or reusing old Workers.
• Revision Events from feat(agent-org): add ordered revision events and incremental run sync #634.

Estimated change size

• Roughly 12–18 files.
• Roughly 900–1,500 changed lines including component tests and rendered E2E.
• Across all five child issues, expect roughly 40–60 unique files and 4,100–6,900 changed lines; re-estimate after feat(agent-org): add exact multi-run session ownership for #635 #642 and feat(agent-org): launch idempotent recoverable Follow-up Runs for #635 #645 reveal the final migration and launch boundaries.