@junghanacs/entwurf 0.24.0 → 0.25.0

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";

package/mcp/entwurf-bridge/dist/scripts/doctor-pi-provider.js

@@ -143,11 +143,24 @@ log(`  project      ${projectPath}: ${projScopeDesc}`);
 log(`  EFFECTIVE (${effectiveScope}): ${effectiveDesc}`);
 // install-state ownership (user scope). absent state on a configured effective is either a
 // pre-Task-2 install or a user-override we deliberately did not own.
+//
+// `command` is read beside it because it — not the bare name — is the CANONICAL managed command
+// (#116 M3-b2). `register-pi-provider.py` writes the same string into the settings entry and into
+// this record (:332-342, :368-369), and in plugin mode that string is an absolute bridge under the
+// certified stable runtime, because a Herdr-plugin host has nothing entwurf on PATH. Reading it
+// here is what lets this doctor judge drift without re-deriving the stable runtime root: the root
+// is the writer's business, and a second derivation in this file would be a second address axis.
+//
+// `ownership` is the PREIMAGE classification — what stood at the key BEFORE that install — so
+// `absent` means "we created it", not "nobody owns it". Treating it as an ownership verdict is what
+// made every plugin-mode host red while its bridge booted and served all eight verbs.
 let ownership;
+let stateCommand;
 if (existsSync(statePath)) {
     try {
         const st = JSON.parse(readFileSync(statePath, "utf8"));
         ownership = typeof st.ownership === "string" ? st.ownership : undefined;
+        stateCommand = typeof st.command === "string" ? st.command : undefined;
         log(`  state: install-state present (ownership=${ownership}).`);
     }
     catch {
@@ -200,9 +213,33 @@ else {
             hardFail = 1;
         }
     }
-    if (!isBare) {
-        // Ownership classification never rounds a broken runtime up to green. It only says who may
-        // repair the non-canonical entry after the independent boot verdict above.
+    // Ownership classification never rounds a broken runtime up to green. It only says who may
+    // repair the entry after the independent boot verdict above.
+    //
+    // A MANAGED record is the pair (known preimage ownership, recorded command). For that pair the
+    // recorded command is canonical and the comparison runs REGARDLESS of whether the effective
+    // command happens to be the bare name. Keeping this decision inside a `!isBare` branch is how
+    // real drift escaped: a record naming the absolute plugin bridge, with the settings repointed to
+    // the bare `entwurf-bridge`, is drift — and a bare bridge that boots would otherwise carry it to
+    // green. "The effective command is spellable as our old default" is not evidence that it is the
+    // command this install wrote.
+    //
+    // Everything else — a record that names no command, or one whose ownership is a word this
+    // doctor does not know — falls through to the ORIGINAL logic below, unchanged. Repairing this
+    // defect is not a licence to migrate the state schema, to grant an amnesty to records written
+    // before `command` existed, or to let an unknown ownership word buy a managed green because a
+    // string happened to match. The state is rewritten by `./run.sh setup`, not by its reader.
+    const knownManagedOwnership = ownership === "absent" || ownership === "managed-current" || ownership === "managed-legacy";
+    if (knownManagedOwnership && stateCommand !== undefined) {
+        if (cmd !== stateCommand) {
+            log(`  FAIL: state records '${stateCommand}' as the managed command (ownership=${ownership}), but the effective command is '${cmd}' — the key drifted to something entwurf never wrote.`);
+            hardFail = 1;
+        }
+        else {
+            log(`  ok: effective command is the managed command this install recorded ('${stateCommand}', preimage ownership=${ownership}).`);
+        }
+    }
+    else if (!isBare) {
         if (ownership && ownership !== "user-override") {
             log(`  FAIL: state owns entwurf-bridge (ownership=${ownership}) but the effective command drifted to '${cmd}'.`);
             hardFail = 1;