@junghanacs/entwurf 0.23.1 → 0.25.0

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/fresh-call-composition.js

@@ -50,6 +50,16 @@ export const FRESH_CALL_BACKENDS = ["pi", "claude-code", "copilot", "omp", "code
  * permission dialect: omp's approval layer consults the same minted string (`source-audit.md`).
  */
 export const FRESH_CALL_CALLBACK_TOOL = {
+    pi: "entwurf_callback",
+    "claude-code": "mcp__entwurf-bridge__entwurf_callback",
+    copilot: "entwurf-bridge-entwurf_callback",
+    omp: "mcp__entwurf_bridge_entwurf_callback",
+    // Codex's tool process is the operator app-server, not the pane: the no-arg
+    // verb refuses there by name. First action stays the delivery verb with args.
+    codex: "mcp__entwurf_bridge__entwurf_v2",
+};
+/** Where a sibling SENDS the task result. Always the delivery verb, never the birth callback. */
+export const FRESH_CALL_DELIVERY_TOOL = {
     pi: "entwurf_v2",
     "claude-code": "mcp__entwurf-bridge__entwurf_v2",
     copilot: "entwurf-bridge-entwurf_v2",
@@ -95,8 +105,11 @@ export const FRESH_CALL_PEERS_TOOL = {
  * `[측정, n=3, same model]` adding the sentence below produced 3/3 callbacks. It is a FACT about the
  * runtime, in the register the rest of this framing uses since the prohibitions came out: it grants
  * nothing, forbids nothing, and names the one call that turns a listed name into a callable tool.
- * Both tools ride ONE `ToolSearch` select, so the corroboration the framing offers stays reachable
- * for a child that takes the offer.
+ * ALL THREE tools ride ONE `ToolSearch` select — the birth callback, the DELIVERY verb the last
+ * line of the framing names, and the peers listing the corroboration sentence offers. The delivery
+ * verb has to be in the same select or the deferral simply moves from the first action to the last:
+ * a sibling that finishes its task and cannot call `entwurf_v2` is the same production silence,
+ * spent instead of saved.
  *
  * Every other backend gets an EMPTY array, deliberately: pi has no deferred-tool surface, and the
  * other three were never measured to need it. A hint invented for a runtime nobody probed would be
@@ -106,7 +119,7 @@ export const FRESH_CALL_TOOL_LOAD_HINT = {
     pi: [],
     "claude-code": [
         "If ${callbackTool} is not callable yet, the entwurf-bridge server is still connecting or its",
-        'tools are deferred: load them first with ToolSearch("select:${callbackTool},${peersTool}") —',
+        'tools are deferred: load them first with ToolSearch("select:${callbackTool},${deliveryTool},${peersTool}") —',
         "it waits for the server — then call ${callbackTool}.",
     ],
     copilot: [],
@@ -125,21 +138,21 @@ export const FRESH_CALL_TOOL_LOAD_HINT = {
 export const OMP_BOOTSTRAP_FLAG = "entwurf-bootstrap";
 /** Payload grammar version, matched exactly by the decoder. A bump means a stale installed
  * unit, which is the one thing `doctor-omp-bridge` exists to say out loud. */
-export const OMP_BOOTSTRAP_VERSION = 1;
+export const OMP_BOOTSTRAP_VERSION = 2;
 /**
  * The whole of what a fresh omp sibling is launched with.
  *
- * THREE FIELDS, CLOSED. The decoder refuses an unknown key, so this object is the entire
- * contract: who to call back, the nonce that proves it is this call, and the task that is
- * released only after that callback succeeds. There is no command here, no path, no env name
- * and no model — the model is already an explicit argv token, and a second copy of it inside
- * a payload would be a second place for it to disagree with the launch.
+ * TWO FIELDS, CLOSED. Address (target + nonce) rides process env, not this payload — a second
+ * copy here would be a second address axis. The decoder refuses an unknown key, so this object
+ * is the entire remaining contract: the task released after the no-arg callback succeeds.
+ * `callerGardenId` / `nonce` stay on the function so launcher call sites do not grow a second
+ * shape; they are not serialised.
  */
 export function buildOmpBootstrapPayload(params) {
+    void params.callerGardenId;
+    void params.nonce;
     return JSON.stringify({
         v: OMP_BOOTSTRAP_VERSION,
-        target: params.callerGardenId,
-        nonce: params.nonce,
         task: params.task,
     });
 }
@@ -271,7 +284,11 @@ export function composeBackendArgs(backend, composition, model, resolveCodexSock
         case "pi":
             return [composition.prompt, "--entwurf-control", "--model", model];
         case "claude-code":
-            return [composition.prompt, `--allowedTools=${FRESH_CALL_CALLBACK_TOOL["claude-code"]}`, `--model=${model}`];
+            return [
+                composition.prompt,
+                `--allowedTools=${FRESH_CALL_CALLBACK_TOOL["claude-code"]},${FRESH_CALL_DELIVERY_TOOL["claude-code"]}`,
+                `--model=${model}`,
+            ];
         case "copilot":
             return ["copilot", "--interactive", composition.prompt, "--model", model, "--yolo"];
         case "omp":
@@ -319,26 +336,41 @@ export function composeBackendArgs(backend, composition, model, resolveCodexSock
  * corroborate the caller instead of an instruction not to look.
  */
 export function composeFreshCallFraming(params) {
-    const tool = FRESH_CALL_CALLBACK_TOOL[params.backend];
+    const birthTool = FRESH_CALL_CALLBACK_TOOL[params.backend];
+    const deliveryTool = FRESH_CALL_DELIVERY_TOOL[params.backend];
     const peersTool = FRESH_CALL_PEERS_TOOL[params.backend];
     // The hint is a per-backend TEMPLATE so the two tool dialects stay the single source of their
     // own spelling here too — a hint that hard-coded Claude's name would go stale the day a dialect
     // moves, and it would go stale silently, in the one sentence a stuck child depends on.
-    const loadHint = FRESH_CALL_TOOL_LOAD_HINT[params.backend].map((line) => line.replaceAll("${callbackTool}", tool).replaceAll("${peersTool}", peersTool));
+    const loadHint = FRESH_CALL_TOOL_LOAD_HINT[params.backend].map((line) => line
+        .replaceAll("${callbackTool}", birthTool)
+        .replaceAll("${deliveryTool}", deliveryTool)
+        .replaceAll("${peersTool}", peersTool));
     const hintBlock = loadHint.length === 0 ? [] : ["", ...loadHint];
     if (params.openingLine.length === 0) {
         throw new Error("fresh-call composition: openingLine is empty — the rail must state where it placed the sibling");
     }
+    const firstAction = params.backend === "codex"
+        ? [
+            `FIRST ACTION, before reading files or anything else: call ${birthTool} with ` +
+                `target=${params.callerGardenId}, intent=fire-and-forget, wants_reply=false, and ` +
+                `message set to exactly ${params.nonce} — that string alone, nothing added.`,
+            `${params.nonce} is a correlation tag this caller minted for this one launch: it names no`,
+            "secret and grants no access. Sending it is how the caller learns the garden id you were born",
+            "with, which it has no other way to know. Your own record does not carry the caller's address,",
+            "so reporting your identity here does not reach it — that tool call does.",
+            "entwurf_callback is refused on this rail: the tool process is the operator app-server, not this pane.",
+        ]
+        : [
+            `FIRST ACTION, before reading files or anything else: call ${birthTool} with no arguments.`,
+            "That call is how the caller learns the garden id you were born with. There are no",
+            "parameters: a target or message you type would be a second address axis.",
+            "Your own record does not carry the caller's address, so reporting your identity here does not reach it — that tool call does.",
+        ];
     return [
         params.openingLine,
         "",
-        `FIRST ACTION, before reading files or anything else: call ${tool} with ` +
-            `target=${params.callerGardenId}, intent=fire-and-forget, wants_reply=false, and ` +
-            `message set to exactly ${params.nonce} — that string alone, nothing added.`,
-        `${params.nonce} is a correlation tag this caller minted for this one launch: it names no`,
-        "secret and grants no access. Sending it is how the caller learns the garden id you were born",
-        "with, which it has no other way to know. Your own record does not carry the caller's address,",
-        "so reporting your identity here does not reach it — that tool call does.",
+        ...firstAction,
         "",
         `You can corroborate the caller first if you want to: ${peersTool} is a read-only listing of`,
         `this garden's citizens and ${params.callerGardenId} is one of them. That listing is capped, so`,
@@ -356,7 +388,7 @@ export function composeFreshCallFraming(params) {
         // its window is not the delivery. Nothing here watches for completion or sends on the
         // sibling's behalf — this rail launches and lets go (Hard Rule 16, and the reason there is no
         // supervisor anywhere in it).
-        `When the task reaches its requested final result, send that result to the same target with ${tool}.`,
+        `When the task reaches its requested final result, send that result to the same target with ${deliveryTool}.`,
         "Output in this sibling window is not delivered to the caller.",
     ];
 }

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

@@ -43,12 +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
@@ -235,6 +246,7 @@ export function buildHerdrTabCreateArgs(params) {
         "PI_SESSION_ID=",
         "--env",
         "PI_AGENT_ID=",
+        ...callbackEnvAssignments(params.callback).flatMap((assignment) => ["--env", assignment]),
     ];
 }
 /** `agent start <name> --kind <kind> --pane <id> -- <backend argv>`. Everything after `--` is the
@@ -565,6 +577,7 @@ export async function herdrFreshCall(params, run, env, nonce, clock = HERDR_REAL
     const tabRun = await run(buildHerdrTabCreateArgs({
         workspaceId: callerPane.workspaceId,
         ...(cwd === undefined ? {} : { cwd }),
+        callback: { target: callerGardenId, nonce },
     }));
     if (tabRun.status !== 0) {
         // WHETHER ANYTHING EXISTS depends on WHO failed, and the stderr says which. herdr's own
@@ -881,9 +894,10 @@ export function renderHerdrFreshCall(result) {
             `mean the sibling is running, that its first turn ran, or that the task was delivered. The tab and pane ` +
             `coordinates are a view and can change under the sibling — they are not an address and nothing may be ` +
             `dispatched to them.\n` +
-            `The sibling's garden id arrives separately — it calls entwurf_v2 back with the nonce above as its first ` +
-            `action, and the sender envelope of THAT message is the address. Nothing is polling for it; if it never ` +
-            `comes, the pane is visible and can be read directly.`,
+            `The sibling's garden id arrives separately — its first action is the zero-argument callback verb, and ` +
+            `the sender envelope of THAT message is the address. The nonce above is the correlation tag it carries; ` +
+            `the sibling reads it from its own launch env, never from this receipt. Nothing is polling for it; if it ` +
+            `never comes, the pane is visible and can be read directly.`,
         isError: false,
     };
 }

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

@@ -21,7 +21,7 @@
  * THE TWO AXES ARE NOT EQUALLY EXACT, AND THE DIFFERENCE IS NAMED. On the claude axis
  * the reported value IS the key, byte for byte. On the pi axis it is a session FILE
  * PATH, and the key is recovered from that filename by a strict conversion measured on
- * pi 0.85.1 — a VENDOR FLOOR, not a key equality. Calling both "a unique-key join"
+ * pi 0.86.0 — a VENDOR FLOOR, not a key equality. Calling both "a unique-key join"
  * would hide which one can drift when a vendor renames a file. The conversion is
  * deliberately strict at both ends so that drift lands as a missed join, never a wrong
  * one, and a listing that declined to read anything says so (see `declinedReports`).
@@ -65,14 +65,34 @@ const OFFICIAL_REPORTS = {
     "herdr:pi": { agent: "pi", kind: "path", backend: "pi" },
 };
 /**
- * A pi session filename, measured 2026-09-14 on pi 0.85.1:
+ * A pi session filename, measured 2026-09-20 on pi 0.86.0:
  *
- *   2026-09-14T05-17-03-979Z_01a09e58-f06a-70e8-b14a-1f0f0c7f7c7d.jsonl
+ *   2026-09-20T00-35-44-197Z_01a0bc3d-87c4-738e-b391-265c8ba5a1b0.jsonl
  *   └────────── start stamp ─────────┘ └──────── nativeSessionId ────────┘
  *
+ * `[측정 2026-09-20]` that is a REAL file a sandboxed pi 0.86.0 wrote, and its own
+ * `{"type":"session"}` header carries `id: 01a0bc3d-87c4-738e-b391-265c8ba5a1b0` —
+ * the exact string `piNativeSessionIdFromPath` recovers from the name. The layout was
+ * re-measured rather than carried: pi 0.86.0 rewrote session-manager.ts (+269 −141
+ * over v0.85.1), but every line that BUILDS a name is byte-unchanged
+ * (`${fileTimestamp}_${this.sessionId}.jsonl`, session-manager.ts:991/1527/1703); the
+ * 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.85.1, measured 2026-09-14** — whether that layout
+ * pi changed it. **Vendor floor: pi 0.86.0, measured 2026-09-20** — whether that layout
  * is a vendor contract or a convention is NOT measured, so this is the one place in the
  * axis that can drift under us. It is therefore strict on both ends — the name must end
  * in `.jsonl` and the tail after the last `_` must be a well-formed uuid — and a name