@aeondave/pi-persona 1.17.3 → 1.17.4

package/AGENTS.md

@@ -37,8 +37,13 @@ the shared behavioral prompt layer: [`docs/SPINE.md`](docs/SPINE.md).
   `@earendil-works/pi-*`; never bundle copies.
 - npm publishes as `@aeondave/pi-persona`. Pi supplies the four `@earendil-works/pi-*` packages
   and `typebox`: keep them as `peerDependencies: "*"` with development-only copies, never runtime
-  dependencies. The supported host floor is Pi ≥ 1.0.0 (`MIN_PI_VERSION` and the README); Node.js
-  must be ≥ 22.19 to match that host. Keep the npm
+  dependencies. Target the latest stable Pi only (currently 1.4.0, aligned with `MIN_PI_VERSION`,
+  the four development pins and README); do not maintain historical-host compatibility branches.
+  **No legacy or deferred cleanup:** remove dead code, obsolete options, superseded implementations
+  and compatibility-only aliases with their replacement. Update every caller, fixture and document
+  in the same change. A completed feature must not leave temporary scaffolding or cleanup debt.
+  Keep a path only when it serves the current host/runtime or a demonstrated current data contract.
+  Node.js must be ≥ 22.19 to match that host. Keep the npm
   `files` allowlist explicit for docs/artwork, inspect `npm pack --dry-run`, and never publish drafts.
 - Supply-chain controls: pin every GitHub Action to a verified full commit SHA; keep top-level
   token permissions read-only, grant write permissions only to the reporting job that needs them,
@@ -175,7 +180,7 @@ the shared behavioral prompt layer: [`docs/SPINE.md`](docs/SPINE.md).
   a live, capability-filtered roster (agents, teams and flows, with descriptions and gated flows tagged in
   headless sessions) + a hand-off default (with one decision-class → method line, checked against the
   registry) to the system-prompt TAIL every turn — discovery that survives context burn.
-- **Sibling peer comm (in-process)**: a strategy can opt a run into direct sibling messaging
+- **Sibling peer comm**: a strategy can opt a run into direct sibling messaging
   (`AgentRunSpec.peers` — the `debate` strategy does). The child gets a `contact_peer` tool
   (`bus/peers.ts`): `list`/`send`, ONE-WAY only (blocking stays supervisor-only, so peers can
   never deadlock), peer list scoped per engine instance (never the whole bus), send budget 20,
@@ -183,7 +188,11 @@ the shared behavioral prompt layer: [`docs/SPINE.md`](docs/SPINE.md).
   Delivery: the in-process engine's bridge steers incoming bus messages into the child session,
   fenced with the sender attributed OUTSIDE the fence — the same bridge delivers the supervisor's
   `intercom send` (previously a dead letter). Gated by `EffectiveCapabilities.canUseBus` (OFF iff
-  the persona explicitly denies `intercom`). The child engine ignores `peers`.
+  the persona explicitly denies `intercom`). Child-process legs use the broker's engine-scoped
+  peer roster; `contact_peer` is installed only when that run opts in and the bus is allowed.
+  Granted communication tools join a nonempty child tool allowlist; explicit empty lists and
+  tool exclusions still win. In-process supervisor contact additionally requires `coaching`;
+  broker-connected children expose it when the bus is allowed.
   Design: [`docs/ARCHITECTURE.md`](docs/ARCHITECTURE.md#the-comm-plane-in-practice) + [`docs/STRATEGIES.md`](docs/STRATEGIES.md).
   On the peer plane: `debate` and `pair` always; `map`/`synthesize` opt-in via `params.peers`.
   `magi`/`judge`/`fanout` stay peer-less BY DESIGN — independence is their bias guard
@@ -191,38 +200,37 @@ the shared behavioral prompt layer: [`docs/SPINE.md`](docs/SPINE.md).
   this. `compete` runs its competitors with `isolation: worktree` (REQUIRES a clean git repo; missing
   repo/dirty checkout/worktree failure fails closed and never falls back to the real tree) and returns
   the winning diff for the SUPERVISOR to apply.
-- **exocom** (`src/exocom/*`, `src/tools/exocom*.ts`; opt-in `PI_PERSONA_EXOCOM=1` / `--exocom`,
-  capability-gated): a plane apart from everything above — those are all INTERNAL to one supervisor's
-  own run (hierarchical, session-keyed children); exocom is FLAT and EXTERNAL, between independent
-  top-level pi instances sharing one selected scope, no parent/child relationship. Bare `--exocom`
-  keeps the current workspace scope; exact `--exocom=Ab0T` joins that existing workspace's scope from
-  another cwd through a persistent, collision-aware, case-sensitive four-character Base62 alias.
-  The scope selects registry/transport/ledger/artifacts, while every peer advertises its actual home
-  workspace id/code/safe label so external file sets are explicit. A foreign peer is advisory for
-  writes: it can inspect its own files and use postcards/ask/answer/wait/progress/release, but
-  `exocom_claim` is inactive and rejected because the ledger's paths are repository-relative to the
-  scope workspace. The code is a same-host/same-agent-dir join reference, not authentication.
-  Postcards remain one-way and non-blocking: `exocom_list`/`exocom_send`
-  plus `exocom_name` (a reply is a send with `in_reply_to` set). The separate shared JSONL work
-  ledger adds `claim`/`ask`/`answer`/`decline`/non-blocking `wait`/`progress`/`release`: overlapping
-  open write sets NACK atomically, and a pending targeted ask gates that participant to answer/decline,
-  read-only tools, and `exocom_name` identity metadata. Semantic frames are signed immediate-wake signals; the ledger is authoritative
-  if delivery is deferred. This is cooperative runtime coordination, not OS authorization. All ten
-  tools remain in `EXOCOM_TOOL_NAMES` (with `claim` withheld for a foreign member), targeted denies win independently, and joining requires
-  `canUseBus` plus at least one callable closer (`answer` or `decline`) so a published peer cannot be
-  wedged by an obligation it has no way to settle. If `exocom_name` is permitted, an unnamed top-level
-  Pi is prompted to invent a task-derived call-sign on its first user or inbound peer turn
-  (no catalog or extra model call). Naming is metadata permitted during pending asks, without
-  settling them; a targeted deny suppresses the prompt. Session identity is shared with standalone
-  `agent_name` and persisted across resume/persona changes. Until a handle is chosen, its actionable
-  naming bootstrap is delivered through the `context` hook because custom Exocom wakes can bypass
-  `before_agent_start`; after selection the hook stays silent. The session-hash suffix of a qualified target survives renames and telemetry resolves the
-  same canonical session.
-  Reuses the broker's wire framing
-  (`bus/broker/framing.ts`) and the
-  core fence (`fenceUntrusted`/`attributeInbound`) — no new trust-sensitive code path; inbound
-  attribution is resolved from the registry, never the envelope's self-reported `from_name`.
-  Design: [`docs/ARCHITECTURE.md`](docs/ARCHITECTURE.md#exocom--the-external-plane).
+- **Exocom** (`src/exocom/*`, `src/tools/exocom*.ts`; opt-in `PI_PERSONA_EXOCOM=1` / `--exocom`;
+  see [the collaboration guide](docs/COLLABORATION.md)): a flat external plane between independent,
+  top-level Pi sessions, separate from one supervisor's internal workers. Bare `--exocom` selects the
+  current workspace; exact `--exocom=Ab0T` joins that existing scope from another cwd through a
+  persistent, case-sensitive four-character Base62 alias. The scope selects registry, transport,
+  ledger and artifacts; each member still advertises its actual home workspace. The code is a
+  same-host/same-agent-dir join reference, not authentication.
+  `EXOCOM_TOOL_NAMES` contains 15 call-time-gated tools: `exocom_list`, `exocom_send`, `exocom_name`,
+  `exocom_claim`, `exocom_ask`, `exocom_answer`, `exocom_decline`, `exocom_wait`, `exocom_release`,
+  `exocom_progress`, `exocom_status`, `exocom_task`, `exocom_offer`, `exocom_publish`, and
+  `exocom_profile`. A joined foreign-workspace peer cannot use `exocom_claim`; write-set task create
+  and pickup also require local scope and callable claim permission. Ledger paths are advisory
+  coordination, never filesystem authorization.
+  `exocom_task create` declares a voluntary task but does not start work or reserve files. The
+  immutable `task_id` is the creation frame's `msg_id`; carry it with `work_key` for take, progress,
+  finish, offer and publish so a reused work key cannot select another generation. Write-set pickup
+  and its claim are one locked ledger transaction; read-only tasks may be taken from a foreign scope.
+  An optional `exocom_offer` expires in at most 24 hours (one hour by default) and creates no answer
+  obligation. Use `exocom_ask` for an explicit blocking question. `exocom_publish` shares a bounded,
+  explicitly written excerpt, not another session's terminal-result archive. Peer prose is fenced and
+  attributed using the registry identity.
+  Tasks, offers and evidence are each capped at 64 records and 128 KiB aggregate. Terminal or stale
+  task facts and expired offers are retained for up to one hour; evidence is retained for up to one
+  hour. `exocom_profile` reports self-described capabilities (up to 8 tags, 48 characters each) and
+  optional `available`/`busy`/`away` status; absent status is unknown, and profiles confer no access.
+  During a pending ask, only settlement, `exocom_name`, status, explicit collaboration reads and
+  read-only filesystem tools remain available: profile `get` is allowed, but `set` and `clear` are not.
+  Naming remains metadata and does not answer the ask. Joining requires `canUseBus` plus at least one
+  callable ask closer (`exocom_answer` or `exocom_decline`) and is rechecked on persona changes.
+  Design: [architecture](docs/ARCHITECTURE.md#exocom--the-external-plane) and
+  [collaboration guide](docs/COLLABORATION.md).
 
 ## Testing
 

package/CHANGELOG.md

@@ -4,7 +4,82 @@ All notable changes to this project are documented here. The format follows
 [Keep a Changelog](https://keepachangelog.com/en/1.1.0/); this project follows the version scheme
 used in its [GitHub releases](https://github.com/AeonDave/pi-persona/releases).
 
-## [Unreleased]
+## [1.17.4](https://github.com/AeonDave/pi-persona/releases/tag/v1.17.4) - 2026-10-25
+
+### Added
+
+- Voluntary Exocom collaboration: generation-bound shared tasks with atomic pickup/write claims,
+  expiring optional invitations, bounded attributed evidence publication and self-reported profiles.
+  Stale ownership remains visible without automatic takeover; task/evidence reads are paginated.
+  See [the collaboration guide](docs/COLLABORATION.md) for the authority and retention contracts.
+- Uniform operator views across every pi-persona surface: tool cards and commands use compact
+  purpose lines with shared-literal expansion (monitor, timer, models, read_result, agent_name,
+  contact_supervisor, contact_peer); session cards share the delegate-family frame (`Event · datum`
+  titles, indented clipped lines, boilerplate-free compact with drift-guarded projections, full
+  payload on expansion); the agent tree and F9 overlay show each leg's effort sigla (`mn l m h xh mx`,
+  off renders nothing) with honest requested→observed divergence, and delegate launch cards show the
+  full effort level next to the model.
+- Audited all operator notifications: bounded and sanitized toasts, single-surface settlement
+  announcements (done/stopped announce once via the follow-up card; failures keep their immediate
+  durable surface).
+- Installed-tarball qualification harness (`scripts/qualify-package.mjs`): packs and inspects the
+  artifact, installs it into isolated temporary hosts, and exercises real delegation, stop and
+  shutdown on both engines with a faux provider, network tripwires and empty credential stores.
+  Current policy: latest stable Pi only (1.4.0); historical host versions are rejected.
+- Per-leg thinking/effort: a typed `thinking` level on agents, delegate single/batch calls, roster
+  and council members, and auxiliary actors. Precedence is explicit leg/member > agent definition >
+  the existing configured/inherited child setting; malformed values fail before launch. Both engines
+  report requested and observed Pi effort separately (an observation is Pi's requested effort, never
+  a claim about provider cognition); the child engine passes a separate `--thinking` argument and the
+  model-suffix synthesis is gone.
+- Bounded durable terminal results: settled delegate/council/flow outcomes are saved as versioned
+  session entries with immutable `result:<UUID>` references (count/byte budgets, honest truncation
+  and storage receipts). `intercom results` lists them and `intercom result { ref, offset, limit }`
+  reads pages after reload — read-only: no respawn, no rebilling, no extra wake. The restore notice
+  now distinguishes vanished runtime work from retained terminal reports.
+
+### Fixed
+
+- Show every council/flow participant's launch model and requested effort, including auxiliary
+  judges and repeated roles with distinct inline selections. Persist the receipt for history;
+  pending model setup remains explicit. Role hints omit code and technical identifiers rather than
+  turning environment-variable names or Git refs into reviewer labels.
+- Treat failed model-availability reads as unavailable rather than advertising the whole catalog.
+  Session identity failures remain explicit and cannot reuse a previous owner or synthesize a
+  process-based identity; branch recovery restores the persisted name.
+- Admit granted bridge communication tools through Pi 1.4's plain tool allowlist, so a read-only
+  worker can still contact its supervisor. Empty grants, explicit exclusions and semantic bus denial
+  remain restrictive; sibling contact requires peer opt-in.
+- Refuse incompatible reference-flow journal versions and non-successful archived phases without
+  respawning completed work, including unapproved saved checkpoints. Retain truncation provenance
+  in resumed previews and final reports.
+- Label compact status usage as cumulative input/output tokens, distinct from context occupancy.
+- Preserve observed model identity after recovery in terminal results and completion views, while
+  launch cards retain the original selection. Requested and observed values remain distinguishable.
+- Announce a successful or stopped async run ONCE: the completion follow-up card is the single
+  settlement surface (the tree row already settles immediately); the duplicate info toast is gone.
+  Failures keep their immediate durable card/sanitized toast.
+- Pin isolated worktree exports to the starting commit, preserving worker commits together with later
+  uncommitted changes and new files in the returned patch.
+- Keep unanswered supervisor decisions/interviews unresolved instead of suggesting implicit approval.
+  Expose explicit outcomes and suppress bus activity for already-cancelled calls.
+
+### Removed
+
+- Remove the `/persona none` alias; use `/persona off` to deactivate the current persona.
+- Remove obsolete host API facades, the CJS-only Pi resolver fallback, unused session/notifier
+  options, unemitted identity-message aliases and redundant internal re-exports. Callers and test
+  fixtures now use the current Pi contracts directly.
+
+### Changed
+
+- Clarify and regression-test `/persona restore`: overwrite all bundled defaults without pruning
+  additional custom personas, agents or resources. Settings, credentials and sessions are not reset.
+- Target the latest stable Pi only (currently 1.4.0): development pins, `MIN_PI_VERSION`, docs and
+  the package-qualification gate move together, and historical host versions are rejected. A scoped
+  development override pins `undici` past known advisories inside the Pi 1.4.0 host dependency tree.
+- Align source SDK smoke checks with the canonical settings store and the current interactive vs
+  headless execution contract; settings qualification also rejects historical host versions.
 
 ## [1.17.3](https://github.com/AeonDave/pi-persona/tree/v1.17.3) - 2026-10-23
 

package/README.md

@@ -17,7 +17,8 @@ you can inspect workers, redirect them, or stop a run while it is in progress.
 
 ## Install
 
-Requires **Pi ≥ 1.0.0**, **Node.js ≥ 22.19**, and **Git**. Configure a model provider in Pi first.
+Requires **the latest stable Pi (currently 1.4.0)**, **Node.js ≥ 22.19**, and **Git**.
+Update Pi together with this plugin; historical Pi releases are not maintained. Configure a model provider in Pi first.
 
 Run in your terminal:
 
@@ -39,9 +40,9 @@ your customizations.
 | Install option | Command |
 |---|---|
 | This project only | `pi install -l npm:@aeondave/pi-persona` |
-| Pin this release | `pi install npm:@aeondave/pi-persona@1.17.3` |
+| Pin this release | `pi install npm:@aeondave/pi-persona@1.17.4` |
 | Update an unpinned install | `pi update npm:@aeondave/pi-persona` |
-| Git tag 1.17.3 | `pi install git:github.com/AeonDave/pi-persona@v1.17.3` |
+| Git tag 1.17.4 | `pi install git:github.com/AeonDave/pi-persona@v1.17.4` |
 
 Restart Pi after updating. For a pinned install, install the new version or tag explicitly.
 If switching from a Git install, remove that source first with
@@ -52,7 +53,8 @@ then install the npm package. Keep only one source configured to avoid loading t
 
 | Capability | What you get |
 |---|---|
-| **Async workers** | Specialists with their own roles, skills, and models; results return while the supervisor continues other work |
+| **Async workers** | Specialists with their own roles, skills, models, and thinking levels; results return while the supervisor continues other work |
+| **Retained results** | Bounded reports remain available after reload and can be read in pages without restarting workers |
 | **Live steering** | Inspect a worker, send guidance, or stop a run from the agent panel |
 | **Cross-session collaboration** | Exocom connects independent Pi sessions to exchange findings and coordinate work |
 | **Councils and flows** | Compare perspectives, run repair-and-check loops, or organize work into stages |
@@ -119,8 +121,9 @@ To enable Exocom, open two terminals in the same workspace and start each with:
 pi --exocom --persona dev
 ```
 
-Then ask one session to consult the other or agree who handles which files.
-Use `/exocom` to inspect the connection and workspace code.
+Use `/exocom` to inspect the connection and workspace code. Sessions can exchange one-way messages,
+record a voluntary task, or share a bounded evidence excerpt. Creating a task does not start work in
+the other session; a peer chooses whether to take it.
 
 A session in another workspace can join using that exact, case-sensitive code:
 
@@ -129,10 +132,11 @@ pi --exocom=Ab0T --persona researcher
 ```
 
 Replace `Ab0T` with the code shown by `/exocom`. Both sessions must run on the same machine and
-share a Pi agent directory. A peer joining from another workspace can advise and exchange results;
-it cannot claim files in the joined workspace.
+share a Pi agent directory. A peer joining from another workspace can advise, exchange results, and
+take read-only tasks; it cannot claim or take tasks that declare write paths in the joined workspace.
 
-See the [collaboration guide](docs/EXPERIENCE.md#work-with-another-pi-through-exocom) for day-to-day use.
+See the [cross-session collaboration guide](docs/COLLABORATION.md) for the task, invitation, ask and
+evidence workflows.
 
 ## Choose a persona
 
@@ -170,8 +174,11 @@ See [the reference](docs/REFERENCE.md) for an inline council example and recover
 Edit installed personas and agents in `~/.pi/agent/persona/agents/`, or add project-specific
 overrides in `.pi/agents/`. Run `/persona reload` after editing.
 
-`/persona seed` preserves existing files. **`/persona restore` replaces bundled defaults**, so use it
-only when you intend to discard customizations to those files.
+`/persona seed` preserves existing files. **`/persona restore` overwrites all bundled defaults**
+(personas, agents, teams, flows, contracts, presets and shared prompts), discarding customizations
+to those files. It does not delete additional custom files: a persona `pippo.md` or an agent
+`pluto.md` remains untouched. A custom file using the same destination as a bundled default is
+replaced. Settings, credentials, sessions and project-local overrides are not reset.
 
 For optional long-term memory, add [pi-persona-mind](https://github.com/AeonDave/pi-persona-mind).
 
@@ -186,6 +193,7 @@ refreshes persona definitions. Model changes apply to future runs. See [configur
 | Guide | What's inside |
 |---|---|
 | [Everyday use](docs/EXPERIENCE.md) | Choosing a persona, following work, and reading results |
+| [Cross-session collaboration](docs/COLLABORATION.md) | Voluntary tasks, optional offers, asks, evidence and presence between Pi sessions |
 | [Customization reference](docs/REFERENCE.md) | Tool APIs, configuration, and copyable recipes |
 | [Strategies](docs/STRATEGIES.md) | Teams, councils, flows, and orchestration options |
 | [Timers and monitors](docs/MONITORS.md) | Reminders and programs that wake the supervisor |
@@ -205,8 +213,10 @@ npm test
 ```
 
 Pi loads the TypeScript extension directly; there is no build step.
-To qualify a separately installed Pi 1.3.0 host without cloud calls or your profile, run
-`node --import tsx scripts/qualify-host.mjs <absolute-path-to-pi-coding-agent-package>`.
+Qualify the installed tarball on the current host without provider traffic or your profile with
+`node scripts/qualify-package.mjs --host <absolute-path-to-pi-coding-agent-package>`.
+The narrower source-SDK contract check is
+`node --import tsx scripts/qualify-host.mjs <absolute-path-to-pi-coding-agent-package>`; both reject historical host versions.
 The [CI workflow](https://github.com/AeonDave/pi-persona/actions/workflows/test.yml) runs strict
 typechecking, dependency auditing and the test suite on Linux and Windows. The OpenSSF badge links to the project's
 scored supply-chain checks; it is not a certification that the code is free of vulnerabilities.

package/docs/ARCHITECTURE.md

@@ -81,9 +81,10 @@ These are the guardrails a contributor must not violate. They are enforced in co
   by the SDK on every `agent()` call and by the engine per child. Concurrency is shared across all
   calls in one SDK instance; token admission uses completed usage and is rechecked after queueing, so
   active legs can overshoot it. Nesting depth is not one of these numeric knobs — it is structural,
-  capped at 1: a child's whole pi-persona extension activation short-circuits under
-  `PI_PERSONA_DISABLE=1` (the **fork-bomb guard**), so it registers NO tools at all —
-  `delegate`/`council`/`orchestrate`/`flow` included. On the child engine this is a one-shot env var
+  capped at 1: full pi-persona activation short-circuits under `PI_PERSONA_DISABLE=1` (the
+  **fork-bomb guard**), so no supervisor orchestration tools (`delegate`/`council`/`flow`) are
+  registered. A broker-enabled child instead loads the minimal bridge, which registers only
+  granted communication and scoped result-reader tools. On the child engine this is a one-shot env var
   set on each spawned process; the in-process engine instead shares one Node process across
   concurrently-building sub-sessions, so it ref-counts the guard (`inproc.ts`) to keep it set until the
   LAST one finishes. The in-process engine also excludes `ORCHESTRATION_TOOLS` from the child session
@@ -151,6 +152,12 @@ These are the guardrails a contributor must not violate. They are enforced in co
 
 ## Module layout
 
+The supported host is the latest stable Pi (currently 1.4.0). Runtime code uses its public APIs
+directly; obsolete host facades, ignored SDK options and compatibility-only aliases are removed
+with their callers. Genuine host failures remain explicit rather than fabricating session identity
+or model availability. One-way user-data migrations and retained-history readers are separate data
+contracts: they remain only while serving stored user data, not to support an older Pi runtime.
+
 Domain dependencies remain downward-only and acyclic: `core ← all`; `engine`/`bus → core`;
 `orchestration → engine + bus + core`; `persona → orchestration + core`; the Exocom transport and
 ledger → `core + bus`; `tools`/`ui → lower layers`. `src/exocom/install.ts` is deliberately the
@@ -282,9 +289,12 @@ up to 16 names. Same idea, two layers, two caps — see docs/REFERENCE.md's exam
 `isolation: worktree` is fail-closed. It requires a clean Git checkout so the detached `HEAD` view
 cannot silently omit staged/unstaged/untracked supervisor work; a non-repository, dirty checkout,
 worktree creation failure, missing diff artifact, or an artifact over the return limit fails the leg —
-the base engine is never invoked against the real tree as a fallback. The diff returns to the
-supervisor before the temporary tree is removed, and every git call is asynchronous so the extension
-host keeps rendering, ticking timers, and serving broker sockets while a large checkout runs.
+the base engine is never invoked against the real tree as a fallback. The created worktree's initial
+commit is pinned before the worker starts. Export compares the final file state against that immutable
+commit, so worker commits, later unstaged changes and new files are included together. The diff is
+captured before the temporary tree is removed and then returned to the supervisor; commit history is
+not applied to the main checkout. Every git call is asynchronous so the extension host keeps rendering,
+ticking timers, and serving broker sockets while a large checkout runs.
 
 Transient retries inside one agent session belong to the host **Pi runtime**'s `retry.*` settings, not
 a persona contract — pi-persona neither parses retry notation nor schedules its own backoff. Both
@@ -501,12 +511,17 @@ events and cannot route, reply, steer, or otherwise control agents.
 ## The comm plane in practice
 
 - **In-process bus** (`bus/inproc.ts`) — a handle-based mailbox: `send` (one-way), `ask` (blocks for a
-  reply), `reply`, `onMessage`. `contact_supervisor` (child→supervisor, gated by `coaching: on`) and
+  reply), `reply`, `onMessage`. `contact_supervisor` (child→supervisor, gated by `canUseBus` and,
+  for in-process children, `coaching: on`) and
   `contact_peer` (sibling→sibling) are the child-side tools bound onto it. Each unread inbox holds at
   most 200 messages; overflow evicts an old one-way note first, and an inbox full of live asks rejects
   new delivery rather than stranding a sender. Ask settlement (reply, timeout, abort, departure, or
   failed delivery) releases its timer/listener and unread entry; a previously retained question stays
   readable with `expectsReply: false`, so old questions never advertise an active reply id.
+  Tool outcomes distinguish `answered` from unavailable, timed-out, cancelled and failed requests;
+  delivery evidence is never approval. Headless questions remain nonblocking and unresolved, allowing
+  only independent already-authorized work or a blocked/partial handoff. Pre-aborted calls perform no
+  bus action, and replies racing cancellation are not reported as answers.
 - **Sibling peer comm** — a strategy opts a run in via `AgentRunSpec.peers` (gated by `canUseBus`). The
   child gets `contact_peer` (`list`/`send`, ONE-WAY so peers can never deadlock; per-engine-instance
   scoping; a 20-send budget and an 8,000-character body limit, enforced before consuming a send). The
@@ -529,6 +544,10 @@ events and cannot route, reply, steer, or otherwise control agents.
   spawn without a bus endpoint, so they never burn connect backoff against a dead socket), and the next
   build retries; `/doctor` surfaces its state on one line. A dropped client connection flips the
   child-side bridge to `⇄ offline` and fails a fresh ask fast rather than hanging.
+  A connected child exposes `contact_supervisor` when `canUseBus` is allowed; `contact_peer` also
+  requires the run's peer opt-in. Granted custom tool names join a nonempty plain allowlist so Pi's
+  host filter does not hide them. Explicit `tools: []` and exclusions remain restrictive. A denied
+  semantic bus does not remove supervisor runtime steering or an independently scoped result reader.
 
 ### Presentation is a projection, not another comm plane
 
@@ -627,6 +646,21 @@ for the supervisor and for explicit retrieval; the default TUI projection is del
   unreadable versions. Session-file deletion owns log deletion; ordinary shutdown saves diagnostics,
   not deletes them. Operator-only expandable log entries do not create model context or extra wakes.
 
+**Terminal result archive** (`src/results/`, `src/extension/results.ts`) applies the same
+ownership model to settled agent work: every terminal delegate/council/flow outcome (and each final
+SDK leg result, after any model recovery) is projected — once, idempotently by immutable origin —
+into a versioned session entry with an opaque `result:<UUID>` reference, independent from runtime
+run ids. Budgets: 128 entries, 8 MiB cumulative serialized payload per owning session file, 512 KiB
+per record; bodies cap at 262,144 UTF-16 units with honest truncation metadata. Unknown, malformed
+and duplicate history still consumes quota; unaccountable history disables new persistence instead
+of resetting it. A fork/copy is a new owning file charged only for the entries it actually carries.
+`storage: "session-entry"` means the host accepted the entry — never an fsync guarantee; memory-only
+retention is labelled as such. Retrieval is read-only: `intercom results` lists, `intercom result
+{ ref, offset, limit }` pages (8,000 default / 16,000 max units, surrogate-safe), with no respawn,
+rebilling, collection or extra wake; reading a page never returns the whole run hidden in metadata.
+A saved result is not a live worker: the restore notice says runtime handles are gone while retained
+reports remain readable.
+
 This is a UI invariant only: truncating a collapsed card must never be confused with truncating the
 underlying result or changing a strategy's contract.
 
@@ -640,17 +674,22 @@ and message peer-to-peer, with no parent/child relationship. (intercom = interna
 external comm.)
 
 Exocom supplies fenced one-way postcards and presence; chat `message` never mutates shared work
-state. Separately, a workspace work ledger (`ledger.ts`, tools in `tools/exocom-work.ts`) records
-claims/asks/answers/progress/releases. `exocom_ask` canonicalizes its target through
-`plane.resolvePeer` (raw session ids on the ledger, never the display name); registry display name is
-keyed by `from_session`, never the envelope's self-reported `from_name`. A pending ask constrains the
-turn (`gate.ts`: answer/decline plus read-only tools) behind a bounded `pendingAskPrompt`.
-`exocom_wait` is non-blocking. Clean shutdown releases this session's claims/asks; if that best-effort
-write fails, the vanished owner is pruned on the next ledger transaction (live registry sessions are
-the lease), and `expireWaiters` wakes any waiter left behind instead of leaving `exocom_wait` armed
-forever. This gate is cooperative coordination for participating local Pi processes — not filesystem
-authorization, not isolation from another same-user process, and not a delegate/council or task/run
-replacement.
+state. `src/exocom/ledger.ts` stores claims, questions, answers and progress; `src/exocom/collaboration.ts`
+adds voluntary tasks, optional offers and explicit evidence excerpts. Tool adapters live in
+`src/tools/exocom.ts`, `src/tools/exocom-collaboration.ts`, and `src/tools/exocom-profile.ts`.
+`exocom_ask` resolves its target through the live registry to a raw session id, never a display name.
+Attribution is resolved by `from_session`, never the envelope's self-reported `from_name`.
+
+A pending ask gates the participant to `exocom_answer`/`exocom_decline`, `exocom_name` identity
+metadata, `exocom_status`, explicit collaboration reads (`exocom_task` list/get, `exocom_publish`
+read, `exocom_profile` get), and read-only filesystem tools. Profile `set`/`clear` and all other
+mutations remain unavailable until the ask is settled. Naming does not settle an ask. The bounded
+`pendingAskPrompt` explains the outstanding obligation. `exocom_wait` is non-blocking. Clean shutdown
+releases this session's claims/asks; if that best-effort write fails, the vanished owner is pruned on
+the next ledger transaction (live registry sessions are the lease), and `expireWaiters` wakes any
+waiter left behind instead of leaving `exocom_wait` armed forever. This gate is cooperative
+coordination for participating local Pi processes — not filesystem authorization, not isolation from
+another same-user process, and not a delegate/council or task/run replacement.
 
 - **Opt-in, OFF by default.** `PI_PERSONA_EXOCOM=1` or bare `--exocom` joins the current workspace;
   `--exocom=Ab0T` joins an existing scope by its exact, case-sensitive four-character Base62 alias
@@ -677,18 +716,31 @@ replacement.
   standing brief, and `/exocom` label a peer as same-workspace or external without exposing its
   absolute `cwd`. External peers are full Pi instances that can inspect files in their own workspace;
   paths are never implicitly shared.
-- **Postcards plus a durable, non-blocking join.** `exocom_send` returns a `msg_id` immediately; a
-  reply is another `exocom_send` with `in_reply_to` set. `target: "*"` broadcasts postcards
-  best-effort (one unreachable peer doesn't fail the rest). Work coordination is separate:
-  `exocom_ask` commits an obligation to the ledger, `answer`/`decline` settles it, and `exocom_wait`
-  arms a bounded idle wake rather than blocking. The signed frame is a wake signal; the ledger remains
-  the source of truth if delivery is deferred.
+- **Postcards, asks and offers have different obligations.** `exocom_send` returns a `msg_id`
+  immediately; a reply is another `exocom_send` with `in_reply_to` set. `target: "*"` broadcasts
+  postcards best-effort. `exocom_ask` commits a targeted question that must be answered or declined;
+  `exocom_wait` arms a bounded idle wake rather than blocking. `exocom_offer` is an optional,
+  expiring invitation to consider an open task, targeted to one peer or the pool; it creates no ask,
+  no answer obligation and no work authorization. Its default lifetime is one hour, capped at 24 hours.
+  Signed immediate-wake frames are signals; the ledger remains authoritative when delivery is deferred.
+- **Task generations and atomic pickup.** `exocom_task create` records a voluntary objective and
+  declared write set; creation neither launches work nor claims paths. The task's immutable
+  `task_id` is its creation frame's `msg_id`; later take/progress/finish, offer and publish actions
+  carry both `work_key` and `task_id`, so reusing a key cannot attach a delayed action to a newer
+  task. A write-set task's pickup and overlapping write claim commit together under the ledger lock;
+  competing overlapping pickups are rejected. Read-only tasks can be taken by a peer in another
+  workspace scope. A task whose owning registry lease disappears becomes stale and cannot be taken
+  over automatically. `exocom_task list` is paginated; `get` returns the complete bounded task detail,
+  including the exact write set. `exocom_publish` attaches an explicitly authored bounded excerpt to
+  one task generation; discovery pages titles and message ids, and the full excerpt is read by id.
+  These excerpts do not grant access to a peer's terminal-result archive.
 - **Cross-workspace writes are advisory-only in v1.** A repository-relative claim path has meaning
   only in the workspace that owns the selected scope, so a member whose home workspace differs from
-  the scope cannot `exocom_claim` (the tool and the signed-frame receiver both reject a foreign
-  claim) — it can still send, inspect its own files, ask, answer/decline, wait, and release its own
-  asks. Multi-repository write coordination would need a versioned resource namespace; paths from
-  unrelated repositories are never compared as if they named the same files.
+  the scope cannot `exocom_claim` or create/pick up a write-set task (the tool and signed-frame
+  transaction both enforce the scope). It can still read shared tasks/evidence, take read-only tasks,
+  send postcards, ask, answer/decline, and release its own asks. Multi-repository write coordination
+  would need a versioned resource namespace; paths from unrelated repositories are never compared as
+  if they named the same files.
 - **Reply routing is session-stable.** `exocom_list` shows human display names (`name`/`name#2`);
   sends and inbound reply hints use `name@<96-bit session hash>`, so a retained qualified target
   stays valid after a rename. Ambiguous suffix matches fail closed rather than guess. The
@@ -727,15 +779,23 @@ replacement.
   double-trigger a turn. An exchange's LENGTH is instead bounded prompt-side: the per-turn peer brief
   (`core/brief.ts`) carries a relevance bound — send only what changes what someone does — deliberately
   not a round count, since a counter can't see whether a round still serves the work.
-- **Tools are lazy and fail closed.** `exocom_list({ offset?, limit? })` exposes bounded, paginated
-  presence; `exocom_send({ target, message, in_reply_to? })` sends one-way (a session-qualified-looking
-  target resolves only as one, never falling back to a display name, since names are self-chosen);
-  `exocom_name({ name })` rebrands the display call-sign without moving any state. The ledger tools —
-  `exocom_claim`, `exocom_ask`, `exocom_answer`, `exocom_decline`, `exocom_wait`, `exocom_progress`,
-  `exocom_release` — are capability-gated with the postcard tools; the live accessor, capability gate,
-  and active-tool set all deny them once the plane stops, since Pi has no dynamic tool-unregister API.
-  Admission requires at least one obligation closer, because every published peer may receive a
-  durable ask and must retain a way to settle it.
+- **Fifteen tools are lazy and fail closed.** `EXOCOM_TOOL_NAMES` lists `exocom_list`, `exocom_send`,
+  `exocom_name`, `exocom_claim`, `exocom_ask`, `exocom_answer`, `exocom_decline`, `exocom_wait`,
+  `exocom_release`, `exocom_progress`, `exocom_status`, `exocom_task`, `exocom_offer`,
+  `exocom_publish`, and `exocom_profile`. Each tool rechecks effective persona capabilities at call
+  time; the live accessor and active-tool set also deny calls once the plane stops, since Pi has no
+  dynamic tool-unregister API. A joined foreign-scope peer has no `exocom_claim`. Admission requires
+  `canUseBus` and at least one callable ask closer, because every published peer may receive a durable
+  ask and must retain a way to settle it.
+- **Collaboration and profile retention are bounded.** The ledger retains at most 64 tasks, 64 offers,
+  and 64 evidence excerpts with a 128 KiB aggregate collaboration-state budget. Task descriptions cap
+  at 2,048 characters; write sets at 64 paths of 256 characters each; progress/finish notes at 4,096.
+  Evidence titles cap at 160 characters and excerpts at 4,096 characters / 8,192 UTF-8 bytes. Finished
+  or stale tasks remain for up to one hour; expired offers remain for up to one hour after expiry, and
+  evidence for up to one hour after publication. Active tasks remain while their owner lease is live.
+  `exocom_profile` contains up to eight self-described capability labels (48 characters each) and
+  optional `available`, `busy` or `away` status. Missing status is unknown. Profiles exist only for
+  their live Exocom session and never prove skills, permission or availability.
 - **Inbound delivery is bounded without loss.** Each message is injected under the same byte cap
   whether plain text or an artifact descriptor. Bursts stay FIFO-queued; each rate-limited wake drains
   as many whole messages as fit, leaving the rest queued. A presentation cap on the collapsed card