Files

T

nntrivi2001 17d56d0e01 refactor!: rebrand CCAM to AgentHub

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).

2026-09-07 12:09:15 +07:00

2.5 KiB

Raw Blame History

description

description
Summarize Workflow-tool fleet runs from the Agent Monitor — these fleets emit no hooks and are ingested from on-disk run journals. List recent runs with status and agents-per-run, then drill into a single run's per-agent detail. Reconciles against the live run-state endpoints. Use when reviewing Workflow() fleets rather than hook-instrumented interactive sessions.

Fleet Runs

Summarize Workflow-tool (Workflow()) fleet runs and drill into one run's agents.

Input

The user provides: $ARGUMENTS

Empty → list the most recent fleet runs.
A run ID → drill into that single run.
latest → drill into the most recent run.

These fleets emit no hooks; the dashboard ingests them from on-disk Workflow-tool run journals, so this data is independent of the hook event stream.

Data Sources

Endpoint	Returns
`GET /api/workflows/runs`	List of ingested fleet run journals: run id, status, agent count, timing
`GET /api/workflows/runs/{runId}`	One run in detail: per-agent status, timing, type, and outputs
`GET /api/run`	Live run state across the fleet (current/active runs)
`GET /api/run/{id}`	Live state for one run, to reconcile against the journal

Report Sections

1. Runs Overview (when listing)

Run ID	Status	Agents	Started	Duration
Sort most recent first. Add a one-line status mix below (e.g. `8 runs: 5 completed, 2 running, 1 error`).

2. Run Detail (when a run ID / `latest` is given)

From GET /api/workflows/runs/{runId}, reconciled with GET /api/run/{id}:

Header: run id, status, total agents, wall-clock duration.
Per-agent table:

Agent Type Status Duration Notes
Call out the longest-running agent and any agent with an error/failed status.

3. Status & Health

Completion rate (completed / total agents), any stalled or errored agents, and whether the journal and the live run-state endpoint agree (flag drift if they do not).

Output

Markdown tables; status mix as a single summary line.
Durations in human units (e.g. 3m 04s).
Make explicit that these runs come from run journals (no hooks), so hook-derived metrics do not apply.
Cite only runs and agents returned by the API; never invent runs.
If there are no fleet runs, say so plainly.
If the dashboard is unreachable, tell the user to start it with npm start from the repo root.

2.5 KiB Raw Blame History