@junghanacs/entwurf 0.24.0 → 0.25.1

package/README.md

@@ -254,7 +254,7 @@ cd ~/repos/gh/entwurf
 
 The full source setup requires Node 24, pnpm, and Python 3 on PATH. Harnesses are
 optional-by-presence: `setup` runs the frozen dependency install, then composes what the operator
-already installed — a compatible `pi` (`>=0.86.0 <0.87`), Claude Code, agy, and the Copilot CLI
+already installed — a compatible `pi` (`>=0.87.1 <0.88`), Claude Code, agy, and the Copilot CLI
 each get their wiring completed when detected, an absent harness is an explicit zero-state SKIP,
 and a detected harness that cannot be completed (including a below-floor `pi`) is a named FAIL
 that makes setup exit nonzero. `setup` never installs a harness binary or touches a credential
@@ -288,7 +288,7 @@ This rail is CERTIFIED on Linux; on macOS it is NOT CERTIFIED — pending
 physical host (control sockets, mux, ACP plugin hosting).
 
 To use the `entwurf` provider inside pi, install a compatible pi binary
-separately (`@earendil-works/pi-coding-agent >=0.86.0 <0.87`). Then point pi at
+separately (`@earendil-works/pi-coding-agent >=0.87.1 <0.88`). Then point pi at
 the npm-installed package or development clone:
 
 ```bash

package/VERIFY.md

@@ -86,7 +86,7 @@ that moved out of `scripts/` and into a file beside its subject would otherwise
 ### The canonical floor — two entry points
 
 - **Deterministic floor — two tiers (#70):** `pnpm check` is the everyday CORE — toolchain (lint + typecheck), the vitest lanes, and the pure-unit / behavioral-contract / source-topology gates plus the cheap static coherence checks. It prints its own total wall time; acceptance is ≤60s on the reference host `oracle` (an operator measurement, never a hard wall-clock gate on arbitrary hosts). `pnpm run check:full` is the FULL deterministic floor — the core plus the hermetic-integration and package/install tiers — and is what the frozen-candidate protocol, push CI, release-gate, and `prepublishOnly` run. Exact membership is the named `check:*` group scripts in `package.json` (the executable SSOT — this document records meaning and principles, not the command list); a gate changes tier by semantic-class decision, never by getting faster or slower. The FULL tier carries the qualification HEAD (`check-gate-manifests`, through `check:hermetic`); the everyday core does not, and neither tier carries the separately scheduled mutant-executing body (`check-gate-qualification`).
-- **Discriminating power of that floor:** `./run.sh check-gate-qualification` (scheduled, not ambient: standalone when a lane changes a gate/mutant/matrix, in the CI `check` job on a branch push that touched the qualification surface, and as a release-gate MUST step — no longer inside the default check chains; a semver TAG push triggers no CI at all, and the exact-SHA evidence a release quotes is whichever run at that commit CARRIES the body — the branch run when the push touched the qualification surface, else a dispatch run; a push that touched none of the qualification surface skips the body, and `workflow_dispatch -f qualify=true` plus a weekly `schedule` run it unconditionally — the exact-SHA release oracle refuses a SHA whose body step did not conclude success) re-plants committed defect mutants (`scripts/mutants/*.json`, one per closed defect class) in an isolated snapshot repo and requires each to turn its gate red **bounded and at its claimed `[QK:<claim>]` signature** — a wrong-reason red fails, a baseline-red control voids the whole group, and the runner is negative-controlled on every run (zero-match/multi-match/survived/wrong-reason/hang/control-red/impurity). This measures whether the deterministic gates still *block* what they claim to block; it is **not a new evidence level** (L0–L5 are untouched) and never substitutes for LIVE evidence. Per-cut records cite claim IDs + killed mutant IDs — "N checks passed" alone is not evidence. `check-agy-permission-matrix` complements it with the enumerated permission contract space (literal cells + stated exclusion rules, oracle independent of the SUT). The gate's HEAD is separable and IS in the floor: `check-gate-manifests` runs the runner self-test, validates the committed manifest set against the origin index, and asserts the declared lane inventory, while executing zero mutants and never snapshotting the repo — three of the five reds qualification has ever produced in CI died in that head, in under five seconds.
+- **Discriminating power of that floor:** `./run.sh check-gate-qualification` (scheduled, not ambient: standalone when a lane changes a gate/mutant/matrix, in the CI `check` job on a branch push that touched the qualification surface, and as a release-gate MUST step — no longer inside the default check chains; a semver TAG push triggers no CI at all, and the exact-SHA evidence a release quotes is whichever run at that commit CARRIES the body — the branch run when the push touched the qualification surface, else a dispatch run; a push that touched none of the qualification surface skips the body, and `workflow_dispatch -f qualify=true` plus a weekly `schedule` run it unconditionally — the exact-SHA release oracle refuses a SHA whose body step did not conclude success) re-plants committed defect mutants (`scripts/mutants/*.json`, one per closed defect class) in an isolated snapshot repo and requires each to turn its gate red **bounded and at its claimed `[QK:<claim>]` signature** — a wrong-reason red fails, a baseline-red control voids the whole group, and the runner is negative-controlled on every run (zero-match/multi-match/survived/wrong-reason/hang/control-red/impurity). This measures whether the deterministic gates still *block* what they claim to block; it is **not a new evidence level** (L0–L5 are untouched) and never substitutes for LIVE evidence. Per-cut records cite claim IDs + killed mutant IDs — "N checks passed" alone is not evidence. `check-agy-permission-matrix` complements it with the enumerated permission contract space (literal cells + stated exclusion rules, oracle independent of the SUT). The gate's HEAD is separable and IS in the floor: `check-gate-manifests` runs the runner self-test, validates the committed manifest set against the origin index, and asserts the declared lane inventory, while executing zero COMMITTED mutants (the self-test runs only its synthetic fixture mutants, in tmp fixture repos) and never snapshotting the repo — three of the five reds qualification has ever produced in CI died in that head, in under five seconds.
 - **Live floor:** `LIVE=1 ./run.sh release-gate <scratch-project-dir> --cut` — `pnpm run check:full` + the v2-native live gates + the ACP plugin acceptance floor. It reports a **two-tier summary**:
   - **MUST tier** (release-blocking — owns the exit code; "green" applies only here): `pnpm run check:full`, `check-gate-qualification`, `smoke-entwurf-v2-matrix-live`, `check-bridge`, `doctor-pi-provider` (#81 — `check-bridge` proves the launcher this checkout SHIPS; this proves the invocation the operator's pi provider actually EXECS, by booting it and requiring the entwurf verb set back, because `command -v` answers yes for a command that exits 127; wired as a step on 2026-08-19 after a relocated pnpm cmd-shim cost a cut sixteen LIVE steps before the same fact surfaced at `smoke-acp-bundled-mcp-live`), the resident-garden-guard zero-token half (record birth / record-keyed socket / attach-on-reopen), the `smoke-acp-*-live` ACP plugin smokes (socket-citizen / raw-turn / overlay / provider / session-reuse / carrier-augment / memory-containment / rgg / mcp / skill / bundled-mcp / v2-send), the axis wired in on 2026-07-31 that the aggregate had simply never listed (`smoke-claude-native-resume-live`), `smoke-entwurf-chain-live` — the cross-harness delivery chain (native Claude Code → pi GPT → pi ACP Sonnet → mailbox terminus) proving sender identity and replyability at every hop plus a real read receipt at the end — the integrated `smoke-mux-lifecycle-live` (its own note below), and the two OMP steps 0.16.0 wired: `smoke-omp-receive-live` (the addressed roundtrip into a live omp citizen; it reads the capability registry and decides its own outcome rather than passing by default) and `smoke-omp-fresh-live` (the clause 7 receipt the release stop now requires). (`smoke-session-id-name` is gone — #50 C3: its `--session-id`/`--name` substrate has no entwurf consumer anymore.)
   - **BEHAVIOR tier** (advisory, non-blocking): the resident-garden-guard positive (a model-in-loop `entwurf_self` turn). A BEHAVIOR FAIL is surfaced with its artifact path but **never blocks the cut**. The lane holds what the model *chooses*, never what our wiring fails to deliver — a gate that TELLS the model which tool to call stays MUST, because its failure is ours — measured 2026-07-24, when the tool turned out to be absent from the session schema in both observed failures (the bundled-MCP readiness gap recorded in `scripts/smoke-acp-v2-send-live.ts`).
@@ -132,6 +132,24 @@ that moved out of `scripts/` and into a file beside its subject would otherwise
 > `LIVE=1 ENTWURF_CODEX_APP_SERVER_PID=<existing-app-server-pid>
 > ENTWURF_CODEX_FRESH_MODEL=<codex-model>
 > ENTWURF_CODEX_FRESH_PI_MODEL=<pi-model> ./run.sh smoke-codex-fresh-live`.
+>
+> Those three values are the step's operator-supplied prerequisite, and
+> **`release-gate --cut` inherits that triple** — it is exported onto the aggregate invocation (the
+> release skill's P5 carries it), never inferred by the gate, so the no-inference rule above holds
+> unchanged inside the aggregate. **An ABSENT value is a protocol SKIP naming what was missing; a PRESENT but wrong one
+> stays a FAIL.** That split is the honest reading of the step-outcome protocol — a step that never
+> ran and a step that ran and broke are different facts — and it is what makes this MUST reproducible
+> at every cut instead of inviting a standing exception: before 2026-09-23 all three were assertions, so their
+> absence threw, and because the aggregate supplied none of them this step went red inside every
+> cut on every host (0.25.0's candidate receipt, `MUST PASS=23 FAIL=1`, is that shape). A SKIP is
+> **not** a softening: `--cut` refuses it as `cut: BLOCKED (MUST SKIP)`, so a cut without this
+> receipt is still impossible — the operator supplies the triple and re-runs. A host with no Codex
+> app-server therefore cannot take a cut, which is the intended cost of #87's release stop
+> (「A visible-fresh receipt outside the MUST tier is no longer the general rule」above) rather than
+> an accident. The installed-config preflights are deliberately NOT in that split and remain FAIL
+> on absence — a missing Codex birth, user MCP/status/terminal-title config, runtime, bridge, tmux
+> seat, or an unanswered launch directory is host state `setup` and the Codex doctors own, not a
+> per-invocation input.
 > **Both of THIS cell's live-spend defaults are `gpt-5.6-luna` from 2026-09-17**
 > (`openai-codex/gpt-5.6-luna` on the pi side) — the Codex leg came down off `sol`. It is a tier
 > choice and not a gate change; the receipt this cell is accepted on must be the one that actually
@@ -269,7 +287,7 @@ The goal is not merely "invoke Claude Code." We want:
 **One install command to remember: `./run.sh setup <project>`.** It is idempotent — re-run the exact same command whenever anything looks wrong. There is no second install surface to juggle: from a clone `setup` runs the whole floor in order.
 
 1. `pnpm install` — installs the pinned development dependencies and builds the bridge (source-checkout bootstrap only; an installed package never runs npm/pnpm inside `node_modules`)
-2. pi wiring → `<project>/.pi/settings.json` + user-scope registration — only when a `pi` inside the supported range (`>=0.86.0 <0.87`) is on PATH; absent pi is an explicit zero-state SKIP, a below-floor pi is a detected FAIL. The user-scope entry is owner-recorded (#86 C2): another root's live-or-missing ownership makes this step a zero-write refusal (setup: pi FAIL) that names `takeover-user-scope`; the install-states bind the exact managed settings path (a drifted/symlinked/corrupt target is a zero-write refusal) and the inverse removes only the recorded owner's exact entry; `doctor-pi-package` reports the verdict
+2. pi wiring → `<project>/.pi/settings.json` + user-scope registration — only when a `pi` inside the supported range (`>=0.87.1 <0.88`) is on PATH; absent pi is an explicit zero-state SKIP, a below-floor pi is a detected FAIL. The user-scope entry is owner-recorded (#86 C2): another root's live-or-missing ownership makes this step a zero-write refusal (setup: pi FAIL) that names `takeover-user-scope`; the install-states bind the exact managed settings path (a drifted/symlinked/corrupt target is a zero-write refusal) and the inverse removes only the recorded owner's exact entry; `doctor-pi-package` reports the verdict
 3. Claude meta-bridge global plugin — only when `claude` is on PATH; otherwise skipped cleanly
 4. source stable-bin exposure — including certified `entwurf` → this checkout's `run.sh`, the managed runtime Copilot fresh resolves; helper units are attempted independently and a foreign helper is a named FAIL
 5. agy bridge + exact permission + statusline + `PreInvocation` hook — only when `agy` is on PATH; each adapter is idempotent and independently doctorable

package/demo/README.md

@@ -46,7 +46,10 @@ a background driver types the scene prompts into the sender pane.
 1. **Spawn** a sonnet sibling (memory write — "tempered indigo").
 2. **Resume** that same sibling (memory recall — identity preservation,
    the #9 regression guard).
-3. **Cross-session greeting** via `entwurf_send` (sent box ↔ received box).
+3. **Cross-session greeting** via `entwurf_send`. *(Historical: `entwurf_send` was retired in the
+   0.12 cutover, and the "sent box" half of that pairing was never actually reachable — the
+   sender-side renderer had zero producers and was removed in #120 P3. What the recording shows on
+   the receive side is real; the send side is a box the operator could not have seen.)*
 
 Run:
 
@@ -139,7 +142,7 @@ SCENE_DELAY=30 FINAL_PAUSE=10 bash demo.sh
 
 ## Prerequisites
 
-- `pi` on PATH (current floor 0.86.0)
+- `pi` on PATH (current floor 0.87.1)
 - `entwurf` provider configured + auth ready for the selected sender/peer models
 - `asciinema` installed
 - `agg` installed (optional — only for GIF conversion)

package/docs/acp-backend-rail.md

@@ -92,8 +92,8 @@ undifferentiated "supported" column is what let a Claude PASS read as if it also
 
 | Surface | Declaration | Class | What a green actually says |
 |---|---|---|---|
-| Entwurf package | `0.24.0` | shipped baseline | the package contract these rows belong to |
-| pi runtime | devDep exact `0.86.0`, peer `>=0.86.0 <0.87` | **exact** oracle + **closed range** | built and certified against 0.86.0; hosts inside the range are accepted, and the ceiling moves only on measurement |
+| Entwurf package | `0.25.0` | shipped baseline | the package contract these rows belong to |
+| pi runtime | devDep exact `0.87.1`, peer `>=0.87.1 <0.88` | **exact** oracle + **closed range** | built and certified against 0.87.1; hosts inside the range are accepted, and the ceiling moves only on measurement |
 | ACP wire SDK | `@agentclientprotocol/sdk 1.4.0` | **exact** | the shared wire oracle both adapters speak |
 | Claude ACP adapter | `@agentclientprotocol/claude-agent-acp 0.79.0` | **exact**, bundled | the adapter we ship and certify; resolved before any PATH fallback |
 | Claude Agent SDK | `0.3.274` (transitive) | **exact** oracle | the runtime risk surface behind the adapter |
@@ -476,6 +476,53 @@ already emitted a `usage_update` at `compact_boundary` and 0.75.1 still does
 
 Receipt, limits and the `completed`-branch gap: `scripts/raw-acp-compaction-measure/README.md`.
 
+## 11-9. A steer reaches an ACP receiver one child turn late (#120 P5, measurement only)
+
+`entwurf_v2 mode:"steer"` injects into the receiver's pi steering queue; it is not an ACP concept.
+On a NATIVE pi receiver that queue is drained seconds later, and on an ACP receiver it is drained
+one whole child turn later. The difference is not a different drain point — it is the same one.
+
+`[측정 2026-09-22, pi-agent-core 0.87.0; 재측정 2026-09-23, 0.87.1 — 좌표 동일]` `dist/agent-loop.js:141` awaits `streamAssistantResponse`
+once per turn, and the steering drain is `:186`, after the `turn_end` emit at `:185`. For this rail
+that one await is `pi-extensions/lib/acp/backend.ts:815` —
+`await Promise.race([session.connection.prompt(promptArgs), lifecycle])` — so it spans the entire
+`session/prompt` round trip. The child's own tool calls and subagent turns are invisible to pi, so
+pi cannot reach `:186` until the child turn ends. Same code path as native, one long await.
+
+That is a property, not a silent failure: the sender's receipt already says `queued-steer` and
+`DELIVERY.md` already states that both queues are volatile and unordered against each other, so
+nothing here is promised and then quietly not delivered. `[QK:PI-QUEUE-NO-MIDFLIGHT-MERGE]`
+(`test/pi-queue.oracle.test.ts`) proves the mechanism on the installed vendor: a message queued
+while a turn is in flight never joins that turn and arrives as a later one. The delay's SIZE is
+that turn's duration, which the same cell fixes by construction.
+
+**Forwarding is not adopted here.** `[측정 2026-09-22]` standard ACP has no steer method at all —
+enumerating the installed `@agentclientprotocol/sdk`'s `AGENT_METHODS` and `CLIENT_METHODS` yields
+zero entries containing `steer`. What exists is a PRIVATE vendor extension,
+`_session/steering` in `@agentclientprotocol/claude-agent-acp@0.79.0`
+(`dist/acp-agent.js:163`, handler at `:7792`), client→agent, advertised through
+`InitializeResponse._meta.steering.supported`. Our client sends `initialize`, `session/new`,
+`session/prompt`, `session/set_config_option` and `session/cancel` (`acp-client.ts:138-149`) and
+has no steering path at all.
+
+Adopting it would mean owning five things this driver does not own today, each a new contract
+rather than a wiring change:
+
+1. reading the `_meta.steering.supported` capability, and deciding what a backend without it is;
+2. a typed schema and version fence for a request that is outside the SDK's method set, so a
+   private extension changing shape is a named refusal rather than a silent no-op;
+3. a backend-specific concurrent-request seam from the control extension to a live ACP connection —
+   today a turn is one in-flight `prompt`, and this adds a second request during it;
+4. an exactly-once / ordering policy that picks the outer pi queue or the vendor injection but never
+   both, since those are two independent orderings that currently do not meet;
+5. a receipt mapping for the extension's outcomes — `injected`, `promptRequired`, `startedNewTurn` —
+   plus the idle race, cancel and release meanings behind them. (`idleBehavior:"promptRequired"`
+   lets a host refuse the detached `startedNewTurn` path, but that opt-in is itself a new contract.)
+
+The adapter keeps its own turn-settlement bookkeeping internally, and our event mapper ignores
+update kinds it does not handle (`event-mapper.ts:377-378`), so nothing above is a claim that
+Entwurf must replicate vendor internals. The reason to stay put is the five contracts, not a ledger.
+
 ## Open work
 
 - causal MCP-readiness diagnosis and, only with proof, a backend-invariant fence;

package/docs/setup-clean-host.md

@@ -22,7 +22,7 @@ evidence split, and its three states must not collapse into "macOS is supported"
 | npm/pnpm | npm is bundled with Node; pnpm is required for source setup | package or source installation |
 | Python 3 | required by `setup`/`install` (project-path normalization + settings writers); `--help`/`check-bridge` stay Python-free | pi/Claude/agy/Copilot/Codex wiring writers |
 | entwurf | global/project-local `@junghanacs/entwurf`, or a source checkout | operator command and garden capability |
-| pi | optional-by-presence, `>=0.86.0 <0.87` — absent is an explicit setup SKIP, below-floor is a named FAIL | ACP provider, control sockets |
+| pi | optional-by-presence, `>=0.87.1 <0.88` — absent is an explicit setup SKIP, below-floor is a named FAIL | ACP provider, control sockets |
 | Claude Code | optional, **`>=2.1.217`** — the exec-form hook floor | Claude ACP auth/runtime and mailbox-backed native citizen |
 | GitHub Copilot CLI | optional-by-presence, operator-installed and authenticated — absent is an explicit setup SKIP; detected composes all four units (birth/MCP/receiver/footer) | self-fetch citizen and visible fresh |
 | OMP (`omp`) | optional-by-presence, operator-installed — absent is an explicit setup SKIP; detected composes all four units (birth/MCP/`tools.xdev` setting/receiver) | self-fetch citizen and visible fresh (accepted on one host — see §4b) |
@@ -156,7 +156,7 @@ on Darwin; that is wiring, not a rail receipt. If `pi` is on PATH,
 Install the exact release floor, then wire the project:
 
 ```bash
-npm install -g @earendil-works/pi-coding-agent@0.86.0
+npm install -g @earendil-works/pi-coding-agent@0.87.1
 pi --version
 
 cd ~/entwurf-smoke
@@ -164,7 +164,7 @@ entwurf install .
 pi -e "$(npm root -g)/@junghanacs/entwurf" --list-models entwurf
 ```
 
-The supported range is `>=0.86.0 <0.87`. It is a hard minimum: installing this
+The supported range is `>=0.87.1 <0.88`. It is a hard minimum: installing this
 release onto a 0.83.x pi host upgrades the runtime rather than keeping the older
 minor. A host using only the external MCP bridge can skip pi until it needs a
 control socket; no delivery rail launches a pi process.
@@ -307,7 +307,7 @@ as a note rather than a fault.
 
 **entwurf sets no OMP version floor in code, and will not grow one on schedule.** Detection is
 presence-only (`command -v "${OMP_BIN:-omp}"`); there is no `entwurf.ompFloor`, no coherence
-gate, and no exact pin — unlike Node (`engines.node`), pi (`>=0.86.0 <0.87`) and Claude Code
+gate, and no exact pin — unlike Node (`engines.node`), pi (`>=0.87.1 <0.88`) and Claude Code
 (`entwurf.claudeCodeFloor`), each of which has an enforcement point. That asymmetry is a
 decision, not an omission. A floor is the answer to a vendor that fails SILENTLY — Claude Code
 earned one because an older binary validates the exec manifest, drops `args` at runtime, and

package/mcp/entwurf-bridge/dist/mcp/entwurf-bridge/src/index.js

@@ -354,7 +354,9 @@ server.tool("entwurf_v2", "CANONICAL DELIVERY SURFACE for garden ids: message, r
     "alone does not say which rail that citizen answers on. Give target + intent; the decider picks transport " +
     "from liveness (live socket citizen → control-socket send; deliverable self-fetch citizen → meta-bridge " +
     "mailbox; probe-alive native-push citizen → direct injection into its conversation) and reports ONE " +
-    "outcome (delivered / rejected / delivered-but-lock-dirty). EXISTING targets only; discover with " +
+    "outcome, named per rail: a control receiver's acceptance boundary (`sent` / `queued-steer` / " +
+    "`queued-follow-up` / `accepted-unknown-boundary` — those four only), a mailbox ENQUEUE receipt, a " +
+    "native-push INJECTION, a rejection, or lock-dirty. EXISTING targets only; discover with " +
     "entwurf_peers. A peer entwurf_peers shows as liveness=alive → fire-and-forget. A " +
     "citizen with NO socket liveness (liveness=unsupported) is ALSO fire-and-forget — unsupported means only " +
     '"no control-socket probe." The decider resolves the actual rail at dispatch time: a self-fetch ' +
@@ -389,9 +391,8 @@ server.tool("entwurf_v2", "CANONICAL DELIVERY SURFACE for garden ids: message, r
     mode: z
         .enum(["steer", "follow_up"])
         .optional()
-        .describe("Injection style for a CONTROL-SOCKET send only: steer (interrupt the current turn) or " +
-        "follow_up (queue after it). The mailbox and native-push plans carry no mode, so it has no " +
-        "effect on those rails."),
+        .describe("Injection style for a CONTROL-SOCKET send only: steer (ask the receiver's steering queue) or follow_up (ask its follow-up queue). NEITHER is an interrupt: a busy receiver drains steering after each turn and follow-ups only when its inner loop ends, so a later steer overtakes every earlier follow_up and there is no order between the two. Both queues are volatile process memory — an abort drops what is in them. The receipt names which queue accepted the message (`queued-steer` / `queued-follow-up`); an idle receiver answers `sent`, meaning the turn was TRIGGERED, not that the model has seen the text. " +
+        "The mailbox and native-push plans carry no mode, so it has no effect on those rails."),
     wants_reply: z.boolean().optional().describe("Human-conversation reply hint (default false)"),
 }, async ({ target, intent, message, mode, wants_reply }, extra) => {
     try {

package/mcp/entwurf-bridge/dist/pi-extensions/lib/control-send-receipt.js

@@ -0,0 +1,101 @@
+/**
+ * control-send-receipt — the ONE place the control-socket's acceptance boundary is named,
+ * on both ends of the wire (#120 P2).
+ *
+ * WHY A BOUNDARY AXIS AT ALL, AND WHY IT IS NOT THE ROUTE AXIS.
+ * `SendFinalOutcome` (`entwurf-v2-send.ts`) answers WHICH LEG delivered — first socket,
+ * re-resolved socket, mailbox — and it is what the release reducer keys on. It is an INTERNAL
+ * route/release algebra and it is NOT the sender-visible delivery boundary: `sent` and
+ * `fallback-sent` say a receiver accepted the bytes, and nothing whatever about what the receiver
+ * then did with them. Answering "what happened to my message" with a route word is how
+ * `control-socket → sent` came to mean four different things, one of which was
+ * "queued behind ten steers and dropped when the operator hit ESC".
+ *
+ * `[측정 2026-09-22, pi-agent-core 0.87.0; 재측정 2026-09-23, 0.87.1 — 좌표 동일]` the receiver's two queues are independent and each is
+ * `one-at-a-time` (`dist/agent.js:60-71,96-97,137-138`); steering is drained after every turn
+ * (`dist/agent-loop.js:85,186`) while follow-ups are drained ONLY when the inner loop has ended
+ * (`:191-197`). There is no global FIFO across them. So `steer` and `follow_up` are not two
+ * spellings of one queue — they are two different promises about when, and a receipt that cannot
+ * tell them apart cannot be used to reason about either.
+ *
+ * WHAT EACH BOUNDARY CLAIMS, EXACTLY:
+ *   sent                        the receiver was idle and the message was accepted as a DIRECT
+ *                               turn trigger. It is an accepted REQUEST, not proof that the model
+ *                               saw it and not proof the turn completed.
+ *   queued-steer                accepted into the receiver's in-process steering queue. Volatile
+ *                               process memory: no durability, no ordering against the other
+ *                               queue, and an abort clears it.
+ *   queued-follow-up            accepted into the receiver's in-process follow-up queue. Same
+ *                               volatility, and it waits for the inner loop to end — a steer that
+ *                               arrives later still goes first.
+ *   accepted-unknown-boundary   the receiver ACCEPTED (its RPC answered success) but did not name
+ *                               a boundary this build understands. Version skew, not failure: the
+ *                               message is gone from our hands either way, so this must never be
+ *                               rendered as a failure to retry — and never as `sent`, which would
+ *                               put back the exact false claim this axis exists to remove.
+ *
+ * NO LEGACY MAPPER LIVES HERE. The previous wire carried `delivered:true` plus a `deliveredAs`
+ * producer nothing consumed; both are gone rather than translated. A new receiver answers an old
+ * sender fine (it keys on `response.success` and ignores `data`), and an old receiver answers a
+ * new sender as `accepted-unknown-boundary` — which is the honest name for it. A dual route would
+ * be a second address for one fact.
+ */
+/** The closed boundary set, in the order a reader should learn them. */
+export const ACCEPTANCE_BOUNDARIES = ["sent", "queued-steer", "queued-follow-up", "accepted-unknown-boundary"];
+/**
+ * RECEIVER SIDE. The whole classification, from the two facts the receiver already has at the
+ * moment it accepts: was it idle, and which queue did the caller ask for. Pure — it reads no
+ * clock, no socket and no session, so the same inputs always name the same boundary.
+ *
+ * `idle` wins over `mode`: an idle receiver takes the message as a direct trigger and neither
+ * queue is involved, which is why `mode` is meaningless there (`entwurf-control.ts` passes no
+ * `deliverAs` on that branch).
+ */
+export function sendReceiptBoundary(input) {
+    if (input.idle)
+        return "sent";
+    return input.mode === "follow_up" ? "queued-follow-up" : "queued-steer";
+}
+/** Is this an acceptance a receiver could have observed about itself? */
+export function isObservedBoundary(value) {
+    return value === "sent" || value === "queued-steer" || value === "queued-follow-up";
+}
+/**
+ * SENDER SIDE. Read the receiver's typed boundary off an RPC `data` payload.
+ *
+ * Anything this build does not recognise — a missing field, an older receiver's shape, a value
+ * outside the set — is `accepted-unknown-boundary` and NOT an error: by the time `data` exists the
+ * RPC has already answered success, so the message has been accepted. Inventing a failure here
+ * would invite a retry that double-delivers, and answering `sent` would claim a direct injection
+ * nobody reported.
+ */
+export function parseAcceptanceBoundary(data) {
+    if (typeof data !== "object" || data === null)
+        return "accepted-unknown-boundary";
+    const value = data.boundary;
+    return isObservedBoundary(value) ? value : "accepted-unknown-boundary";
+}
+/** How much of an unrecognised answer may be repeated back. A receiver's payload is untrusted
+ * input from another process; a full object on a status line is an injection surface and an
+ * unbounded one at that. */
+const UNKNOWN_DIAGNOSTIC_MAX = 80;
+/**
+ * A BOUNDED, single-line description of an answer we could not classify — for the operator who has
+ * to decide whether this is version skew or a broken peer. Returns `undefined` when there is
+ * nothing worth saying, so a caller renders the bare boundary rather than an empty parenthesis.
+ *
+ * It describes the SHAPE and never trusts the content: the raw value is stringified, stripped of
+ * newlines and truncated. Never the whole object.
+ */
+export function describeUnknownBoundary(data) {
+    if (typeof data !== "object" || data === null)
+        return data === undefined ? undefined : `data: ${typeof data}`;
+    const value = data.boundary;
+    if (value === undefined)
+        return "no boundary field";
+    const raw = typeof value === "string" ? value : typeof value;
+    const flat = raw.replace(/\s+/g, " ").trim();
+    if (flat === "")
+        return "empty boundary";
+    return flat.length > UNKNOWN_DIAGNOSTIC_MAX ? `${flat.slice(0, UNKNOWN_DIAGNOSTIC_MAX)}…` : flat;
+}

package/mcp/entwurf-bridge/dist/pi-extensions/lib/entwurf-v2-contract.js

@@ -228,8 +228,12 @@ export const ENTWURF_V2_TRANSPORTS = ["control-socket", "meta-mailbox", "native-
 // and a future visible-resume verb would speak them again.
 export const ENTWURF_V2_ACTIONS = ["send"];
 export const ENTWURF_V2_OWNERSHIPS = ["ack-only"];
-// Delivery mode of the message to the target (how it is injected) — steer =
-// interrupt the current turn, follow_up = queue after it. A SEPARATE axis from
+// Delivery mode of the message to the target: WHICH QUEUE a busy receiver is asked for.
+// `[측정 2026-09-22, pi-agent-core 0.87.0; 재측정 2026-09-23, 0.87.1 — 좌표 동일]` neither is an interrupt — `dist/agent-loop.js:186`
+// drains steering after each turn and `:191-197` drains follow-ups only once the inner loop has
+// ended, and the two queues (`dist/agent.js:96-97,137-138`) have no FIFO between them, so a later
+// steer overtakes every earlier follow_up. Both are volatile process memory and an abort drops
+// them. A SEPARATE axis from
 // both the intent/ownership axis (F1) and the liveness-routing axis. The removed
 // v1 `entwurf_send` carried the same steer|follow_up surface, so this axis is
 // inherited vocabulary, not a second live delivery verb.

package/mcp/entwurf-bridge/dist/pi-extensions/lib/entwurf-v2-production.js

@@ -28,6 +28,7 @@
  * canonical socket path; `indeterminate` (EACCES/unknown) fails loud rather than silently
  * claiming "no conflict". The decider's later `inspectSocket` probe is a SEPARATE step.
  */
+import { describeUnknownBoundary, parseAcceptanceBoundary } from "./control-send-receipt.js";
 import { sendRpcCommand as realSendRpc, } from "./entwurf-control-rpc.js";
 import { mailboxConversationalDeliverable, resolveMailboxReceiverFacts, } from "./entwurf-deliverability.js";
 import { isOutOfSocketDomainGardenIdConflict } from "./entwurf-facts.js";
@@ -190,7 +191,22 @@ export function makeProductionEntwurfV2Deps(opts) {
                 wants_reply: plan.wantsReply,
                 sender: opts.senderProvider(),
             });
-            return { success: response.success, error: response.error };
+            // #120 P2 THE WIRE SEAM. `response.data` is another process's payload, so it is
+            // classified here by one total function and never carried raw any further: a shape we
+            // do not recognise becomes `accepted-unknown-boundary`, an ACCEPTANCE we could not
+            // name rather than a failure — the RPC already answered success, so the message is out
+            // of our hands and inventing a failure here would invite a double delivery. Only a
+            // SUCCESSFUL answer gets a boundary; a refusal carries its error instead.
+            const boundary = response.success ? parseAcceptanceBoundary(response.data) : undefined;
+            if (boundary === "accepted-unknown-boundary") {
+                // The operator has to be able to tell version skew from a broken peer, and the
+                // receipt itself may not carry another process's payload onto a status line.
+                // Hard Rule 15: diagnostics go to stderr, bounded and single-line.
+                const shape = describeUnknownBoundary(response.data);
+                process.stderr.write(`[entwurf_v2] ${plan.targetGardenId} accepted the message but named no boundary this build knows` +
+                    `${shape === undefined ? "" : ` (${shape})`}\n`);
+            }
+            return { success: response.success, error: response.error, boundary };
         },
         classifyConnect: io.classifyConnect,
         releaseLock: release,

package/mcp/entwurf-bridge/dist/pi-extensions/lib/entwurf-v2-runner.js

@@ -55,6 +55,7 @@ export async function executeDispatch(decision, deps) {
                         outcome: r.outcome,
                         rejectReason: r.rejectReason,
                         messagePath: r.messagePath,
+                        boundary: r.boundary,
                     },
                 };
             }
@@ -67,6 +68,9 @@ export async function executeDispatch(decision, deps) {
                         transport,
                         error: errorMessage(err),
                         finalizedOutcome: err.finalizedOutcome,
+                        finalizedBoundary: err.finalizedBoundary,
+                        finalizedMessagePath: err.finalizedMessagePath,
+                        finalizedRejectReason: err.finalizedRejectReason,
                         releaseFailed: true,
                         retrySafe: false,
                     };

package/mcp/entwurf-bridge/dist/pi-extensions/lib/entwurf-v2-send.js

@@ -32,6 +32,19 @@
  * `releaseLock` throw never MASKS a send failure — the original error wins (5b).
  */
 import { decideReleasePolicy, initialReleaseState, reduceRelease, } from "./entwurf-v2-release.js";
+/**
+ * A successful SOCKET answer always carries a boundary: the wire seam classifies every answer with
+ * one total function, and an answer it cannot place is `accepted-unknown-boundary` rather than
+ * nothing. So `undefined` here is not a host state, it is a bypassed seam — a dep wired straight
+ * past the classifier. Fail loud. A silent default would make the one shape that must never be
+ * mistaken for a direct trigger — delivered, boundary unknown to us — look exactly like one.
+ */
+function requireBoundary(result) {
+    if (result.boundary === undefined) {
+        throw new Error("entwurf-v2-send: a successful control-socket RPC reported no acceptance boundary — the wire seam that classifies one was bypassed (contract violation).");
+    }
+    return result.boundary;
+}
 /**
  * Execute a control-socket send to a final outcome and release the held lock exactly
  * once. `lock` MUST be the in-domain claim the decider handed over —
@@ -58,7 +71,12 @@ export async function executeControlSocketSend(plan, lock, deps) {
         drive = { outcome: "failed", error: err };
     }
     finalizeRelease(policy, deps, held, drive);
-    return { outcome: drive.outcome, rejectReason: drive.rejectReason, messagePath: drive.messagePath };
+    return {
+        outcome: drive.outcome,
+        rejectReason: drive.rejectReason,
+        messagePath: drive.messagePath,
+        boundary: drive.boundary,
+    };
 }
 /** Drive the 1차 send and route a connect failure through the F3 split. */
 async function driveSend(plan, lock, deps) {
@@ -78,7 +96,7 @@ async function driveSend(plan, lock, deps) {
     }
     // A completed RPC: ack ⇒ sent; in-band refusal ⇒ rejected, NO fallback. Preserve
     // its receiver error verbatim when supplied; do not make a reason up when absent.
-    return result.success ? { outcome: "sent" } : inBandRejected(result);
+    return result.success ? { outcome: "sent", boundary: requireBoundary(result) } : inBandRejected(result);
 }
 /**
  * The dead-path fallback: re-resolve ONCE under the held lock, then run the resolver's
@@ -116,7 +134,7 @@ async function driveDeadFallback(plan, lock, deps) {
             // connect failure finalizes as failed (no further fallback).
             try {
                 const r = await deps.sendOverSocket(rePlan);
-                return r.success ? { outcome: "fallback-sent" } : inBandRejected(r);
+                return r.success ? { outcome: "fallback-sent", boundary: requireBoundary(r) } : inBandRejected(r);
             }
             catch (err) {
                 return { outcome: "failed", error: err };
@@ -152,12 +170,35 @@ async function driveDeadFallback(plan, lock, deps) {
  */
 export class SendDeliveredReleaseFailedError extends Error {
     finalizedOutcome;
+    /** #120 P2: the ACCEPTANCE the send actually reached, carried through the failure so the
+     * dirty-lock line can say what happened instead of a bare route word. Absent on a `rejected`
+     * finalization (nothing was accepted) and on the mailbox fallback leg (which carries a file
+     * instead) — those two are exactly why this is optional rather than defaulted. */
+    finalizedBoundary;
+    /** #98 R receipt, same reason: a mailbox fallback that then failed to release still wrote a
+     * `.msg`, and the operator has to be told WHICH one before touching the lock. */
+    finalizedMessagePath;
+    /** The receiver's own refusal text on a `rejected` finalization. Without it the dirty-lock line
+     * is the ONE place a refusal loses its reason — and it is the place an operator reads while
+     * deciding by hand whether the message still needs sending. */
+    finalizedRejectReason;
     releaseError;
-    constructor(finalizedOutcome, releaseError) {
+    constructor(finalizedOutcome, releaseError, accepted = {}) {
         const detail = releaseError instanceof Error ? releaseError.message : String(releaseError);
-        super(`entwurf-v2-send: ${finalizedOutcome} delivered but releaseLock failed (lock dirty, do NOT re-send): ${detail}`);
+        // NOT "delivered". The word was wrong on two of the three shapes that reach here — a
+        // `rejected` finalization delivered nothing at all, and a `queued-*` one is sitting in
+        // volatile memory — and DELIVERY.md refuses a bare `delivered` for exactly that reason.
+        // What is true of all three is that the send REACHED A TERMINAL RESULT and must not be
+        // repeated.
+        const what = finalizedOutcome === "rejected"
+            ? `rejected${accepted.rejectReason ? ` (${accepted.rejectReason})` : ""}`
+            : (accepted.boundary ?? "mailbox-enqueued");
+        super(`entwurf-v2-send: the send finalized as \`${what}\` and releaseLock then failed (lock dirty, do NOT re-send): ${detail}`);
         this.name = "SendDeliveredReleaseFailedError";
         this.finalizedOutcome = finalizedOutcome;
+        this.finalizedBoundary = accepted.boundary;
+        this.finalizedMessagePath = accepted.messagePath;
+        this.finalizedRejectReason = accepted.rejectReason;
         this.releaseError = releaseError;
     }
 }
@@ -183,7 +224,13 @@ function finalizeRelease(policy, deps, lock, drive) {
                 throw original;
             // N1: the delivery/refusal already happened — surface it as a structured,
             // retry-unsafe error rather than a bare release throw.
-            throw new SendDeliveredReleaseFailedError(drive.outcome, releaseErr);
+            // The acceptance truth rides along: without it the dirty-lock line is the ONE place
+            // left that still answers "what happened to my message" with a route word.
+            throw new SendDeliveredReleaseFailedError(drive.outcome, releaseErr, {
+                boundary: drive.boundary,
+                messagePath: drive.messagePath,
+                rejectReason: drive.rejectReason,
+            });
         }
     }
     if (drive.outcome === "failed")

package/mcp/entwurf-bridge/dist/pi-extensions/lib/entwurf-v2-surface.js

@@ -124,9 +124,34 @@ export function renderEntwurfV2Result(result) {
                 // socket-to-socket retry (no file) and on every non-mailbox outcome, so the
                 // line degrades to the bare outcome rather than printing "undefined".
                 const enqueued = o.messagePath ? ` (enqueued ${basename(o.messagePath)})` : "";
+                if (delivered) {
+                    // #120 P2 — THE BOUNDARY IS THE RECEIPT, and the route is an annotation.
+                    // `sent` / `fallback-sent` name which LEG carried the bytes. An operator
+                    // cannot act on that: for 78 minutes this line said `sent` about a message
+                    // lying in a queue. So the visible word is what the RECEIVER observed —
+                    // `sent` only for an idle direct trigger, `queued-steer` /
+                    // `queued-follow-up` for the two volatile in-process queues, and
+                    // `accepted-unknown-boundary` when a peer answered success in a shape this
+                    // build cannot classify. That last one is never spelled with the word
+                    // "sent": it was accepted, and saying "sent (unknown)" would put back the
+                    // exact false claim this axis exists to remove.
+                    //
+                    // A re-resolved MAILBOX leg has no turn-injection boundary at all — it
+                    // wrote a durable file — so it says `mailbox-enqueued` rather than a bare
+                    // route word. The route survives as a separate annotation either way,
+                    // because "your first socket was dead" is a real thing to have been told.
+                    const route = o.outcome === "fallback-sent" ? " (via a re-resolved route)" : "";
+                    // A re-resolved leg with no boundary IS the mailbox leg — that rail reports a
+                    // durable file instead. A PRIMARY leg with no boundary is structurally
+                    // impossible (the send hand throws on it), so if one ever arrives here it is
+                    // named as the acceptance we could not classify rather than dressed as a
+                    // mailbox file that was never written.
+                    const boundary = o.boundary ?? (o.outcome === "fallback-sent" ? "mailbox-enqueued" : "accepted-unknown-boundary");
+                    return { text: `entwurf_v2 control-socket → ${boundary}${route}${enqueued}`, isError: false };
+                }
                 return {
                     text: `entwurf_v2 control-socket → ${o.outcome}${reason}${enqueued}`,
-                    isError: !delivered,
+                    isError: true,
                 };
             }
             if (o.transport === "native-push") {
@@ -150,9 +175,19 @@ export function renderEntwurfV2Result(result) {
         }
         case "execution-failed": {
             if (result.releaseFailed && result.finalizedOutcome) {
-                // N1: the delivery/refusal reached a terminal outcome but releaseLock then threw.
+                // N1: the send reached a terminal result and `releaseLock` then threw.
+                //
+                // #120 P2 — THIS LINE USED TO SAY `DELIVERED (<route>)` ABOUT ALL THREE SHAPES THAT
+                // REACH IT, and it was wrong about two of them: a `rejected` finalization delivered
+                // nothing at all, and a `queued-*` one is sitting in volatile receiver memory. So
+                // the same acceptance vocabulary the ordinary receipt uses is named here too — a
+                // dirty lock is a reason to be MORE precise about what happened, not less, because
+                // the operator is about to decide by hand whether anything needs re-sending.
+                const what = result.finalizedOutcome === "rejected"
+                    ? `rejected${result.finalizedRejectReason ? ` (${result.finalizedRejectReason})` : ""} — the receiver refused it; nothing was accepted`
+                    : `${result.finalizedBoundary ?? "mailbox-enqueued"}${result.finalizedMessagePath ? ` (enqueued ${basename(result.finalizedMessagePath)})` : ""}`;
                 return {
-                    text: `entwurf_v2 ${result.transport} DELIVERED (${result.finalizedOutcome}) but the lock is DIRTY ` +
+                    text: `entwurf_v2 ${result.transport} finalized as ${what}, and the lock is DIRTY ` +
                         `(release failed) — do NOT retry, a re-send would double-deliver. Clear the lock by hand.` +
                         `\n  error: ${result.error}`,
                     isError: true,

package/mcp/entwurf-bridge/dist/pi-extensions/lib/herdr-fresh-call.js

@@ -43,13 +43,23 @@
 import { createHash } from "node:crypto";
 import { statSync } from "node:fs";
 import path from "node:path";
+import { HERDR_FRESH_CALL_BACKENDS } from "../../scripts/herdr-rails.mjs";
 import { callbackEnvAssignments } from "./callback-env.js";
 import { buildOmpBootstrapPayload, composeBackendArgs, composeFreshCallFraming, normalizeFreshCallInputs, TASK_MAX_CHARS, } from "./fresh-call-composition.js";
-/** The pilot set, closed. `[#116 decision]` herdr's own `--kind` enum is much larger, and that is
+/**
+ * The pilot set, closed. `[#116 decision]` herdr's own `--kind` enum is much larger, and that is
  * NOT evidence of support: every other backend is a pre-mutation named reject here, and there is
  * no fallback to the tmux rail — a caller inside herdr who asks for codex gets a refusal, not a
- * window somewhere else. */
-export const HERDR_FRESH_CALL_BACKENDS = ["pi", "claude-code"];
+ * window somewhere else.
+ *
+ * The VALUE now lives in `scripts/herdr-rails.mjs`, the one leaf the status pane and the install
+ * narration also read (#116 A7), so a fourth backend cannot appear in prose on one surface while
+ * this rail still refuses it. The re-export keeps this module's public name unchanged. The TYPE
+ * still has to be a tuple: a `.mjs` leaf infers `readonly string[]` without the JSDoc cast there,
+ * and `HerdrFreshCallBackend` would silently widen to `string` while every runtime check still
+ * passed. A gate pins that.
+ */
+export { HERDR_FRESH_CALL_BACKENDS };
 /** Our backend name → the `--kind` token herdr accepts. `[측정 2026-09-14]` both round-tripped with
  * the vendor executable echoed back in `argv`. This is a REQUESTED kind: `[file:line @ c77af189]`
  * `src/app/agents.rs:197-199` turns it into a bare executable name and writes it into the pane's

package/mcp/entwurf-bridge/dist/pi-extensions/lib/herdr-placement.js

@@ -79,6 +79,17 @@ const OFFICIAL_REPORTS = {
  * only diff in that file's `.jsonl` lines is a lambda parameter rename on the READER
  * side. A source read alone would not have settled it, so the real file is the receipt.
  *
+ * `[측정 2026-09-22, pi 0.87.0]` re-measured, and the shape of the evidence CHANGED for the better.
+ * Source: the three lines that BUILD a session name are byte-unchanged from 0.86.0
+ * (`packages/coding-agent/src/core/session-manager.ts` `${fileTimestamp}_${sessionId}.jsonl` at
+ * :1080/:1666/:1842, moved from :991/:1527/:1703 by the +148/−9 `SessionManager`-canonical work
+ * 0.87.0 declares as breaking). File: `scripts/check-herdr-placement.ts` now makes the installed
+ * `SessionManager` write a real session file into a temp dir on EVERY run — `create()` plus one
+ * `appendMessage`, zero model, zero network, zero child process — and asserts this parser reads
+ * that basename back to the id the file's own header declares. So the vendor floor below is no
+ * longer a receipt somebody took once; it is re-taken by the gate. The 0.86.0 hand-measured file
+ * stays a 0.86.0 fact in the bump ledger rather than being re-dated.
+ *
  * WHY THIS IS PINNED HERE AND NOT INFERRED. The uuid is the join key and it lives in
  * a VENDOR filename, so this rule depends on pi's naming and would break silently if
  * pi changed it. **Vendor floor: pi 0.86.0, measured 2026-09-20** — whether that layout

package/mcp/entwurf-bridge/dist/protocol.js

@@ -20,10 +20,3 @@
  * AGENTS.md section from its own pi-context augment.
  */
 export const ENTWURF_PROJECT_CONTEXT_OPEN_TAG = "<project-context";
-/**
- * Sender-side UI echo custom message type for successful entwurf_v2 send calls.
- * The bridge emits it, the control renderer draws it, and the provider-level
- * context filter removes it before LLM conversion. Keep as one SSOT: a typo
- * here otherwise becomes a silent UI/context split.
- */
-export const ENTWURF_SENT_MESSAGE_TYPE = "entwurf-sent";