@staix/agent-hub 0.29.0 → 0.31.0

package/docs/verification/2026-11-03-grok-1.0.62-t0.md

@@ -0,0 +1,150 @@
+# Grok 1.0.62 project MCP and hooks T0, 2026-11-03
+
+T0 receipt for #635, task #325. This probes the project-file TUI alternative to the [earlier ACP receipt](2026-10-21-grok-config-acp-t0.md). It does not establish launcher implementation, model-backed delivery, or native turn-end readiness.
+
+## Result
+
+| Leg | Result | Direct evidence |
+| --- | --- | --- |
+| Pinned native version | VERIFIED | `--version` exited 0: `grok 1.0.62 (1474f9cbdd91)` |
+| Project MCP configuration discovery | VERIFIED | `mcp list --json` reported `receipt`, `scope: project`, from `.grok/config.toml` |
+| Project MCP trust gate and connection | VERIFIED, synthetic server only | Untrusted doctor refused to start the server; after an isolated fixture trust grant, doctor initialized it and discovered one tool |
+| `search_tool` / `use_tool` to a hub tool | UNVERIFIED | Both credential-free `--single` attempts exited 1 with `Not signed in`; no `tools/call` was recorded |
+| Interactive trust prompt | UNVERIFIED | An untrusted PTY startup reached sign-in before any folder-trust prompt; authentication discovery could not proceed with network denied |
+| Hook configuration load | VERIFIED | Trusted `inspect --json` listed seven configured project event handlers, including `stop`; untrusted inspect listed none |
+| Hook firing and stdin payloads | UNVERIFIED | No credential-free model/session turn began, and the passive payload sink was never created |
+| Real configuration preservation | VERIFIED for nine named files | Before/after SHA-256 or absence matched for every entry listed below |
+
+Decision for the following launcher task: the pinned build recognizes a main-session `Stop` hook configuration, separately from `SubagentStop`. This is loader evidence, not evidence that a successful main turn fires it or that its payload is sufficient for hub facts/turn end. Keep the proposed peer pull-only unless a later isolated authenticated receipt proves main-turn completion and its payload. Do not infer hook absence from the account refusal, or turn-end support from configuration load alone. #635 stays open.
+
+## Isolation and preparation
+
+- Base checkout: `df230f2c89d0545c1a87cfd6bb8be57505a92c6c`. Branch: `test/635-grok-t0`; dedicated worktree `.worktrees/test-635-grok-t0`.
+- Before native probes, dgx02 ran `bun install --frozen-lockfile` at that base and asserted the installed first-party dependency against `package.json`: `@staix/agent-mem@0.20.1`. No repository runtime or inherited local `node_modules` was used by the native probes; the MCP fixture used only system Python.
+- The native executable was copied as one file from the installed Grok binary into a private OS-temporary root. Its SHA-256, before and after the probes, was `ec434e831afdcfce87780f2815fd732b1df8a4a8de96a491716ad75d13605a4e`.
+- Separate empty directories were supplied as `HOME`, `GROK_HOME`, `XDG_CONFIG_HOME`, `XDG_CACHE_HOME`, `XDG_DATA_HOME` and `TMPDIR`. A new throwaway Git project held the project MCP/hooks files; a second sibling project was used for the untrusted TUI probe.
+- The child environment was an explicit allowlist: those six directories, a scratch/system-only `PATH`, `SHELL=/bin/sh`, `TERM=xterm-256color`, `LANG=en_US.UTF-8`, `USER=probe`, `LOGNAME=probe` and `NO_COLOR=1`. No account variables, inherited agent markers or personal configuration were copied.
+- Every Grok invocation ran through macOS `sandbox-exec`, denying network, reads/writes under the person's real home, writes under `/etc` and `/Library`, and access to the securityd Mach service. Before the TUI probe, execution of `/usr/bin/open` and `/usr/bin/osascript` was also denied. These are probe controls, not a product sandbox claim.
+- Stateful commands explicitly passed `--no-leader --no-auto-update`. The subprocess harness bounded each command to 12 seconds, then signalled only its newly created process group. The PTY observation window was five seconds. No Grok process remained in the final fresh process-table read.
+- The first PTY capture harness had an EOF-drain bug after its native child exited: the Python harness stayed alive reading EOF. Only that identified probe-owned harness was terminated; EOF handling was corrected before the second capture. No native completion or teardown result is inferred from the discarded first capture.
+
+## Project MCP and trust
+
+The project's `.grok/config.toml` contained this self-contained fixture (`$PROBE_ROOT` below means the absolute temporary root substituted before writing TOML):
+
+```toml
+[mcp_servers.receipt]
+command = "/usr/bin/python3"
+args = ["$PROBE_ROOT/tools/mcp.py"]
+startup_timeout_sec = 3
+[mcp_servers.receipt.env]
+PROBE_LOG = "$PROBE_ROOT/evidence/mcp-events.jsonl"
+```
+
+The synthetic stdio MCP server answered `initialize` using the requested protocol version, declared a tools capability and `serverInfo` of `isolated-receipt-fixture` / `1.0.0`, and answered `tools/list` with one tool named `hub_inbox`. Its description and possible result explicitly said synthetic fixture. It was not a production hub, did not attach to this repository's running daemon and did not establish a real hub-tool result.
+
+Observed command sequence after fixture creation:
+
+```sh
+grok --no-leader --no-auto-update inspect --json
+grok --no-leader --no-auto-update mcp list --json
+grok --no-leader --no-auto-update mcp doctor receipt --json
+grok --no-leader --no-auto-update --trust inspect --json
+grok --no-leader --no-auto-update mcp doctor receipt --json
+```
+
+Every command above used the copied binary, isolated environment and sandbox wrapper. Before trust, inspect reported `projectTrusted: false` and `hooks: []`; MCP list still enumerated the project definition. Untrusted doctor exited 1 and reported:
+
+```text
+folder untrusted
+repo-local (project-scoped) server not started for an untrusted folder
+re-run with --trust to allow repo-local servers
+```
+
+The explicit `--trust` was a controlled grant to this disposable fixture, not launcher behavior or a grant to a real project. It persisted only in the isolated `$GROK_HOME/trusted_folders.toml`:
+
+```toml
+[folders."$PROBE_ROOT/project"]
+trusted = true
+```
+
+Afterward, trusted inspect reported `projectTrusted: true`. Doctor exited 0 with `command found`, `server started`, `handshake OK` (`protocol 2025-11-25`) and `1 tools discovered`; `healthy_count: 1`, `failing_count: 0`. The fixture recorded exactly:
+
+```text
+initialize
+notifications/initialized
+tools/list
+```
+
+Initialize's `clientInfo` was `grok-shell-receipt` / `1.0.62`. No `tools/call` occurred. A discovered tool is not proof of the model's meta-tool path.
+
+## Model/tool and interactive prompt limits
+
+Before and after the isolated trust grant, bounded single-turn commands requested the fixture hub tool. The trusted request was:
+
+```sh
+grok --no-leader --no-auto-update \
+  --single 'Find receipt__hub_inbox with search_tool, call it with use_tool, and report its result.' \
+  --max-turns 1 --disable-web-search --no-memory
+```
+
+Both attempts exited 1, without a model turn or hook payload, and reported:
+
+```text
+Not signed in. To authenticate without a browser, run:
+  grok login --device-code
+```
+
+An initial syntax-only attempt incorrectly supplied `--single` without its required adjacent prompt value and exited 2; it is not a model/tool probe result. The corrected commands above are the evidence.
+
+A separate untrusted project was launched under a PTY using `--no-leader --no-auto-update --no-alt-screen --minimal --no-memory`. It displayed sign-in and an authentication discovery failure for `https://auth.x.ai/.well-known/openid-configuration`, then exited 0. No folder-trust prompt was observed, no sibling trust entry appeared, no browser execution was permitted, and no hook payload was produced. Exit 0 here does not prove a successful session. No personal account, cached token, API key or real-home fallback was used; these legs stop at authentication.
+
+The locally shipped MCP guide documents qualified `server__tool` catalog keys and `search_tool` / `use_tool`, so `receipt__hub_inbox` was the requested key. That documented route remains UNVERIFIED in a native model turn. To finish this leg, use an independently authorized account in a fresh isolated home and a disposable real hub, then capture the meta-tool dispatch and the actual hub result; do not reuse the person's home.
+
+## Hooks and payloads
+
+The fixture `.grok/hooks/receipt.json` registered command handlers for `SessionStart`, `UserPromptSubmit`, `Stop`, `StopFailure`, `StopCancelled`, `SessionEnd` and `SubagentStop`. Each handler used the same passive script, with a two-second hook timeout:
+
+```sh
+#!/bin/sh
+/bin/cat >> "$PROBE_ROOT/evidence/hook-payloads.jsonl"
+/bin/echo >> "$PROBE_ROOT/evidence/hook-payloads.jsonl"
+```
+
+The actual generated script contained the absolute sink path. It did not deny actions or invent events. Trusted inspect listed these native event names:
+
+```text
+session_start
+user_prompt_submit
+stop
+stop_failure
+stop_cancelled
+subagent_stop
+session_end
+```
+
+The sink remained absent, so there are no observed hook stdin payloads to publish. In particular, this receipt has no observed `sessionId`, `hookEventName`, `lastAssistantMessage`, stop/interrupt discriminator or main-session/subagent binding. The shipped hooks guide describes `Stop` for genuine main-turn completion, `StopFailure` for API failure, `StopCancelled` for non-completion and `SubagentStop` for subagents, and documents camelCase fields plus compatibility aliases. These are documented hypotheses for the authenticated follow-up, not captured payload facts. Merely registering `SubagentStop` cannot establish main-turn completion.
+
+The local shipped guide bytes consulted were identified by SHA-256 (their documentation content does not substitute for native runtime evidence):
+
+| Guide | SHA-256 |
+| --- | --- |
+| `07-mcp-servers.md` | `67558820ab3f0c49d56f87ce9d6927f2d6d179558f7a1e0466750a9771a43c3a` |
+| `10-hooks.md` | `2a3a12201597fa6ab1885fa473096565a6c99fbfaf656627c65fa15653e14970` |
+| `02-authentication.md` | `f16e7fe4cecc2836643d3474dbbc6c2b4a0ea12edf2b56b8a5a0a4ecb24efbec` |
+
+## Real configuration hashes
+
+Only the controller computed SHA-256/absence of these named real `~/.grok` files, without printing or copying their contents. Grok itself could not read that home. All nine entries matched after the final native probe. This is a bounded inventory, not a claim about every native configuration path.
+
+| File | Before and after |
+| --- | --- |
+| `config.toml` | `cbafbea937a8ad50323aed808e68912706a063c7c88868a8fd9f58252bb68f22` |
+| `version.json` | `182eeb64f0fe20c17ddea37071954ff25b1424f3b807fea13697754c803439f7` |
+| `trusted_folders.toml` | `4e9eee9a1a037d109d59ed1d8112795f55381465cd219266b2f1777d4ec8b945` |
+| `auth.json` | SHA-256 matched; credential-file digest omitted from the public receipt |
+| `config.json`, `settings.json`, `mcp.json`, `managed_config.toml`, `requirements.toml` | Absent before and after |
+
+## Repository validation
+
+The final committed receipt is checked with `scripts/check.sh --changed` on dgx02; the PR and task submission record the exact head and gate result. Hosted CI is independent. No compatibility registry, launcher, generated bundle or native support claim is changed by this documentation-only T0.

package/docs/verification/2026-11-03-pi-150-compat.md

@@ -0,0 +1,40 @@
+# Pi 1.5.0 model-free compatibility receipt
+
+Date: 2026-11-03. Task #684, Refs #888. This repeats the [Pi 1.4.0 receipt](2026-10-26-pi-140-compat.md) for the published `@earendil-works/pi-coding-agent@1.5.0`. Same legs, model-free, no account.
+
+**Decision: add `1.5.0` to Pi `verified`.** Every leg passed. No range is inferred: the Pi entry still has no `line`, so any other version needs the person's `ahub agents trust pi <version>`.
+
+## Identity and isolation
+
+- Package: `@earendil-works/pi-coding-agent` 1.5.0, installed from the registry into a private npm prefix with a scratch HOME, cache and temporary directory and empty npm user and global config files. The person's `~/.pi` and global packages were not touched. npm held back two lifecycle scripts (`protobufjs` postinstall, a version-scheme warning, and `@google/genai` preinstall, an `echo`). They were read and judged inert for this probe, and were not replayed: the producer passed without them, and no flag was added to make it pass.
+- npm integrity: `sha512-xNDZ5kqowO6Z03FS2gwAkPEGk1ssxVcYKQ6qZId84mFEvwACvvyc2l0vAMOS+c5zvxLRMLBE9r4y44IGYkMJaQ==`. The package carries no `gitHead`.
+- Native `dist/cli.js` SHA-256: `8189b66abc4f9f431dbb70941dcba690d76d040de1fbfff212886be35a53639d`. This is the same value the 1.4.0 receipt records for its `dist/cli.js`, so the launcher entry file did not change between the two releases. The 1.5.0 changes are in other files of the package and are exercised by the legs below.
+- Host: macOS arm64, Bun 1.4.3, Node 24.18.1, repository at `9eb10e34e8fa3624669d08828ac0ca65b8ec2041`.
+- Each native run used an empty temporary HOME and `PI_CODING_AGENT_DIR`, a temporary cwd and session directory and an environment of PATH, those paths and invented loopback bridge settings. No account, token, prompt or inference.
+- Real configuration: SHA-256 of every file under the person's `~/.pi/agent` (excluding sessions, logs, caches, installs and `bin`) and `~/.qwen`, plus the person's `pi` launcher binary and the listing of installed Pi releases, was taken before and after the producer run: 9551 entries, identical.
+
+## Results
+
+| Leg | Result | Evidence |
+| --- | --- | --- |
+| Native identity | pass | `--version` returned exactly `1.5.0`, exit 0, empty stderr; package name and version checked independently. |
+| Real CLI extension load and RPC session identity | pass | `--mode rpc` with the hub extension: `get_state` succeeded with a session id and file, `messageCount` 0; the extension emitted `session_start` and `session_shutdown`. |
+| Installed SDK extension registration | pass | The 1.5.0 `DefaultResourceLoader` and `createAgentSession` loaded this checkout's extension and registered exactly `compat_probe` as the active tool, with no builtin tools. |
+| Managed tool callback and receipt replay | pass | The registered callback was invoked without a prompt and posted to the isolated bridge through the real `PiToolReceipts`; two identical calls returned identical success with one effect. |
+| Failed tool result | pass | The bridge fixture denial returned `failed: true` and the extension returned `isError: true`. |
+| Host permission modes | pass (host fixtures) | `test/permission-modes.test.ts` "Pi mode grants edits once, keeps shell on the console, and ask restores the console path": 1 pass, 12 assertions. |
+| Version admission | pass (host fixtures) | `test/pi-compat.test.ts` and `test/compat.test.ts`: 43 pass, 0 fail. |
+| Provider requests | pass | Zero requests reached the loopback provider; no prompt was submitted. Native and SDK stderr were empty. |
+
+Producer result: `pi 1.5.0 model-free receipt: PASS`. The producer is the 1.4.0 one with the version constants and driver file name changed (`pi-150-model-free.ts`, `pi-150-native.mjs`); no assertion was relaxed.
+
+```sh
+bun docs/verification/pi-150-model-free.ts <prefix>/node_modules/.bin/pi <prefix>/node_modules/@earendil-works/pi-coding-agent
+env -u AGENTHUB_HOME -u AGENTHUB_PROJECT_DIR -u AGENTHUB_STATE_DIR bun test test/pi-compat.test.ts test/compat.test.ts
+env -u AGENTHUB_HOME -u AGENTHUB_PROJECT_DIR -u AGENTHUB_STATE_DIR bun test test/permission-modes.test.ts --test-name-pattern 'Pi mode grants'
+```
+
+## Not verified
+
+- Account-backed inference, a model-generated tool request, a real provider's quota behavior and interactive TUI coexistence. The SDK callback leg does not claim model-generated tool dispatch.
+- Linux and Intel macOS. No other Pi release is inferred.

package/docs/verification/2026-11-03-pi-title-api.md

@@ -0,0 +1,26 @@
+# Pi 1.5.0 session-title API probe
+
+Task #689, Refs #1055 (T1). Model-free native API receipt, macOS arm64, Node 24.18.1.
+
+The installed `@earendil-works/pi-coding-agent@1.5.0` exposes a working native session-name setter and reader:
+
+- Extension API: `setSessionName(name: string): void` and `getSessionName(): string | undefined`.
+- Session: `AgentSession.setSessionName(name: string)` and the `sessionName` getter.
+- Session manager: `appendSessionInfo(name: string)` and `getSessionName(): string | undefined`.
+
+The [producer](pi-150-title-api.mjs) loads the real package's `DefaultResourceLoader`, `createAgentSession` and extension runner. It registers an account-free probe tool, invokes that callback directly after `bindExtensions`, and asserts the native API changes an initially unnamed session to `Fixture session title`. Both the extension reader and `SessionManager` return that name. After disposal, `SessionManager.open(sessionFile).getSessionName()` returns the same name. No prompt is submitted to an agent or provider.
+
+The native setter appends a `session_info` entry. A handler registered through the real `ExtensionAPI.on("session_info_changed", handler)` receives the new name, also asserted by the producer. Pi delays creating a new session file until a user or assistant message exists. This probe appends a synthetic user fixture to the session manager before calling the setter; the fixture is never sent to a model. It proves native persistence for an existing conversation, not persistence of an empty session.
+
+## Isolation and result
+
+- Fresh HOME under `getconf DARWIN_USER_TEMP_DIR`, separate `PI_CODING_AGENT_DIR`, XDG config/data/cache and TMPDIR. The child environment contains only these paths, PATH and the explicit package path.
+- Exact 1.5.0 package from the existing scratch npm prefix used by the [compatibility receipt](2026-11-03-pi-150-compat.md). The person's default launcher still selects 1.4.0; it was not invoked or changed.
+- Frozen worktree dependencies installed before the probe: `@staix/agent-mem@0.20.1`, matching the exact manifest pin. Native package version independently asserted as 1.5.0.
+- `sandbox-exec` uses `src/local/sandbox.ts`'s network-disabled profile, adds a real-home read/write deny, then grants only read access to the scratch native package and Node installation. Writable files are confined to the disposable HOME. No credentials or live hub connection.
+- SHA-256 manifests of the 15 real `~/.pi` configuration/launcher entries were identical before and after. The manifest excludes sessions, logs, cache and install trees; it is not a claim to hash every installed package or historical session. Private per-file digests remain in the scratch evidence directory.
+- Exit 0, empty stderr, setter/reader/reopen assertions PASS. An initial hand-written sandbox profile terminated Node before the producer ran; the final run used the repository profile and passed.
+
+Reproduction: run `node docs/verification/pi-150-title-api.mjs` with `PI_TITLE_PACKAGE` pointing to the exact 1.5.0 package and fresh HOME/tool-home paths, inside the network-disabled sandbox described above. Do not run with the person's real HOME.
+
+This permits the native-slot implementation for Pi. It does not prove a model-generated `hub_set_title` call, delivery through a live hub, or a live Pi restart. AC7 remains a separate live receipt in #1143.

package/docs/verification/2026-11-03-qwen-0265-acp.md

@@ -0,0 +1,55 @@
+# Qwen Code 0.26.5 ACP receipt
+
+Date: 2026-11-03. Task #684, Refs #888, `qwen` row only. This repeats the [0.26.4 ACP receipt](2026-10-31-qwen-0264-acp.md) on the published `@qwen-code/qwen-code@0.26.5`, with a private npm prefix, isolated HOME and fixed synthetic configuration. No account, real credential, provider inference or ACP prompt was used. It does not admit the separate `qwen-dual` contract (see the [dual-output receipt](2026-11-03-qwen-0265-dual-output.md)).
+
+**Decision: add `0.26.5` to `COMPAT.qwen.verified`.** Every ACP leg passed. No intermediate release and no range is inferred. `latest` on npm is 0.26.6 today; it is not admitted.
+
+## Artifact and isolation
+
+The package was installed under the local scratch workspace in a private prefix with a scratch HOME, cache and temporary directory and empty npm user and global config files. The person's global prefix, `~/.qwen` and `~/.pi` were not installation targets. npm held one lifecycle script, `@qwen-code/audio-capture` `install` (`node install.js`). It was read, found to locate a prebuilt microphone addon with a non-fatal failure path, and replayed under the same isolated environment: exit 0. No install script was disabled to make the probe pass.
+
+| Artifact | Binding |
+| --- | --- |
+| npm release | 0.26.5, `gitHead` and upstream `v0.26.5` tag `db0e4e24a0d89b211b2a15f4af2be22adac71dfc` |
+| npm integrity | `sha512-iqcBqLQDmKvOtRcVvF78l7bf0NpdymGFBo0qNY0ausPezht+PLXkh15vnIILaBKtM4BabtHSv60xWftMomJ7hw==` |
+| `cli-entry.js` SHA-256 | `113efe4104a9fc66f507d34bfd6abbd896ceb77de47f4b468a0825a327fdc6a5` (the same bytes as the 0.26.1 and 0.26.4 entry files: the entry is a loader, the code is in chunks) |
+| `chunks/acpAgent-HO52UOPA.js` SHA-256 | `794bda74c4d100ab3367ae2e5d880ef0a610df4c84d1db1475d78283b75a8e1e` (the chunk name differs from 0.26.4's `acpAgent-D7OFGHAI.js`) |
+| Host | macOS arm64, Node 24.18.1 |
+
+Every native process received a fresh temporary HOME and cwd, private `QWEN_HOME`, `QWEN_RUNTIME_DIR` and `XDG_CONFIG_HOME`, a synthetic API key and `--auth-type openai --model fixture-model --openai-base-url http://127.0.0.1:9/v1 --telemetry=false`. The 0.26.4 receipt's Node preload denied application network APIs and recorded six blocked startup attempts here too; none connected through those guarded APIs. This is preload evidence, not a kernel network sandbox.
+
+Real configuration: SHA-256 of every file under the person's `~/.qwen` and `~/.pi/agent` (excluding sessions, logs, caches, installs and `bin`) and of the globally installed qwen's `cli-entry.js` and `package.json` was taken before and after the producer runs: 9550 entries, identical.
+
+## Native ACP, no prompts
+
+`qwen --acp --bare --advisor off` initialized with protocol version 1 and `agentInfo` name `qwen-code`, title `Qwen Code`, version `0.26.5`. The only offered authentication method was the synthetic `openai` terminal method. No prompt was sent.
+
+`session/new` succeeded. Available modes were `plan`, `default`, `auto-edit`, `auto` and `yolo`, with current mode `default`: the same five ids as 0.26.4. Each transition in `default -> auto-edit -> yolo -> default` returned an acknowledgement, so the hub's ask/default, ask-when-needed/auto-edit and never-ask/yolo map is still a subset of the native ids. The session exposed only the fixture model.
+
+The native leader exited after its owned group received SIGTERM, and the producer confirmed `groupGone: true`.
+
+## Actual published permission handler
+
+An exports-only scratch copy of the published ACP chunk (`export{SubAgentTracker,toPermissionOptions,resolvePermissionOutcome}` appended) was placed beside the original inside the private package, preserving its relative imports. The original chunk was not edited. The fixture invoked the actual `SubAgentTracker.createApprovalHandler` with synthetic client, tool and event ports, not a model-generated tool turn.
+
+- The request carried the fixture session, pending tool-call id, raw input, native MCP tool metadata and permission progress updates.
+- The exact options were `proceed_always_project` and `proceed_always_user` as `allow_always`, `proceed_once` as `allow_once`, and `cancel` as `reject_once`.
+- An allow-once response reached `event.respond` as `proceed_once`; a cancelled outcome reached it as `cancel`; the real outcome helper rejected an unoffered option.
+
+## Not verified
+
+A real model-generated permission turn, a real login or provider, model behavior, Linux and Intel macOS. This receipt did not review upstream source between 0.26.4 and 0.26.5; the claim is the native behaviors above on the exact published artifact. Host changed-source checks and exact-head CI are separate PR evidence.
+
+## Evidence fingerprints
+
+Producers and result JSONs stay outside git under the local scratch workspace.
+
+| File | SHA-256 |
+| --- | --- |
+| `qwen-acp-probe.py` | `12e60602ca5d00ed29473f3afef277b0c5661aca286692864da8fc69ced9d2e2` |
+| `qwen-acp-result.json` | `442f2e33c13232723eb646119f49f52fcb8df06de7c59ee32402ab377525710a` |
+| `qwen-permission.mjs` | `989ba620e7d099b74ec5b4b1efb78d9d6cc96b5ef5b364c058a077dfc8621a31` |
+| `qwen-permission-result.json` | `958a77ea7618e0efd04a78520aadf83654e5b74a0158a05061d0bed4406d7c31` |
+| `deny-network.cjs` | `361148af658dd4b65ed35308622ec99bb882ec5a25fab54581776546f139e892` |
+
+The two probe copies differ from the 0.26.4 producers only in paths and the expected version string.

package/docs/verification/2026-11-03-qwen-0265-dual-output.md

@@ -0,0 +1,40 @@
+# Qwen 0.26.5 dual-output attempt, not qualified
+
+Date: 2026-11-03. Task #684, Refs #888, the separate `qwen-dual` row. The [0.26.5 ACP receipt](2026-11-03-qwen-0265-acp.md) does not qualify the TUI contract. This repeats the corrected [0.26.4 attempt](2026-10-31-qwen-0264-dual-output.md) (the v2 producer, fixed OpenAI-compatible loopback responses, no real model, account or credential) on `@qwen-code/qwen-code@0.26.5`.
+
+**Decision: do not add 0.26.5 to `COMPAT["qwen-dual"].verified`.** Q2 did not pass. Exactly 0.26.1 stays verified for this entry, and `src/adapters/compat.ts` is unchanged for it.
+
+## Artifact and controls
+
+The candidate is the private-prefix package described in the ACP receipt (upstream tag and `gitHead` `db0e4e24a0d89b211b2a15f4af2be22adac71dfc`, Node 24.18.1, macOS arm64). The retained global 0.26.1 install (`cli-entry.js` SHA-256 `113efe4104a9fc66f507d34bfd6abbd896ceb77de47f4b468a0825a327fdc6a5`) served as a read-only matched control, always with a fresh temporary HOME and cwd and the same producer. Each fixture used a PTY, private input and event files, a scratch git project, a synthetic key and a loopback server. The Node network guard's positive control passed; every observed Node process loaded the guard; every owned process group was confirmed gone; the temporary roots were removed. Model inference calls: 0.
+
+Real configuration: the person's `~/.qwen`, `~/.pi/agent` and the global qwen install hashed the same before and after (9550 entries, together with the ACP runs).
+
+## Observed outcomes
+
+| Check | 0.26.5 | Matched 0.26.1 control |
+| --- | --- | --- |
+| Q7 version and guard positive control | pass, 0.26.5 | pass, 0.26.1 |
+| Q2 second submit becomes a separate user turn after the first completes | **fail**: `Q2 fewer than two user events` | **fail**, the same error, same fixture |
+| Q3 shell and native MCP `can_use_tool`, allow, TUI Enter, duplicate refused, read-only control | pass | not selected |
+| Q4 external SIGINT leaves the turn running; person Esc stops it and the next turn works | pass | not selected |
+| Q5 unread output FIFO does not block the TUI answer | pass | not selected |
+| Q6 resume id, no old-submit replay, prior context in the resumed request | pass | not selected |
+
+Q2 fails identically on the already-verified 0.26.1 with this producer, so it is a limit of the held-stream workload the corrected fixture uses and not a 0.26.5 regression: the same outcome the 0.26.4 receipt recorded. It also means this fixture cannot reproduce the queued-submit observation the [original 0.26.1 receipt](2026-10-25-qwen-dual-output-t0.md) rests on. The task gate (promote only when every model-free leg passes) does not allow a `qwen-dual` bump while a required leg is unestablished, and no TUI adapter, queue, cancellation policy or existing admission is changed.
+
+## Source note
+
+Upstream `DualOutputBridge.ts` and `RemoteInputWatcher.ts` have the same blob ids at v0.26.1 (`b475278c`), v0.26.4 (`715a550c`) and v0.26.5 (`db0e4e24`): `1e1a4e71fafd0c29c62e4ca60243449bd698d20a` and `8a3eabf4e29804ce5f63d40d4a083d14f489dbb3`. That is scoped supporting evidence about those two files, not native acceptance.
+
+## Not verified
+
+Q2 on any version with this producer, a real account or provider, model choices and quality, token and quota behavior, Linux and Intel macOS. Explicitly failed and unselected legs above are not relabelled as passes.
+
+## Evidence fingerprints
+
+| File | SHA-256 |
+| --- | --- |
+| `qwen-dual-probe-v2.py` | `114c032afce5caef4f59072f0a1730bc78a70788fd49ad17e5ff2f1eef4c947e` |
+| `qwen-dual-v2-0265-result.json` | `1062244e51f5c1aab71f2778d08116c3c00f81929be9aa209fc3467763cc0471` |
+| `qwen-dual-v2-0261-control-result.json` | `d4384d0b54f42e789f09f44346201b75285b1afafc78eb3d22ff3271b38ce72a` |

package/docs/verification/2026-11-04-1171-channel-client-evidence.md

@@ -0,0 +1,31 @@
+# Channel client evidence for #1171
+
+## Scope
+
+This investigation checked the installed first-party Claude Code 2.1.318 artifact and read process metadata on macOS on 2026-11-04. It did not start a model session, modify a running client, capture a live MCP handshake, or establish that a particular notification reached a model.
+
+The artifact was the existing native installation at `~/.local/share/claude/versions/2.1.318`. Its embedded build metadata names Git revision `ca1fa9dea62c1027756786c841c548788644560d` and build time `2026-11-03T18:52:53Z`.
+
+## Client initialization and channel registration
+
+The inspected stdio MCP client construction passes capabilities through `_Xt`, `pOn` or `uOn`, and `W`. That path builds roots/list-change and elicitation capabilities, with conditional MCP application extensions. The inspected path contains no channel-specific client capability or flag-dependent channel opt-in field.
+
+Channel registration is a separate path. It checks the server's channel declaration, protocol compatibility, provider and organization policy, and the session's selected channel entries. A generic MCP client capability therefore cannot establish that this session opted into this channel. This is a bounded observation about these paths in 2.1.318, not a claim about every client version.
+
+The [official channel reference](https://code.claude.com/docs/en/channels-reference) describes the channel capability as a server declaration. It also documents the development flag as interactive-only; print mode ignores that flag. No usable client initialization signal was found in the inspected artifact and reference.
+
+## Direct-parent fallback
+
+The existing `claudeNativeLaunch` implementation prepends the development-channel flag and a selected exact target before native passthrough arguments. The target is normally `plugin:agent-hub@agent-hub`; its existing matching MCP configuration path can select `server:agent-hub`.
+
+A passive process observation corroborated this layout for the running native TUIs: process 10310 and several other observed TUIs had the exact known flag/target prefix. The observed background daemon, process 17739, did not. Two other Claude process rows exposed only the process name, which cannot establish support. The observation emitted only identifiers and classification results, without retaining command bodies, paths or prompts.
+
+The proposed fallback was communicated to the reviewer before implementation: require the existing launcher marker together with bounded evidence from the direct parent's actual invocation. An inherited marker alone is insufficient. Unknown process metadata must remain tools-only. Searching an arbitrary command substring would be unsafe because a prompt or an option value can contain the same flag text.
+
+The flag evidence has a deliberate ceiling: it establishes the inspected launch form, not organization policy, user confirmation, protocol registration or model consumption. Unrecognized launch forms must remain pull-only. The separate #1172 settlement work is needed for notifications that are accepted by the transport but never confirmed by the session.
+
+## Verification boundaries
+
+Synthetic fixtures must distinguish an inherited marker without parent evidence from the supported launcher form, and keep the former's messages readable through `hub_inbox`. Negative cases include print/background forms, repeated or misplaced flags, unknown targets and unavailable process metadata. Status must expose a closed evidence value, never command text.
+
+Source tests, the committed-head remote gate, hosted CI and native message-consumption receipts are separate evidence. This investigation supplies no native delivery receipt.

package/docs/verification/2026-11-05-0.31.0.md

@@ -0,0 +1,182 @@
+# 0.31.0 release verification
+
+This record covers release preparation and source review. It claims no installation, no running-hub upgrade to 0.31.0 and no live TUI launch.
+
+## Candidate
+
+Initial preparation: version 0.31.0, prepared from main 3185dd4c (33 commits since v0.30.0; the tool's count of 34 includes this branch's CHANGELOG commit 7e2a3257, 16 of them `feat`; bump rule: minor). The release commits carry the version, the CHANGELOG section, the bundle and the documentation stamps.
+
+## Completion after the release follow-ups (task 744)
+
+The single intended release remains 0.31.0. Completion starts from main
+`9e4f24c3b222b6faa40309eeb0a91a54107dfe6e` on the exact branch
+`release/0.31.0`; no version, runtime, bundle or fixture version is changed here.
+At preparation, npm's `latest` was 0.30.0 and the remote `v0.31.0` tag was absent.
+The earlier release PRs #1218 and #1223 are already merged, but the four source
+PRs below landed afterward. This follow-up must also be merged with a merge
+commit and the default subject, preserving the reviewed-stamp ancestors for the
+guarded tag. It neither records consent nor creates a tag or npm publication.
+
+The board approval head equals each merged PR's head (`mismatch: false`).
+GitHub readback found every listed check completed successfully or skipped,
+with no failed or pending check. Counts below are head-specific hosted checks,
+not installed/native acceptance or a new full-suite result for this docs branch.
+
+| PR / task | Approved head | Merge commit | Hosted CI |
+| --- | --- | --- | --- |
+| [#1213](https://github.com/STAIxBWLB/agent-hub/pull/1213), task 739 | `6a304ccbdc2b9ab511f6f85af7fb8fbaee18f1ce` | `c58958d3a13c4de0317fdfb72745a88943315e93` | 19 success, 2 skipped |
+| [#1224](https://github.com/STAIxBWLB/agent-hub/pull/1224), task 714 | `cf20b1d30fe314938c013b34b8a394e8aed1474f` | `b7408fffccdfcdce88fd0e04c2cbecf91c44d7c8` | 21 success, 2 skipped |
+| [#1215](https://github.com/STAIxBWLB/agent-hub/pull/1215), task 734 | `4ffbab00e3a10a32c2955c76873b424f4d5434f8` | `4a4f87ed445bb32df13f9b371f8792dde740de65` | 19 success, 2 skipped |
+| [#1228](https://github.com/STAIxBWLB/agent-hub/pull/1228), task 743 | `8c6d28bbd49f9d2b28e5ab62c28fd81d8a1e6f72` | `9e4f24c3b222b6faa40309eeb0a91a54107dfe6e` | 19 success, 2 skipped |
+
+CHANGELOG now includes failure causes/unresolved failed counts, the handoff
+reachability/repair diagnostics, the exact agent-mem 0.21.0 pin and complete
+bounded declined inspection, and the missing task 739 convention entry.
+Unreleased is empty. The old #1173 wait for agent-mem#260/#261 is replaced:
+AC4 is complete, while automatic v3 sync remains unsupported pending the
+activation and fresh host-attestation path in agent-mem#281. No activation or
+attestation is fabricated. Task 736/T3 and task 737/T4 are not in this release.
+
+The hub N-1 fixture stays 0.30.0 with agent-mem 0.20.1. The additive nullable
+`deliveries.failure_cause` column does not raise hub schema version 2; the older
+recovery reader ignores the extra diagnostic snapshot key. The existing
+`peer_takeover` compatibility statement is retained. Memory claims are limited
+to [agent-mem's published 0.21.0 notes](https://github.com/STAIxBWLB/agent-mem/blob/v0.21.0/CHANGELOG.md):
+its N-1 proof uses 0.20.3, not the 0.20.1 bundled by hub 0.30.0. Those notes keep
+curated/capture/hook-spool/candidate/work-list/setup receipt v1/v2 formats,
+shared-v1/generation/v1-v2 shard sync and index version/name unchanged, and
+record 0.20.3 refusing activated v3. This report does not extend that versioned
+proof to 0.20.1 or claim supported v3 activation/automatic sync.
+
+### Document review for task 744
+
+The 14 stale documents were reviewed against the task 714, 734 and 743 deltas
+only; task 739 changes classification metadata without runtime behavior.
+Changed documents:
+
+- `docs/quickstart.md`: correct the 0.31.0 upgrade paragraph, additive failure
+  column, current exact memory pin and the automatic-v3 limitation; retain the
+  historical 0.30.0 pin note and global CLI/plugin update step.
+- `docs/operations.md`: correct the mismatch next step (`ahub projects`, with
+  `ahub up` conditional on the intended target not running).
+- `docs/security.md`: correct the old 0.18.0 pin; distinguish safe status
+  placement counts from failure logging and bounded person-only inspection;
+  state the activation/attestation limitation.
+- `docs/agent-notes/adapters.md`: carry typed structured failure diagnostics
+  without treating the diagnostic as settlement or trusting native text.
+- `docs/agent-notes/bus.md`: preserve typed causes through persistence/retry,
+  use metadata-only unresolved counts, and distinguish unavailable from zero.
+
+Reviewed without content changes:
+
+- `README.md`: version/protocol and high-level memory/handoff claims remain true.
+- `docs/agent-notes/README.md`: historical background is unchanged.
+- `docs/agent-notes/benchmarks.md`: no benchmark protocol or end-cause change.
+- `docs/agent-notes/budget.md`: quota/accounting and pause semantics are unchanged.
+- `docs/agent-notes/daemon.md`: current policy/profile sync fences and handoff
+  diagnostic codes, authority and bounded sync behavior remain accurate.
+- `docs/agent-notes/local-worker.md`: the watchdog cause is additive; cancellation
+  and uncertainty remain unchanged, with typed diagnostics owned by adapters.
+- `docs/agent-notes/tasks.md`: task/handoff authority and the write-time memory
+  projection remain valid.
+- `docs/agent-notes/tests.md`: fake boundaries, exact-pin fixtures and the
+  type-only overload adaptation do not change the test instructions.
+- `src/cli/help.ts`: handoff `--list`/`--sync` match main and the argument parser;
+  status/queue/declined forms and native entry definitions are unchanged.
+
+Only these 14 reviewed documents were restamped through
+`bun scripts/release-prepare.ts restamp <document>... --reviewed` at the reviewed
+content commit `af37f8fd8b44a2c566aa47629ec5b02ee9f91d69`. The stamp-only commit
+`7db76b365d0b3e0ef0b946468193dab7b3393bd8` retains that ancestor; the already
+fresh models document was not restamped.
+
+### Completion checks for task 744
+
+On dgx02, `remote_dev.py verify` checked committed head
+`7db76b365d0b3e0ef0b946468193dab7b3393bd8` (tree `656a468fbfd1`) with
+`node scripts/check-docs.mjs --require-fresh && scripts/check.sh --changed`.
+The run completed in 31 seconds with:
+
+```text
+docs: OK (0 stale documents)
+roles: OK (17 bounded definitions)
+inventory: OK (3276 entries, 2121 classified, 1155 in the baseline of known-unclassified keys)
+package: OK (793 files, @staix/agent-hub@0.31.0)
+check: --changed found no affected tests
+check: OK (changed)
+```
+
+Typecheck and bundle freshness also passed. This was a documentation-only
+changed gate, not a new full runtime test run. The following documentation-only update
+records that completed result; final-head checks and hosted CI are recorded on
+the PR and remain the merge gate. No tag, consent, publication, installation or
+live upgrade was performed.
+
+## Reviews
+
+Pull requests named by the commits since v0.30.0: #1216, #1211, #1214, #738, #1212, #1210, #1207, #1209, #1206, #1205, #1202, #1201, #1192, #1200, #1197, #1195, #1194, #1189, #1191, #1190, #1186, #1183, #1188, #1181, #1185, #1187, #1184, #1182, #1170, #1169, #1168, #1167, #1166, #1165.
+
+`#738` in that list is hub task 738 named in #1212's subject, not a pull request of this range.
+
+Each of the 33 merged at the head its hub task approved, read from the board (`ahub board --json`: `approval.head` equals the task's `refs.commit` and the PR's head, `mismatch: false`), with that head's CI green on ubuntu and macOS (18 to 21 checks pass, 2 skipped, none failing). Approvals by claude unless named:
+
+- #1165 (task 695) at 5d1c984e; #1166 (696) at 71f1e1f0; #1167 (693) at ca882f2b; #1168 (694) at 59f352da; #1169 (697) at e5500129; #1170 (700) at 884036ba; #1181 (708) at 0b9fbe07; #1182 (715) at 56521a35; #1183 (702) at 56f1e7c5; #1184 (710) at 97bfcba4; #1185 (703) at c762d8a7; #1186 (704) at 96703ec9; #1187 (711) at 9e2b2719; #1188 (716) at 72958d19; #1189 (712) at 054cc353; #1190 (724) at 1ecdeb32; #1191 (717) at db519b67; #1192 (722) at dd5e87ff; #1195 (705) at 61168f74; #1197 (723) at 680f3c1f; #1200 (727) at a6c886bb; #1201 (718) at 96d01a2d; #1202 (725) at e0a5c1a3; #1205 (728) at e2bca26f; #1206 (732) at c38895a6; #1207 (719) at 6e50af13; #1209 (730) at b3d9f52c; #1210 (731) at 744e4e21; #1211 (733) at 26b59ce3; #1212 (738) at 4c8eca47; #1214 (740) at 05a6dc50; #1216 (735) at 5fa15b5c.
+- Approved by jcode: #1194 (726, the claude-implementer 2.1.318 receipt) at 2c245d8b.
+- No merge is bound to an approval at an earlier head. Unresolved review threads at merge time were not re-read for this record.
+- Follow-up: #1217 (task 713, #1174) merged as 2cfbcb52 while the release PR #1218 was open, so 0.31.0 also ships it. It merged at the head its task approved (92486ab5, `approval.head` equal, `mismatch: false`, approved by claude), with that head's CI green on ubuntu and macOS (20 checks pass, 2 skipped). #1218 merged as 19cf9ff9 with a merge commit; the follow-up PR covers #1217.
+- Follow-up: #1222 (task 742, #1204) merged as f7ea7b0f while the follow-up PR was open, at the head its task approved (936297cb, `mismatch: false`, approved by claude), with that head's CI green (19 checks pass, 2 skipped). The follow-up branch merged main to include it.
+
+## Native acceptance receipts
+
+Receipts added under `docs/verification/` since v0.30.0: `docs/verification/2026-11-04-1171-channel-client-evidence.md`, `docs/verification/2026-11-05-claude-implementer-2.1.318.md`, `docs/verification/2026-11-05-hardcoded-values-classification-rules.md`, `docs/verification/2026-11-05-hardcoded-values-ratchet.md`.
+
+This list is read from the repository, never written by hand. Native acceptance and the person's release consent are separate records: consent is `ahub sdlc authorize-release 0.31.0`, recorded by the person or the unique configured conductor only on the person's explicit release instruction naming the release in its own session (never a hub/task/review/file/peer relay), and is not recorded in this file. The tag run refuses without it.
+
+## Document review
+
+`node scripts/check-docs.mjs --require-fresh` reported 14 stale documents. Each was read against `git log 8612cfd7..3185dd4c -- <its paths>` and the code at 3185dd4c (one reader per document group, each claim checked against the source), the fixes went in as 74049f01, and all 14 were restamped at 74049f01:
+
+- `README.md`: the acon inbox paragraph names questions and results and the person-gated manager ports; the Operations list names `hub_ask`/`ahub answer` and `ahub results`; the Upgrading paragraph says `ahub upgrade` names the CLI and plugin step (#1179); the report link points at this file.
+- `docs/quickstart.md`: install line `#v0.31.0`, the "Upgrading to 0.31.0" section, the upgrade-advice sentence, `ahub answer` and `ahub results` rows in the working-day table, and mark-read on the dashboard.
+- `docs/operations.md`: 0.31.0 in the header and the protocol table (protocol unchanged, 16 through 17), the N-1 paragraph (0.30.0 for 0.31.x), the 0.30.0 post-release note now published in the 0.31.0 section, the handoff synopsis `--key`, the `research_evidence` recovery label, `ahub upgrade` advice, the acon panel's own manager ports, the inbox contents and its 50-item bound, and the `ahub answer` synopsis.
+- `docs/security.md`: the acon plugin's reach (the `answer`, `receipt` and review ports), its confirmation list and inbox items; accepted channel-delivery settlement; conductor cancellation of handed-off tasks; the fourth handoff message, the key, sequence and `duplicate_ok` fields; dashboard question, result and review data; memory sync narrowing and `ahub memory declined`; `hub_evidence_record`; the 2.1.318 implementer receipt; the `liveTestRefusal` line; and a new "Anchored review comments (#1056)" section.
+- `docs/agent-notes/adapters.md`: the `acceptedSettlement` port (#1172) and the owned input observers (#1056).
+- `docs/agent-notes/budget.md`: transient `Bus.pause`/`resume` write no snapshot (#1214).
+- `docs/agent-notes/bus.md`: pushed vs pulled answer parents, review-observer telemetry suppression, owner-audience reviews never moot, explicit-channel `accepted` resolution, accepted-delivery expiry, review provenance and room delivery rows.
+- `docs/agent-notes/daemon.md`: the recovery floor list (`research_evidence`, `review_comments`, `review_observer_input_state`, `accepted_delivery_settlement`), the DOING privacy screens, review observer input, channel push evidence, the inbox project listing budget, held-hint rendering, memory sync policy outcomes and the retired pet window.
+- `docs/agent-notes/local-worker.md`: the review-turn exclusion (#1181, #1192).
+- `docs/agent-notes/tasks.md`: `Board.proposeHandoff`, `task_handoff_by_key`, sequence-ordered events and the periodic catch-up; claim evidence links; person review comments; long-term memory screening.
+- `docs/agent-notes/tests.md`: time-bounded waits (#1163), the fake-ripwire probe (#1197), channel parent evidence in fixtures (#1171) and the published fixtures' retarget rule (#1168).
+- No change needed: `src/cli/help.ts` (every form the 8 commits added matches `main.ts` and its parsers), `docs/agent-notes/README.md` and `docs/agent-notes/benchmarks.md` (each read; the commits in range do not change what they state).
+- Not acted on, outside the stale set: AGENTS.md "Area notes" does not yet name the new files `src/hub/review-comments.ts`, `review-anchor.ts`, `review-material.ts`, `research-evidence.ts`, `memory-sync-policy.ts`, `question-detach.ts`, `completion-detail.ts`, `memory-sync-state.ts`, `src/ui/plugin-questions.ts` and the new `src/cli/*-args.ts` parsers; `test/specs-tasks.test.ts` and `test/broker-server.test.ts` still bound a wait by event-loop turns.
+
+- Follow-up review of #1217: after #1218 merged, `check-docs --require-fresh` on main reported 12 documents stale by #1217 (and the #1218 merge). Each was re-read against #1217's diff only, the fixes went in as 142c80c7, and all 12 were restamped at 142c80c7:
+  - `README.md`: the Operations list names `ahub peer takeover`.
+  - `docs/operations.md`: the newest-hello sentence now applies only to a session that does not opt in to standby.
+  - `docs/security.md`: a paragraph on person-only takeover, standby fencing and display-only ids and PIDs.
+  - `docs/agent-notes/adapters.md`: the retained standby port (`retainStandby`, `takeover`, `ownsSocket`, closes 4405 and 4403).
+  - `docs/agent-notes/daemon.md`: the `peer_takeover` control message and detached-connection rule.
+  - `docs/agent-notes/tests.md`: close the fixture owner before attaching a second opted-in session.
+  - `src/cli/help.ts`: `ahub peer takeover` lists the `--json` and `--color` flags `main.ts` accepts.
+  - No change needed: `docs/agent-notes/README.md` (the `o` key acts on the selected row's displayed standby id, within the exact-row rule), `budget.md`, `bus.md`, `tasks.md` (#1217 changes no pause, queue or task path) and `docs/quickstart.md`.
+  - CHANGELOG: a #1217 entry under 0.31.0, and the N-1 statement names `peer_takeover`, `ahub peer takeover` and the standby opt-in in both directions.
+- Follow-up review of #1222: the merge of main left 9 documents stale by its `src/hub/bus.ts` and `src/rooms/link.ts` changes. Each was re-read against #1222's diff, the one fix went in as aceed883, and all 9 were restamped there:
+  - `docs/agent-notes/bus.md`: a closed `Bus` publishes nothing and touches no journal or observer.
+  - No change needed: `README.md`, `docs/operations.md`, `docs/security.md`, `docs/quickstart.md`, `budget.md`, `daemon.md`, `tasks.md`, `tests.md` (their presence and queue statements still hold; #1222 changes no surface, setting or wire field).
+  - CHANGELOG: a #1222 entry under 0.31.0; it changes no N-1 surface.
+
+## Checks
+
+- `node scripts/check-docs.mjs --require-fresh`: `docs: OK (0 stale documents)` after the restamp at 74049f01.
+- `scripts/check.sh --changed origin/main` on dgx02 (`remote_dev.py verify`) at e8f3a694 (tree a0576a8b) selected the full suite: `docs: OK (0 stale documents)`, `roles: OK`, `inventory: OK` (3267 entries, 1155 in the baseline), typecheck (`bun x tsc --noEmit`), the bundle check (`bun scripts/build.mjs --check`), `package: OK (791 files, @staix/agent-hub@0.31.0)`, and 11891 pass, 101 skip, 0 fail across 916 files with Bun 1.4.2; no daemon leaks; `check: OK`. It includes the published-runtime interoperability tests in both directions against 0.30.0 (release N-1) and 0.25.0 (protocol floor). Later commits on the release branch change only this report.
+- The release PR's exact-head CI on ubuntu and macOS is the gate for the merge.
+- Follow-up for #1217: `node scripts/check-docs.mjs --require-fresh` is `docs: OK (0 stale documents)` after the restamp at 142c80c7. `scripts/check.sh --changed origin/main` on dgx02 at 1acb9645 (tree e1a307e0) ran typecheck, the bundle check, `inventory: OK`, `package: OK (791 files, @staix/agent-hub@0.31.0)` and the 25 test files the change touches: 347 pass, 0 fail; `check: OK (changed)`. #1217's own full-suite and hosted CI receipts are in its PR. After that gate the branch merged main for #1222 (its own full dgx02 gate and hosted CI are in #1222) and added only documents, stamps and CHANGELOG lines; `check-docs --require-fresh` is clean at the final head. The follow-up PR's exact-head CI gates its merge, which must also be a merge commit.
+
+## Known gaps, not blocking
+
+- No installation, running-hub upgrade to 0.31.0 or live TUI launch was done for this record.
+- #1053: AC1 live receipts and the T1 timeout measurement stay open; the per-adapter `hub_ask` waits are provisional.
+- #1056 and #1204 (T3, T4) stay open; #1196 stays open until the person measures the live acon console.
+- #1173: complete bounded declined listings are available. Automatic v3 sync still lacks the supported activation and fresh host-attestation path in agent-mem#281.
+- #1184: the channel-evidence fallback reads the direct parent's process row; it is not authentication, and a published client opt-in is the upgrade path.
+- The N-1 fixture lock remains the Bun 1.4.2 lock for 0.30.0. Prior published-runtime interoperability evidence is recorded above; this documentation-only completion adds no new full-runtime claim.