@junghanacs/entwurf 0.14.1 → 0.15.0

package/scripts/probe-bridge-command.ts

@@ -0,0 +1,330 @@
+#!/usr/bin/env node
+// probe-bridge-command — does the EFFECTIVE bridge command actually BOOT and serve MCP?
+//
+// WHY THIS EXISTS (#81): every doctor that judged the bridge wiring asked only whether the
+// configured command RESOLVES — `command -v <bare name>` for pi (doctor-pi-provider) and agy
+// (agy-bridge.sh). Resolvability is not bootability, and the gap is not theoretical: on the
+// reference host `~/.local/bin/entwurf-bridge` was a symlink to the canonical pnpm shim, and
+// that shim derives its target from `$0`. Invoked through the relocated link the derived
+// `../global/...` path does not exist, so the launcher exits 127 and the MCP child never boots
+// — while `command -v` kept answering yes and both doctors kept printing ok. The model in a
+// Pi-hosted ACP turn then had no `mcp__entwurf-bridge__*` tool at all, which is a direct
+// violation of #81's minimum core value (explicit Entwurf bridge connectivity).
+//
+// So this leaf asks the only question that carries the claim: run the command, speak MCP to it,
+// and require the entwurf tool surface back. A green here is about the command the harness
+// actually execs — never a recomputed desired one (the same rule meta-bridge-doctor's delivery
+// self-diagnostic already states for the Claude lane).
+//
+// SIDE EFFECTS: none on operator state. Only `initialize` + `tools/list` are sent — never a
+// `tools/call` — so no lock is taken, no record is written, and no message is delivered. The
+// child is killed as soon as the frame arrives or the deadline passes. This is what makes the
+// probe affordable inside a doctor an operator runs repeatedly.
+//
+// USAGE
+//   library:  const r = await probeBridgeCommand({ command, args });   // doctor-pi-provider.ts
+//   CLI:      node probe-bridge-command.ts <command> [args...]
+//             node probe-bridge-command.ts --invocation-json '{"command":"…","args":[],"env":{}}'
+//             exit 0 = booted and served the entwurf tool surface; 1 = did not (reason on stdout).
+import { spawn } from "node:child_process";
+import { basename } from "node:path";
+
+/** Why a probe failed. Each value is a DISTINCT operator situation, never a generic "broken". */
+export type BridgeProbeReason =
+	| "ok"
+	| "spawn-failed" // the command could not be executed at all (ENOENT / EACCES)
+	| "exited-before-tools-list" // it ran and DIED — the relocated-shim 127 class lands here
+	| "initialize-failed" // it did not complete the MCP initialize handshake before tools/list
+	| "timeout" // it stayed up but never answered — a hung/wrong binary
+	| "no-tools-array" // it answered id:2 without result.tools — not an MCP server
+	| "tool-set-mismatch"; // an MCP server, but not THIS bridge (foreign binary, or a stale build)
+
+export interface BridgeProbeResult {
+	ok: boolean;
+	reason: BridgeProbeReason;
+	/** One line, safe to print in a doctor verdict. Carries rc/signal/stderr head when relevant. */
+	detail: string;
+}
+
+export interface BridgeProbeOptions {
+	command: string;
+	args?: string[];
+	env?: NodeJS.ProcessEnv;
+	timeoutMs?: number;
+}
+
+// The EXACT public verb set of the current bridge. Identity is the whole set, not one member:
+// the #81 symptom was a session whose schema lacked `entwurf_self` specifically, and a probe that
+// only looked for `entwurf_v2` would have called that host healthy. Exactness also catches the
+// other direction — a STALE build still serving a retired verb, or a foreign binary that happens
+// to expose an `entwurf_v2`. check-entwurf-bridge-boot binds this list to the real runtime
+// tools/list, so a verb added or retired without updating it turns that gate red.
+export const EXPECTED_TOOLS = [
+	"entwurf_v2",
+	"entwurf_self",
+	"entwurf_peers",
+	"entwurf_inbox_read",
+	"entwurf_register_native",
+	"entwurf_fresh_call",
+	"entwurf_resume_call",
+] as const;
+const DEFAULT_TIMEOUT_MS = 10_000;
+/** How long a probed child gets to die politely before it is killed outright. */
+const CLEANUP_GRACE_MS = 500;
+
+/** Collapse captured stderr into one printable line — a doctor verdict must stay one line. */
+function head(text: string, limit = 200): string {
+	const flat = text.replace(/\s+/g, " ").trim();
+	return flat.length > limit ? `${flat.slice(0, limit)}…` : flat;
+}
+
+export function probeBridgeCommand(opts: BridgeProbeOptions): Promise<BridgeProbeResult> {
+	const { command, args = [], env, timeoutMs = DEFAULT_TIMEOUT_MS } = opts;
+	return new Promise((resolve) => {
+		// No shell: a bare name goes through the normal PATH lookup the harness itself does,
+		// and an argument can never be reinterpreted as shell syntax.
+		const child = spawn(command, args, { stdio: ["pipe", "pipe", "pipe"], env });
+		// `write()` reports a synchronous closed pipe by throwing, but a launcher that dies on exec
+		// closes stdin under us and the resulting EPIPE arrives ASYNCHRONOUSLY, as an 'error' event on
+		// the stream. Unlistened, Node turns that into an uncaught exception, so the probe dies
+		// printing its own stack trace INSTEAD of the launcher's stderr: precisely the diagnosis #81
+		// exists to surface, destroyed in the one cell that needs it. The window is real, not
+		// theoretical — under CPU contention the child can exec, write its stderr and exit between
+		// uv_spawn and our first write, which is how CI saw a doctor verdict with no launcher stderr
+		// in it. The `close` handler owns the verdict for that child (with captured stderr), so this
+		// listener is installed before anything can write and stays deliberately silent — one reason
+		// per failure, never an unhandled probe crash.
+		child.stdin.on("error", () => {});
+		let stdoutPending = "";
+		let stderr = "";
+		let settled = false;
+		let initialized = false;
+		let exited: { code: number | null; signal: NodeJS.Signals | null } | undefined;
+		let stderrEnded = false;
+
+		// This probe deliberately runs whatever command the operator configured — including a
+		// foreign or broken one — so it owns closing what it opened. Escalate SIGTERM → SIGKILL
+		// once, bounded: cleanup for THIS child, not a supervisor (no retries, no watching, no
+		// process-tree walking).
+		//
+		// The reap is AWAITED before the result resolves, and that ordering is load-bearing: the
+		// callers are doctors that print a verdict and `process.exit()` immediately, which tears
+		// down any still-pending timer. A fire-and-forget SIGTERM plus a deferred SIGKILL would
+		// therefore leave a TERM-ignoring launcher running after the doctor is gone — the probe
+		// would leak exactly the kind of broken process it exists to detect.
+		const reap = (): Promise<void> =>
+			new Promise((finished) => {
+				if (child.exitCode !== null || child.signalCode !== null) return finished();
+				let reaped = false;
+				let hard: ReturnType<typeof setTimeout> | undefined;
+				const finish = (): void => {
+					if (reaped) return;
+					reaped = true;
+					if (hard) clearTimeout(hard);
+					finished();
+				};
+				child.once("close", finish);
+				try {
+					child.kill("SIGTERM");
+				} catch {
+					return finish(); // already gone
+				}
+				hard = setTimeout(() => {
+					try {
+						child.kill("SIGKILL");
+					} catch {}
+					// SIGKILL cannot be trapped, so `close` follows. The outer bound exists only so a
+					// child already reaped by someone else can never hang this promise forever.
+					setTimeout(finish, CLEANUP_GRACE_MS);
+				}, CLEANUP_GRACE_MS);
+			});
+
+		const done = (reason: BridgeProbeReason, detail: string): void => {
+			if (settled) return;
+			settled = true;
+			clearTimeout(timer);
+			void reap().then(() => resolve({ ok: reason === "ok", reason, detail }));
+		};
+
+		const timer = setTimeout(() => {
+			const waitingFor = initialized ? "tools/list" : "initialize";
+			done(
+				"timeout",
+				`'${command}' stayed up but never answered ${waitingFor} within ${timeoutMs}ms` +
+					(stderr.trim() ? ` — stderr: ${head(stderr)}` : ""),
+			);
+		}, timeoutMs);
+
+		child.on("error", (err) => {
+			done("spawn-failed", `'${command}' could not be executed: ${String(err)}`);
+		});
+
+		// `ChildProcess` close is normally after the stdio pipes close, but under nested shell
+		// capture that ordering has raced on this host. Do not mint a no-stderr diagnosis until the
+		// stderr reader ended: the launcher's own final diagnostic is part of the operator verdict.
+		const reportExited = (): void => {
+			if (!exited || !stderrEnded) return;
+			// Reaching here un-settled means the process died before answering id:2. This is the
+			// cell the relocated pnpm shim lands in (exit 127), and the stderr head is what tells
+			// the operator WHICH launcher hop broke.
+			done(
+				"exited-before-tools-list",
+				`'${command}' exited before answering tools/list (code=${exited.code} signal=${String(exited.signal)})` +
+					(stderr.trim() ? ` — stderr: ${head(stderr)}` : " — no stderr"),
+			);
+		};
+		child.on("close", (code, signal) => {
+			exited = { code, signal };
+			reportExited();
+		});
+
+		child.stderr.on("data", (d) => {
+			stderr += String(d);
+		});
+		child.stderr.on("end", () => {
+			stderrEnded = true;
+			reportExited();
+		});
+		child.stdout.on("data", (d) => {
+			const chunk = String(d);
+			stdoutPending += chunk;
+			if (settled) return;
+			// MCP frames are newline-delimited JSON-RPC. Consume each complete frame exactly once:
+			// replaying the accumulated id:1 response on a later data event would send a second
+			// tools/list before the first reply and stop being a sequential handshake.
+			const frames = stdoutPending.split("\n");
+			stdoutPending = frames.pop() ?? "";
+			for (const line of frames) {
+				const trimmed = line.trim();
+				if (!trimmed) continue;
+				let msg: {
+					id?: unknown;
+					error?: unknown;
+					result?: { protocolVersion?: unknown; capabilities?: unknown; serverInfo?: unknown; tools?: unknown };
+				};
+				try {
+					msg = JSON.parse(trimmed);
+				} catch {
+					continue;
+				}
+				if (msg?.id === 1) {
+					const result = msg.result;
+					const valid =
+						msg.error === undefined &&
+						result?.protocolVersion === "2024-11-05" &&
+						typeof result.capabilities === "object" &&
+						result.capabilities !== null &&
+						typeof result.serverInfo === "object" &&
+						result.serverInfo !== null;
+					if (!valid) {
+						done("initialize-failed", `'${command}' returned an invalid MCP initialize response`);
+						return;
+					}
+					initialized = true;
+					sendReadyFrames();
+					continue;
+				}
+				if (msg?.id !== 2) continue;
+				if (!initialized) {
+					done("initialize-failed", `'${command}' answered tools/list before MCP initialize completed`);
+					return;
+				}
+				const tools = msg?.result?.tools;
+				if (!Array.isArray(tools)) {
+					done("no-tools-array", `'${command}' answered tools/list without result.tools — not an MCP server`);
+					return;
+				}
+				const names = tools
+					.map((t) => (t as { name?: unknown })?.name)
+					.filter((n): n is string => typeof n === "string");
+				const served = new Set(names);
+				const missing = EXPECTED_TOOLS.filter((t) => !served.has(t));
+				const unexpected = names.filter((n) => !(EXPECTED_TOOLS as readonly string[]).includes(n));
+				if (missing.length > 0 || unexpected.length > 0) {
+					// Name BOTH directions: a missing verb is the #81 symptom (the model had no
+					// entwurf_self), an unexpected one means this is not the bridge we ship.
+					const parts: string[] = [];
+					if (missing.length > 0) parts.push(`missing ${missing.join(", ")}`);
+					if (unexpected.length > 0) parts.push(`unexpected ${unexpected.join(", ")}`);
+					done(
+						"tool-set-mismatch",
+						`'${command}' is an MCP server but does not serve this bridge's verb set — ${parts.join("; ")} (served: ${names.join(", ") || "none"})`,
+					);
+					return;
+				}
+				done("ok", `'${command}' booted and served the exact entwurf verb set (${EXPECTED_TOOLS.length} tools)`);
+				return;
+			}
+		});
+
+		const send = (obj: unknown): void => {
+			try {
+				child.stdin.write(`${JSON.stringify(obj)}\n`);
+			} catch {
+				// Synchronous throws (a destroyed stream) land here; async EPIPE lands on the
+				// listener above. Both are the same verdict-free silence.
+			}
+		};
+		const sendReadyFrames = (): void => {
+			send({ jsonrpc: "2.0", method: "notifications/initialized" });
+			send({ jsonrpc: "2.0", id: 2, method: "tools/list" });
+		};
+		send({
+			jsonrpc: "2.0",
+			id: 1,
+			method: "initialize",
+			params: {
+				protocolVersion: "2024-11-05",
+				capabilities: {},
+				clientInfo: { name: "probe-bridge-command", version: "0" },
+			},
+		});
+	});
+}
+
+// CLI entrypoint. Kept argv-driven (no env carrier) so `./run.sh probe-bridge-command entwurf-bridge`
+// asks about exactly the name an operator typed, and a doctor can shell out to the same verdict.
+// Match the BASENAME exactly. A suffix test would also fire for `check-probe-bridge-command.ts`,
+// which imports this module — the CLI arm would then hijack that gate's argv and exit 2.
+if (process.argv[1] && /^probe-bridge-command\.(ts|js)$/.test(basename(process.argv[1]))) {
+	const argv = process.argv.slice(2);
+	let options: BridgeProbeOptions;
+	if (argv[0] === "--invocation-json") {
+		let raw: unknown;
+		try {
+			raw = JSON.parse(argv[1] ?? "");
+		} catch {
+			console.error("probe-bridge-command: --invocation-json must be valid JSON");
+			process.exit(2);
+		}
+		const obj = raw as { command?: unknown; args?: unknown; env?: unknown };
+		if (
+			typeof obj?.command !== "string" ||
+			!obj.command ||
+			!Array.isArray(obj.args) ||
+			!obj.args.every((arg) => typeof arg === "string") ||
+			typeof obj.env !== "object" ||
+			obj.env === null ||
+			Array.isArray(obj.env) ||
+			!Object.values(obj.env).every((value) => typeof value === "string")
+		) {
+			console.error("probe-bridge-command: invocation JSON requires string command, string[] args, string-map env");
+			process.exit(2);
+		}
+		options = {
+			command: obj.command,
+			args: obj.args as string[],
+			env: { ...process.env, ...(obj.env as Record<string, string>) },
+		};
+	} else {
+		const [command, ...args] = argv;
+		if (!command) {
+			console.error("usage: probe-bridge-command <command> [args...]");
+			process.exit(2);
+		}
+		options = { command, args };
+	}
+	const result = await probeBridgeCommand(options);
+	console.log(`[probe-bridge-command] ${result.reason}: ${result.detail}`);
+	process.exit(result.ok ? 0 : 1);
+}

package/scripts/raw-async-delivery/README.md

@@ -1,4 +1,4 @@
-# raw-async-delivery — RAW async message delivery into LIVE Claude Code / agy / Codex sessions
+# raw-async-delivery — RAW async message delivery into LIVE Claude Code / agy / Codex / Copilot sessions
 
 Goal: deliver an async message INTO an already-running **subscription** session,
 free, with no `claude -p` / backend CLI prompt spawn — and in particular wake an
@@ -13,6 +13,26 @@ Codex is split by launch surface:
   WebSocket-over-UDS wakes the live thread — **demonstrated, no managed
   standalone, no cloud**.
 
+Copilot is no longer blocked on transport, and the probe below is no longer the
+product — it is the receipt the product was built on:
+
+- **Copilot CLI 1.0.80 extension**: the CLI forks a first-party extension and
+  speaks JSON-RPC over that child's **stdio**, so `fs.watch` -> `session.send()`
+  wakes the idle TUI with **no network listener or token-authentication axis**. Idle wake
+  and exact-marker attribution were demonstrated; addressed isolation was observed but its
+  decisive control log was not preserved (2026-08-23, one Linux workstation). It needs the experimental
+  `COPILOT_CLI_ENABLED_FEATURE_FLAGS=EXTENSIONS` flag at launch. The older
+  hidden `--ui-server` loopback probe is retired — it found the capability
+  through a door that could not pass admission. Undocumented
+  `~/.copilot/run/ws.*` is still not a rail.
+- **The MANAGED receiver now lives at `pi/copilot-receive/entwurf-receive/`** and is
+  installed with `run.sh install-copilot-receive` (#82 RAIL 5). Read it before reusing
+  anything here, because it deliberately differs on three points: it binds to the V3
+  record instead of publishing its own `ready.json`; its receiver marker is owned by the
+  extension pid, so a crash retires it; and it **announces** the inbox rather than
+  sending the body, leaving the drain (and the read-receipt) to `entwurf_inbox_read`.
+  The files below stay as the measurement — do not develop the product in them.
+
 ## TL;DR — three reception paths, ranked
 
 | Path | Self-arms idle watch? | Portable / drop-in | Verdict |
@@ -82,6 +102,9 @@ do not ship that. Proven: deliver to A's sessionId → A wakes (FileChanged), B'
 - `raw-agy-send.sh <conv_id> …` — agy parity: PUSH into a live Antigravity session (LS gRPC)
 - `raw-codex-ws-turn-start.py <sock> <thread_id> …` — Codex parity (no managed standalone, no cloud): PUSH `turn/start` over WebSocket-over-UDS into a bare `app-server --listen` socket
 - `codex-local-appserver.sh [sock]` — start a bare local app-server so plain `codex` auto-attaches and becomes addressable
+- `copilot-enqueue-addressed.sh <session_id> …` — Copilot raw sender: write `.msg` + poke one session's signal; refuses a missing marker, but deliberately does not claim production stale-receiver safety
+- `copilot-extension-receive/extension.mjs` — Copilot reception unit: a first-party CLI extension that arms the per-session mailbox and calls `session.send()` (stdio JSON-RPC; no port, no token)
+- `copilot-ui-server-probe.mjs` — RETIRED rail, kept as history; the hidden `--ui-server` loopback path whose authentication could not be established
 
 ### Reproduction drivers
 - `repro-plugin-idle-wake.sh` — single-session smoke.
@@ -244,6 +267,170 @@ send-message-v2` spins a fresh thread, not the live one.
 4. **Unix-socket transport is WebSocket** (tokio-tungstenite), not newline JSON-RPC,
    and requires **no auth token** on the UDS. A plain WS client suffices.
 
+## Copilot CLI delivery status (1.0.80) — idle wake DEMONSTRATED on the extension rail
+
+Copilot is a GitHub **harness** (issues, PR, CI, model `auto`, mode `autopilot`,
+remote/delegate), not a second GPT provider next to pi. This makes a native lane
+product-distinct from the declined Codex lane: Copilot can own GitHub work while
+implementation checkpoints arrive from another garden id. That split is operator
+etiquette plus dispatch, not a substrate role system.
+
+The cost premise must stay honest. Copilot reports AI Credits and a monthly
+premium-interaction entitlement; model `auto` chooses a path within that budget.
+The reason to use it is GitHub specialization and auto routing, not an unlimited
+subscription claim. Model `auto` and mode `autopilot` are separate axes.
+
+### The rail: a first-party CLI extension, stdio only
+
+`copilot-extension-receive/extension.mjs` + `copilot-enqueue-addressed.sh`.
+
+The CLI forks an extension as its own child and speaks JSON-RPC over that
+child's stdio. `joinSession()` attaches it to the foreground session; from
+there `session.send({mode:"enqueue"})` injects a user message. So the whole
+delivery path is:
+
+```
+external file write  ->  fs.watch in the extension  ->  session.send()  ->  the idle session takes a turn
+```
+
+`fs.watch` -> `session.send()` is not a mechanism found by inspection: the
+bundled SDK documents it (`copilot-sdk/docs/examples.md`, "Detecting when the
+plan file is created or edited"). The SDK also ships *inside* the CLI package
+(`<platform-pkg>/copilot-sdk/`) and is injected into extension children by
+`preloads/extension_bootstrap.mjs`, so nothing has to be installed and the SDK
+version cannot drift from the CLI.
+
+**This is why the rail clears the network-boundary bar the old one could not.**
+The `--ui-server` probe was refused because its loopback RPC authentication was
+not established. An extension has no port, token, or listener, so that network
+authentication axis does not exist. Product admission must instead certify the
+installed extension's provenance and the CLI-owned parent/child lifecycle; the
+fork is the transport boundary, not proof that every permission, liveness, and
+integrity obligation is already closed.
+
+### Launch contract
+
+Extensions sit behind an experimental feature flag. Without it the CLI never
+scans for extensions and the receiver is inert **with no error at all** —
+budget for that when a receiver appears not to arm:
+
+```bash
+COPILOT_CLI_ENABLED_FEATURE_FLAGS=EXTENSIONS copilot --model auto
+```
+
+`--experimental` is NOT required (measured: a session launched with the env var
+alone armed its receiver). Discovery scopes are `user`
+(`~/.copilot/extensions/`), `plugin`, `session`, and — interactive mode only —
+`project` (`.github/extensions/`). Prompt mode (`-p`) drops `project` unless
+`GITHUB_COPILOT_PROMPT_MODE_EXTENSIONS=true`. The `plugin` scope matters most
+here: the existing entwurf Copilot plugin is the candidate install scope for
+this receiver, so product design need not start from a per-repository
+`.github/extensions/` directory.
+
+### Reproduce
+
+```bash
+mkdir -p /tmp/cop-lab/.github/extensions/entwurf-mailbox
+cp copilot-extension-receive/extension.mjs /tmp/cop-lab/.github/extensions/entwurf-mailbox/
+
+# terminal A: a visible session that arms its own receiver
+cd /tmp/cop-lab
+export COPILOT_MAILBOX_ROOT=/tmp/cop-lab/mbx COPILOT_CLI_ENABLED_FEATURE_FLAGS=EXTENSIONS
+copilot --model auto --allow-all-tools     # accept folder trust
+
+# terminal B: find the armed receiver, then wake it with zero typing
+ls /tmp/cop-lab/mbx/*/ready.json
+COPILOT_MAILBOX_ROOT=/tmp/cop-lab/mbx \
+  ./copilot-enqueue-addressed.sh <session_id> "Reply with exactly PING and nothing else."
+```
+
+### Measured — 2026-08-23, CLI 1.0.80, model `auto`, one Linux workstation (oracle, arm64)
+
+Evidence level **L4 direct-native, one host**. The receiver log lines that still
+travel are pasted here. Scratch was cleaned before the second-session control and
+second-turn lines were copied, so those two observations are explicitly downgraded
+below rather than being laundered into durable receipts:
+
+```text
+02:19:33.996 ARMED sessionId=4fc16d8d-473d-4258-a1fd-f99d3cb375e9
+02:20:03.388 DELIVER (signal) 1787451603.msg bytes=96
+02:20:03.422 SENT 1787451603.msg
+02:20:06.141 EVENT user.message  {"content":"...Reply with exactly ENTWURF-WAKE-1787451603..."}
+02:20:06.492 EVENT assistant.turn_start {"turnId":"0"}
+02:20:09.935 EVENT assistant.message {"turnId":"0","content":"ENTWURF-WAKE-1787451603"}
+02:20:10.024 EVENT session.idle {}
+```
+
+- **Idle wake: PASS.** The session had never been typed into — an empty timeline,
+  already past any turn boundary. An external file write started a turn. ~2.7 s
+  poke -> `user.message`, ~6.5 s poke -> reply. The visible TUI showed the prompt
+  and the answer.
+- **Attribution: PASS.** A unique per-run marker went in and came back exactly,
+  on one `assistant.turn_start`/`assistant.message` pair.
+- **Addressed routing: reported, receipt not preserved.** The measuring Opus
+  reported that a second armed process B stayed at one `ARMED` line across two
+  deliveries to A, with no `user.message` or `assistant.*` event. The decisive B
+  line and A's second delivery were not copied before scratch cleanup, so this is
+  a lead for the admission rerun, not durable D3 acceptance.
+- **Continuity: one turn demonstrated.** The pasted chain shows one joined
+  session taking the marker turn and replying; no `-p` process was spawned. A
+  second same-session turn was reported but its lines were not preserved, so no
+  stronger repeatability claim crosses from this checkpoint.
+
+### Not proven — do not describe these as working
+
+- **Active-turn delivery.** Every measured send landed on an idle session.
+  `mode:"enqueue"` vs `"immediate"` against a busy turn is untested.
+- **Multi-session inside ONE CLI process.** A and B were separate `copilot`
+  processes. Whether a *background* session inside one process (sidebar tabs)
+  can be woken while another holds the foreground is untested, and
+  `joinSession()` attaching to "the foreground session" is the reason to doubt it.
+- **`/clear` and foreground replacement.** The docs say extensions reload there;
+  re-arming was not measured. `[문서]`, not `[측정]`.
+- **Flag durability.** `EXTENSIONS` is an experimental flag with
+  `experimental`/`staff-or-experimental` availability. It can move or be
+  withdrawn between CLI releases; re-verify on upgrade. A flagged surface is an
+  admission question for a managed lane even when the transport is sound.
+- **Permission ownership, crash and ordering behavior, delivery under load.**
+
+That fence has since been walked, not deleted: `backend:"copilot"` receive capability
+IS now real (`wakeMode: self-fetch` plus a record-bound receiver marker, #82 RAIL 5),
+and it arrived through the managed unit with its own installer, doctor, gate and
+mutants — not by widening anything in this directory. `FRESH_CALL_BACKENDS` now
+includes `copilot` (#82 RAIL 9); that launch path lives in `mux-fresh-call`, not here.
+This probe still does not open a sibling. Waking an already-running Copilot and
+opening a new one remain different capabilities.
+The registry's receive grade moved off D0 later, and NOT because of this probe: a managed
+LIVE wake was observed on 2026-08-23 (garden `20260823T181316-d9f6ba`, CLI 1.0.80,
+doorbell→`lastReadAt` 09:23:41.235Z→09:23:56.480Z) and that is what makes the shipped lane
+D6, with D7 partial and D3 pending. This probe's receipt remains what it always was —
+evidence about the MECHANISM, not about the shipped lane. Keep the two apart when citing
+either.
+
+### Retired: the hidden `--ui-server` probe (kept for the lesson)
+
+The 2026-08-19 probe reached the TUI through `copilot --ui-server --port 43817`
+and the separately-installed SDK, and it did demonstrate an idle enqueue. It was
+refused admission because the launch flag is hidden from `copilot --help` and its
+loopback RPC authentication could not be established: an unauthenticated client
+connected, while setting `COPILOT_CONNECTION_TOKEN` on the server made a
+token-bearing client fail with `AUTHENTICATION_NOT_CONFIGURED`.
+
+The lesson is not "that probe was wrong". It found a real capability through the
+wrong door, and then the door — not the capability — was what failed admission.
+The bundled extension door was in the same package the whole time: the SDK that
+this probe installed from npm also ships inside the CLI, with an `extension.mjs` contract and
+docs beside it. `copilot-ui-server-probe.mjs` remains in this tree as that history.
+Do not revive `--ui-server` as a rail; use the extension.
+
+Also still true, and still out of bounds: hooks have no `FileChanged` /
+`watchPaths` / `asyncRewake`, so the Claude mailbox hook mechanism cannot be
+copied; the shell command-hook `sessionStart` input carries no `sessionId`
+(the receiver publishes its own `ready.json` instead of scraping for one);
+`--acp` is a pi-host child path and `--remote` is GitHub web/mobile steering,
+neither of which is a local `entwurf_v2` API; and undocumented
+`~/.copilot/run/ws.*` is not a rail.
+
 ## Live SSOT for "is the target session alive?"
 
 - Claude Code: `~/.claude/sessions/<pid>.json` (pid, sessionId, cwd, status). NOT
@@ -256,3 +443,18 @@ send-message-v2` spins a fresh thread, not the live one.
   `$HOME/.codex/app-server-control/app-server-control.sock` (or any owned 0700
   socket via `codex app-server --listen unix://PATH`) is the delivery surface.
   threadId comes from the newest rollout's `session_meta.id`.
+- Copilot raw probe: `<COPILOT_MAILBOX_ROOT>/<session_id>/ready.json`, written by
+  the receiver extension about itself (sessionId, pid, cwd, armedAt). `[번들]`
+  `preloads/extension_bootstrap.mjs` monitors the CLI parent, but this is a
+  discovery marker for the experiment, **not a production liveness SSOT**: the
+  probe sender checks only that the file exists, so a crashed extension can
+  leave stale state and produce a false enqueue receipt.
+- Copilot PRODUCT: `<pi-agent-dir>/meta-receivers/<gardenId>.json`, written by the
+  managed extension and keyed by the garden id a sender actually targets. Liveness is
+  pid + start-key on the EXTENSION child, so a crashed receiver reads as inactive at the
+  next read — that is what `ready.json` could not do. Parent monitoring never cleaned the
+  probe's marker by itself; the product does not depend on cleanup at all. Nothing
+  scrapes `~/.copilot/session-store.db` or the session-state dirs, and the shell
+  command-hook `sessionStart` input is NOT
+  a source — it carries no `sessionId`. The retired `--ui-server` TCP port was
+  never an identity axis.

package/scripts/raw-async-delivery/copilot-enqueue-addressed.sh

@@ -0,0 +1,35 @@
+#!/usr/bin/env bash
+# Deliver an async message INTO one already-running, IDLE Copilot CLI session.
+#
+# Addressed by sessionId: only the named session's receiver sees the poke, so
+# siblings stay idle. Free — it is a file write plus a continuation of a session
+# that is already running; no `copilot -p` spawn is involved.
+#
+#   ./copilot-enqueue-addressed.sh <session_id> "your async message"
+#
+# The receiving session must be running the copilot-extension-receive extension
+# and must agree on COPILOT_MAILBOX_ROOT. `ready.json` is raw-probe discovery,
+# not production liveness authority: this script does not close stale pid/PID-reuse.
+# Inspect armed candidates with:
+#   ls "${COPILOT_MAILBOX_ROOT:-$HOME/.copilot/mailbox}"/*/ready.json
+set -euo pipefail
+
+root="${COPILOT_MAILBOX_ROOT:-$HOME/.copilot/mailbox}"
+session_id="${1:?usage: copilot-enqueue-addressed.sh <session_id> <message>}"
+shift
+message="${*:?usage: copilot-enqueue-addressed.sh <session_id> <message>}"
+
+box="$root/$session_id"
+# Refuse an address that never armed. A stale marker remains possible in this raw
+# probe; the managed product must add record-backed pid + start-key certification.
+if [[ ! -f "$box/ready.json" ]]; then
+	echo "no receiver marker at $box (no ready.json) — not queued" >&2
+	exit 1
+fi
+
+msg="$box/$(date +%s%N).msg"
+printf '%s\n' "$message" > "$msg"
+# The body lands before the doorbell rings, so the receiver never wakes to an
+# empty box.
+printf 'poke\n' >> "$box/inbox.signal"
+echo "queued-and-poked $msg (raw probe; extension log is the delivery receipt)"