@with-logic/elwood 0.1.3 → 0.2.1

package/docs/cli-output.md

@@ -212,3 +212,7 @@ fi
 Do not use `jq -r .response` alone as a success check. Error documents can
 carry a partial `response`, and streamed text can be partial when the process
 exits nonzero.
+
+For retained text runs, `--show-session-id` opts into a session-ID footer on stderr.
+Without it, use `elwood sessions` to find the ID. JSON and JSONL always keep their
+existing `sessionId` field.

package/docs/cli.md

@@ -15,8 +15,9 @@ elwood run --output json < prompt.txt
 ```
 
 `elwood "prompt"` runs in the current directory, waits for one complete turn,
-prints the combined assistant text to stdout, then tears its Elwood session
-state down. It does not undo files the agent changed or remove history owned by
+prints the combined assistant text to stdout, then stops the agent and preserves
+its Elwood session state for later listing or resumption. Use `--ephemeral` to
+remove that state afterward. It does not undo files the agent changed or remove history owned by
 the agent CLI. `elwood run "prompt"` is the same command in explicit form.
 
 Positional words are joined with spaces. Non-empty piped stdin is appended after
@@ -141,11 +142,13 @@ combined with `--stream`, `--verbose`, `--debug`, or `--output jsonl`.
 
 ## Continuation and cleanup
 
-New runs are ephemeral unless `--keep` is supplied. A kept text run reports its
-session ID on stderr; JSON and JSONL include it in the terminal record:
+New and resumed runs preserve state by default; `--keep` explicitly selects
+that default. Text output contains only the agent response. Add
+`--show-session-id` to print the retained ID on stderr, or run `elwood sessions`
+to find it later. JSON and JSONL include it in the terminal record:
 
 ```sh
-first=$(elwood --keep --output json "Remember that the release color is teal")
+first=$(elwood --output json "Remember that the release color is teal")
 id=$(printf '%s' "$first" | jq -r .sessionId)
 elwood --resume "$id" "What is the release color?"
 elwood --resume "$id" --ephemeral "Finish this conversation"
@@ -166,10 +169,13 @@ remain. It is supported only for new sessions, never with `--resume`.
 ## Trust and security
 
 Headless mode is non-interactive. With the default `--trust`, Elwood answers
-only its allowlisted workspace-directory and extension trust dialogs, plus the
-Elwood-owned Codex hook trust needed for operation. `--no-trust` disables the
-workspace and extension approvals. Any other recognized dialog fails safely as
-`blocked_prompt` instead of hanging or guessing.
+only its allowlisted workspace-directory and extension trust dialogs.
+`--no-trust` disables those approvals. Codex hook trust is always bypassed for
+the entire session, including third-party hooks configured in Codex, because
+Elwood needs its own hook bridge to run. This bypass is independent of `--trust`.
+Other recognized dialogs fail as `blocked_prompt`. The same error applies when
+safe trust automation cannot clear a gate within five seconds; queued prompt
+input is never sent into that gate.
 
 Piped text and image paths are prompt input with the same authority as text
 typed by the caller. Do not combine untrusted input with broad filesystem

package/docs/codex/cli.md

@@ -40,6 +40,50 @@ Useful CLI capabilities for Elwood:
   terminal output and also project recognized warnings into typed `warning`
   events with remediation commands.
 
+## Commentary and final replies
+
+Subscribe to `activity` to display Codex's committed user-facing progress:
+
+```ts
+session.on("activity", (event) => {
+  if (event.kind === "assistant_progress" && event.text) {
+    appendProgress(event.text);
+  } else if (event.kind === "assistant_message" && event.text) {
+    appendFinalReply(event.text);
+  }
+});
+```
+
+Progress uses `source: "transcript"`, `label: "assistant"`, the session ID,
+transcript path and optional native turn ID. It preserves string content and
+ordered array-form `output_text` blocks from `response_item` messages explicitly
+marked `phase: "commentary"`. Analysis and unknown phases never become progress.
+Readable reasoning retains its separate `reasoning` channel; encrypted reasoning
+is never normalized into text.
+
+Response items are the canonical progress source. Explicit non-final legacy
+`agent_message` mirrors remain raw transcript events with `other` summaries and
+no normalized text, avoiding duplicate publication and false final replies.
+Legacy unphased and final-answer behavior is preserved.
+
+Keep progress separate from final-reply handlers: it must not clear working
+state, consume reply context, finalize a trace, or route mentions to other
+agents. Progress does not end a turn or change session status. Ergonomic
+`send()` and `stream()` keep collecting their existing final-answer content;
+use `on("activity", ...)` for progress. These are live observations, not token
+deltas or replayed history, and their text may contain sensitive conversation
+content just like final replies.
+
+## Native questions
+
+Codex modal and queued question tools surface through Elwood's shared
+`question` event, normalized `question` activity, `listQuestions()` and
+`answerQuestions()`. Modal question sets are one request; queued asynchronous
+questions are independently answerable requests and can coexist with ongoing
+work. Question-bearing asynchronous messages remain distinct from final replies,
+even when their native record says `phase: "final_answer"`. See
+[native questions](../questions.md) for consumer usage and lifecycle details.
+
 ## Resume Implications
 
 Codex stores transcripts locally under Codex-owned state. Elwood should persist

package/docs/embedding.md

@@ -80,3 +80,10 @@ cap does not constrain your state layout.
   before the user starts a session — use `listClaudeModels`/`listCodexModels`.
   They spin up a throwaway session, list, and always tear it down, so they cost
   a few seconds each; cache the result in the parent app if you call them often.
+
+## Scaling concurrent sessions
+
+See [performance.md](performance.md) for the fifty-session workload, measured
+CPU improvement, and the existing `terminal.xterm.options.scrollback` history
+budget. Headless history and the browser terminal's history are separate;
+choose both budgets and avoid polling fresh snapshots for hidden sessions.

package/docs/login-recovery.md

@@ -13,6 +13,30 @@ surfaces this so a session never wedges silently:
   matching `warning` activity) carrying `recoveryCommand: "/login"`, and leaves
   the session alive so you can recover without restarting.
 
+## Advance renewal notices
+
+Claude can show `Your login expires in 3 days · run /login to renew` while the
+session is still usable. Elwood exposes this separately from `login_expired`:
+
+```ts
+session.on("warning", (warning) => {
+  if (warning.code === "login_expiring") {
+    // Notify a human or schedule renewal according to your application's policy.
+    showRenewalNotice(warning.expiresInDays, warning.recoveryCommand);
+  }
+});
+```
+
+Subscribe immediately after `startClaude` or `resumeClaude` returns to receive
+startup observations. The same payload appears in `activity` with
+`kind: "warning"`, `label: "login_expiring"`, and the typed warning in `raw`.
+The CLI-reported `expiresInDays` is a duration, not an exact expiry timestamp.
+Each distinct countdown value emits once per live session. Warnings are never
+persisted or replayed to later subscribers. Native welcome banners and empty
+composer footers are recognized; arbitrary transcript text is ignored. Elwood
+does not change status or initiate login. A consumer can offer the existing
+`session.login()` flow when the human is ready.
+
 ## Driving `/login`
 
 `ClaudeSession.login(options)` drives the interactive `/login` flow. The

package/docs/native-question-proofs.md

@@ -0,0 +1,57 @@
+# Native question proofs
+
+These opt-in tests exercise `listQuestions()` and `answerQuestions()` against
+real authenticated CLI processes. Each entrypoint uses two valid-model turns.
+Run them separately after `npm run check`; they consume model quota.
+
+## Claude: C-E2E-18
+
+```sh
+ELWOOD_NATIVE_QUESTIONS_PROOF=1 node --no-warnings --test --test-concurrency=1 tests/e2e/claude-questions.e2e.ts
+```
+
+The proof pins Claude Code 2.1.305 and uses `haiku`. It prefers that exact binary
+in `~/.local/share/claude/versions/`, falling back to the installed binary only
+when its version matches. It copies credentials into a private temporary home
+and writes a minimal temporary configuration. Parent configuration is checked
+for changes; it is not copied into the proof's home. The parent CLI installation
+remains unchanged.
+
+The first turn submits grouped single and multiple choices. The second submits
+multiline alternative text. Both compare the native `AskUserQuestion`
+PostToolUse answers, require an answered closure and an empty pending list,
+and keep the original `send()` waiting for the final assistant reply.
+
+Question events and normalized activities must correspond exactly and contain
+no submitted answer marker. The proof recursively checks Elwood-owned state
+before and after shutdown. Diagnostic artifacts use private, exclusive files
+inside the sandbox. Teardown removes the sandbox and verifies that parent
+configuration, authentication and process environment remain unchanged.
+
+## Codex: C-E2E-19
+
+```sh
+ELWOOD_NATIVE_QUESTIONS_PROOF=1 node --no-warnings --test --test-concurrency=1 tests/e2e/codex-questions.e2e.ts
+```
+
+The proof pins Codex 0.163.0 and uses `gpt-6-luna` with low effort. The first
+turn asks three queued questions in one asynchronous call. It answers Note,
+Literal, then Color through the public API, checking the other requests remain
+available and the original turn remains running. The second turn submits one
+three-question Plan modal, including None of the above and a named choice with
+additional notes.
+
+Both long answers exceed 700 characters and include CRLF and CR line endings,
+interior tabs, indented caret rows, interior trailing spaces and outer Unicode
+whitespace. Complete committed native free-text answers and notes must match
+after newline normalization and outer Unicode White_Space trimming. Queued
+selected labels are trimmed; modal selected labels remain exact (PRD §5.10).
+The literal answers
+`Type your answer` and `Add notes` must also match exactly; a clipped viewport
+or placeholder rendering is not accepted as proof of the submitted value.
+
+The proof compares complete queued reply envelopes and grouped modal answer
+arrays, requires four answered request closures and final-only ergonomic
+replies, and applies the same telemetry/state privacy and parent-state checks
+as the Claude proof. Native transcripts and diagnostic captures stay inside
+private sandbox directories that teardown removes.

package/docs/performance/terminal-engines.md

@@ -0,0 +1,88 @@
+# Terminal engine assessment — October 24, 2026
+
+Keep xterm for the current optimization. A private Ghostty WASM probe showed
+a useful parser/formatter CPU reduction, but does not yet implement Elwood's
+terminal contract. Replacing the engine requires an explicit API migration: the
+public `terminal.xterm` exposes the complete headless xterm Terminal, including proposed
+APIs. Running both engines would retain both parsing and buffer costs.
+
+## Probe scope and provenance
+
+The experiment instantiated the official full `ghostty-vt.wasm` in Node 26.3.1
+with one WASM instance containing 50 terminals. Both engines parsed the same
+80 full-screen redraws at 120 columns by 40 rows. The snapshot variant decoded
+Ghostty's plain formatter output and checked final round markers. UTF-8 copy
+and decoding were included. This was a standalone diagnostic, not the full
+Elwood runtime workload; no hook/watch/classification or browser costs were
+included. The trace did not fill scrollback.
+
+The official nightly release was associated with source revision
+`22f100c6367045bb5fc86172f837047dee2f7670`, library `0.1.0-dev`.
+The 1,189,559-byte WASM SHA-256 was
+`e23598cefe95b42d441221a45d22d435c9c1915bca7475fe735e7617eac1a0d1`.
+Its embedded type metadata had a null commit field: the binary hash pins the
+measured bytes; the source association comes from release metadata. The `tip`
+URL moves and must not be treated as an immutable version. No dependency or
+WASM binary was added to Elwood.
+
+Sources: [official release](https://github.com/ghostty-org/ghostty/releases/tag/tip),
+[WASM API](https://github.com/ghostty-org/ghostty/blob/22f100c6367045bb5fc86172f837047dee2f7670/include/ghostty/vt/wasm.h),
+[official example](https://github.com/ghostty-org/ghostty/blob/22f100c6367045bb5fc86172f837047dee2f7670/example/wasm-vt/index.html).
+
+## Standalone measurements
+
+Three alternating fresh processes per engine used shared input/output scratch
+for all Ghostty terminals. The xterm side included Elwood's headless write queue
+and cursor tracking from commit `34ab7dd5`. The snapshot paths differ: xterm extracts the full physical
+viewport; Ghostty formats plain text. These numbers compare the prototypes,
+not equivalent complete engines.
+
+| Diagnostic median | xterm path | Ghostty WASM path |
+|---|---:|---:|
+| Parsing path CPU | 326.275 ms | 176.598 ms |
+| Parsing plus snapshot/formatter CPU | 559.623 ms | 343.816 ms |
+| Parsing plus snapshot/formatter RSS | 131.6 MiB | 139.5 MiB |
+
+Parsing CPU samples were 345.918 / 326.275 / 229.376 ms for xterm and
+225.668 / 147.451 / 176.598 ms for Ghostty. Snapshot/formatter samples were
+575.996 / 559.623 / 429.162 ms and 356.796 / 343.816 / 322.240 ms.
+The host was busy; all paired CPU comparisons favored the prototype, but the
+variation is substantial. The approximately 39% lower median CPU in the
+formatter comparison is not a whole-Elwood speedup.
+
+Ghostty's shared linear memory reached 23.625 MiB; WASM allocations must not
+be inferred from JS heap alone. Process RSS was not lower in the formatter
+comparison. No lower-memory replacement conclusion follows from this trace.
+An earlier per-terminal scratch variant allocated about 16 MiB unnecessarily;
+only the shared-scratch measurements above are used for this comparison.
+
+## Compatibility work required before replacement
+
+Elwood needs exactly one line per physical viewport row, cursor coordinates
+through scrollback and reflow, and cell-column prefix extraction for wide and
+combining characters. Question editors require cursor-cell dimming to distinguish
+placeholder text from real answers. Plain formatter output does not prove those
+properties.
+
+A replacement must also preserve parser-completion ordering, input ownership,
+protocol replies, title updates, synchronized-output holds, resize events,
+wrap-pending cursor positions and failure/disposal behavior. The WASM prototype
+did not install the write-to-PTY callback; query responses were therefore absent.
+Its marker checks establish only the diagnostic trace, not native CLI safety.
+
+The next useful engine experiment would compare full viewport/cursor/style and
+protocol-event fixtures through a compatibility adapter. A native addon should
+follow only if measured WASM boundary costs justify its build/distribution cost.
+Sources: [render state](https://github.com/ghostty-org/ghostty/blob/22f100c6367045bb5fc86172f837047dee2f7670/include/ghostty/vt/render.h),
+[grid references](https://github.com/ghostty-org/ghostty/blob/22f100c6367045bb5fc86172f837047dee2f7670/include/ghostty/vt/grid_ref.h),
+[terminal effects](https://github.com/ghostty-org/ghostty/blob/22f100c6367045bb5fc86172f837047dee2f7670/include/ghostty/vt/terminal.h).
+
+## Other candidates
+
+[libvterm 0.3.3](https://www.leonerd.org.uk/code/libvterm/) provides a screen and
+output callbacks, but its released screen-cell attributes lack the dim/faint
+flag used by question provenance. [vte](https://github.com/alacritty/vte) is a
+parser rather than a complete terminal emulator.
+[libtsm](https://github.com/Aetf/libtsm) still needs protocol, Unicode, dimming,
+resize and packaging verification. None offered a measured compatible replacement
+within this investigation.

package/docs/performance.md

@@ -0,0 +1,193 @@
+# Performance checks
+
+Elwood's parent process renders terminal output, classifies frames, retains a
+bounded replay buffer, and watches transcripts for each session. Native Claude
+and Codex processes consume additional resources outside this process.
+
+## Repeatable terminal load
+
+Run these from the repository root after `npm ci`, using Node 24 or newer:
+
+```sh
+ELWOOD_BENCH_AGENT=claude node --expose-gc --no-warnings scripts/performance/terminal.ts 8 1 8 32
+ELWOOD_BENCH_AGENT=codex node --expose-gc --no-warnings scripts/performance/terminal.ts 8 1 8 32
+```
+
+Each child writes 8 MiB through a real PTY. The probe checks byte counts and a
+final rendered marker, then reports elapsed time, memory, event-loop delay,
+pending output, and resources remaining after cleanup. The selected observer
+runs the production startup-prompt, screen-fact, turn, attention, and replay
+code. Omit `ELWOOD_BENCH_AGENT` to measure rendering and snapshots alone.
+
+This is a synthetic output burst. It does not launch agent CLIs, make model
+requests, exercise hook or transcript traffic, or measure child-process memory.
+Use it to detect regressions in Elwood's output processing; real workloads need
+their own measurements.
+
+### September 16, 2026 baseline
+
+Measured on the development Mac with Node 24.7.0. Results vary with machine and
+concurrent workload; these are observations, not performance guarantees.
+
+| Observer | Sessions | Total output | Elapsed | Peak parent RSS | Event-loop p99 / max |
+|---|---:|---:|---:|---:|---:|
+| Claude | 1 | 8 MiB | 0.185 s | 110 MiB | 11.3 / 11.3 ms |
+| Claude | 8 | 64 MiB | 0.969 s | 240 MiB | 14.4 / 16.0 ms |
+| Claude | 32 | 256 MiB | 7.608 s | 363 MiB | 26.2 / 31.9 ms |
+| Codex | 1 | 8 MiB | 0.243 s | 117 MiB | 19.5 / 19.5 ms |
+| Codex | 8 | 64 MiB | 1.537 s | 248 MiB | 17.4 / 23.4 ms |
+| Codex | 32 | 256 MiB | 9.270 s | 364 MiB | 23.9 / 42.3 ms |
+
+At 32 sessions, final rendering finished within 10 ms of child exit. Neither
+run retained PTY resources after cleanup, and post-GC heap usage did not increase
+over that trial's starting heap. The remaining `PipeWrap` was the probe's stdout.
+
+Before output batching, the snapshot-only probe took 14.497 s for one 8 MiB
+session, queued about 8.19 MiB, and spent 14.19 s rendering after child exit.
+The corresponding post-fix trial took 0.544 s. These two trials used the same
+snapshot-only workload; the table above also includes production frame observers.
+
+A separate ten-second idle probe used 128 real empty transcript files, split
+evenly between Claude and Codex watchers at their default polling intervals. It
+used 97.9 ms of CPU time (about 0.98% of one core), with 19.0 ms p99 event-loop
+delay. It reported no errors, no retained heap increase, and no active resources
+after closing the watchers. This measures idle polling, not transcript parsing
+under active output.
+
+## Bounds and regression coverage
+
+- Adjacent PTY output is batched for at most 4 ms or 64 KiB, preserving order and
+  content. Renderer observations occur at batch boundaries.
+- Real PTYs pause at 1 MiB of pending output and resume below 512 KiB. An already
+  delivered chunk can exceed the threshold. Custom PTY factories must provide
+  flow control to receive this backpressure.
+- Runtime cleanup gives received output up to one second to render before
+  disposal. Process exit and reaping remain immediate; direct terminal disposal
+  discards pending output immediately.
+- Tests cover batch ordering, Unicode/ANSI boundaries, slow-renderer
+  backpressure, disposal, final output on exit, and cancellation of late
+  readiness timers.
+
+Re-run the probe after changes to rendering, frame classification, replay,
+transcript polling, or cleanup. Compare output correctness and cleanup as well
+as throughput, memory, and event-loop delay.
+
+## Fifty-session runtime workload
+
+```sh
+node --expose-gc --no-warnings scripts/performance/fleet/index.ts
+```
+
+This probe starts 50 production runtimes, alternating Claude and Codex, with
+synthetic PTY producers. Dependency seams model macOS even on other hosts; this
+does not test native-agent support on those hosts. It exercises real local hook
+sockets, transcript watchers, frame observers, public snapshots and cleanup without
+launching agent CLIs or making model calls. Each session receives 80 full-screen redraws at
+120 columns by 40 rows, then 1,200 scrolling lines. Assertions check all
+15,155,250 output bytes, 500 transcript activities and final viewport markers.
+The process reports setup separately, a two-second idle CPU sample, active CPU,
+wall time, event-loop delay, live memory after GC and resource cleanup.
+For a quick smoke run, set `ELWOOD_BENCH_SESSIONS=2 ELWOOD_BENCH_ROUNDS=2`.
+
+### October 24, 2026: shared completed-frame text
+
+Three alternating reference/candidate pairs used the same worktree, v2 probe
+and Node 26.3.1 on the development Mac. Both sides used the benchmark from
+`f6e4406c`; the reference restored runtime files from release `ba8b634e`
+(0.2.0), while the candidate used the runtime at `f6e4406c`.
+Values below are medians, not guarantees. Host activity changed absolute
+timings substantially between measurement windows; compare matched pairs.
+
+| Parent-process metric | Reference | Shared frame | Change |
+|---|---:|---:|---:|
+| Active CPU | 1,177.071 ms | 1,043.927 ms | −11.3% |
+| Idle CPU over two seconds | 20.955 ms | 22.113 ms | +1.158 ms; variable |
+| Live JS heap | 52.828 MiB | 53.084 MiB | +0.5% |
+
+Active CPU samples were 1,176.453 / 1,177.071 / 1,195.298 ms before and
+1,043.927 / 1,045.998 / 1,031.162 ms after. Every v2 run passed per-session
+byte/activity attribution, final viewport markers and resource-count checks.
+The probe awaits teardown of every session, removing private socket homes before
+its shared root. Regression tests verify filesystem cleanup, rejection ordering,
+extra handles of an existing type and offsetting per-session accounting gaps.
+Idle samples ranged from 20.275–25.492 ms before and 16.285–23.858 ms after;
+no idle optimization is claimed. The CPU reduction is below the initial 15%
+estimate, with effectively unchanged live heap.
+
+The change removes a second viewport conversion in foreign-picker observation
+while preserving fresh public snapshots and input-boundary reads. Raw xterm
+writes, writeln and reset invalidate private cached text; disposal restores the
+original methods. Regression tests fail with the change removed, including a
+raw write in an owned parser drain, writeln's synchronous parse after user input
+and method restoration on disposal.
+
+An earlier v1 comparison measured 10.3% lower CPU. Its aggregate assertions
+did not establish per-session completeness, same-type handle counts or socket-home
+removal; the v2 comparison above supersedes that result.
+
+These measurements exclude browser rendering and agent-process memory/CPU.
+The probe's final screen assertions and 500 activity count protect this workload;
+they do not establish correctness for every native dialog. The repository's
+conformance suite remains the merge gate.
+
+## Consumer memory and rendering budgets
+
+Elwood's headless xterm retains 1,000 history lines by default. Consumers that
+retain their own raw terminal history can opt out of headless scrollback through
+the existing advanced xterm handle:
+
+```ts
+import { CodexSession } from "@with-logic/elwood";
+
+const session = await new CodexSession({ cwd }).start();
+session.terminal.xterm.options.scrollback = 0;
+```
+
+The same setting applies to Claude sessions. Apply it at session creation,
+before sustained output. This discards headless scrollback and changes what
+xterm can recover/reflow on scrolling and resizing; choose a small nonzero
+budget if that history is needed. It does not change the consumer's own replay
+store or browser terminal's independent scrollback setting.
+
+Three alternating default/zero-history runs of the fixed 50-session workload
+on Node 26.3.1, commit `f6e4406c`, measured the following medians after
+1,200 scrolling lines per session. The experimental preload changed only xterm
+constructor scrollback; all byte, transcript, viewport and cleanup assertions
+passed. A separate two-adapter smoke used the public setter above and verified
+zero history rows after scrolling. This is a configuration comparison, not a
+runtime default change.
+
+| Parent-process memory | Default 1,000 lines | Zero history |
+|---|---:|---:|
+| Live JS heap | 53.080 MiB | 38.977 MiB |
+| External memory | 81.017 MiB | 13.065 MiB |
+| Process RSS | 318.766 MiB | 231.484 MiB |
+
+JS heap samples ranged from 53.078–53.080 MiB at the default budget and
+34.650–38.987 MiB at zero history. History, dimensions, GC and host activity
+affect these values. CPU and
+idle timing varied enough that no CPU benefit is claimed for this setting.
+
+For many-session consumers:
+
+- Feed all ordered `terminal:data` bytes to the consumer's terminal/history
+  pipeline; batch browser writes without dropping bytes or ANSI boundaries.
+- Keep only visible terminals rendering. Bound browser scrollback independently
+  and avoid polling public snapshots for every hidden session. Public snapshots
+  deliberately perform a fresh viewport read.
+- Use normalized activity for chat/progress updates. Append to a bounded store
+  and batch UI updates instead of rerendering all terminal history per event.
+- Measure Elwood parent CPU separately from agent child processes and the UI
+  renderer. Browser refresh/history costs do not appear in the headless probe.
+
+The update-dialog prefilter prototype reduced active CPU by 3.8% in its matched
+window, below this investigation's 5% decision threshold, and was not retained.
+Fifty idle sessions used roughly 20 ms of parent CPU per two seconds; the
+measurements did not justify a polling rewrite. The
+[terminal engine assessment](performance/terminal-engines.md) records the
+Ghostty prototype and the compatibility requirements for a replacement.
+
+The fleet probe dispatches authenticated local hook requests directly; it does
+not launch the generated hook-bridge subprocess for each request. Bridge-process
+startup/CPU, agent processes and the browser need separate measurements. The
+parent-process results do not establish a whole-system scaling guarantee.