Add a centralized activity view for background compose calls and subagents

[walker-tx]

Summary

Background compose calls and subagents are displayed primarily where their originating tool call appears in the chat transcript. Once the conversation moves on, discovering what is still running requires scrolling back through the chat log.

Add a single, persistent place to view and manage all background work in the current session, similar to Claude Code's subagent/activity display.

Environment

• Kit: 0.1.99
• OS: Darwin 25.6.0 arm64
• Surface: ACP chat
• Relevant tools: compose(background=true), subagent, background shell/tool work

Current behavior

1. Start a background compose call, optionally containing a subagent.
2. Continue the conversation while it runs.
3. Its in-progress state remains associated with the original tool-call card in the transcript.
4. After enough new messages, the user must scroll back and locate that card to determine what is still running.
5. With multiple concurrent calls, there is no single user-facing summary of active, completed, failed, or canceled background work.

This is especially difficult when a parent background compose call contains a subagent: the user needs to understand both that work exists and whether it is progressing, but the relevant state is spatially separated across older chat entries.

Desired behavior

Provide a persistent session-level Background activity view or panel that aggregates background work regardless of where it was launched. The original transcript card can remain, but it should not be the only practical place to discover status.

Each entry should ideally show:

• concise task/title and type (compose, subagent, shell/tool call);
• status: starting, running, completed, failed, canceled;
• elapsed time and completion time;
• latest bounded progress update or result preview;
• parent/child relationship, such as compose → subagent;
• a link/jump to the originating transcript entry;
• actions supported by the underlying tool, such as cancel/close; and
• clear unread/completion/failure indication.

The panel should remain discoverable while the user scrolls or continues chatting and should distinguish active work from historical completed work.

Suggested interaction model

• A compact persistent indicator shows the number of active background jobs.
• Opening it reveals active jobs first, followed by recent completed/failed jobs.
• Selecting an entry expands bounded progress and offers “jump to message.”
• Parent compose calls can expand to show nested subagents/tool calls without duplicating them as unrelated jobs.
• Completion/failure updates the centralized entry and the original transcript card from the same source of truth.

Acceptance criteria / automated coverage

1. Single background compose: launch one job, continue chatting, and verify it remains visible in the central activity view through running and completed states.
2. Multiple concurrent jobs: launch two independent jobs and verify both appear with independent state transitions and stable identities.
3. Nested subagent: launch background compose containing a subagent; verify the hierarchy is represented without double-counting active top-level work.
4. Failure: force a background provider/tool failure and verify the activity view shows failed state, a safe error summary, and a jump to details.
5. Cancellation: cancel from the activity view and verify both the centralized entry and transcript card transition consistently.
6. Out-of-order completion: complete newer work before older work and verify entries update by identity rather than transcript position.
7. Session cleanup: close completed subagents/jobs and verify active capacity and activity history update correctly.
8. Privacy: previews must obey existing truncation/redaction rules and must not surface hidden prompts, credentials, or provider payloads.
9. Long transcript: add enough messages to move the originating call off-screen; active work must still be discoverable without scrolling back.

Why this matters

Backgrounding is most useful when the user can continue productive conversation. Tying observability primarily to the old launch position makes concurrent work easy to lose and undermines confidence about whether a task is running, stalled, failed, or finished.

No private prompts, credentials, customer data, or provider payloads are included in this report.