harnex 0.12.0 → 0.29.0

data/docs/lanes.md

@@ -0,0 +1,202 @@
+# Lanes
+
+A **lane** is one Pi worker doing one job: a question, a task, or a task plus
+its follow-ups. You start one with `harnex ask` or `harnex delegate`, collect
+it with `harnex result`, continue it with `harnex reply`, and finish it with
+`harnex land` or `harnex discard`. Every lane has a name, runs in a visible
+tmux window named after it, and leaves a small record so any later command can
+find it by name from anywhere in the repository.
+
+Lanes are the agent-facing layer of harnex. Everything here is also available
+as native tools through [`harnex mcp`](mcp.md), and the low-level `run`, `send`,
+`wait` and `watch` commands remain underneath for custom orchestration.
+
+| Need | Command |
+| --- | --- |
+| A second opinion, an explanation, a read-only review | `harnex ask "QUESTION"` |
+| A task that edits code | `harnex delegate --worktree NAME "TASK"`, review, then `harnex land NAME` |
+| A task that only runs or inspects things | `harnex delegate "TASK"` |
+| Several tasks in parallel | `harnex delegate --no-wait --worktree NAME "TASK"` per task, then `harnex result` |
+| More work for the same worker, with its context | `harnex reply NAME "MESSAGE"` |
+| Throw a lane away | `harnex discard NAME` |
+| What is open and what each worker is doing | `harnex lanes` |
+
+## Ask
+
+```bash
+harnex ask "Which module writes dispatch rows, and is the lane case tested?"
+harnex ask --model openai/gpt-5.1 --file /tmp/review.md
+```
+
+The worker reads the repository with read-only tools (`read`, `grep`, `find`,
+`ls`), answers, and stops. It cannot run commands or change anything; for
+that, use `delegate`. stdout is the answer; stderr gets one line naming the
+lane, its time and the model. `--write` lets the worker edit and run commands,
+and `--fallback-model M` asks once more with another model when the first one
+is out of capacity or rate limited.
+
+Every ask is a lane (`pi-ask-xxxx`), so `harnex reply pi-ask-xxxx "..."` asks a
+follow-up of the same worker, with everything it read still in context.
+
+## Delegate
+
+```bash
+harnex delegate --worktree word-count \
+  "Add TextKit.word_count(text): the number of whitespace-separated words, with a test. Run bin/test."
+```
+
+The worker edits files, runs commands, and replies with a summary. harnex
+prints that reply and then a footer:
+
+```text
+Committed as `a6bf91e` on `harnex/word-count`.
+- Added `TextKit.word_count(text)` in `lib/textkit.rb`.
+- Ran `bin/test`: 3 tests, 6 assertions, all passing.
+
+── word-count: done in 49s · gpt-5.1 · $0.03 · 1 commit, 2 files (+12 -0)
+   worktree .harnex/worktrees/word-count (branch harnex/word-count)
+   next: review `git diff HEAD...harnex/word-count`, then `harnex land word-count` ...
+```
+
+The footer always says what happened and what to do next: state, time, model,
+cost, commits and the next commands.
+
+- **`--worktree NAME`** creates `.harnex/worktrees/NAME` on a new branch
+  `harnex/NAME` from `HEAD`. The worker is told to commit there. Parallel lanes
+  never collide, and your checkout is untouched until you land. If your checkout
+  has uncommitted changes, harnex warns that the worktree starts from `HEAD`.
+- **Without `--worktree`** the worker works in the current directory, which is
+  right for tasks that only run or inspect things (tests, a benchmark, a long
+  command). `--name NAME` names the lane; otherwise harnex derives a name from
+  the task (`pi-slow-bench`).
+- **`--file PATH`** reads a long brief from a file. Briefs must be
+  self-contained: the worker has not seen your conversation. Name the files, the
+  expected behavior and how to verify it.
+- **`--model provider/model`** and **`--effort low|medium|high`** pick the
+  model; the default is Pi's own default model.
+
+### Waiting, and long tasks
+
+Blocking commands (`ask`, `delegate`, `reply`, `result`) wait up to 9 minutes
+by default, which fits under the 10-minute tool cap most coding agents have.
+`--timeout DUR` changes it (`540`, `9m`, `1h30m`, or `none`).
+
+| Exit code | Meaning |
+| --- | --- |
+| 0 | done |
+| 1 | the worker failed (the footer says why and what to try) |
+| 2 | usage error (nothing was started) |
+| 124 | still working — the worker keeps going; run `harnex result NAME` |
+
+```text
+── slow-bench: still working (9m02s so far)
+   keep waiting: harnex result slow-bench
+```
+
+`harnex result NAME` blocks again (another 9 minutes by default) and prints the
+result in the same format once it lands, even if the worker finished between
+calls.
+
+## Review and land
+
+```bash
+git diff HEAD...harnex/word-count     # read the change
+(cd .harnex/worktrees/word-count && bin/test)
+harnex land word-count
+```
+
+`harnex land NAME` merges `harnex/NAME` into the current branch of the main
+checkout, then removes the worktree and the branch. Leftover uncommitted
+changes in the lane are committed first. `harnex land` with no name lands every
+finished worktree lane you started in this repo, oldest first.
+
+**Conflicts.** When the merge conflicts, git's merge is left in progress and
+harnex lists the files. Resolve them, `git add` them and `git commit`, then run
+`harnex land NAME` again to clean up (or `git merge --abort` to give up).
+Several lanes that touched the same file land one at a time.
+
+**Merging by hand** works too. A lane whose branch is already in `HEAD` (and
+whose worktree is clean) is tidied up by the next `delegate`, `result`, `lanes`
+or bare `land`.
+
+`harnex discard NAME` stops the lane if it is still working and deletes its
+worktree and branch without merging.
+
+## Parallel lanes
+
+```bash
+harnex delegate --no-wait --worktree slugify  "Fix TextKit.slugify so punctuation is dropped ..."
+harnex delegate --no-wait --worktree truncate "Add TextKit.truncate(text, n) ..."
+harnex delegate --no-wait --worktree titleize "Add TextKit.titleize(text) ..."
+harnex result          # waits for all three, printing each result as it lands
+harnex land            # lands every finished worktree lane, oldest first
+```
+
+`harnex result` with no names covers every lane you started in this repo whose
+result you have not collected yet. Name lanes to wait for specific ones.
+"You" is the calling agent session (`CLAUDE_CODE_SESSION_ID` or
+`PI_SESSION_ID`); a Claude Code subagent shares its parent's id, so a subagent
+should name the lanes it waits for.
+
+## Follow-ups
+
+```bash
+harnex reply word-count "Also add TextKit.char_count(text), in the same style, with a test."
+```
+
+The worker keeps its context. A worker still on its turn takes the message
+mid-task as a follow-up; a lane that has finished is relaunched on its own Pi
+session (`pi --session`), so it remembers everything from the earlier turns.
+The footer's cost is the lane's total so far.
+
+## When a model fails
+
+```text
+── word-count: FAILED after 3s (API error (404): model_not_found) · gpt-9 · $0.00 · 0 commits
+   next: `harnex reply word-count "Continue the same task from where you stopped" --model openai/gpt-5.1`
+         (keeps the task; another model) or `harnex discard word-count`
+```
+
+For provider and model failures (not found, rate limited, out of capacity) the
+footer suggests continuing on Pi's default model. `reply --model` resumes the
+same session, so the task is not lost. For `ask`, `--fallback-model` does this
+automatically.
+
+## Watching a worker
+
+```bash
+harnex lanes
+```
+
+```text
+NAME      STATE                  AGE    MODEL    BRANCH           NEXT
+slugify   working (now bash 12s) 1m40s  gpt-5.1  harnex/slugify   harnex result slugify
+truncate  done                   2m03s  gpt-5.1  harnex/truncate  harnex land truncate
+```
+
+A working lane shows the tool it is running right now (tool names only; harnex
+never records tool arguments). `harnex pane --id NAME --lines 40` captures the
+worker's tmux window, and the window itself is always there to watch.
+
+## Where things live
+
+- **Lane records:** `~/.local/state/harnex/lanes/` (one JSON file per lane:
+  repo, worktree, branch, model, owner, Pi session, cost, last result). Closed
+  lanes are pruned after 30 days; open lanes never are.
+- **Worktrees:** `.harnex/worktrees/NAME` inside your repository, on branch
+  `harnex/NAME`.
+- **`.harnex/`** is added to the clone's `.git/info/exclude` the first time
+  harnex writes there, so lane worktrees and dispatch rows never show up as
+  untracked work. Nothing tracked changes.
+
+## Habits from `harnex run`
+
+The lane commands accept the flags people and agents reach for from the
+low-level `run`, instead of refusing them: `--id NAME` and `--tmux NAME` name
+the lane, `--auto-stop` and `--wait-done` are what lanes do anyway,
+`--wait-timeout` means `--timeout`, and `--context`/`--context-file` give the
+task.
+
+See also: [MCP server](mcp.md), [Coding agents](agents.md), and the CLI
+reference (`harnex help delegate`, `result`, `reply`, `land`, `discard`,
+`lanes`, `ask`).

data/docs/mcp.md

@@ -0,0 +1,102 @@
+# MCP server
+
+`harnex mcp` serves the [lane](lanes.md) commands as native
+[Model Context Protocol](https://modelcontextprotocol.io) tools over stdio.
+Claude Code, Pi and any other MCP client can then hand work to Pi workers
+without shelling out, quoting a brief, or looping on exit codes.
+
+```bash
+harnex mcp install     # register for Claude Code (user scope) and Pi
+harnex mcp status      # where it is registered
+harnex mcp uninstall   # remove both registrations
+```
+
+Restart running Claude Code and Pi sessions afterwards: clients load MCP
+servers when a session starts. `harnex doctor` reports the registrations under
+`integrations`.
+
+## Tools
+
+Each tool runs the matching CLI command and returns its text: the worker's
+reply followed by the `── NAME:` footer.
+
+| Tool | Arguments | Does |
+| --- | --- | --- |
+| `ask` | `question`; `model`, `effort`, `fallback_model`, `write`, `cwd`, `wait_minutes` | A read-only answer from a Pi worker |
+| `delegate` | `task`; `worktree`, `name`, `wait`, `model`, `effort`, `cwd`, `wait_minutes` | A worker does the task (in a worktree when `worktree` is set) |
+| `result` | `names`; `cwd`, `wait_minutes` | Wait for lanes and return each result |
+| `reply` | `name`, `message`; `model`, `wait`, `cwd`, `wait_minutes` | Follow-up to the same worker, which keeps its context |
+| `land` | `names` (optional); `cwd` | Merge worktree lanes, remove worktrees and branches |
+| `discard` | `names`; `cwd` | Drop lanes without merging |
+| `lanes` | `all`; `cwd` | Open lanes, what each worker is doing, the next step |
+
+Arguments are forgiving: `prompt`, `brief` or `message` work for `task`;
+`prompt` or `query` for `question`; `lane` or `id` for `name`. `cwd` defaults
+to the server's working directory, which MCP clients set to the project.
+
+## Long calls
+
+A blocking call (`ask`, `delegate`, `reply`, `result`) waits up to
+`wait_minutes` (default 25) and then returns "still working" with the lane name;
+the worker keeps going and `result` collects it. While it waits, the server
+sends `notifications/progress` every 15 seconds:
+
+```text
+word-count: working 2m10s · 7 tool calls · now bash 12s
+```
+
+Progress resets the clients' idle timers (Claude Code's 30-minute stdio idle
+timeout, Pi's per-request timeout), and Claude Code shows it under the running
+tool call.
+
+- **Claude Code, main conversation:** a call still running after two minutes
+  moves to a background task on its own; Claude keeps working and is notified
+  when the result lands. A plain `delegate` therefore behaves like a background
+  subagent.
+- **Claude Code subagents and headless runs** block on the call. Headless
+  `claude -p` stops background work ten idle minutes after the main turn ends;
+  set `CLAUDE_CODE_PRINT_BG_WAIT_CEILING_MS=0` for longer unattended runs.
+- **Pi:** `harnex mcp install` registers the server with `exposure: direct`
+  (the tools are declared to the model like built-ins) and a two-hour request
+  timeout.
+- **Cancelling** a call (for example pressing Esc) stops the wait, not the
+  worker; `lanes` and `result` still see it.
+
+Calls run concurrently, so a client can start several `delegate` calls with
+`wait: false` and collect them with one `result`.
+
+## Workers never get harnex's tools
+
+Pi keeps MCP tools even when a worker is limited with `--tools`, so a worker
+started by harnex would otherwise see `delegate` and could start more workers,
+or escape a read-only ask. harnex prevents both: every Pi worker starts with
+`--exclude-tools mcp__harnex__…`, and a read-only ask worker starts with
+`--no-mcp`.
+
+## Other clients
+
+Any client that speaks MCP over stdio can run the server. The command is the
+`harnex` executable with the argument `mcp`. Prefer the absolute path of the
+RubyGems wrapper, `$(ruby -e 'print Gem.bindir')/harnex`, which is what
+`harnex mcp install` registers, so no version-manager shim or working
+directory gets in the way:
+
+```json
+{
+  "mcpServers": {
+    "harnex": { "command": "/path/to/bin/harnex", "args": ["mcp"] }
+  }
+}
+```
+
+The server negotiates MCP protocol revisions 2024-11-05 through 2025-11-25
+and declares only the `tools` capability.
+
+## Troubleshooting
+
+- **The tools don't appear:** restart the client session; check
+  `harnex mcp status` and, for Pi, `pi mcp list`.
+- **A call ends with "still working":** that is the wait limit, not a failure;
+  call `result` with the lane name.
+- **A worker failed on its model:** the footer suggests
+  `reply` with another `model`, which keeps the task.

data/docs/pi-rpc.md

@@ -7,8 +7,8 @@ scraping the TUI:
 harnex run pi  ->  pi --mode rpc  ->  LF-delimited JSON objects on stdio
 ```
 
-Pi RPC is JSONL, not JSON-RPC 2.0. Codex uses `codex app-server` JSON-RPC;
-Harnex presents the same run/send/wait/events control surface over both.
+Pi RPC is JSONL, not JSON-RPC 2.0. Harnex presents the same
+run/send/wait/events control surface over it as over its PTY adapters.
 
 ## Compatibility
 
@@ -35,11 +35,11 @@ with Pi 0.80.4-0.83.x and avoids printing the final message twice on 0.84+.
 ## Dispatch
 
 ```bash
-harnex run pi --id cx-i-42 --tmux cx-i-42 \
+harnex run pi --id pi-i-42 --tmux pi-i-42 \
   --context "Implement issue 42 and run tests" --auto-stop
 
-harnex wait --id cx-i-42 --until task_complete --timeout 3600
-harnex events --id cx-i-42
+harnex wait --id pi-i-42 --until task_complete --timeout 3600
+harnex events --id pi-i-42
 ```
 
 `--context` is sent as an RPC `prompt` command; it is not passed as a Pi
@@ -49,7 +49,7 @@ Harnex model and effort flags are active controls, not telemetry-only labels:
 
 ```bash
 harnex run pi \
-  --model anthropic/claude-sonnet-4-5 --effort high \
+  --model openai/gpt-5.1 --effort high \
   --context "Review the change" --auto-stop
 ```
 
@@ -66,7 +66,7 @@ Pass Pi startup flags after `--`:
 
 ```bash
 harnex run pi --context "Implement X" --auto-stop -- \
-  --no-session --no-extensions --model anthropic/claude-sonnet-4-5
+  --no-session --no-extensions --model openai/gpt-5.1
 ```
 
 When both Harnex `--model` and a Pi child `--model` are supplied, the Harnex
@@ -116,6 +116,55 @@ RPC requests are bounded, stderr is continuously drained into a bounded
 diagnostic tail, and Harnex consumes Open3's wait thread so the real subprocess
 exit status is not lost to a competing `waitpid`.
 
+Persistent workers can be stopped after accepted `agent_settled` completion.
+An explicit idle `harnex stop` preserves the latest accepted/no-change receipt,
+including after a follow-up turn. Expected EOF and TERM teardown are normal
+adapter cleanup, not a lost connection. Harnex reports a logical exit of zero
+for that cleanup; the `process_exited` event retains the raw child exit code
+and signal (TERM yields code 143; Pi may handle it with `process.exit(143)`,
+so signal 15 is only present when the OS reports a signalled exit).
+
+A new prompt invalidates the preceding turn's completion before waiting for its
+RPC response. Stop during that new work fails closed, and late lifecycle events
+cannot promote the interrupted turn or replace the idle-stop decision. Unexpected
+EOF (even exit zero), malformed transport, and abnormal cleanup exits remain
+failures. Output is drained before final receipt/dispatch finalization so trailing
+transport errors are not silently lost. Existing `--auto-stop` settlement remains
+supported.
+
+## Runtime limits and activity
+
+Harnex 0.14.0 adds opt-in `run --max-runtime DUR`, independent of observer
+`watch --max-wait` / `wait --timeout`. Check `doctor --adapter pi` for
+`capabilities.runtime_budget: 1` before enabling it. The fixed monotonic budget
+is armed before child launch and initial prompting, and never resets on retries,
+follow-up prompts, steering, or UI output. Expiry terminates without waiting for
+an abort RPC or completion/output lock, including during startup. Owned worker
+process groups cover their normal descendants; deliberately detached groups are
+not an OS-level containment guarantee. Active work fails with logical run exit
+124; cleanup after accepted idle settlement preserves proof. Shutdown/finalization
+has separate I/O overhead. An earlier stop cannot disable the deadline;
+`runtime_budget.enforced` records actual enforcement separately from stop labels.
+
+Live JSON status separates `activity` work clocks from `log_idle_s`. Pi assistant
+message boundaries and text/thinking/tool-call deltas update model activity;
+`tool_execution_*` updates tool activity. Thinking content is not stored in the
+activity tracker or newly logged. Extension UI/queue/retry events never fake
+model/tool progress. `model_active` describes an observed stream lifetime, not
+hidden provider state; a quiet active stream is not a completed task. PTY clocks
+are unknown. Dispatch-end rows retain the terminal activity snapshot.
+
+The first requested stop records reason/origin/time and work state in a
+`stop_requested` event, JSON status/end metadata, and receipt `observed.stop`.
+The labels are bounded caller declarations, separate from acceptance. Harnex's
+runtime expiry is `runtime_budget`/`runtime`, ordinary stop is `manual`/`cli`,
+and auto-stop is `completion`/`auto_stop`. Expected cancellation EOF is not a
+provider disconnection; unexpected EOF or malformed/unterminated JSONL remains a failure.
+Raw Pi exit evidence is in `process_exited`, before logical normalization.
+
+See `harnex agents-guide monitoring` for clock fields, heartbeat streaming,
+observer deadlines, stop labels, and the full runtime-budget contract.
+
 ## Telemetry
 
 At settlement and teardown, Harnex reads `get_session_stats` and records:
@@ -127,6 +176,31 @@ At settlement and teardown, Harnex reads `get_session_stats` and records:
 - terminal and peak active-context usage.
 
 Message/tool/retry/compaction events are available through `harnex events`.
+
+### Command proof
+
+Built-in `bash` tool calls are command evidence in the observed receipt.
+Harnex correlates `tool_execution_start` and `tool_execution_end` by
+`toolCallId` and records a command only when both structured facts exist:
+non-empty `args.command` text (bounded to 2,000 characters) and an integer
+`result.structuredContent.exit_code`. Status is `completed` or `failed` from
+`isError`; `duration_s` comes from `durationMs`. Command output, including
+`structuredContent.output`, is never persisted.
+
+Pi reports aborts, timeouts, and shell exits without a code as plain error
+text with no `structuredContent`; extensions that replace a result can drop it
+too. Harnex never parses that prose. Such calls, malformed exits, and calls
+still in flight at teardown count in `observed.commands_unobserved`, and
+`command_observation` becomes `partial` (some exits observed) or `unsupported`
+(none). A session with no bash calls reports `observed` with no commands.
+Other tools — read, edit, write, MCP, extension tools — are tool calls, not
+commands. `actual.commands_executed` counts bash calls; `actual.tool_calls` is
+Pi's own reported total, which includes them.
+
+Live verified on Pi 1.2.0 and 1.3.0. Older Pi releases without bash
+`structuredContent` fail closed to `unsupported`. Harnex 0.15.0+ advertises
+this contract as `harnex doctor` `capabilities.pi_command_proof: 1`; check it
+before treating Pi receipt commands as proof.
 Blocking extension dialogs (`select`, `confirm`, `input`, `editor`) are
 currently auto-cancelled so autonomous workers cannot hang. Full extension UI
 mediation is not implemented.

data/docs/upgrading-to-0.29.md

@@ -0,0 +1,87 @@
+# Upgrading to 0.29
+
+harnex 0.29 is the agent release. It adds lanes (`delegate`, `result`,
+`reply`, `land`, `discard`, `lanes`), the `harnex mcp` server and the `gpt`
+subagent for Claude Code. The low-level session commands (`run`, `send`, `wait`,
+`watch`, `stop`, `status`, `pane`, `logs`, `events`) keep working as before.
+
+The last RubyGems release before this one was 0.12.0. If you are upgrading
+from it, read the whole page; from 0.21 on, only the 0.22 section applies.
+
+```bash
+gem install harnex          # 0.29.0
+harnex --version
+harnex doctor               # checks Pi; reports MCP and agent integrations
+harnex mcp install          # optional: native tools for Claude Code and Pi
+pi update                   # harnex needs Pi 0.80.4+; MCP features want 1.0.4+
+```
+
+## Breaking changes
+
+### Codex support was removed (0.20)
+
+harnex now runs Pi workers backed by GPT and other models; Pi's structured RPC
+mode is the worker path that is designed, tested and supported. Removed:
+
+- the `codex` and `codex app-server` adapters and the JSON-RPC session
+  transport;
+- `harnex run --fast` and `--legacy-pty`, and `harnex preflight --legacy-pty`;
+- the Codex checks in `harnex doctor` (it checks Pi; `--adapter pi|all`).
+
+`harnex run codex` is no longer special-cased; it wraps a `codex` binary as a
+generic PTY program. Claude Code, OpenCode and any other terminal CLI still run
+under a PTY as before. Dispatch rows keep their schema; Codex-only fields stay
+`null` in new rows.
+
+### `harnex ask` waits 9 minutes by default (0.22)
+
+`ask` used to wait without a limit. It now stops waiting after 9 minutes (the
+worker keeps going) and exits 124, naming `harnex result ID`, which keeps
+waiting and prints the answer. Pass `--timeout none` for the old behavior.
+`ask --resume ID` still works and no longer needs `--repo`.
+
+### Pi starts with `--no-approve` (0.22)
+
+Pi's RPC mode cannot show its project-trust prompt, so harnex now starts every
+Pi worker with `--no-approve`: project-local Pi resources (`.pi/` extensions,
+skills, prompts) are ignored unless you pass `-- --approve`. Before, the result
+depended on Pi's default.
+
+### Workers never see harnex's own MCP tools (0.25)
+
+When harnex is registered as an MCP server in Pi, every Pi worker harnex
+starts gets `--exclude-tools mcp__harnex__…`, and a read-only ask worker gets
+`--no-mcp`. A worker can no longer start other workers. Your own `--tools`
+and `--exclude-tools` still apply (the exclusions are merged).
+
+## What's new, briefly
+
+- **Lanes** — `delegate` hands a task to a worker (optionally in its own git
+  worktree) and prints its reply with a footer of state, model, cost, commits
+  and next steps. `result` collects parallel lanes, `reply` follows up with the
+  worker's context (a finished lane resumes its Pi session), `land` merges and
+  cleans up, `discard` drops a lane, `lanes` shows what each worker is doing.
+  See [Lanes](lanes.md).
+- **`harnex mcp`** — the same verbs as native MCP tools for Claude Code, Pi and
+  any MCP client, with progress notifications for long calls. See
+  [MCP server](mcp.md).
+- **The `gpt` subagent** for Claude Code, installed by `harnex mcp install`.
+  See [Coding agents](agents.md).
+- **Hygiene** — harnex adds `.harnex/` to the clone's `.git/info/exclude`, so
+  lane worktrees and dispatch rows never show up as untracked work.
+- **`harnex doctor`** reports `integrations` (MCP registrations, the agent)
+  and new capabilities (`lanes`, `mcp`, `ask_resume`).
+- **`wait --since TIME`** ignores events from an earlier launch of a reused
+  session id.
+
+## If something looks different
+
+| You see | Why | Do |
+| --- | --- | --- |
+| `ask` exits 124 after 9 minutes | new default wait | `harnex result ID`, or `--timeout none` |
+| A Pi worker ignores `.pi/` resources | `--no-approve` by default | `harnex run pi ... -- --approve` |
+| `harnex run codex` behaves like a plain PTY program | Codex adapters removed | use Pi workers (`harnex delegate`, `harnex run pi`) |
+| A new `.harnex/` line in `.git/info/exclude` | harnex hides its own state | nothing; it is local to the clone |
+| Workers lack `mcp__harnex__*` tools | recursion guard | intended |
+
+The full history is in the [changelog](../CHANGELOG.md).