agents-can-communicate 0.2.0 → 0.3.0

package/docs/HOW_IT_WORKS.md

@@ -0,0 +1,277 @@
+# How ACC works
+
+ACC is a local communication layer around AI sessions that the user opened independently.
+It gives those sessions a shared set of coordination facts without giving ACC ownership of
+their prompts, permissions, processes, or work.
+
+This page follows one interaction from client startup to an acknowledged answer. It is the
+engineering tour; [Protocol](PROTOCOL.md) is the normative record contract and
+[Architecture](ARCHITECTURE.md) is the package-level reference.
+
+## The whole system in one picture
+
+```mermaid
+flowchart LR
+  U["human direction and authority"] --> A["independent session A"]
+  U --> B["independent session B"]
+  A --> X["CLI, MCP, or adapter hook"]
+  X --> C["vendor-neutral core"]
+  C <--> S[("filesystem store outside the repository")]
+  C --> Y["B adapter hook or acc inbox"]
+  Y --> B
+  C --> R["optional live-delivery router"]
+  R -.-> B
+  B --> Z["CLI, MCP, or adapter hook"]
+  Z --> C
+```
+
+There is no required ACC daemon and no coordinator model. CLI commands and native hooks
+are short-lived local processes that open the same workspace store when needed. An MCP
+client may keep its own `acc-mcp` stdio child running, but that child is a tool boundary for
+one participant, not a scheduler or owner of the room.
+
+## 1. A client session joins a workspace
+
+For a native client, an installed startup hook sends the client event to `acc-hook`. The
+vendor adapter normalizes that event, then the hook runner:
+
+1. discovers the workspace;
+2. opens its filesystem store;
+3. resolves the exact client version and its certified capabilities;
+4. opens or resumes one ACC session generation; and
+5. stores a small binding from the client's session id to that ACC generation.
+
+Workspace discovery uses an explicit `acc.workspace.json` first, the Git common directory
+second, and the canonical plain directory otherwise. Git worktrees therefore share one
+room but keep separate checkout and branch facts. Git itself is optional.
+
+A participant is the address messages target. A session is one current opening of that
+participant, and its unguessable generation token prevents an old process from mutating a
+replacement session. The default participant name is derived from the client session. Set
+`ACC_PARTICIPANT` in the client launch environment when an address must survive a client
+restart and recover messages sent while it was away.
+
+Attaching one session does not create durable workspace history. Its presence and intent
+can remain ephemeral until a second live session appears or someone creates the first
+claim, message, or handoff. This is how ACC stays silent when a session is alone without
+making discovery unreliable when a peer arrives.
+
+## 2. Sessions publish awareness, not assignments
+
+An intent records a short summary, mode, and resource hints. A claim adds a leased
+reservation for a canonical resource such as `file:src/item.mjs` or `file:src/**`.
+Neither creates a task or grants one session authority over another.
+
+A claim is `guarded` only when every live client path involved has a captured pre-write
+guard. Otherwise it is `advisory`: visible coordination that peers should respect, but not
+an operating-system lock. Even a guarded claim cannot stop unrelated programs or a write
+path the client never exposes to its adapter.
+
+## 3. Sending commits the durable truth first
+
+When session A sends an addressed question, the CLI or MCP boundary validates the closed
+protocol shape and resolves A's current session generation. Core then performs one
+filesystem transaction that creates:
+
+- the immutable logical message, including sender, recipients, kind, obligation, thread,
+  and explicit body;
+- one `queued` receipt for each recipient; and
+- a `message.recorded` event.
+
+The first message in a thread uses its own `messageId` as `threadId`. A caller-supplied
+`clientMessageId` is a retry key: identical retries return the original message, while the
+same key with different content is rejected.
+
+For a room message, recipients are the known peer participants with open sessions at
+commit time. Participants arriving later can find the room record through full forensic
+sync, but they do not receive retroactive receipts.
+
+Only after the transaction commits may ACC try to make the message arrive sooner. Thus a
+crashed, unsupported, or unreachable adapter cannot erase a successfully recorded
+question.
+
+## 4. Delivery has three paths
+
+The paths share one durable record but prove different facts.
+
+### Durable inbox
+
+`acc inbox` is the universal recovery path. It returns only messages addressed to the
+calling participant and atomically advances that participant's receipt to `retrieved`.
+An exact `acc inbox --message message_x` remains usable after context compaction or when a
+message was too large to project safely.
+
+### Certified next-turn projection
+
+On an exact client version and platform with passing evidence, a before-turn hook asks core
+for queued messages just before the client's next normal turn. The adapter projects each
+complete body inside an attributed `untrusted peer message` frame. If the complete frame
+does not fit the configured byte budget, the hook keeps the message id and the exact inbox
+recovery command instead of silently truncating peer text.
+
+The hook entry point records `offered` only after its stdout transport reports that the
+bytes crossed the boundary. The state is not `retrieved`: ACC still has no observation
+that the model attended to those bytes.
+
+### Native live push
+
+The delivery router offers an actionable message to an already-running session when all of
+these hold at once:
+
+- exactly one live generation for the recipient;
+- an unexpired generation-bound delivery binding published by that session's own start;
+- a recorded policy permitting this message kind (`actionable` covers question, request,
+  answer, decision, and handoff; `all` adds note; room messages are never live);
+- an adapter that declares `delivery.livePush` and a native contract; and
+- adapter acceptance of the bytes.
+
+Any missing condition leaves the receipt `queued` and returns a safe fallback reason. Two
+adapters ship a native transport, both experimental and off until a per-client opt-in:
+
+```text
+sender -> durable ACC record -> exact live binding -> vendor transport -> receiver
+                             \-> queued inbox on every failure
+```
+
+- **Claude Code 2.1.258** uses a vendor Channel: an ACC-owned MCP child, started only when
+  the user's ordinary `claude` launch carries the captured development-channel flag, offers
+  the message as a native notification and routes the model's explicit `acc_reply` back as a
+  real ACC answer. Claude's development-channel warning is vendor-owned and stays visible.
+- **Codex 0.152.1** adds the message to the App Server thread queue over the vendor daemon's
+  control socket; it is presented on the idle thread or after the current turn. Codex answers
+  through the ordinary `acc reply` command, so its reply route is not native.
+
+Compatibility is decided at the launch-time bootstrap and again by a per-session handshake
+bound to the exact client process; there is no maximum client version, but a newer stable
+release must pass a current probe and handshake for the captured protocol, and an older,
+prerelease, known-bad, or uncaptured client stays durable-only. ACC is never the parent of
+a model session after the shell `exec`, and `ACC_BYPASS=1` starts the unmodified client.
+
+## 5. Reply closes the communication obligation
+
+The complete question-and-answer path is:
+
+```mermaid
+sequenceDiagram
+  participant A as Session A
+  participant Core
+  participant Store
+  participant B as Session B
+  A->>Core: addressed question for B
+  Core->>Store: message + queued receipt + event
+  Store-->>Core: transaction committed
+  Core-->>A: recorded with delivery outcome
+  alt certified next-turn
+    B->>Core: normal turn hook
+    Core-->>B: attributed untrusted envelope
+    Core->>Store: receipt offered after transport accepts bytes
+  else durable inbox
+    B->>Core: acc inbox for the message
+    Core->>Store: advance B receipt to retrieved
+    Core-->>B: attributed message and receipt
+  end
+  B->>Core: reply to the question id
+  Core->>Store: answer + A receipt + acknowledge B receipt
+  Core-->>A: answer through next-turn or inbox
+```
+
+`reply` verifies that B owns the original receipt, writes an `answer` in the same thread,
+creates the answer's receipt for A, and advances B's original receipt to `acknowledged` in
+one transaction. A transport failure after that cannot undo the reply. `ack` performs the
+last transition without creating an answer when the obligation only asks for
+acknowledgement.
+
+Receipts are per recipient and monotonic:
+
+```text
+queued -> offered -> retrieved -> acknowledged
+```
+
+`recorded` is the successful send boundary, not a receipt state. `offered` does not mean
+read, `retrieved` does not prove model attention, and `acknowledged` resolves communication
+only. A reply saying “I will do it” is not evidence that the requested work finished; ACC
+does not have accepted, running, or done task states.
+
+## 6. The filesystem is the control plane
+
+Each workspace lives below the platform data home, conceptually:
+
+```text
+<platform data home>/acc/workspaces/workspace_x/
+├── protocol.json          store version and workspace identity
+├── state/<kind>/<id>.json materialised current records
+├── events/<sequence>.json immutable semantic history
+├── journal/               crash-recovery authority
+├── locks/                 one cross-process writer mutex
+├── ephemeral/             non-durable presence, intent, and delivery bindings
+├── bindings/              client-session to ACC-generation mappings
+├── retained/              logical deletion and retired evidence
+└── tmp/                   staged atomic publications
+```
+
+This layout is diagnostic, not a public mutation API. Clients write through the protocol
+and core rather than editing these files.
+
+On macOS the platform data home is `~/Library/Application Support`; on Linux it is
+`$XDG_DATA_HOME` or `~/.local/share`. `ACC_DATA_HOME` replaces that base. Runtime paths are
+checked against workspace roots so ACC state cannot be placed inside the project.
+
+Every durable mutation holds the same writer mutex, loads only its declared record kinds,
+checks state generations, stages the full result, and writes a recovery journal before
+publishing. Events are immutable no-replace files; current state is a materialised view
+replaced atomically. While publication is incomplete, the active journal bounds event
+cursors below the transaction's first sequence; the next store opener rolls a decided
+transaction forward before serving a read. The store prefers a recoverable duplicate offer
+after a crash to an unearned delivery claim.
+
+Paths are opened with containment and no-follow checks. Corrupt records, a foreign
+workspace identity, and unknown store versions fail before mutation rather than being
+guessed into a compatible shape.
+
+## 7. Adapters translate evidence, not product semantics
+
+The vendor-neutral layers know nothing about Codex, Claude Code, Gemini CLI, Grok, or Kimi
+Code. `protocol` owns record shapes and state transitions; `core` owns coordination rules;
+`storage-filesystem` owns persistence. Vendor adapters own hook payloads, installation,
+client-specific response shapes, and captured capability evidence. `hook-runner` applies
+the common bounded fail-open lifecycle, while `delivery-router` evaluates optional live
+delivery.
+
+Unknown client versions and platforms inherit no capability. A method in an adapter or a
+vendor documentation example is not enough: every `true` capability needs a retained
+real-client fixture. This is why the same product can degrade visibly from next-turn
+projection to inbox polling without changing its message or receipt semantics.
+
+## 8. What crosses the trust boundary
+
+ACC stores only explicit coordination data: identity, presence, one-line intent, claims,
+messages the sender chose to send, structured handoffs, receipts, artifacts, and events.
+It does not collect raw prompts, assistant responses, transcripts, environment variables,
+credentials, or permission approvals.
+
+Peer bodies remain untrusted data. The projector attributes the sender, escapes framing
+and terminal control sequences, and never promotes peer text to system authority. The
+receiving session still evaluates it under its own instructions and permissions.
+
+Every native hook has a five-second ceiling and fails open: if ACC cannot read the store or
+decide safely, the client's action continues. Coordination may become less effective, but
+ACC itself must not stop a session from working.
+
+## Trace the implementation
+
+The shortest source-code path is:
+
+1. `packages/hook-runner/src/runner.mjs` — attach, before-turn projection, guards, and the
+   fail-open boundary;
+2. `packages/core/src/conversations.mjs` — record-first messages, threads, receipts, and
+   handoffs;
+3. `packages/core/src/inbox.mjs` — recipient-owned retrieval, reply, and acknowledgement;
+4. `packages/delivery-router/src/router.mjs` — policy, reachability, certification, and live
+   fallback;
+5. `packages/storage-filesystem/src/store.mjs` — transactions, snapshots, ephemeral state,
+   and recovery; and
+6. `packages/adapter-sdk/src/context-projector.mjs` — bounded untrusted peer framing.
+
+Continue with [Capabilities](CAPABILITIES.md) for what each shipped client actually proves,
+[Security model](SECURITY_MODEL.md) for trust boundaries and attack tests, and
+[Adapter authoring](ADAPTER_AUTHORING.md) for the integration contract.

package/docs/PROTOCOL.md

@@ -182,7 +182,7 @@ livePolicy · opaqueEndpointRef · leaseUntil
 The recipient owns `livePolicy` because native push may start a model turn:
 
 - `off`: inbox and normal next-turn paths only;
-- `actionable`: questions, requests, and addressed handoffs may use live push;
+- `actionable`: questions, requests, answers, decisions, and addressed handoffs may use live push;
 - `all`: every addressed kind may use live push.
 
 Default is `off`. Policy never creates a capability. The router still requires a current

package/docs/RELEASING.md

@@ -47,7 +47,7 @@ else installs it.
 ## Record the evidence
 
 Put the tarball name, sha256, **the commit it was built from**, exact platform/client
-facts, fallback result, and known limitations in `docs/release-evidence/v0.2.0.md` and
+facts, fallback result, and known limitations in `docs/release-evidence/v0.3.0.md` and
 the current `CHANGELOG.md` release table. A release without them is a release nobody can
 audit later. Test count is deliberately left out: nothing verifies it, so it only
 decorates or, when it drifts, misleads.
@@ -81,6 +81,12 @@ absent and Claude stopped at the development-channel warning. Record those exact
 captures and run the packed inbox/next-turn fallback instead of promoting an unobserved
 native path. Windows is an explicit unsupported-platform skip, not a passing capture.
 
+By v0.3.0 that had gone both ways, which is the point of doing it per release rather than
+once. Claude Code passed and ships a live Channel; Codex's queue capture passed and the
+capability was **withdrawn anyway**, because the mode it needs hides which workspace the
+session belongs to, and a session that cannot be placed must not be addressed. A capture
+that works is not the same claim as a capability that is safe to ship.
+
 A published version's record is history and is not rewritten; later changes
 get a new `## Unreleased` entry at the top, checked the same way against the
 current tree.

package/docs/TROUBLESHOOTING.md

@@ -53,9 +53,15 @@ do not run. `acc doctor` reports the installed cache copy and missing activation
 ## Gemini does not guard a write
 
 Default and `plan` modes expose no write tool to the model. `auto_edit` exposes edit tools;
-shell availability depends on approval mode. Only Gemini CLI 0.37.0 on `darwin-arm64` has
+shell availability depends on approval mode. Only Gemini CLI 0.57.0 on `darwin-arm64` has
 package-shipped delivery certification; other versions still use inbox.
 
+From 0.55 onwards there is a quieter cause with the same symptom: an untrusted folder. The
+client prints `Approval mode overridden to "default" because the current folder is not
+trusted` and keeps going, and the default mode has no write or shell tool to guard - so the
+guard never fires and the mode you passed appears to have been ignored. Trust the folder,
+or start the session somewhere trusted.
+
 ## Grok shows no injected message
 
 Grok 1.0.13 discarded UserPromptSubmit context in the real capture. Its next-turn and guard

package/docs/index.md

@@ -8,7 +8,9 @@ separates protocol truth from adapter reach.
 
 1. [Why ACC](WHY_ACC.md) — the product boundary and when a managed runtime fits better.
 2. [Concepts](CONCEPTS.md) — peers, durable threads, receipts, intent, and claims.
-3. [Capabilities](CAPABILITIES.md) — certified support, current reachability, recipient
+3. [How ACC works](HOW_IT_WORKS.md) — the end-to-end path from client hook and workspace
+   identity through durable storage, delivery fallback, reply, and acknowledgement.
+4. [Capabilities](CAPABILITIES.md) — certified support, current reachability, recipient
    policy, fallback, and limitations beside each adapter.
 
 ## Use it

package/node_modules/@agents-can-communicate/adapter-claude-code/certification.json

@@ -1,59 +1,119 @@
 {
   "evidence": [
     {
-      "client": "claude-code", "version": "2.1.233", "platform": "darwin-arm64",
-      "observedAt": "2026-08-16", "capability": "lifecycle.sessionStart",
-      "fixture": "fixtures/SessionStart.json", "idleBehavior": "fires when a session starts",
-      "provenance": "fixtures/certification-provenance.json", "provenanceId": "session-start",
-      "busyBehavior": "fires before the first model turn", "authorityLevel": "advisory",
-      "limitations": ["capture used a one-session --plugin-dir"], "result": "pass"
+      "client": "claude-code",
+      "version": "2.1.233",
+      "platform": "darwin-arm64",
+      "observedAt": "2026-08-16",
+      "capability": "lifecycle.sessionStart",
+      "fixture": "fixtures/SessionStart.json",
+      "idleBehavior": "fires when a session starts",
+      "provenance": "fixtures/certification-provenance.json",
+      "provenanceId": "session-start",
+      "busyBehavior": "fires before the first model turn",
+      "authorityLevel": "advisory",
+      "limitations": [
+        "capture used a one-session --plugin-dir"
+      ],
+      "result": "pass"
     },
     {
-      "client": "claude-code", "version": "2.1.233", "platform": "darwin-arm64",
-      "observedAt": "2026-08-16", "capability": "lifecycle.sessionEnd",
-      "fixture": "fixtures/SessionEnd.json", "idleBehavior": "fires when a session exits",
-      "provenance": "fixtures/certification-provenance.json", "provenanceId": "session-end",
-      "busyBehavior": "does not run until the session exits", "authorityLevel": "advisory",
-      "limitations": ["cannot write a handoff after the model has stopped"], "result": "pass"
+      "client": "claude-code",
+      "version": "2.1.233",
+      "platform": "darwin-arm64",
+      "observedAt": "2026-08-16",
+      "capability": "lifecycle.sessionEnd",
+      "fixture": "fixtures/SessionEnd.json",
+      "idleBehavior": "fires when a session exits",
+      "provenance": "fixtures/certification-provenance.json",
+      "provenanceId": "session-end",
+      "busyBehavior": "does not run until the session exits",
+      "authorityLevel": "advisory",
+      "limitations": [
+        "cannot write a handoff after the model has stopped"
+      ],
+      "result": "pass"
     },
     {
-      "client": "claude-code", "version": "2.1.233", "platform": "darwin-arm64",
-      "observedAt": "2026-08-16", "capability": "context.beforeTurnInjection",
-      "fixture": "fixtures/UserPromptSubmit.json", "idleBehavior": "waits for the next user prompt",
-      "provenance": "fixtures/certification-provenance.json", "provenanceId": "user-prompt-submit",
-      "busyBehavior": "does not interrupt an in-progress turn", "authorityLevel": "context",
-      "limitations": ["requires the hookSpecificOutput additionalContext envelope"], "result": "pass"
+      "client": "claude-code",
+      "version": "2.1.233",
+      "platform": "darwin-arm64",
+      "observedAt": "2026-08-16",
+      "capability": "context.beforeTurnInjection",
+      "fixture": "fixtures/UserPromptSubmit.json",
+      "idleBehavior": "waits for the next user prompt",
+      "provenance": "fixtures/certification-provenance.json",
+      "provenanceId": "user-prompt-submit",
+      "busyBehavior": "does not interrupt an in-progress turn",
+      "authorityLevel": "context",
+      "limitations": [
+        "requires the hookSpecificOutput additionalContext envelope"
+      ],
+      "result": "pass"
     },
     {
-      "client": "claude-code", "version": "2.1.233", "platform": "darwin-arm64",
-      "observedAt": "2026-08-16", "capability": "guards.beforeWrite",
-      "fixture": "fixtures/PreToolUse-Edit.json", "idleBehavior": "no write exists to guard",
-      "provenance": "fixtures/certification-provenance.json", "provenanceId": "pre-tool-use-edit",
-      "busyBehavior": "denies a file edit before disk mutation", "authorityLevel": "blocking",
-      "limitations": ["runtime writes are outside the hook boundary"], "result": "pass"
+      "client": "claude-code",
+      "version": "2.1.233",
+      "platform": "darwin-arm64",
+      "observedAt": "2026-08-16",
+      "capability": "guards.beforeWrite",
+      "fixture": "fixtures/PreToolUse-Edit.json",
+      "idleBehavior": "no write exists to guard",
+      "provenance": "fixtures/certification-provenance.json",
+      "provenanceId": "pre-tool-use-edit",
+      "busyBehavior": "denies a file edit before disk mutation",
+      "authorityLevel": "blocking",
+      "limitations": [
+        "runtime writes are outside the hook boundary"
+      ],
+      "result": "pass"
     },
     {
-      "client": "claude-code", "version": "2.1.233", "platform": "darwin-arm64",
-      "observedAt": "2026-08-16", "capability": "guards.beforeShell",
-      "fixture": "fixtures/PreToolUse.json", "idleBehavior": "no shell call exists to guard",
-      "provenance": "fixtures/certification-provenance.json", "provenanceId": "pre-tool-use-bash",
-      "busyBehavior": "denies a Bash call before execution", "authorityLevel": "blocking",
-      "limitations": ["only tool calls reaching PreToolUse are guarded"], "result": "pass"
+      "client": "claude-code",
+      "version": "2.1.233",
+      "platform": "darwin-arm64",
+      "observedAt": "2026-08-16",
+      "capability": "guards.beforeShell",
+      "fixture": "fixtures/PreToolUse.json",
+      "idleBehavior": "no shell call exists to guard",
+      "provenance": "fixtures/certification-provenance.json",
+      "provenanceId": "pre-tool-use-bash",
+      "busyBehavior": "denies a Bash call before execution",
+      "authorityLevel": "blocking",
+      "limitations": [
+        "only tool calls reaching PreToolUse are guarded"
+      ],
+      "result": "pass"
     },
     {
-      "client": "claude-code", "version": "2.1.233", "platform": "darwin-arm64",
-      "observedAt": "2026-08-16", "capability": "delivery.nextTurn",
-      "fixture": "fixtures/UserPromptSubmit.json", "idleBehavior": "offers complete peer messages at the next prompt",
-      "provenance": "fixtures/certification-provenance.json", "provenanceId": "user-prompt-submit",
-      "busyBehavior": "does not interrupt an in-progress turn", "authorityLevel": "context",
-      "limitations": ["delivery requires the next normal user turn"], "result": "pass"
+      "client": "claude-code",
+      "version": "2.1.233",
+      "platform": "darwin-arm64",
+      "observedAt": "2026-08-16",
+      "capability": "delivery.nextTurn",
+      "fixture": "fixtures/UserPromptSubmit.json",
+      "idleBehavior": "offers complete peer messages at the next prompt",
+      "provenance": "fixtures/certification-provenance.json",
+      "provenanceId": "user-prompt-submit",
+      "busyBehavior": "does not interrupt an in-progress turn",
+      "authorityLevel": "context",
+      "limitations": [
+        "delivery requires the next normal user turn"
+      ],
+      "result": "pass"
     },
     {
-      "client": "claude-code", "version": "2.1.252", "platform": "darwin-arm64",
-      "observedAt": "2026-09-01T16:17:06Z", "capability": "delivery.livePush",
-      "fixture": "fixtures/delivery/claude-code-2.1.252.json", "idleBehavior": "unobserved",
-      "provenance": "fixtures/certification-provenance.json", "provenanceId": "native-delivery-2-1-252",
-      "busyBehavior": "unobserved", "authorityLevel": "none",
+      "client": "claude-code",
+      "version": "2.1.252",
+      "platform": "darwin-arm64",
+      "observedAt": "2026-09-01T16:17:06Z",
+      "capability": "delivery.livePush",
+      "fixture": "fixtures/delivery/claude-code-2.1.252.json",
+      "idleBehavior": "unobserved",
+      "provenance": "fixtures/certification-provenance.json",
+      "provenanceId": "native-delivery-2-1-252",
+      "busyBehavior": "unobserved",
+      "authorityLevel": "none",
       "limitations": [
         "Claude Code displayed the development-channel security warning and the operator did not accept it",
         "Claude Code did not spawn the acc-spike MCP child and the Unix-domain socket was never created",
@@ -62,17 +122,107 @@
       "result": "fail"
     },
     {
-      "client": "claude-code", "version": "2.1.252", "platform": "darwin-arm64",
-      "observedAt": "2026-09-01T16:17:06Z", "capability": "delivery.replyRoute",
-      "fixture": "fixtures/delivery/claude-code-2.1.252.json", "idleBehavior": "unobserved",
-      "provenance": "fixtures/certification-provenance.json", "provenanceId": "native-delivery-2-1-252",
-      "busyBehavior": "unobserved", "authorityLevel": "none",
+      "client": "claude-code",
+      "version": "2.1.252",
+      "platform": "darwin-arm64",
+      "observedAt": "2026-09-01T16:17:06Z",
+      "capability": "delivery.replyRoute",
+      "fixture": "fixtures/delivery/claude-code-2.1.252.json",
+      "idleBehavior": "unobserved",
+      "provenance": "fixtures/certification-provenance.json",
+      "provenanceId": "native-delivery-2-1-252",
+      "busyBehavior": "unobserved",
+      "authorityLevel": "none",
       "limitations": [
         "Claude Code displayed the development-channel security warning and the operator did not accept it",
         "Claude Code did not spawn the acc-spike MCP child and the Unix-domain socket was never created",
         "idle, busy, reply, duplicate, and fallback branches were not observed"
       ],
       "result": "fail"
+    },
+    {
+      "client": "claude-code",
+      "version": "2.1.258",
+      "platform": "darwin-arm64",
+      "observedAt": "2026-09-02T21:20:11.676Z",
+      "capability": "delivery.livePush",
+      "fixture": "fixtures/delivery/claude-code-2.1.258.json",
+      "idleBehavior": "offered",
+      "provenance": "fixtures/certification-provenance.json",
+      "provenanceId": "native-delivery-2-1-258",
+      "busyBehavior": "queued_after_turn",
+      "authorityLevel": "experimental",
+      "limitations": [
+        "captured on darwin-arm64 only; Linux and Windows remain uncaptured",
+        "the vendor development-channel warning stayed visible and was accepted by the operator by hand",
+        "the plugin .mcp.json must live in the marketplace source copy; the plugin cache copy alone is not read",
+        "acc_reply routed through the spike's explicit tool call; the spike created no durable ACC answer record",
+        "presentation after the busy turn was observed by the operator; the channel log records the write at 21:18:45Z and the explicit reply at 21:19:21Z"
+      ],
+      "result": "pass"
+    },
+    {
+      "client": "claude-code",
+      "version": "2.1.258",
+      "platform": "darwin-arm64",
+      "observedAt": "2026-09-02T21:20:11.676Z",
+      "capability": "delivery.replyRoute",
+      "fixture": "fixtures/delivery/claude-code-2.1.258.json",
+      "idleBehavior": "offered",
+      "provenance": "fixtures/certification-provenance.json",
+      "provenanceId": "native-delivery-2-1-258",
+      "busyBehavior": "queued_after_turn",
+      "authorityLevel": "experimental",
+      "limitations": [
+        "captured on darwin-arm64 only; Linux and Windows remain uncaptured",
+        "the vendor development-channel warning stayed visible and was accepted by the operator by hand",
+        "the plugin .mcp.json must live in the marketplace source copy; the plugin cache copy alone is not read",
+        "acc_reply routed through the spike's explicit tool call; the spike created no durable ACC answer record",
+        "presentation after the busy turn was observed by the operator; the channel log records the write at 21:18:45Z and the explicit reply at 21:19:21Z"
+      ],
+      "result": "pass"
+    },
+    {
+      "client": "claude-code",
+      "version": "2.1.260",
+      "platform": "darwin-arm64",
+      "observedAt": "2026-09-04T03:41:29.688Z",
+      "capability": "delivery.livePush",
+      "fixture": "fixtures/delivery/claude-code-2.1.260.json",
+      "idleBehavior": "offered",
+      "provenance": "fixtures/certification-provenance.json",
+      "provenanceId": "native-delivery-2-1-260",
+      "busyBehavior": "queued_after_turn",
+      "authorityLevel": "experimental",
+      "limitations": [
+        "captured on darwin-arm64 only; Linux and Windows remain uncaptured",
+        "the vendor development-channel warning stayed visible and was accepted by the operator by hand",
+        "two ordinary sessions in one workspace, each bound to its own client process; the earlier 2.1.259 attempt is what exposed the channel binding another session identity, and this run is the verification of that fix",
+        "duplicate was observed as one logical message id and one native offer: the repeated send took the durable path, so the channel was never asked to notify twice, and exactly one answer was recorded",
+        "busy was observed by the operator: the running turn completed before the channel presented the message, and the session named that order in its own answer"
+      ],
+      "result": "pass"
+    },
+    {
+      "client": "claude-code",
+      "version": "2.1.260",
+      "platform": "darwin-arm64",
+      "observedAt": "2026-09-04T03:41:29.688Z",
+      "capability": "delivery.replyRoute",
+      "fixture": "fixtures/delivery/claude-code-2.1.260.json",
+      "idleBehavior": "offered",
+      "provenance": "fixtures/certification-provenance.json",
+      "provenanceId": "native-delivery-2-1-260",
+      "busyBehavior": "queued_after_turn",
+      "authorityLevel": "experimental",
+      "limitations": [
+        "captured on darwin-arm64 only; Linux and Windows remain uncaptured",
+        "the vendor development-channel warning stayed visible and was accepted by the operator by hand",
+        "two ordinary sessions in one workspace, each bound to its own client process; the earlier 2.1.259 attempt is what exposed the channel binding another session identity, and this run is the verification of that fix",
+        "duplicate was observed as one logical message id and one native offer: the repeated send took the durable path, so the channel was never asked to notify twice, and exactly one answer was recorded",
+        "busy was observed by the operator: the running turn completed before the channel presented the message, and the session named that order in its own answer"
+      ],
+      "result": "pass"
     }
   ]
 }