/dashboard

name: dashboard
license: MIT
description: >-
  Real-time harness observability dashboard. Reads campaigns, fleet sessions,
  telemetry, and pending queues to present a snapshot of harness state at a
  glance. Invoked by /dashboard, /do status, or phrases like "what's happening"
  and "show activity".
user-invocable: true
auto-trigger: false
trigger_keywords:
  - dashboard
  - what's happening
  - what's going on
  - show activity
  - harness state
  - show me status
last-updated: 2026-03-26

/dashboard — Harness Observability Dashboard

When to Use

• "What's happening?" / "Status?" / "What's going on?"
• "Show activity" / "Show me the dashboard"
• After returning to a project after time away
• When /do routes "status", "dashboard", "what's happening", "what's going on", "show activity"
• Directly: `/dashboard`

Inputs

None required. Works with whatever state exists on disk.

Protocol

Step 0: RUN DASHBOARD IMPLEMENTATION

Run the local dashboard implementation from the project root:

node scripts/dashboard.js

If the package scripts are available, this equivalent command is also valid:

npm run dashboard

The script is read-only. It renders a user-facing control-plane snapshot from `.planning/`, telemetry, hook config, coordination state, worktrees, and cost data. Use the manual collection protocol below only as a fallback if the script is missing or fails in the current project.

Step 1: COLLECT STATE

Read the following sources. Each is optional — if a file or directory doesn't exist, treat it as empty. Never crash on missing state.

**Campaigns:**

• Glob `.planning/campaigns/*.md`
• For each file, read the first 40 lines to extract:
• `Status:` field
• `Direction:` field (truncate to 60 chars)
• Phase progress (search for `Phase N of M` or `## Phase` headings)
• Most recent line starting with `- [` from the Decision Log
• If all phases are complete but status is still active, report

`needs-completion` and show: `node scripts/campaign.js complete <slug> --archive`

• If a campaign is marked completed but still lives in `.planning/campaigns/`,

report `needs-archive` and show the same archive command.

• If prior build/verify phases are complete but the `review-package` Exit

Evidence row is still pending, missing, or points at a missing local package, report a repair before campaign completion: `node scripts/package-delivery.js <slug>`

**Cost Data (two sources, prefer real):**

• Primary: run `node scripts/session-tokens.js --today` and `--all` — reads Claude Code's native session JSONL for exact token counts
• Fallback: read `.planning/telemetry/session-costs.jsonl`; cost priority `real_cost` > `override_cost` > `estimated_cost`; group by `campaign_slug`, sum cost/agents/minutes, compute grand total
• Live session: read `.planning/telemetry/cost-tracker-state.json` for burn rate
• Label real data "(real)" and estimates "(est)"

**Fleet Sessions:**

• Glob `.planning/fleet/session-*.md`
• For each file, read the first 30 lines to extract:
• `status:` field
• `wave:` or wave number
• `agents:` or agent count

**Recent Telemetry:**

• Read last 50 lines of `.planning/telemetry/hook-timing.jsonl` (if it exists)
• Read last 50 lines of `.planning/telemetry/audit.jsonl` (if it exists)
• Merge and sort by timestamp (descending). Take the 10 most recent entries.
• For each entry: extract `ts` (or `timestamp`), `hook` (or `event`), and a

short description field. Format as relative time.

**Recent Hook Activity (separate from general telemetry):**

• Read last 20 lines of `.planning/telemetry/hook-timing.jsonl`
• For `event: "timing"` entries: extract `hook`, `duration_ms`, `timestamp` (relative), and `outcome` (pass if no matching error in hook-errors.jsonl within 1s; block if a block entry exists)
• For `event: "counter"` entries: extract metric name as the "event" column with count context

**Hook Overhead (timing percentiles):**

• Read all of `.planning/telemetry/hook-timing.jsonl` (if it exists)
• Keep only entries with a numeric `duration_ms`; group by `hook`
• Per hook compute: count, p50, p95, max (nearest-rank percentile over the sorted durations)
• Sort rows by p95 descending
• If the file is missing or contains no timed entries, render the one-line note instead

**Routine Quota (account-wide 15 runs / 24h cap):**

• Read `.planning/telemetry/routine-runs.jsonl` (if it exists)
• Expected JSONL shape, one record per quota-consuming run:

`{"ts": "<ISO timestamp>", "kind": "RemoteTrigger" | "CronCreate" | "ScheduleWakeup"}`

• Count records with `ts` inside the last 24 hours; compare against the cap of 15
• Warn when the count exceeds 12 (hitting the cap pauses every routine on the

account; see `docs/ROUTINE-QUOTA.md`)

• The harness does not write this file automatically yet — remote-run logging

populates it when a routine mechanism is actually used. Local runners (`local-watch.js`, `local-daemon.js`, `local-schedule.js`) never consume quota and must not be counted.

**Pending Queues:**

• Count actionable entries in `.planning/telemetry/doc-sync-queue.jsonl` where `status` is `pending` or `needs-review` (or 0 if missing)
• Count lines in `.planning/telemetry/merge-check-queue.jsonl` (or 0 if missing)
• Count files in `.planning/intake/` (or 0 if missing)

**Hook Value Data (for HOOKS VALUE section):**

• Read `.planning/telemetry/hook-errors.jsonl` (if it exists, last 200 lines)
• Count entries where `hook` = "protect-files" (blocked file access)
• Count entries where `hook` = "external-action-gate" (gated external actions)
• Count entries where `hook` = "quality-gate" (quality violations)
• Read `.planning/telemetry/hook-timing.jsonl` (if it exists, last 200 lines)
• Count entries where `hook` = "circuit-breaker" and `metric` = "trips"
• Count total entries from today (entries containing today's ISO date prefix)
• Read `.planning/telemetry/audit.jsonl` (if it exists, last 200 lines)
• Count ent