harness-dispatch 0.7.9 → 0.8.0

package/CHANGELOG.md

@@ -6,6 +6,661 @@ pre-1.0, so minor versions can carry behaviour changes.
 
 ## [Unreleased]
 
+## [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 +1444,8 @@ 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.8.0...HEAD
+[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