@junghanacs/entwurf 0.39.0 → 0.40.0

package/BASELINE.md

@@ -46,8 +46,10 @@ outside the experimental preview (rows below).
 | macOS physical-host probe | shipped, unrun on a Mac | `scripts/raw-macos-measure/` — `/bin/sh`, cells M1–M9, 3.5 s; needs neither entwurf install nor login. Still unmeasured: Darwin foreign-process environ (`ps -Eww`) and whether macOS `python3` is a CommandLineTools stub. |
 | WSL2 Entwurf-only install + zero-token Pi citizen (GitHub Actions `windows-2025` runner, not a physical machine) | shape-only | Experimental, non-voting CI (not read by the release oracle): 2026-10-18, `.github/workflows/wsl2-install-surface.yml` run 39098773010 @ `b03d646` ([#78 receipt](https://github.com/junghan0611/entwurf/issues/78#issuecomment-6245947301)). Guest kernel `6.18.40.1-microsoft-standard-WSL2`, host `wsl --list --verbose` VERSION 2, guest fstype quoted raw as `ext2/ext3`. The run's packed tgz digest is equal across producer, host and guest; guest Node 24.18.1; harness-absent `setup` green with protected auth/harness state unchanged. Pi 1.3.0 (sha512 pinned to the registry integrity) wired by `setup`: one V3 record whose filename is its gid, a gid-keyed control socket with a native connect, `peer-facts` alive; only `get_state` was sent and no `agent_start` was observed. Pi creating an empty `auth.json` is not a login. It certifies no harness rail. Linux-guest runtime evidence only: not native-Windows evidence, and not a substitute for the required Linux CI jobs. |
 | WSL2 delivery, non-pi harnesses, vendor turn, physical user machine | unverified | No receipt. Authentication and model turns were deliberately excluded from the CI cells' scope (not a CI impossibility); non-pi harnesses, delivery, fresh/resume and physical machines are unmeasured. |
-| native Windows experimental preview: Pi citizen + `entwurf_v2` delivery (GitHub Actions `windows-2025` x64 runner, Node 24.18.1, Pi 1.3.0; 0.39.0 candidate, not yet released; release and npm publication pending; the evidence below is the feature-branch CI artifact at `3b65bdc`) | shape-only | Experimental, non-voting CI (not read by the release oracle): 2026-10-18, `.github/workflows/windows-native-preview.yml` run 39123555360 @ `3b65bdc`, with the required `ci.yml` four jobs green at the same SHA (run 39123555224). Build: MSVC (VS 2026, toolset v145, SDK 10.0.26100.0), two builds byte-identical (`entwurf_win.node` sha256 `9837893521ec…`), imports advapi32 + kernel32 with `node.exe` the only delay-load; node-gyp 13.1.0 and the Node headers/`node.lib` pinned. The pack carries exactly the addon and its manifest; npm installed it into a sandboxed consumer prefix; Pi came from a tarball checked against its pinned SRI. Six addon cells PASS (final-component reparse and non-regular refusals on the read handle, no connect through a symlink to a pipe, one-deadline timeout with reclaim, pipe-name stability and loader refusals). B1: two `pi --entwurf-control` citizens, one V3 record each, record-derived pipes alive through the product probe, `peer-facts` alive, graceful exit with both addresses dead afterwards. D1: A's model called `entwurf_v2` toward B's garden id with a nonce; A's receipt `control-socket → sent`, B's model context and B's transcript `entwurf-message` entry from A carry it. The model is an offline pi-ai `fauxProvider`: no vendor turn and no comprehension claim. The transcript fact is the harness's assertion; the raw transcript is not archived. The run used the elevated Administrators owner branch, so user-SID-only privacy is not measured. Pi's `peerDependencies` warning was observed, not waived. Not evidence for any other harness on Windows. |
+| native Windows experimental preview: Pi citizen + `entwurf_v2` delivery (GitHub Actions `windows-2025` x64 runner, Node 24.18.1, Pi 1.3.0; ships in core 0.39.0; the evidence below is the feature-branch CI artifact at `3b65bdc`, and the released tarball's own Windows cells are preview run 39146098592 @ `551402c`) | shape-only | Released tarball: preview run 39146098592 @ `551402c` installed the core 0.39.0 tarball (sha256 `1d5693241b8c…`) and its eight cells (L0, L0c, R1, R2, T1, N1, B1, D1) PASS, with a faux model and no vendor turn. The text that follows is the earlier feature-branch receipt (same addon sha256 `9837893521ec…`, not the release pack). Experimental, non-voting CI (not read by the release oracle): 2026-10-18, `.github/workflows/windows-native-preview.yml` run 39123555360 @ `3b65bdc`, with the required `ci.yml` four jobs green at the same SHA (run 39123555224). Build: MSVC (VS 2026, toolset v145, SDK 10.0.26100.0), two builds byte-identical (`entwurf_win.node` sha256 `9837893521ec…`), imports advapi32 + kernel32 with `node.exe` the only delay-load; node-gyp 13.1.0 and the Node headers/`node.lib` pinned. The pack carries exactly the addon and its manifest; npm installed it into a sandboxed consumer prefix; Pi came from a tarball checked against its pinned SRI. Six addon cells PASS (final-component reparse and non-regular refusals on the read handle, no connect through a symlink to a pipe, one-deadline timeout with reclaim, pipe-name stability and loader refusals). B1: two `pi --entwurf-control` citizens, one V3 record each, record-derived pipes alive through the product probe, `peer-facts` alive, graceful exit with both addresses dead afterwards. D1: A's model called `entwurf_v2` toward B's garden id with a nonce; A's receipt `control-socket → sent`, B's model context and B's transcript `entwurf-message` entry from A carry it. The model is an offline pi-ai `fauxProvider`: no vendor turn and no comprehension claim. The transcript fact is the harness's assertion; the raw transcript is not archived. The run used the elevated Administrators owner branch, so user-SID-only privacy is not measured. Pi's `peerDependencies` warning was observed, not waived. Not evidence for any other harness on Windows. |
 | native Windows: own pre-existing pipe-name birth refusal, record link/rename syscalls, descendant cleanup after a forced kill, cross-user, mixed elevation, remote callers, user-SID-only privacy, physical user machine | unverified | No receipt; the preview cells name these as unmeasured. |
+| Remote pair (#107): one declared pi-durable pair, Linux server ↔ Linux notebook over operator SSH (feature branch, not a release) | one LIVE exchange recorded (L4, one pair, one run) | 2026-10-20, both hosts at branch commit `e632294`; that commit's exact-SHA CI run 39202248407 was green on all four jobs. B's native `entwurf_v2` → one SSH → A `remote-pair-receive` → A mailbox enqueue `2026-10-19T22-19-47-662Z-13c897.msg`; A's one reply → B inbox read at `2026-10-19T22:20:24.837Z`, with the matching nonce `107-live-20261020T071937-B-A-6e42d1`. Before the send, the selected compiled bridge hash, the post-build bridge start and the record/owner/sender joins were checked on both hosts; the user reopened both visible sessions. Receipt: [#107](https://github.com/junghan0611/entwurf/issues/107#issuecomment-6278665895). |
+| Remote pair: OFF target, negative paths over real SSH, other rails, more than one pair, non-Linux hosts, GUI rendering of the received envelope | unverified | No receipt. The deterministic and installed cells (VERIFY) do not stand for these. |
 | native Windows: other harnesses, `setup` and the `.sh` bins, fresh/resume, mux/Herdr/ACP, ARM64, records over 16 MiB, reparse-backed store folders | UNSUPPORTED | Outside the preview's scope by decision; the preview loader refuses an install without the Windows addon by name. |
 
 Notes the table cannot carry without becoming prose again:
@@ -69,8 +71,8 @@ Notes the table cannot carry without becoming prose again:
 - **macOS evidence is split, not a support claim.** The Entwurf-only install surface is
   CERTIFIED (CI) (row above); the harness rails are NOT CERTIFIED — pending
   physical host (rental remains unscheduled). The package-level `os` field stays
-  unrestricted, and native Windows is an experimental preview (0.39.0 candidate, not
-  yet released; release and npm publication pending) with its own named gaps (rows above), not a supported platform.
+  unrestricted, and native Windows is an experimental preview (core 0.39.0) with its own
+  named gaps (rows above), not a supported platform.
 
 **Operator acceptance rule:** on a claimed Claude host, reinstall from the released
 artifact, restart every old Claude process, open a new session, and run the doctor

package/CHANGELOG.md

@@ -4,6 +4,242 @@ All notable changes to this project will be documented here. Format follows [Kee
 
 ## Unreleased
 
+## 0.40.0 - 2026-10-20
+
+The bridge is crossed and the questions are carried forward. A person laid a bridge
+between two machines, and a message sent across it to an existing sibling came back. That
+crossing happened once, at pre-release branch commit `e632294`. This cut carries that
+capability and its open questions, not a new two-host LIVE measurement at its own SHA. It
+does not solve remote trust or remote visibility; the questions it leaves open are listed
+below as questions, not as features.
+
+### Remote pair (#107)
+
+- **One operator-declared pair across two hosts.** An opt-in `entwurf-remote-pair.json`
+  beside each host's meta-record store has exactly four keys: `remoteGardenId`, `ssh` (an
+  existing alias), `localGardenId` and `remotePairFile` (the other host's own file). One
+  file serves both directions. An absent file is off. A symlink, non-regular, unreadable
+  or invalid file is refused. The file is read at every send and receive and never cached.
+  The operator owns the connection between the hosts (a private network such as Tailscale
+  is recommended, not required) and SSH authentication. Entwurf installs, configures,
+  discovers and retries none of it.
+- **Send.** `entwurf_v2` to the declared `remoteGardenId` makes exactly one `ssh -o
+  BatchMode=yes -o ConnectTimeout=10 <alias> entwurf remote-pair-receive --pair <file>`
+  call, with no shell and the claim on stdin. A declared target that also has a local
+  trace is refused as `remote-route-local-conflict`. A sender other than `localGardenId`
+  is refused as `remote-sender-not-declared`. Both refusals make zero SSH calls. An
+  undeclared target takes the unchanged local path. The send ends in one of three ways.
+  The first is the other host's receipt, quoted verbatim: an acceptance, or an error it
+  reported while processing (`remote-reported-error`). The second is its named refusal
+  before any mutation. The third is `remote-indeterminate`. A result is decided only when
+  the exit code and JSON kind agree. There is no retry.
+- **Receive.** `entwurf remote-pair-receive` accepts only its own canonical file path
+  (normalized, not realpath). It refuses a `from` or `target` outside the declared pair
+  before any mailbox mutation and hands a match to that host's existing local `entwurf_v2`
+  dispatch. The compiled twin ships in the tarball
+  (`dist/scripts/remote-pair-receive.js`). The received envelope names the remote origin,
+  marks the sender's cwd as a sender-host path and carries `replyable=false`, with "reply
+  route declared, not probed". This display is proven for the self-fetch mailbox body
+  only. `entwurf_callback` stays local.
+- **Trust and visibility, as built.** The trust model is same-operator SSH account trust.
+  The receiving host checks the declared pair. It does not cryptographically authenticate
+  a citizen, and it says nothing about whether the content deserves trust. The route has
+  no launch, fresh or resume path. For the measured self-fetch pair an OFF citizen is
+  undeliverable, and every other target keeps its own rail's admission. The code does not
+  check that the target's screen is open; owner pids, TTYs and garden-id labels are not
+  visibility. Delivery to an active, armed pi-durable can start a turn at once.
+- **A reported error is not read as non-delivery.** When the other host's dispatch reports
+  an error (exit 4), the sender's first line says that an error was reported, that
+  delivery is not inferred from that line and that nothing was retried, and it quotes the
+  other host's text verbatim. That text includes its own `retry-safe: false` after a
+  possible write. An external source review on #107 raised this before the cut.
+- **Docs.** DELIVERY ("Remote pair (#107)") owns the contract. `docs/setup-clean-host.md`
+  gains the operator steps (§2c) and "Applying new source to a running host": a pi-durable
+  host runs the compiled bridge even from a checkout, and a running bridge keeps the
+  modules it loaded, so neither a pull nor a green setup line shows which bytes are live.
+  `docs/remote-sibling-principles.md` is new; it holds the boundaries kept across hosts
+  and the questions below.
+
+### Questions carried forward
+
+- **Is a connection the same as trust?** Today's boundary is an operator-owned SSH account
+  and one exactly declared pair. How should the reach of an account be told apart from
+  trusting the sibling that sent a message?
+- **Does visibility survive a machine boundary?** Locally, the operator's visible-first
+  policy keeps conversation turns to siblings the user has open; that is a policy, not a
+  technical screen check. Across hosts, the first exchange relied on the user's own
+  confirmation that both sessions were open. What would observe and keep visible-first
+  remotely, without a hidden turn or a watcher?
+- **How much can a sender know?** Acceptance is not a read, and a reply does not tell its
+  sender that the reply was read. How should that uncertainty be shown honestly without
+  retries, a third ACK, read tracking or a conversation manager?
+
+None of these is a hidden backlog item;
+[remote-sibling-principles](./docs/remote-sibling-principles.md) keeps them as open
+questions. Automatic discovery, reconnection, OFF wake, hidden model turns, remote
+callbacks and support for every backend or platform are not claimed.
+
+### Evidence boundary
+
+- **Deterministic and installed.** T1 executor-in and T2 surface-in cells sit beside the
+  behavior: the real bridge over MCP stdio, with a stand-in `ssh` running the other host's
+  real entry under a separate HOME. `./run.sh check-remote-pair-installed --tgz <abs>`
+  (checkout-only) runs T2 against installed bytes and audits module realpaths, with a
+  checkout negative control. Six new mutant lanes (remote-pair display 3, receive 8,
+  roundtrip 5, send 12, transport 4, installed-audit 2): the committed set is now 1034
+  mutants across 79 lanes. `check:vitest` runs `check-remote-pair-installed-audit`.
+- **One real exchange, at `e632294`, not at this release's SHA.** On 2026-10-20 B's native
+  `entwurf_v2` went over one SSH call to A's mailbox
+  (`2026-10-19T22-19-47-662Z-13c897.msg`). A's one reply carried nonce
+  `107-live-20261020T071937-B-A-6e42d1`, and B read it at `2026-10-19T22:20:24.837Z`. The
+  pair was two already-open pi-durable siblings on two Linux hosts, which the user
+  reopened visibly beforehand. Before the send, the selected compiled bridge hash, the
+  bridge start time after the build and the record/owner/sender joins were checked on both
+  hosts. That check first caught one host still on a pre-feature build, so the trial was
+  held until a manual build and visible resume. This is L4 (one pair, one run). It is not
+  a release-gate MUST and was not re-measured at this release's SHA. Unmeasured: an OFF
+  target, negative paths over real SSH, other rails, more than one pair, non-Linux hosts,
+  GUI rendering, and SSH's own known-hosts side effects. Receipt:
+  [#107](https://github.com/junghan0611/entwurf/issues/107#issuecomment-6278665895).
+- Kill-power re-measured at this shipped SHA: none (all 1034 committed claims not re-proved,
+  #144).
+- Earlier-candidate PARTIAL (operator-attested, not this SHA): head 6ac477d944c6 surface
+  974e264f5879 -- `["bash","run.sh","check-tests-beside-behavior"]` 38/38 receipt
+  c8d59ba79b6a
+- Earlier-candidate PARTIAL (operator-attested, not this SHA): head 3afbfb660562 surface
+  bc925701184b -- `["bash","run.sh","check-tests-beside-behavior"]` 37/37 receipt
+  4e324810643d
+- Earlier-candidate PARTIAL (operator-attested, not this SHA): head 3afbfb660562 surface
+  bc925701184b -- `["bash","run.sh","check-remote-pair-installed-audit"]` 2/2 receipt
+  bfa5031abc54
+- **An earlier RED is kept as history.** The `check-tests-beside-behavior` group at the R2
+  candidate (head a7aaac7390d8 surface 07625e040df9, receipt b5d681a291f5) killed 34 of
+  37: three mutants failed type-checking rather than the claim. Their replacements were
+  repaired and the group re-ran on the next candidate. No kill-power was carried over from
+  that run.
+- **Static/LIVE split.** Local `check:full` is not run on this operator host and is not
+  counted as passed. The whole static floor is owed to this prepared SHA's exact push CI.
+  The earlier branch commit `e632294` passed all four jobs in run 39202248407; that is not
+  this SHA. The remote-pair installed gate is owed against this release's own candidate
+  tarball. The installed 11/11 on an earlier manually produced tarball is not this
+  release's evidence.
+- **Local LIVE r1, this release's non-static LIVE: MUST (non-static 23) PASS=23 FAIL=0
+  SKIP=0 UNRUN=0; BEHAVIOR PASS=1 FAIL=0.** It ran once, 09:40:03–09:44:49 KST on
+  2026-10-20, on head `de0bf03` plus this preparation's four metadata files (diff
+  `22d0a8b856ae`), with the candidate fingerprint (`22053b62bc0e`) equal at freeze, before
+  and after. The one-off driver (`15d7fb9dd49f`) ran the release gate's non-static steps
+  in its own order, command, environment and working directory; its 24 step lines equal
+  `release_gate()`'s by kind, name and argv, and that body is byte-identical to 0.39.0's.
+  GLG approved this shape for this cut: test-owned scratch sessions only, including
+  headless model turns and the gates' own close/resume, with no existing user or OFF
+  session as a target
+  ([#107](https://github.com/junghan0611/entwurf/issues/107#issuecomment-6280460022)). The
+  Codex step ran against a test-owned app-server in its own tmux session A (named pane pid
+  with its recorded start ticks, stopped by one TERM afterwards) from gate session S, with
+  the requested tiers `gpt-6-luna` and `openai-codex/gpt-6-luna`; that is the request, as
+  the step's own assertions check it, not a billing or model-identity proof. The compiled
+  bridge those steps spawned was rebuilt once beforehand, with GLG's approval, and matched
+  a private emit of this source 87/87. Receipts on the operator host:
+  `.tmp-verify/release-0.40.0/live-r1/` (`live.log` `4ced6b51ec03`, `steps.SHA256SUMS`
+  `f1b7e7b79d97`, 24 logs). It is not a local `release-gate --cut` PASS: the static step
+  did not run locally.
+- **Still owed before the tag.** The static floor is this prepared SHA's exact push CI
+  (four required jobs). This release is carrier-bearing, so its candidate is the
+  native-Windows preview workflow's pack at the prepared SHA (release skill M3w), accepted
+  by the eight Windows cells and the Linux container, never a local `npm pack`; the
+  remote-pair installed gate runs against that same candidate. VERIFY §3.4 (the strict
+  `doctor-meta-bridge` on an installed 0.40.0 Claude host in a new post-install session)
+  follows the accepted candidate. Tag, GitHub release and npm publication each need their
+  own GO.
+- **agy excluded from this cut.** VERIFY §3.7 (three agy doctors and a same-gid
+  native-push reply in a new operator conversation) is excluded by GLG's explicit decision
+  of 2026-10-20: unmeasured, not a PASS. It is a new decision for this cut only, not the
+  0.39.0 exclusion carried over and not a standing waiver
+  ([#107](https://github.com/junghan0611/entwurf/issues/107#issuecomment-6280460022)).
+- **Host residue after LIVE (P9).** The census counted 1934 directories owned by this
+  operator under `/tmp` after one stale, unused root of this repo's own prefix (16K) was
+  reclaimed, from 1935. The largest groups (`acp-cache-test`, `render-take-test`,
+  `caption-take-test`) do not match the prefixes this repo's gates mint, so their
+  ownership is not certified by that extractor; they were not deleted. One reparented
+  holder of a `/tmp` path is an unrelated editor daemon, untouched. Observation: the
+  memory-containment and chain gates left fresh roots of their own prefixes
+  (`entwurf-memguard-overlay-*`, `entwurf-chain-*`); that is a finding about those gates,
+  not fixed in this cut.
+- **Herdr follows core.** `plugins/herdr/runtime-lock.json` returns from the published npm
+  0.39.0 pin to the closed `herdr-checkout` source for this unpublished candidate, as
+  0.38.1 and 0.39.0 did; the comment is re-dated only. The runtime-bootstrap gate requires
+  an npm-source lock to equal the checkout's package version, so an npm 0.39.0 pin cannot
+  sit beside package 0.40.0. There are no plugin manifest, registry pin or snapshot
+  changes; re-pinning the measured 0.40.0 registry bytes is a separate Herdr snapshot
+  after publication.
+
+## v2026.10.19-herdr.0.39.0 — Herdr Entwurf plugin 0.39.0
+
+A separate Herdr plugin snapshot, not another core release: core package 0.39.0 and its
+`v0.39.0` tag remain unchanged. The operator has published the core to npm.
+
+**Reading guide (2026-10-19).** The `## 0.39.0` section below and the appendix of the
+[v0.39.0 GitHub release](https://github.com/junghan0611/entwurf/releases/tag/v0.39.0) are
+prepare- and cut-time text. The appendix records the tag, VERIFY §3.4 met, and §3.7 (agy)
+excluded for that cut only by the operator's decision, not a PASS. Both still say npm was not
+published. The publish is the later registry fact recorded in this section (`latest` 0.39.0,
+published 2026-10-18T21:24:39Z, registry bytes equal to the accepted candidate). Neither the
+published tarball's CHANGELOG nor the release page is amended by this snapshot.
+
+### Herdr plugin
+
+- **Re-pin the published core 0.39.0 and close the checkout window.**
+  `plugins/herdr/runtime-lock.json` returns from the `herdr-checkout` carrier that core 0.39.0
+  rode to production npm source `@junghanacs/entwurf@0.39.0` with the registry's measured
+  sha512 (`sha512-xTRMQkSi…JY+1A==`). The plugin manifest moves 0.38.0 → 0.39.0; admission
+  remains Herdr >= 0.9.0 and the one-build/one-pane/Linux shape is unchanged. Core 0.38.1 got
+  no Herdr snapshot, so the previous npm pin is 0.38.0.
+- **Pi range unchanged.** The acquired runtime still accepts Pi `>=1.3.0 <1.4`.
+- **Upgrade by acquisition source, not just version.** A settled npm-source 0.38.0 installation
+  can rebind under the plugin README's ownership conditions. A host that installed an
+  intervening `herdr-checkout` candidate must explicitly deactivate by its own absolute runtime
+  path before reinstalling the npm-source snapshot. No operator installation or active session
+  is rewired by this release work.
+
+### Source-specific verification
+
+- Registry metadata reports `latest` 0.39.0 and `repair` 0.12.8-repair.1, 605 files, published
+  2026-10-18T21:24:39Z. The downloaded registry tarball is byte-equal to the preserved accepted
+  core candidate (SHA256 `1d5693241b8cd5fa827869cf15ecbf0048215c7f0b4ebb0422650b6ae2773578`,
+  11254616 bytes); its independently computed sha512 and sha1 equal `dist.integrity` and
+  `dist.shasum`, so core make's Docker consumer of those bytes (`node:24-bookworm`, repoDigest
+  `node@sha256:6dac556d…`) is reused here, not repeated. A sandboxed `pi install` of the
+  registry package resolved its bridge inside the sandbox, recorded the registry URL with that
+  integrity, and listed the curated Claude anchors with `--list-models entwurf`; a sandboxed
+  global npm install of the same package passed its installed `check-bridge`.
+- **The npm runtime swap against the real registry**, by the registry-shipped
+  `scripts/herdr-runtime.mjs` (byte-equal to this checkout's) in sandboxed user roots, 22/22
+  checks. The 0.38.0 runtime was seeded from its own committed lock (`beb5925`); the swap to
+  0.39.0 took one acquisition, the cached tarball's sha512 equals the lock and its sha256 equals
+  both the ready journal's observed digest and the accepted candidate. The `installing` journal
+  carried the 0.38.0 identity as `previousRuntime` and the `runtime-ready` journal carries
+  `null`; when acquisition began the 0.38.0 tree was still at the active address. A manually
+  seeded torn swap (the active tree moved to the backup address with a half candidate in
+  staging; not a killed process) was restored before acquisition and reported `recovered:
+  torn-swap-with-candidate`. An exact re-request acquired nothing and left journal and tree
+  byte-identical, and the owned removal reclaimed cache, runtime and journal. The helper is a
+  leaf that probes no Pi, so these cells certify neither a Pi upgrade nor Herdr's
+  install/update relocation, harness wiring, the installed CLI's deactivate path, a model turn,
+  or recovery from a real kill.
+- **Focused gates on the branch**, with HEAD, index and work surface unchanged across them:
+  `check-herdr-supply` (11 assertions), `check-herdr-plugin` (49),
+  `check-herdr-plugin-profile` (14), `check-herdr-runtime-bootstrap` (31),
+  `check-herdr-activation` (33), `check-herdr-placement` (25), `check-herdr-fresh-call` (45)
+  and `check-gate-manifests` (1000 committed mutants across 73 lanes validated, none executed).
+  `check-herdr-plugin-build` and `check-herdr-sandbox` were not run locally because they run
+  the operator's own herdr; they ride the pushed SHA's FULL floor in CI.
+- Pending, and not claimed here: the pushed SHA's four-job CI and the public-ref
+  install/use/deactivate journey of this npm pin, on Herdr 0.9.5 (the binary
+  `scripts/fixtures/herdr-supply.json` names) with Pi 1.3.0, from the public `main` ref rather
+  than the tag. Earlier npm or checkout-carrier receipts cannot certify these source-specific
+  axes. Those outcomes are recorded in the snapshot's post-push acceptance ledger, not in this
+  frozen text.
+
 ## 0.39.0 - 2026-10-18
 
 ### Native Windows (experimental preview, #78)

package/DELIVERY.md

@@ -571,6 +571,40 @@ same class of capability through the CLI-owned stdio lifecycle. Absence of Claud
 `FileChanged` / `asyncRewake` / `watchPaths` therefore means only that Claude's hook
 mechanism cannot be copied — it never proved Copilot had no vendor wake surface.
 
+### Remote pair (#107): one declared pair across two hosts
+
+This is an opt-in route between two existing citizens on two hosts. Why it keeps these boundaries, and which questions it leaves open, is [remote-sibling-principles](./docs/remote-sibling-principles.md); this section owns the mechanism. It is off unless the operator places a file on each host. The operator owns the connection between the hosts (a private network such as Tailscale is recommended, not required) and owns SSH authentication and authorization. Entwurf installs, configures, discovers and retries none of it. It adds no relay, listener, queue or registry. One SSH process runs per send and then exits.
+
+- **Declaration.** Each host has at most one `entwurf-remote-pair.json`, beside its meta-record store (`remotePairOptInPath()`: the pi agent dir, unless `ENTWURF_META_SESSIONS_DIR` moves the store and the file with it). It has exactly four keys:
+  - `remoteGardenId`.
+  - `ssh`: an existing SSH alias whose characters need no quoting.
+  - `localGardenId`.
+  - `remotePairFile`: the other host's canonical absolute path to its own file.
+
+  One file serves both directions. An absent file means off. A symlink, non-regular, unreadable or invalid file is refused. The file is read at every send and receive and never cached. The sending bridge and the SSH-spawned receive entry must resolve the same root; an override set in only one of those environments moves the file.
+- **Send.** The sending host's `entwurf_v2` reads the file and then decides:
+  - A target other than `remoteGardenId` takes the unchanged local path.
+  - A declared target that also has a local trace on this host (a record in any state, or a control socket) is refused as `remote-route-local-conflict`, with zero SSH.
+  - A sender other than `localGardenId` is refused as `remote-sender-not-declared`, with zero SSH.
+  - Otherwise it spawns one `ssh -o BatchMode=yes -o ConnectTimeout=10 <alias> entwurf remote-pair-receive --pair <remotePairFile>`, with no shell and the claim on stdin.
+- **Receive.** The entry accepts only when `--pair` equals its own canonical file path. Canonical means the normalized expected path, not realpath equivalence: a spelling through a symlinked home alias is refused. That file is the entry's whole scope. It refuses a `from` or `target` outside the declared pair before any mailbox mutation. A match goes to that host's existing local `entwurf_v2` dispatch, so every deliverability rule of the target's rail applies there; the measured pair used the self-fetch mailbox.
+- **Outcomes.** The send ends in one of three outcomes:
+  - the other host's receipt, quoted verbatim (its paths are on the other host). This is either an acceptance or an error the other host reported while processing (`remote-reported-error`, exit 4). That error can follow a write, for example an enqueue whose later step threw and is reported `retry-safe: false`. The sender's header therefore claims neither non-delivery nor safety to resend; the quoted text is the fact;
+  - the other host's named refusal, made before any mutation: a pair mismatch (exit 3) or invalid input (exit 2);
+  - `remote-indeterminate`.
+
+  A result is decided only when the exit code and the JSON kind agree. There is no retry. An unanswered message stays unconfirmed. Acceptance is not a read or a reply. Neither side learns whether its last message was read unless the other side answers, and there is no third ACK.
+- **Display.** The received envelope names the remote origin and route, marks the sender's cwd as a sender-host path, and carries `replyable=false`, with "reply route declared, not probed" stated separately. Display is proven only for the self-fetch mailbox body; control-socket and native-push rendering are not proven. `entwurf_callback` stays local.
+- **Trust.** The model is same-operator SSH account trust. The receiving host checks the declared pair. It does not cryptographically authenticate a citizen, and the same account could claim either declared id.
+- **Visibility.** For the measured self-fetch pair, delivery requires backing records, live owners and armed watches, so an OFF citizen of that rail is undeliverable. Any other target keeps its own rail-specific local admission. The remote route has no launch, fresh or resume path. The code does not check that the target's screen is open: an owner pid, a TTY or a garden-id label is not visibility. Live use addresses only siblings the user has open, and delivery to an active pi-durable can start a turn at once.
+- **SSH side effects.** The transport adds exactly two options, `BatchMode=yes` and `ConnectTimeout=10`. Host-key checking, known-hosts writes and every other SSH policy remain the operator's, as configured. Their side effects on a real exchange were not measured.
+
+Evidence:
+
+- T1 (executor-in) and T2 (surface-in) are deterministic. T2 drives the real bridge over MCP stdio, and a stand-in `ssh` on PATH runs the other host's real entry under a separate HOME. An installed-tarball gate runs the T2 cells against installed bytes.
+- One real exchange is recorded in [#107](https://github.com/junghan0611/entwurf/issues/107#issuecomment-6278665895), at branch commit `e632294` on 2026-10-20. A nonce went B→A→B between two already-open pi-durable siblings on two Linux hosts. That is L4: one pair, one run.
+- Unmeasured: an OFF target, negative paths over real SSH, other rails, more than one pair, and non-Linux hosts.
+
 ## Recording a new claim
 
 For every matrix change, record:

package/README.md

@@ -81,11 +81,10 @@ Detected harness wiring on Darwin can therefore be written while setup stays
 non-green. WSL2: a CI runner (experimental) measured the Entwurf-only install and a
 zero-token Pi citizen; general, physical-machine or harness-parity WSL2 support is **not
 declared**, and delivery, other harnesses and physical machines are unmeasured. Native
-Windows has an **experimental first preview**, a CI-built x64 addon on `main` for the
-0.39.0 candidate (not yet released; release and npm publication pending); the registry's
-0.38.1 has no Windows addon. On a GitHub Actions `windows-2025` x64 runner with Node
-24.18.1 and Pi 1.3.0, a CI-built artifact was installed, wired with `pi install`, birthed
-two Pi citizens and
+Windows has an **experimental first preview**, a CI-built x64 addon that ships in core
+0.39.0 (published to npm); 0.38.1 and earlier carry no Windows addon. On a GitHub Actions
+`windows-2025` x64 runner with Node 24.18.1 and Pi 1.3.0, a CI-built artifact was installed,
+wired with `pi install`, birthed two Pi citizens and
 delivered one garden-id `entwurf_v2` message between them, with an offline scripted model
 and no vendor turn. Every other native-Windows surface (other harnesses, `setup` and the
 `.sh` bins, fresh/resume, mux/Herdr/ACP, physical machines) is **not declared**; the
@@ -198,9 +197,9 @@ pi / pi-durable / Claude Code / Copilot / OMP / Antigravity / Codex
 | Open a new visible sibling | `entwurf_fresh_call {backend, model, task, cwd?}` | Launch receipt only; the sibling's nonce callback envelope supplies its new garden id |
 | Reopen a dormant pi citizen under its own id | `entwurf_resume_call {target}` | Separate LAUNCH and socket OBSERVATION receipts; no turn is run |
 
-**Delivery starts no process.** A live pi receives over its record-addressed Unix
-control socket; an armed self-fetch citizen (Claude Code, Copilot, OMP, pi-durable)
-through its mailbox; a probe-alive native-push citizen (Antigravity, Codex) through
+**Delivery starts no process.** A live pi receives over its record-addressed control
+address (a Unix socket; on the experimental native-Windows Pi preview, a named pipe);
+an armed self-fetch citizen (Claude Code, Copilot, OMP, pi-durable) through its mailbox; a probe-alive native-push citizen (Antigravity, Codex) through
 its native conversation/thread. Dormant pi, undeliverable mailboxes, dead/indeterminate native
 push and record-less sockets reject honestly. Only control-socket dispatch takes
 the per-target lock; the other rails use their own deliverability/probe evidence.
@@ -213,6 +212,8 @@ receipt. `wants_reply` is etiquette, not waiting, polling or ownership; replyabi
 is a live rail fact, not merely a consequence of trusted identity.
 [DELIVERY](./DELIVERY.md#control-socket-acceptance-boundaries-120) owns these distinctions.
 
+**One declared remote pair (opt-in, #107).** The operator places an `entwurf-remote-pair.json` on each of two hosts. Then `entwurf_v2` to the declared remote garden id runs the other host's `entwurf remote-pair-receive` once over the operator's own SSH, and that host checks the pair and dispatches locally. The trust is the same operator's SSH account. It makes one attempt with no retry, and it uses no relay or listener. [DELIVERY](./DELIVERY.md#remote-pair-107-one-declared-pair-across-two-hosts) owns the contract; [setup](./docs/setup-clean-host.md#2c-optional-remote-pair-between-two-hosts-107) covers the operator steps.
+
 **Mux launches; it never delivers.** Inside Herdr, fresh opens a new unfocused tab
 in the caller's workspace, pi/Claude Code only, with no tmux fallback. Outside,
 it opens pi/pi-durable/Claude Code/Copilot/OMP/Codex visibly on the caller's own tmux
@@ -238,7 +239,8 @@ and [Herdr launch](https://github.com/junghan0611/entwurf/blob/main/docs/herdr-l
 
 The pi adapter registers the compiled bridge with Pi's built-in MCP after record
 birth; Pi supervises the MCP child. **MCP is ingress; pi receive remains the
-record-addressed Unix control socket.** Garden identity and dispatch stay Entwurf's.
+record-addressed control address (a Unix socket, or the native-Windows preview's named
+pipe).** Garden identity and dispatch stay Entwurf's.
 Codemode is harness-internal, not another garden citizen.
 
 ## Operation guides

package/VERIFY.md

@@ -209,6 +209,16 @@ that moved out of `scripts/` and into a file beside its subject would otherwise
 
 Do not collapse source, package, fixture, and native-host evidence into one “green.”
 
+**Remote pair (#107).** Each layer of evidence lives in its own place:
+
+- **Deterministic.** The cells sit beside the behavior in `pi-extensions/lib/remote-pair-*.test.ts` and are found by `check-tests-beside-behavior`. T1 is executor-in. T2 is surface-in: the real bridge over MCP stdio, with a stand-in `ssh` on PATH that runs the other host's real `run.sh` under a separate HOME. Both are offline.
+- **Installed bytes.** `./run.sh check-remote-pair-installed --tgz <abs>` is checkout-only and takes a caller-supplied candidate tarball. It installs a sandboxed copy, checks the compiled surface, and runs the T2 cells against the installed subject. It also audits that every module those processes load resolves inside the consumer prefix, with a checkout negative control. Its audit primitive is mutation-qualified as `check-remote-pair-installed-audit` inside `check:vitest`.
+- **Real two-host exchange (T3).** This is opt-in operator LIVE evidence, recorded in [BASELINE](./BASELINE.md) and #107. It is not a release-gate MUST and not a fixture that needs a second machine online. A T1, T2 or installed green does not stand for it, and its record belongs to the commit it ran on; a later SHA does not inherit it. Re-run T3 when any of these change:
+  - the SSH argv or quoting;
+  - the receive entry's layout, stdout or exit codes;
+  - the declaration schema or root resolution;
+  - either host's Node or Pi.
+
 **Native durable contact (#129, #130 carrier).** Three deterministic beside-test/mutant
 coordinates in `check:contracts` split the durable contact by the file that carries each claim's QK
 (#144): a carrier or native-module mutant runs its one file, the rest run four. `check-pi-durable-beside` holds the adapter, the installed
@@ -428,7 +438,7 @@ mailbox with `origin=pi-session`, `replyable=true`).
 
 ### 1.4 Cross-install / cross-backend parity (optional, high-value)
 
-Compare a fresh self-awareness report across axes: (1) same backend, different install path — answer must be path-invariant; (2) same backend, different machine — identical native tool list + MCP server/tool set; (3) different backend, same bridge — same garden capability but **different** native tool surface (a Claude session reporting another backend's native tools is a fail); (4) native pi routing vs ACP-bridged, same model — the native pi citizen reaches the compiled `entwurf-bridge` through Pi's built-in MCP (`mcp__entwurf_bridge__<verb>`, six active tools and two hidden), while the ACP backend reaches that bridge through the explicit `entwurfProvider.mcpServers` projection in its own callable dialect (see §2.1). Compare the actual ingress provenance and backend-native tools, not an assumed absence of MCP on pi; receive to the pi citizen remains its record-addressed Unix control socket. Honest "I cannot tell" hedging is preferable to inventing provenance. This is the current #125 comparison criterion, not a newly measured parity receipt. agy is graded by its native-citizen checklist, not by pretending it has an ACP overlay.
+Compare a fresh self-awareness report across axes: (1) same backend, different install path — answer must be path-invariant; (2) same backend, different machine — identical native tool list + MCP server/tool set; (3) different backend, same bridge — same garden capability but **different** native tool surface (a Claude session reporting another backend's native tools is a fail); (4) native pi routing vs ACP-bridged, same model — the native pi citizen reaches the compiled `entwurf-bridge` through Pi's built-in MCP (`mcp__entwurf_bridge__<verb>`, six active tools and two hidden), while the ACP backend reaches that bridge through the explicit `entwurfProvider.mcpServers` projection in its own callable dialect (see §2.1). Compare the actual ingress provenance and backend-native tools, not an assumed absence of MCP on pi; receive to the pi citizen remains its record-addressed control address (a Unix socket; a named pipe on the experimental native-Windows Pi preview). Honest "I cannot tell" hedging is preferable to inventing provenance. This is the current #125 comparison criterion, not a newly measured parity receipt. agy is graded by its native-citizen checklist, not by pretending it has an ACP overlay.
 
 **Cortex on axis 3.** A cortex session must expose the same garden capability
 while keeping cortex's own native tool surface. Its callable MCP identifier shape is

package/docs/setup-clean-host.md

@@ -19,8 +19,7 @@ evidence split, and its three states must not collapse into "macOS is supported"
   unmeasured Darwin doctor reason is per-process environment DISCOVERY
   (start-key is portable).
 - **UNSUPPORTED** — native Windows `setup` and its harness rails. macOS is never this.
-  An experimental native-Windows Pi preview (0.39.0 candidate, not yet released; release
-  and npm publication pending) exists outside `setup`; see [BASELINE](../BASELINE.md#release-host-baseline).
+  An experimental native-Windows Pi preview (core 0.39.0) exists outside `setup`; see [BASELINE](../BASELINE.md#release-host-baseline).
 
 ## Requirements
 
@@ -244,7 +243,8 @@ message. These are harness tools, not shell subcommands; pi exposes them through
 Pi's built-in MCP as `mcp__entwurf_bridge__<verb>`. The bridge has eight tools;
 pi hides `entwurf_inbox_read` and `entwurf_register_native`, leaving six active.
 Tool-call ingress is MCP; delivery to a pi citizen is still its record-addressed
-Unix control socket. A boot/listing from `check-bridge` is not a model-turn or
+control address (a Unix socket; a named pipe on the experimental native-Windows Pi
+preview). A boot/listing from `check-bridge` is not a model-turn or
 native-rail acceptance.
 
 To inspect the ACP provider from a project-local package instead of a global one:
@@ -449,6 +449,34 @@ The owned source is formatted at upstream width (`biome.json` override, indentWi
 per-file exception. A formatting change to an owned file changes its emitted bytes. So it is
 re-emitted with `--write`, and its generated digest is reviewed like any other carrier change.
 
+## 2c. Optional remote pair between two hosts (#107)
+
+This lets one declared pair of existing citizens on two hosts reach each other over SSH that you already run. [DELIVERY](../DELIVERY.md#remote-pair-107-one-declared-pair-across-two-hosts) owns the contract. The machine boundary is set by a person, and nothing here is automatic.
+
+1. **Connect the hosts yourself.** Use a private network (Tailscale or similar is recommended) and SSH keys and authorization you already trust. From each host, `ssh -o BatchMode=yes <alias> true` must succeed non-interactively, and the other host's non-interactive `command -v entwurf` must resolve to the installation you intend. Entwurf edits no SSH config, key, known-hosts file or network setting. Whatever SSH itself writes under your own policy, such as host-key updates, stays yours.
+2. **Run the accepted bytes on both hosts, in the processes that matter.** See [applying new source to a running host](#applying-new-source-to-a-running-host). A pulled checkout or a green setup line does not, by itself, show what a running bridge loaded.
+3. **Write one file on each host,** at `remotePairOptInPath()`. That is the pi agent dir unless `ENTWURF_META_SESSIONS_DIR` moves the meta-record store. Check that the sending bridge's environment and the SSH receive environment resolve the same path. Use mode `0600` and never overwrite a file you did not inspect:
+
+   ```json
+   {
+     "remoteGardenId": "<the other host's garden id>",
+     "ssh": "<your existing alias for the other host>",
+     "localGardenId": "<this host's garden id that talks to it>",
+     "remotePairFile": "<absolute path of the other host's own file>"
+   }
+   ```
+
+   The two files mirror each other: one host's `remoteGardenId` is the other's `localGardenId`. The other host's `remotePairFile` must spell this path as it is normalized, not through a symlinked alias.
+
+   To check a file, read it with the repository's internal parser from a source checkout. Use the same agent/store-root settings the bridge runs with. This is a read-only dev-clone check: there is no installed operator validation verb, and it performs no send and no model input.
+
+   ```bash
+   node --experimental-strip-types -e 'import("./pi-extensions/lib/remote-pair-send.ts").then(m=>console.log(m.readRemotePairOptIn(m.remotePairOptInPath())))'
+   ```
+
+   Do not validate the configuration by sending a test message.
+4. **Use it only between siblings you have open.** The measured self-fetch pair must be active and armed, and the target rail's own admission still applies. Delivery never starts, resumes or wakes an OFF citizen. To an active, armed one it rings the normal doorbell, which may start a turn at once in the receiving TUI. Remove the file to switch the pair off; there is nothing to stop or reconnect.
+
 ## 3. Optional Claude Code native citizen
 
 This rail is CERTIFIED on Linux; on macOS it is NOT CERTIFIED — pending physical
@@ -1128,6 +1156,17 @@ run `pnpm install` when the lockfile changed and `pnpm run build-bridge` before
 artifact-consuming checks such as `./run.sh check-bridge-delivery`; ignored dist
 may be missing or stale. Installed mode never bootstraps pnpm in `node_modules`.
 
+### Applying new source to a running host
+
+New source on disk is not a fresh runtime. A pi-durable host spawns the compiled bridge `mcp/entwurf-bridge/dist/mcp/entwurf-bridge/src/index.js` even from a checkout (the bootstrap's `PACKAGED_BRIDGE_ENTRY`). Ordinary `start.sh` in a checkout runs the TypeScript source instead. An already-running bridge keeps the modules it loaded. So, for a host that has to run new bridge code:
+
+1. Build once from the checkout (`pnpm run build-bridge`, or its body `bash scripts/with-dist-lock.sh bash scripts/build-bridge.sh` when no package lifecycle should run).
+2. Compare the whole compiled output with the accepted candidate's, as a file-set and hash manifest. A hash of the selected entry alone is not enough: the entry can stay identical while a helper it loads differs. Check the pinned SDK set separately, and that the new process started after the build.
+3. Close the visible session and reopen it with its own native same-id resume.
+4. Confirm `entwurf_self` names the same garden id, and that the receiver/owner join points at the new process, whose bridge child started after the build.
+
+A per-component setup PASS or a `git pull` does not show which bytes a running bridge loaded. On 2026-10-20 one host of the #107 pair still selected a pre-feature dist after a pull and a green setup. The cause was not traced. A hash check caught it before the first message, and a manual build and visible resume fixed it. Entwurf adds no auto-build, reload or watcher for this.
+
 ## 8. Release acceptance versus host acceptance
 
 - `entwurf check-bridge`: installed MCP bytes boot; no backend auth.

package/mcp/entwurf-bridge/dist/mcp/entwurf-bridge/src/index.js

@@ -84,6 +84,9 @@ import { probeNativeSenderAlive, reconcileSenderIdentityClaims, resolveCodexRequ
 import { applyOmpBridgeChildRootPolicy, defaultMetaMailboxDir, defaultMetaSessionsDir, makeStoreRecordReader, readActiveStoreEntries, readMetaIdentityByGardenId, readMetaInbox, readMetaReceiverMarker, readMetaSenderMarker, requireBackend, } from "../../../pi-extensions/lib/meta-session.js";
 import { RESUME_CALL_REJECT_HINT, resumeCall } from "../../../pi-extensions/lib/mux-resume-call.js";
 import { registerNativeConversation } from "../../../pi-extensions/lib/native-push/register.js";
+import { makeLocalTraceFact, readRemotePairOptIn, remotePairOptInPath, runEntwurfV2WithRemoteRoute, } from "../../../pi-extensions/lib/remote-pair-send.js";
+import { processTransport } from "../../../pi-extensions/lib/remote-pair-transport.js";
+import { CONTROL_SOCKET_DIR } from "../../../pi-extensions/lib/socket-discovery.js";
 import { probeSocketLiveness } from "../../../pi-extensions/lib/socket-probe.js";
 const HOME = os.homedir();
 // ============================================================================
@@ -431,11 +434,22 @@ server.tool("entwurf_v2", "CANONICAL DELIVERY SURFACE for garden ids: message, r
         // Resolved ONCE so the dispatch-moment timestamp is fixed and the control RPC sender
         // + the mailbox body sender share one envelope. No replyability gate (see above).
         const sender = await buildSendSenderEnvelope({ requestMeta: extra._meta });
-        const rendered = await runAndRenderEntwurfV2FromSurface({ target, intent, message, mode, wants_reply }, 
-        // No trust-preflight inputs are passed, and none exist to pass: the preflight on this
-        // path guarded the resume verdict and left with `owned-outcome`. `senderProvider` is
-        // the whole options surface now.
-        { senderProvider: () => sender });
+        // #107: the operator's remote-pair opt-in is read per send. Absent = off and the local
+        // surface below runs exactly as before; a declared target goes over that one route.
+        const rendered = await runEntwurfV2WithRemoteRoute({ target, intent, message, mode, wants_reply }, {
+            senderProvider: () => sender,
+            route: readRemotePairOptIn(remotePairOptInPath()),
+            // The decider's canonical socket dir AND this bridge's ENTWURF_DIR: a trace in either is local.
+            localTrace: makeLocalTraceFact({
+                sessionsDir: defaultMetaSessionsDir(),
+                controlSocketDirs: [CONTROL_SOCKET_DIR, ENTWURF_DIR],
+            }),
+            transport: processTransport,
+            // No trust-preflight inputs are passed, and none exist to pass: the preflight on this
+            // path guarded the resume verdict and left with `owned-outcome`. `senderProvider` is
+            // the whole options surface now.
+            runLocal: (params, opts) => runAndRenderEntwurfV2FromSurface(params, opts),
+        });
         return rendered.isError ? textErr(rendered.text) : textOk(rendered.text);
     }
     catch (err) {

package/mcp/entwurf-bridge/dist/pi-extensions/lib/meta-mailbox-body.js

@@ -60,13 +60,19 @@ export function formatMetaMailboxBody(sender, message, wantsReply) {
     const replyable = sender.replyable === true;
     const isMeta = sender.origin === "meta-session";
     const kind = isMeta ? "meta-session, " : "";
+    // A remote sender is never replyable here: no reply route was probed. Its cwd is a path on the
+    // SENDING host, so it is neither abbreviated against this host's HOME nor shown as a local path.
+    const remote = !replyable ? sender.remote : undefined;
     const sessionLine = replyable
         ? `${sender.sessionId} (${kind}replyable — reply via entwurf_v2 to this sessionId, intent=fire-and-forget)`
-        : isMeta
-            ? `${sender.sessionId} (meta-session, non-replyable)`
-            : `${sender.sessionId} (external, non-replyable)`;
+        : remote
+            ? `${sender.sessionId} (remote via ${remote.via}; ${remote.replyRoute === "declared" ? "reply route declared, not probed" : "no reply route declared"})`
+            : isMeta
+                ? `${sender.sessionId} (meta-session, non-replyable)`
+                : `${sender.sessionId} (external, non-replyable)`;
+    const where = remote ? `${sender.cwd} (sender-host path)` : abbreviateHome(sender.cwd);
     return (`[entwurf received ⟵]\n` +
-        `  from:        ${sender.agentId} @ ${abbreviateHome(sender.cwd)}\n` +
+        `  from:        ${sender.agentId} @ ${where}\n` +
         `  session:     ${sessionLine}\n` +
         `  at:          ${formatKstTimestamp(sender.timestamp)}\n` +
         `  wants reply: ${wantsReply ? "yes" : "no"}\n` +