Debug Dashboard

System-level debugging for the running pi-agent-dashboard. Three layers:

flowchart TD
  L1["Layer 1 - Is the server alive?<br/>npx tsx ./scripts/health-probe.ts<br/>npx tsx ./scripts/tail-server-log.ts"]
  L2["Layer 2 - Are the bridges connecting?<br/>npx tsx ./scripts/list-sessions.ts<br/>npx tsx ./scripts/tail-server-log.ts --errors"]
  L3["Layer 3 - Is the UI rendering?<br/>(use the browser skill)"]
  L1 --> L2 --> L3

First moves — always run these

npx tsx ./scripts/health-probe.ts        # mode + uptime + version, or "not-running"
npx tsx ./scripts/tail-server-log.ts     # last 50 lines of current run
npx tsx ./scripts/list-sessions.ts       # connected pi sessions via REST

Scripts are TypeScript (cross-platform). All invocations use npx tsx so they work on Linux, macOS, and Windows. tsx is already a project dep.

If health-probe says "not-running" → server isn't up. Check server.log for the most recent start banner ([bootstrap] ready ...) and what came after. The log appends with timestamped headers per start, so the last banner block is the relevant one.

When the server is up but misbehaving

Loader launch recipes: server → native register (platform/native-ts-register.mjs); jiti only for pi-hosted code. See node-inspect-debugger skill, Tier 2 / Tier 2b.

Full known-issue catalogue: `references/known-issues.md`.

When tests fail mysteriously

Use the tee→grep pattern. Never rerun to inspect — capture once, grep forever:

npx tsx ./scripts/run-tests-triage.ts                 # all tests, tee to OS tmpdir, summarize failures
npx tsx ./scripts/run-tests-triage.ts packages/server # restrict to one package's vitest
npx tsx ./scripts/run-tests-triage.ts -t 'my test'    # by test name

After it finishes, the log lives at:

• Linux/macOS: /tmp/pi-test.log
• Windows: %TEMP%\pi-test.log

You can re-grep / re-read with custom patterns; the script prints the absolute path on each run.

Patterns + per-package vitest configs + watch mode are documented in `references/test-failure-triage.md`.

When the UI is the problem

This skill stops at "the server says X but the UI shows Y". For visual debugging — verifying layouts, screenshotting, hunting console errors, testing responsive breakpoints — switch to the browser skill (shipped by the dashboard bridge extension to every session). Quick pointer: see `references/ui-debug.md`.

When you must verify a change without touching the live server

The live :8000 server runs MAIN-repo code — /api/restart never loads worktree edits, and a careless npm run build leaks into packages/client/dist (what live serves). To verify a UI/worktree change or serve a review mockup in full isolation (temp HOME, non-8000 ports, PI_DASHBOARD_NO_MDNS=1), see `references/isolated-verification.md`.

Log file locations

All log + config files. Worth bookmarking. See `references/log-locations.md` for the full map.

STOP — docs-first gate

Before answering any "how do I X" / "why does Y happen" question:

grep -ni '<keyword>' docs/faq.md docs/*.md README.md

The FAQ already documents most recurring symptoms (Electron Node bin, Fastify crash range, tunnel watchdog, port conflicts). Reading source before grepping docs wastes tokens and risks wrong answers. Per AGENTS.md "STOP — Docs-First Gate".

Related skills

• browser — UI/visual issues, screenshots, console errors, responsive testing (Electron + web)
• implement — back to implementing once the bug is identified
• pi-dashboard — interact with the dashboard via REST (list sessions, send prompts, abort)
• ci-troubleshoot — when the problem only shows up in CI
• code-review — review the fix before committing