@staix/agent-hub 0.29.0 → 0.31.0

package/docs/security.md

@@ -26,7 +26,7 @@ agent-hub connects agents that can each run commands. This page says what the hu
 
 ## Native memory authority and profile selection
 
-The portable core is the exact-pinned first-party `@staix/agent-mem` 0.18.0 package; it does not replace the hub's caller identity, PII policy or task-write authority. Deny, hardened git, real paths and process identity are single-sourced in its Node-safe platform entry. Current project privacy is applied by the hub before promotion and again before model-facing reads. Standalone person reads are unscreened, and the standalone `--policy-free` acknowledgement grants no hub or peer authority.
+The portable core is the exact-pinned first-party `@staix/agent-mem` 0.21.0 package; it does not replace the hub's caller identity, PII policy or task-write authority. Deny, hardened git, real paths and process identity are single-sourced in its Node-safe platform entry. Current project privacy is applied by the hub before promotion and again before model-facing reads. Standalone person reads are unscreened, and the standalone `--policy-free` acknowledgement grants no hub or peer authority.
 
 `hub_memory_search`, `hub_memory_show` and `hub_memory_graph` take the project from the daemon, require `memory_read`, refuse private turns and validate UTF-8 input before logs or storage work. Complete records and graph metadata are screened before counts and truncation. Search is at most 20 lines/4 KiB (default 8); show accepts at most 8 ids and returns at most 8 KiB; graph is at most 120 nodes/240 edges/6 KiB (default 60 nodes), with no edge lacking an endpoint. Unknown, ambiguous and withheld ids share one neutral refusal. Arguments and results are excluded from hub-managed capture; this does not govern a vendor's independent transcript or memory hooks.
 
@@ -165,6 +165,20 @@ enrollment and X4 privacy/framing/role boundaries are in their own sections belo
 traffic metadata, availability, malicious owners and same-user compromise remain
 outside the encryption boundary.
 
+Room presence uses a signed `ephemeral: true` header (#1204 T1). This reveals
+presence traffic class to the blind broker, not peer state or body text. Only the
+latest sender observation is retained for connected, ready recipients; offline
+recipients and broker restart do not retain presence. Durable queue limits and
+receiver replay/admission checks are unchanged. A `queue_full` storage refusal
+names the verified frame digest; local bounded backoff retries that same sealed
+frame and grants no completion authority.
+
+
+The ephemeral advertisement is a transport capability, not authentication or
+completion authority. Old brokers receive the legacy frame shape. The broker withholds ephemeral frames from older member
+hubs until they upgrade; chat
+frames remain compatible. See [room wire compatibility](design/bus.md#room-wire-compatibility-1204-t1).
+
 ## What is not defended
 
 - **A malicious local process running as you.** It can read the control token, `hub.db`, the project and your home directory without the hub's help. The token keeps web pages and other users out, not your own processes.
@@ -362,7 +376,7 @@ as that peer in tools mode. Messages and task changes retain that actor;
 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, agent version trust, budget overrides, role assignment, `--as-user`, recovery
-operations, the interactive terminals (`watch`, `pet --window`, a launcher's person-only flags), and `ask`
+operations, the interactive terminals (`watch`, a launcher's person-only flags), and `ask`
 (#933 keeps the person's class to trust, money, attribution and interactive terminals).
 For live verification explicitly authorized by the user, an agent may invoke
 `ahub --live-test [--project <path|id>] <command> [args...]`. The flag delegates
@@ -389,8 +403,8 @@ messages, proposals and reviews. Peer starts, pause and resume may delegate
 operational console authority; task assign/escalate under the flag refuse. `--as-user`, person task labels,
 person-authored planning/release/memory/goal writes, SDLC record, spec and plan-departure acceptance, release authorization, design-spec stamps (`ahub specs stamp`), agent version trust, benchmark run,
 `ahub recovery reattach`, a `--fresh-session` dispose that would replace a repaired
-session's conversation (or whose scope cannot be read), and the pet
-composer are refused; presentation flags such as `--color` or `--verbose` before
+session's conversation (or whose scope cannot be read), `ahub answer` with an
+operand and the `ahub results` receipt forms are refused; presentation flags such as `--color` or `--verbose` before
 the recovery action do not hide it from this check. No argument text is copied into this audit.
 Delegated dashboard restrictions are bound to its server-issued ticket/session:
 operational settings/start/stop controls remain, but message, proposal and
@@ -465,9 +479,10 @@ start (Jcode). Memory changes and the other `goal` changes stay the person's
 while amem records their actor as the user. `task unassign` is a conductor form;
 it keeps the conductor as the board actor. `task cancel` remains separately
 available through `hub_task_cancel` only on the caller's own eligible task
-(#933), not as a conductor operation; `task role`, `task label` and
-`ahub deliverables` retain their own-task checks. `models start|stop` and
-`pet --window` remain Console. `restart --yes`,
+(#933), and for the conductor only on an unaccepted task another project handed
+off (#1175), not as a general conductor operation; `task role`, `task label` and
+`ahub deliverables` retain their own-task checks. `models start|stop` remains
+Console. `restart --yes`,
 `upgrade --yes --to <exact-version>` and `recovery resume|abort` have the
 separate continuity proof described below. Each conductor operation is admitted
 after a recheck of role and project membership; effectful operations and history
@@ -557,7 +572,7 @@ Please report vulnerabilities privately through GitHub's "Report a vulnerability
 - The exchange creates a separate random session, valid for one hour without renewal, in an `HttpOnly; SameSite=Strict; Path=/` cookie named for this listener's port. Sessions and tickets live only in memory and die with the daemon. The page itself keeps one more cookie, `agent-hub-theme` (issue #246): script-set, `SameSite=Strict`, kept for a year for the whole `127.0.0.1` host, and read back only as one of `system`, `light` or `dark`. A second script-set cookie, `agent-hub-office` (issue #264), keeps the Office view choice under the same attributes and is read back only as `off`, `flat` or `isometric`. The #391 view split adds two more script-set cookies under the same attributes: `agent-hub-view`, read back only as one of the seven view names, and `agent-hub-column-focus`, read back only as one of the five board columns or empty. HTTP is loopback-only; the cookie is not a substitute for the origin checks.
 - Every request must have the exact listener Host. Every data or action request, including the ticket exchange and snapshot polling, must be POST with the exact listener Origin and JSON content type. Foreign and missing origins, missing or expired sessions, oversized bodies and unknown actions are rejected. There is no CORS support. The only unauthenticated GET is the fixed, data-free HTML shell. No files or paths are served dynamically.
 - Responses are non-cacheable, cannot be framed, suppress referrers, and use a content security policy restricting scripts/styles to the shipped inline content and connections to this origin. Browser text is rendered with textContent, never interpreted as HTML.
-- The browser receives a bounded redacted event stream, peer states and queue counts, public task views (with a task's screened changed-symbol observation, #684: ids, paths, names and kinds, never source or line spans, and its Code group, #684 phase 2c: those symbols marked against the plan's names, each name re-screened by the public metadata screen; a private task has no group and its plan names never enter the snapshot), budget windows, each peer's DOING line (#878: a native session title or current plan item, at most 120 characters, kept in daemon memory only and screened when observed and again when shown; a failed screen, a private turn or the peer's open PII task shows `[private]`), pending approvals, the settings rows (closed values and ids, the file each comes from) and each startable peer's start plan (issue #269), benchmark run summaries (issue #251): the newest runs in `~/.agenthub/bench/`, whichever project on this machine ran them, by suite name, arm label, state, the task id in progress, counts, tokens and times, never suite text, the Usage view (#683 U4), computed only while the Agents view is open: peer ids, UTC days and token counts with their source, budget pause, resume and reset events without their reason text, and per-task rows of the task id, a PII flag and token counts, never a title, and the office view's optional fields (issue #264): each peer's open turn (start time, attributed task id, attribution kind), a `checking` flag on tasks whose check is running, and warning `links` of overlapping, conflicting or cohort tasks (task and peer ids only, never paths, symbols or reasons; a PII task never joins a link, and a private or PII-attributed turn exposes no task id). Private envelope bodies and PII task text never cross this endpoint. Local-worker and Pi approval titles can contain PII, so their details remain terminal-only; the dashboard identifies the request and directs the operator to `ahub tail` before allowing it. Budget checkpoint summaries are also omitted.
+- The browser receives a bounded redacted event stream, peer states and queue counts, public task views (with a task's screened changed-symbol observation, #684: ids, paths, names and kinds, never source or line spans, and its Code group, #684 phase 2c: those symbols marked against the plan's names, each name re-screened by the public metadata screen; a private task has no group and its plan names never enter the snapshot), budget windows, each peer's DOING line (#878: a native session title or current plan item, at most 120 characters, kept in daemon memory only and screened when observed and again when shown; a failed screen, a private turn or the peer's open PII task shows `[private]`), pending approvals, the settings rows (closed values and ids, the file each comes from) and each startable peer's start plan (issue #269), benchmark run summaries (issue #251): the newest runs in `~/.agenthub/bench/`, whichever project on this machine ran them, by suite name, arm label, state, the task id in progress, counts, tokens and times, never suite text, the Usage view (#683 U4), computed only while the Agents view is open: peer ids, UTC days and token counts with their source, budget pause, resume and reset events without their reason text, and per-task rows of the task id, a PII flag and token counts, never a title, and the office view's optional fields (issue #264): each peer's open turn (start time, attributed task id, attribution kind), a `checking` flag on tasks whose check is running, and warning `links` of overlapping, conflicting or cohort tasks (task and peer ids only, never paths, symbols or reasons; a PII task never joins a link, and a private or PII-attributed turn exposes no task id). Private envelope bodies and PII task text never cross this endpoint. Local-worker and Pi approval titles can contain PII, so their details remain terminal-only; the dashboard identifies the request and directs the operator to `ahub tail` before allowing it. Budget checkpoint summaries are also omitted. An ordinary (not live-test) session's snapshot also carries the open questions with their full text, a private one included, for the person's answer form (#1053), and unread results with the detail built when shown (#1054). An explicit review refresh of one task adds its person review comment threads and placement, with PII and private-path comments as counts only (#1056).
 - The closed action list includes permission response, peer pause/resume, console message, task proposal/assignment and the settings actions below (set, undo, preview, reload, and the structural edit preview and apply of a settings session). Project-board actions add revision-fenced planning, Backlog pull/return/split/undo and release planning/state changes through Tasks; they do not tag, publish or write GitHub state. These use the existing daemon/task paths and budget pause rules. `start_peer` (issue #269) starts a peer from a closed list in the mode a person set, with a command the hub assembles: the request carries a peer id and nothing else. There is no generic control proxy, task-detail read, shell, file access, free-form configuration edit, budget override, launch of a caller-chosen command or daemon shutdown API.
 - The listener stops with the daemon. Expired sessions must be reopened with `ahub ui`; the page does not silently obtain new credentials.
 
@@ -598,30 +613,38 @@ its existing basename/worktree aliases and provider accounts can remain shared.
 
 `@staix/agent-hub/ui-plugin` runs inside the agent-console (`acon`) process as the
 same user. It holds no credential of its own: it reaches project hubs only through
-the multi-project manager's listing and forwarding above, which connect as the
-console with each project's control token, so it has exactly what `ahub ui --all`
-has. Every action must be on the manager's closed list and every view one of the
-seven view names, and there is no generic control proxy, task-detail read, shell,
-file access or caller-chosen command.
+the multi-project manager, which connects as the console with each project's
+control token. Beyond what `ahub ui --all` has, it uses dedicated manager ports the
+dashboard page cannot reach: `answer` (#1053), `receipt` (#1054) and the review port
+(`review_comment_put|delete|send`, `review_comments`, `review_blob`, #1056). Every
+write through them requires acon's verified `ActionMeta`, as described in those
+sections. Every other action must be on the manager's closed list and every view one
+of the seven view names. There is no generic control proxy, task-detail read, shell
+or caller-chosen command, and the only file read is the bounded review material of a
+public task (`review_blob`).
 
 - **Registration.** `ahub setup` writes `console/plugins/ahub.json` under the hub
   home (directory 0700, file 0600, atomic replace) with the module path and its
   sha256; acon refuses to load a module whose hash no longer matches.
 - **Confirmation.** Outward or destructive actions (`stop`, `permit`, `send`,
   `setting`, `setting_undo`, `setting_reload`, `config_edit_apply`, `start_peer`,
-  `backlog_split` and the inbox's Allow once and Deny) first answer `needsConfirm`
+  `backlog_split`, `worktree_override_set`, `worktrees_refresh_prs`,
+  `review_comment_send`, `review_comment_delete` and the inbox's Allow once and Deny) first answer `needsConfirm`
   with a preview and a fingerprint, a sha256 of the request's own fields; the call
   runs only when it comes back with `confirmed` and that fingerprint. The
   fingerprint binds a confirmation to one exact request, so a changed request needs
   a new confirmation; it is not a secret, and the confirm step is acon's host UI
   contract, not authentication. A process that can load the module already has the
   console's reach, and the hostile-agent boundary above applies unchanged.
-- **Inbox.** Items are the pending approvals and the in-review tasks whose reviewer
-  is the person, read from the same redacted dashboard snapshot: a local-worker or
+- **Inbox.** Items are the pending approvals, the in-review tasks whose reviewer
+  is the person, open questions (#1053) and, for a console that gives receipts
+  person evidence, unread results (#1054), read from the same dashboard snapshot: a local-worker or
   Pi approval shows only the fixed private stub and offers Deny, and Allow once for
   it is refused with "answer this approval with ahub permit". Allow once and Deny
   resolve to the hub's own `permit` with an option the pending request offers,
-  looked up again at the time of the call; nothing else is reachable from an item.
+  looked up again at the time of the call; nothing else is reachable from an approval
+  item. A question's Answer and a result's mark-read go only through the person-evidence
+  paths in "Questions a peer asks the person" and "Results a person's runs leave behind".
   Task titles are the public view's, so a PII task shows the `[pii]` stub.
 - **Space.** The Space scene is built only from the office model the dashboard
   already allowlists (#264): peer ids, conditions and counts, task ids, classes,
@@ -644,6 +667,15 @@ file edits, and a configuration reload refuses roster changes. External ids outs
 admission rules. A roster key left by an undeclared instance loads as inert and grants
 nothing; the only change it accepts is its removal from `config.local.json`.
 
+Handing a peer to a standby session (#1174) is the person's: `peer_takeover` is
+console-role only, and `ahub peer takeover` is refused to agent shells and
+`--live-test`. A standby connection runs no peer operation until it owns the peer,
+and the selected standby is rechecked for membership, launch and isolation,
+lifecycle and claim generation after its preface. Standby ids and reported PIDs are
+display metadata, never native-session or permission evidence. Takeover detaches
+the old hub connection, not its native process; that session's later hub calls are
+refused, and takeover never marks a delivery completed.
+
 Kimi's pull-only TUI owns its tool approvals and session. The person's launcher
 merges/removes only the hub MCP entry; the daemon never edits that file and
 refuses headless starts while a stale entry exists. An attached Kimi TUI blocks
@@ -673,7 +705,7 @@ withholds the scoped mode on these writes so an older hook grants nothing too.
 
 Agent CLI versions (#691). One policy gates the Codex and Kimi fresh reviewers, the headless Claude implementer, Jcode, agy, Qwen (ACP and the dual-output TUI) and Pi (#843): a receipt-verified version passes, Jcode and agy also start an untested version inside their compatible line with a note, and any other version is refused unless the person trusts that exact version on this machine with `ahub agents trust <id> <version>`. The record is `agent-compat.json` in the hub home (`~/.agenthub`), written atomically with mode 600 and at most 64 entries; an unreadable, linked, oversized or invalid record trusts nothing. Agent shells and `--live-test` may read `ahub agents` but cannot trust or revoke. Trust lifts only the version pin: the fresh reviewers' runtime proofs still run before every child, and an untested version's native contract stays unverified.
 
-Qwen Code's optional production ACP peer requires the qwen-code native identity, a compat-admitted version (receipt-verified 0.25.0, 0.26.0, 0.26.1 and 0.26.4)
+Qwen Code's optional production ACP peer requires the qwen-code native identity, a compat-admitted version (receipt-verified 0.25.0, 0.26.0, 0.26.1, 0.26.4 and 0.26.5)
 and advertised mode ids before setting a policy or starting work. Its own tools
 have no hub sandbox; auto-edit approves file edits, yolo every tool. Configured
 never-ask still requires the person's confirmation. qwen_cmd is machine-local and
@@ -682,7 +714,7 @@ this production table. Startup diagnostics withhold native host/payload details.
 
 Jcode is optional, source/version-fenced and runs native tools without a hub sandbox or hub permission-mode mapping. .jcode joins the scoped-grant exclusion, including lexical/resolved aliases. Only a person writes its unique project MCP entry; foreign/override/symlink entries refuse. The hub owns a private daemon/socket and ACP group, never the global daemon, and copies no credentials. It accepts a plain jcode release from 0.98.0 up to, not including, 1.0.0 (#529; only 0.98.1, 0.99.0 and 0.99.1 are verified, and another version in that line starts with a note), or an exact version the person trusts (#691), and runs every owned jcode process (probe, serve, ACP and TUI) with `JCODE_NO_TELEMETRY=1`, because jcode's telemetry can report the provider account's email. Native diagnostics withhold payloads/hosts. Hub tools are bound to an owned launch (task 368): the shared project entry names no peer, each owned Jcode process carries its own peer id and launch id, the daemon admits a hub-tools connection for a Jcode peer only with the id of that peer's current owned launch, and a tools-mode server started without a peer id refuses every tool. Extra Jcode instances (#685, at most 8) are declared only through `instances` in an untracked `.agenthub/config.local.json`, start headless, and each needs its own `jcode_home`, which may not be the base home or another instance's, nor nested in or around one, however it is spelled. Unproved conversation loads refuse; no fresh replacement is called a restore. A finished task's advisory about the project root checkout names the branch only after the hub's whole public-text screen (`Tasks.publicMetadataText`: a PII pattern, a secret shape and a project-private path) passes it and it is a plain ref name; otherwise a generic sentence carries no part of it (#572). Native TUI launch exposes its private socket/session tuple only to the authenticated console, bound to the same live owned socket and session after read-only native persistence proof. Tools/status do not receive it. The TUI has no single-writer guard: person input may interleave with ACP. Native policy remains unmanaged and closing the frontend does not stop ACP. An `important` message reaches a busy Jcode as a soft interrupt written to the hub's own private server socket for the owned session (#572); the hub never cancels a turn to deliver, and a steer that was sent but not acknowledged, or whose turn ended first, is held as `needs_review`, never replayed. Jcode has no switch to choose its MCP servers, so the owned serve and ACP processes load every server named in `<JCODE_HOME>/mcp.json` and the project's `.jcode/mcp.json`, `.mcp.json` and `.claude/mcp.json`, besides the hub's own; `ahub doctor` lists their names only. Point `jcode_home` at a separate home, or remove a server from those files, to keep it out.
 
-Antigravity (`agy`, #485) is optional, cloud and off roster by default. The launcher accepts the Antigravity CLI 1.4.x line; only 1.4.2 and 1.4.7 have a native receipt ([1.4.7](verification/2026-10-26-agy-1.4.7.md)), so another 1.4.x patch launches with a warning that it is unverified, and every other version is refused before a hub connection or plugin write (#589) unless the person trusts that exact version (#691). It runs native tools under its own unmanaged permissions, without a hub sandbox or hub permission-mode mapping; headless, resume, unattended and native permission flags are refused. Its roles are capped at implementer and verifier, so it never plans, reviews or receives PII work. Only the person's `ahub agy` launcher writes its three plugin files in `.agents/plugins/agent-hub/` (`plugin.json`, `mcp_config.json`, `hooks.json`): linked or foreign entries refuse before any write, cleanup removes only that launch's matching files, and it never writes project-level `.agents/hooks.json` or the person's `~/.gemini` settings. Conductor starts are refused, and a declared agy extra instance is refused at config load (#625). Hook authority (`native_hook_launch`) comes only from that launcher, belongs to the console socket that began it and ends when that socket closes; hook input over 1 MiB is refused, and observations are bound to the daemon, launch, native session and project.
+Antigravity (`agy`, #485) is optional, cloud and off roster by default. The launcher accepts the Antigravity CLI 1.4.x line; only 1.4.2, 1.4.7 and 1.4.12 have a native receipt ([1.4.7](verification/2026-10-26-agy-1.4.7.md), [1.4.12](verification/2026-11-03-agy-1.4.12-launcher-nonce.md)), so another 1.4.x patch launches with a warning that it is unverified, and every other version is refused before a hub connection or plugin write (#589) unless the person trusts that exact version (#691). It runs native tools under its own unmanaged permissions, without a hub sandbox or hub permission-mode mapping; headless, resume, unattended and native permission flags are refused. Its roles are capped at implementer and verifier, so it never plans, reviews or receives PII work. Only the person's `ahub agy` launcher writes its three plugin files in `.agents/plugins/agent-hub/` (`plugin.json`, `mcp_config.json`, `hooks.json`): linked or foreign entries refuse before any write, cleanup removes only that launch's matching files, and it never writes project-level `.agents/hooks.json` or the person's `~/.gemini` settings. Conductor starts are refused, and a declared agy extra instance is refused at config load (#625). Hook authority (`native_hook_launch`) comes only from that launcher, belongs to the console socket that began it and ends when that socket closes; hook input over 1 MiB is refused, and observations are bound to the daemon, launch, native session and project.
 
 Configured ACP adapters (#451 A3) are declared only by the person, in a Git-confirmed untracked `.agenthub/config.local.json`. The whole declaration (command, argv, identity, roles and mode maps) is machine-local authority: a shared or tracked declaration is ignored with a notice, settings never edit it, and changes need a hub restart. The hub runs only the declared argv, never a module or callback. Argv that selects a leader, attach, connect or remote mode is refused, and a Grok declaration needs `--no-leader`. Each start requires the pinned native identity, an exact `session/load` echo on resume, and positive ownership of the spawned process and its original process group; unknown ownership refuses, and stop signals only that verified group. An agent that hands its work to a process outside that group is outside this boundary. Without a mode map native policy is unmanaged, and there is no hub sandbox either way. Configured kinds are cloud peers (never PII), headless only and off roster by default, and the hub makes no quota, context or controlled-recovery claims for them. A read-only instance needs the native read-only mode acknowledged before a prompt and is limited to read and review hub tools, both in the published MCP list and at the host; its native non-read tool requests are rejected, and no setting or runtime change can raise it. These agents' stderr and error text are withheld from logs, and previews redact the executable, argv and session id.
 
@@ -759,45 +791,47 @@ historical claude-mem database used only by the explicit read-only import.
 Sync starts only after a person configures a remote. Public GitHub remotes are
 refused; unknown visibility proceeds with a warning for the configured remote.
 Short-term segments, machine identity and the derived index are excluded from
-sync. Suggested graph edges are off by default and are not evidence until a
-person confirms them. Operational details and limits: [hub memory](memory.md).
-
-## Standalone pet window (#391)
-
-The macOS window reads local files only. Its detached host reuses `readPet`,
-including signed-daemon liveness and recovery-lock handling, and publishes an
-atomic counts-only `pet-view.json` (state, act/watch, known character, blink,
-palette from the closed list, built-in pixel frame). It excludes item ids,
-task titles/text, refs, paths,
-notices and approval prose. Missing or unconfirmed status produces only
-`{offline:true}`. Process and position files are separate from this view.
-
-The local WKWebView has a deny-by-default CSP, with only its shipped inline
-script/style allowed and network connections forbidden. Text never becomes
-HTML or executable source. The retained JXA bridge accepts fixed drag/send/
-palette/open/close operations; `NSTask` invokes the host-supplied Bun/CLI/project argv
-and appends `say`, `--` and a single message argument, or `pet`, `--palette`
-and one closed palette name. It does not evaluate a
-shell string. Message text is never logged by the window/host; command stdout
-and stderr go to the null device. `ahub say` keeps its existing console-message
-authority and recording behavior, and `ahub ui` opens its existing session.
-The CLI restricts `pet --window` (including close) to console identity, while
-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.
+sync. Sync and direct long-term writes apply the configured agent-mem sync policy
+narrowed by the hub's deny paths, PII patterns and project-private paths; a promotion
+that fails it leaves the note short-term (#1173). Status exposes safe sync state and
+counts, including verified withheld/exported counts from a successful SDK placement
+result. Failure logs retain only the closed cause and known declined count.
+`ahub memory declined` is person-only (refused to agent shells and `--live-test`)
+and uses bounded physical-row inspection to show IDs and rule categories, never
+note text or literal patterns; incomplete inspection is not a zero count.
+Default-host v3 sync remains unsupported because the hub supplies no fresh
+placement attestation. No activation proof is fabricated; the supported activation
+and attestation path remains agent-mem#281. Suggested graph edges are off by default
+and are not evidence until a person confirms them. Operational details and limits: [hub memory](memory.md).
+
+## Floating pet retirement (#1012)
+
+The standalone JXA host, WKWebView, window bridge and its packaged assets are
+removed. `ahub pet --window [--close]` only prints the `acon ui` Mini pointer and
+exits successfully; it has no launcher, process-control or network effect and
+is available to agent shells and `--live-test`. Legacy `pet.window` is ignored
+as compatibility input and grants no configuration or conductor authority.
+
+Terminal pet reads retain their existing behavior. The retired `pet --palette`
+command validates its argument and prints the same Mini pointer without writing
+`.agenthub/config.local.json`. Existing `pet.palette` values remain validated
+compatibility input and have no rendering effect.
+
+The **Console message** view already exists in the agent-hub acon plugin
+(#935). Its existing `send` action retains message audience, PII and actor
+checks; the retired window adds no alternative composer path.
 
 ## Planner, cancellation and delivery authority
 
 The `planner` setting is person-controlled: one peer id or a list of up to eight (#525-2). A valid pin determines the planner holders without adding them 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. Each new non-PII task and each planner-created release records one effective planner from the same pure walk `ahub route explain` shows; only that planner or the person changes its planning. A bound planner keeps that authority while busy, paused or offline; one removed from the holders or the roster falls back to the current holders, and older rows with no binding, PII tasks included, keep holder-wide authority. Only the person moves a task's planner (`ahub task assign <id> <peer> --role planner`). Another holder may record a plan review without gaining the task's other planning powers; an agent cannot review its own plan while another rostered holder is not offline, and otherwise the receipt records `selfReview: true` with `planAuthor`. 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; a planner can cancel only its own proposed/backlog work with no historical acceptance, and only as that task's effective planner. 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.
+`cancelled` is closed, never approval. The person can cancel non-approved work with a reason and optional supersession reference; a planner can cancel only its own proposed/backlog work with no historical acceptance, and only as that task's effective planner. The configured, rostered conductor can cancel only a task another project handed this one (#1175), while it is proposed or backlog, nobody has accepted it, it has no execution evidence and it is not PII. 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. In the same way it refuses a target without `task_planners` once a planner list or an instance planner is configured or any task or release planner binding or plan-review authorship is stored, even after that configuration is removed. 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 or owner 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 pause removal. `hub_delivery_resolve` (#1112) lets a local agent mark only its own `needs_review` row `completed` or `discard`, at the revision `hub_inbox` showed, with a public, screened reason recorded under its actor. It never replays the originals or changes task state. An unknown id, another peer's row and a row that is not `needs_review` share one refusal, so the answer never confirms another peer's row. The person, the hub, a remote peer, a paused or held peer, and recovery, shutdown or storage holds are refused. A row that carries an invocation stays person-only, because its outcome is uncertain. An explicit `hub_inbox` read may return newly queued messages behind such a hold, never the held originals, and only when no recovery, pause, lifecycle or storage fence applies. 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.
+`hub_delivery_retry` grants an eligible recipient one retry of its own `needs_review` work, never pause removal. `hub_delivery_resolve` (#1112) lets a local agent mark only its own `needs_review` row `completed` or `discard`, at the revision `hub_inbox` showed, with a public, screened reason recorded under its actor. An attached Claude push-channel session may also settle its own `accepted` row that way (#1172); any other peer's `accepted` row is refused. It never replays the originals or changes task state. An unknown id, another peer's row and a row in neither state share one refusal, so the answer never confirms another peer's row. A channel `accepted` row that gets neither native completion nor that disposition within `bus.accepted_settle_ms` (default ten minutes) becomes `needs_review` with no replay. With `conductor.feed` on, the configured conductor gets one ids-only notice for an important, task or review timeout. The person, the hub, a remote peer, a paused or held peer, and recovery, shutdown or storage holds are refused. A row that carries an invocation stays person-only, because its outcome is uncertain. An explicit `hub_inbox` read may return newly queued messages behind such a hold, never the held originals, and only when no recovery, pause, lifecycle or storage fence applies. 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.
 
 A declared instance whose only role is reviewer gets review requests, task messages addressed to it and the person's messages; agent chat, digests and presence are discarded and journaled, and it gets no memory recall (task 223). The headless Claude reviewer runs one new `claude -p` per review with `--setting-sources ""`, `--strict-mcp-config`, `--no-session-persistence`, tools limited to Read, Grep, Glob, `hub_review` and `hub_task_show`, and `dontAsk`. Its prompt holds hub facts and a bounded diff, never the builder's summary, and its `hub_task_show` drops the builder's notes. Changes touching `local.deny` or `pii.paths` are withheld and passed as `Read` deny rules, which Claude enforces, not the hub. Private tasks are never given to it. Its `hub_review` counts only while the child started for that task still runs; a stop or exit revokes it first, and surviving processes hold the delivery as `needs_review` and keep the reviewer busy.
 
@@ -805,7 +839,7 @@ A terminal Claude implementer or verifier instance (#525-5) owns write-class tas
 
 A planner-only instance (#525-6: `planner` without `implementer` or `verifier`) plans on the project checkout, so a declared `worktree` is refused. A Codex planner's `thread/start` and `thread/resume` are requested read-only, and a thread is adopted only when Codex's reply positively confirms a read-only sandbox; an unconfirmed or malformed reply refuses that RPC and closes the link before the hub adopts the thread or delivers work, and the current roles are rechecked before each injection. This is an initial ceiling, not confinement of the person's attached TUI, which can change its native sandbox later. A declared planner-only Claude channel instance gets no automatic grant from its facts hook for any tool but Read, LS, Glob and Grep, whatever the permission mode.
 
-The headless Claude implementer (#525-4) runs one owned `claude -p` child per turn in its declared worktree, with `--setting-sources ""`, `--strict-mcp-config`, native permission mode `default`, the hub's managed PreToolUse hook and `--permission-prompt-tool mcp__agent-hub__hub_permission_request`; never `--bare`, `acceptEdits`, `dontAsk` or `bypassPermissions`, and `never-ask` is refused. Each task keeps its own persisted session; unscoped chat reuses one only while exactly one task is in progress, and a `hub_inbox` read refuses a batch attributed to another task. The approval path fails closed: `hub_permission_request` is accepted only from the current child's launch and generation, goes to the console's existing approval queue and `approvals.timeout_s`, and offers allow-once and deny only, with no allow-always or session grant. A timeout, a prompt failure, a disconnect, a hub that is down or refusing, or a stale child binding answers deny; a failed hook decides nothing, so the call still waits for a person. The approval title is the tool name and a JSON rendering of the arguments passed through `sanitize()` and the public-text screen (any PII, secret or private-path match withholds the whole value as `[withheld]`, before any cut), never task text, cut at 600 characters with a `[cut, N chars]` marker; the original arguments stay with the child and are not logged. The MCP wire cannot tell a native permission dispatch from a call the model makes itself; a person allow still refers only to its original arguments. Automatic Bash authorization uses the separate single-use host wrapper contract below, never a caller-supplied tool id as native provenance. A stop holds an uncertain delivery until the owned process group is confirmed gone. The [native permission receipt](verification/2026-10-23-headless-claude-permissions.md) is model-free on Claude Code 2.1.309, [repeated on 2.1.310](verification/2026-10-26-claude-implementer-2.1.310.md), [on 2.1.314](verification/2026-10-31-claude-implementer-2.1.314.md) and [on 2.1.316](verification/2026-10-31-claude-implementer-2.1.316.md); it is not sandbox proof, and a real account, model and person interaction remains a live leg.
+The headless Claude implementer (#525-4) runs one owned `claude -p` child per turn in its declared worktree, with `--setting-sources ""`, `--strict-mcp-config`, native permission mode `default`, the hub's managed PreToolUse hook and `--permission-prompt-tool mcp__agent-hub__hub_permission_request`; never `--bare`, `acceptEdits`, `dontAsk` or `bypassPermissions`, and `never-ask` is refused. Each task keeps its own persisted session; unscoped chat reuses one only while exactly one task is in progress, and a `hub_inbox` read refuses a batch attributed to another task. The approval path fails closed: `hub_permission_request` is accepted only from the current child's launch and generation, goes to the console's existing approval queue and `approvals.timeout_s`, and offers allow-once and deny only, with no allow-always or session grant. A timeout, a prompt failure, a disconnect, a hub that is down or refusing, or a stale child binding answers deny; a failed hook decides nothing, so the call still waits for a person. The approval title is the tool name and a JSON rendering of the arguments passed through `sanitize()` and the public-text screen (any PII, secret or private-path match withholds the whole value as `[withheld]`, before any cut), never task text, cut at 600 characters with a `[cut, N chars]` marker; the original arguments stay with the child and are not logged. The MCP wire cannot tell a native permission dispatch from a call the model makes itself; a person allow still refers only to its original arguments. Automatic Bash authorization uses the separate single-use host wrapper contract below, never a caller-supplied tool id as native provenance. A stop holds an uncertain delivery until the owned process group is confirmed gone. The [native permission receipt](verification/2026-10-23-headless-claude-permissions.md) is model-free on Claude Code 2.1.309, [repeated on 2.1.310](verification/2026-10-26-claude-implementer-2.1.310.md), [on 2.1.314](verification/2026-10-31-claude-implementer-2.1.314.md), [on 2.1.316](verification/2026-10-31-claude-implementer-2.1.316.md) and [on 2.1.318](verification/2026-11-05-claude-implementer-2.1.318.md); it is not sandbox proof, and a real account, model and person interaction remains a live leg.
 
 The #845 host shell wrapper is the only automatic Bash path for a headless implementer. In `ask-when-needed`, a complete public input must pass the existing #816 read-only proof or the closed task-command proof, with an active owned task and registered worktree. Enabled action-policy classes still ask, and `ask`, PII handling and the `never-ask` refusal are unchanged. The native request and authenticated host response both name wrapper protocol 1, so an older plugin cannot drop the rewrite and execute an original command automatically.
 
@@ -835,6 +869,8 @@ What the sandbox can and cannot write is stated here so nobody relies on more. A
 
 On decline or cancel the hub removes the worktree and deletes the branch while it is still the empty base. A worktree with uncommitted changes, or that cannot be checked, is never force-removed: it is kept with its branch and reported as a console notice. A branch the hub committed to is kept, because its commit may be pushed and under review. A peer that makes its own worktree (Claude, Codex, Kimi) is untouched, and a PII task never gets a hub worktree. Residual: a same-user process outside the sandbox can still plant a ref under `.git/refs/heads`; the sandbox no longer lets a sandboxed command do it (#1123), and the hub refuses to commit or push on top of a moved ref either way.
 
+Worktree shelf (#1057). Apart from the empty hub-made task worktree above, the daemon never removes a worktree or deletes a branch; the shelf only reads and records the person's Park or Pin. `ahub worktrees` and the `ahub worktrees tidy` preview are reads an agent may run outside a private turn; Park, Pin, "Refresh PR states" and `tidy --confirm` are the person's (the console, or the dashboard session the manager forwards for it; a live-test dashboard is refused, and `tidy --confirm` is person-only for an agent identity and refused under `--live-test`). The only removal path is `ahub worktrees tidy --confirm <fingerprint>` in the person's own CLI process (`src/cli/worktree-tidy.ts`, which the daemon does not import). It re-reads every row and refuses the whole run when the fingerprint changed, operates only on a path git itself lists, and runs exactly `git worktree remove <path>` and `git branch -d <branch>`, never `--force` or `-D`. A row is refused when it is the main checkout, an instance worktree, outside the project, dirty, locked, without a branch, unpushed, without an upstream, not merged into the default branch, bound to a task that is not approved or cancelled, or on a branch that changed since the preview, and whenever git cannot tell; a parked row passes the same checks. No read makes a GitHub call; only the explicit refresh does, for at most 8 PRs. A worktree bound to a PII task keeps that binding on the host, so it stays live and tidy refuses it, but its row carries no task id, PR or task state.
+
 Refs, HEAD and worktree admin writes (#1123). A hub-sandboxed peer (Pi, the local worker) cannot move what a branch, `HEAD` or a linked worktree points at. The profile (`gitRefRules` in `src/local/deny.ts`, built into `hubWriteRegexes`) refuses every write to `refs/**` (branches, tags, `refs/stash`, remote refs), `packed-refs` (and its lock and new files), `HEAD` (and `HEAD.lock`) and `worktrees/**` (a linked worktree's admin dir: its `HEAD`, `index`, `logs`, anything new, and a new admin dir). The rules sit directly under the git dir, so a project below a directory that happens to be named `refs`, `worktrees`, `HEAD` or `packed-refs` keeps working. They cover a plain `.git`, and each external git dir (the common dir and a linked worktree's own, whether the worktree is inside the project or beside it, and a bare repository's common dir that is not named `.git`). Every name is folded for the code points HFS+ ignores like the other git names, and each regex literal stays under seatbelt's 1024-byte limit at any project depth (`test/sandbox-git-refs.test.ts`, run with the real sandbox-exec in the main checkout, in a hub-made worktree, in a worktree outside its project and in a bare repository's worktree). The hub's own git is hardened and runs outside the sandbox, so #1115's hub commit and push are unaffected.
 
 What a sandboxed command can still write under `.git`, each with its reason, probed with the real profile: the main checkout's `index` and `index.lock` (`git add` and `git restore` stage there), `logs/HEAD`, `ORIG_HEAD`, `FETCH_HEAD`, `MERGE_HEAD`, `COMMIT_EDITMSG`, `info/exclude` and `description` (none can run a program or move a branch), and NEW loose objects under `objects/` (a staged blob, #864; existing objects, `objects/info` and `objects/pack` stay refused). Still refused as before: a gitfile, `config`, `config.worktree`, `hooks`, `commondir` (#270). Inside a linked worktree the sandbox cannot write the worktree's own admin dir, so `git add` there fails on its `index.lock`; the working tree itself is writable and `git status`, `diff`, `log`, `show`, `blame`, `ls-files`, `rev-parse`, `for-each-ref` and `cat-file` all still work.
@@ -879,6 +915,14 @@ role admission.
   separate `runner-attested` level described below; their fields never overwrite
   declared or host-measured evidence. Public experiment recording tools and the
   receipt CLI are the separate #602 slice.
+- **Claim evidence links (#931 T1).** `hub_evidence_record` is published only to
+  research-profile peers. It admits only the current in-progress owner of a stored
+  research task, outside a private turn, on a non-PII task and a registered public
+  source whose raw hash matches. The checks repeat after screening and inside the
+  append transaction. Its relation, projection hash and locator are declared
+  provenance, never an entailment judgment or host verification; person verdicts
+  stay the only judgment record. Receipts carry the link id, revision and task id
+  only, and arguments and results are excluded from capture.
 - **Privacy.** A campaign whose parent task is PII, or that names a private source,
   is private, and so is an attempt with a private task, input or output path.
   Public views keep ids, counts, states and provenance and stub every question,
@@ -938,7 +982,7 @@ A handoff crosses a project boundary, but not a security boundary: both projects
 belong to the same machine user. The origin daemon reads the target's control
 token file and connects to the target's daemon as the `console` role through
 `ControlClient`, like every control message; the hello checks the target's project
-root and instance. It sends that connection only the three handoff messages, and
+root and instance. It sends that connection only the four handoff messages, and
 it has no reach a same-user process lacks (see "What is not defended").
 
 - **Who may hand off.** `ahub task handoff` is Console in `classifyPeerCommand`;
@@ -948,21 +992,28 @@ it has no reach a same-user process lacks (see "What is not defended").
   the target's own `status.json` must advertise `task_handoff` and name no other project. A target
   that is not running is refused with the action; nothing is queued.
 - **No authority in the target.** The target answers `task_handoff`,
-  `task_handoff_event` and `task_handoff_states` to a console connection only, and
+  `task_handoff_event`, `task_handoff_by_key` and `task_handoff_states` to a console
+  connection only, and
   refuses a new handoff while it recovers or shuts down. The task is an ownerless proposal
   its own hub makes and routes. The origin project and peer are a record in
   `task_handoff_origin` and a line at the end of the detail, never an actor, a
   roster peer or a role: the origin cannot accept, review, approve, assign or
   cancel there.
 - **What crosses.** To the target: a title (300 characters), a class, a detail
-  (4,000), up to 16 repository-relative paths, a spec issue number, and the origin
-  project id, peer id and task id, at most 8 KiB in all. The request is parsed
+  (4,000), up to 16 repository-relative paths, a spec issue number, an optional
+  `duplicate_ok` reason (300, kept in the target's detail), a handoff key (a UUID,
+  sent only to a target that advertises `task_handoff_key`), and the origin project
+  id, peer id and task id, at most 8 KiB in all. The request is parsed
   closed on both sides: an unknown field, an accessor or a control character is
   refused, never dropped, and the target sanitizes before it stores. No memory,
   evidence, turn content or task history crosses. Back to the origin: an event
-  name, a PR number and a full 40-hex head, never the target's title, notes or
-  other text; the restart catch-up answers only for tasks whose recorded origin
-  is the asking project, with the same fields. The origin peer gets that as a
+  name, a sequence number, a PR number and a full 40-hex head, never the target's
+  title, notes or other text; a duplicate-issue refusal names only the target's own
+  open non-PII task ids. The catch-up (at start, every five minutes and when a
+  target's descriptor changes) and the key lookup answer only for tasks whose
+  recorded origin is the asking project, with the same fields. A key the target
+  already holds answers with the task it made and never files a second one; the
+  same key with a different request is refused. The origin peer gets that as a
   hub-written `kind: task` message.
 - **Privacy.** The origin refuses during a private turn and for a `[pii]` task
   named as the source, before anything leaves. The text itself is checked by the
@@ -1076,9 +1127,20 @@ targets before any local effect; implicit broadcast never crosses the boundary.
 
 Signed completion proves remote durable queue admission only and is displayed as
 completed (admitted). Crypto inbox, application claim and Bus publication use
-separate durable stages; a cross-DB failure is uncertainty, never an exactly-once
-or native-execution claim. Late proof cannot auto-settle uncertainty. Person
-accept/discard is local disposed metadata and never a signed application receipt.
+separate durable stages; a receiver cross-DB failure is uncertainty, never an
+exactly-once or native-execution claim. A late authenticated ordinary-chat receipt
+may settle its matching unresolved sender row under current room/member identity,
+without overriding a person disposition. Invocation uncertainty remains person-held
+and is never inferred from transport proof. Person accept/discard is local disposed
+metadata and never a signed application receipt.
+
+Sender retries retain the application id, canonical content and original queue TTL.
+A distinct root delivery requires the same retained content hash and recipient,
+with no disposition or permanent hold; it inherits the original creation/expiry.
+Legacy unknown content hashes refuse cross-root reuse. Receipt ciphertext commits
+to the local durable outbox before chat transport ACK and replays until broker
+storage confirmation. Deferred admission may ACK its durable crypto inbox entry
+and commit its receipt when admission resumes. Neither path claims native execution.
 
 Schema3 reserves a separate durable lane for at most eight canonical receipt
 payloads per room, at most 1,024 bytes each and 512 KiB extra globally. A receipt
@@ -1098,12 +1160,15 @@ Capacity recovery requests fresh presence once per transition; runtime and
 other storage errors stay unACKed.
 Fresh, fully authenticated chat at the ordinary cap is likewise durably refused
 and transport-ACKed without admission, floor advance or signed receipt. Its
-sender remains uncertain until the application ACK deadline; the refused chat
-cannot hold matching receipt traffic behind it in the broker FIFO.
+sender retries at the ACK deadline under the same immutable application id, without
+renewing its queue TTL. Queue expiry or a permanent refusal ends automatic sending.
+The refused chat cannot hold matching receipt traffic behind it in the broker FIFO.
 
 Permanent signed sequence floors survive all application retention/eviction.
 Application-id and trace guards retain 30 days/10,000 rows per room, settled first;
-outside that retention they make no historical claim. MAX_HOP 3 remains absolute.
+outside that retention they make no historical claim. Automatic resend can reach
+this settled-eviction ceiling and repeat admission under a fresh ciphertext sequence:
+exactly once within dedupe ceiling. MAX_HOP 3 remains absolute.
 All-unsettled capacity refuses with ids/counts, and person disposition releases
 settled capacity. This state protects against other users, not hostile code
 running as the same user with access to the private room keys. Native/account,
@@ -1176,3 +1241,58 @@ path and no polling when no real cleanup occurred.
 Done/discard acknowledgement precedes the background room retry. A network retry
 failure or socket loss during that later work cannot report a committed local
 disposition as failed.
+
+## Hub-owned session titles
+
+`hub_set_title` (#1055) is offered only to fixed Pi/local definitions with a
+hub-owned title slot. Publication grants no authority: the daemon checks the
+current adapter/session, private turn, open PII ownership or review and public
+metadata policy. An agent may write only while the native/current slot remains
+unnamed. A person's console rename may replace it, but cannot bypass privacy.
+The title and any unnamed display label are screened again when shown; unknown
+screening is `[private]`. Title tool inputs/results are excluded from capture
+and progress observations. No title crosses rooms, changes task/Git/instance
+records, or causes an extra model call.
+
+A fallback label is never persisted. Its original message has the existing
+journal retention; the separate `session-title-inputs.json` stores only peer,
+title-session, delivery and envelope IDs written by positive delivery
+acknowledgement, never by a title tool. Restart resolves a still-retained
+original only for the same title-session ID. A missing or different session,
+invalid binding or pruned original yields no inherited label. Live status may
+show it only to the console or configured conductor; other readers see
+`unnamed`. Metadata screening does not grant audience membership. The label's
+source note identifies incoming-message text and never attributes it as the
+recipient peer's own speech. `status.json`, events, logs and memory never
+receive a derived copy. Removed-instance and Local bindings are not retained.
+
+## Questions a peer asks the person (#1053)
+
+`hub_ask` lets any peer put a structured question (one to four questions, two to eight options each) to the person. A question is not a permission: it is its own record in `hub.db` (`questions`), has its own control messages, and never expires as a denial.
+
+- **Who answers.** Only the console role. The control message `answer { questionSet, answers, surface? }` is refused, with a reply and no change to the row, for every `tools` or `peer` connection, the asking peer's own included. Nothing a peer writes counts as an answer: a `hub_send` body, a tool result, a file or an envelope that quotes one (the exact JSON `hub_ask` returns included) is text, and `test/questions-daemon.test.ts` pins that none of them changes a row. The answer envelope the peer receives is built by the hub (`kind: "answer"`, `from: "user"`), so its header cannot be forged: every body goes through `sanitize()`, and `kind`, never the sender, is what code keys on.
+- **One terminal transition.** `open` becomes `answered`, `superseded`, `cancelled` or `expired` by one compare-and-set (`UPDATE ... WHERE state = 'open'`). Of any number of concurrent answers, stops and expiries exactly one wins, and every other caller is told the row's real state. A second answer is refused and publishes nothing.
+- **Validation.** An answer is checked against the stored row before anything is written: every question answered once, only offered option ids, one option unless `multi`, free text only where `allowOther` and at most 500 characters. The refusal names the question by position and never echoes the offered or submitted text. Input is closed and bounded the same way (`parseAsk`).
+- **Answering from acon (#1053 T5).** The plugin accepts an `answer` action only when the console advertises `action.meta` and passes its own `meta` (`via: "console"`, a verified `identity` and `node`), which the page cannot set. Without it, or with page-supplied `identity`, `surface`, `questionSet`, `projectId` or `instanceId` fields, the action is refused before any request reaches the hub (`test/questions-plugin.test.ts`). The project and set come from the inbox item id the plugin built, never from the page. The plugin reaches the hub through a dedicated manager port (`projectConsole(...).answer`), not through the dashboard action whitelist, so the dashboard page of `ahub ui --all` and the manager's `ui_action` whitelist have no `answer` action, and a page can never answer for the person. The hub re-validates every answer against the stored row. The verified `identity` the plugin read from the console's own `meta` rides with the answer (`answer { ..., surface: "acon", person }`); the hub records it, one bounded line, on the answered row and on the `question` event, and reads `person` only for the `acon` surface, so a terminal or console answer cannot claim another person. It is never question or answer text. The acon types of the form and of the submitted answer (`ActionMeta`, `InboxVerb`, `VerbForm`, `InboxAnswers`) are type-only imports from the exact-pinned `@staix/agent-console/contract` entry, never hand-copied. `ahub answer` with any operand is refused in `liveTestRefusal` (a delegated `--live-test` run is promoted to console identity, so without it an agent shell could answer its own `hub_ask` as the person); only the bare listing is allowed there.
+- **Residual.** The same as `permit`: a vendor agent that can read the control token can act as the console (see "What is not defended"). This feature does not narrow that and does not widen it.
+- **Privacy.** Question and answer text live in `hub.db` and in the envelope addressed to the asking peer, nowhere else: never `hub.log` (an `answer` or question-notice envelope logs a fixed stub), never `events.jsonl` (the `question` event carries the set id, peer, event name, counts, latency, surface and a closed reason), never the console tail or the dashboard feed (`redactBusEvent` stubs the body), never memory capture (`QUESTION_TOOLS`) or the progress observer. A question asked in a PII turn, or about a PII task, is stored `private` and its late envelope is private too. The inbox title of a private question is a stub (`<peer> asks a question`); its text is only in the answer form, the person's own answer surface, and the status attention model, the stream line and the CLI audit carry ids only. `test/questions-console-daemon.test.ts` pins these with a PII task, the status reply, the dashboard snapshot, `hub.log`, `events.jsonl` and memory capture.
+- **Not defended.** A peer that is cancelled, superseded or restarted loses a pending question's wait, never its row, until the person or `questions.ttl_s` settles it. An answer a person gives is shown to the asking peer in full; do not ask the person for a secret.
+
+## Results a person's runs leave behind (#1054)
+
+A result is the record that a run the person started has settled. Reading one and marking it read are separate acts, and only the person makes the second.
+
+- **A receipt is the person's, on every surface.** `result_seen`, `results` (`read-all`, `unread-last`) and the dashboard's `result_seen`, `results_read_all` and `results_unread_last` write or delete a receipt, and each is refused unless the caller is the console role or a dashboard session the console opened: a peer's connection, a `hub_send` body, a tool result or an agent shell (`ahub results` is the person's command, and its receipt forms `--read`, `--read-all` and `--unread-last` are in `liveTestRefusal`, so a delegated `--live-test` run of them is refused too; the bare listing stays allowed there) is text and never reaches the store. A snapshot, a listing and the Results section's refresh never write one; a poll is not a person looking (`test/results-dashboard-1054.test.ts`).
+- **From acon.** The plugin accepts `result_seen`, `results_read_all` and `results_unread_last` only when the console advertises `action.meta` and passes its own `meta` (`via: "console"`, a verified `identity` and `node`), which the page cannot set. Without it, or with page-supplied `identity`, `surface`, `person` or a completion key, the action is refused before any request reaches the hub (`test/results-plugin-1054.test.ts`). The project and the result come from the inbox item id the plugin built or, from the panel, from the project it is showing; acon's `seenAt` and `explicit` are accepted and dropped, because the hub stamps its own time. The write goes through a dedicated port (`projectConsole(...).receipt`) as a console-role control message on the `acon` surface, never through the dashboard's forwarding list, and a plugin that is not given the person's meta cannot widen that.
+- **A live-test dashboard** gets no results and is refused every receipt, in two places that each hold alone: the page server's live-test allowlist and the daemon's own guard (`test/results-dashboard-1054.test.ts`).
+- **Residual.** The same as `permit`: a vendor agent that can read the control token can act as the console (see "What is not defended"), and so can write a receipt. This feature does not narrow that and does not widen it. A receipt is not an authority: it clears an unread need and nothing else.
+- **Privacy.** No prompt or reply text is stored: a completion row keeps envelope ids only. The one-line detail shown beside a result (the head of the starting prompt) is built when the person looks, from the envelope the bus still holds, after `sanitize` (so it cannot forge a hub header) and the hub's secret, PII and private-path screens; it is thrown away after it is shown and is in no `hub.db` row, `hub.log` line, `events.jsonl` event, status field or memory capture (canary tests: `test/results-dashboard-1054.test.ts`, `test/completions-daemon.test.ts`). A private run shows `a private request` without its body being read, a head the screens refuse shows a withheld stub, and a request the bus no longer holds shows nothing. The title is built from the peer and the outcome, never from request text, and the `completion_seen` event carries the id and the surface.
+- **Not defended.** The detail is the person's own request shown back to them on their own surfaces, so a request that holds something the screens do not recognise is shown to the person who typed it. Marking a result read does not mean the person read it: the hub takes the console's word, and acon's seeing rule (agent-console#27) is what makes that word mean the result was in view.
+
+## Anchored review comments (#1056)
+
+Person comment writes (`review_comment_put`, `review_comment_delete`, `review_comment_send`) are console-role control messages, and their actor is always the person: the conductor, a planner and every peer are refused. From acon they require the console's verified `ActionMeta` (`via: "console"`, `identity`, `node`). Page-supplied `author`, `meta`, `personMeta`, `at`, `state` or `sentAt` fields are refused before any request, and delete and send also need acon's confirmation fingerprint. The standalone `ahub ui` page is read-only for comments.
+
+- **Material.** Placement material comes only from guarded immutable Git snapshots at the task's recorded head (declared refs, plan paths, or same-head verified PR paths), bounded per operation to eight files and eight seconds; a sent package is at most 12,000 bytes. `review_blob` refuses a PII task, and periodic snapshots make no comment-material Git or GitHub read. PII tasks and private paths keep comments on the board and count-only in every public view.
+- **Delivery.** A sent package carries the host-only `refs.reviewPackage` marker: the intended owner gets the body, while logs, stream projections, incoming labels, memory capture and observers get an ids-only stub; review markers a peer supplies are discarded. Open sent comments, anchored findings and unsettled review deliveries keep the original recipient's responses out of shared memory and observers until resolution, dismissal, task close or explicit disposition (#1192, #1205). The marker grants no task, console or PII authority.
+- **Retry and recovery.** A send is never retried automatically, and a queued receipt proves publication, not that the owner read it. A restart, upgrade or recovery onto a daemon lacking `review_comments` is refused while anchored comments are stored.

package/docs/smoke.md

@@ -38,7 +38,7 @@ Autonomy T4 (#999 AC8): [2026-11-02 live inventory](verification/2026-11-02-auto
 | Character glyphs in real terminals and tmux (#280) | Console attention; Dashboard character | agent-evidence / person-verdict | glyph rendering in physical terminals |
 | Console Settings panel in a native terminal (#439) | Settings reload and console fixture | agent-evidence / person-verdict | the panel as a person sees it |
 | Reviewer pool native legs (#519) | Reviewer pool native legs | agent-executable | after #783 ships |
-| Antigravity TUI close (#485) | Antigravity P1 | agent-executable | |
+| Antigravity TUI close (#485) | Antigravity P1 | agent-executable | launcher close leg passed on 2026-11-03 ([receipt](verification/2026-11-03-agy-tui-close.md)); still open: `hub_send` and a board read or proposal through the TUI, a real account |
 | Managed Pi live receipts (#418 AC8) | none yet (issue #418) | person-only, then agent-executable | the person opts in to a check runner and answers the approvals |
 | Kimi credential probe (#285 AC9) | Kimi usage counting | person-only | the owner's approval of the probe |
 | Six role instances (#525-6, hub card #138 I4) | Six role instances (#525-6) | person-only | native terminal/account starts, the person's sandbox and approval choices, and the live six-instance verdict |
@@ -2025,7 +2025,8 @@ Kimi usage ceiling: 2.2.0 print stream-json exposes no token counts. Keep unobse
 
 ## Antigravity P1 (#485)
 
-- Run agy on the 1.4.x line (1.4.2 and 1.4.7 verified; other patches warn, #589); verify its executable/version and keep the actual TUI/IDE leg separate from the account-free T0 transport receipts ([1.4.2](verification/2026-10-19-agy-p1-t0.md), [1.4.7](verification/2026-10-26-agy-1.4.7.md)).
+- Run agy on the 1.4.x line (1.4.2, 1.4.7 and 1.4.12 verified; other patches warn, #589); verify its executable/version and keep the actual TUI/IDE leg separate from the account-free T0 transport receipts ([1.4.2](verification/2026-10-19-agy-p1-t0.md), [1.4.7](verification/2026-10-26-agy-1.4.7.md), [1.4.12](verification/2026-11-03-agy-1.4.12.md) and its [launcher nonce leg](verification/2026-11-03-agy-1.4.12-launcher-nonce.md)).
+- The hub launcher's own close leg ran in a scratch project with the real `ahub agy` and a fixture provider ([2026-11-03 receipt](verification/2026-11-03-agy-tui-close.md)): the launch slot is held while agy starts and runs, a normal `/exit` releases it so the next launch is admitted, only the managed three-file plugin is removed, and the real Gemini config hashes are unchanged. Set `AGY_CLI_DISABLE_AUTO_UPDATE=1` for any further live agy run: without it agy replaced `~/.local/bin/agy` during that run.
 - With a reviewed compatible daemon running and agy explicitly on roster, the person runs `ahub agy` in a terminal. Confirm peer `agy` is pull-only, native permissions unmanaged and no hub sandbox/budget source is claimed.
 - In the native TUI call `hub_inbox`, `hub_send`, and a permitted board read/proposal within a non-PII task. Confirm the tool audience and actor remain `agy`, the native model consumes the tool results, and no unsolicited push or PII task text reaches it.
 - End the TUI normally. Confirm its group/socket detaches and only its matching managed three-file plugin is cleaned up; unrelated project/global settings remain unchanged.
@@ -2163,3 +2164,13 @@ account fixture needs the person's account setup. Ask the planner before any
 quota-heavy run. Never publish prompts, tokens, credentials, endpoints, native
 transcripts or session ids as evidence. This slice implements no task `exec`,
 routing policy or matrix runner.
+
+## Pi session title restart receipt (#1055, #1143)
+
+- [ ] Unverified: in a real managed Pi session, call `hub_set_title`, verify its
+  native name and DOING, restart into that same saved session and verify the
+  name survives. A second agent call must return `already_named`; a person
+  rename must replace the name and remain final against the agent.
+- The fake-free Pi 1.5.0 setter/readback/reopen API probe is recorded separately
+  in `docs/verification/2026-11-03-pi-title-api.md`; it does not complete this
+  model-backed managed-session restart receipt. Track the live leg in #1143.