@staix/agent-hub 0.12.19 → 0.12.20

package/docs/security.md

@@ -4,7 +4,7 @@ agent-hub connects agents that can each run commands. This page says what the hu
 
 ## Trust boundaries
 
-- **Other agents' text is untrusted.** Every message that crosses from one peer to another is framed as untrusted input (a channel tag with `meta.source` for Claude, a fixed header line plus a standing instruction for the others). A message body cannot forge the hub's own headers: such lines are quoted (`sanitize`). Replies inherit a hop count capped at 3, so agents cannot ping-pong forever; neither a digest nor a steer can reset it.
+- **Other agents' text is untrusted.** Every message that crosses from one peer to another is framed as untrusted input: a channel tag with `meta.source` for Claude started with `ahub claude`; otherwise a fixed header line (`frame()`, `[agent-hub message from ...]`) with an instruction that says it is untrusted, the plugin's server instructions for a tools-only Claude reading `hub_inbox` and a standing instruction for the others. A message body cannot forge the hub's own headers: such lines are quoted (`sanitize`). Replies inherit a hop count capped at 3, so agents cannot ping-pong forever; neither a digest nor a steer can reset it.
 - **The control link is loopback plus a secret.** The daemon and the Codex proxy bind 127.0.0.1 only. The control WebSocket requires a per-run token (`.agenthub/state/control-token`, mode 600), and both servers refuse any request that carries an `Origin` header: any web page can open a WebSocket to localhost, and browsers always send `Origin`. External clients cannot claim the console user's id or a hub-managed peer's id.
 - **Permission prompts stay on.** `ahub claude` and `ahub codex` add nothing that weakens the agents' own prompts. Kimi's and `local`'s permission requests are relayed to the console and cancelled after `approvals.timeout_s` (default 120 s) of silence; the macOS notification for a waiting request carries the peer and the tool name only. The one exception is the hub's own tools (`hub_send` and the task tools, matched by exact name): Kimi's requests for them are approved once without a prompt and logged by name, the same trust Codex gets through `approval_mode` in the hub's config. They invoke hub-owned operations rather than arbitrary file or shell tools, and every call passes the hub's own checks. Identity comes from the exact permission title, or from the earlier tool-call title bound to the same call id and resolved against the configured MCP servers when the permission title contains argument JSON (Qwen). Payload text and unrelated display titles never establish identity. For ACP agents, a payload longer than the console shows is marked as cut and never offers a session-wide grant. Pi's write, edit, shell and git write requests are relayed the same way and can be answered `Always allow <tool> until Pi restarts`: later calls of that tool by the same Pi start skip the prompt but stay inside the path guard and sandbox. The grant covers every later call of that tool whatever its payload, is kept in memory only, cannot be given from the dashboard, and each call it allows is logged by tool name. `--unattended` turns prompts off, says so loudly, and is never the default.
 - **A committed config cannot choose launch commands, credential files, data endpoints or a wider sandbox.** The machine-local fields (`kimi_cmd`, `codex_bin`, `pi.cmd`, `checks`, `mlx.bin`, `mlx.runtimeDir`, `mlx.modelPath`, `omniroute.urls`, `omniroute.access_hosts`, the `omniroute` key files, `memory.worker_url`, `local.read_allow`, `local.bash_network`, `local.network_allow`) apply only from a config file git confirms nobody committed: `.agenthub/config.json` or `.agenthub/config.local.json`, matched by file identity so no other spelling the file system accepts slips past, and `.agenthub` itself not a committed symlink or submodule. Without a repository, or when git fails, they keep their defaults; an empty value always means the default. "Untracked" is answered by the repository that contains the project: a checkout copied or extracted into an unrelated repository, or into an ignored directory of one, is trusted like your own files. So a cloned repository cannot choose a launch command, a completion check, a gateway to send a key file to, a memory endpoint, or a wider sandbox. A command in `checks` runs as you, outside the local worker's sandbox, like a git hook. Nothing in `routing.toml` or in task text is ever run. `routing.toml` and the other shared fields still come from the checkout, and they matter: `routing.toml` picks the models the local worker and the hub's inference use at your gateway and can turn the PII constraint off, and roles and budget shape who does what. Review them in a repository you do not trust.
@@ -13,12 +13,13 @@ agent-hub connects agents that can each run commands. This page says what the hu
 - **The edit hook reads, never decides.** `ahub check-path --hook` (issue #32) reads hub.db and returns context for Claude and a line for you; it sets no permission decision, so your permission rules stay in charge. It names other owners' task ids, titles and states, which then reach Claude's model; PII tasks are left out.
 - **The session record holds identities only.** `.agenthub/state/sessions.json` (issue #37, mode 600) keeps each attached peer's recovery metadata: launch options, session and thread ids, Pi's session file path. No message or task text; loss notices name deliveries by id, sender and public task title.
 - **Context checkpoints have a separate text record.** Native occupancy readings carry numeric metadata only. An optional context checkpoint persists its summary in `.agenthub/state/context-checkpoint-<peer>.json` with mode 0600 and attempts shared-memory storage when enabled. Completion requires the outstanding request id, current peer/native session and transport generation; new connection claims invalidate old requests. Private turns, every open PII task associated with the peer as owner or reviewer (including pending review), and PII-pattern summaries are refused before persistence or cloud memory. Its text is never broadcast, and context pressure does not pause, reassign or replace the session.
-- **The local worker is boxed in.** Paths are resolved through symlinks and must stay inside the project; a secrets denylist (`.env*`, keys, credential files, the hub's own state) applies to its file tools, its git arguments and its memory capture alike; `.git` and `.agenthub` are not writable. Writes, edits, shell commands and mutating git wait for approval, and the approver sees what will be written or run, with control characters escaped. Everything it executes runs under the macOS sandbox, attended or not. Since 0.10 the profile starts from deny default (issue #39): commands run and read only the system, toolchain and project directories (and the project's git dir and the selected developer dir; with network on, the public CA bundles); no writes outside the project, its git dir and a temp dir of its own (`TMPDIR`, made for each command and removed when it ends; issue #63); no `.git/hooks` or `.git/config` writes; no network, loopback included, unless `local.bash_network`; with it, only through the hub's egress proxy to the hosts in `local.network_allow` (issue #65), which refuses names that resolve to internal addresses (behind NAT64 with the well-known prefix, by the IPv4 address the answer carries; a network-specific prefix is not recognised), so claude-mem and the Codex app-server stay out of reach (`"direct"` opens everything, until 0.13.0). One channel stays open: `trustd`, which TLS clients need, can fetch a certificate's AIA or OCSP URL on a command's behalf, outside the proxy. The allow-default profile of 0.9 and earlier was removed in 0.12.0 (issue #83); a `local.sandbox` setting is ignored with a note. The shared temp dirs (the user's and `/private/tmp`) are closed. Without the sandbox there is no `bash` tool.
+- **The local worker is boxed in.** Paths are resolved through symlinks and must stay inside the project; a secrets denylist (`.env*`, keys, credential files, the hub's own state and the state archives `ahub reset --all` leaves) applies to its file tools, its git arguments and its memory capture alike; `.git` and `.agenthub` are not writable. Writes, edits, shell commands and mutating git wait for approval, and the approver sees what will be written or run, with control characters escaped. Everything it executes runs under the macOS sandbox, attended or not. Since 0.10 the profile starts from deny default (issue #39): commands run and read only the system, toolchain and project directories (and the project's git dir and the selected developer dir; with network on, the public CA bundles); no writes outside the project, its git dir and a temp dir of its own (`TMPDIR`, made for each command and removed when it ends; issue #63); no `.git/hooks` or `.git/config` writes; no network, loopback included, unless `local.bash_network`; with it, only through the hub's egress proxy to the hosts in `local.network_allow` (issue #65), which refuses names that resolve to internal addresses (behind NAT64 with the well-known prefix, by the IPv4 address the answer carries; a network-specific prefix is not recognised), so claude-mem and the Codex app-server stay out of reach (`"direct"` opens everything, until 0.13.0). One channel stays open: `trustd`, which TLS clients need, can fetch a certificate's AIA or OCSP URL on a command's behalf, outside the proxy. The allow-default profile of 0.9 and earlier was removed in 0.12.0 (issue #83); a `local.sandbox` setting is ignored with a note. The shared temp dirs (the user's and `/private/tmp`) are closed. Without the sandbox there is no `bash` tool.
 - **Capabilities are enforced, not suggested.** `capabilities` (issue #39) is checked by the daemon where task operations and messages arrive, so a peer cannot get round it by phrasing. A peer can never answer a permission request: the control link takes `permit` from the console role only, and a message that quotes a permit command is just text. Both bind the hub's own tool paths: a vendor agent with its own shell in the project (Codex, Claude, Kimi) can read `.agenthub/state/control-token` and connect as the console, which only the local worker's and Pi's sandbox prevents.
 - **PII has an enforced path.** A task matching `signals.pii_patterns` goes to `local` or to nobody; its text is absent from other peers' envelopes, the console stream, the log and the board listing; the console user reviews it; `local` answers such a turn to the console only, keeps it out of its history, refuses it when the only gateway is off campus, and may not save notes or spin off tasks during it. Nothing about it is sent to claude-mem, whose observer is a cloud model.
-- **Free text is screened too.** On an ordinary task, a done summary (with its check output: a match withholds the whole note), a review note, an unmet item or a budget handoff that matches a PII pattern (issue #69) is not saved to claude-mem, and every peer, `local` included, gets a stub naming `ahub task show <id>`; the board keeps the text, `hub.log` notes the withholding by task id only, and `ahub ask` shows such a note only when its model is reached on campus. `hub_remember` refuses a match; what a vendor agent writes to its own memory is not screened.
+- **A model screen can add to the patterns (issue #198).** With `signals.pii_screen = "local"` in `routing.toml` (default `off`; it applies while `constraints.pii = "local_only"`), a newly proposed task is read by a model before the hub does anything else with it: until the verdict it is on no board, in no envelope, before no triage model, and the hub makes no brief or note call for it. The proposer's own channel is not covered: when the local worker proposes it in an ordinary turn, claude-mem capture of that worker's tool calls (below) sends the arguments whatever the verdict. The screen runs on the model on this machine (MLX or Ollama, loopback only) or, without one, on the gateway only while `onCampus()` holds, and the gateway call is refused once more right before transport if the gateway is behind Access; task text never goes off campus to be screened. When the on-device generation slot is taken (Pi generating, another screen), the screen goes to the campus gateway instead of waiting, and on campus a device that fails or is still loading after 60% of the deadline hands over to the gateway too; off campus it waits for the slot and the device within the deadline. With the legacy MLX provider the screen may start an `mlx_lm.server`, as Pi's relay does, and it stays running until `ahub models stop`. Its answer is `pii` or `clear` plus a category from a closed list (name, student id, phone, address, grade, health, other). Anything else, a timeout (8 s, one call and one generation slot per item), a missing or off-campus model, or text longer than 6000 UTF-8 bytes (about 2000 Hangul syllables) is `unknown`, and an unknown task is a PII task: this is the hub's one model call that fails closed, so with the screener down every new task waits for `local`. An unknown verdict has the costs of any PII task, even when a second look clears it later: opening it lifts every silent turn-free cohort for good and turns facts off while it is open, and off campus a proposal without a class is refused (triage is not asked for a PII task there), with an error that says so. Off campus with the on-device slot taken, a task stays `unknown` until it is screened again: while it is still proposed and no peer ever owned it, the hub's release timer (every 60 s, one task at a time, the least tried first, at most 10 times per task in a hub run; never text too long to read) asks again, and `clear` lifts its `pii` signal and routes it through the class peers (a named owner is not remembered; a reserved one is offered first, as always). A task `local` took keeps its PII path, also once it is declined back to nobody. A pattern match is PII without a call. The task's history records the source of its `pii` signal (`regex`, `screen` with the category, or `unknown` with the reason), an unknown verdict is a console line naming the task id only, and `events.jsonl` gets a `pii_screen` record with the item kind, label, source, category, reason and latency, never the text. A routing explanation of a draft does not call the screen and says so.
+- **Free text is screened too.** On an ordinary task, a done summary (with its check output: a match withholds the whole note), a review note, an unmet item or a budget handoff that matches a PII pattern (issue #69) is not saved to claude-mem, and every peer, `local` included, gets a stub naming `ahub task show <id>`; the board keeps the text, `hub.log` notes the withholding by task id only, and `ahub ask` shows such a note only when its model is reached on campus. `hub_remember` refuses a match; what a vendor agent writes to its own memory is not screened. With the model screen on, the same items (and `hub_remember` notes) go through it as well, one call each and only after the call's own checks (owner, state, verdict, a running check, memory enabled) pass: a `pii` or `unknown` verdict withholds the item exactly like a pattern match, and the board marks the history entry (`withheld`) so later views (task lists, completed-change notices, `ahub ask`, a reviewer replaced after a restart) keep withholding it. A budget hand-off is screened once per hand-off, whatever the number of tasks it moves; an escalation's reason is the hub's own text and is not screened. Pattern-only, without the model: the check output tail in a done note (only the summary is screened), a plan given with `hub_task_accept`, a decline reason, a task's refs (paths, branch), and context checkpoint summaries. Not screened at all (an existing gap, not new with the screen): the local worker's claude-mem capture records its tool calls in ordinary turns with their raw arguments, including the hub tools, so a title, detail, done summary, review note or `hub_remember` text it writes reaches claude-mem without a pattern or model check.
 - **Secrets stay where they are read.** The gateway key and Cloudflare Access values are read inside the gateway client and go only into request headers: never into logs, errors, envelopes, tool output, memory, or the generated Switchyard config (the key travels by environment variable name). Subscription logins of Claude, Codex and Kimi are never proxied or pooled.
-- **The hub's own model calls are fenced.** Digest condensation and task triage read agent-written text as data; their output is capped text framed as untrusted, or a value checked against a closed list. It is never used as a route, a peer id, a tool call or an instruction.
+- **The hub's own model calls are fenced.** Digest condensation, task triage and the PII screen read agent-written text as data; their output is capped text framed as untrusted, or a value checked against a closed list. It is never used as a route, a peer id, a tool call or an instruction.
 
 ## What is not defended
 
@@ -48,12 +49,18 @@ It does not make the token inaccessible to an agent with unrestricted project
 shell access. The existing OS sandbox and loopback authentication boundaries apply.
 
 Steering tools require an explicit `conductor` role, independent of default-allow
-capabilities. Only one peer may hold that role. A conductor may inspect public
-state, assign or escalate work, start supported headless peers and place its own
-delivery holds. It cannot answer approvals, resolve durable deliveries, override
-budget pauses or release a human hold. Pending approval summaries exclude titles;
-PII tasks remain public stubs. Conduct events contain ids only. Supervision feeds
-use structured reasons and never carry check output or approval bodies.
+capabilities. Only one peer may hold that role. Two task-scoped exceptions need
+no role: a task's current owner and reviewer may read its public view with
+`hub_task_show`, and the peer that proposed a task may redirect it with
+`hub_task_assign` while it is proposed, nobody ever accepted it and its latest
+move other than the hub's own was not made from the console (to another peer
+only with `assign` when its capabilities are listed).
+A conductor may inspect public state, assign or escalate work, start supported
+headless peers and place its own delivery holds. It cannot answer approvals,
+resolve durable deliveries, override budget pauses or release a human hold.
+Pending approval summaries exclude titles; PII tasks remain public stubs.
+Conduct events contain ids only. Supervision feeds use structured reasons and
+never carry check output or approval bodies.
 
 ## Reporting
 

package/docs/smoke.md

@@ -2,6 +2,32 @@
 
 `scripts/check.sh` covers everything against fakes. The legs below need real accounts and an interactive terminal, so they are run by hand and recorded here.
 
+## ahub reset on a scratch project (#214)
+
+Not yet run. A person runs it in a terminal, on a scratch project only, never
+on a project whose hub state matters:
+
+1. `ahub init`, `ahub up`, attach Claude with `ahub claude` and one headless
+   peer; queue work for an offline peer with `ahub say @<peer> ...` and
+   `ahub pause <peer>`; propose one task.
+2. Quit Claude Code (its status line tee writes into the state directory) and
+   run `ahub kill`, so nothing else changes the state files, and take their
+   checksums. `ahub reset`: the listing shows ids and counts only, and
+   `hub.db`, `hub.db-wal` and the other state files keep their checksums
+   (`hub.db-shm`, SQLite's shared-memory index, may change on any read).
+3. `ahub up` and `ahub claude` again, then `ahub reset --yes`: the hub stops
+   first; `ahub up` then shows no queued or needs_review delivery
+   (`ahub queue list`), no hold or pause, and the same board; the reset says
+   to relaunch Claude with `ahub claude`.
+4. `ahub reset --all --yes`: `.agenthub/archive/state-<UTC time>/` is 0700 and
+   git-ignored, the state directory holds only `project.json`, and `ahub up`
+   starts with the same project id, an empty board and an empty queue.
+5. Restore the archive as `docs/operations.md` describes (the current state
+   directory goes into `.agenthub/archive/` too) and check the board from
+   step 1 is back.
+
+Record the version, the commands, each result and anything that differed.
+
 ## Operator console and conductor candidate (#190, #191, #193-#195)
 
 Candidate 0.12.17, protocol 15, observed on 2026-10-09 KST. The final Claude
@@ -321,6 +347,23 @@ ahub setup                                 # Claude Code channel plugin from thi
 
 Claude channels are a research preview: `ahub claude` passes `--dangerously-load-development-channels plugin:agent-hub@agent-hub`.
 
+## Claude without channel evidence (#205)
+
+Not run live yet. On a candidate with the rebuilt plugin bundle (protocol 16),
+record only what was observed:
+
+1. Start a plain `claude` in the project (not `ahub claude`). `ahub status`
+   shows `claude` `idle` with `tools-only: messages wait for hub_inbox; ...`.
+   Run `ahub say @claude "<unique text>"`: status shows `queued 1`, `ahub queue
+   list --peer claude` has no `accepted` or `dispatching` row, and no pushed row
+   appears in the TUI. Ask the session to call `hub_inbox`: it returns the text
+   under an `[agent-hub message from "user"` header, status shows `queued 0`,
+   and the queue list shows one `completed` row `read through hub_inbox`.
+2. Start `ahub claude` in the same project (AC3). It takes the peer and the
+   plain session stands by. A new `ahub say @claude "<unique text>"` appears as
+   a native channel row, its delivery reaches `accepted`, and `hub_delivery_done`
+   or a correlated reply settles it `completed`. Status shows no `tools-only`.
+
 ## npm package preparation (issue #4)
 
 Verified locally on 2026-09-19 with Bun 1.3.14, using an actual `npm pack` tarball:
@@ -1285,3 +1328,18 @@ refused by the identity gate). Claude (the session writing this) and Pi on
   nothing happened on the hub: plain `ahub console`, 0.11 s over 60 s
   (about 0.18%); `ahub console --panels`, 0.46 s over 120 s from 05:52:30
   (about 0.38%, 0.21 to 0.25 s per minute, not growing).
+
+## Console layout and readability: how to check (#213, #201 AC2)
+
+Not run yet. Record the terminal, its theme and the result per step.
+
+- In a light and a dark terminal profile, run `ahub console --panels` at 80x24
+  with at least one pending approval, one task and one `needs_review` delivery.
+- Check that the rules, the bracketed active tab, the tab counts, every table's
+  header row and the footer hint are readable, and that titles, approval details
+  and body text use the default foreground.
+- Repeat with `--color=never`: the active tab, selection marker and states must
+  still read without color.
+- Press `?`, Enter on an approval and Tab back to the stream; check that the key
+  table, the labeled detail and the stream's rule above the footer read in both
+  themes.

package/docs/specs/2026-09-19-agent-hub-design.md

@@ -986,8 +986,8 @@ session modes (`default`, `plan`, `auto`, `yolo`) but nothing per server or tool
   route explain` and assignment agree. Accept and done refuse a waiting task,
   for the console user too.
 - A proposal that names an owner (a claim, or an owner for someone else) and
-  would wait is refused: the owner of waiting work is chosen when it is ready,
-  by routing or by `ahub task assign`.
+  would wait stores that owner as the task's reserved owner (issue #207 below
+  replaced the refusal this bullet first specified).
 - Approval, by review or by a class without a reviewer, releases the
   dependents that wait for nothing else; each is recorded as `ready` and assigned.
   A proposal re-reads what it waits for after its insert, since triage may have
@@ -1377,13 +1377,66 @@ checks even for redirected stream output, without enabling panels or raw mode;
 never disables styling. Invalid values fail with usage text before connection.
 Plain `renderConsole` remains available, while `renderConsoleLines` exposes
 semantic spans. Geometry is computed from sanitized plain Unicode text before
-painting. `paint` sanitizes every span, inserts only fixed palette SGR sequences
+painting. Wrapping breaks at whitespace and splits only a word longer than a whole
+line; a wrapped line's continuations start four columns deeper than
+its source line; a source indent and a continuation indent are both capped at half the width, so wrapped peer text in the stream
+never starts at a column where hub-written lines start (#212). `paint` sanitizes every span, inserts only fixed palette SGR sequences
 and resets each styled span. Interactive exits, signals, disconnect and errors
 retain the console restoration sequence. No new dependencies, protocol changes,
 polling or redraw triggers are added. Tail, logs and machine-readable output
 remain unchanged. Native light/dark readability and idle-CPU observations are
 separate smoke evidence, not inferred from fake-terminal tests.
 
+Console layout (issue #213) separates the panel header (the project root's
+directory name, since the registry id is a hash, then the tabs), the body and
+the footer with ASCII `-` rules, and puts one rule above the stream footer; the
+console emits no box-drawing or other ambiguous-width glyph. The active tab is
+bracketed; the Approvals and Queue tabs count pending requests and
+`needs_review` deliveries. Peers, Approvals, Tasks and Queue are tables: a
+header row, columns two spaces apart sized with `Bun.stringWidth` from every
+row (at most a third of the width), the last column taking the rest. Peers' LINK
+column reads `tools-only` when the optional `toolsOnly` status field (#205) is
+present. Zero counters read `-`, durations `45s`, `12m`, `3h05m` or `2d03h`, and
+resets and pauses are relative. Detail views and the Approvals panel's request
+block put labels at column 0 and values one column past the longest label; a
+list puts `- ` before each item, and every other line of a value (its own
+newlines, wrapped continuations) starts two columns deeper, so untrusted text
+passes neither for a label nor for an item. Only a field's own string shows as
+written: every agent-written string below it (nested pairs and lists, list
+items) and every option name or id in the Approvals block, the prompts and the
+stream's permission line is JSON-quoted unless it is a plain word starting with
+a letter, so `;`,
+`,`, `)`, quotes and newlines in it cannot pass for hub structure. Values show
+no JSON objects, epoch milliseconds or ISO times. Allow options keep one line
+each; `d deny` always stays in view, options that do not fit are counted on a
+`(more)` line, table rows give way, and a cut title is marked `(more)` in the
+label column. The selected request is tracked by id: only the first request is
+selected on arrival, `[`, `]` and j/k move the selection, `a`, `d` and `v` act on
+it alone, and its detail is rendered from the live request. When it closes, the
+selection and its detail clear with a notice; `a`, `d` and `v` act on nothing
+until `[`, `]` or j/k select again, so a request that arrives as the person
+reacts is never acted on. Everything pending on a request belongs to the
+selected one, checked after every key and every prune: an option choice or
+confirmation for another request is dropped, an open detail follows the
+selection from its top, and the option prompt names the request. `a`, `d` and
+`v` act only while the request list or its detail is shown, and a task or
+delivery detail that arrives after the person moved to another panel or row is
+dropped; with a task, delivery or peer detail open, the row keys act on the item
+the detail shows, by its id. A pushed request's agent-supplied fields are kept as
+strings, so a malformed one cannot throw on a draw. The key table is modal: only
+`?`, Escape and `q` act under it, and a paste is dropped. Offline peers keep the default foreground, also
+when selected, and a tab counts as one space when a line is cut. The footer
+hint lists only the keys valid in the mode, panel and state, and `?` shows a
+key table grouped by panel (in stream mode it is printed into the stream, as
+`v`'s copy of a request is, without entering the Events buffer). Errors and refusals take the failure tone, informing notices (a closed or
+missing selection) the attention tone. A notice clears at the next key, or once 10 s have passed when the
+existing 1 s tick redraws. In the stream, `v` prints the selected request with
+the push's framing, and `:` command output lines start at column 4. `fit`
+measures a cut line as `paint` prints it, so a cut that ends a span in
+`[agent-hub` cannot widen the line with a `> ` marker. A context reading in the
+console stream and Events panel shows its measurement time as local time, as
+event headers do; `ahub tail` and `ahub status` keep the ISO time.
+
 Agent shell CLI calls connect as the detected peer in tools mode. Hub launches
 set `AGENTHUB_PEER_ID`; the pinned installed Codex shell injects
 `CODEX_THREAD_ID` after environment filtering, and Claude uses `CLAUDECODE`.
@@ -1534,3 +1587,346 @@ only. The path guard, denylist and sandbox still apply to each call; the
 dashboard still offers Pi only deny; unattended mode still picks `allow_once`;
 the local worker keeps allow and deny. The console and `ahub permit` already
 handle more than one allow option, so the control protocol is unchanged.
+
+## Amendment: Claude sessions without channel evidence (issue #205)
+
+Claude Code without `--dangerously-load-development-channels` drops channel
+notifications without an error, so a plain `claude` session used to mark every
+push `accepted` and show none of them.
+
+- Evidence: `ahub claude` passes the flag and, in the same launch, sets
+  `AGENTHUB_CHANNEL=1` in Claude's environment (`nativeLaunchEnv`);
+  `peerChildEnv` removes the marker from every other native child. The plugin's
+  MCP server inherits Claude Code's environment (a local check on 2026-10-09,
+  not a live smoke: a plain session's plugin server inherited a shell-only
+  `AGENTHUB_*` variable, and the plugin's `.mcp.json` sets no env), as it
+  already does for
+  `AGENTHUB_STATE_DIR` and `AGENTHUB_PEER_ID`. Only the value `1` counts. With
+  the marker the server keeps
+  the push and settlement contract of "Live channel settlement" unchanged.
+  Without it (a plain `claude`, an IDE session, or the flag passed by hand) the
+  session attaches tools-only.
+- Decision: the launch marker is sufficient evidence, and no positive readback
+  is required before the first `accepted`.
+  - The marker and the flag come from the same launch, so the marker shows that
+    this Claude process got the flag. A readback would add per-push proof of
+    display, which stays out of scope: `accepted` means the bridge handed the
+    notification over, and `hub_delivery_done` or a correlated reply settles
+    handled work.
+  - A readback (a native turn citing the pushed id) would hold every first
+    delivery until the model chose to answer, and a session that never answers
+    would look the same as one that never rendered.
+  - The existing launch identity (`AGENTHUB_INSTANCE_ID`, `AGENTHUB_LAUNCH_ID`)
+    is not used: `ahub claude` sets it only when a daemon is already running at
+    launch, so an `ahub claude` started before `ahub up` would lose pushes it
+    can show.
+  - Limits: the marker is inherited by the session's own shell children, so a
+    plain `claude` started inside an `ahub claude` session reads as
+    channel-capable (it also inherits the peer id and takes the peer over); so
+    does `claude -p` run by a hook or script inside such a session, with its
+    state dir and peer id. The marker is per process while the flag names MCP
+    servers: `ahub claude --mcp-config <candidate>` without
+    `--strict-mcp-config` loads channels only for `server:agent-hub`, yet the
+    installed plugin server in the same process also sees
+    `AGENTHUB_CHANNEL=1`. A session started with the flag by hand reads as
+    tools-only and is pointed to `ahub claude`.
+- Tools-only attach: the server declares tools only, sends `channel: false` in
+  its `peer` hello and lists `hub_inbox` but not `hub_delivery_done`. It never
+  reports `accepted`: a `deliver` it is handed anyway goes back as a
+  `needs_review` receipt. The daemon attaches its `WsPeer` as `pullOnly`; a
+  push drain needs the peer deliverable (`Bus.deliverable`: not held, idle, not
+  pull-only), checked at each loop and again after condensation, so a plain
+  session that takes the peer while a push is condensed gets nothing. Its
+  messages stay queued and count as `queued`. Board routing still treats the
+  peer as attached.
+- `hub_inbox` sends `inbox`. The daemon answers "not attached yet; retry"
+  between welcome and attach, and refuses it for a session with pushes.
+  `Bus.pull` is held by every hold a drain respects (`Bus.held`: recovery, an
+  uncertain delivery, a console, budget or conductor pause), though unlike a
+  drain it does not wait for the peer to be idle; a held pull journals nothing
+  and the refusal names the hold and the next action. Otherwise it takes what one
+  push delivery would (the preface, then `take`'s batch of at most ten,
+  important first; the reply says how many still wait) and checkpoints it like
+  a push, so queued journal rows of the same envelopes (an operator retry) are
+  grouped into it, then marks it `completed`, reason `read through hub_inbox`,
+  in the same transaction: the tool result that returns them is the readback,
+  so nothing waits in `accepted`. What it hands over is registered (and moved
+  to the newest end of the cache) for `reply_to` like a push, and a read clears
+  the peer's failure streak as a completed push does. If that journal write fails, only this peer's queue
+  and preface are put back (every pause stays) and the bus stops with
+  `delivery journal unavailable`. A pull is not a native turn and is not
+  counted as supervision. The row is completed at hand-out, before anything
+  shows the model saw it: a reply lost on the way, a tool call cancelled with
+  Esc or a plugin that dies loses the batch (a `ponytail:` ceiling in
+  `Bus.pull`), and `ahub queue resolve --action retry` refuses a terminal row.
+  The completed row keeps the envelopes, so the operator reads them with `ahub
+  queue show <id>` and sends what matters again.
+- Who holds the peer: an `ahub claude` session takes it from a plain session
+  as any newer hello does, a standing-by one included (its standby check does
+  not wait for a holder that status reports `toolsOnly`); attach clears
+  `pullOnly`, the waiting queue is pushed to it, and the plain session stands by
+  (close 4000). A plain session
+  never takes it from a session with pushes, attached or still arriving: its
+  hello is closed with 4000 and it stands by the same way, so an IDE or plain
+  `claude` with the user-scope plugin cannot strand the channel session's
+  unsettled deliveries. It attaches once that session leaves.
+- Status: `status.json` peers carry `toolsOnly`, a line naming the state and the
+  next action (`ahub claude`); `ahub status`, the console footer and the
+  dashboard show it.
+- Control protocol 16 adds the hello `channel` field and `inbox`. Recovery
+  sources add protocol 15 (0.12.17 through 0.12.19); the transition from a real
+  0.12.19 hub is not yet proven.
+## Amendment: owner and reviewer read their task (issue #208)
+
+`hub_task_show` stays a conductor tool, and a task's current owner and current
+reviewer may also call it for that task. They get exactly the conductor's
+view: `publicConductorTask` over `Tasks.publicView(task, true)`, so the whole
+history with its done summary and check line, notes that match a PII pattern
+withheld, and a PII task as a stub with no history. Any other peer is refused
+with the conductor-role error, whatever the task. That refusal is about the
+tool, not a secret: the view holds nothing private beyond the PII stub, and the
+control op `task_show` (`ahub task show` from an agent shell) already returns
+the same public view to any peer. These reads write no conduct audit event, as
+task list polling does not. `hub_status` stays conductor-only.
+
+## Amendment: reserved owners and proposer redirects (issue #207)
+
+- `reserved` is a nullable text column on `tasks`, added to existing boards
+  like `plan` and `deps` (old rows reserve nobody). `hub_task_propose` with an
+  `owner` and an `after` that still waits stores the owner there instead of
+  refusing; the capability check for naming another peer is unchanged. With
+  nothing left to wait for, a named owner is assigned as before.
+- The reservation is an input of `assign()`, read from the task, so `ahub
+  route explain` and assignment agree. When no candidate list is given, the
+  reserved owner is the only candidate if `blocked()` passes it; otherwise the
+  trace says why it is not honored and routing proceeds through the class
+  peers. PII, capability limits (`local_allowed`, Pi's context limit),
+  exclusions, failing peers and offline or paused peers all pass it over, so a
+  PII task still goes to `local` or nobody.
+- Lasting exclusions are refusals only: a decline records the owner it was
+  declined for in its history entry's `from` (also when the console declines
+  for that owner), and an escalation with reason `rejections` (a reviewer's
+  repeated changes_requested) or `manual` (by hand) records the owner it took
+  the task from the same way. `excluded()` reads both (older decline rows name
+  only the decliner), so those peers stay out of every later reroute and of
+  `route explain`: the reservation never hands the task back to them. The
+  hub's own escalations after a failed delivery or inference
+  (`delivery_failed`, `inference_failed`), and an owner released as gone, moved
+  by the idle sweep or relayed for its budget, exclude that owner only from
+  that move's own reroute: none of these is a refusal, so a later reroute may
+  give it the task again from its reservation. A person's explicit assign
+  (`ahub task assign`, the dashboard) is not blocked by lasting exclusions and
+  clears an agent's reservation, so a later reroute does not hand the task to
+  the agent's choice; the conductor's and a proposer's assigns respect the
+  exclusions and keep the reservation.
+- A named candidate list (console or conductor assign, escalation, budget
+  relay, the idle sweep's auto-reassignment of its suggestion) replaces the
+  reservation; the idle sweep's step-3 suggestion itself is an `assign()`
+  without candidates, so it consults the reservation like routing does. A task
+  that waits shows its reservation in the trace before the readiness check,
+  which then stops; the trace says whether routing would honor it only once
+  the task is ready. `route explain <id>` also names it in the header. The
+  reservation stays after it is honored or passed over.
+- Passing over a reservation is a console and hub.log notice naming the
+  reserved peer and the reason, from assignment and from the idle sweep's
+  suggestion alike, and the assignment's history note keeps it, appended to a
+  note the caller gave (a gone owner's release). Only news is said: nothing
+  when the reserved peer is the owner the task moves away from (its decline,
+  escalation, release or idle sweep), and nothing once it refused the task for
+  good (the decline or escalation said that). The reserved peer is not
+  messaged.
+- `Tasks.assignTo` on a task that waits records a `reserved` event with reason
+  `manual` and changes the reserved owner instead of the silent no-op it was;
+  this applies to the console, the conductor and a proposer alike. The release
+  timer treats a `reserved` last event like `blocked`.
+- `hub_task_assign` stays a conductor tool, and the task's proposer (the `by`
+  of its first history entry) may call it while the task is `proposed` and its
+  history has no `accepted` entry: a decline or a release puts a task that was
+  worked on back in `proposed`, and that task is no longer the proposer's to
+  redirect. Handing it to another peer needs `assign` when the proposer has a
+  capabilities entry; redirecting to itself does not. The conductor needs
+  `assign` for any assign when it has a capabilities entry. The proposer path
+  is refused while the last owner or reservation change of the task
+  (`assigned`, `reassigned`, `escalated`, `unassigned`, `reserved`) that the
+  hub did not make itself was made by the console user: a person's assign or
+  reservation stands until the conductor or the console moves it, also after
+  the hub carried it out or passed it over. The id is taken as `Tasks.need()`
+  takes it, a whole number or a digit string. Any other non-conductor peer, and
+  the proposer once the task was accepted or a person moved it, get the
+  conductor-role error. A proposer's redirect goes through `Tasks`, keeps the
+  proposer as the actor with reason `manual` (on the `reassigned` or `reserved`
+  entry), and writes no conduct audit event; during a PII turn it is refused
+  like the conductor's.
+## Amendment: ahub reset (issue #214)
+
+`ahub reset [--all] [--yes]` returns a project's hub to a clean state. It is
+human-only (the CLI identity gate refuses it from an agent shell) and a dry run
+unless `--yes`: the dry run reads `hub.db` read-only (with `immutable=1` when
+`hub.db-wal` or `-shm` is absent, so it creates neither) and prints delivery ids,
+peer names and counts per category, never task or message text. With `--yes`
+it stops a running hub through `stopProject`, the path `ahub kill` takes, then
+acts on the stopped state directory.
+
+- Refusals, each before anything changes: the machine's recovery lock is held
+  (`recoveryLock()` read directly: a reset is never part of an operation, so
+  `AGENTHUB_RECOVERY_OPERATION` does not let it through as it lets the
+  operation's own processes through `assertLifecycleAvailable`); no
+  registration matches this root and state directory, running or not (`ahub
+  up` registers a stopped project; when this root is registered with another
+  state directory the error names `ahub --project <id> reset` instead, since
+  `ahub up` would register the default directory and orphan that state); the
+  hub's ownership is not verified (any inspection state other than stopped, running
+  or stopping); a running hub reports a recovery operation whose phase is not
+  `released`; `--all` with a state directory other than the literal
+  `<root>/.agenthub/state` (an override or symlink elsewhere would cross file
+  systems or pull outside state into the tree); `--all` when `.agenthub` or
+  the state directory is not a real directory of this user, when
+  `.agenthub/archive` exists as anything else (a symlink could carry hub.db,
+  PII included, out of the project), or when its `.gitignore` is not a regular
+  file (a symlink would truncate the file it names). These are checked before
+  the stop and again right before the rename (`archiveProblem`); a hard-linked
+  `.gitignore` is replaced by a temp file and rename, never written through.
+  Checked, then renamed by path: a symlink swapped in between still wins
+  (marked `ponytail:`; `renameat` on a held descriptor would close it).
+- Between stop and act: after `stopProject` the CLI takes the project's
+  registry claim (`Registry.claim` with its own pid), the claim a daemon must
+  hold to run, and checks that no manifest names a daemon whose pid is alive
+  or uncertain (`processAlive`, the rule `inspectProject` uses); either failing
+  means a hub started in between and nothing is reset. A reset's claim carries
+  the instance prefix `reset-`, so losing the claim to a concurrent reset says
+  so. A crashed daemon's manifest (`status.json`, `control-token`, `hub.pid`
+  with a dead pid, after SIGKILL or the forced shutdown exit; an empty or
+  garbled `hub.pid` beside a dead `status.json` included) does not count: the runtime reset
+  removes it and `--all` archives it. With the claim held, the CLI checks the
+  machine's recovery lock again, so an upgrade or recovery that took it in
+  between does not run beside the reset. The claim is released when the reset
+  ends; a reset that dies leaves a dead pid, which the next claim takes over.
+- Failures: the plan is read only for the dry run, so `--all --yes` archives a
+  state directory it cannot read as it is (its dry run says what it could not
+  read). A failure after the stop says how far it got. A runtime reset that
+  cannot read the state (a corrupt `hub.db`, malformed JSON or valid JSON of
+  the wrong shape, which `planReset` checks as the journal would, a journal the
+  constructor refuses: root mismatch, corrupt metadata, too many rows) fails
+  the same way on a rerun, so its error points to `--all`; any other runtime
+  failure is finished by a rerun, every step being idempotent. `--all` prints
+  the archive path as soon as the rename happened; a failure before it says
+  the hub is stopped and nothing was moved. JSON and SQLite errors are printed
+  by class and code only (`failureText`): a parser's message can quote the
+  data it choked on, envelope bodies and task text included.
+- Runtime scope (default): the CLI opens the journal as a new instance, which
+  turns the stopped run's dispatching and accepted rows into `needs_review`,
+  and settles every `queued` and `needs_review` entry of `Bus.queueList`,
+  including queue entries without a row, with `resolveDelivery(..., "discard",
+  "reset")`: one `resolution_history` entry each. It clears manual holds
+  through the bus, deletes the `budget_pauses` and `conductor_holds` rows and
+  removes `sessions.json`, `claude-session.json` and `claude-context.json`,
+  and a crashed run's manifest.
+  The board, turns and touches, execution budgets, logs, `events.jsonl`,
+  `cli-audit/`, recovery records, `pi-sessions/` and configuration stay.
+- Full scope (`--all`): the state directory is renamed, unchanged, to
+  `<root>/.agenthub/archive/state-<YYYYMMDDTHHMMSSZ>/` (0700); an existing
+  target refuses the move. The archive directory gets a `.gitignore` of `*`
+  (checked on every `--all` and rewritten when it differs) because `hub.db`
+  holds task text, PII included; turn snapshots exclude `**/.agenthub/archive/**`
+  as they exclude the state directory, also when the user's index tracks it or
+  the `.gitignore` is gone; and `.agenthub/archive` is a
+  `DENY_SEGMENTS` entry (`src/local/deny.ts`), so the local worker's and Pi's
+  path guard, seatbelt profile and memory capture refuse it like
+  `.agenthub/state`. A new 0700 state directory (created with `recursive`, as
+  the status line tee may have re-created it) holds only a copy of
+  `project.json`; the project id is the hash of its root,
+  so the registration and id are unchanged. Archives are never pruned.
+- Output says that claude-mem is not touched and that attached Claude Code
+  sessions must be relaunched with `ahub claude`. The control protocol is
+  unchanged: reset never talks to a running hub except to inspect and stop it.
+
+## Amendment: model-based PII screen (issue #198)
+
+- `routing.toml` `[signals] pii_screen = "off" | "local"`, default `off`; any other
+  value fails the load like a bad pattern. With `off`, or with `constraints.pii =
+  "off"`, nothing changes and no screen call is made.
+- Order. With `local`, `Tasks.propose` screens the task's title, detail and plan
+  text right after the pattern check and before triage. "Held as private" is met
+  by holding the task back entirely: until the verdict it is not on the board, so
+  no envelope, notice, triage call, brief or note of the hub's can read it. The
+  local worker's claude-mem capture of its own tool calls is outside this: in an
+  ordinary turn it sends a proposal's arguments whatever the verdict (an existing
+  gap for every hub tool, not closed here). Writing it as
+  a PII task first was rejected: a PII task opening lifts every silent turn-free
+  cohort for good and switches facts off (#107, #108), so every proposal would do
+  that. The proposal's tool call waits for the verdict, as it already waits for
+  triage: for an ordinary task at worst the screen (8 s), triage (8 s) and a brief
+  (2 x 2 s), 20 s; for a task the screen marked PII, triage first runs its own
+  on-campus probe (two 4 s rounds when the gateway stalls), so about 24 s. Both
+  stay under the plugin's 30 s control timeout. `hub_task_done` and `hub_review`
+  put the screen (8 s) ahead of their existing waits, such as the briefs
+  `releaseDependents` fetches for the tasks an approval releases.
+- The screener (`screenPii`, `src/hub/inference.ts`): the on-device model when
+  `mlx.enabled` and it can be had (`ensureMlx`, loopback only; a legacy MLX runtime
+  is started the way Pi's relay starts it and keeps running until `ahub models
+  stop`), else the gateway's `local.fixed_model` only while the
+  daemon's `onCampus()` holds, with `onCampusOnly` so the client refuses an Access
+  host once more before transport; never the Switchyard sidecar. One call per item,
+  an 8 s deadline over the whole call, and a generation slot of its own: it asks
+  for one without waiting (`acquire(abort.signal, 0)`: one look, then
+  `MlxBusyError`); with all taken (Pi generating, another screen) it uses the
+  campus gateway when `onCampus()` holds and otherwise waits for the slot under the
+  deadline. On campus the device gets 60% of the deadline: an error reply or a
+  device still loading then hands over to the gateway within the rest; off campus
+  it keeps the whole deadline. `max_tokens` 32, temperature 0 and `reasoning_effort: "none"` on both
+  paths, so a reasoning model does not spend the budget thinking. The
+  prompt frames the text as data and carries Korean and English examples and hard
+  negatives. The answer must be exactly `clear` or `pii <category>` with a category
+  from `name, student_id, phone, address, grade, health, other`.
+- Fail closed: an answer outside that form, a timeout, a failed or missing model,
+  an off-campus gateway, or text over 6000 UTF-8 bytes (every token is at least a
+  byte, so text and prompt fit the 8k on-device context; Ollama could otherwise
+  judge cut input) is `unknown`. `pii` and `unknown` add the `pii` signal,
+  so the task takes the whole existing PII path (local or nobody, user review,
+  private envelopes, redacted views, no claude-mem). A pattern match is PII without
+  a call. The source is recorded as a `screened` history entry (`pii: regex`,
+  `pii: screen, <category>`, `pii: unknown, <reason>`, `clear`) and a `pii_screen`
+  event; an unknown verdict is a console and hub.log line with the task id and the
+  closed reason only. `route explain` on a draft does not call the screen and adds
+  a trace line saying a proposal would. The cost of `unknown` is the cost of any PII
+  task, even if a re-screen clears it later: it lifts every silent turn-free cohort
+  for good and turns facts off while open, and off campus triage is not asked, so a
+  classless proposal that is not a claim is refused with an error naming that.
+- Re-screen. Off campus with the device slot taken, the verdict is `unknown`. A
+  task whose last `screened` entry is `pii: unknown` (not `too long`, which a
+  second look cannot change), that is still `proposed` and that no peer ever owned
+  (no history entry carries an owner) has had nothing private sent anywhere, so
+  `Tasks.rescreen()`, on the daemon's 60 s release timer (one task per tick, the
+  least tried first, at most 10 tries per task in a hub run, in memory), screens it
+  again. `clear` lifts the `pii` signal through `Board.update` (a `screened` entry
+  `clear, screened again`), notifies by task, and routes it through the class
+  peers (a named owner or a claim is not remembered; a reserved owner, #207, is
+  offered first as `assign()` always does); `pii` settles it; another `unknown`
+  changes only the event record. A task an owner took (`local`) keeps its PII path,
+  also after it was declined back to nobody: its review notes, summary and decline
+  reason were never screened.
+- Free text (#69): the done summary, the review note with its unmet items, a
+  budget hand-off (once per hand-off, however many tasks it moves) and a
+  `hub_remember` note go through the same screen on an ordinary task when they
+  match no pattern; a match is recorded as a `regex` verdict without a call. The
+  call's cheap checks (owner, state, verdict, a running check, memory enabled) run
+  first, then the screen, then the checks again on a fresh read. An escalation's
+  reason is the hub's own text and stays pattern-only. `pii` or `unknown` withholds the
+  item exactly as a pattern match does (stubs, no memory note, no summary line in
+  completed-change or integration notices; `hub_remember` is refused). The board
+  keeps the text and marks the history entry `withheld: true`, so public views,
+  later reviewers, held cohort notices and `ahub ask` keep withholding it after a
+  restart without another call. The check output tail of a done note, a plan given
+  at accept, a decline reason, refs (paths, branch) and context checkpoint
+  summaries stay pattern-only.
+- Calibration (AC4): `test/fixtures/pii-screen.json` holds synthetic Korean and
+  English positives across the categories and hard negatives (roles,
+  placeholders, field and function names, ports, codes); none is copied from the
+  prompt, and its account, passport and resident numbers have impossible lengths
+  or dates. `bun scripts/pii-screen-eval.ts [--project <dir>] [--out <file>]` screens
+  each item once, in order, through `screenPii` with the project's configuration
+  and reports recall, recall as handled (pii or unknown), precision, the unknown
+  rate, held negatives, category agreement and latency. The bound, fixed here
+  before any measurement: the model itself labels at least 90% of the positives
+  `pii` (an unknown verdict counts as a miss). The report goes to
+  `docs/verification/`; the script exits 1 under the bound.

package/docs/specs/2026-09-20-pi-local-models-design.md

@@ -18,6 +18,8 @@ Issue: #25. Pi is a managed project peer for implementation, edits, tests, summa
 - Apple Silicon setup pins Python 3.12, `mlx-lm==0.31.3`, and `Qwen/Qwen3-8B-MLX-4bit` revision `383413e909f3bc5303ce195ebbdf0339c5a1a2a3`.
 - The MLX input estimate is capped at 16,000 tokens; decode and prompt concurrency are one. DGX's default input estimate cap is 262,144 tokens.
 - The relay authenticates every call, rejects browser origins and unknown model aliases, and preserves streamed bytes. It records the requested route and model reported by the backend. Per request it also journals sanitized identity and lifecycle evidence (#139): resolved alias, upstream-configured model, observed provider and served model with their source (gateway header, generation SSE event, or local MLX configuration), outcome (completed, cancelled, failed), duration, and a confirmed-mismatch flag. A request cancelled before any identification stays explicitly unidentified; a backend's mutable last-served label is never a request's own evidence, and a primary/auxiliary role stays unknown without native evidence. Records carry no prompts, tools, keys or Access headers.
+- Load and cooldowns (#199, amended 2026-10-09). A `hub/auto` request bound for MLX keeps exactly its two candidates, MLX then its DGX fallback; load and cooldowns only reorder them, and a fixed alias (`mlx/fast`, `pi_backend = "mlx"`) is never reordered. The fallback goes first when MLX is cooling down, unless the fallback is cooling down or its own last dispatch failed in any way (an error status or a failed stream included) within 30 s and it has not succeeded since. Load moves are opt-in: with `[pi] efficient_wait_ms` set (below the 120 s slot wait; read when the hub first starts Pi), a movable request whose MLX slot is still busy after it, and an enforced tool loop pinned to the fallback, put the fallback first under the same health rule, and only while the request runs under no execution budget, where a move could spend the model call or the time MLX needs (budget-aware moves from the admission's remaining units are the upgrade path). Under #197 `enforce` a load move happens only at a user turn. A moved attempt gets a 15 s deadline to its response headers, after the gateway lookup, and is then abandoned for MLX; a reorder for a cooling MLX keeps the full request deadline. The bound ends with the headers: a stream that stalls or fails after them cannot fall back to MLX, and a failed one marks the fallback failing so later requests do not move. Each relay alias cools down after three consecutive transport or startup failures outside a cooldown (a failure more than twice the cap after the last counted one starts the count over), for 30 s doubling up to 5 min; a busy MLX slot and timeouts cut short by the execution budget never count, and any HTTP answer, a success or an error status, proves the transport works and clears the streak and the cooldown. A cooling DGX alias with no alternative is still tried. An alias that fails before it has a status row (gateway or key unavailable) gets one, so its cooldown shows. Both reorders are invisible to PII, which never reaches the relay (Pi refuses PII work). A load move journals no MLX attempt unless MLX then serves as the fallback. Route events record `source: "load"` or `"cooldown"` and `stateless` for a request without a session key; `events.jsonl` records `cooldown` start and end, and `ahub status` shows the cooldown on the backend line. Before the relay first starts MLX, startup decides as before. The live wait-time measurement on a mixed workload (#199 AC5) is open.
+- Decision, 2026-10-09: load moves are off unless `efficient_wait_ms` is set, a deviation from the issue's "default about 500 ms". Reason: the move is unmeasured (AC5 is open), its bound covers only the response headers, and each review round found another way an unmeasured move could make a request worse than main. Revisit with the AC5 measurement.
 - MLX may fall back to DGX before response streaming begins. Failed non-PII tasks can escalate to configured cloud peers with an explicit warning to reconcile partial effects.
 - Runtime ownership includes process start identity. Project shutdown releases its relay, while explicit `ahub models stop` controls the shared MLX process.