feat: Claude Code Monitor — lanes, pipelines and a merged workspace

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.
This commit is contained in:
2026-07-29 17:07:45 +07:00
commit 57dc91585d
783 changed files with 221743 additions and 0 deletions
@@ -0,0 +1,73 @@
---
description: >
Quick dashboard health and status overview — checks the Agent Monitor API
(port 4820), reports session/agent/event counts from /api/stats, confirms
WebSocket connectivity, validates hook configuration in ~/.claude/settings.json,
and shows data freshness (last event timestamp). Use to verify the monitoring
system is operational.
---
# Dashboard Status
Quick status check on the Claude Code Agent Monitor dashboard.
## Input
The user provides: **$ARGUMENTS**
Options: empty (default: full status), "quick" (API only), "verbose" (include endpoint details).
## Data Sources
| Endpoint | Returns |
|----------|---------|
| `GET /api/health` | HTTP 200 if API is running |
| `GET /api/stats` | `{ total_sessions, active_sessions, active_agents, total_agents, total_events, events_today, ws_connections, agents_by_status, sessions_by_status }` |
| `GET /api/settings/info` | Dashboard configuration: version, port, data paths |
| `GET /api/events?limit=1` | Most recent event (for freshness check) |
## Status Report
### 1. API Server
- Reachable at `http://localhost:4820`? Response time?
- If unreachable: suggest `npm start` from the project directory
### 2. System Counts
From `/api/stats`:
- Total sessions tracked (`total_sessions`)
- Active agents currently running (`active_agents`)
- Total events ingested (`total_events`)
- Events today (`events_today`)
- WebSocket connections (`ws_connections`)
### 3. Data Freshness
From latest event:
- Time since last event ingested
- If >1 hour: warn about possible hook disconnect
### 4. Hook Status
Check `~/.claude/settings.json` for configured hooks:
- Expected: PreToolUse, PostToolUse, Stop, SubagentStop, Notification, SessionStart, SessionEnd
- Report which hooks are present vs missing
### 5. Dashboard Info
From `/api/settings/info`:
- Dashboard version
- Database path and size
- Configured port
## Output Format
Compact status card:
```
╔══════════════════════════════════════╗
║ AGENT MONITOR STATUS ║
╠══════════════════════════════════════╣
║ API: ✅ Online (42ms) ║
║ Sessions: 127 tracked ║
║ Events: 4,892 ingested ║
║ Hooks: 7/7 configured ║
║ Last Event: 3 minutes ago ║
╚══════════════════════════════════════╝
```
@@ -0,0 +1,62 @@
---
description: >
Probes each major Agent Monitor API route — /api/stats, /api/analytics,
/api/sessions, /api/pricing/cost, /api/workflows/runs, /api/cc-config/overview
— and reports each one's HTTP status, latency, and response shape, flagging
which are reachable. Use to verify a dashboard install is wired up correctly.
---
# Endpoint Probe
Smoke-test the dashboard's main API surface by hitting each major route once and
reporting whether it responds and what shape it returns.
## Input
The user provides: **$ARGUMENTS**
Options: empty (default: probe all routes below), or a substring to filter which
routes are probed (e.g. `pricing` probes only matching routes).
## Data Sources
| Endpoint | Returns |
|----------|---------|
| `GET /api/stats` | `{ total_sessions, active_sessions, active_agents, total_agents, total_events, events_today, ws_connections, agents_by_status, sessions_by_status }` |
| `GET /api/analytics` | `{ overview, tokens, tool_usage, daily_events, daily_sessions, agent_types, event_types, avg_events_per_session, total_subagents, sessions_by_status, agents_by_status }` |
| `GET /api/sessions` | Session list; each: `id, status, model, cwd, started_at, ended_at, cost, metadata` |
| `GET /api/pricing/cost` | `{ total_cost, breakdown:[{ model, input_tokens, output_tokens, cache_read_tokens, cache_write_tokens, cost, matched_rule }] }` |
| `GET /api/workflows/runs` | Workflow-tool run journals (fleets) |
| `GET /api/cc-config/overview` | Claude Code config explorer overview (skills, agents, commands, plugins, mcp, hooks, etc.) |
## Method
For each route, issue a single `GET` against `http://localhost:4820<path>` with a
short timeout, capturing the HTTP status code, round-trip latency, and the
top-level shape of the JSON body (object keys, or array length). A route counts
as reachable when it returns a 2xx with parseable JSON.
If `/api/stats` itself fails to connect, the dashboard is not running — stop and
tell the user to start it with `npm start` (or `npm run dev`) from the repo root.
## Report Sections
### 1. Probe Matrix
A Markdown table — one row per route — with columns:
`endpoint`, `status` (HTTP code), `latency`, `reachable` (✅/❌), `shape`
(e.g. `object: {total_cost, breakdown[…]}` or `array[N]`).
### 2. Reachability Summary
Count of reachable vs total. Name any unreachable or non-2xx routes explicitly.
### 3. Verdict
One line: install looks healthy (all reachable) or partially wired (list the
gaps and the most likely cause — server not running, route disabled, or empty data).
## Output
- Compact Markdown; the probe matrix is the centerpiece.
- Cite the real status code, latency, and observed shape per route — never assume.
- Report shape from what actually came back; if a route returns an empty array or
object, say so rather than inferring fields.
- Keep currency, where shown, to 4 decimals (e.g. `total_cost: $0.0000`).
@@ -0,0 +1,63 @@
---
description: >
Polls the Agent Monitor /api/stats endpoint several times over a short window
and reports the live deltas in active_sessions, active_agents, events_today,
and ws_connections so you can see activity moving in real time. Use when
watching the dashboard for live changes rather than a one-time snapshot.
---
# Live Watch
Watch the dashboard's live counters change over a short window by polling
`/api/stats` a few times and reporting the deltas.
## Input
The user provides: **$ARGUMENTS**
Interpreted as the watch shape: number of polls and/or interval (e.g. `5x3s` =
5 samples 3 seconds apart). Defaults when empty: **5 samples, ~3 seconds apart**
(a ~15-second window). A bare number means that many samples at the default
interval; a bare duration means the default sample count at that interval.
## Data Sources
| Endpoint | Returns |
|----------|---------|
| `GET /api/stats` (polled) | `{ total_sessions, active_sessions, active_agents, total_agents, total_events, events_today, ws_connections, agents_by_status, sessions_by_status }` |
## Method
Poll `GET /api/stats` once per interval for the configured number of samples,
recording the timestamp and the four watched counters each time. Pace the polls
with a short wait between requests; keep the total window short (seconds, not
minutes) so it stays interactive.
If the very first poll fails to connect, the dashboard is down — stop and tell
the user to start it with `npm start` (or `npm run dev`) from the repo root,
then retry.
## Report Sections
### 1. Watch Window
State the sample count, interval, and total elapsed window.
### 2. Sample Timeline
A Markdown table — one row per poll — with columns:
`#`, `time`, `active_sessions`, `active_agents`, `events_today`, `ws_connections`.
### 3. Deltas
For each of the four watched counters, report the net change from the first to
the last sample using ▲ (increase), ▼ (decrease), or `=` (no change). Note any
mid-window spikes or dips visible in the timeline.
### 4. Verdict
One line: is the dashboard actively receiving traffic (counters moving) or idle
(flat) over the window?
## Output
- Compact Markdown. The timeline table is the centerpiece.
- Cite real values from each poll — never interpolate or invent samples.
- Deltas use ▲/▼/= with the signed numeric change, e.g. `events_today: ▲ +7`.
- Keep it scannable in a terminal — no padding beyond the table.
@@ -0,0 +1,52 @@
---
description: >
One-line summary of key Agent Monitor metrics — active sessions, total
cost from the pricing engine, events today from daily_events, top tool
from tool_usage, and current model from the most recent session. Use for
a fast at-a-glance check without leaving the terminal.
---
# Quick Stats
One-line summary of key Agent Monitor metrics.
## Input
The user provides: **$ARGUMENTS**
Options: empty (default), "cost" (cost only), "sessions" (sessions only), "tokens" (token summary).
## Data Sources
| Endpoint | Returns |
|----------|---------|
| `GET /api/stats` | `{ total_sessions, active_sessions, active_agents, total_agents, total_events, events_today, ws_connections, agents_by_status, sessions_by_status }` |
| `GET /api/pricing/cost` | `{ total_cost, breakdown }` |
| `GET /api/analytics` | tokens (total_input, total_output, total_cache_read, total_cache_write — baselines pre-summed), tool_usage, daily_sessions, daily_events |
| `GET /api/sessions?limit=1` | Most recent session for model/status |
## Output
Produce a single-line or compact summary:
**Default format:**
```
📊 127 sessions | 💰 $4.2301 total cost | 🔧 4,892 events | ⚡ 3 active | 🏆 Top tool: Read (1,204)
```
**Cost format:**
```
💰 Total: $4.2301 | Sonnet: $3.1200 | Opus: $0.9800 | Haiku: $0.1301 | Cache efficiency: 67%
```
**Sessions format:**
```
📋 127 total | ✅ 98 completed | ❌ 12 errored | 🏃 3 active | 💤 14 abandoned | Rate: 87%
```
**Tokens format:**
```
🔤 Input: 2.4M | Output: 890K | Cache Read: 1.8M | Cache Write: 340K
```
Keep it short enough to scan in a terminal prompt.