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.
2026-07-29 17:07:45 +07:00
commit 57dc91585d
783 changed files with 221743 additions and 0 deletions
@@ -0,0 +1,53 @@
+---
+description: >
+  Report concurrency and parallelism for a session — how many agents ran in
+  parallel, concurrency-lane utilization, peak parallel width, and
+  serialization bottlenecks (sequential chains that could have run as parallel
+  lanes) — using the Agent Monitor workflow intelligence API. Use when checking
+  whether a multi-agent session used parallelism efficiently.
+---
+
+# Concurrency Report
+
+Report on parallel execution for one Claude Code session: lanes, peak width, utilization, and where work serialized.
+
+## Input
+
+The user provides: **$ARGUMENTS**
+
+A session ID. If empty, fetch `GET /api/sessions?limit=1` and report on the most recent session, stating which one.
+
+## Data Sources
+
+| Endpoint | Returns |
+|----------|---------|
+| `GET /api/workflows/{sessionId}` | The `concurrency` dataset (overlapping agent execution lanes with start/end timing) and the `complexity` dataset (numeric score from depth, breadth, and tool diversity) |
+
+## Report Sections
+
+### 1. Parallelism Summary
+From `concurrency`: number of distinct lanes, peak parallel width (max agents running simultaneously), and total agents. Pair with the `complexity` score to judge whether the parallelism matched the work's size.
+`Lanes: N · Peak parallel: M · Agents: K · Complexity: S`
+
+### 2. Lane Timeline
+A per-lane list of the agents that occupied each lane in order:
+`Lane 1: explore (0–12s) → code-review (12–48s)`
+`Lane 2: debugger (5–30s)`
+Show overlapping windows so simultaneity is visible.
+
+### 3. Utilization
+| Lane | Busy time | Idle time | Utilization % |
+|------|-----------|-----------|---------------|
+Plus an overall utilization figure (busy lane-time / total lane-time).
+
+### 4. Serialization Bottlenecks
+Identify sequential chains where one agent waited on the previous despite no apparent dependency — candidates to run as parallel lanes. State the chain and the wall-clock time it cost. Only flag chains the `concurrency` timing data actually shows as sequential.
+
+## Output
+
+- Markdown tables for utilization; a fenced list for the lane timeline.
+- Durations in human units (e.g. `48s`, `2m 10s`); percentages to whole numbers.
+- Use ▲/▼ when comparing utilization against an even-distribution baseline.
+- Cite only timing returned by the API; never invent lane overlaps or durations.
+- If the session ran a single agent (no concurrency), say so plainly rather than inventing lanes.
+- If the dashboard is unreachable, tell the user to start it with `npm start` from the repo root.