@junghanacs/entwurf 0.23.1 → 0.25.0

package/pi-extensions/lib/control-send-receipt.ts

@@ -0,0 +1,108 @@
+/**
+ * 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"] as const;
+
+export type AcceptanceBoundary = (typeof ACCEPTANCE_BOUNDARIES)[number];
+
+/** What a receiver can actually observe about itself. `accepted-unknown-boundary` is a READER's
+ * verdict about an answer it could not classify, so a receiver may never produce it. */
+export type ObservedBoundary = Exclude<AcceptanceBoundary, "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: { idle: boolean; mode: "steer" | "follow_up" }): ObservedBoundary {
+	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: unknown): value is ObservedBoundary {
+	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: unknown): AcceptanceBoundary {
+	if (typeof data !== "object" || data === null) return "accepted-unknown-boundary";
+	const value = (data as { boundary?: unknown }).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: unknown): string | undefined {
+	if (typeof data !== "object" || data === null) return data === undefined ? undefined : `data: ${typeof data}`;
+	const value = (data as { boundary?: unknown }).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/pi-extensions/lib/entwurf-v2-contract-schema.ts

@@ -51,7 +51,7 @@ export const EntwurfV2InputSchema = Type.Object(
 		mode: Type.Optional(
 			StringEnum(ENTWURF_V2_MODES, {
 				description:
-					"delivery mode (steer = interrupt current turn, follow_up = queue) — NOT the ownership axis (F1) nor liveness routing. MEANINGLESS on the meta-mailbox transport (F-mailbox): a mailbox ack is enqueue+doorbell, not a turn injection, so steer/follow_up does not apply when the verdict transport is meta-mailbox.",
+					"delivery mode — NOT the ownership axis (F1) nor liveness routing. 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. MEANINGLESS on the meta-mailbox transport (F-mailbox): a mailbox ack is enqueue+doorbell, not a turn injection, so steer/follow_up does not apply when the verdict transport is meta-mailbox.",
 			}),
 		),
 		wantsReply: Type.Optional(

package/pi-extensions/lib/entwurf-v2-contract.ts

@@ -265,8 +265,12 @@ export type EntwurfV2Transport = (typeof ENTWURF_V2_TRANSPORTS)[number];
 // and a future visible-resume verb would speak them again.
 export const ENTWURF_V2_ACTIONS = ["send"] as const;
 export const ENTWURF_V2_OWNERSHIPS = ["ack-only"] as const;
-// 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/pi-extensions/lib/entwurf-v2-production.ts

@@ -29,6 +29,7 @@
  * claiming "no conflict". The decider's later `inspectSocket` probe is a SEPARATE step.
  */
 
+import { describeUnknownBoundary, parseAcceptanceBoundary } from "./control-send-receipt.ts";
 import {
 	type RpcClientOptions,
 	type RpcCommand,
@@ -318,7 +319,24 @@ export function makeProductionEntwurfV2Deps(opts: ProductionEntwurfV2Opts): Entw
 				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/pi-extensions/lib/entwurf-v2-runner.ts

@@ -28,6 +28,7 @@
  * lets the hand's `decideReleasePolicy` fail loud on a mis-pairing.
  */
 
+import type { AcceptanceBoundary } from "./control-send-receipt.ts";
 import type {
 	DispatchDecision,
 	DispatchInput,
@@ -71,7 +72,15 @@ export interface DispatchExecutorDeps {
  * and it is the ONLY enqueue-side datum carried (never a read timestamp; see
  * `RpcSendResult`). */
 export type ExecutedOutcome =
-	| { transport: "control-socket"; outcome: SendFinalOutcome; rejectReason?: string; messagePath?: string }
+	| {
+			transport: "control-socket";
+			outcome: SendFinalOutcome;
+			rejectReason?: string;
+			messagePath?: string;
+			/** #120 P2: the receiver's acceptance boundary. The SURFACE renders this, not
+			 * `outcome` — that one names the route/release leg, which an operator cannot act on. */
+			boundary?: AcceptanceBoundary;
+	  }
 	| { transport: "meta-mailbox"; success: true; messagePath?: string }
 	// native-push carries `retried` so the surface can note the 1-shot re-probe retry fired.
 	| { transport: "native-push"; success: true; retried: boolean };
@@ -89,6 +98,15 @@ export type EntwurfV2RunResult =
 			receipt: SuccessReceipt;
 			transport: ExecutionPlan["transport"];
 			error: string;
+			/** #120 P2, N1: the ACCEPTANCE the send reached before the release failed. Without it
+			 * the dirty-lock line is the one surface left that answers "what happened to my
+			 * message" with an internal route word. Absent on a `rejected` finalization (nothing
+			 * was accepted) and on the mailbox fallback leg (which carries a file instead). */
+			finalizedBoundary?: AcceptanceBoundary;
+			/** #98 R, same case: the `.msg` a mailbox fallback wrote before the release failed. */
+			finalizedMessagePath?: string;
+			/** The receiver's own refusal text, when the finalization was a `rejected` one. */
+			finalizedRejectReason?: string;
 			/** Present ONLY for the N1 case: the delivery/refusal reached a terminal outcome
 			 * but `releaseLock` then threw (lock dirty). A re-send would double-deliver. */
 			finalizedOutcome?: Exclude<SendFinalOutcome, "failed">;
@@ -129,6 +147,7 @@ export async function executeDispatch(
 						outcome: r.outcome,
 						rejectReason: r.rejectReason,
 						messagePath: r.messagePath,
+						boundary: r.boundary,
 					},
 				};
 			} catch (err) {
@@ -140,6 +159,9 @@ export async function executeDispatch(
 						transport,
 						error: errorMessage(err),
 						finalizedOutcome: err.finalizedOutcome,
+						finalizedBoundary: err.finalizedBoundary,
+						finalizedMessagePath: err.finalizedMessagePath,
+						finalizedRejectReason: err.finalizedRejectReason,
 						releaseFailed: true,
 						retrySafe: false,
 					};

package/pi-extensions/lib/entwurf-v2-send.ts

@@ -32,6 +32,7 @@
  * `releaseLock` throw never MASKS a send failure — the original error wins (5b).
  */
 
+import type { AcceptanceBoundary } from "./control-send-receipt.ts";
 import type { ExecutionPlan } from "./entwurf-v2-decider.ts";
 import type { LockClaim } from "./entwurf-v2-lock.ts";
 import {
@@ -50,6 +51,12 @@ export type MetaMailboxPlan = Extract<ExecutionPlan, { transport: "meta-mailbox"
  * `send-final` outcomes. `fallback-sent` is a REAL final outcome (legacy parity: a
  * re-resolved delivery is not a hidden retry). */
 export type SendFinalOutcome = "sent" | "fallback-sent" | "rejected" | "failed";
+// NOTE (#120 P2): the type above is the ROUTE/RELEASE algebra and is NOT the sender-visible
+// delivery boundary. It answers WHICH LEG carried the bytes — first socket, re-resolved socket,
+// mailbox — which is exactly what the release reducer needs and exactly what an operator cannot
+// act on: `sent` here says a receiver accepted, never what the receiver then did with it. The
+// boundary is a SEPARATE axis (`AcceptanceBoundary`, control-send-receipt.ts) riding beside this
+// one, so neither can overwrite the other.
 
 /** What a single RPC / mailbox enqueue reports. `success:false` is an in-band reject
  * (the receiver answered and refused) — distinct from a thrown connect error.
@@ -66,6 +73,12 @@ export interface RpcSendResult {
 	success: boolean;
 	error?: string;
 	messagePath?: string;
+	/** #120 P2: the receiver's OWN acceptance boundary, already classified by
+	 * `control-send-receipt.ts` at the wire seam. Present on every SUCCESSFUL control-socket
+	 * answer — an answer we could not classify is `accepted-unknown-boundary`, not an absence —
+	 * and absent on the mailbox rail, which has no turn-injection boundary to report and answers
+	 * with a durable file receipt instead. */
+	boundary?: AcceptanceBoundary;
 }
 
 /** The same-lock one-shot re-resolve result (5c-2b implements the resolver; 5c-2a
@@ -116,6 +129,12 @@ export interface ControlSocketSendResult {
 	 * mailbox delivery whose sender gets no per-message identifier — the same letter the
 	 * primary mailbox rail names. */
 	messagePath?: string;
+	/** #120 P2: the acceptance boundary the receiver reported, on EVERY successful
+	 * control-socket leg including the re-resolved one — a `fallback-sent` that dropped it would
+	 * say "delivered" about a message sitting in a volatile queue behind whatever else is in it.
+	 * Absent on the mailbox fallback leg (no turn-injection boundary exists there) and on
+	 * rejected/failed. */
+	boundary?: AcceptanceBoundary;
 }
 
 // A drive step's verdict: the terminal outcome, plus the original error to RETHROW on
@@ -127,6 +146,24 @@ interface SendDrive {
 	rejectReason?: string;
 	/** #98 R receipt from the mailbox fallback leg (see `ControlSocketSendResult`). */
 	messagePath?: string;
+	/** #120 P2 acceptance boundary from a socket leg (see `ControlSocketSendResult`). */
+	boundary?: AcceptanceBoundary;
+}
+
+/**
+ * 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: RpcSendResult): AcceptanceBoundary {
+	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;
 }
 
 /**
@@ -159,7 +196,12 @@ export async function executeControlSocketSend(
 		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. */
@@ -179,7 +221,7 @@ async function driveSend(plan: ControlSocketPlan, lock: LockClaim, deps: Control
 	}
 	// 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);
 }
 
 /**
@@ -224,7 +266,7 @@ async function driveDeadFallback(
 			// 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 };
 			}
@@ -261,14 +303,42 @@ async function driveDeadFallback(
  */
 export class SendDeliveredReleaseFailedError extends Error {
 	readonly finalizedOutcome: Exclude<SendFinalOutcome, "failed">;
+	/** #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. */
+	readonly finalizedBoundary?: AcceptanceBoundary;
+	/** #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. */
+	readonly finalizedMessagePath?: string;
+	/** 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. */
+	readonly finalizedRejectReason?: string;
 	readonly releaseError: unknown;
-	constructor(finalizedOutcome: Exclude<SendFinalOutcome, "failed">, releaseError: unknown) {
+	constructor(
+		finalizedOutcome: Exclude<SendFinalOutcome, "failed">,
+		releaseError: unknown,
+		accepted: { boundary?: AcceptanceBoundary; messagePath?: string; rejectReason?: string } = {},
+	) {
 		const detail = releaseError instanceof Error ? releaseError.message : String(releaseError);
+		// 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: ${finalizedOutcome} delivered but releaseLock failed (lock dirty, do NOT re-send): ${detail}`,
+			`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;
 	}
 }
@@ -294,7 +364,13 @@ function finalizeRelease(policy: ReleasePolicy, deps: ControlSocketSendDeps, loc
 			if (drive.outcome === "failed") 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") throw original;

package/pi-extensions/lib/entwurf-v2-surface.ts

@@ -159,9 +159,35 @@ export function renderEntwurfV2Result(result: EntwurfV2RunResult): EntwurfV2Surf
 				// 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") {
@@ -185,10 +211,23 @@ export function renderEntwurfV2Result(result: EntwurfV2RunResult): EntwurfV2Surf
 		}
 		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 ` +
+						`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/pi-extensions/lib/fresh-call-composition.ts

@@ -54,6 +54,17 @@ export type FreshCallBackend = (typeof FRESH_CALL_BACKENDS)[number];
  * permission dialect: omp's approval layer consults the same minted string (`source-audit.md`).
  */
 export const FRESH_CALL_CALLBACK_TOOL: Record<FreshCallBackend, string> = {
+	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: Record<FreshCallBackend, string> = {
 	pi: "entwurf_v2",
 	"claude-code": "mcp__entwurf-bridge__entwurf_v2",
 	copilot: "entwurf-bridge-entwurf_v2",
@@ -101,8 +112,11 @@ export const FRESH_CALL_PEERS_TOOL: Record<FreshCallBackend, string> = {
  * `[측정, 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
@@ -112,7 +126,7 @@ export const FRESH_CALL_TOOL_LOAD_HINT: Record<FreshCallBackend, readonly string
 	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: [],
@@ -144,22 +158,22 @@ 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: { callerGardenId: string; nonce: string; task: string }): string {
+	void params.callerGardenId;
+	void params.nonce;
 	return JSON.stringify({
 		v: OMP_BOOTSTRAP_VERSION,
-		target: params.callerGardenId,
-		nonce: params.nonce,
 		task: params.task,
 	});
 }
@@ -298,7 +312,11 @@ export function composeBackendArgs(
 		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":
@@ -354,28 +372,44 @@ export function composeFreshCallFraming(params: {
 	 * default: a sibling told nothing about where it is would be told something false by silence. */
 	openingLine: string;
 }): string[] {
-	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),
+		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`,
@@ -393,7 +427,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.",
 	];
 }