Dashboard

/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 entries mentioning "circuit-breaker" or "circuit_breaker"

Hook Problem Taxonomy:

• Read last 100 entries from .planning/telemetry/hook-errors.jsonl.
• Classify protect-files blocks and hard external-action-gate blocks as safety-block with info severity; they prove protection fired and do not create a repair action by themselves.
• Classify error and parse-fail actions as hook-failure with high severity; these are actionable.
• Classify blocked-restricted as restricted-scope-block with high severity; this is actionable.
• Classify first-encounter and consent-block from external-action-gate as approval-needed with medium severity; this is actionable.
• If an external-action-gate approval entry has a later matching tool-call entry in audit.jsonl, classify it as resolved-approval with info severity; it should not create a repair action. Treat git push -u and git push as equivalent for the same branch, and allow a small near-simultaneous timestamp skew between hook and tool-call entries.
• If an unresolved external approval entry is older than 15 minutes, classify it as stale-approval with low severity; it should not create a current repair action.
• Classify entries older than 24 hours as stale with low severity and do not create a repair action from stale entries.
• The /telemetry repair action should appear only when actionable entries are present. Safety blocks remain visible in PROBLEMS and HOOKS VALUE.

Health:

• Count circuit breaker entries from audit.jsonl (from hook value data above)
• Count total lines in .planning/telemetry/audit.jsonl written today
• Count entries in hooks array of .claude/hooks-template.json (or .claude/hooks.json if template not present); use 0 if neither exists
• Read .claude/harness.json (Citadel's shared config path for all runtimes, including Codex) → trust object:
  • sessions_completed, campaigns_completed counters
  • Compute level: novice (sessions < 5), familiar (5-19), trusted (20+ with 2+ campaigns)
  • If trust.override is set, use that and note "(override)"