Feature request: Subagent observability and resilience — per-agent metrics, infra-failure resume, failure state report

Feature request: Subagent observability and resilience — per-agent metrics, infra-failure resume, failure state report

Context

Observed on 2026-08-29 during a rebase resolution (deepseek-harness):

The second point is the costliest in trust: a failed subagent leaves the parent without information about side effects already produced, and the only available response is a manual re-inspection of the repository.

Problem or Gap

1. No per-subagent metrics: tokens in/out, duration, tool call count, and the model actually used are not exposed during or after execution.
2. No resume guarantee: a subagent killed by an infrastructure error (402/429/network) cannot be resumed as-is; its context is lost to the parent.
3. No failure state report: on failure, nothing indicates the last action performed or the files touched.

Proposal

1. Per-subagent metrics: tokens in/out, duration, tool call count, and the model actually used — exposed in the UI and via an API, during and after execution. The actually-used model cross-references the provider-fallback FR (issue-09): after a fallback, the UI must show the effective model, not the initial alias.
2. Resume guarantee for infrastructure errors: a subagent killed by a 402/429/network error is resumable as-is — its context is preserved and resuming by id restores the execution state.
3. Minimal failure state report: on failure, produce a minimal report: last action performed and files touched — the parent can verify side effects without re-exploring the repository.

Impact

• Cost control: per-agent metrics make subagent cost visible before completion.
• Resilience: infrastructure errors become recoverable instead of fatal.
• Trust: failure reports let the parent verify side effects deterministically instead of re-inspecting manually.

Acceptance criteria

1. A running subagent's metrics (tokens in/out, duration, tool calls, effective model) are queryable during execution, from both the UI and the API.
2. A subagent killed by 402/429/network is resumable by its id, and resuming restores its context.
3. A failed subagent produces a report listing the last action performed and the files touched.
4. The displayed model is the one actually used after a fallback (cross-check with the provider-fallback FR).
5. A user-initiated TaskStop produces a status distinct from an infrastructure failure and does not auto-resume.
6. Non-infrastructure failures (logic error, permission denied) show an explicit status; as-is resume is not silently attempted.
7. Providers without usage counters leave metric fields explicitly absent — no misleading zeros.
8. A subagent dying before any action produces a minimal "no action performed, no files touched" report (no crash).

No files, tests, or entry points are named in the issue. Start by locating the subagent execution, metrics, UI/API, resume, and failure-report paths, then check how TaskStop and provider fallback are represented. Done means satisfying all eight acceptance criteria, including explicit handling for unsupported metrics and each failure class.