nntrivi2001
57dc91585d
Internal SmartGift build of a Claude Code monitoring dashboard. Lanes: a durable unit of parallel agent work, one per working directory, tracked across session restarts. Managed lanes are git worktrees the dashboard provisions and can reset or remove behind a three-check destroy guard and a counted preflight; adopted lanes are directories you already own and are never destroyable. Pipelines: a lane moves through pipeline stages. A stage the agent declares with evidence renders green; a stage inferred from the tool-event stream renders dashed amber and never counts as done. Detection is forward-only within a 30-minute window, and never writes the declared stage. Workspace: one page at /run with a lane grid, the selected lane's pipeline, and a full Claude console behind a disclosure.
2.7 KiB
description
| description |
|---|
| Trace error propagation through a multi-agent session by agent depth — where failures originated, the depth at which they appeared, and how they cascaded up to parent agents — using the Agent Monitor workflow intelligence API and the session event stream. Use when a multi-agent run failed and you need to find the origin and blast radius of the failure. |
Error Propagation
Trace where a multi-agent session's failures started and how far they spread.
Input
The user provides: $ARGUMENTS
A session ID. If empty, fetch GET /api/sessions?limit=1, but prefer the most recent session whose status is error or abandoned; state which one you picked.
Data Sources
| Endpoint | Returns |
|---|---|
GET /api/workflows/{sessionId} |
The errorPropagation dataset: failures grouped by agent depth, with originating depth and cascade paths to parents |
GET /api/events?session_id={sessionId} |
The event stream — corroborate with APIError, SubagentStop, and failing PostToolUse events (event_type, tool_name, summary, timestamp) |
Report Sections
1. Failure Summary
From errorPropagation: total errors, the depth where the first error originated, and how many distinct agents were affected.
Origin depth: d · Errors: N · Agents affected: M
2. Errors by Depth
| Depth | Errors originated | Errors inherited from children | Net failing agents |
|---|---|---|---|
| Show whether failures concentrate deep in the tree (leaf subagents) or shallow (orchestrator). |
3. Cascade Paths
For each originating failure, the path it propagated along:
debugger (depth 2, tool failure) → code-review (depth 1, marked error) → root (depth 0, aborted)
Tie each step to a concrete event from /api/events (event_type + tool_name + timestamp) where available.
4. Error Taxonomy
Break errors down by type from the event stream: APIError vs failing tool calls vs SubagentStop with error status. Note the most frequent tool involved in failures.
5. Containment Assessment
Whether failures were contained at the depth where they originated or leaked to parents. Name any parent that aborted solely because a child failed — a candidate for better error handling / isolation.
Output
- Markdown tables for the depth breakdown; a fenced list for cascade paths.
- Timestamps for the first and last error.
- Cite only errors present in
errorPropagationand the event stream; never invent failures or causes. - If the session has no errors, say so plainly and stop.
- If the dashboard is unreachable, tell the user to start it with
npm startfrom the repo root.