devharness 0.9.9 → 0.9.11

package/docs/message-system.md

@@ -2,7 +2,7 @@
 
 ## Overview
 
-The cdp-tools debugger uses a centralized message system to provide consistent, markdown-formatted responses to all tool calls. This guide explains how to use the system and when to use different patterns.
+The devharness debugger uses a centralized message system to provide consistent, markdown-formatted responses to all tool calls. This guide explains how to use the system and when to use different patterns.
 
 ## Architecture
 

package/docs/messages.md

@@ -1,6 +1,6 @@
-# cdp-tools Message Templates
+# devharness Message Templates
 
-This file contains all user-facing messages for the cdp-tools debugger. Messages use markdown formatting and support variable interpolation using `{{variable}}` syntax.
+This file contains all user-facing messages for the devharness debugger. Messages use markdown formatting and support variable interpolation using `{{variable}}` syntax.
 
 ## Template Usage Status
 
@@ -45,7 +45,53 @@ These templates should not be removed - they represent potential error condition
 **Type:** error
 **Code:** CHROME_LAUNCH_TIMEOUT
 
-Chrome did not become ready on port {{port}} within {{timeout}}s.
+Chrome spawned from `{{chromePath}}` and port {{port}} did not answer `/json/version` in {{probeAttempts}} probes over {{elapsedMs}}ms. No exit event was observed before the launch was abandoned.
+
+{{#probeFailures}}**Each probe's failure, in order:**
+
+```
+{{probeFailures}}
+```
+{{/probeFailures}}
+{{#stderrTail}}**Chrome stderr, last bytes:**
+
+```
+{{stderrTail}}
+```
+{{/stderrTail}}
+{{#profileDir}}**Profile retained at:** `{{profileDir}}`{{/profileDir}}
+
+---
+
+## CHROME_LAUNCH_PROCESS_EXITED
+
+**Type:** error
+**Code:** CHROME_LAUNCH_PROCESS_EXITED
+
+Chrome spawned from `{{chromePath}}` and the process ended before port {{port}} answered `/json/version`. Exit code {{exitCode}}, signal {{exitSignal}}, {{elapsedMs}}ms after spawn, across {{probeAttempts}} probes.
+
+{{#probeFailures}}**Each probe's failure, in order:**
+
+```
+{{probeFailures}}
+```
+{{/probeFailures}}
+{{#stderrTail}}**Chrome stderr, last bytes:**
+
+```
+{{stderrTail}}
+```
+{{/stderrTail}}
+{{#profileDir}}**Profile retained at:** `{{profileDir}}`{{/profileDir}}
+
+---
+
+## CHROME_BINARY_ABSENT
+
+**Type:** error
+**Code:** CHROME_BINARY_ABSENT
+
+No file exists at `{{chromePath}}`, the path resolved for platform `{{platform}}`. No process was spawned.
 
 ---
 
@@ -1220,12 +1266,6 @@ Unsupported platform: {{platform}}
 
 Failed to spawn Chrome process: {{error}}
 
-**Suggestions:**
-- Verify Chrome is installed on your system
-- Check that you have permission to execute Chrome
-- On macOS: Chrome should be at `/Applications/Google Chrome.app`
-- On Linux: Chrome/Chromium should be in your PATH
-
 ---
 
 ## PUPPETEER_NOT_CONNECTED
@@ -3631,7 +3671,7 @@ Note: `tools.enabled`/`tools.disabled` changes still require an MCP server resta
 **Type:** success
 **Summary:** Restart requested
 
-Sent a restart signal to the cdp-tools supervisor (PID {{pid}}). The server restarts shortly - no reconnect needed.
+Sent a restart signal to the devharness supervisor (PID {{pid}}). The server restarts shortly - no reconnect needed.
 
 Note: any Chrome instances this session launched will be killed (call `launchChrome` again). Managed dev servers (the `server` tool) survive and reattach automatically.
 
@@ -3890,7 +3930,7 @@ This session is `{{self}}`. Its mailbox: `{{mailboxPath}}`
 
 {{sessionList}}
 
-**Note:** To receive a message while doing other work, arm a Monitor on this session's mailbox file - it appends one JSON line per message, so a `tail -f` style watch fires the moment one lands. Without a Monitor, messages surface only when `message({ action: 'read' })` runs.
+**Note:** An arriving message announces itself on this session's event stream, `{{eventStreamPath}}`, which is also where guard blocks land - one watch covers both. The plugin's SessionStart hook prints that path and the `Monitor` call at the start of every session. Without a watch, messages surface only when `message({ action: 'read' })` runs. Nothing watches the mailbox file; it holds the conversation and the read cursor.
 
 ---
 

package/docs/parser-plugins.md

@@ -2,7 +2,7 @@
 
 `content({ action: 'parse' })` runs small, user-written parser plugins against
 the current page and returns their JSON output. Plugins are **not** shipped with
-cdp-tools — you write the ones you need.
+devharness — you write the ones you need.
 
 ## Usage
 

package/docs/replay.md

@@ -1183,7 +1183,7 @@ rendered in their own section — never merged into `results` or the
 successful/failed counts. A broken cleanup must not turn a passing run red, nor
 make a failing one look like it failed somewhere it did not.
 
-Teardown is best-effort by construction: a killed cdp-tools process takes any
+Teardown is best-effort by construction: a killed devharness process takes any
 pending teardown with it. It reduces accumulation; it cannot guarantee a clean
 world, so assertions that depend on absence remain order-dependent regardless.
 

package/docs/troubleshooting.md

@@ -8,7 +8,7 @@
 dev server has stopped - but the MCP connection still works.
 
 **Cause:** The session was suspended. With no request from the client for
-`session.idleSuspendMinutes` (default 120), cdp-tools releases what it holds
+`session.idleSuspendMinutes` (default 120), devharness releases what it holds
 and exits; the supervisor stays connected and started a fresh server for your
 next call.
 
@@ -24,7 +24,7 @@ released when no other live session claims it or is working in its directory.
 
 ### A dev server stopped when I opened a new session
 
-**Problem:** Starting cdp-tools in a project stopped a dev server that was
+**Problem:** Starting devharness in a project stopped a dev server that was
 already running.
 
 **Cause:** Every session that had claimed it was gone, so it was collected as
@@ -34,7 +34,7 @@ running until you reboot.
 **Solutions:**
 - Restart it (`server({ action: 'start', serverId: '...' })`).
 - To keep a server outside this lifecycle, run it yourself rather than through
-  the `server` tool; cdp-tools only collects servers it manages, and only ones
+  the `server` tool; devharness only collects servers it manages, and only ones
   it can prove nobody is left to use.
 
 ## Chrome Connection Issues

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "devharness",
-  "version": "0.9.9",
+  "version": "0.9.11",
   "description": "MCP server that connects AI assistants to Chrome DevTools Protocol for runtime debugging - set breakpoints, inspect variables, monitor network traffic, and automate browser interactions",
   "type": "module",
   "main": "build/index.js",

package/plugin/skills/devharness/SKILL.md

@@ -2,7 +2,7 @@
 name: devharness
 description: Drive and debug a running app via the devharness MCP server - launch or attach to Chrome and Node.js, set breakpoints and logpoints, inspect call stacks and variables, watch console and network, manage dev servers, replay any earlier tool call by its history index, and record reproduction sequences that verify a fix. Use whenever a task involves running or debugging a live app, reproducing or verifying a bug, re-driving setup you already did (relaunching, re-logging in, refilling a form), or the user mentions breakpoints, Chrome DevTools, CDP, replay sequences, or devharness tools (launchChrome, navigate, breakpoint, inspect, replay, server, issues, etc.).
 compatibility: Requires the devharness MCP server to be connected (tools such as launchChrome, breakpoint, inspect, replay, server, issues). The shell commands need `devharness` on PATH (`npm i -g devharness`); without it use `npx -y devharness@<version> <command>`. Previously published as cdp-tools-mcp.
-version: 0.9.9
+version: 0.9.11
 ---
 
 # devharness

package/plugin/skills/devharness/references/sequences.md

@@ -1,6 +1,6 @@
 # Replay Sequences
 
-A sequence is an ordered list of tool calls you can re-run. It's how cdp-tools
+A sequence is an ordered list of tool calls you can re-run. It's how devharness
 turns "I clicked around and hit the bug" into something repeatable - a
 regression test, a repro attached to an issue, or a multi-step automation.
 
@@ -590,7 +590,7 @@ A failing teardown step never changes the run's verdict; it is reported in its
 own section. Otherwise a broken cleanup would mask the failure it was cleaning up
 after.
 
-**Teardown is always best-effort.** A killed cdp-tools process takes any pending
+**Teardown is always best-effort.** A killed devharness process takes any pending
 teardown with it, so it reduces accumulation and cannot guarantee a clean world.
 An assertion that depends on nothing being left over ("No assets yet") stays
 order-dependent whether or not teardown exists - mint your own fixture and assert

package/plugin/skills/devharness/references/tool-categories.md

@@ -80,11 +80,11 @@ runs against (see the skill's Quick Start).
 **Messages**: `message` (actions: sessions, send, read, reply)
 - Text between two devharness sessions on this machine - a session hitting a devharness bug talking to the session working on devharness itself. `sessions` lists reachable mailboxes and this session's own mailbox path
 - `send({ to, text, waitForReplyMs })` holds the call open until something lands in this session's mailbox (max 300000ms) and returns it; without `waitForReplyMs` it returns as soon as the line is written. `reply({ replyTo, text })` routes back to the sender of that message. The wait returns on ANY arrival, not only a tagged reply, so two sessions blocking at the same moment both release
-- Transport is one append-only JSONL file per session under `~/.devharness/messages/`, which is what makes it work across project roots. A busy session needs a Monitor armed on its mailbox file to be interrupted; otherwise messages surface on its next `message({ action: 'read' })`
+- The mailbox is one append-only JSONL file per session under `~/.devharness/messages/`, holding the conversation and the read cursor; the global directory is what makes it reach across project roots. Nothing watches it. An arrival announces itself on that session's event stream, `~/.devharness/events/<id>.jsonl`, so one watch covers messages and guard blocks alike; without one, messages surface on the next `message({ action: 'read' })`
 
 **Server**: `server` (actions: start, stop, restart, list, logs, stopAll, setAutoRun, clearLogs, remove, monitorPort, unmonitorPort, listMonitored, acknowledgePort, acknowledgeStartup, extendStartup, cancelPendingRestart)
 - Use `global: true` to access servers started from a different working directory
-- `start({ watch: true, watchPaths?: [...] })`: cdp-tools watches the given paths (default: cwd) and auto-restarts the server on file changes, instead of relying on `--watch`/nodemon. Pause-aware: if a breakpoint debugger is paused on that server's inspector port, the restart queues instead of firing immediately - `cancelPendingRestart` discards a queued restart to keep debugging without it firing on resume
+- `start({ watch: true, watchPaths?: [...] })`: devharness watches the given paths (default: cwd) and auto-restarts the server on file changes, instead of relying on `--watch`/nodemon. Pause-aware: if a breakpoint debugger is paused on that server's inspector port, the restart queues instead of firing immediately - `cancelPendingRestart` discards a queued restart to keep debugging without it firing on resume
 
 **Replay**: `replay` (actions: history, create, list, get, delete, export, load, listSaved, deleteSaved, run, runAll, step, finish, insert, addConditional, status, cancel, repeat, runFromLog, recordInteraction)
 - `recordInteraction`: record mouse, keyboard, and navigation events with a visual overlay
@@ -108,6 +108,6 @@ runs against (see the skill's Quick Start).
 - `show`: Display current configuration
 - `listTools`: List all toggleable tools with status and dependency conflicts
 - `reload`: Re-read config.json now (also happens automatically on file edits, ~250ms debounce). Doesn't apply `tools.enabled`/`tools.disabled` - those need `restart`
-- `restart`: Restart cdp-tools itself via the mcp-supervisor (see "Restarting cdp-tools" above) - use when the server seems stuck/broken, or to apply `tools.enabled`/`tools.disabled` changes
+- `restart`: Restart devharness itself via the mcp-supervisor (see "Restarting devharness" above) - use when the server seems stuck/broken, or to apply `tools.enabled`/`tools.disabled` changes
 - `listProfiles`: List named persistent Chrome profiles and the root they live under
 - `resetProfile`: Wipe and recreate a named profile (`config({ action: 'resetProfile', profile: 'device-a' })`). Refused while a live Chrome holds that profile - nothing is deleted in that case