@staix/agent-hub 0.24.0 → 0.25.0

package/docs/operations.md

@@ -557,7 +557,7 @@ and so is every help entry the gate has no class for yet;
 
 | Command | Class | Why |
 | --- | --- | --- |
-| `ahub doctor [--json] [--full] [--color=...]` | Allowed | a read-only check of tools, daemon, plugin, gateway, models and memory |
+| `ahub doctor [--json] [--full] [--color=...]` | Allowed | a read-only check of tools, daemon, plugin, gateway, models and memory; the `memory capture: codex` and `memory capture: kimi` rows come from agent-mem's setup state (`amem setup <tool> --json` on PATH, a preview that writes nothing), as set up, `amem setup <tool> --apply` needed, client missing, or unknown when `amem` is missing, refuses or prints no setup plan (#1008) |
 | `ahub doctor --stale-anchors [--json]` | Allowed | a bounded read-only report of memory symbol anchors at current HEAD |
 | `ahub queue list [--peer <id>] [--json] [--full] [--color=...]` | Allowed | public queue metadata only; held bodies and resolution remain conductor operations |
 | `ahub roster [--json] [--color=...]` | Allowed | public roster status; add/remove retain conductor admission |
@@ -573,6 +573,7 @@ and so is every help entry the gate has no class for yet;
 | `ahub task cancel\|label\|role <id> ...` | Allowed | the daemon decides per task (#933): `label` and `role` only on a task the caller owns, `role` not while it is in review, and `cancel` by the `hub_task_cancel` rule (the planner's own unaccepted backlog or proposed work) |
 | `ahub deliverables [--task <id>] [--approved] [--check] [--json]` | Allowed | only the rows `hub_task_show` would show the caller, through the same public screening (#933) |
 | `ahub room list [--json]`, `ahub room status [<name>] [--json]` | Allowed | room metadata only; every other `room` form, the inbox included, stays Console |
+| `ahub study show [<id> \| --after <id>] [--json] [--color=...]` | Allowed | the same read as `hub_study_show`: a private campaign, task or source shows ids, counts and states only; `study draft\|revise\|approve\|approve-protocol\|close` stay Console (#930) |
 
 `backlog list`, `release list` and `sdlc costs|metrics` retain their existing
 planner/person policy. Their CLI forms stay Console for ordinary agents; a
@@ -926,6 +927,37 @@ Incompatible or unverified processes are shown explicitly and are never killed b
 PID-name matching. See the operations guide and the
 [multi-project specification](specs/2026-09-19-multi-project-design.md).
 
+## acon console plugin (#935, #1012)
+
+`ahub setup` registers agent-hub as a plugin of the family console
+([agent-console](https://github.com/STAIxBWLB/agent-console), `acon ui`). It writes
+`$AGENTHUB_HOME/console/plugins/ahub.json` (default `~/.agenthub/console/plugins/ahub.json`;
+the directory 0700, the file 0600, replaced atomically) naming the installed module
+`@staix/agent-hub/ui-plugin` and its sha256, and prints `acon plugin registered`, `acon plugin
+up to date` or why it was not registered. acon reads the file at its next start and marks the
+plugin stale when the module changed after setup, so run `ahub setup` again after each upgrade.
+
+- **Panels.** The plugin's panels are the dashboard's seven views, and the panel is the `ahub ui`
+  page itself, following acon's theme. It reaches project hubs only through the manager's own
+  listing and forwarding (`ahub ui --all`): registered project and instance ids, the manager's
+  closed action list and the seven view names. There is no new protocol or action.
+- **Inbox.** acon's inbox lists each running project's pending approvals (Allow once / Deny,
+  answered with the hub's own `permit` and an option the request offers) and in-review tasks whose
+  reviewer is you (Open board). A local-worker or Pi approval stays deny-only there, as on the
+  dashboard: answer it with `ahub permit` after `ahub tail`.
+- **Confirmation.** `stop`, `permit`, `send`, the settings writes (`setting`, `setting_undo`,
+  `setting_reload`, `config_edit_apply`), `start_peer`, `backlog_split` and the inbox's Allow once
+  and Deny answer `needsConfirm` with a preview first; acon runs them after you confirm.
+  Previews and the other dashboard actions run directly, as on the page.
+- **Space.** The plugin feeds acon's Space view from the dashboard's office model
+  (`src/ui/office-space.ts`): peers are actors (state from condition, approvals and review, with
+  approval, queue, paused and mode marks), the office rooms are queue, work, review and done zones,
+  tasks are cards, and overlap, conflict and cohort links and recent message arcs are links. Ids
+  are project-prefixed, every running project's scene is merged within acon's caps (32 actors, 200
+  cards, 64 links, newest links kept), and a project that has not answered within about 3 s is left
+  out of that poll. Only labels and states reach the scene, never message bodies, task details,
+  approval titles or reasons; a PII task's card shows the `[pii]` stub.
+
 ## Install and start
 
 Use Bun 1.4.2 or newer. Source checks and CI use the version pinned in
@@ -943,7 +975,8 @@ ahub up
 `ahub init` writes the project configuration and managed instruction blocks.
 Run it after an upgrade when those blocks need refreshing. `ahub setup`
 installs or updates the Claude plugin and a project-neutral PreToolUse hook in each
-Claude configuration home in use (see "Machine autonomy and Claude homes"). Keep `ahub console` open when a local worker
+Claude configuration home in use (see "Machine autonomy and Claude homes"), and
+registers the acon console plugin (see "acon console plugin"). Keep `ahub console` open when a local worker
 may request an approval.
 
 `.agenthub/config.json` can be committed and shared. The fields that choose
@@ -1135,6 +1168,15 @@ and start): a committed file must not choose commands the hub runs. Keys that
 are not task classes are ignored with a log line. A hub stopped mid-check leaves
 the task in progress (`check interrupted`); the owner marks it done again.
 
+The owner may call `hub_task_done` again while the task is in review, with a
+different full lowercase commit SHA in `refs.commit` (#1000, #1021). It replaces the
+delivered artifact, not a verdict: the reviewer gets a fresh request for the new
+head, the old CI watch is replaced, stale observed, reviewed and merge evidence is
+cleared, and open Important findings, spec acceptance and the rejection count stay.
+A configured completion check first returns the task to in progress until it passes.
+The same head, a malformed SHA, another owner or a running check refuse without
+effect, and a verdict started on the old request no longer applies.
+
 While the project root checkout is on a branch other than its default
 (`origin/HEAD`, else `main`), finishing a task adds `the main checkout is on
 <branch>; move the work to a worktree under .worktrees/` to the owner's result
@@ -1427,6 +1469,60 @@ ahub research backfill             # build this project's records once from even
 ahub task label 12 reverted        # a later verdict (ok, regressed, reverted, incomplete, wrong, abandoned)
 ```
 
+## Research campaigns: `ahub study` (#930)
+
+A research campaign splits one question on an approved parent task into bounded units, each a task with
+its own sources and required output. Nothing happens until a campaign is drafted, and the `ahub research`
+telemetry above is unrelated. The contract, its bounds and the slices are in the
+[research campaigns spec](specs/2026-11-01-research-campaigns-design.md); the worked three-source example is in
+[profiles](profiles.md).
+
+```bash
+ahub study draft 12 contract.json            # store revision 1 as a draft; creates no task
+ahub study revise rc-0123456789ab 1 next.json  # store the next draft; a stale revision refuses
+ahub study approve rc-0123456789ab 2         # person only: create the unit tasks as Backlog cards
+ahub study show [rc-0123456789ab]            # list campaigns (50 per page, --after continues) or one projection
+ahub study close rc-0123456789ab 2 --reason "answered"
+ahub study approve-protocol <64-hex hash>    # person only: approve one exact experiment protocol
+```
+
+- **Contract.** The JSON names the question, scope, exclusions, registered source ids, 1 to 32 units
+  (round, question, perspective, required output, sources, dependencies and a purpose: discovery,
+  independent check, analysis or synthesis), deliverable sections, a stop policy (`maxUnits`,
+  `maxFollowUpRounds` up to 5, a deadline at most 90 days after approval) and an optional execution budget.
+  A contract over its bounds refuses whole, naming the field.
+- **Who does what.** Draft and revise are the person's (`ahub study`) or a configured planner's
+  (`hub_study_draft`, `hub_study_revise`); they store drafts only. Approve, approve-protocol and close are
+  console commands. Approval is the only step that creates unit tasks: they go to Backlog and the planner
+  offers them through its ordinary pull; the campaign never assigns owners or approves a task. Re-running
+  approve on an approved revision creates nothing.
+- **Dispatch gate.** Before a unit task is offered, assigned, pulled or handed to another owner the hub
+  re-reads the campaign and holds the task with a reason when its revision is no longer the latest approved
+  one, the deadline has passed or the stop policy is exceeded. A newer draft holds older bound work until it
+  is approved, and an owner offer held this way is re-offered after approval, across a restart too. A hold
+  never stops a native turn already running.
+- **Handoffs and coverage.** The current in-progress owner of a unit records `hub_study_handoff`: evidence per
+  source, unresolved questions, contradictions and limitations, or `insufficientEvidence`. `ahub study show` and
+  `hub_study_show` report per unit its round, task state, handoff completeness, covered sources and duplicate
+  discovery assignments, the budget support label per resource (`enforceable`, `advisory`, `unknown` or
+  `unavailable`) and why dispatch is held. A follow-up round needs every discovery unit of the previous round
+  settled by a complete handoff or `insufficientEvidence`.
+- **Budgets.** A contract's `budget: { id, hardCap: [...] }` names an existing execution budget. With a non-empty
+  `hardCap`, approval refuses unless the budget is enabled, every capped resource has a limit and is not
+  `tokens`, and at least one of its peers is instrumented (today `pi` and `local`); every later dispatch and
+  owner change rechecks that same budget. The ledger is shared with the peers' other work.
+- **Experiments.** Protocols, comparison plans and attempts are stored with their provenance (`declared`,
+  `host-observed` from a check receipt or a hub-hashed deliverable), and `ahub study approve-protocol` binds an
+  approval to one exact protocol hash and its evaluator; a changed protocol needs its own approval. The hub
+  never ranks results. This release has no hub tool or CLI that records experiments; they are host storage
+  for the slices that follow.
+- **Privacy.** A campaign whose parent task is PII, or that names a private source, is private: every view keeps
+  ids, counts, states and provenance and stubs its text as `[pii]`. Study tool arguments and results are kept out
+  of hub-managed memory capture.
+- **Upgrades.** The daemon advertises `research_records`, `research_dispatch`, `research_dropped_offers`,
+  `research_experiments` and `research_comparisons`. While the matching rows exist, a restart, upgrade or
+  recovery onto a release without the feature is refused.
+
 ## Hub memory
 
 The hub opens the selected amem memory profile under `memoryHome()` (default `~/.agenthub/memory/`), with no claude-mem worker dependency ([how it works](memory.md)): notes saved
@@ -1442,7 +1538,7 @@ ahub memory forget 1a2b3c4d              # a person's; also promote, demote, sup
 
 `"memory": { "native": false }` in `.agenthub/config.json` turns it off for a project.
 
-The exact-pinned `@staix/agent-mem` 0.15.0 resolves `AMEM_HOME`, then `$AGENTHUB_HOME/memory`, then `~/.agenthub/memory`. An absent `M/profile.json` selects shared v1; an explicit generation selects `M/generations/G` with the package's readonly legacy bridge. All daemon memory consumers and the hub memory/goal CLI use that selected profile. Invalid metadata or a missing selected generation makes native memory unavailable while the bus and board continue; there is no fallback to legacy writes. Inspect the daemon's memory binding/availability before interpreting missing memory as an empty store.
+The exact-pinned `@staix/agent-mem` 0.18.0 resolves `AMEM_HOME`, then `$AGENTHUB_HOME/memory`, then `~/.agenthub/memory`. An absent `M/profile.json` selects shared v1; an explicit generation selects `M/generations/G` with the package's readonly legacy bridge. All daemon memory consumers and the hub memory/goal CLI use that selected profile. Invalid metadata or a missing selected generation makes native memory unavailable while the bus and board continue; there is no fallback to legacy writes. Inspect the daemon's memory binding/availability before interpreting missing memory as an empty store.
 
 The daemon checks its selector at hub operation entry and before candidate/counter writes. It does not hot-switch handles or provide an atomic fence against selection changes during an in-flight core call. Quiesce consumers and close their handles before migration or selection changes; reopen through the supported session-preserving lifecycle afterward. Candidate/counter storage remains `M/candidates.db`, independent of `G`; since agent-mem 0.7.0 `amem review` also lists and accepts candidates on a selected generation. Every running hub using this home needs an authenticated receipt: a matching ready binding, or a generation-capable unbound receipt (`disabled` when native memory is off, `unavailable` when opening failed) proving it holds no memory handle. An unbound daemon and zero running hubs are quiesced for memory; a stale bound handle, unreadable registry or unknown runtime is not ready. Existing JSON memory/goal results remain unchanged; the additive binding receipt belongs to daemon status, profile-check and the decay object. This source integration does not authorize installing a new runtime, migrating real memory, restarting sessions or claiming real-machine sync/capture receipts. Migration/deactivation and their limits belong to [agent-mem](https://github.com/STAIxBWLB/agent-mem); see [the hub profile contract](memory.md#selected-memory-profile).
 
@@ -4323,6 +4419,22 @@ A bundled adapter module is authorized by the person with `adapter_modules` (at
 - Refresh instructions with init and restart the daemon/MCP clients to apply their resolved contracts. Existing flow-role and executable-check authority remains in `roles`/trusted `checks`. Native model/account evidence remains unverified.
 
 
+## Calendar schedules: `cron` and `tz` (#1017)
+
+A `schedules` entry in `.agenthub/config.local.json` takes either `every` (an interval, `<n>m|h|d`, 15 minutes at least) or `cron`, never both. `cron` ties the run to the clock:
+
+```json
+{ "schedules": [{ "id": "digest", "cron": "30 7 * * 1-5", "tz": "Asia/Seoul", "class": "plan", "title": "Morning digest" }] }
+```
+
+- **The expression** is the standard five fields, minute, hour, day of month, month, day of week, with numbers, lists (`1,15`), ranges (`1-5`) and steps (`*/15`, `10-50/10`). Day of week 0 and 7 are Sunday. There are no seconds, no year, no `@daily` macros and no names (`MON`, `jan`). When both day fields are restricted a day matches if either does (the classic rule); a field that begins with `*` leaves the other to decide.
+- **`tz`** is an IANA zone name (`Asia/Seoul`, `America/New_York`) and applies to `cron` only. Without it the machine's own zone is used. An unknown zone is refused with the entry named.
+- **Daylight saving, one rule.** A local time the clock skips runs at the next valid minute of that day; a local time the clock repeats runs once, at its first occurrence.
+- **Too frequent.** An expression that can fire more often than every 15 minutes (`* * * * *`, `*/5 * * * *`, `0,10 7 * * *`) is refused when the config loads, naming the schedule, as is one that never fires (`0 0 31 2 *`).
+- **Everything else is as for `every`.** A schedule never runs at first sight; a hub that was down or held through several fire times proposes one task when it can, not one per missed fire; a budget pause or hold skips and counts the tick; no second task while the first is open. `ahub schedule list`, `ahub status` and the dashboard show the expression and the next run in the schedule's zone, for example `2026-11-02 07:30 Asia/Seoul`.
+- **Upgrades.** The daemon advertises `calendar_schedules`. While a schedule uses `cron` or `tz`, a restart, upgrade or recovery onto a release without it is refused, naming the reason.
+- Out of scope: holiday and exchange calendars. A task whose first step finds a non-working day can end itself.
+
 ## Staging work in Backlog (#263)
 
 Use `ahub task propose implement "Later work" --backlog --owner codex` to stage
@@ -4941,7 +5053,7 @@ Native launcher connections retry transport timeouts/unclean closes with bounded
 
 ## amem runtime (agent-mem#13 P4)
 
-The hub exact-pins @staix/agent-mem 0.15.0 for recall, curated evidence and local deterministic capture. No runtime call reaches a claude-mem worker; `memory.worker_url` is ignored. The person's `ahub memory import claude-mem` remains explicit and off by default. Existing profile, alias, PII and private-turn fences still apply. `ask --remember` and context checkpoints propose machine-local candidates, never automatic curated evidence. See [memory integration](memory.md#in-process-recall-and-capture-agent-mem13-p4) for changed behavior and bounded-view ceilings.
+The hub exact-pins @staix/agent-mem 0.18.0 for recall, curated evidence and local deterministic capture. No runtime call reaches a claude-mem worker; `memory.worker_url` is ignored. The person's `ahub memory import claude-mem` remains explicit and off by default. Existing profile, alias, PII and private-turn fences still apply. `ask --remember` and context checkpoints propose machine-local candidates, never automatic curated evidence. See [memory integration](memory.md#in-process-recall-and-capture-agent-mem13-p4) for changed behavior and bounded-view ceilings.
 
 ## Backlog issue identity and notes
 
@@ -5334,3 +5446,24 @@ Lists are complete up to 1,100 rows. If an all-room list exceeds that limit, the
 CLI explicitly asks you to choose a room name; it never silently truncates.
 ponytail: pagination is later work; a filtered room's 100 unread plus 1,000
 settled stubs fit the current response ceiling.
+
+## Handing work to another project (#604, agent-hub#1030)
+
+Work that belongs to another repository that runs agent-hub on this machine goes onto that repository's board, not into this session. Its own roles plan, implement and review it, and each state change it reaches is reported back here. The first case: after a library you maintain publishes a release, raising its exact pin in a consumer belongs on the consumer's board.
+
+```
+ahub task handoff --project <root|id> [<class>] <title...> [--path <p>]... [--issue <n>] [--task <n>] [--detail <text>]
+```
+
+- `--project` is the other project's canonical root or its id from `ahub projects`. It must be registered and its hub must be running (`ahub up` in that project). Nothing is queued: a hub that is not running is refused with that action.
+- A feature or behavior change first gets a spec issue in the other repository: pass its number as `--issue`. A mechanical chore (an exact version pin, a regenerated file) goes straight to a task.
+- `--path` names files in the other project, repository-relative (no absolute path, `~` or `..`). `--task` names your own task this comes from, so a `[pii]` one is refused.
+- `ahub task handoff` is the person's command (an agent's shell is refused it as a console command). Agents use `hub_task_handoff` (the same fields) when they hold the planner or conductor role; `hub_task_handoffs` and `ahub board --handoffs` list what this project handed over and the last state each target reported.
+
+What the other project sees: an ownerless proposed task, made by its hub, whose detail ends with where it came from; `ahub board` and `ahub task show` there name the origin project and peer. Its own routing offers it as it would a local proposal. The requesting peer has no identity or authority there: it cannot accept, review, approve, assign or cancel.
+
+What comes back: each change is recorded in `ahub board --handoffs`, and an agent that handed the task over also gets one `kind: task` message per change, `agent-hub task 123 accepted`, `in review`, `approved: PR #7 at <sha>`, `declined` or `cancelled` (a handoff you made from the terminal sends you no message: read the list). It carries an event name, a PR number and a full head, never the other project's text. If this project's hub was stopped meanwhile, it asks each running target hub where its open handoffs stand when it starts again; a target that is down then is asked at the next start.
+
+Refusals, each named with the action: an unregistered target, this very project, a hub that is not running, a request over 8 KiB or with an unknown field, a caller that is not a planner, the conductor or the person, a private (PII) turn, a `[pii]` task named with `--task`, text that matches the target's PII patterns or that the target's screen cannot clear, a target hub in recovery or shutting down (hand it off again after that ends), and an older target hub (it lacks the `task_handoff` feature: run `ahub upgrade` in that project).
+
+Recovery: `task_handoff` is its own recovery label. A project that holds a handoff row, in either direction, refuses a recovery target that lacks it.

package/docs/profiles.md

@@ -21,6 +21,8 @@
 - Configure an explicit machine-local `checks.fact_check` command if desired. Alias checks take precedence over a base `checks.test`; no check runs merely because a profile was selected.
 - Example deterministic check: `bun /path/to/agent-hub/scripts/check-citations.ts report.md references.bib`. It checks bracketed Markdown `[@key; @other]` keys against BibTeX entry keys, with 256 KiB/4 MiB input caps. It performs no fetch, validates no source quality and is not a full Markdown/BibTeX parser. A missing key exits 1. A resolved bibliography is one check, not proof that claims are supported.
 - Keep a person's sign-off as the final review. The live three-source/two-agent example remains unverified and was not run during solo implementation.
+- A multi-unit study (#930, #601) goes through `ahub study`: the person (or a configured planner with `hub_study_draft` / `hub_study_revise`) stores a contract as a draft, only the person approves it with `ahub study approve <id> <revision>`, which creates one task per unit, and anyone reads coverage with `ahub study show [<id>]` or `hub_study_show`. A unit owner records `hub_study_handoff` with evidence for every source the unit names, or `insufficientEvidence`; a done task is not a handoff, and an incomplete handoff does not close a discovery round. A private campaign, task or source shows ids, counts and states only.
+- The deterministic three-source, two-peer example (`test/study-daemon.test.ts`, "three-source, two-peer example"): one contract names sources S0, S1 and S2 and two discovery units, `alpha` (S0 and S1, owned by codex) and `beta` (S2, an independent check, owned by kimi). After `ahub study approve` both units read `none` and `0/2 covered`, `0/1 covered`. A handoff for S0 only moves `alpha` to `incomplete` with `1/2 covered`. A handoff for both S0 and S1, and one for S2, make both `complete` and the discovery round complete. Another peer's handoff for `alpha` is refused. This runs with fake peers: it shows the hub's rules, not that a native model follows the guidance.
 
 # General project example
 

package/docs/quickstart.md

@@ -17,7 +17,7 @@ ahub setup                                # installs the channel plugin and a pr
 Or use the matching GitHub release:
 
 ```bash
-bun add -g github:STAIxBWLB/agent-hub#v0.24.0
+bun add -g github:STAIxBWLB/agent-hub#v0.25.0
 ahub setup
 ```
 
@@ -30,6 +30,10 @@ and upgrade or crash recovery, see the [operations guide](operations.md). To
 move running projects to a newer release later, run `ahub upgrade` in a
 terminal: it reviews the plan with you, applies it and follows it.
 
+## Upgrading to 0.25.0
+
+Nothing changes until you use something new. `ahub setup` now also registers agent-hub as a plugin of the family console ([agent-console](https://github.com/STAIxBWLB/agent-console), `acon ui`): it writes `~/.agenthub/console/plugins/ahub.json` with the sha256 of the installed `@staix/agent-hub/ui-plugin` module, so acon shows the dashboard's views as panels for every running project, lists pending approvals (Allow once / Deny) and in-review tasks whose reviewer is you in its inbox, and asks you to confirm every outward or destructive action first (#935, #1032). The same plugin feeds acon's Space view from the dashboard's office model: peers are actors, the board columns are zones and task links and recent messages are links, with labels and states only, never bodies, details or approval titles (#1012, #1033). acon refuses a module that changed after setup, so run `ahub setup` again after this and every later upgrade. The hub exact-pins `@staix/agent-mem` 0.18.0 (was 0.15.0); since agent-mem 0.16.0 every amem writer on one memory home, hub pins included, must run 0.16.0 or later, because an older drain deletes hook-spool records a newer one staged without reading them, so upgrade the hub together with a global `amem` of 0.16.0 or later (#1035, #1042). `ahub doctor` now reads its `memory capture: codex` and `memory capture: kimi` rows from that `amem` (`amem setup <tool> --json`, a preview that writes nothing) instead of `dot ai memory status`, and names `amem setup <tool> --apply` when setup is pending (#1025). Research campaigns are new and start only when you draft one: `ahub study draft` stores a contract (question, scope, sources, units and a stop policy) as a draft, a configured planner may draft and revise it with `hub_study_draft` and `hub_study_revise`, only your `ahub study approve` creates the unit tasks as Backlog cards for the planner to offer, unit owners record their evidence with `hub_study_handoff`, and `ahub study show` reports coverage per unit, budget support and why dispatch is held; `ahub study approve-protocol` approves one exact experiment protocol hash (#1024, #1027, #1028, #1029, #1031, #1041; see [research campaigns](operations.md#research-campaigns-ahub-study-930)). While campaign or experiment records exist, a restart, upgrade or recovery onto an older release is refused. A schedule in `config.local.json` can now take a five-field `cron` expression with an optional IANA `tz` instead of `every`; while one does, a restart or recovery onto an older release is refused (#1022; see [calendar schedules](operations.md#calendar-schedules-cron-and-tz-1017)). An owner can now re-file `hub_task_done` during review with a different full commit SHA, and the reviewer gets a fresh request for the new head (#1021). Work that belongs to another project that runs agent-hub on this machine can now go onto that project's board: `ahub task handoff --project <root|id> <title...>` (you) or `hub_task_handoff` (a planner or the conductor) files it there as an ownerless proposal when that hub is running and has the `task_handoff` feature, and `ahub board --handoffs` and the requesting agent learn each state change it reaches (#1030, #1043; see [handing work to another project](operations.md#handing-work-to-another-project-604-agent-hub1030)); while a handoff record exists, a restart, upgrade or recovery onto an older release is refused. A connection that names a peer but is not that peer's current Claude session, such as a plugin that inherited another project's hub, now joins as a distinct `<peer>~<id>` sender that can send and read but holds none of that peer's roles, and every message and attach in `events.jsonl` records the sending connection; nothing that connected before is refused, this tells sessions apart without authenticating them, and while an unsettled delivery holds such a session's message, a restart, upgrade or recovery onto an older release is refused (#1036, #1037). Upgrade running hubs with `ahub upgrade` and restart Claude sessions so they load the 0.25.0 plugin.
+
 ## Upgrading to 0.24.0
 
 Nothing changes until you opt in. `ahub autonomy on` (person only, from a terminal) previews the shipped autonomy preset for this project and applies it with one confirmation: task auto-pull and sweep switches, permission and start defaults, and `action_policy.floor: true`. `--all-projects` applies it to every registered project. `ahub autonomy status [--json]` reports each peer's effective mode, where the floor is enforced and the Claude homes. `ahub autonomy off` removes the preset keys, including hand-set values of those keys, and the retained consent (#1009, #1010; see [project autonomy](operations.md#project-autonomy-one-preset-and-one-confirmation-999-t1)). `on` also writes the machine default `~/.agenthub/defaults.json` (owner-only, 0600), which a newly initialized project inherits; `off` disables it (see [machine autonomy](operations.md#machine-autonomy-and-claude-homes-999-t2)).
@@ -144,7 +148,7 @@ The restarted Claude planner gets the release-train tools (`hub_release_new`, `h
 
 Jcode must be 0.98.0 or later, below 1.0.0; 0.94.0 is no longer accepted, so `ahub doctor` fails its Jcode row for an older install and the peer does not start (#529). Every owned jcode process runs with `JCODE_NO_TELEMETRY=1`.
 
-Since 0.12.37 the hub opens a split memory home through its shards (#534); the current exact `@staix/agent-mem` pin is 0.15.0. Before anyone runs `amem migrate --shards` on a memory home, every hub using that home must run 0.12.37 or later: an older hub does not see the split and keeps writing the old layout. `ahub memory profile-check` is split-aware and compares each hub with its own project's shard (#536). See [memory profiles and rollout](memory.md#selected-memory-profile).
+Since 0.12.37 the hub opens a split memory home through its shards (#534); the current exact `@staix/agent-mem` pin is 0.18.0. Before anyone runs `amem migrate --shards` on a memory home, every hub using that home must run 0.12.37 or later: an older hub does not see the split and keeps writing the old layout. `ahub memory profile-check` is split-aware and compares each hub with its own project's shard (#536). See [memory profiles and rollout](memory.md#selected-memory-profile).
 
 From 0.12.30 or earlier, existing Jcode project MCP entries need one refresh before conductor or dashboard starts. Once per project, the person runs:
 
@@ -212,7 +216,7 @@ More: `ahub help`. How it is built and why: [`docs/specs/2026-09-19-agent-hub-de
 
 ## Shared memory
 
-The hub exact-pins the first-party `@staix/agent-mem` 0.15.0 core, including deterministic capture; no claude-mem worker is needed. Existing shared-v1 memory remains the default; upgrading does not migrate it. Managed agents use screened `hub_memory_search`, `hub_memory_show` and `hub_memory_graph` tools, or propose a correction with `hub_memory_correct`; only a person accepts candidates through the supported `amem review` path. Since agent-mem 0.7.0, `amem review` also accepts candidates on a selected generation.
+The hub exact-pins the first-party `@staix/agent-mem` 0.18.0 core, including deterministic capture; no claude-mem worker is needed. Existing shared-v1 memory remains the default; upgrading does not migrate it. Managed agents use screened `hub_memory_search`, `hub_memory_show` and `hub_memory_graph` tools, or propose a correction with `hub_memory_correct`; only a person accepts candidates through the supported `amem review` path. Since agent-mem 0.7.0, `amem review` also accepts candidates on a selected generation.
 
 Before any real generation migration, upgrade every hub sharing that memory home to 0.12.30 or later and check its authenticated binding with `ahub memory profile-check` in each custom registry. Ready bindings prove compatibility, not an atomic live cutover: quiesce consumers and close their handles before migrating, then reopen through the supported session-preserving lifecycle. Invalid or changed profiles disable native memory without falling back to legacy writes; the bus and board continue. See [memory operations](operations.md#hub-memory) for the remaining rollout gates.
 
@@ -245,6 +249,9 @@ load historical logs. An unopened dashboard has no listener. A paused budget
 window cannot be overridden on the page; the CLI's `ahub budget resume <peer>`
 remains the explicit override.
 
+If you use the family console (`acon ui`), `ahub setup` registers the same
+dashboard there as a plugin; see [the acon console plugin](operations.md#acon-console-plugin-935-1012).
+
 
 ## Concurrent project development (0.4.0)
 

package/docs/security.md

@@ -7,7 +7,7 @@ agent-hub connects agents that can each run commands. This page says what the hu
 - **Other agents' text is untrusted.** Every message that crosses from one peer to another is framed as untrusted input: a channel tag with `meta.source` for Claude started with `ahub claude`; otherwise a fixed header line (`frame()`, `[agent-hub message from ...]`) with an instruction that says it is untrusted, the plugin's server instructions for a tools-only Claude reading `hub_inbox` and a standing instruction for the others. A message body cannot forge the hub's own headers: such lines are quoted (`sanitize`). Replies inherit a hop count capped at 3, so agents cannot ping-pong forever; neither a digest nor a steer can reset it.
 - **The control link is loopback plus a secret.** The daemon and the Codex proxy bind 127.0.0.1 only. The control WebSocket requires a per-run token (`.agenthub/state/control-token`, mode 600), and both servers refuse any request that carries an `Origin` header: any web page can open a WebSocket to localhost, and browsers always send `Origin`. The bearer header a Codex TUI sends to the proxy carries only the terminal launch id (#586): it binds terminal ownership and is not a credential. External clients cannot claim the console user's id or a hub-managed peer's id.
 - **Permission prompts stay on unless an operator selects a permission mode.** `ask` leaves native decisions unchanged. `ask-when-needed` grants scoped Claude file tools or Pi/local writes and edits, and a headless Claude implementer's proven shell commands through the host wrapper (#845, below); Kimi and Codex use their own native policies. `never-ask` requires explicit runtime confirmation, a person's console `y` for a config default at hub start, or retained autonomy consent bound to that peer's exact never-ask value in the untracked `config.local.json` (#999, below). Without one of these the peer runs in `ask`. Kimi's and `local`'s permission requests are relayed to the console and cancelled after `approvals.timeout_s` (default 120 s) of silence; the macOS notification for a waiting request carries the peer and the tool name only. The one exception is the hub's own tools (`hub_send` and the task tools, matched by exact name): Kimi's requests for them are approved once without a prompt and logged by name, the same trust Codex gets through `approval_mode` in the hub's config. They invoke hub-owned operations rather than arbitrary file or shell tools, and every call passes the hub's own checks. A call the always-ask policy classes (below) is never approved this way, whatever its title. Identity comes from the exact permission title, or from the earlier tool-call title bound to the same call id and resolved against the configured MCP servers when the permission title contains argument JSON (Qwen). Payload text and unrelated display titles never establish identity. Configured ACP kinds (#451) never get this exception: a request whose title spells a hub tool exactly still goes to the person approval path, and only a mapped native mode changes what the agent itself asks. For ACP agents, a payload longer than the console shows is marked as cut and never offers a session-wide grant. Pi's write, edit, shell and git write requests are relayed the same way and can be answered `Always allow <tool> until Pi restarts`: later calls of that tool by the same Pi start skip the prompt but stay inside the path guard and sandbox. The grant covers every later call of that tool whatever its payload, is kept in memory only, cannot be given from the dashboard, and each call it allows is logged by tool name. A Pi or `local` request whose call was cancelled or whose turn ended is withdrawn at once: a later answer is refused and grants nothing, an `Always allow` included. One shell command runs without a hub approval: the `!command` a person types in the managed Pi TUI. It stays inside the same sandbox and denylist, and the hub takes it only from the verified owner process of a Pi in TUI mode, while Pi is idle, on a reservation that is used once; a model's own bash call never takes that path (issue #253). `--unattended` turns prompts off, says so loudly, and is never the default; a classed call from a hub-owned ACP peer, the local worker or Pi still waits for a person under it.
-- **A committed config cannot choose launch commands, credential files, data endpoints, permission modes or a wider sandbox.** The machine-local fields (`kimi_cmd`, `permission_modes`, `codex_bin`, `pi.cmd`, `checks`, `mlx.bin`, `mlx.runtimeDir`, `mlx.modelPath`, `omniroute.urls`, `omniroute.access_hosts`, the `omniroute` key files, `memory.worker_url` (still accepted, ignored since 0.16.0), `local.read_allow`, `local.bash_network`, `local.network_allow`, `local.doc_read`, `local.web_fetch`, `terminal.open`, `tasks.auto_pull`, `tasks.queue_backpressure`, `context.max_assignment_used`, `schedules`, `folder_triggers`, `corpus.paths`, `invocation`, `instances`, `action_policy`, `rooms`) apply only from a config file git confirms nobody committed (`instances`, `action_policy` and `rooms` are read only from an untracked `.agenthub/config.local.json`; in `config.json` they are ignored even when untracked): `.agenthub/config.json` or `.agenthub/config.local.json`, matched by file identity so no other spelling the file system accepts slips past, and `.agenthub` itself not a committed symlink or submodule. Without a repository, or when git fails, they keep their defaults; an empty value always means the default. "Untracked" is answered by the repository that contains the project: a checkout copied or extracted into an unrelated repository, or into an ignored directory of one, is trusted like your own files. So a cloned repository cannot choose a launch command, a completion check, a gateway to send a key file to, a memory endpoint, a permission mode, the command that opens a terminal, a folder the hub reads, work proposed on a timer, a host a model may fetch from, which of your agents' skills other peers may call, or a wider sandbox. A command in `checks` runs as you, outside the local worker's sandbox, like a git hook. So do the `setup` and `verify` commands of a benchmark suite (issue #251): `ahub bench run <suite.json>` is a person's command, refused from an agent session, and it resets the work tree for each attempt, so it runs only with `bench.enabled`, at the root of a clean repository that tracks nothing under `.agenthub/`. Nothing in `routing.toml` or in task text is ever run. `routing.toml` and the other shared fields still come from the checkout, and they matter: `routing.toml` picks the models the local worker and the hub's inference use at your gateway and can turn the PII constraint off, and roles and budget shape who does what. Review them in a repository you do not trust. The hub's own git calls outside the sandbox (snapshots, facts, config trust, project discovery, memory recall, the bench runner) all use the single hardened implementation in the exact-pinned first-party `@staix/agent-mem/platform` package, re-exported by `src/hub/git.ts`, which disables the programs a repository's configuration can name — the file-system monitor, hooks, external diff, the pager, and the credential and askpass helpers, with prompts failing closed — so a config that ever does get written cannot run code with the hub's rights. Of those, the monitor, hooks and external diff are reachable by commands the hub issues (the planted-program test exercises all three; a `diff --no-index` reads the repo's config, so that call also passes `--no-ext-diff` and `--no-textconv`); the pager is not (every call pipes stdout). Credential and askpass helpers are disabled for project repositories; memory sync alone may use credentials for its own memory repository, without prompts. The cost: `core.fsmonitor=false` also turns off a person's enabled built-in monitor for the hub's own calls, so the per-turn snapshot's `add -A` scans the whole tree (the snapshot Git calls of one burst share a 250 ms budget, each call at most 10 s; a boundary that runs out is recorded as unknown, never as a stale baseline) (#576). git has no global switch for filter drivers, and of the hub's commands only the snapshot's `add`/`restore` would run one (its driver command lives in the protected `.git/config`).
+- **A committed config cannot choose launch commands, credential files, data endpoints, permission modes or a wider sandbox.** The machine-local fields (`kimi_cmd`, `permission_modes`, `codex_bin`, `pi.cmd`, `checks`, `mlx.bin`, `mlx.runtimeDir`, `mlx.modelPath`, `omniroute.urls`, `omniroute.access_hosts`, the `omniroute` key files, `memory.worker_url` (still accepted, ignored since 0.16.0), `local.read_allow`, `local.bash_network`, `local.network_allow`, `local.doc_read`, `local.web_fetch`, `terminal.open`, `tasks.auto_pull`, `tasks.queue_backpressure`, `context.max_assignment_used`, `schedules` (the `every`, `cron` and `tz` forms alike), `folder_triggers`, `corpus.paths`, `invocation`, `instances`, `action_policy`, `rooms`) apply only from a config file git confirms nobody committed (`instances`, `action_policy` and `rooms` are read only from an untracked `.agenthub/config.local.json`; in `config.json` they are ignored even when untracked): `.agenthub/config.json` or `.agenthub/config.local.json`, matched by file identity so no other spelling the file system accepts slips past, and `.agenthub` itself not a committed symlink or submodule. Without a repository, or when git fails, they keep their defaults; an empty value always means the default. "Untracked" is answered by the repository that contains the project: a checkout copied or extracted into an unrelated repository, or into an ignored directory of one, is trusted like your own files. So a cloned repository cannot choose a launch command, a completion check, a gateway to send a key file to, a memory endpoint, a permission mode, the command that opens a terminal, a folder the hub reads, work proposed on a timer, a host a model may fetch from, which of your agents' skills other peers may call, or a wider sandbox. A command in `checks` runs as you, outside the local worker's sandbox, like a git hook. So do the `setup` and `verify` commands of a benchmark suite (issue #251): `ahub bench run <suite.json>` is a person's command, refused from an agent session, and it resets the work tree for each attempt, so it runs only with `bench.enabled`, at the root of a clean repository that tracks nothing under `.agenthub/`. Nothing in `routing.toml` or in task text is ever run. `routing.toml` and the other shared fields still come from the checkout, and they matter: `routing.toml` picks the models the local worker and the hub's inference use at your gateway and can turn the PII constraint off, and roles and budget shape who does what. Review them in a repository you do not trust. The hub's own git calls outside the sandbox (snapshots, facts, config trust, project discovery, memory recall, the bench runner) all use the single hardened implementation in the exact-pinned first-party `@staix/agent-mem/platform` package, re-exported by `src/hub/git.ts`, which disables the programs a repository's configuration can name — the file-system monitor, hooks, external diff, the pager, and the credential and askpass helpers, with prompts failing closed — so a config that ever does get written cannot run code with the hub's rights. Of those, the monitor, hooks and external diff are reachable by commands the hub issues (the planted-program test exercises all three; a `diff --no-index` reads the repo's config, so that call also passes `--no-ext-diff` and `--no-textconv`); the pager is not (every call pipes stdout). Credential and askpass helpers are disabled for project repositories; memory sync alone may use credentials for its own memory repository, without prompts. The cost: `core.fsmonitor=false` also turns off a person's enabled built-in monitor for the hub's own calls, so the per-turn snapshot's `add -A` scans the whole tree (the snapshot Git calls of one burst share a 250 ms budget, each call at most 10 s; a boundary that runs out is recorded as unknown, never as a stale baseline) (#576). git has no global switch for filter drivers, and of the hub's commands only the snapshot's `add`/`restore` would run one (its driver command lives in the protected `.git/config`).
 - **Telemetry holds no bodies.** `.agenthub/state/events.jsonl` (issue #40) records envelope ids, routing and sizes, task ids and states, overlapping paths and token counts, and the task id (with a PII flag) that each usage and token record is attributed to. It never records a message body, a task title or detail, and marks private (PII) envelopes and tasks as such. Budget pauses, resumes and quota resets carry the peer, window, times and the hub's own reason text, and a person's release authorization its commit, version and docs digest. The usage roll-up (#683) folds the usage, token and limit records into `hub.db` and joins issue, PR and release from the board when read; `ahub usage` and the console's Usage panel answer only the console and a configured planner, and a planner not during a private turn. Kimi's token records (#285) are counted from its own session wire log under its home: only the four token integers, the model label and the row time are copied, and the record id is an opaque hash, never a path, session id or text. The log stays on the machine; `ahub export` only prints it. Two opt-in stores copy numbers from it into your home directory, shared by every project on the machine (directories mode 700, files 600): research records (issue #247, `research.enabled`) in `~/.agenthub/research/` hold per approved task the ids, states, counts, tokens, times and PII flag the events hold, a person's label from a closed list, and a hash in place of the project id; benchmark runs (issue #251) in `~/.agenthub/bench/` hold suite name and hash, arm label, the attached peers' ids, models and permission modes, task ids, outcomes, exit codes, counts, tokens and times, never suite text or a command's output.
 - **Snapshots stay in your repository.** Per-turn snapshots (issue #33) are git objects in the project's own object store, written through a temporary index; nothing is referenced, pushed or copied elsewhere, and `git gc` prunes them. They hold what the work tree held, including untracked files that are not ignored, so keep secrets in ignored files. They carry the repository's own permissions, and nothing caps their disk use but `git gc`. A turn of a peer holding an open PII task is not snapshotted; a PII file left in the project is snapshotted by later turns like any other file. `ahub undo` restores only files whose current content is exactly what the turn left.
 - **The edit hook reads, never decides.** `ahub check-path --hook` (issue #32) reads hub.db and returns context for Claude and a line for you; it sets no permission decision, so your permission rules stay in charge. It names other owners' task ids, titles and states, which then reach Claude's model; PII tasks are left out.
@@ -24,13 +24,13 @@ 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.15.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.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.
 
 `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.
 
 Code neighbours (#684 phase 4). For a symbol start, `hub_memory_graph` and the dashboard Memory view's Code neighbours toggle add one hop of callers and callees, read at the current commit through the optional code-facts boundary and shown with that commit; these edges are never stored. They share the graph limits above, an ambiguous or name-only seed is withheld, attached notes are screened again when published, current HEAD, profile, policy and caller privacy are rechecked across awaits, and a PII task or private turn starts no code query. `ahub doctor --stale-anchors` (#684 phase 3) only reads: it never edits, deletes or repairs a note, and an anchor whose task record is now private, foreign or missing stays unknown.
 
-`hub_memory_correct` requires `memory_correct` and proposes a machine-local candidate after the same project/privacy checks, including revalidation after asynchronous screening. It cannot accept or alter a note. Public review failures with unmet items may also propose candidates through Tasks, and `ahub ask --remember` answers and context checkpoints are saved only as candidates, never as curated notes (agent-mem#13 P4). Candidates and usage counters stay at `M/candidates.db`, are not synced/imported, and never enter recall, briefs, ask or graph evidence. A person accepts shared-v1 candidates through the package CLI's TTY/policy checks; the accepted result is an ordinary v1 note, while the sidecar remains local. Generation `amem review` remains unsupported and refuses. Citation counters are observation proxies, not evidence that an agent understood or used a note.
+`hub_memory_correct` requires `memory_correct` and proposes a machine-local candidate after the same project/privacy checks, including revalidation after asynchronous screening. It cannot accept or alter a note. Public review failures with unmet items may also propose candidates through Tasks, and `ahub ask --remember` answers and context checkpoints are saved only as candidates, never as curated notes (agent-mem#13 P4). Candidates and usage counters stay at `M/candidates.db`, are not synced/imported, and never enter recall, briefs, ask or graph evidence. A person accepts shared-v1 candidates through the package CLI's TTY/policy checks; the accepted result is an ordinary v1 note, while the sidecar remains local. Generation `amem review` is supported since agent-mem 0.7.0, subject to the package CLI's applicable TTY and policy checks. Citation counters are observation proxies, not evidence that an agent understood or used a note.
 
 The hub binds the selected root/profile at open. Invalid/missing generation metadata refuses native memory without a shared-v1 fallback; the bus and board continue. Explicit checks at hub operation entry and before sidecar writes stop later stale calls, but are not atomic against a selector change during an in-flight core operation. Migration therefore requires quiescing consumers and closing handles before changing selection, then reopening through the supported lifecycle. A public core pre-write hook is the upgrade path for atomic in-flight cutover.
 
@@ -417,6 +417,33 @@ This is an honest default against accidental impersonation and injected commands
 It does not make the token inaccessible to an agent with unrestricted project
 shell access. The existing OS sandbox and loopback authentication boundaries apply.
 
+Distinguishable sessions and sender provenance (#1036, #1037) make a mix-up
+between two sessions of one person visible; they are not authentication. A tools
+hello that names a Claude channel peer while presenting a launch id that is not
+that peer's current launch record, or that asks to be a session (the channel
+plugin does when its process has no project of its own and inherited another
+project's state directory), is bound to an id the daemon mints, `<peer>~<origin>`.
+Such a session may send, read status and run the read task ops in
+`SESSION_READ_OPS`; every other message is refused with `this session is <id>,
+not this project's <peer>`. It is never a bus peer: no delivery, no push, none of
+the peer's roles, and it replaces nobody. Its envelopes carry `session: true` and
+recipients see the minted id in the header; an origin label is kept only when it
+already is a plain lowercase token, so no path or sentence reaches a sender name.
+Every envelope event and one `attach` event per admitted peer or tools hello in
+`events.jsonl` carry `origin`: the connection's role, peer and launch or instance
+id, never a path, cwd, token or body. The channel plugin applies the CLI's
+ownership proof to an inherited `AGENTHUB_STATE_DIR` instead of trusting it, and
+does not join a hub whose `status.json` lacks `session_identity` as a session,
+since that hub would bind the real peer id. What this does not guarantee: a hello
+with no launch id still becomes the peer (the native facts hook, helpers and a
+person's shell connect that way), a launch id is an environment value every child
+of the session inherits, not a secret, and a same-user process that reads the
+control token can present the right id, present none, or connect as the console.
+Nothing that connected before is refused. A recipient weighs a `<peer>~<origin>`
+sender as another session's message; a plain peer id proves no more than it did
+before. A restart, upgrade or recovery onto a daemon without `session_identity`
+is refused while an unsettled delivery holds a session's message.
+
 Steering tools require an explicit `conductor` role, independent of default-allow
 capabilities. Only one peer may hold that role. Two task-scoped exceptions need
 no role: a task's current owner and reviewer may read its public view with
@@ -565,6 +592,42 @@ not inherit state, unattended or gateway URL/key overrides from the session that
 opened the manager. Native memory is deliberately not a project-isolation boundary:
 its existing basename/worktree aliases and provider accounts can remain shared.
 
+## acon console plugin (#935, #1012)
+
+`@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.
+
+- **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`
+  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
+  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.
+  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,
+  states, owners and public titles, approval counts, and overlap, conflict, cohort
+  and message link ids. No envelope body, task detail, approval title, reason, path
+  or symbol reaches it, a PII task never joins a link, and the scene is trimmed to
+  acon's caps. `test/acon-plugin.test.ts` pins this with a marker fixture.
+
 ## Peer roster authority
 
 The running peer roster changes only through console-only settings requests.
@@ -760,6 +823,95 @@ Person release authorization (#481 S6). `ahub sdlc authorize-release <version>`
 
 SDLC metrics and control bands (#481 S7). `ahub sdlc metrics` and `hub_sdlc_metrics` are planner or person only, read-only, and refused during a private or PII turn. A private task is counted as withheld and read for nothing else; the report calls no model and makes no GitHub read. Band breaches are written only by the daemon's evaluator through Tasks, never while it is stopping, recovering or has a storage error. A `diagnose` or `propose` card is a backlog task (`triage` or `plan`) whose text is fixed words, numbers and task ids, never task text; it passes the PII signal check and the candidate-text screen before it is written, and no GitHub issue is created. A `log` breach is one hub notice, remembered in the board's `band_notices` table as a marker (`<metric>:#<task>:log`, checked against a fixed pattern) and a time, nothing else.
 
+## Research campaigns and study tools (#930, #932)
+
+Campaign authority is the person's. `ahub study draft|revise|approve|approve-protocol|close`
+are Console in `classifyPeerCommand`, and the daemon answers the `study_*` operations
+to the console role only; `ahub study show` is the only form an agent shell may run.
+Agents use hub tools instead: `hub_study_draft` and `hub_study_revise` take the
+configured planner's planning authority and store drafts only, `hub_study_show` is
+read-only for every connection, and `hub_study_handoff` takes only the current
+in-progress owner of the bound unit task. No tool approves a campaign or a protocol,
+closes a campaign or attests anything, and a unit's `purpose` or a research role
+grants no authority: dispatch, ownership and review use the existing routing and
+role admission.
+
+- **Approval creates work, nothing else does.** Only the person's `ahub study approve`
+  creates unit tasks, as Backlog cards the planner offers through its ordinary pull.
+  The approval revalidates and screens the revision before a single transaction
+  that rechecks it is still the latest draft; a changed campaign, task or
+  dependency refuses whole. A campaign never assigns an owner or approves a task.
+- **Dispatch is rechecked at the write.** Before a unit task is offered, assigned,
+  pulled or handed to another owner, after any asynchronous screen, the hub rereads
+  the stored campaign and holds the task when the revision is not the latest
+  approved one, the deadline has passed or the stored stop policy is exceeded. A
+  contract's `budget.hardCap` is checked against that exact budget id at approval
+  and again at every dispatch and owner change; another budget covering the task
+  proves nothing. A hold never stops a running native turn.
+- **Provenance is never upgraded.** Experiment fields are `declared` unless the hub
+  measured them itself from a finished check receipt for the same task and commit,
+  or by hashing a deliverable through the #509 path policy; an agent-supplied hash
+  is never host evidence. `ahub study approve-protocol` binds approval to one exact
+  protocol hash and evaluator identity hash, and nothing copies it to a changed
+  protocol. Environment descriptors are refused when they contain assignment
+  forms, Bearer credentials or known secret shapes; that screen detects those forms
+  only and does not prove a secret is absent. This release exposes no hub tool for
+  recording experiments, and runner attestation (`research.runners`) is not
+  implemented yet.
+- **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,
+  scope, text, path, excerpt and metric name as `[pii]`; source text is never stored
+  in a campaign or handoff, only source ids. Study tool arguments and results are
+  excluded from hub-managed memory capture, and raw contract, handoff and attempt
+  text never enters task history, notices or memory.
+- **Recovery.** A restart, upgrade or recovery onto a daemon lacking the matching
+  `research_*` feature is refused while campaign, dispatch, re-offer, experiment or
+  comparison rows exist, or while `research.runners` is configured.
+
+## Cross-project task handoff (#604, #1030)
+
+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
+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`;
+  agents use `hub_task_handoff`, admitted for the person, a configured planner or
+  the conductor only, and never for a remote room peer. The target is chosen only
+  from the machine registry by canonical root or id, this project is refused, and
+  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
+  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
+  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
+  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
+  target, against the target's PII patterns and, when the target's model screen is
+  on, that screen under the target's routing; a match or an uncleared verdict
+  refuses the whole handoff and nothing is stored on either board. The origin's
+  own patterns are not applied to the text, so keep private text out of a handoff.
+  `hub_task_handoff` and `hub_task_handoffs` arguments and results are excluded
+  from hub-managed memory capture.
+- **Recovery.** A restart, upgrade or recovery onto a daemon lacking
+  `task_handoff` is refused while either handoff table holds a row.
+
 ## Bounded task specs and isolated checks (#418)
 
 `hub_task_spec` reads only the GitHub issues named by a current owner's or reviewer's task in this project's origin repository, including the validated canonical GitHub intake source when its title/body has no issue token. Bare `#N` references count only in the title; detail references require `owner/repo#N` or `https://github.com/owner/repo/issues/N`. Bare detail numbers denote hub tasks, and arbitrary file paths are not parsed as issue references. A qualified reference cannot begin after a slash or a name character, so `src/hub/tasks.ts#12` is a file path. Routing uses this same parser. Without a GitHub project identity, bare title numbers do not require spec access, but explicit qualified/URL references, `refs.repo` and imported GitHub identity still fail closed. `refs.repo`, which `hub_task_propose` and `hub_task_accept` take since #476 to scope overlap per repository, is metadata only: it grants no file access or execution root, and a spec read for a task naming another repository refuses. The daemon resolves authenticated and container executables outside the project, pins their absolute paths and uses fixed arguments; repository-writable PATH shims are refused. Runner Git resolves its host executable through a restricted PATH. For specs, the model receives no credential or arbitrary authenticated URL capability. Foreign/transferred issues, more than three references, bodies over 64 KiB and aggregate results over 80 KiB fail explicitly. Spec fetches share a 25-second budget inside the control client's 30-second cap; each gh call remains bounded to 15 seconds. Current PII, secret and private-path policy withholds the complete spec rather than returning a partial contract. PII turns and PII tasks refuse these tools. The independent `spec_read` and `check_run` capabilities apply when a peer has a narrowed capability list. Arguments and results are excluded from capture. Proven deterministic pre-effect guards return PreEffectToolRefusal so Pi settles the exact refusal receipt; generic transport/storage failures and failures after durable receipt/output changes remain uncertain, never reclassified from error text.

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

@@ -4700,6 +4700,12 @@ ahub builds the review brief that the workspace gate used to take from `ocr dele
 - **Coverage gate.** `hub_review` takes `coverage: { reviewed: [paths], skipped: [{ path, reason }] }`. An approval must account for every reviewable path. The gate follows the lifecycle mode (deviation from the issue, which refuses always): `enforce` refuses before any write, naming the paths, and also refuses when the brief is unavailable (an unknown inventory is never an empty one); `advise` records `Coverage gap (N): ...` or `Coverage unknown: ...` in the verdict note; `off` and a person's own verdict skip it. The commit under review is the task's commit, else the head the verdict names, else the head its lifecycle receipt records. Code work (a task with a commit, branch or PR) for which none of these is known, or whose brief cannot be built, has an unavailable brief. Work with no commit, branch or PR is exempt, with nothing to account for. So is a `Tasks` built without a brief provider (library use and tests; the daemon always provides one). One head throughout: the head the verdict names, or the `reviewedHead` it would inherit from an earlier review, must equal the brief's head (with a PR, the lifecycle approval gate already binds the reviewed head to the PR head). The task's commit and its lifecycle receipt (which holds the inherited `reviewedHead`) are pinned when coverage is checked and rechecked before every write after an await, so a commit or receipt that moves during the verdict is refused.
 
 
+### Owner re-file during review (#1000)
+
+The owner may submit `hub_task_done` again while the task is `in_review` with a different full lowercase commit SHA. This replaces the delivered artifact, not a reviewer's approval. Same-head, malformed-head, foreign-owner and active-check submissions refuse without effects. Normal privacy, lifecycle, readiness and completion-check gates still apply; a failed admission leaves the old review intact. Concurrent submissions are fenced by their initial history revision, so a delayed submission cannot overwrite a newer delivery.
+
+The new delivery clears stale observed/reviewed/merge evidence and retains local check evidence only when it already names the new head. Spec acceptance, open Important findings and rejection counts remain. A configured completion check atomically returns the task to `in_progress` with the new head; failure leaves it with the owner, and success publishes the new review. Other state transitions are unchanged. Every verdict, even without an explicit head in off mode, is fenced by the request revision it began reviewing. A refreshed delivery publishes a new request and replaces the old CI watcher; it never records a rejection or escalation.
+
 ### Optional changed symbols (#682, #684 phase 1a)
 
 `src/hub/code-facts.ts` is the sole runtime caller of optional ripwire. The initial verified CLI contract is 0.6.7: strict `ripwire.pr-context/v1` and `ripwire.at/v1` XML (these verbs do not support JSON), and validated callers/callees JSON keys. Unknown versions, schemas, malformed/capped output, tool failures and timeouts give `unknown`, never a passing gate. The rendered advice has a 16000-byte ceiling (oversize is unknown). Parse metadata values only; discard raw text, owners, author email and source fragments. Calls have a 5 s execution deadline and an owned-process cleanup bound; cache successful values by canonical repo, SHA and query (including the base for a diff). A busy reader gives new distinct queries unknown instead of making review wait in a queue. Name-only graph edges are marked ambiguous and hidden; graph count floors are retained.
@@ -5188,7 +5194,7 @@ Where the code differs from or fixes a detail the section above leaves open:
 ### Schedules and folder triggers (#512)
 
 - `schedules` is a machine-local key: add it to `MACHINE_LOCAL` in `config-trust.ts`, so only `config.local.json` can set it. A committed config that creates tasks is refused, like the other machine-local keys.
-- Entry: `{id, every, class, title, detail?, sources?, owner?, queue?: "backlog" | "ready"}`. `every` is `<n>m|h|d` with a 15-minute minimum. `cron` is accepted by the schema but refused with "cron not supported yet; use every", because a cron parser is a new runtime dependency or new code; it is a later slice.
+- Entry: `{id, every, class, title, detail?, sources?, owner?, queue?: "backlog" | "ready"}`. `every` is `<n>m|h|d` with a 15-minute minimum. `cron` was refused here until #1017; see "Calendar-anchored schedules (#1017)" below for the calendar form.
 - Due checks run on their own interval timer, started whenever `schedules` or folder triggers are configured, independent of `task_sweep.enabled` (the task sweep's timer exists only when that option is on, and it defaults to off). The timer runs no task sweep, and it is re-armed on config reload. `queue` defaults to `backlog`. Missed runs coalesce: a schedule proposes at most one task per tick, and none while its previous task is still open. A global pause or hold skips the tick and coalesces it. Last and next run times live in `hub.db`, and status and the dashboard show the next run.
 - Folder trigger: `{id, folder, glob?, class, title, ...}`. `folder` is resolved with `realPath`, must lie inside the project or a declared data path, and is polled on the schedules timer, not watched. Symlinks that leave the folder are skipped. A new file (by `realPath`, size, mtime and SHA-256 recorded in `hub.db`) is registered as a source (#508) and proposes one task that names it. The trigger therefore lands after the source registry.
 - `ahub schedule list|run <id>|pause <id>|resume <id>` is person-only for `list`; `run`, `pause` and `resume` are also the configured conductor's since #933 (implementation notes in #512b below).
@@ -5220,6 +5226,20 @@ Where the code states or fixes a detail the section above leaves open:
 - **Dashboard.** The UI snapshot carries `schedules` (the same views, ids, enums and times only; absent when none is configured, so an older page and an unconfigured project see no change). The Agents view has a read-only Schedules table, built from the existing `usage-table` classes so no style changes, with a next-run column worded by `scheduleNextLabel`: the time for `scheduled`, `Paused (would be <time>)`, `Due now`, `Due, waiting for task #N to close` or `Due, held`, and `unknown` for anything else, never an invented time. The dashboard has no run, pause or resume control: those stay the person's CLI commands.
 - **Not in this slice.** Folder triggers (#512c) and cron remain refused or absent.
 
+#### Calendar-anchored schedules (#1017)
+
+Issue #1017 (the person's), AC1 to AC5. It replaces the "cron not supported yet" refusal and changes nothing about `every`.
+
+- **Entry.** `{id, every | cron, tz?, class, title, ...}`. Exactly one of `every` and `cron`; both is refused ("give every or cron, not both"), neither is refused, and `tz` without `cron` is refused. The refusals name the entry like every other config error. `cron` is stored with its fields single-spaced; `tz` is stored as the runtime spells the zone (`asia/seoul` is `Asia/Seoul`).
+- **Expression.** The standard five fields with numbers, lists, ranges and steps (`*/n`, `a-b/n`; a bare `a/n` is refused); day of week 0 and 7 are Sunday. No seconds, no year, no `@` macros, no names, at most 100 printable characters. Both day fields restricted: a day matches if either does; a field that begins with `*`: both must match (the classic rule); the month always has to match.
+- **Zones.** `tz` is an IANA name validated with `Intl.DateTimeFormat`; without it the machine's own zone. No third-party dependency (AGENTS.md): the zone arithmetic is `Intl` and `Date` only, in `src/hub/schedules.ts` (`parseCron`, `cronNext`, `cronMinGapMinutes`, `scheduleNext`, `scheduleZone`), pure, each taking the time it works from.
+- **Daylight saving, the one rule.** Fires are found on the zone's wall clock and then placed on the timeline: a wall time the clock skips runs at the first valid minute of that day (`30 2 * * *` on the spring-forward day runs at 03:00), and a wall time the clock repeats runs once, at its first occurrence (`30 1 * * *` on the fall-back day runs at the first 01:30). A wall time never maps to two fires.
+- **Too frequent (AC3).** `schedulesConfig` refuses an expression whose smallest gap between fires, read on the calendar over one 400-year Gregorian cycle, is under 15 minutes, with the gap in the reason, and an expression that never fires. Daylight saving can move two fires closer on its one change day; a schedule proposes at most one task per pass and none while its previous task is open, so that costs no flood. ponytail: the gap is read on the wall clock, not per zone; upgrade is to walk `cronNext` over the change days of a zone.
+- **Next run and coalescing (AC4).** The period still starts at the anchor (first sight, then the last run) and the schedule is due once `scheduleNext(entry, anchor)` has passed, where `every` is anchor plus the period and `cron` is the next fire strictly after the anchor. A run restarts the period at `now`, so any number of missed fire times is one run: nothing a restart, a hold or a long outage missed is replayed. Holds, budget pauses, the open-task rule, the pause and resume commands, and the fences are `runSchedule`'s, unchanged. A cron with no matching day in a full 400-year Gregorian cycle (146097 days, after which every date and weekday pattern repeats; a Feb 29 that is a Sunday recurs 28 to 40 years apart, so a shorter scan would call it never) has a next run of `Number.MAX_SAFE_INTEGER` and never runs.
+- **Where it shows.** A view carries `cron` and `zone` instead of `every`; the task's detail says `Scheduled on the calendar "<cron>" (<zone>)`. `ahub schedule list` has a SCHEDULE column (`cron 30 7 * * 1-5 (Asia/Seoul)` or `every 1h`) and the next run in the schedule's zone with the relative time; `ahub status` and the dashboard read the same way (the dashboard shows the time in the schedule's zone, and says so when the browser does not know it). An `every` schedule reads as before.
+- **Older targets.** An older daemon refuses a `cron` or `tz` key at load ("cron not supported yet"), so a controlled recovery (`prepare`, `commit` and a target-checking `inspect`) refuses a target without the daemon feature `calendar_schedules` while a raw `schedules` entry in `config.json` or `config.local.json` has either key, before any effect. The raw files decide, so an entry the effective config drops still counts; an unreadable file is unknown, never absent. A project with only `every` entries is unchanged.
+- **Not here.** Holiday and exchange calendars.
+
 #### Folder triggers (#512c) implementation notes (hub task #336: `folder_triggers`, `src/hub/folder-trigger.ts`)
 
 - **Config.** `folder_triggers` is a separate machine-local key (not inside `schedules`, whose entries are time-based), in `MACHINE_LOCAL` and `NEVER_EDITABLE`, validated by the pure `foldersConfig` in the loader and in `config-apply.ts`. Entry: `{id, folder, glob?, class, title, detail?, owner?, queue?}`, at most 16. `glob` is a file-name pattern (letters, digits, `. _ -`, space, `*`, `?`; never a path) that matches whole names; a dot file never matches.
@@ -6426,3 +6446,7 @@ C2 runs `read` invocations end to end. `write` and `external` stay refused (the
 The writing domain pack is named `writing-pack` (base `writing`), preserving the existing rule that a pack cannot shadow a profile. `analysis` uses `research` and the existing analyst role; `ops` uses `general`. The catalog adds four original writing roles (editor, translator, style-checker, terminology-checker) and two original ops roles (project-manager, meeting-actions-owner). Their guidance grants no authority, and pack loading does not assign peers automatically.
 
 Each pack supplies criterion ids in its rubric and exactly one advisory check entry. Standalone examples in `templates/checks/` validate writing JSON metadata/literal terminology/mechanical style, rerun an explicitly selected analysis program twice against declared input/expected bytes, or validate meeting-action owner/due/status records. They are shipped with synthetic fixtures, not executed by init or by parsing pack data. The existing person-owned `checks` policy is still the only way to select a task command. Inputs are bounded to 1 MiB, analysis runs to 5 seconds and 1 MiB stdout each, and errors never echo artifact contents. Checks emit criterion ids and a deterministic final result; semantic quality, meeting coverage and undeclared analysis dependencies remain reviewer judgments. `docs/profiles.md` records exact invocations, formats and limits. The role inventory lint compares every template group with the bundled registry rather than assuming the first eleven definitions. No live adoption or native model ingestion is claimed.
+
+## Amendment: research campaigns, experiment receipts and runner attestation (#930, #932, #1018)
+
+The implementation contract for #929 R1 and R3 and for #1018 is `docs/specs/2026-11-01-research-campaigns-design.md`: campaign, protocol, attempt and receipt schemas and bounds; the provenance levels `declared`, `host-observed`, `runner-attested` and `person-attested`; the Board tables; the person-only activation, attestation and runner registration; the `ahub study` and `hub_study_*` / `hub_experiment_*` wire names; the `research_records` recovery feature; and the delivery slices (#596 to #602). Slices that must differ amend that document in their own PR.