@junghanacs/entwurf 0.24.0 → 0.25.1

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/herdr-fresh-call.ts

@@ -44,6 +44,7 @@
 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.ts";
 import {
 	buildOmpBootstrapPayload,
@@ -55,11 +56,20 @@ import {
 	TASK_MAX_CHARS,
 } from "./fresh-call-composition.ts";
 
-/** 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"] as const;
+ * 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 };
 export type HerdrFreshCallBackend = (typeof HERDR_FRESH_CALL_BACKENDS)[number];
 
 /** Our backend name → the `--kind` token herdr accepts. `[측정 2026-09-14]` both round-tripped with

package/pi-extensions/lib/herdr-placement.ts

@@ -126,6 +126,17 @@ const OFFICIAL_REPORTS: Readonly<
  * 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/protocol.js

@@ -21,11 +21,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";