@staix/agent-hub 0.12.30 → 0.12.31

package/docs/quickstart.md

@@ -17,7 +17,7 @@ ahub setup                                # installs the Claude Code channel plu
 Or use the matching GitHub release:
 
 ```bash
-bun add -g github:STAIxBWLB/agent-hub#v0.12.30
+bun add -g github:STAIxBWLB/agent-hub#v0.12.31
 ahub setup
 ```
 
@@ -30,6 +30,19 @@ and upgrade or crash recovery, see the [operations guide](operations.md). To
 move running projects to a newer release later, run `ahub upgrade` in a
 terminal: it reviews the plan with you, applies it and follows it.
 
+## Upgrading to 0.12.31
+
+Existing Jcode project MCP entries need one refresh before conductor or dashboard starts. Once per project, the person runs:
+
+```bash
+ahub jcode --mode headless
+ahub init
+```
+
+The first command starts Jcode and rewrites only the hub-owned `agent-hub-jcode` entry in `.jcode/mcp.json`, adding its delivery-only marker. Foreign or overriding entries refuse instead of being overwritten. `ahub init` keeps an untracked machine-path file out of git; review a tracked file deliberately. Daemon readiness checks never rewrite this entry. See [Jcode operations](operations.md#optional-jcode-peer).
+
+Task owners running as Pi or `local` need the isolated test capability for non-PII `implement`, `test` and `bulk_edit` work. A person sets `checks.runner` to `"container"` in untracked `.agenthub/config.local.json`; the Apple container service and pinned image must also be available. Issue-backed owners additionally need spec access. Manual messages remain available, and PII work retains its local-only routing. See [bounded check requirements](security.md#bounded-task-specs-and-isolated-checks-418) before enabling the runner.
+
 ## First session
 
 In your project directory, one terminal each:
@@ -68,6 +81,8 @@ or set `OMNIROUTE_API_KEY`. Name the model in `.agenthub/routing.toml` (`[local]
 | `ahub say [@peer] <text>` | talk; start with `[STATUS]` to let it batch, `[FYI]` for the record only |
 | `ahub task propose [--class <c>] <title>` | put work on the board; the hub picks an owner and a reviewer, and the class if you name none |
 | `ahub board` | who has what; `ahub task show <id>` for one task |
+| `ahub task cancel <id> --reason <text>` | close obsolete work without approving it or stopping a native turn |
+| `ahub settings set planner <peer>` | pin the planner; status reports whether it came from settings, roles or the automatic choice |
 | `ahub status` | peers, queues, pauses; `ahub budget` for quota windows |
 | `ahub memory profile-check` | a person's read-only check of running memory bindings in the current registry |
 | `ahub ask <question>` | what the board, shared memory and the log say, with the ids the answer rests on |
@@ -80,7 +95,7 @@ More: `ahub help`. How it is built and why: [`docs/specs/2026-09-19-agent-hub-de
 
 The hub exact-pins the first-party `@staix/agent-mem` 0.3.0 core. Existing shared-v1 memory remains the default; upgrading does not migrate it. Managed agents use screened `hub_memory_search`, `hub_memory_show` and `hub_memory_graph` tools, or propose a correction with `hub_memory_correct`; only a person accepts candidates through the supported `amem review` path. Generation candidate acceptance is still refused.
 
-Before any real generation migration, upgrade every hub sharing that memory home to 0.12.30 and check its authenticated binding with `ahub memory profile-check` in each custom registry. Ready bindings prove compatibility, not an atomic live cutover: quiesce consumers and close their handles before migrating, then reopen through the supported session-preserving lifecycle. Invalid or changed profiles disable native memory without falling back to legacy writes; the bus and board continue. See [memory operations](operations.md#hub-memory) for the remaining rollout gates.
+Before any real generation migration, upgrade every hub sharing that memory home to 0.12.30 or later and check its authenticated binding with `ahub memory profile-check` in each custom registry. Ready bindings prove compatibility, not an atomic live cutover: quiesce consumers and close their handles before migrating, then reopen through the supported session-preserving lifecycle. Invalid or changed profiles disable native memory without falling back to legacy writes; the bus and board continue. See [memory operations](operations.md#hub-memory) for the remaining rollout gates.
 
 ## Browser dashboard
 

package/docs/security.md

@@ -31,7 +31,7 @@ The portable core is the exact-pinned first-party `@staix/agent-mem` 0.3.0 packa
 
 The hub binds the selected root/profile at open. Invalid/missing generation metadata refuses native memory without a shared-v1 fallback; the bus and board continue. Explicit checks at hub operation entry and before sidecar writes stop later stale calls, but are not atomic against a selector change during an in-flight core operation. Migration therefore requires quiescing consumers and closing handles before changing selection, then reopening through the supported lifecycle. A public core pre-write hook is the upgrade path for atomic in-flight cutover.
 
-Before migrating any real home, every hub sharing it must first be on 0.12.30 with positive authenticated binding or unbound/quiesced proof from `ahub memory profile-check` in each relevant registry. An unknown or unreadable runtime is not proof of absence, and a matching ready binding still holds a handle that must be closed. Profile-check reports only its named registry inventory. Root paths, selector receipts and malformed-legacy counts are person-local diagnostics, excluded from ordinary peer status and allowed agent CLI reads. Source/fixture checks do not establish native capture, real migration or account/device-sync success.
+Before migrating any real home, every hub sharing it must first be on 0.12.30 or later with positive authenticated binding or unbound/quiesced proof from `ahub memory profile-check` in each relevant registry. An unknown or unreadable runtime is not proof of absence, and a matching ready binding still holds a handle that must be closed. Profile-check reports only its named registry inventory. Root paths, selector receipts and malformed-legacy counts are person-local diagnostics, excluded from ordinary peer status and allowed agent CLI reads. Source/fixture checks do not establish native capture, real migration or account/device-sync success.
 
 ## What is not defended
 
@@ -82,7 +82,7 @@ Inside an agent session, `ahub` identifies the caller from `AGENTHUB_PEER_ID`,
 or the native Claude/Codex shell marker when the hub marker is absent. It connects
 as that peer in tools mode. Messages and task changes retain that actor;
 `say` defaults to status priority and important messages still require the peer's
-capability. Conflicting or malformed markers fail closed. There is no `--as-user`.
+capability. Conflicting or malformed markers fail closed. Refusals name only the marker variable names actually present, never their values. There is no `--as-user`.
 By default, console operations are refused before connecting, including permission answers
 and permission modes, queue resolution, budget overrides, benchmark runs, research
 backfill and task labels, stopping a peer (`ahub stop`), lifecycle and recovery
@@ -316,3 +316,31 @@ plain terminal pet reads and `pet --palette` remain available to agent shells;
 the palette write merges only the closed name into `.agenthub/config.local.json`,
 validated and replaced by temp file and rename. Signed pidfiles
 fence instance ownership and close; unknown owners are never signalled.
+
+## Planner, cancellation and delivery authority
+
+The `planner` setting is person-controlled. A valid pin determines the planner without adding it to the roster; otherwise configured rostered planner roles apply, then the first rostered peer in the closed planner catalog. The automatic choice is not written to disk. Planner guidance does not grant conductor authority or bypass roster, PII, WIP or owner capability checks.
+
+`cancelled` is closed, never approval. The person can cancel non-approved work with a reason and optional supersession reference; the configured planner can cancel only its own proposed/backlog work with no historical acceptance. Current task revision, privacy and recovery/shutdown holds are checked before writing and again after awaited screening. Cancellation preserves history, releases reservations and overlap membership, writes no outcome memory, and does not stop native turns or delete branches/worktrees. Owner/reviewer stop notices remain relevant; earlier task requests become moot. Dependents remain blocked and receive ids-only advice, including backlog dependents.
+
+Current daemons advertise `task_cancel` in hello and status metadata. A current CLI refuses cancellation against a daemon without that feature. Controlled upgrade/restart refuses an unsupported target while cancelled task ids exist; source prepare and commit recheck compatibility, and the rows are never rewritten as approved. A manually started older binary is outside this compatibility guarantee: it can display cancelled rows as open or fail to move them.
+
+Stall causes are persisted and deduplicated by cause and replanning revision. Planner advice joins its next delivery as bounded ids-only context; it does not manufacture an ordinary task turn. Pull-only offer attention clears only after acceptance, decline, supersession or durable positive evidence for that exact offer and recipient. Operator/hub completion of an uncertain delivery is not evidence that the offer was read.
+
+`hub_delivery_retry` grants an eligible recipient one retry of its own `needs_review` work, never completion/discard authority or pause removal. Durable per-original evidence survives journal pruning; unknown retry history or a used retry requires the person. Hub presence prefaces are excluded from attempted-work identity, so a shared context preface does not consume an unrelated message's retry. Delivery-only local and ACP peers (including Jcode) cannot invoke recipient retry; tool exposure hints do not replace the daemon's actual-adapter guard. Their held work requires person resolution. Before transport handoff, storage failure preserves the queue and preface; after handoff an uncertain effect is never automatically replayed.
+
+## Bounded task specs and isolated checks (#418)
+
+`hub_task_spec` reads only the GitHub issues named by a current owner's or reviewer's task in this project's origin repository, including the validated canonical GitHub intake source when its title/body has no issue token. Bare `#N` references count only in the title; detail references require `owner/repo#N` or `https://github.com/owner/repo/issues/N`. Bare detail numbers denote hub tasks, and arbitrary file paths are not parsed as issue references. A qualified reference cannot begin after a slash or a name character, so `src/hub/tasks.ts#12` is a file path. Routing uses this same parser. Without a GitHub project identity, bare title numbers do not require spec access, but explicit qualified/URL references, `refs.repo` and imported GitHub identity still fail closed. The daemon resolves authenticated and container executables outside the project, pins their absolute paths and uses fixed arguments; repository-writable PATH shims are refused. Runner Git resolves its host executable through a restricted PATH. For specs, the model receives no credential or arbitrary authenticated URL capability. Foreign/transferred issues, more than three references, bodies over 64 KiB and aggregate results over 80 KiB fail explicitly. Spec fetches share a 25-second budget inside the control client's 30-second cap; each gh call remains bounded to 15 seconds. Current PII, secret and private-path policy withholds the complete spec rather than returning a partial contract. PII turns and PII tasks refuse these tools. The independent `spec_read` and `check_run` capabilities apply when a peer has a narrowed capability list. Arguments and results are excluded from capture. Proven deterministic pre-effect guards return PreEffectToolRefusal so Pi settles the exact refusal receipt; generic transport/storage failures and failures after durable receipt/output changes remain uncertain, never reclassified from error text.
+
+`hub_check_start` accepts only a current owner's in-progress task, its recorded branch/commit and either `typecheck` or one to 32 existing `test/*.test.ts` paths. `checks.runner = "container"` is a person opt-in in an untracked config file; a tracked config cannot grant it. Missing service/image, an unverified internal network, stale task/owner/native generation, unavailable dependencies or an invalid path fails closed. There is no host-shell, network or Seatbelt fallback.
+
+The runner uses Apple `container`, pinned Bun 1.4.2 and a verified `hostOnly` internal network with DNS disabled, two CPUs and 4 GiB. It starts a named, labeled VM with a bounded idle process, copies a hub-owned snapshot into the running VM, then invokes a fixed `container exec` check. This run/copy/exec sequence is required because Apple `container copy` rejects a stopped container. No host directory, home, credential directory, hub state or socket is mounted. Source blobs are read from the exact Git commit; symlinks and gitlinks anywhere in the source refuse the run before exclusions. Directory prefixes and filenames are checked for NFC/Unicode case-fold collisions before staging writes, including denied entries; folding must reach a fixed point within a bounded number of passes or the run refuses. This is a conservative collision screen, not a claim of exact parity with every host filesystem. Denied and PII paths are excluded and counted. Dependency files require an equal lockfile, bounded regular files/directories and internal relative symlinks. No dependency installation or Internet access occurs in the VM.
+
+Dependency copies detect observed inode, size and timestamp changes and refuse final-component symlinks using `O_NOFOLLOW`. A same-user writer can still exchange and restore a parent directory between observations; this is not an atomic immutable-dependency guarantee. Source commits remain immutable. Do not treat a dependency copy as protection against a hostile process running as the same host user.
+
+Checks serialize through the repository's existing `ahub-heavy.lock`, with one active and at most two queued runs, a ten-minute execution ceiling after heavy-slot admission and a bounded heavy-slot wait. Container startup has a 120-second cap for cold VM boot, and copy has a 180-second cap for the bounded 512 MiB source plus 1 GiB dependency corpus. Each stage is clamped to the remaining ten-minute budget and uses the same cancellation signal; exec receives only the remaining budget. Network/probe commands retain a 15-second cap, also clamped and cancellable during an admitted run. Named-container cleanup has its separate bounded teardown commands and must still be confirmed before releasing the heavy slot. Queued cancellation settles its receipt and releases queue capacity immediately; active cancellation, timeout and shutdown stop only the named check container. Cleanup is confirmed through inventory before releasing the heavy slot; unknown cleanup keeps the slot and reports an error. Startup removes only this project's labeled containers whose signed recorded hub owner is confirmed gone. Unknown owners are reported for the person, never killed.
+
+Only an unchanged task/owner/native-generation binding receives an agent result. Stale receipts are person-only. Public receipts include the exact source/tree/lockfile, runner/platform, command, exit and bounded output; they omit internal host paths, owner process identity and generation binding. The output tail is screened again before any tool response or hub envelope. For inactive valid receipts, local full output is bounded to 1 MiB and removed when the owner reads its result (person inspection does not consume it), after 24 hours or beyond the newest 20 outputs; at most 200 inactive valid receipts remain, with active runs excluded from retention. Unknown receipts are an explicit retention exception: malformed/unreadable receipt bytes, full output and source staging remain until ownership/inactivity can be established or the receipt is removed. Their ID-only warnings remain visible. Unknown payload maintenance performs no path-based deletion: a same-user process can swap a parent directory after an entry check, and no atomic descriptor-relative cleanup is available at this boundary. Maintenance never removes an unknown container. Removing the whole receipt directory counts as an empty record set, clears its ID warnings and allows ordinary expired unindexed-staging cleanup. Linux VM evidence is separate from macOS Seatbelt and managed-native acceptance.
+
+Routing receives capability availability and its reason as pure inputs. Capability admission applies to task owners only: non-PII implement/test/bulk-edit owners require tests, and non-PII issue-backed owners in every class (including review-class owners) require spec access. Designated reviewers are not gated by these owner-only capabilities; roster, privacy, role and other eligibility rules still apply. PII tasks are exempt from these two capability requirements and retain the existing local-only owner and person reviewer rules; spec/check tools still refuse them. Explicit nominations and reservations cannot bypass these checks. Inactive sandboxed peers establish their GitHub probe at first spec use, and every explicit local/Pi start path refreshes it (including a prior authentication failure) with concurrent probes shared; host-provided embeddings can inject bounded probe implementations without implicitly contacting real accounts in fixtures. Neither path grants a model control over the probes.

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

@@ -1287,7 +1287,9 @@ session modes (`default`, `plan`, `auto`, `yolo`) but nothing per server or tool
 ## Reliability follow-ups, 0.12.1 (#89-#95)
 
 - Delivery retries exhausted for an owned open task trigger escalation through `Tasks`, with a redacted reason and a console notice. Delivery health skips peers after three consecutive exhausted deliveries until a completed delivery clears the streak.
-- `needs_review` continues to hold a peer's queue. Console notices, status and assignment explanations identify the hold and operator commands; moved or approved task references are context for the operator, never automatic discard authorization.
+- `needs_review` holds uncertain work that still matters. The hub settles a row `completed` only when every original is a hub presence item or a hub task/review notice provably moot for its recipient: an approved or cancelled task (except its cancellation stop notice), a review no longer in review for that reviewer, or a notice whose authoritative `refs.taskRecipient` audience (`owner` or `reviewer`) is no longer current. Hub producers tag current-owner notices, reviewer reminders and planner coordination separately; former-owner stop notices and former-owner/former-reviewer withdrawal notices use untagged kind `task` and stay held until task approval or cancellation, because their purpose is to tell the former role to stop. Task-kind reviewer reminders remain live while the recipient is that in-review reviewer. Planner notices and untagged legacy task-kind notices stay held until approval or cancellation: without an audience marker, sender/kind/task id cannot prove that an owner assignment moved. This conservative legacy ceiling preserves still-live coordination and guidance. Unknown tasks, live recipient notices and mixed peer/user rows remain held. Rows whose recorded reason starts with `requested stop:` are never completed automatically, even when their tasks become approved. `supersededDeliveryReason` alone authorizes completion; a separate pure `deliveryTaskContext` retains ids-only approved/moved task context for mixed rows without authorizing settlement. Status, console notices and console/peer/tool route explanations list every hold once, including sender, kind and age; public explanations screen appended hold lines through the current privacy policy and keep task context ids-only. Classify on entry, after restore, after the daemon releases its recovery hold and on board changes; use the existing resolve path with a recorded hub actor, preserving pauses and Tasks state. Hub completion restores presence originals through the same preface merge and transaction rollback path as retry, preserving shared notes for the next queued delivery; person completion remains consumed (#434).
+- A Claude session without channel support returns `failed_safe` before the push reaches the model, preserving originals for pull. If an older daemon rejects that receipt, the plugin falls back once to its prior generation-bound `needs_review` receipt instead of leaving the row dispatching. A thrown `server.notification` remains `needs_review`: the MCP SDK delegates to a transport whose stdout write can already have emitted bytes before an exception is observed, so the exception alone cannot prove no frame left. Existing proven pre-acceptance guards in Codex, ACP, Pi and the local worker remain unchanged. Console-only command refusals name only the inherited identity marker keys actually present (never their values), explain `!` commands, and direct the person to a separate terminal or `ahub console` (#434).
+- `hub_delivery_retry { delivery_id }` lets an authenticated recipient retry only its own current `needs_review` row. This option is offered only to transports with an independent tool turn (Claude channel/pull, Codex and Pi). The delivery-only local worker and headless ACP peers cannot start a tool turn through their own hold, so they do not advertise this tool and the daemon refuses a manual call before mutation. Their held hints ask the person to resolve the row; ordinary messages never bypass the hold. Kimi TUI remains pull-only and keeps the recipient option. An ephemeral delivery-only MCP marker controls exposure and hint copy only; the current adapter class is the authority. There is no action or reason input: `completed` and `discard` remain person-only. Any explicit retry in that recipient's lineage, including a person's retry, consumes this allowance; a redelivery held again stays for the person. The existing resolution transaction records `peer:<id>` and a fixed reason, keeps original envelopes unchanged and requeues them through the existing put-back path. A busy recipient may consent to this queue-only operation, but delivery waits for idle and all pause/recovery and active-delivery fences remain. The rendered clone reserves the existing journal body cap for the warning, clipping only the clone at a Unicode character boundary with an explicit cut marker when needed; originals remain unchanged. Jcode project MCP entries carry the same delivery-only exposure marker as other headless ACP peers, preserving their own configuration and peer identity rules. Final rendered output, after condensation and on pull or steer, starts with the fixed sanitized header `Hub redelivery warning: An earlier attempt of this delivery is uncertain; check for its effects before acting.` Explicit retry history is scoped by recipient and original envelope ids. A separate monotone consumed-proof projection records one proof id and warning provenance per original, leaving resolution audit rows unchanged. Explicit resolution and coalesced handoff inherit that proof atomically for every grouped non-context original; a rejected checkpoint consumes no fresh allowance. Hub presence originals carry mutable recall/shared context whose id survives merging, so their ids never participate in retry proof lookup, inheritance, warnings or unknown marking. A preface shared with earlier work cannot consume an unrelated new message's retry allowance; actual task/chat originals retain their consumed lineage. Safe-failure requeue, withdrawal of an earlier original, terminal-state changes, pruning, restart or older-writer audit replacement cannot renew the allowance. Older attempt-bearing rows backfill this projection on return. Recovery snapshots without history and unmappable pruned pre-feature retry records mark only their affected recipient/original ids unknown: those lineages require a person, while unrelated new messages keep their allowance. Tool results expose held metadata only (total count, ids, senders, kinds and age), at most 32 rows/4 KiB with explicit truncation; no body or task text enters the hint. These hints work independently of channel mode and do not wait behind the held queue (#434).
 - Local attach and idle model/route replacement require a reachable authenticated gateway, served models and successful minimal availability calls. Busy workers refuse replacement; validation failure leaves the current worker intact. Controlled recovery can reconstruct a manually paused local worker without gateway availability, but manual resume validates its restored choice before lifting the pause. Doctor checks the fixed model against the inventory.
 - Reviewer routing appends attached peers holding `roles.reviewer` after the review class's candidates. Without a reviewer, task results and console notices explain direct approval and the skipped candidates.
 - Conflict detection includes `in_review` work. Completed overlapping snapshots that share files generate one concurrent-edit notice per task pair/file, containing both turn ids and attributing the changes to neither peer. Private tasks and sensitive file names remain redacted.
@@ -1321,7 +1323,8 @@ to that socket, and a live accepted journal row. This acknowledgement is not pro
 of a native turn boundary. Failed notifications, disconnects, replaced sessions
 and interrupted daemon instances retain `needs_review`, with no automatic replay.
 A person inspects and resolves uncertain work through the existing revision-fenced
-`ahub queue` commands. Older source protocols 9, 10 and 11 remain authenticated
+`ahub queue` commands; #434 also permits an addressed peer with an independent tool turn one explicit
+`hub_delivery_retry`, with the transport, warning and lineage limits above. Older source protocols 9, 10 and 11 remain authenticated
 upgrade sources; ordinary clients must use protocol 12 (13 from 0.12.4, with 12 a source).
 
 ## Amendment: stale overlap notices (issue #106)
@@ -1495,7 +1498,13 @@ Unicode cell widths, fall back below 80x24, and restore terminal state on exit.
 Tabs change with the digits 1 to 5 or with Left and Right, wrapping at both
 ends, with the digit's guards and resets (an arrow under a confirmation dismisses
 it like any key but y, without moving a tab); a read holding nothing but arrow
-sequences is that many key presses, never a paste. An Events row's header is
+or Home/End sequences is that many key presses, never a paste. Home or `<` selects
+the first row of a panel and End or `>` the last (Home tops an open view); the
+Events panel follows new events while its selection is on the last row, keeps a
+row the person moved to, and opening it or changing its filter selects the newest
+row (#441). In panels `w` opens the project dashboard (`ahub ui`) and `o` the pet
+window (`ahub pet --window`) as a person's console command; the `:` line also
+accepts `ui` and `pet` (#452). An Events row's header is
 tokenized by the stream's own tokenizer on the same tab-flattened text, with the
 event's tone and kind; body lines stay plain, and selection changes only the
 `>` marker. The tail prints a peer's context reading once and repeats it only
@@ -3022,3 +3031,28 @@ One explicit profile binding is used by daemon Tasks, read tools, briefs/recall/
 Candidates/counters remain at the independent root `M/candidates.db` using the package's explicit sidecar home API. They are neither migrated into `G` nor synced. Selector changes fence Tasks candidate producers and retained telemetry callbacks as well as native note operations; asynchronous privacy work rechecks binding before side effects. Standalone generation `amem review` remains unsupported and refuses; this change adds neither candidate acceptance nor dashboard acceptance for generations.
 
 PII authority, complete-row host screening, capture exclusion, byte budgets and fail-open task delivery remain unchanged. Memory/goal domain JSON remains unchanged; `memoryProfile` is additive only in daemon status, profile-check and the decay object. Synthetic integration must show bridged legacy reads, cross-writes through the package CLI and daemon tools, failure without fallback for invalid/missing generation state, and no note/candidate/counter writes for calls begun after a selector change while bus service remains available. Source/fixture evidence does not authorize real installation, migration or session restart. Real rollout requires separately approved deployed versions and matching live root/profile/selector bindings, synthetic canaries and quiesced/closed/reopened handles. Every running hub using this home needs an authenticated receipt: a matching ready binding, or a generation-capable unbound receipt (`disabled` when native memory is off, `unavailable` when opening failed) proving it holds no memory handle. An unbound daemon and zero running hubs are quiesced for memory; a stale bound handle, unreadable registry or unknown runtime is not ready. Native capture, account/device sync and real memory receipts remain open until observed.
+
+### Bounded sandboxed-peer capabilities (#418)
+
+The frozen issue #418 contract supplies task-bound `hub_task_spec` and the finite `hub_check_start/result/cancel` tools; memory reads reuse #412 P2. `checks.runner = "container"` remains an untracked, person-owned opt-in. Specs include validated canonical GitHub intake identity as well as bounded textual references and remain complete-or-refused; checks run immutable Git source in a credential-free, internal-network Linux VM with fixed commands and binding-scoped receipts. Default sandbox permissions remain unchanged.
+
+Apple container 1.5.0 requires a running VM for `copy`. The implementation therefore uses `run --detach --rm` with the fixed bounded idle process, copies the validated source/dependencies, executes only the selected finite check argv and confirms cleanup. A create/copy/start probe failed on the stopped-container copy and left no container; the run/copy/exec probe passed. `--internal` is verified as network configuration `mode: hostOnly`, not an inferred network name. Inactive sandboxed peers establish the cached spec authentication probe at first start/use rather than making unrelated host-embedding fixtures contact real accounts. Source and dependency staging ceilings are 100,000 entries each, 512 MiB source and 1 GiB dependencies; exceeding one refuses the check.
+
+Without a GitHub project identity, bare title issue numbers require no spec capability; qualified GitHub references, issue URLs, explicit repository refs and imported external issues still require it and fail closed at the repository boundary. Malformed receipts remain visible as unknown ids and never prevent startup. Unknown receipt bytes, full output and source staging are retained until ownership/inactivity can be established or the receipt is removed, an explicit exception to normal retention. Unknown containers require confirmed ownership/inactivity before cleanup; removing a receipt never authorizes their removal. Unknown payloads are never deleted through path-based entry checks, which cannot prevent a same-user parent-directory swap at this boundary. Removing the receipts directory is an empty record set, clearing obsolete unknown warnings and allowing normal expired staging cleanup.
+
+Evidence: `docs/verification/2026-10-17-418-probes.md`. The feasibility probe is Linux/arm64 Apple-container evidence, not a managed-Pi or macOS security acceptance receipt. Issue #418 stays open until its managed-Pi live and independent review gates pass.
+
+## Amendment: designated planner (#455)
+
+`config.roles` is derived from the policy roles (defaults, then each file's `roles` block) by `settlePlanner` in the daemon, in place, so Tasks reads the same object. A `planner` key (`config.json` or `config.local.json`, local wins; one of `PLANNER_PEERS`, which excludes the hub-sandboxed pi and local) makes that peer the only planner. With no key the `roles` planners stand; when none of them is on the roster, the first rostered `PLANNER_PEERS` entry plans (`automatic`), recomputed at start, on each policy refresh and after a roster change, never written to disk. The `planner` setting (group Roles, live, risk raises) is the one write path; status carries `planner: { peers, source }` and `roleInfo[peer].planner`. Planning authority and backlog notices follow at once; role text in a peer's instructions follows at its next start. A pinned planner that leaves the roster leaves the project without a planner until a person changes the setting. Planning operations that await a PII screen (pull, plan, split, new release) recheck planner authority after the await, before their board write.
+
+
+## Amendment: task stalls, exact offer attention and cancellation (#438)
+
+- Ready ownerless tasks retain the ordinary routing decision and reservation guards. A persisted cause/replanning signature admits one ids-only console and supervision notice for an ineligible reserved peer, no eligible peer or a cancelled dependency. Repeated release passes with the same cause add neither history nor notices; a changed cause or explicit replanning admits one new notice. The designated planner (the settled configured planner roles) receives bounded ids-only advice in its next preface, while the configured supervision stream receives the structured item under its existing scope. Advice does not manufacture an ordinary task turn beside a stale backlog batch. Without a planner, the console attention list remains the recipient. Existing owner/reviewer ladders remain unchanged.
+- A current proposed offer to a pull-only peer remains console attention until acceptance, decline, supersession or positive delivery evidence for that exact offer envelope and recipient. Tasks records the original envelope id, assignment revision and offer-time pull-only classification before publication. This classification survives detach and restart; current attachment is not evidence that an unread offer disappeared. Actual adapter completion, a correlated reply or a completed pull records positive evidence atomically with journal completion, surviving terminal pruning and reopening. Accepted-only receipts, unrelated inbox activity and operator/hub completion are not read evidence. Advisory queries never dequeue, steer or settle work. Decoded offer/stall candidates are cached by board revision and live eligibility inputs; positive journal read evidence is checked afresh. The derived revision advances atomically with task and stall writes, independently of unrelated delivery-journal writes.
+- The disabled-by-default sweep adds `ready-unassigned` with `ready_min: 60`. A ready proposed ownerless task follows the existing deterministic, restart-safe ladder, without treating quiet stall/offer bookkeeping as activity. A person-unassigned task stays suppressed until explicit person assignment or reservation. Planner-pulled work retains reserved-only/WIP admission, and a saved-but-undelivered reassignment does not stop the remaining sweep. Cancellation does not satisfy a dependency. This change does not enable any project's live sweep configuration.
+- `cancelled` is terminal and retained. The person may cancel backlog, proposed, in-progress, in-review or changes-requested work, never approved work. A configured planner tool may cancel only its own backlog/proposed task with no historical acceptance. `Tasks.cancel` validates the optional flow revision, screens the reason/reference and rechecks authority, revision and recovery/shutdown exclusion after asynchronous screening before the sole board mutation. History retains actor, reason and optional supersession reference. After the cancellation write commits, advisory cleanup and notices cannot change its successful result. No outcome memory, native cancellation, branch deletion or dependent release occurs.
+- Cancellation releases overlap/reservation participation and sends each distinct former owner/reviewer one stop notice. Its trusted cancellation revision marker keeps that stop notice relevant; earlier notices for the cancelled task become moot under #434. The classifier never uses timestamps alone to identify the stop notice. Dependents keep waiting and receive the cancelled-dependency cause. List, show, explain, dashboard and release projections treat cancellation as closed, retaining the current privacy screen and distinguishing cancellation from successful approval.
+- The daemon advertises `task_cancel` in hello and status features. Current clients refuse cancellation without that feature. Upgrade and restart persist the verified target's exported features with its immutable root/digest before prepare, including cached targets, and reuse that receipt on resume after verifying the same bytes. A legacy staged receipt without feature evidence is probed only while a project is not yet past commit; fully committed projects do not require another probe. This preserves #215: a transient probe failure cannot refuse a target that was already staged with verified evidence. Preflight checks only uncommitted sources and refuses a target lacking `task_cancel` while cancelled rows exist. Source prepare/commit recheck before holds/snapshots and around asynchronous work; cancellation cannot write through recovery preparation. Refusals name task ids and never rewrite rows. An older binary started manually can misclassify cancelled rows as open or fail to move them; this is the explicit unsupported compatibility ceiling. Never map cancellation to approval.
+- The post-release live step remains separate: do not cancel the historical task or enable the project's sweep from implementation tests. AC7 needs installed-runtime receipts.

package/docs/specs/2026-09-20-upgrade-recovery-design.md

@@ -249,11 +249,36 @@ itself is not distinguished from a slow one, and whether Orca reports the bare
 login shell as TUI-idle is not verified: if it does, the create stops at once as
 not mappable to the session; if not, after the 10-minute readiness bound. Either
 way it blocks as needing manual verification with the receipt `pending`, and the
-next resume, finding no live launcher and no attached session, records `failed`. Resume settles a `pending` or `failed` receipt by what is live
-(the table below): an attached planned (or accepted) session is the
-restoration, a launcher that may run is waited for, and only nothing live makes
-it `failed` or, for `failed`, launches again. No terminal is created while a
-recorded launcher for the peer may run on the target or its session is attached.
+next resume, finding no live launcher and no attached session, records `failed`.
+After a new terminal becomes ready, or a `pending` or `failed` receipt finds a
+verified live launcher of the current target, the coordinator saves that exact
+handle, incarnation and worktree before waiting up to 600 seconds for the
+planned (or accepted) session to attach. The restore receipt is an explicit
+tagged union: `pending`, `waiting` with `origin` (`pending` for a new launch, or
+`failed`) and `binding`, `done` with `binding`, or `failed`. A missing receipt
+means no launch has been attempted. Only the compatibility decoder reads released older
+string/bare-binding receipts; new writes use the tagged states. The never-released
+development attachmentReceipt marker is refused rather than inferred as a state. Interruption and
+timeout retain the waiting receipt, and resume waits on that binding without
+adopting a replacement.
+An idle terminal alone is not attachment proof. Each poll checks the selected
+launcher's signed identity. Only that exact launcher being gone and the target
+reporting no attached session or other live launcher exits the wait: a
+pending-origin wait records `failed` and exposes the failed-restoration choices;
+a failed-origin wait returns to `failed` and retries the launch. A launcher
+record not written yet keeps polling within the same bound. A signed ended row
+for a different handle is not a current record for the chosen terminal. An
+attached session with no id keeps that same wait after all older-launcher
+checks; an offline saved id does not count as attachment or bypass those
+checks. A current record arriving between observations continues polling only
+when its handle, incarnation and worktree match the saved binding. Unknown
+records and live replacements still block. An unreadable launcher identity, changed
+terminal binding or unreadable target blocks without recording failure.
+Successful attachment records `done` after exact terminal/session revalidation.
+A `done` receipt only revalidates its saved binding; an exited launcher cannot
+turn it into `failed` or offer a fresh session. No terminal is
+created while a recorded launcher for the peer may run on the target or its
+session is attached.
 A launch that failed, or a thread found not resumable before the launch, is
 receipted `restored:<peer>` = `failed` and never counts as restored. A Codex
 store that cannot be read (other than missing) is unknown and blocks the plan,
@@ -268,7 +293,7 @@ Status. `ahub recovery status <id>` reports the receipt (phase, step, update
 time, error); whether a runner process holds the operation now (`runner.state`
 `running` with its pid, or `none`); `stale` when the receipt says `running` but
 no runner holds it; each project's phase and effect receipts (`closed:<peer>`,
-`restored:<peer>` as `done`, `pending` or `failed`); whether the shared plugin
+`restored:<peer>` as `done`, `pending`, `waiting:pending`, `waiting:failed` or `failed`); whether the shared plugin
 and the global CLI were installed; any lost continuity and disposition; and
 `next`, the commands that apply now. It never contains task or message text.
 `resume` does not start a second runner while one is alive.
@@ -439,9 +464,9 @@ An attached session is the target's report of that peer online with a thread
 | project `prepared`, no `commitSent`, operation of a #215 coordinator | source stopped (crashed before any commit request) | blocks; the phase stays `prepared` (nothing was committed, so there is nothing to start from); not offered | abort if no effects, dispose | `<c> recovery abort <id>` without effects, else stop-and-archive (the lock refuses starting that hub by hand) |
 | project `prepared` | source unavailable, starting, stopping or not inspected | as above when it reads again | none: abort (its hold may still stand) and stop-and-archive are refused until it reads | `<c> recovery status <id>` once it answers |
 | project `prepared`, operation of an older coordinator (no `commitSent` written) | source not running, or not inspected | as its own runner does | dispose once it reads running, stopped or missing; abort neither offered nor accepted (it may have committed) | `<c> recovery status <id>` |
-| project `started` or `peers-restored` | target stopped (a crash or reboot after it started), this operation's snapshot kept | records the restart (dead instance, time), retires the dead instance's done `restored:<peer>` receipts, moves the project back to `stopped` and starts the target from the snapshot; once per resume | dispose | `the target stopped after it started; resume restarts it from this operation's snapshot` (`stopped again after restart <n> in this resume` when it stops again) |
+| project `started` or `peers-restored` | target stopped (a crash or reboot after it started), this operation's snapshot kept | records the restart (dead instance, time), retires the dead instance's done and waiting `restored:<peer>` bindings, moves the project back to `stopped` and starts the target from the snapshot; once per resume | dispose | `the target stopped after it started; resume restarts it from this operation's snapshot` (`stopped again after restart <n> in this resume` when it stops again) |
 | project `started` or `peers-restored` | target stopped, snapshot gone | blocks; not offered | dispose | `this operation's restart snapshot is gone, so nothing can start it` |
-| `retired:<peer>` (a done restoration of a dead target instance) | Orca lists its terminal, or cannot be read | closed under the close receipt rules (`closedRetired:<peer>` `pending` until Orca no longer lists it); an unreadable inventory changes nothing | dispose | `close Orca terminal <handle> by hand` or `check it in Orca`, `then <c> recovery resume <id>` |
+| `retired:<peer>` (a done or waiting restoration of a dead target instance) | Orca lists its terminal, or cannot be read | closed under the close receipt rules (`closedRetired:<peer>` `pending` until Orca no longer lists it); an unreadable inventory changes nothing | dispose | `close Orca terminal <handle> by hand` or `check it in Orca`, `then <c> recovery resume <id>` |
 | project `stopped` | target stopped without this operation's snapshot (never committed) | blocks; not offered | dispose | `the target is stopped and this operation's restart snapshot is gone` |
 | project `stopped`, `started` or `peers-restored` | target running unfenced, as another instance or another version | blocks; not offered | dispose | `daemon is not owned by this recovery operation` (or `daemon instance changed`, `target daemon version mismatch`) |
 | any, at staging | preserved source or staged target changed, or (first staging of these bytes only) target protocol or recovery waivers refused | blocks; recorded as `final`, so resume is never offered again | abort if no effects, dispose | the refusal |
@@ -451,7 +476,14 @@ An attached session is the target's report of that peer online with a thread
 | `closed:<peer>` done | peer attached again | blocks | dispose | `end that <peer> session, then <c> recovery resume <id>` |
 | `restored:<peer>` `pending` or `failed` | session attached with the planned id (or an accepted new one: fresh choice, planned fresh start, zero-turn Claude) | recorded as restored | none: `--fresh-session` is neither offered nor accepted while the inspection shows the planned session attached; when it cannot tell (not inspected, target unreadable), the `failed` receipt alone decides, and a chosen fresh session whose original then attaches is cleared on resume while its audit entry stays | none |
 | `restored:<peer>` `pending` or `failed` | another session attached | blocks | dispose | `end that <peer> session and close its terminal, then <c> recovery resume <id>` |
-| `restored:<peer>` `pending` or `failed` | no session, recorded launcher live or unknown | blocks | dispose | `wait until it attaches, or end it and close terminal <handle>, then <c> recovery resume <id>` |
+| `restored:<peer>` `pending` or `failed` | no session, verified live launcher of the current target | records `waiting {origin, binding}` with the exact binding, waits up to 600 s for authenticated attachment; timeout retains both for resume | dispose | `attachment not verified within 600 s; terminal <handle> retained; resume after it attaches` |
+| `restored:<peer>` `pending` or `failed` | no session, a live launcher belongs to an older target instance | blocks, retains the original receipt; no terminal created | dispose | end that launcher and close its terminal, then `<c> recovery resume <id>` |
+| `waiting {origin, binding}` | the planned or accepted session attaches | runs the ordinary settlement rules, writes a waiver for an accepted replacement or clears `fresh` when the planned session returns, exactly revalidates the selected terminal and clears the waiting origin | none while the planned session is attached | none |
+| `waiting {origin, binding}` | selected launcher gone, but an older target instance's launcher remains live or unknown | blocks and retains the selected binding and waiting origin; no failure or retry is inferred | dispose | end or verify the older launcher, then `<c> recovery resume <id>` |
+| `waiting {origin, binding}` | selected exact signed launcher gone, target confirms no session or other live launcher | pending origin (including a new launch): records `failed` and blocks; failed origin: records `failed` and retries the launch | fresh session (Codex, Claude), dispose | the failed-restoration choices below |
+| `waiting {origin, binding}` | selected identity unreadable, replacement terminal, or target unreadable | blocks, retains exact binding and waiting origin; never adopts a replacement or treats unknown as gone | dispose | verify the saved launch or target, then `<c> recovery resume <id>` |
+| `waiting {origin, binding}` | no current launcher record (including a confirmed-ended other-handle row), with no session or an id-less attachment and no older live/unknown launcher | polls within the same 600 s bound; timeout retains waiting | fresh-session only for waiting:failed (subject to ordinary choices), dispose | `waiting:<origin>`; resume uses the same exact binding |
+| `done {binding}` | launcher gone or no session attached | blocks exact restoration verification, retains done and its resumable conversation; never launches again or records failed | dispose; no fresh-session | resume the recorded conversation; `done` |
 | `restored:<peer>` `pending` | no session, launcher gone or never recorded | receipted `failed`, blocks | fresh session (Codex, Claude), dispose | the failed-restoration choices below |
 | `restored:<peer>` `failed` | no session, launcher gone or never recorded | launches again (fresh if chosen) | fresh session (Codex, Claude), dispose | the failed-restoration choices below |
 | `restored:codex` absent | rollout missing | receipted `failed`, blocks, no terminal created | fresh session, dispose | the failed-restoration choices below |
@@ -463,6 +495,48 @@ An attached session is the target's report of that peer online with a thread
 | disposition recorded, not finished | any | refused | stop-and-archive only | `rerun <c> recovery dispose <id> --stop-and-archive --reason <text>` where `disposeRefusal` allows it, else `wait until <project>'s hub settles, then <c> recovery status <id>` |
 | `completed` or `cancelled` | any | nothing to do | none | none |
 
+The restore transition function is `restoreTransition` in
+`src/cli/upgrade-restore-state.ts`. Its generated table below is checked byte for
+byte by `test/upgrade-restore-state.test.ts`; the Cartesian test separately
+checks all 540 receipt/evidence/choice cells. `settle` and `revalidate` propose a
+state only: the runtime commits it after authenticated session and exact
+terminal validation. Fresh-session eligibility is shared by status, interactive
+operation lines and refusal messages: only `failed` and `waiting:failed` expose
+it, further narrowed by Pi, an existing choice, a planned fresh start, target
+waiver support and the planned session already being attached.
+
+Restore transition table (generated).
+
+Cells show action -> next receipt status. Fresh-session eligibility is marked fresh; peer/operation-specific restrictions still apply. Exact terminal revalidation and settlement must succeed before persisting a proposed done receipt.
+
+| Priority condition | Decision |
+|---|---|
+| Target stopped or changed | block -> unchanged |
+| Running target, other session not allowed | block -> unchanged |
+| Absent receipt | unstarted; initial launch is handled by the runtime outside this receipt table |
+
+Running target, no attached session (either allowOther value):
+
+| Receipt | live | gone | unknown | no-record-yet | replaced | older-instance |
+|---|---|---|---|---|---|---|
+| pending | poll -> waiting:pending | fail -> failed; fresh | block -> pending | fail -> failed; fresh | block -> pending | block -> pending |
+| waiting:pending | poll -> waiting:pending | fail -> failed; fresh | block -> waiting:pending | poll -> waiting:pending | block -> waiting:pending | block -> waiting:pending |
+| waiting:failed | poll -> waiting:failed; fresh | create -> failed; fresh | block -> waiting:failed; fresh | poll -> waiting:failed; fresh | block -> waiting:failed; fresh | block -> waiting:failed; fresh |
+| done | block -> done | block -> done | block -> done | block -> done | block -> done | block -> done |
+| failed | poll -> waiting:failed; fresh | create -> failed; fresh | block -> failed; fresh | create -> failed; fresh | block -> failed; fresh | block -> failed; fresh |
+
+Running target, planned session or explicitly allowed other session (different decisions are labeled):
+
+| Receipt | live | gone | unknown | no-record-yet | replaced | older-instance |
+|---|---|---|---|---|---|---|
+| pending | settle -> done | settle -> done | settle -> done | settle -> done | settle -> done | settle -> done |
+| waiting:pending | settle -> done | settle -> done | block -> waiting:pending | settle -> done | block -> waiting:pending | block -> waiting:pending |
+| waiting:failed | settle -> done | settle -> done | block -> waiting:failed; fresh | settle -> done | block -> waiting:failed; fresh | block -> waiting:failed; fresh |
+| done | planned: revalidate -> done; other: block -> done | planned: revalidate -> done; other: block -> done | planned: revalidate -> done; other: block -> done | planned: revalidate -> done; other: block -> done | planned: revalidate -> done; other: block -> done | planned: revalidate -> done; other: block -> done |
+| failed | settle -> done | settle -> done | settle -> done | settle -> done | settle -> done | settle -> done |
+
+End of generated restore transition table.
+
 The failed-restoration choices are `<c> recovery dispose <id> --fresh-session
 <peer> --reason <text>` (Codex or Claude; records the lost session and resumes;
 if the original session attaches after all, the recorded loss is cleared) and
@@ -490,7 +564,7 @@ replaces the record of a Codex already running.
 #225: a target that stopped after it started is restarted only while its state
 directory holds this operation's unreleased snapshot. The runner records the restart
 in the project's receipt (`restarts`: the dead instance and the time) before acting,
-moves each done `restored:<peer>` binding to `retired:<peer>`, clears the instance
+moves each done or waiting `restored:<peer>` binding to `retired:<peer>`, clears the instance
 and moves the project back to `stopped`, whose path starts the target from the
 snapshot; the journal imports the snapshot only at revision 0, so the second start
 continues from what the first wrote. `closed:<peer>`, `commitSent`, `fresh`, waivers

package/docs/verification/2026-10-17-0.12.31.md

@@ -0,0 +1,71 @@
+# 0.12.31 release verification
+
+This record covers release preparation and source review. It does not claim publication, installation, a running-hub restart or native/live acceptance.
+
+## Candidate
+
+Version 0.12.31, control protocol 16 (`src/hub/control-client.ts`), from merged main `09bfd51b5c00b9e8e584693cef135cc2f21ad3a7`. The candidate includes all 14 PRs merged since `v0.12.30`: #435, #436, #440, #442, #443, #444, #448, #453, #454, #456, #458, #459, #460 and #461. Every body and final head was read back; intermediate PR evidence is historical where the final head differs. The exact first-party memory pin remains `@staix/agent-mem` 0.3.0.
+
+- After upgrade, run `ahub jcode --mode headless` once per Jcode project before conductor or dashboard starts of Jcode to update the owned MCP entry. It requires a running daemon with Jcode on the roster and starts Jcode; it is a person operation, not a readiness check or an action performed during preparation.
+- Cancellation requires a daemon advertising `task_cancel`; current clients and controlled downgrade paths refuse incompatible versions while cancelled rows exist. An older binary started by hand remains outside that guarantee. Cancelled work is closed history, never approval and never a released dependency.
+- `seeded guards` is now required alongside both OS checks. The live branch-protection readback during preparation listed exactly `check (ubuntu-latest)`, `check (macos-latest)` and `seeded guards`; the latter succeeds only after all four shards.
+- Local/Pi non-PII implement/test/bulk_edit owners need an enabled, available isolated runner; issue-backed owners need authenticated bounded spec access. PII and designated-reviewer exemptions remain. Source and CI evidence does not close installed managed-Pi #418 AC8.
+- Planner designation, task stalls/offers, recipient retry and recovery changes retain their task/privacy/transport fences. #439 live settings reload is not included and remains frozen for this release.
+
+## Document review
+
+The initial `node scripts/check-docs.mjs --require-fresh` reproduced 13 stale documents. Each was compared against its covered source changes from `79a113dfc4395a0e00890ba8b8d2d90bb289ee9f` through main `09bfd51b`, then against the release metadata and generated assets. Current symbols and numeric limits were checked, not inferred from commit counts. No document review is deferred. The already-fresh models note retains its stamp.
+
+| Document | Prior source stamp | Review result | Checked claims and correction |
+| --- | --- | --- | --- |
+| `README.md` | `79a113dfc4395a0e00890ba8b8d2d90bb289ee9f` | corrected | Version/protocol, planner and closed cancellation, isolated owner admission, Jcode refresh and explicitly open live legs; routing, board, hub tools and Jcode entry checked. |
+| `docs/agent-notes/README.md` | `79a113dfc4395a0e00890ba8b8d2d90bb289ee9f` | unchanged | Console attention exact-row identity and human background remain accurate after the console navigation/event changes. |
+| `docs/agent-notes/adapters.md` | `79a113dfc4395a0e00890ba8b8d2d90bb289ee9f` | corrected | Pre-effect classification after durable receipt/output changes; task/session/privacy fences, actual-adapter retry authority and failed_safe fallback. |
+| `docs/agent-notes/benchmarks.md` | `79a113dfc4395a0e00890ba8b8d2d90bb289ee9f` | unchanged | Covered source commits have no net benchmark-runner/sandbox contract change; retained benchmark ceilings and teardown rules still match. |
+| `docs/agent-notes/budget.md` | `79a113dfc4395a0e00890ba8b8d2d90bb289ee9f` | corrected | Context PII association uses the shared closed-state predicate, excluding cancelled tasks while preserving a private turn fence. |
+| `docs/agent-notes/bus.md` | `79a113dfc4395a0e00890ba8b8d2d90bb289ee9f` | corrected | Exact positive offer-read evidence and cancellation revision-bound stop notices; existing presence-excluded retry and delivery-only refusal rules verified. |
+| `docs/agent-notes/daemon.md` | `79a113dfc4395a0e00890ba8b8d2d90bb289ee9f` | corrected | Immutable target-feature evidence, prepared commitSent bounded polling and tagged restore receipt origin/binding rules. |
+| `docs/agent-notes/local-worker.md` | `79a113dfc4395a0e00890ba8b8d2d90bb289ee9f` | unchanged | Retry tool filtering and bounded-tool capture exclusions match the existing central instructions; sandbox/path/permission contracts are unchanged. |
+| `docs/agent-notes/tasks.md` | `79a113dfc4395a0e00890ba8b8d2d90bb289ee9f` | corrected | Cancelled is closed but never approval, persisted pull-only offers, planner authority, ready-sweep admission and owner-only capability exemptions. |
+| `docs/agent-notes/tests.md` | `79a113dfc4395a0e00890ba8b8d2d90bb289ee9f` | corrected | Delivery-only fixture marker stripping, .bun-version, dual-OS/aggregate seeded release checks and separated publish/release credential authority. |
+| `docs/operations.md` | `79a113dfc4395a0e00890ba8b8d2d90bb289ee9f` | corrected | Presence-excluded retry, bounded Pi access and inactive/unknown receipt retention, durable offer attention, guarded ready sweep, cancellation and cached-feature/resume behavior; current 0.12.31 guide/header/upgrade examples and protocol range, existing planner and console keys verified. |
+| `docs/quickstart.md` | `79a113dfc4395a0e00890ba8b8d2d90bb289ee9f` | corrected | 0.12.31 example, one-time person-run Jcode refresh, opt-in check/spec requirements and planner/cancel commands; memory migration prerequisite remains 0.12.30 or later. |
+| `docs/security.md` | `79a113dfc4395a0e00890ba8b8d2d90bb289ee9f` | corrected | Planner/cancel/version refusal, exact offer and retry evidence, marker names, explicit non-GitHub references, Unicode staging collision screen and active/unknown retention exceptions. |
+
+Reviewed baseline source `fce7777f208f4885cf6524c4403fd5048cfe8f8b` contains the generated assets. A subsequent source review corrected the operations guide header, explicit upgrade targets and protocol-16 release range to 0.12.31, and clarified the unchanged minimum memory-profile migration prerequisite as 0.12.30 or later. The historical warning about the 0.12.30 CLI mislabelling waiting receipts is intentionally preserved. The original stamp follow-up advanced the 13 reviewed entries to corrected source `56ae16dfd69d3c72bcc1f4efdabbda1905f75b9c`. A later wording pass clarifies that Jcode refresh requires an already-running daemon and precedes conductor or dashboard starts of Jcode, attributes required seeded guards to the repository setting after #458, and restores tag-on-main refusal and Dependabot actions coverage. The unstamped `docs/memory.md` also now says 0.12.30 or later. The README stamp names the reviewed wording commit `6637a383c3f46ae173b14268d29c8b0d306eac95`; the other 12 reviewed entries and the already-fresh models entry remain unchanged.
+
+Source review is distinct from native/runtime verification. The release PR must use a merge commit so every source stamp remains an ancestor; before tagging, rerun committed freshness. A separate manifest commit follows the reviewed source and generated assets, without stamping itself.
+
+## Recorded checks
+
+GitHub readback verified each run below is completed successfully and its `headSha` exactly matches the PR's final head. Both OS check jobs and `seeded guards` succeeded for every row. Earlier runs used the sequential seeded job; rows with sharded CI also had all four shards and the aggregate green. These prior PR gates do not replace the release candidate's own exact-head CI.
+
+| PR | Final head | CI run | Recorded result |
+| --- | --- | --- | --- |
+| [#435](https://github.com/STAIxBWLB/agent-hub/pull/435) | `c135f8827aa76d482fa7938edd80a63677c52718` | [38997048821](https://github.com/STAIxBWLB/agent-hub/actions/runs/38997048821) | Both OS checks and sequential seeded guards SUCCESS |
+| [#436](https://github.com/STAIxBWLB/agent-hub/pull/436) | `d336b895eb556e6c674e8c4ae9dc7838fda581d4` | [38987274924](https://github.com/STAIxBWLB/agent-hub/actions/runs/38987274924) | Both OS checks and sequential seeded guards SUCCESS |
+| [#440](https://github.com/STAIxBWLB/agent-hub/pull/440) | `df55c6b45bea7fd219d28d6f634410d5f5c3c36f` | [38993748843](https://github.com/STAIxBWLB/agent-hub/actions/runs/38993748843) | Both OS checks and sequential seeded guards SUCCESS |
+| [#442](https://github.com/STAIxBWLB/agent-hub/pull/442) | `45420bed8b70e99d7d3865a66530c76a7bba9e6e` | [38987497318](https://github.com/STAIxBWLB/agent-hub/actions/runs/38987497318) | Both OS checks and sequential seeded guards SUCCESS |
+| [#443](https://github.com/STAIxBWLB/agent-hub/pull/443) | `3094d3f2ffdb73a4086b6215e5807208557df245` | [39010001473](https://github.com/STAIxBWLB/agent-hub/actions/runs/39010001473) | Both OS checks; four seeded shards and aggregate SUCCESS |
+| [#444](https://github.com/STAIxBWLB/agent-hub/pull/444) | `8eee1da65712109df3d25f361e209c207ce3c25f` | [38990131100](https://github.com/STAIxBWLB/agent-hub/actions/runs/38990131100) | Both OS checks and sequential seeded guards SUCCESS |
+| [#448](https://github.com/STAIxBWLB/agent-hub/pull/448) | `37bf6b863eacdea273d5957ca67c9b871cee4ad9` | [39011678855](https://github.com/STAIxBWLB/agent-hub/actions/runs/39011678855) | Both OS checks; four seeded shards and aggregate SUCCESS |
+| [#453](https://github.com/STAIxBWLB/agent-hub/pull/453) | `876824867a254bcfa99726b61999a46ed2bfd939` | [38997592343](https://github.com/STAIxBWLB/agent-hub/actions/runs/38997592343) | Both OS checks and sequential seeded guards SUCCESS |
+| [#454](https://github.com/STAIxBWLB/agent-hub/pull/454) | `ee338b3459ab809d13dbdc3de22fc306d0a9bd15` | [39004948075](https://github.com/STAIxBWLB/agent-hub/actions/runs/39004948075) | Both OS checks; four seeded shards and aggregate SUCCESS |
+| [#456](https://github.com/STAIxBWLB/agent-hub/pull/456) | `5541bcf1c01ef21008d4ab7fd60b7127ac8a808b` | [39004850799](https://github.com/STAIxBWLB/agent-hub/actions/runs/39004850799) | Both OS checks; four seeded shards and aggregate SUCCESS |
+| [#458](https://github.com/STAIxBWLB/agent-hub/pull/458) | `9104e00b5b0b742656b24f2d40e731bf0a054748` | [39002544473](https://github.com/STAIxBWLB/agent-hub/actions/runs/39002544473) | Both OS checks; four seeded shards and aggregate SUCCESS |
+| [#459](https://github.com/STAIxBWLB/agent-hub/pull/459) | `757c47e613d289dee9edac388276f87e0e72317a` | [39012529459](https://github.com/STAIxBWLB/agent-hub/actions/runs/39012529459) | Both OS checks; four seeded shards and aggregate SUCCESS |
+| [#460](https://github.com/STAIxBWLB/agent-hub/pull/460) | `0625808d12eccfc21c15bb902b9901ae5b4f0db8` | [39016099853](https://github.com/STAIxBWLB/agent-hub/actions/runs/39016099853) | Both OS checks; four seeded shards and aggregate SUCCESS |
+| [#461](https://github.com/STAIxBWLB/agent-hub/pull/461) | `4789b436aeb75d337141a14b800486b40fa93f82` | [39018722513](https://github.com/STAIxBWLB/agent-hub/actions/runs/39018722513) | Both OS checks; four seeded shards and aggregate SUCCESS |
+
+- Hosted preparation [39020520475](https://github.com/STAIxBWLB/agent-hub/actions/runs/39020520475) ran `bun install --frozen-lockfile` and `bun run build` at metadata source `e59c5551c7e31fe93767185575f404f5ab64da9f`. Only actual generated plugin assets were copied back; no dependency tree was copied. Later edits are documentation only and do not change bundle inputs.
+- Generated `server.js`: 618526 bytes, SHA-256 `1bc69dee0b1fbdf7b6f08904212fd2a869ac6401157076a26a6784f83f7540cf`. Plugin manifest: 379 bytes, SHA-256 `d7c1ba72407bae6c658ac0ddfc0a3f9b8e4ac9239931aafb9efdd41fd8ce5c74`, version 0.12.31.
+- The final committed candidate requires `node scripts/check-docs.mjs --require-fresh --committed` and its own exact-head CI with both `scripts/check.sh` gates, all four seeded shards and aggregate before merge. The tag workflow independently checks main ancestry, fresh documentation and successful identical-tree CI.
+
+## Not verified by this record
+
+- Installed managed-Pi #418 AC8 / task #142 remains open. This preparation does not run managed tools against the person's active session, enable the container runner, install code or restart frozen-schema sessions.
+- #438 AC7 remains open: no live task cancellation or sweep enablement was performed. Fixture/CI cancellation, attention and sweep tests are not native operational receipts.
+- Native/live legs in #273 and #1 remain open according to their ledgers; no source-only or historical evidence is promoted to native success.
+- Previously unrun #412 P5 legs L03 (real claude-mem import), L04 (real model suggestions/person confirmation) and L05 (visual Memory/Long-term checks) are not completed by this release.
+- The person's package/plugin installation, running-hub upgrade/restart, recovery/session continuity, real-home migration and remote memory synchronization require separate authorized operational readbacks.
+- npm publication/provenance and the GitHub Release are later workflow outcomes, not actions or results of release preparation.

package/docs/verification/2026-10-17-418-probes.md

@@ -0,0 +1,21 @@
+# #418 isolated runner feasibility
+
+- Observed: 2026-10-17 KST, Apple container CLI 1.5.0, Bun 1.4.2, Linux/arm64 VM.
+- Exact source: `7d470afe86b0dc0d9ff4f80701731aa869c922e4`.
+- Image: `oven/bun@sha256:9114c058aeae42162ee16dd5084b95fe9473970bb6bcb5b232ab1630f0546895`.
+- Network: `agenthub-check`, verified configuration `mode: hostOnly`, verified internal gateway, no DNS.
+- Source: Git blobs from the named commit; no source symlinks/gitlinks. Dependency lockfile equal to the source; regular dependency tree with internal relative links copied, no host mount.
+- Admission: ran after the admitted #433 native gate completed. Earlier admission deferrals were honored; no memory worker or other session was stopped.
+
+## Results
+
+- `container create` succeeded; copying into its stopped VM failed explicitly with `container ... is not running`. The created container was removed. This alternative is not used.
+- `container run --detach --rm` with the pinned image, internal network, no DNS, two CPUs, 4 GiB and bounded idle process succeeded.
+- Source/dependency copy into the running VM succeeded.
+- `container exec --workdir /work <name> bun test test/control-client.test.ts`: 12 pass, 0 fail, 36 assertions, exit 0. These unchanged repository tests bind their own loopback servers.
+- Separate fixed isolation probe: VM loopback server returned `pong`; `/root/.config/gh` absent; HTTP connection attempts to both observed host gateways on the hub control port and Internet `1.1.1.1` failed within bounded waits; exit 0.
+- Kill succeeded and `--rm` removed the VM. Subsequent container inventory contained no probe container. Unrelated containers were preserved.
+
+## Limits
+
+This proves the selected transfer and Linux runtime mechanism on this Mac. It does not certify a managed Pi calling the new tools, a deployed daemon, macOS Seatbelt behavior, another Mac, failing-check receipt handling or every lifecycle negative. Those require the implementation fixtures and issue #418 live rows. No fallback removal, daemon restart or security-policy change was performed.

package/docs/verified.json

@@ -2,7 +2,7 @@
   "schemaVersion": 1,
   "documents": {
     "README.md": {
-      "verifiedAgainst": "79a113dfc4395a0e00890ba8b8d2d90bb289ee9f",
+      "verifiedAgainst": "6637a383c3f46ae173b14268d29c8b0d306eac95",
       "paths": [
         "package.json",
         "src/",
@@ -11,14 +11,14 @@
       ]
     },
     "docs/security.md": {
-      "verifiedAgainst": "79a113dfc4395a0e00890ba8b8d2d90bb289ee9f",
+      "verifiedAgainst": "56ae16dfd69d3c72bcc1f4efdabbda1905f75b9c",
       "paths": [
         "src/",
         "templates/"
       ]
     },
     "docs/operations.md": {
-      "verifiedAgainst": "79a113dfc4395a0e00890ba8b8d2d90bb289ee9f",
+      "verifiedAgainst": "56ae16dfd69d3c72bcc1f4efdabbda1905f75b9c",
       "paths": [
         "package.json",
         "src/",
@@ -35,7 +35,7 @@
       ]
     },
     "docs/quickstart.md": {
-      "verifiedAgainst": "79a113dfc4395a0e00890ba8b8d2d90bb289ee9f",
+      "verifiedAgainst": "56ae16dfd69d3c72bcc1f4efdabbda1905f75b9c",
       "paths": [
         "package.json",
         "src/",
@@ -43,7 +43,7 @@
       ]
     },
     "docs/agent-notes/adapters.md": {
-      "verifiedAgainst": "79a113dfc4395a0e00890ba8b8d2d90bb289ee9f",
+      "verifiedAgainst": "56ae16dfd69d3c72bcc1f4efdabbda1905f75b9c",
       "paths": [
         "src/adapters/",
         "src/pi/",
@@ -62,7 +62,7 @@
       ]
     },
     "docs/agent-notes/benchmarks.md": {
-      "verifiedAgainst": "79a113dfc4395a0e00890ba8b8d2d90bb289ee9f",
+      "verifiedAgainst": "56ae16dfd69d3c72bcc1f4efdabbda1905f75b9c",
       "paths": [
         "scripts/benchmarks/",
         "test/benchmarks/",
@@ -74,7 +74,7 @@
       ]
     },
     "docs/agent-notes/budget.md": {
-      "verifiedAgainst": "79a113dfc4395a0e00890ba8b8d2d90bb289ee9f",
+      "verifiedAgainst": "56ae16dfd69d3c72bcc1f4efdabbda1905f75b9c",
       "paths": [
         "src/hub/budget.ts",
         "src/cli/statusline-tee.ts",
@@ -86,7 +86,7 @@
       ]
     },
     "docs/agent-notes/bus.md": {
-      "verifiedAgainst": "79a113dfc4395a0e00890ba8b8d2d90bb289ee9f",
+      "verifiedAgainst": "56ae16dfd69d3c72bcc1f4efdabbda1905f75b9c",
       "paths": [
         "src/hub/bus.ts",
         "src/hub/envelope.ts",
@@ -98,7 +98,7 @@
       ]
     },
     "docs/agent-notes/daemon.md": {
-      "verifiedAgainst": "79a113dfc4395a0e00890ba8b8d2d90bb289ee9f",
+      "verifiedAgainst": "56ae16dfd69d3c72bcc1f4efdabbda1905f75b9c",
       "paths": [
         "src/hub/daemon.ts",
         "src/hub/control-client.ts",
@@ -135,7 +135,7 @@
       ]
     },
     "docs/agent-notes/local-worker.md": {
-      "verifiedAgainst": "79a113dfc4395a0e00890ba8b8d2d90bb289ee9f",
+      "verifiedAgainst": "56ae16dfd69d3c72bcc1f4efdabbda1905f75b9c",
       "paths": [
         "src/adapters/local-worker.ts",
         "src/local/",
@@ -155,7 +155,7 @@
       ]
     },
     "docs/agent-notes/tasks.md": {
-      "verifiedAgainst": "79a113dfc4395a0e00890ba8b8d2d90bb289ee9f",
+      "verifiedAgainst": "56ae16dfd69d3c72bcc1f4efdabbda1905f75b9c",
       "paths": [
         "src/hub/tasks.ts",
         "src/hub/board.ts",
@@ -172,7 +172,7 @@
       ]
     },
     "docs/agent-notes/tests.md": {
-      "verifiedAgainst": "79a113dfc4395a0e00890ba8b8d2d90bb289ee9f",
+      "verifiedAgainst": "56ae16dfd69d3c72bcc1f4efdabbda1905f75b9c",
       "paths": [
         "test/",
         "scripts/check.sh",
@@ -191,7 +191,7 @@
       ]
     },
     "docs/agent-notes/README.md": {
-      "verifiedAgainst": "79a113dfc4395a0e00890ba8b8d2d90bb289ee9f",
+      "verifiedAgainst": "56ae16dfd69d3c72bcc1f4efdabbda1905f75b9c",
       "paths": [
         "src/cli/console-state.ts",
         "src/cli/attention.ts",

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@staix/agent-hub",
-  "version": "0.12.30",
+  "version": "0.12.31",
   "description": "Native multi-agent hub: Claude Code, Codex, Kimi Code, Pi and local inference as peers in one project",
   "license": "MIT",
   "type": "module",

package/plugins/agent-hub/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "agent-hub",
-  "version": "0.12.30",
+  "version": "0.12.31",
   "description": "Channel between Claude Code and the agent-hub daemon: peer messages from Codex, Kimi and the local worker arrive as channel events; hub_send replies.",
   "author": {
     "name": "Young Joon Lee",