feat(tui): keep /tasks Preview Output fresh and surface load errors

[ayu-exorcist]

What feature would you like to see?

Make the /tasks Preview Output panel refreshable and trustworthy for the currently selected task.

Today the panel fetches getBackgroundTaskOutput(taskId, { tail: 4000 }) once when a task is selected. If the task is still running at that moment, the preview remains empty even when output arrives later or a subagent successfully completes. R refreshes task metadata but does not retry the selected task's output request. In addition, a rejected output request is rendered as the same [no output captured] state as a genuinely silent task.

This makes a long-running task difficult to distinguish from a stuck task, and can leave a completed task looking empty until the user changes selection or reopens /tasks.

Suggested behavior:

• Refresh the selected task's preview when its task metadata or output changes, while avoiding unnecessary repaint/request churn.
• At minimum, make R retry the selected preview and refresh it once the selected task reaches a terminal state.
• Show a distinct, actionable error state when preview retrieval fails (for example, Cannot load preview: … plus a retry hint) rather than reporting [no output captured].
• Preserve the existing tail limit, selection/request-id race protection, and full-output viewer behavior.

Additional information

This is complementary to #667 and its open implementation PR #2130, which add live subagent events to the background task output buffer. Even after that output exists, the /tasks preview needs to re-fetch or subscribe to it; otherwise an initial empty fetch can remain stale for the lifetime of the browser dialog.

Relevant current paths:

• apps/kimi-code/src/tui/controllers/tasks-browser.ts: loadTail() fetches once on selection; its rejection path assigns an empty preview.
• apps/kimi-code/src/tui/components/dialogs/tasks-browser.ts: an empty tail is rendered as [no output captured].

Suggested acceptance criteria:

1. Select a running background agent whose output is initially empty, wait for it to succeed, and observe its final result without changing selection or reopening /tasks.
2. A running process task's recent stdout/stderr becomes visible in the selected preview after output arrives.
3. A failed preview fetch is visibly distinguishable from a task that emitted no output and can be retried.
4. Existing stale-response protection continues to prevent an older selected task's result from overwriting the active selection.

[ayu-exorcist]

Follow-up: make task progress observable without inventing a percentage

Refreshing Preview Output is necessary, but the useful goal is broader than showing more text: users need to tell whether a running background task is still making progress.

A task should not derive a numeric completion percentage from elapsed time. Subagent reasoning, tool latency, retries, and long-running commands are too variable for time-based percentages to be trustworthy.

When the task can provide them, the /tasks panel should instead surface these progress signals:

• Status: lifecycle state (running, completed, failed, etc.).
• Activity freshness: when the latest output/progress event arrived, so an active task is distinguishable from a silent or stalled one.
• Current phase: a concise state such as searching, reading files, running tests, waiting for a subprocess, or finalizing.
• Recent event/output tail: the existing Preview Output area, kept fresh while the selected task runs.
• Optional measured progress: completed/total work units only when the task genuinely knows them (for example, 18 / 42 files inspected).

A possible compact rendering:

Status: running · 42m
Activity: 8s ago
Phase: Running focused tests
Recent event: pnpm test packages/agent-core/...

The live subagent-event stream proposed in #667 / PR #2130 can provide the activity and phase signals. This issue should ensure the TUI consumes them safely: refresh the selected preview, preserve the tail limit and stale-response guard, and show an explicit retrieval error rather than treating it as an idle task with no output.

[ayu-exorcist]

Follow-up: unify activity/progress semantics across the main agent, subagents, and /tasks

The current UI exposes related work through several surfaces with different semantics:

• The main agent has qualitative phases/spinners, tool cards, Todo state, and plan state, but no common task-progress model.
• Ordinary subagent cards expose lifecycle/count/activity information; AgentSwarm additionally has a heuristic visual-progress bar.
• Background /tasks exposes lifecycle metadata and a Preview Output tail, but today its output can become stale and retrieval errors are indistinguishable from no output.

These surfaces should share a consistent activity/progress vocabulary so users do not have to reinterpret each view.

Proposed common model

Every active unit of work, where the data exists, should expose the same ordered signals:

1. Lifecycle status — running, completed, failed, timed out, killed, etc.
2. Activity freshness — when its latest observable event arrived.
3. Current phase — concise, human-readable work state (for example: thinking, searching, running tests, waiting for a subprocess, finalizing).
4. Recent event/output — an inspectable tail with clear loading, empty, and error states.
5. Measured progress — completed / total only where a real work-unit total exists; never infer a percentage merely from elapsed time.

A compact view can omit lower-priority fields, while a detail view can expand them. The meanings should stay identical across the main activity pane, Agent/AgentSwarm cards, and /tasks.

Interaction expectations

• Selecting a running unit should show its latest available state and continue to update while it remains selected.
• A refresh action should refresh both metadata and the selected unit's activity/output, and visibly report retrieval failure.
• Terminal transitions should immediately update the common status and retain the useful final result/failure context.
• Existing per-view features can remain: Todo/Plan are especially useful for the main agent; child counts remain useful for groups; AgentSwarm may retain its explicitly heuristic bar. None of these should be presented as an authoritative percentage unless backed by measured work units.

#667 and PR #2130 provide an important event source for subagents. This issue can define the TUI-side consistency contract so that the main-agent activity stream, subagent events, and background task output are presented coherently rather than as separate, partially stale indicators.