harness-dispatch 0.7.9 → 0.9.0

package/CHANGELOG.md

@@ -6,6 +6,1173 @@ pre-1.0, so minor versions can carry behaviour changes.
 
 ## [Unreleased]
 
+## [0.9.0] — 2026-09-02
+
+### Changed (breaking)
+
+- **A config file that defines routes is now authoritative about them.**
+  Auto-detection used to run unconditionally, so a file with `clis:` or
+  `endpoints:` entries ADDED to the installed harnesses rather than replacing
+  them, and only `disabled:` — naming every route, including ones you might
+  not know existed — subtracted.
+
+  That default caught three acceptance passes in a row despite explicit
+  warnings, and caught this project's own test suite: one test dispatched to
+  the real Claude Code CLI on every `npm test` and every CI run, under a
+  comment asserting it could not reach a route. It also decayed — adding
+  support for a new harness would auto-add it to every existing config, so a
+  `disabled:` list written today quietly stopped isolating tomorrow.
+
+  The legacy `services:` format has always behaved this way, so the two shapes
+  now agree rather than this being a new rule.
+
+  **What changes for you.** A config that has a `clis:` or `endpoints:` key
+  gets exactly the routes listed under it — including `clis: []`, which means
+  no CLI routes. Add `detect: true` to keep the old behaviour. A config
+  mentioning NEITHER key — one carrying only `overrides:`, `disabled:` or
+  settings — still auto-detects, because a file cannot be authoritative about
+  routes it does not describe; it now says so in a warning. `detect: false`
+  turns detection off outright.
+
+  Note that `disabled:` and `overrides:` tune AUTO-DETECTION, so they do
+  nothing in a config that lists its own routes — remove the entry instead.
+  The config the README tells you to copy said the opposite of this until it
+  was corrected in the same release; check yours if you wrote it from that.
+
+### Fixed
+
+- **Re-running `configure` after installing a harness no longer needs
+  `--force`.** The natural first-run order — install this tool, configure,
+  find out a harness is needed, install one, configure again — was refused
+  at the last step: "already exists ... --force". And had the first run found
+  anything, the re-run would have loaded that file as authoritative and not
+  detected the new harness at all. `configure` now stamps what it writes
+  with a fingerprint; a re-run that finds its own unedited output regenerates
+  it from a fresh detection, and says so. A file that has been edited, or
+  that configure did not write, is still loaded (so its settings migrate)
+  and still refused without `--force` — and since such a file lists its own
+  routes, `--force` regenerates it from the file, not from a detection. It
+  used to print "Detected N harness routes" there anyway; an acceptance pass
+  measured that line with a second harness on PATH that never appeared. It
+  now says detection did not run and how to merge (`detect: true`). The
+  non-interactive hint at the end of `configure --yes` also told the user to
+  pass `--yes`, which they just had; it now names `connect`. Seen on the
+  cold-install walk.
+
+- **`connect` now registers with a Claude Code that has never been opened.**
+  A client counted as installed only if its config file existed, and Claude
+  Code writes `~/.claude.json` on its first interactive launch — so a user who
+  installed Claude Code and this tool together was told "No MCP clients found
+  on this machine" with `claude` on PATH, handed JSON to paste by hand, and
+  `claude mcp list` stayed empty. A client whose command is on PATH now counts
+  as installed; when its file is missing, `connect` creates it holding only
+  our entry (0600), which Claude Code accepts as a user-scope registration.
+  Doctor's `mcp-clients` line names the installed-but-unregistered client
+  instead of a generic "not registered". Seen on the cold-install walk.
+
+- **`configure` writes its config where every later command can find it.**
+  It wrote `./config.yaml` into whatever directory it was run from, and
+  lookup stopped at the current directory, so a config written from `~` was
+  invisible to `doctor` or `dispatch` run inside a project — "0 configured
+  route(s)", no hint why — while the MCP client, handed the absolute path,
+  saw it fine. The default target is now the state directory
+  (`~/.harness-dispatch/config.yaml`, or under `HARNESS_DISPATCH_STATE_DIR`),
+  lookup falls back to that file after `./config.yaml` (a per-project file
+  still wins), `connect` looks in the same place, and doctor's `config` line
+  names the file it loaded. `--config` and `HARNESS_DISPATCH_CONFIG` are
+  unchanged. Seen on the cold-install walk, where a run from `/` produced
+  `/config.yaml`.
+
+- **`doctor` now notices a Codex that is installed but not logged in.** A
+  ready route meant "the CLI is on PATH", so a never-logged-in Codex passed
+  routes, billing and safety, and the first dispatch failed with a raw OpenAI
+  `401 Unauthorized ... Missing bearer` that never mentioned `codex login`.
+  A new `harness-login` check asks `codex login status` and fails with the
+  command to run when it answers "Not logged in". The CLI is asked rather
+  than its credential file read, because Codex accepts a ChatGPT login or an
+  API key and honours its own home directory, and only its own answer is
+  right in every case. Any answer other than a definite "Not logged in" —
+  an older Codex without the subcommand, a spawn failure — is reported as
+  undetermined and does not fail the install. Codex only: the other
+  harnesses have no equivalent subcommand this tool has verified.
+
+- **The installed command did nothing on Linux and macOS.** `npm install -g`
+  puts `harness-dispatch` on PATH as a symlink to `dist/bin.js`, and node
+  hands that unresolved link path to the program, so a run-if-entrypoint guard
+  that only looked for a filename ending in `bin.js` decided it was being
+  imported, ran nothing, and exited 0. Every documented command — `configure`,
+  `doctor`, `connect`, `dispatch`, even `--help` — printed nothing and reported
+  success on every non-Windows `npm install -g` or `npx` since the first
+  release. Windows was unaffected only because npm's `.cmd` shim passes the
+  real file path. The guard now also accepts an invoked path that resolves to
+  this file. Found by walking the README's three install steps in a clean
+  container, which nothing before had done: every prior walk ran `node
+  dist/bin.js` on this Windows machine.
+
+- **SECURITY: workspace paths are now built and verified rather than checked
+  and trusted.** Four consecutive releases patched a guard that inspected a
+  path STRING and then let every later write re-resolve it, and each patch was
+  found incomplete by the next review: it followed the link it was checking,
+  then covered one of the two isolation policies, then only the last path
+  segment, then stopped one directory short of the one the release notes named
+  — and was silently inert altogether if the workspaces setting had a trailing
+  slash or a `..` in it. Validating once also left the rest of the dispatch
+  trusting the result, so swapping a directory for a link mid-copy redirected
+  it.
+
+  Every directory from the anchor down is now created by this tool with a
+  non-recursive `mkdir`, which cannot traverse a link it did not make, and the
+  verified path is returned and used instead of being re-derived. Destructive
+  operations re-verify immediately before acting. The symlink refusal now
+  applies on Windows too, where junctions need no privileges and were being
+  followed.
+
+  Verified as two separate users on Linux across every shape reported: a link
+  at the workspace root, at the base, at the base's parent, and with the
+  setting spelled with a trailing slash or `..` — all refused, with nothing
+  written into the attacker's directory. Legitimate use is unaffected,
+  including a symlinked temp directory, which is normal on macOS.
+
+- **A delegated "run the tests" task no longer blocks its own route.** The
+  rate-limit phrase check ran against the whole transcript with no filter, so
+  this project's own test output — which names rate limits in test titles —
+  flagged as a real limiter, tripping the breaker for 300 seconds and
+  recording a rate limit that never happened. It is now checked per line and
+  past the same filter the numeric check uses.
+
+- **Real limiter messages that were being missed now register**, including
+  Anthropic's `rate_limit_error` and OpenAI's "You exceeded your current
+  quota" wording. A missed limit is the worse direction: the router keeps
+  hammering a route that has already said stop.
+
+- A metered route that declares it cannot bill you is no longer told to allow
+  paid usage. The previous release put that advice in a branch such a route
+  never reaches, so it worked for local routes only.
+
+- The claims checker now also scans MCP resource descriptions, every
+  route-refusal message, the rendered status body and the CLI's own help text
+  — surfaces a user or agent reads that it could not see.
+
+- **SECURITY: the workspace symlink guard covered one of the two isolation
+  policies.** The previous release applied the `lstat` refusal, the
+  guard-before-prune ordering and the sweep's name check to `copy` only.
+  `git_worktree` kept all three defects, so the identical attack still
+  destroyed data — reproduced as two real users: `copy` refused, `git_worktree`
+  deleted the victim's directory and raised the guard's error afterwards. The
+  entry claiming the class was closed was true for one policy and false for the
+  other. The test shipped with it passed `policy: "copy"` only, so the suite
+  stayed green over a live vulnerability; it now runs against both.
+
+- **The same guard only checked the last path segment.** `<tmp>/harness-dispatch`
+  and `<tmp>/harness-dispatch/workspaces` are fixed names under a
+  world-writable directory and were never examined, so a link planted one or
+  two levels up redirected the whole copy into an attacker's tree. Every
+  segment from the workspaces base down is now checked for links and ownership.
+
+- **A rate-limit regression from the previous release.** The filter added to
+  stop false positives discarded any line containing "should", which threw away
+  real limiter messages — a missed 429 means the router keeps hammering an
+  exhausted route. Two other patterns in that filter could never match at all.
+
+- **A free local route is no longer told it can bill you, with a fix that does
+  nothing.** A route with a declared kind and `paid_usage_possible: false` is
+  blocked when its `billing_confidence` is `unknown` — deliberate — but was
+  shown "route can incur paid usage" beside `paid=no` and advised to set a
+  field it already had. It now names the real cause and a remedy that works.
+
+- The `usage` tool description and README told agents that `service` and
+  `models` are unvalidated. Both throw on an unknown route id. The same wrong
+  sentence was corrected in the plugin skill one release earlier and missed
+  here — `scripts/check-claims.mjs` could not see tool descriptions at all, and
+  now does.
+
+- `scripts/fetch_benchmarks.py` no longer replaces good benchmark data with its
+  bundled fallback when the network fails. It swallowed every exception,
+  returned an empty set, wrote it out and exited 0 — turning a transient outage
+  into a permanent downgrade of the file that ships in the package.
+
+- An env-var reference embedded in a larger value (`base_url:
+  https://${HOST}/v1`) is now stripped from spawned CLI environments. The
+  sanitizer anchored to whole-string matches, so a key inside a longer string
+  stayed visible — the exact leak it was written to close, one string shape
+  over.
+
+- `OPERATIONS.md` described streamed fanout wrongly (its arms DO create jobs,
+  and are not aborted on disconnect), `safety.ts` claimed every shipped harness
+  defines all three safety profiles (`cursor_cli` declares one),
+  `ux-walkthrough.md` called `discard` the only destructive operation (the
+  retention sweep is the one that deleted files), and two module headers said
+  three tools where six are registered.
+
+- **SECURITY: a `copy` dispatch could delete files outside its workspace.**
+  The ownership guard used `stat`, which follows symlinks, so it compared the
+  uid of whatever a link POINTED AT rather than the link's own — and on a
+  shared machine the workspace path is predictable, so another local user can
+  plant one. Worse, the retention sweep that deletes aged workspaces ran
+  BEFORE the guard and had no ownership, marker or name check of its own.
+  Reproduced end to end in a container: a victim's directory chmod'd, the
+  project copied into it, and their files removed. All three now fixed —
+  `lstat` with symlinks refused outright, the guard runs before anything
+  destructive, and the sweep only deletes directories matching the name shape
+  this tool generates. The previous release's entry claiming a foreign-owned
+  root was "refused outright" was false against exactly this attack.
+
+- **Non-ASCII output was being corrupted.** Every stdout chunk was decoded on
+  its own, so a character split across two reads became replacement
+  characters — accented text, CJK, emoji, box-drawing. This is the path every
+  job uses, so it reached partial output, saved logs and delivered results,
+  and was invisible to anyone working in English.
+
+- **An aborted streaming request now stops the run.** Nothing connected the
+  client disconnect to the dispatch, so an abandoned stream ran to completion,
+  spending quota — and being the one path with no job record, it could not be
+  cancelled either. On a CLI route that meant an agent still editing files for
+  a caller that had gone.
+
+- **HTTP fanout with no eligible route now refuses** instead of answering 200
+  with an empty list. CI and cron read 200 as success; the MCP surface already
+  refused the identical request by name.
+
+- A configured `timeout_ms` now covers reading an endpoint's response body,
+  not just its headers — the same defect as the leaderboard timeout fixed last
+  release, in the path the router uses for its primary route.
+
+- Endpoint credentials can no longer leak through streaming error text: undici
+  embeds the request URL, and this branch returned it unscrubbed while its
+  sibling scrubbed it deliberately.
+
+- A rate-limit false positive no longer trips the breaker on text ABOUT a 429
+  — a line number, or a test assertion the delegate ran. One flag blocks a
+  route for 300 seconds and records a limit that never happened.
+
+- Config hot-reload now notices a config whose timestamp moves BACKWARDS
+  (restored from a backup, `cp -p`, extracted from an archive), and documents
+  the two cases where it does nothing at all.
+
+- The MCP snippet `configure` prints is now the entry `connect` actually
+  writes. Pasting the documented snippet then running `connect` was answered
+  "has an entry we did not write" — the tool called its own output
+  hand-edited and refused to update or remove it.
+
+- The chained-context omission notice named the wrong jobs when a job id
+  repeated, listing ones whose output was directly above it.
+
+- **An existing `copy` workspace directory is now actually secured.** The
+  previous release set 0700 with `mkdir`'s `mode` option, which applies only to
+  directories it CREATES — so everyone who had used `copy` before kept a
+  world-readable root holding a full copy of their source, and the entry
+  claiming otherwise was wrong. Measured on Linux: 0755 before, 0755 after. An
+  explicit chmod fixes them. A root owned by ANOTHER user is now refused
+  outright rather than copied into: the path is deterministic inside a shared
+  temp directory, so on the multi-user machine this guard exists for, someone
+  else can create it first.
+
+- **A half-dead leaderboard endpoint no longer hangs every dispatch.** The 8s
+  timeout was cancelled as soon as response headers arrived, leaving the body
+  read unbounded — measured still pending after 15s. Quality scores are awaited
+  per routing candidate, so this stalled routing indefinitely. Off by default,
+  which is why it was not worse.
+
+- **The HTTP server no longer leaks an MCP server per rejected request.** A
+  request carrying an unknown session id is answered 400 without initialising,
+  so nothing ever closed the server built for it in advance — five such
+  requests left five alive until shutdown. Sessions are also expired after 30
+  minutes idle: nothing removed them before except an explicit HTTP DELETE,
+  which the standard client never sends, so a clean shutdown left its session
+  resident forever.
+
+- **`retry_job` on an abandoned job no longer races the original.** Its guard
+  read the derived status while the claim path reads the raw status file, so a
+  supervisor could pick up the original while the retry ran — the exact outcome
+  the command's own error text says it prevents. The original is now marked
+  cancelled.
+
+- **Chained context says what it left out.** Jobs past the character budget
+  were dropped with no header and no note, contradicting the contract stated in
+  the same file. The docblock also claimed oldest entries truncate first, which
+  was never true — the last ones go.
+
+- The `copy` size refusal named the parent of your project rather than the
+  workspace holding the work, and the `force` flag's description still promised
+  an uncommitted-changes refusal that only exists inside a git repository.
+
+- **`configure` no longer deletes `detect: false`.** That key is the only
+  setting that isolates a machine from its installed paid CLIs, and it had no
+  field on the internal config object, so regenerating a file silently dropped
+  it. Measured: `detect: false` plus `max_concurrent_runs: 2` came back as the
+  latter alone, and reloading it with all four harness CLIs present produced
+  four routes on real subscriptions — under a "Wrote" message. A bare
+  `detect: false` regenerated as an empty document, where even the
+  "this config defines no routes" warning is suppressed, because its trigger
+  requires a non-empty file. `detect` now round-trips, and is written only when
+  the file stated it — carrying the resolved value would stamp `detect: true`
+  into every config that merely omitted it.
+
+- **`connect --remove` now removes the entry.** Without `--clients` it printed
+  "our entry is here — will be removed", exited 0, and left the file
+  byte-identical. The chooser filtered out plans whose entry already matches —
+  correct when registering, and exactly backwards when removing, where a
+  matching entry is the one being removed. `--clients` bypassed that function
+  and always worked; the broken form is the one documented in README and
+  OPERATIONS.md. A hand-edited entry is still refused without `--force`, and
+  now exits non-zero rather than reporting success for work it did not do.
+  This command had no test coverage at all; it does now.
+
+- **The test suite can no longer reach a real route.** Test setup already
+  sandboxed the log, state and jobs directories — where the suite WRITES — but
+  not config, which is what it DISCOVERS. A test that loaded config without
+  naming a file or stubbing detection picked up whatever the developer's
+  machine offers. Measured while closing this: on the maintainer's machine
+  that is the repo's own `config.yaml`, yielding four API routes with real
+  keys; on a machine with the CLIs installed it is the harness fleet, on real
+  subscriptions. One boundary test really did dispatch to Claude Code on every
+  CI run once. Setup now pins `HARNESS_DISPATCH_CONFIG` at a `detect: false`
+  sandbox, so an un-stubbed load gets an empty route table; a test wanting
+  routes passes its own path, which still wins.
+
+- **An orphaned job can be cancelled again — when it is still able to run.**
+  There are two kinds: one written to disk when the server exits before a
+  queued job starts (genuinely terminal), and one DERIVED from a stale
+  heartbeat while the file still says `queued`. The second is not inert — a
+  supervisor reclaims it once the dead owner's claim ages out — and `cancel`
+  answered "had already finished; nothing to cancel" about work that could
+  still start, leaving no way to stop it. It now settles the status itself,
+  since an orphaned job has no runner to notice a marker. The written kind
+  still reports nothing to cancel.
+
+- **A `copy` workspace of many files can no longer build an unbounded patch.**
+  The per-file diff was already bounded; the concatenation of those files was
+  not, so files each under the limit still summed past it. Both limits now
+  explain themselves — the worktree path used to surface the cap as
+  `stdout maxBuffer length exceeded`, which says nothing about patches or
+  about the work still being safe on disk.
+
+- **Isolated workspaces are created 0700**, like the state and job
+  directories. A `copy` workspace holds a full copy of your source and the
+  default base is in the shared temp directory, so on a multi-user POSIX
+  machine it was readable by everyone. No effect on Windows.
+
+- **Chained context says which project it came from.** `contextJobs` inlines
+  any job from the machine-wide store with no working-directory scoping, so a
+  job from one project could be pulled into a dispatch for another with
+  nothing indicating it. Disclosed rather than blocked: chaining across
+  projects is legitimate and the caller passes the id explicitly — what was
+  missing is that nobody could see it happen.
+
+- **Dead supervisor heartbeats are swept.** A killed supervisor's file stopped
+  being counted but stayed forever, and the liveness check reads every file on
+  every drain. The sweep is limited to heartbeats: the crash log beside them
+  exists to explain the very supervisor that died.
+
+- `workspace apply`'s description no longer claims a refusal it cannot always
+  make: the uncommitted-changes check needs a git repository. Outside one,
+  only the per-file check applies — a file the patch touches is still
+  refused, unrelated edits cannot be seen.
+
+- A `timeout_ms` or token-cap warning no longer claims routing reads the
+  field. Routing does not; the range branch was fixed for this and the
+  not-a-number branch beside it was not.
+
+- **Usage counters are no longer silently lost when two dispatches finish at
+  once.** `withFileLock` runs its critical section unlocked after a 2s
+  timeout — deliberate, and still right for the circuit breaker, which has
+  nothing to fall back on. It was wrong for the quota counters, which keep a
+  pending delta and clear it only on success: an unserialised write landed,
+  the delta was cleared as though serialised, and the process actually holding
+  the lock then overwrote the file with a value computed before that write
+  existed. Reproduced against the built artifact: five recorded calls gone,
+  no error. The counters now defer instead, and the delta lands on the next
+  result. A busy moment is no longer reported as "counters not reaching
+  disk" — they are delayed, not lost, and saying otherwise makes a working
+  system look broken.
+
+- **A route knocked out by a 429 no longer reports `tripped: true,
+  failures: 0`.** `trip()` set the cooldown without counting the failure, so
+  `usage` — the surface an orchestrator is told to consult before delegating
+  — showed a contradiction that reads as a bookkeeping bug rather than a real
+  trip.
+
+- **Discarding a workspace whose directory is already gone now clears the
+  registration git is still holding.** The early return skipped the block that
+  removes a worktree through git, so a workspace pruned by retention or
+  deleted by hand left `.git/worktrees/<name>` in the user's repo
+  permanently — the exact outcome `discardWorkspace`'s own documentation says
+  it exists to prevent. Reproduced: `git worktree list` still showing the path
+  as `prunable` after discard reported success.
+
+- **An orphaned or cancelled job now hands back its partial work through the
+  tool an orchestrator actually calls.** The progress was on disk and
+  `getAsyncJob` read it, but `job_status` answered `output: ""`: orphaned and
+  cancelled count as terminal, and the poll response attached `partialOutput`
+  only on the NOT-terminal branch. So a commit titled "an orphaned job hands
+  back its progress" was correct in the module it edited and had no effect at
+  the surface a caller touches — verified at the function, not at the tool.
+  The crash path (a `failed` status with no result) was losing its output the
+  same way. The HTTP surface already salvaged this; MCP now matches it, and
+  the answer says the output is PARTIAL so salvage is not read as a result.
+
+- **A gitignored file the agent wrote is no longer reported as applied while
+  being left behind.** Under `git_worktree`, the patch came from `git add -A
+  -N`, which obeys `.gitignore`, while the changed-file list came from a
+  filesystem fingerprint, which does not. A job that wrote a `.env` or any
+  ignored file got `applied: true` naming it, with the file absent from the
+  patch and from the project. It compounded: the already-applied guard needs
+  every recorded change present, so it never fired, and the next apply refused
+  with "changed since dispatch" — blaming the caller for the first apply's own
+  writes, the misleading refusal an earlier fix had removed. The paths already
+  recorded as changed are now force-added, which also makes `git_worktree`
+  agree with `copy`, whose per-file patch always carried them.
+
+- **`clis: []` now isolates a config, which is what the previous release said
+  it did.** Authoritativeness keyed off a NON-EMPTY list, so the most explicit
+  way to write "no CLI routes" still loaded every harness on the machine —
+  the exact failure the change was written for, described in its own comment
+  in the past tense while remaining true. Presence of `clis:`/`endpoints:` is
+  now what makes a config authoritative, empty or not. A config that mentions
+  neither still auto-detects, unchanged.
+
+- **An infinite or NaN route field is no longer accepted, and the warning
+  about it is no longer false.** The new range check covered negative values
+  but not `.inf`, `.nan`, or `1e999` (which YAML types as a string, and
+  `Number()` overflows to `Infinity`). Two paths were wrong: `1e999` produced
+  no warning at all, and `tier: -.inf, weight: .inf` loaded as
+  `-Infinity`/`Infinity` — ahead of every tier, above every score —
+  underneath a warning reading "IGNORED, and the built-in default applies
+  instead". A message asserting the opposite of what happened is worse than
+  the silence it replaced. Warnings also now name the value the operator
+  actually wrote (`JSON.stringify(Infinity)` is `null`, so they reported
+  `tier is null` for a file saying `-.inf`), and explain the right mechanism
+  per field rather than describing routing for `timeout_ms`.
+
+- **`configure` no longer generates a config that fails its own `doctor`.**
+  It carried `disabled:` forward alongside the `clis:` it generates; in an
+  authoritative config that control does nothing, so `doctor` reported it had
+  no effect and exited 1. The disabled route is already absent from the
+  generated list, so the name was saying nothing. It is still emitted for a
+  generated config that lists no routes, where it does the work.
+
+- **A `clis:` or `endpoints:` written as a mapping instead of a list now
+  says so.** The entries vanished, the config counted as defining no routes,
+  detection ran, and someone trying to name their own routes silently got
+  every installed paid harness instead — under a warning claiming their
+  config defined no routes, which contradicted the file in front of them.
+
+- Legacy `services:` configs now get the same top-level key warnings as the
+  modern shape. That path returned before the check ran, so `policy: copy`
+  warned twice in one format and not at all in the other.
+
+- **A negative `tier`, `weight` or `cli_capability` no longer hands a route
+  every dispatch.** These were type-checked but never range-checked, and
+  routing multiplies `weight` and `cli_capability` into the score while
+  ordering `tier` ascending — so a negative pair does not demote a route, it
+  promotes it past every legitimate one. An acceptance pass measured
+  `tier: -5, weight: -100, cli_capability: -3` scoring 299.8 against a normal
+  route's 0.88, from a tier sorting ahead of them all, with no warning
+  anywhere. Out-of-range values are now reported and ignored, so the built-in
+  default applies — the same outcome an unreadable value already got. Upper
+  bounds were deliberately not added: `cli_capability: 1.1` ships in this
+  repo's own default config as real tuning, and the defect is sign, not
+  magnitude.
+
+- Top-level `policy:` and `workspace_policy:` now say they have no effect.
+  Both were allow-listed and read nowhere — and both ARE valid per-route keys,
+  which is what makes the top-level spelling easy to write: it looks like a
+  global default for the per-route setting, and there is no such default. An
+  isolation control that silently does nothing is the failure the config
+  validator exists to prevent. The per-route keys are unaffected.
+
+- An `execute` task can no longer be routed to an HTTP endpoint. An endpoint
+  has no agent loop, no file access and no shell — PRODUCT.md states this as
+  design rather than gap — but an undeclared capability defaults to 1.0 and no
+  endpoint example declares any, so endpoints scored PERFECT for execute. An
+  acceptance pass measured a `--task-type execute` dispatch routed to an
+  endpoint, returning prose with exit 0: execution reported as succeeded when
+  none happened. It surfaced exactly when the CLI routes were busy or tripped,
+  which is the case a caller is least able to check.
+
+  Refused outright rather than scored low, on both counts deliberately: a score
+  of 0 still leaves a route selectable when it is the only candidate — the
+  failing case itself — and a declared capability must not override it, the
+  same rule as the safety-flag check. Endpoints remain full members of the mix
+  for plan, review and second opinions.
+
+- An orphaned job now hands back the progress it saved. When a supervisor dies
+  there is no result, but its output is on disk in `stdout.partial.log` — and
+  the orphan branch returned above the code that reads it, so the response was
+  empty while the trail sat there. Chaining had the same gap, reporting "no
+  result available" for a job whose partial output was recoverable; it now
+  carries that output, labelled INCOMPLETE. PRODUCT.md names losing this trail
+  as the defining failure: "a wasted attempt with no trail".
+
+- HTTP fanout arms are now job-backed, like the MCP surface has always been.
+  They called `routeTo` directly, so an arm's work existed only inside the
+  request — no job directory, no manifest, no partial log. Killing the client
+  or the server mid-fanout lost every arm's output with nothing on disk to
+  salvage, which is the failure PRODUCT.md names as defining, on one of two
+  surfaces.
+
+  The response shape is unchanged: arms are awaited and the same rows are
+  returned, so an OpenAI-compatible client sees exactly what it saw before.
+  Each row additionally carries the arm's `jobId`, which is what makes salvage
+  possible. This was briefly recorded here as deferred "because it changes what
+  a client receives" — that was wrong, and re-reading the MCP path showed why:
+  durability and the response contract are independent.
+
+## [0.8.0] — 2026-08-31
+
+### Added
+
+- `GET /health` — liveness on the HTTP surface, and the only route served
+  without a token. Every endpoint required the bearer token, so a deploy gate
+  or container probe could not ask whether the process was up without being
+  handed a credential, and a health check that needs a secret is one most
+  orchestrators will not perform. It answers `{"status","service","version"}`
+  and nothing else; `/v1/status` keeps the richer answer behind the token.
+
+- `OPERATIONS.md` — the signals worth watching, what there is to alert on (and
+  honestly, that there is nobody to page for a tool that runs on one laptop),
+  the failure modes that have actually happened here, and how to recover from
+  each.
+
+- `harness-dispatch connect` registers this server with the MCP clients on your
+  machine, and `configure --yes` now offers it as the last step of setup instead
+  of printing JSON for you to paste. `connect --remove` takes the entry back out.
+
+  Setting this up was a copy-paste job that nobody owned, and the paths in it
+  later moved. On the maintainer's machine that produced, simultaneously: a
+  Claude Code entry launching a directory renamed away months earlier, a session
+  hook pointing at the same dead path, and a working Cursor entry with no
+  `--config` — so the two clients disagreed about which routes existed while
+  both appeared to work.
+
+  Careful with other applications' files, because this project has already got
+  this wrong once (v0.1.0's setup wrote instructions and a hook; v0.2.0 removed
+  the command and left both behind for seven minor versions). Only the two
+  config shapes actually opened on a real machine are written. Every write is
+  backed up next to the file, merged rather than replaced — other servers and
+  our own entry's `env`, which holds live API keys, are preserved — and swapped
+  in atomically after being parsed back, so a half-written `~/.claude.json` is
+  not a possible outcome. An entry that already exists and differs is shown and
+  left alone unless you say otherwise; that Cursor entry was the working one.
+  Re-running changes nothing. With no terminal and no `--clients`, it reports
+  what it would do and writes nothing rather than prompting into the void.
+
+  `connect --dev` registers the checkout you are running instead of the
+  published package, for anyone developing against this repo. Without it that
+  case is not merely unsupported but actively wrong: on a machine with nothing
+  installed globally, the package form resolves through `npx` to whatever is on
+  the registry, so registering it swaps a checkout that is commits ahead for an
+  older release and reports success. Found by running `connect` on the
+  maintainer's machine, where it correctly declined to do exactly that. The
+  trade — an absolute path breaks silently when the directory moves — is why it
+  is opt-in per run, prints the path before writing it, and leans on the
+  `doctor` check that already fails on a client entry naming a path that has
+  gone.
+
+- The dispatch log records `candidates` — what the picked route beat — so the
+  question the field was added to answer can be asked of a month of history
+  rather than one response. It recorded `reason` ("tier 1 best (3 available)")
+  and never what the choice was between, so the log could show the router had
+  been used and not whether it chose well.
+- `doctor` fails when an MCP client on this machine is configured to launch
+  this server from a path that does not exist.
+
+  That failure is invisible from both ends: a client which cannot spawn its
+  server simply has no tools, which looks exactly like never having installed
+  one, and the server never runs so it cannot complain. On the maintainer's
+  machine Claude Code spent months launching a `dist/bin.js` under a directory
+  that had been renamed away, alongside a session hook pointing at the same
+  dead path. Neither said anything, and the tool had no way to notice because
+  nothing looked.
+
+  Read-only — it inspects Claude Code's and Cursor's config and never writes to
+  them. Not being registered with any client is fine and reported as such; only
+  a path that is genuinely absent fails. A bare command like `npx` is not
+  checked, because resolving it means replicating PATH and shim lookup, and
+  getting that wrong would report working installs as broken.
+
+- `harness-dispatch dispatch "<prompt>"` — one routed task from the command
+  line, with `--service`, `--safety`, `--task-type`, `--no-fallback` and
+  `--json`. `route` still works; it is the same command under the name the MCP
+  tool already uses.
+
+  It existed as `route` and had no flags, which made it unusable for the job it
+  is most needed for: an acceptance pass has to exercise the build in the
+  working tree, and the MCP tool runs in whatever server process is already
+  connected — a different artifact from a different moment. Meanwhile `route`
+  hardcoded `execute` with two fallbacks, so asking for one read-only call on
+  one route could get an execute-profile run on up to three. A typo'd
+  `--safety` is refused by name rather than dropped to a default, which would
+  hand the delegate more access than was asked for.
+
+### Changed
+
+- Cursor dispatches send the prompt on STDIN too — the route the ceiling
+  actually broke. It is a `cursor-agent.CMD` wrapper, so cmd.exe caps its
+  command line, and a 9,031-character prompt once died with the bare "The
+  command line is too long." that the check exists to replace. A
+  13,554-character prompt now dispatches and answers. Antigravity stays on argv:
+  `agy --print` requires an inline argument and its only stdin path needs a
+  different output parser, so the length machinery still has one route to
+  protect.
+- Claude Code dispatches send the prompt on STDIN instead of in the command
+  line. Every command-line defect this project has fixed — replicating
+  cross-spawn escaping, the 8,191-character cmd.exe ceiling, the npm-shim
+  double-escape, a refusal band that was too tight and then too loose — applies
+  only to routes that pass the prompt as an argument, and this was one of three
+  that did. Codex has always used stdin. A 21,670-character prompt — 2.65x the
+  8,191-character ceiling — refused outright by the old form, now dispatches and
+  answers.
+
+### Fixed
+
+- The CLI no longer aborts with exit 127 after printing a correct answer. A
+  routed fallback — the first route answering but unusably, the second
+  succeeding — ended in a libuv assertion on Windows and an exit status every
+  shell reads as "command not found". The work was done and the report of it
+  was a crash. Three acceptance passes reproduced it 3/3 and it was the oldest
+  confirmed defect here; the cause was tearing the event loop down with
+  `process.exit()` while two HTTP connections were still closing. Verified at
+  the built binary: 127 with the assertion on all three runs before, 0 with
+  none on all three after.
+
+- `base_url` values with a path of their own are no longer mangled. `/v1` was
+  appended to anything not already ending in it, so this project's own
+  documented `https://generativelanguage.googleapis.com/v1beta/openai` became
+  `/v1beta/openai/v1/chat/completions`, which Google does not serve, and an
+  `anthropic_messages` host on a non-`/v1` path was unconfigurable. A bare
+  origin still gets `/v1`; a path you supplied is now used as you wrote it.
+
+- `configure` writes `config.yaml` with 0600. It can contain a literal
+  `api_key` — `configure` deliberately preserves one rather than replacing it
+  with a `${VAR}` reference — and it was written with default permissions,
+  0644 under a typical umask, in a module family that is careful everywhere
+  else. POSIX only; Windows ignores the mode.
+
+- Usage counters that cannot reach disk now say so. The in-process view kept
+  serving the numbers it had accumulated, so nothing looked wrong until the
+  next restart showed every count at zero, with `usage` reporting them as fact
+  in between. Reported under `status`'s "State problems", never thrown: a
+  dispatch that produced a real answer must not fail over a counter.
+
+- `doctor` reports unreadable saved state. It read the config warnings
+  directly, so a corrupt breaker record or unwritable usage counters were
+  invisible to it — eleven green checks over state it could not read. `status`
+  grew a heading for this and `doctor` had not followed.
+
+- Two messages that reached the right conclusion by the wrong description: a
+  route blocked because its billing CONFIDENCE is unknown was told "billing
+  source is unknown", for a route `status` prints as `billing=metered_api`;
+  and `doctor` described a dead `--config` path as somewhere the client
+  "launches from".
+
+- The test suite no longer dispatches to your real subscription harnesses.
+  Config entries are additive, so a test config declaring empty CLI and
+  endpoint lists did NOT isolate it from the harnesses installed on the
+  machine — and one boundary test reached the real Claude Code CLI on every
+  `npm test`, every `npm run check` and every CI run, spending quota to prove a
+  schema check. An acceptance pass measured it: 6.4 seconds, 47k input tokens.
+  The test carried a comment asserting the opposite, which nobody had checked.
+  Verified fixed by measurement rather than by reading — the dispatch log stood
+  at 425 lines before a full run and 425 after.
+
+- A mistyped safety setting no longer gets you MORE access than you asked for.
+  `safteyProfile: "read_only"` at the top level of an MCP call was accepted in
+  silence and the dispatch then ran at the `workspace_edit` default — an
+  acceptance pass measured it writing a file into the project. The HTTP surface
+  had refused the same input all along, so one input got two opposite answers.
+
+  It could not be fixed in the schema: the MCP SDK validates arguments before
+  any handler runs and discards unknown keys, so nothing downstream could see
+  what was sent. `hints` is strict, which is why the nested form was always
+  caught; the outer object cannot be, because MCP carries its own `_meta`
+  there. The fix wraps the SDK's tool-call handler and inspects the raw
+  arguments before delegating, leaving routing, validation and progress
+  reporting untouched. Both surfaces now run one shared check, and the parity
+  suite asserts it on both rather than recording the difference as deliberate.
+
+  The refusal says WHERE the key belongs, per key and per surface, because the
+  two differ: the HTTP surface reads all seven hint names from the top level of
+  the request, while on MCP only two are top-level and the rest go inside
+  `hints`. A single "did you mean X?" sent the caller to a second rejection -
+  the same failure this project already recorded from its snake_case traps, "a
+  refusal that confidently points at the wrong landing spot costs the round
+  trip it exists to save". On the five tools that take no hints at all the
+  message says so, rather than warning about access it cannot grant.
+
+- An endpoint credential embedded in `base_url` no longer reaches the terminal
+  or `logs/dispatches.jsonl` through an error message. The redaction only ever
+  cleaned URLs this code assembles; Node embeds the URL it was handed inside
+  its OWN exception text, which was then passed through verbatim with a
+  redacted URL appended beside it — the two forms side by side, under a comment
+  promising the result was safe to paste into a bug report. Userinfo, query
+  values and the host are now removed from wrapped messages too.
+
+- Applying the same `git_worktree` job twice now says "already applied"
+  instead of accusing you of a conflict with your own apply. That answer lived
+  only on the empty-patch path, which a worktree patch never reaches — it is
+  `git diff <baseCommit>` inside the worktree, so it does not empty out the way
+  a rebuilt `copy` patch does. The second apply fell through to the conflict
+  check, which saw the file differ from its recorded base (the difference the
+  first apply had just made) and pointed the user at `force: true`. The
+  walkthrough says both policies answer "already applied"; only one did.
+
+  The refusal message also claimed "unlike a worktree patch there is no common
+  commit for git to merge against" — while refusing a worktree patch, which
+  has one. That clause now appears only for `copy`, which it describes.
+
+- `workspace apply` no longer refuses on a clean tree when the dispatch ran in
+  a SUBDIRECTORY and `HARNESS_DISPATCH_WORKSPACES_DIR` points inside the
+  project. `git status` prints repository-root-relative paths; they were being
+  resolved against the dispatch directory, so the workspaces folder failed to
+  match and read as your uncommitted work. The same defect fixed at the repo
+  root a day earlier, surviving one level down.
+
+- A `git_worktree` dispatch now explains the three ordinary ways it cannot
+  start — no git on PATH, not a git repository, no commits yet — instead of
+  handing back raw git internals with no route taken. A freshly initialised
+  project is a normal state, not an error.
+
+- The streaming HTTP surface no longer emits an SSE `error` frame for a route
+  failure that a fallback then recovers. The frame was written the moment a
+  route failed, before the next route had been tried, so a request that
+  SUCCEEDED still carried an error ahead of its own answer. The OpenAI
+  streaming contract has no non-fatal error frame, so a client treating one as
+  terminal reported a failure for a request that worked. The frame is now held
+  and sent only if nothing succeeds.
+
+- A route reporting only `remaining` in its rate-limit headers no longer wipes
+  the limit already known for it. Both fields were assigned under a guard that
+  only asks whether EITHER arrived, so a partial update nulled the limit — and
+  with no limit there is no ratio, so the quota score went back to a full
+  1.0. A route with two requests left scored the same as an untouched one, and
+  the router preferred it. Headers are a partial update, not a replacement.
+
+- An unreadable `quota_state.json` is now moved aside rather than replaced.
+  "No file yet" and "a file I could not read" both produced an empty map, and
+  the caller applies its delta to that and writes the result back — so a single
+  bad read did not merely stop counting, it REPLACED every route's history.
+  Measured: two routes at 5 and 3 calls became one route at 1, with `usage`
+  reporting that as fact. Counters are informational, so this does not try to
+  recover them; it declines to be the thing that destroys them.
+
+- A fanout where NO route can run now errors instead of answering
+  `completed: true` with an empty results array. `completed` is `every()` over
+  the arms, so zero arms was vacuously true, on the field the tool description
+  tells agents to branch on. An unknown route NAME already errored, so the same
+  mistake produced two opposite shapes depending on whether the route named
+  happened to exist and be disabled. The error names each route and why.
+
+- `connect` no longer rewrites a client config whose shape it does not
+  understand — at any level, not just the outermost one. "Does it parse" and
+  "is it the shape I am about to merge into" are different questions and only
+  the first was asked, so an array-rooted file came back as
+  `{"0":…,"1":…,"mcpServers":{…}}` with success reported.
+
+  The first version of this fix guarded the JSON root alone, and an acceptance
+  pass the next day found `{"mcpServers":"oops"}` still having its string
+  rekeyed the same way — the same defect one level down. The question is now
+  asked wherever this spreads: the root, the servers map, and our own existing
+  entry. A backup was always taken, so both were recoverable, but this writes
+  another application's config, which is the highest-consequence thing here.
+
+- `workspace apply` no longer overwrites a file you wrote and committed
+  yourself, when the agent CREATED a file at the same path. The conflict check
+  compares each touched file against how it looked when the dispatch started;
+  an added file has no such record, because it did not exist — and every change
+  without one was skipped, so the protection was simply absent for the change
+  kind that creates new files. Its ABSENCE is the base: if the path is there
+  now, the project gained it. This is verbatim the failure the check was added
+  for, live for one of the three change kinds, and committing your work is what
+  the dirty-tree refusal tells you to do. `force: true` still overrides.
+
+- A route can no longer claim a safety profile it has no flags for by pinning
+  `effective_safety`. The pin returned before the flag check ever ran, so a
+  route declaring `effective_safety: read_only` while defining flags for only
+  `workspace_edit` launched its harness with no safety argument at all, reported
+  `read_only` everywhere including the audit log, and wrote a file into the
+  project under a read-only dispatch. The flag check now runs first — nothing
+  declared can conjure a flag that does not exist. A pin is still honoured for a
+  route that is not flag-controlled at all, which is the case it exists for. The
+  shipped harnesses are unaffected. Found by an acceptance pass, which also
+  found the test pinning the old behaviour describing a fixture it did not have.
+
+- A `copy` workspace now SAYS which directories it left out. `bin`, `dist`,
+  `build`, `target`, `obj` and `.venv` are excluded by name as build output —
+  and are real source directories in some projects. The omission was invisible
+  on every surface: the agent reasoned from an incomplete tree, and a change to
+  an excluded file could not appear in the patch or the changed-file count.
+
+- `workspace apply` no longer refuses on a clean tree when
+  `HARNESS_DISPATCH_WORKSPACES_DIR` points inside the project — the
+  configuration README recommends, for reflinks. Only the legacy hard-coded
+  `.harness-dispatch` name was filtered from the dirty check, so the configured
+  workspaces root read as your uncommitted work and blocked every apply.
+
+- A failed config hot-reload now reaches `status`, under a `State problems`
+  heading, instead of only stderr — which no MCP client and no HTTP caller ever
+  sees. The comment at that code described the bug as "nothing on stderr and
+  nothing in status" while closing only the first half. Breaker warnings moved
+  to the same heading: they were filed under config warnings, which says "these
+  change behaviour" and means ignored config entries.
+
+- `workspace` operations with `git` missing from PATH now say that, instead of
+  `spawn git ENOENT`.
+
+- `safeEqual` in the HTTP auth path did its length-mismatch comparison against
+  the caller-supplied buffer, so the work scaled with a length an attacker
+  chose while the comment claimed the opposite. Not reproduced as an
+  exploitable signal, and the result was always correct.
+
+- An endpoint that answers HTTP 200 without an answer is now a failure on both
+  request paths, not a successful empty answer. A success heals the circuit
+  breaker, so a route serving nothing but empty 200s was recorded as healthy
+  indefinitely and never tripped.
+
+  The streaming path — the only one `dispatch` and `job_status` ever take, so
+  the surface an orchestrating agent branches on — reported `success: true`
+  with an empty output for a body carrying no content at all. The buffered path
+  (what the CLI uses) refused that one, but accepted a well-formed response
+  whose `content` was the empty string, returning success with nothing in it.
+  Both now refuse both, which is what makes the two surfaces agree; an earlier
+  entry here claimed the buffered path already refused empty answers, and that
+  was wrong.
+
+  Both paths now answer the same two questions in the same order, in one
+  shared function so that the agreement is enforced rather than asserted: was
+  the body readable, and did any bytes arrive? A read that FAILED is reported
+  as a failed read — saying "no body" there would be a claim about what the
+  server sent, and a reset connection is not evidence of it. Otherwise the
+  body is quoted if one arrived, and reported as absent if not. The dispatcher
+  does not try to work out WHY a response was unusable.
+
+  Two earlier versions did try, and each was wrong in ways only an acceptance
+  pass found. The first called anything that produced no text "no content", so
+  an HTML error page, plain prose and a gateway that ignored `stream: true`
+  were all described as empty. The second tested whether the body looked like
+  SSE, and got three more cases backwards: a stream in a dialect the route was
+  not configured for had its real answer thrown away and called empty; SSE
+  comment keepalives — which a real provider sends while thinking — were
+  called an unexpected shape; and an HTML page containing any `data:` line was
+  called empty. Worse, the same body was described two different ways
+  depending on how the network happened to split it.
+
+  A well-formed but empty stream now quotes its own terminator instead of
+  being described in nicer words. The message says only that no answer came
+  out of the body and shows what did arrive; it does not call the shape
+  unexpected, because a stream that carried nothing had exactly the expected
+  shape.
+
+  Reproduced by acceptance passes.
+
+- A corrupt circuit-breaker record is now reported as unknown state instead of
+  rendering as a healthy route. `status` said `breaker=closed failures=0` — an
+  assertion the process had no basis for — and a single bad file therefore
+  un-tripped a live cooldown in silence, which is the exact failure this
+  persistence layer was added to prevent.
+
+  Rather than enumerate the ways a record can be corrupt — a list acceptance
+  passes kept finding entries missing from — this checks the invariant the
+  module already holds: a healthy route has NO file, because a healthy save
+  deletes one. So a file that reads back fully healthy is a contradiction, and
+  that catches the `[]`, `{}` and foreign-schema records a list of type checks
+  had missed, without having to name them.
+
+  It does NOT catch everything, and an earlier version of this entry claimed
+  it did. A record carrying a *deadline* is not fully healthy, so the
+  invariant never looks at it — leaving a nonsense deadline to read as a
+  normal route. Deadlines are now checked against what the code can actually
+  produce: `snapshot()` emits `null` or `Date.now() + remaining`, capped at
+  `MAX_COOLDOWN_SEC`, so zero, negative and far-future values were never
+  written here. That last one matters most — an unchecked far-future deadline
+  would have blocked a route for years rather than merely un-blocking it.
+
+  What remains, stated rather than papered over: a corrupt deadline that
+  happens to look plausible is indistinguishable from a real cooldown that
+  has simply expired, because nothing rewrites the file until the route's next
+  event. Type checks remain for a wrong-typed field on a record that is
+  otherwise not-healthy. A field that is simply ABSENT is still tolerated,
+  because older builds wrote fewer of them.
+
+  The same validation runs on the pre-split `breaker_state.json` read during
+  an upgrade, which had none of it: a bad entry there was coerced to healthy,
+  skipped as nothing-to-migrate, and the file deleted — so upgrading, the
+  moment a live cooldown is most likely to be sitting on disk, destroyed it
+  silently. The per-route "healthy is a contradiction" rule cannot apply
+  there, because the old format wrote healthy entries legitimately, so the
+  shared validator gained a floor instead: a record naming none of the fields
+  it understands is not one it understands. Without that floor, `{}` and a
+  foreign schema — including the snake_case shape of the Python implementation
+  this was ported from — still passed and were still destroyed.
+
+  A blob is now rewritten with only the entries this could not consume, so
+  each entry is read exactly once and the file disappears on a clean upgrade.
+  Keeping the WHOLE blob whenever one entry was bad meant the good entries
+  were replayed on every read, forever — recreating a per-route record after
+  the route had recovered and its record was deleted, leaving it one failure
+  from tripping and unable to heal.
+
+  An unreadable record whose name is not a configured route (every corrupt
+  blob, since it has no route name) is reported under its own `status`
+  heading, separate from config warnings — nothing here was misconfigured or
+  ignored, and `doctor` and the CLI's "ignored config entries" list both read
+  the config warnings directly.
+
+  The lost count cannot be recovered and this does not guess at it — failing
+  closed would strand a route until someone deleted a file by hand. `status`
+  says the saved state was unreadable and may be stale, in the text output and
+  as `breaker.stateUnreadable` in the JSON. `doctor` does not report it.
+
+- Workspace reclamation no longer deletes directories it did not create. The
+  sweep added earlier in this cycle judged a directory by age alone, so pointed
+  at a shared `HARNESS_DISPATCH_WORKSPACES_DIR` it would recursively delete
+  anything sitting there untouched for a day. That override is not an obscure
+  escape hatch — the README recommends it — and nothing said the directory
+  would become this tool's exclusively. An acceptance pass reproduced the loss
+  against the built artifact: two unrelated directories with real content
+  destroyed by a single dispatch. Default installs were never affected, since
+  the default base is dedicated.
+
+  A directory is now reclaimed only if it carries a marker file this tool
+  writes into every root it creates. The first attempt matched the generated
+  NAME shape instead, `-[0-9a-f]{8}$` — and eight decimal digits are valid hex,
+  so every `<name>-<YYYYMMDD>` still matched: a second acceptance pass planted
+  `backup-20260401` beside the directories that now survived and watched one
+  dispatch delete it recursively. A heuristic cannot answer "did I create
+  this". Roots made before the marker existed are still reclaimed, but only
+  when every child is a generated run directory and there is at least one, so
+  the earlier disk leak does not return through the back door.
+
+  The original test passed only because its fixture happened to be named
+  `gone-project-deadbeef`, matching that shape by accident. It now has two
+  companions that must survive: an ordinary directory, and one named to
+  collide with the shape check that failed.
+
+- Endpoint redaction actually redacts. `redactEndpointHost` replaced the
+  hostname by assigning to `url.hostname`, and the WHATWG URL setter silently
+  rejects a value containing `<` and `>` — so it returned its input verbatim,
+  every time, while three call sites presented the result as scrubbed (one
+  commented "safe to paste into a bug report"). An acceptance pass measured a
+  failed dispatch reporting `https://api.secret-internal.example.com/v1?key=…`
+  into both the error and the dispatch log. Userinfo, query and fragment are
+  now dropped on every path including loopback, since a key embedded in a URL
+  is a credential wherever the host points. It shipped inert because nothing
+  tested it; it has tests now.
+
+- `auth rotate` invalidates the old token for a running server. The token was
+  read once at startup and held, so rotation was a lie in both directions: the
+  old token kept returning 200 and the newly issued one was refused with 401 —
+  measured. Invalidating the old value is the only reason anyone rotates a
+  credential. The token file is re-read when its mtime moves, so the common
+  path stays a stat.
+
+- `connect` will not replace a client entry you edited by hand without your
+  say-so. `connect --remove` always refused this; `connect` did not, so the
+  protection existed on the half where the cost is lower — and `OPERATIONS.md`
+  promised it for both. Running `connect` with no `--clients` shows the
+  difference and asks; `--force` overrides. Naming a client is not consent to
+  overwrite what is there.
+
+- A job stranded in the slot queue by a server that exited is reported as
+  orphaned instead of reading `queued` forever. Slot-queued jobs are exempt
+  from orphan detection because nothing heartbeats for them, and the only
+  things that drained the queue were a runner exiting or a new dispatch
+  arriving. Reported, deliberately, rather than resumed: resuming was tried
+  first and an acceptance pass demonstrated the cost — kill a server with a job
+  queued, restart, and it runs to completion in its original working directory
+  at up to `full_auto`, unattended, bounded only by the 7-day retention window.
+  `retry_job` re-runs it as a decision.
+
+  Only when no supervisor is alive to run it. The first version of this reasoned
+  that a starting server means any queued job belongs to a dead session — false
+  in the configuration this ships by default, where `connect` registers Claude
+  Code and Cursor and `serve` is a third, all sharing one jobs root. Measured:
+  with one server live and holding a legitimately queued job, starting a second
+  marked it orphaned within a second and removed it from the drain queue,
+  killing live work with an error stating a cause that was not true.
+
+- A streamed request stops rather than falling back once any answer text has
+  been sent. It fell back anyway and then discarded what the fallback produced:
+  an acceptance pass measured an endpoint streaming `he`, `llo `, dying, and the
+  fallback route succeeding with 49 characters the client never saw — produced,
+  charged for, thrown away. A fresh answer cannot be spliced onto a half-sent
+  one without garbling it, so the client now gets a truthful error and no second
+  route is billed. Falling back before anything is sent still happens, which is
+  the case fallback exists for.
+
+- `git_worktree` no longer leaves a worktree registered in your repository when
+  an attempt failed without changing anything. Retention deliberately never
+  removes worktrees — unregistering one needs git, and only the owning repo can
+  do it — so they accumulated per attempt, and a failed FALLBACK arm is not
+  named in the response at all, so its worktree had no cleanup hint anywhere.
+  Measured: one HTTP request leaving two entries in `git worktree list`. A
+  failure that DID change files is still kept, because it may hold work worth
+  recovering.
+
+- `connect --yes` no longer overwrites a hand-edited client entry. The consent
+  gate added for `--clients` treated "no client named" as consent, and `--yes`
+  takes that path — so the flag that skips the question was accepted as an
+  answer to it. Consent is answering the prompt, or `--force`.
+
+- Streaming returns the ANSWER, not the harness's protocol. `POST
+  /v1/chat/completions` with `stream: true` forwarded every stdout chunk into
+  `delta.content`, so a client concatenating deltas from a CLI harness received
+  `{"type":"thread.started",...}` and internal thread ids — while the
+  non-streaming call on the same endpoint returned the parsed result. One
+  endpoint, two answers, and the streaming one was unusable by the clients the
+  OpenAI envelope exists for. An endpoint route still streams its text as it
+  arrives; a CLI harness sends its answer once, at completion.
+
+  Streaming still creates no job record, so there is no `jobId` and an
+  interrupted stream cannot be recovered. Now stated in the README and
+  OPERATIONS rather than left to be discovered.
+
+- The HTTP surface refuses a bare `safety` key instead of dropping it. This
+  product's own CLI flag is `--safety`, so it is the most plausible slip anyone
+  will make — and at seven edits from `safetyProfile` the near-miss rule
+  correctly declines to guess, which left it accepted and silently ignored while
+  the dispatch ran at the default profile.
+
+- `models: []` is refused instead of fanning out to every route. An explicit
+  empty array fell through to the same branch as omitting the field, so a
+  caller whose filter matched nothing got one dispatch per configured route —
+  eight arms where an acceptance pass measured it. Omitting `models` is still
+  how you ask for that, and it stays a deliberate keystroke.
+
+- Job retention no longer deletes directories this tool never created. The
+  sweep removed every stale directory under the jobs root recursively, with no
+  check of any kind — the same defect workspace reclamation shipped twice in
+  this release, found by an acceptance pass in the one place nobody had looked.
+  Pointed at a directory holding `backup-20260401` and `my-notes`, it destroyed
+  both. Only `job-<timestamp>-<8 hex>` directories are eligible now. Narrower
+  in practice than the workspace case — neither `HARNESS_DISPATCH_JOBS_DIR` nor
+  `HARNESS_DISPATCH_STATE_DIR` is documented in the README, unlike the
+  workspaces override — but "narrower" is not a property anyone can rely on.
+
+- `workingDir` must be an absolute path. A relative one was resolved against
+  the SERVER's working directory rather than the caller's — and `../..` exists,
+  so every check passed and a real dispatch ran somewhere neither party chose.
+  The omitted-value warning could not fire either, since the value was not
+  omitted. The caller and the server are different processes with different
+  working directories, so there is no correct relative value to accept.
+
+- The HTTP surface rejects a top-level key that is nearly a hint name, instead
+  of accepting and dropping it. The outer body cannot be strict — it carries
+  OpenAI's own fields — so `safteyProfile` (a transposition) and hints wrapped
+  in `harness_dispatch` (the key this endpoint uses in its own *responses*, so
+  the natural wrong guess) both returned HTTP 200 and dispatched at the default
+  `workspace_edit`: more access than the caller asked for, with no signal,
+  while the correct spelling produced `read_only`. Now refused by name with the
+  intended spelling. One typo apart, transpositions included; unrelated keys
+  and every OpenAI field stay legitimate.
+
+- A CLI route asked for a safety profile its protocol has no flags for is now
+  refused instead of run unconstrained. `{{safety}}` expands to the protocol's
+  arguments for the requested profile and to nothing when the profile is
+  missing, so a user-added route defining `workspace_edit` and `full_auto` but
+  not `read_only` launched the harness with NO safety arguments — and every
+  surface said `read_only`, including the dispatch log. An acceptance pass
+  measured the child's argv: just the prompt. A route that cannot show it
+  constrains anything is now treated as constraining nothing, which makes the
+  existing compatibility check refuse it. The shipped harnesses are unaffected;
+  they define all three profiles or pin the gaps with `effective_safety`.
+
+- `status --json` and the `harness-dispatch://status.json` MCP resource no
+  longer emit a route's `base_url` verbatim. Credentials embedded in the URL —
+  `?key=…`, which is Google AI Studio's own shape — reached both, and that
+  resource is one this server's instructions tell agents to read, so the
+  credential landed in an agent's context. The text rendering was always
+  redacted, which is how it hid. `redactEndpointHost` is also idempotent now:
+  applying it twice used to be worse than once, degrading the model-discovery
+  hint to a bare placeholder.
+
+- `overrides:` gets the same value and unknown-key checks as the route blocks.
+  It was left out when they were added, and it is the block most likely to carry
+  the fields they exist for — the shipped config presents `overrides:` as the
+  way to adjust `tier` and `weight` without writing a full config.
+
+- A recognised config key carrying the wrong TYPE of value now says so instead
+  of silently taking the default. The unknown-key warning covered a misspelled
+  key; it never covered a correctly-spelled one whose value cannot be read,
+  because the key is not unknown — `coercions.ts` drops on mismatch and the
+  caller supplies a default. Found live on the maintainer's own machine by an
+  acceptance pass: four routes carrying `tier: metered`, which is not a number,
+  silently running at the default tier 3, with nothing ever having said so.
+  `weight: very-high` becomes 1.0 the same way, and both feed routing.
+
+- A route name declared twice now warns that everything the earlier entry set is
+  discarded. Measured: a first entry setting `safety_profile: read_only` and
+  `workspace_policy: copy`, replaced wholesale by a second with neither, left
+  the surviving route running `workspace_edit` / `shared_locked` — silently
+  LESS restrictive than what was written, with no warning on any surface.
+
+- `services:` written as a YAML list no longer fails silently. It must be a map
+  of route id to settings, but `typeof [] === "object"`, so a list slipped
+  through and became routes called `0`, `1`, … with each item's `name:`
+  ignored. Nothing looked wrong — `doctor` reported the routes and `status`
+  listed them — until `--service my_route` answered "Unknown service". The
+  mistake is a natural one: the sibling keys `clis:` and `endpoints:` ARE lists
+  whose items carry `name:`. The behaviour is unchanged; it now says what
+  happened, what the ids became, which names were dropped, and how to write it.
+
+- `connect` keeps the last three backups of a client config rather than one per
+  run forever. Every write and every removal takes one, and `~/.claude.json`
+  holds live API keys, so the old behaviour accumulated copies of someone's
+  secrets with nothing to prune them. They are bounded rather than deleted by
+  `--remove`: undoing a registration is the worst moment to destroy the record
+  of what it replaced. Backups anyone else made are not touched.
+
+- Retrying a job on a DIFFERENT route no longer carries the old route's model,
+  which defeated the one thing retargeting exists for. A model name belongs to
+  the route it was picked for, so reusing it verbatim made the retry fail for
+  the same reason as the original: observed end to end, a Cursor run that died
+  on `Cannot use this model` was retried onto Claude and died on
+  `unrecognized_model`, never reaching the task. That same job now completes.
+
+  Narrow, and reported rather than silent. The model is kept when the retry
+  stays on the original route (a plain "try that again") and when the new route
+  declares it anyway; only a model the destination does not know is left
+  behind, and the response says so as `droppedModel`.
+
+- Workspaces belonging to projects that never dispatch again are reclaimed.
+  Retention only ever swept inside one project's own directory, and only when
+  that project dispatched again — so a project renamed, deleted, or created as
+  a throwaway temp directory kept its workspaces forever, because the code that
+  would reclaim them was reachable only from a project that no longer existed.
+  Measured on the maintainer's machine: 840 project directories, 839 of them
+  still holding runs five days past a 24-hour window. This project has already
+  lost a disk to leaked scratch directories once.
+
+  Conservative by construction: a project directory is removed only when every
+  run inside it is past retention, never the caller's own, and never one
+  holding a git worktree — those need git's own removal, which only the owning
+  repository can do.
+
+- `taskType: "local"` now actually reaches a local endpoint. It could not: the
+  preference was a score bonus, a bonus only reorders routes within a tier, and
+  local endpoints sit in the cheap tier — so any healthy top-tier route won
+  before the bonus was ever consulted. Measured on a real config, every task
+  type including `local` resolved to the same top-tier CLI, and a configured
+  local box had zero calls in a month. It is a cross-tier selection rule now,
+  and the only one: tier gating still stops plan and review work drifting onto
+  a weaker route, because those task types are about capability and this one is
+  explicitly not.
+- "Local" means one thing again, and it is what a route DECLARES — provider,
+  surface, auth source, billing kind — exactly as `routePolicy: "local_only"`
+  has always decided it. `taskType: "local"` used its own narrower test of a
+  loopback URL, so a real box on a LAN or tailnet address was local enough to
+  be the only thing `local_only` would run, and not local enough for the task
+  type named after it.
+
+  A URL shape no longer overrides a declaration. Briefly it did both, and that
+  was worse: a metered proxy on 127.0.0.1 — LiteLLM, OpenRouter, anything
+  fronting a paid API — declares itself metered, and the loopback check
+  overruled it, so the one task type meaning "free local endpoint" preferred
+  the PAID route over a free subscription CLI. Nothing was lost by removing it:
+  a local box that declares the fields is already covered, one declaring
+  nothing on a known runtime port is inferred local from the port, and one on
+  any other port never reaches candidacy at all.
+
 ## [0.7.9] — 2026-08-28
 
 **Upgrade from 0.7.8.** Fixes found by using the thing: two from the release
@@ -789,7 +1956,9 @@ the MCP surface to three tools: `dispatch`, `job_status`, `usage`.
 Known issues in this release, fixed in 0.5.0: `configure` writes resolved API keys into
 its output, and `configure --yes --force` can delete user-added harnesses.
 
-[Unreleased]: https://github.com/fstubner/harness-dispatch/compare/v0.7.9...HEAD
+[Unreleased]: https://github.com/fstubner/harness-dispatch/compare/v0.9.0...HEAD
+[0.9.0]: https://github.com/fstubner/harness-dispatch/compare/v0.8.0...v0.9.0
+[0.8.0]: https://github.com/fstubner/harness-dispatch/compare/v0.7.9...v0.8.0
 [0.7.9]: https://github.com/fstubner/harness-dispatch/compare/v0.7.8...v0.7.9
 [0.7.8]: https://github.com/fstubner/harness-dispatch/compare/v0.7.7...v0.7.8
 [0.7.7]: https://github.com/fstubner/harness-dispatch/compare/v0.7.6...v0.7.7