nntrivi2001
17d56d0e01
Clean break, no compatibility alias. Renames the product name, the CLI binary (`ccam` -> `agenthub`), the env var prefix (`CCAM_` -> `AGENTHUB_`), the Prometheus metric namespace (`ccam_*` -> `agenthub_*`), the tmux session prefix (`ccam-lane-<id>` -> `agenthub-lane-<id>`), the per-repo runtime profile directory (`.ccam/profile` -> `.agenthub/profile`), the lanes state root (`~/.claude/ccam-lanes` -> `~/.claude/agenthub-lanes`), the bundled plugins (`plugins/ccam*` -> `plugins/agenthub*`) and their slash commands (`/ccam-doctor` -> `/agenthub-doctor`, `/ccam:*` -> `/agenthub:*`). Because there is no alias, an existing install has to be updated by hand: rename its `.ccam/profile` directory and any `CCAM_*` variables, and reinstall the plugin under its new name. Two other name families are deliberately left alone here, since they are not just strings: the `Claude-Code-Monitor` repository/marketplace name, and the `agent-dashboard` npm package plus its `~/.claude/agent-dashboard` runtime directory, which holds the live database and needs a migration rather than a rename. Verified: server 1406/1406, client 459/459, `grep -i ccam` clean across tracked files, `openapi.yaml` regenerated (95 paths, unchanged count).
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.