@with-logic/elwood 0.1.3 → 0.2.0

package/prd/12a-cli.md

@@ -91,7 +91,10 @@ outcome by default, after stop-or-kill cleanup. `--keep` explicitly selects this
 default. `--ephemeral` instead requests teardown for either a new or resumed
 run; it cannot be combined with `--keep`. Teardown does not undo workspace
 changes or remove history owned by the underlying agent. A preserved run reports
-its resumable session ID on stderr in text mode. A resume uses `--resume <id>` to load exactly the
+its resumable session ID on stderr in text mode only when `--show-session-id`
+is supplied. By default, successful text output contains only the agent response;
+`elwood sessions` lists retained IDs. The flag affects only the text footer, not
+the `sessionId` field in JSON/JSONL, and emits nothing for ephemeral sessions. A resume uses `--resume <id>` to load exactly the
 stored adapter and cwd; it never falls back to a new conversation, and `--cwd`
 is therefore rejected with `--resume` rather than overriding the stored
 workspace. Explicit adapter conflicts are usage errors. Before launch, resumed state and its cwd MUST satisfy the private,
@@ -258,8 +261,11 @@ final nonzero result.
 While attached, Elwood temporarily puts terminal stdin into raw mode and
 discards ordinary keyboard, mouse, paste, and terminal-response bytes: v1 head
 mode is observational, not interactive. Every Ctrl-C byte follows the same
-first-interrupt/repeated-force-kill lifecycle as SIGINT. On every normal,
-failure, timeout, or interruption outcome, Elwood MUST remove its input and
+first-interrupt/repeated-force-kill lifecycle as SIGINT. The mirror MUST stay
+attached through session cleanup, so PTY output received before the run ended —
+including the tail that runtime cleanup drains (§9.4) — reaches the display
+rather than being discarded with a still-pending render batch. After cleanup, on
+every normal, failure, timeout, or interruption outcome, Elwood MUST remove its input and
 resize listeners, restore terminal stdin's prior raw/cooked mode, flush pending
 display writes, reset attributes, disable mouse and bracketed-paste modes, show
 the cursor, and leave the alternate screen before emitting the final stdout
@@ -302,8 +308,8 @@ nothing to stdout, one concise notice naming the state directory to stderr, and
 exits 0. JSON output is exactly one version-1 document
 `{ "schemaVersion": 1, "type": "sessions", "stateDir": "...", "sessions": [...] }`
 whose array may be empty. JSONL is not a listing protocol; selecting it from any
-source is a usage error that names the source. Any other run option or a
-positional word is a usage error.
+source is a usage error that names the source. Any other run option (including
+`--show-session-id`) or a positional word is a usage error.
 
 ### 12A.9 Interactive mode
 
@@ -341,7 +347,7 @@ the agent owns the resumed conversation, later `elwood resume <id>` runs see
 whatever the user said interactively.
 
 `--output json`, `--output jsonl`, `--stream`, `--verbose`, `--debug`, `--head`,
-`--timeout`, `--persona`, `--image`, `--keep`, `--ephemeral`, and `--resume`
+`--timeout`, `--persona`, `--image`, `--keep`, `--show-session-id`, `--ephemeral`, and `--resume`
 are usage errors with `interactive`, and more than one positional word is a usage
 error. A launch that cannot spawn fails with the adapter's not-found error code
 and status 1.
@@ -389,7 +395,7 @@ whose rows are the `AgentModelOption` objects. Every string is sanitized under
 §12A.3. Failures — timeout (124), interruption (130), blocked prompts, agent
 exit, and picker automation failures — use the existing stderr, error-document,
 and status conventions, and cleanup still runs exactly once. `--stream`,
-`--head`, `--persona`, `--image`, `--keep`, `--resume`, `--ephemeral`,
+`--head`, `--persona`, `--image`, `--keep`, `--show-session-id`, `--resume`, `--ephemeral`,
 positional words, and JSONL output are usage errors.
 
 Listing sessions resolves only state-directory and output settings. Adapter,

package/prd/13-latitude.md

@@ -10,3 +10,92 @@ above:
 - Whether the package runs on Node.js or another compatible JavaScript runtime, as long as the TypeScript API
   contract is met by supported hosts.
 - Internal storage filenames under `.elwood/`.
+
+The documentation site's sprite-load errors identify the failing relative asset
+path, bounded to 200 characters, and retain the underlying error as their cause.
+
+Sprite requests for the same metadata or atlas key share one fetch/decode operation.
+An explicit consumer may cancel without cancelling remaining consumers or silencing
+their automatic failure report. Only the final consumer cancels the underlying
+operation; an abandoned completion cannot publish into a successor request.
+Explicitly retained pages stay alive through delivery and cache eviction until their
+owner releases them, while current/outgoing pose owners remain protected.
+After successful complete animation preparation, the shared idle clip's two shipped
+pages remain leased for that sprite bank's lifetime, so later actions reuse them
+without repeated fetching or decoding. Failed or cancelled preparations do not
+establish this lease. The shared lease is capped at two pages: an idle manifest
+with more pages falls back to ordinary animation/cache ownership.
+The ordinary cache remains capped at four pages; rotation and action pages receive
+no bank-lifetime lease. Disposal releases the shared idle lease together with all
+other resource owners.
+
+Sprite decoder requests may carry an abort signal. Cancellation rejects the
+request promptly, skips requests that have not started decoding, and
+never falls back to another decoder. The internal worker protocol pairs decode
+request IDs with cancellation messages and completion acknowledgements. The page
+owns the waiting queue and sends one request at a time; aborting the active
+request does not release that physical slot until the worker replies. In-flight
+browser bitmap decoding cannot be interrupted; its eventual image is released,
+without terminating the worker or cancelling other requests. Settled requests remove their abort listeners.
+
+Automatic gesture and facing tasks may wait at most eight seconds before delivery.
+Once elapsed time exceeds eight seconds, the next simulation update cancels the
+task before checking asset readiness or silhouette fit. Assets becoming ready
+between updates cannot revive that expired task; delivery at exactly eight seconds
+remains eligible. This limit does not shorten an action already delivered.
+
+### 13.1 Landing-page explicit animation controls
+
+Landing gesture and front/back requests wait for every page of the requested clip,
+idle and rotation before delivering input. Pending explicit loading suppresses
+automatic actions. Requests are ineligible while dragging, holding movement,
+airborne, hanging, climbing, landing, settling, or committed to a pending jump or
+jump wind-up. Eligibility is checked before loading and again before delivery.
+
+A request accepted into an existing gesture's recovery queue retains its delivered
+pages until playback activation or replacement. Activation owns the requested clip
+before the opening turn paints. Held movement that clears the recovery queue also
+releases its delivered request. Reset, responsive reflow and supersession cancel
+pending/delivered work while preserving active/outgoing poses; reflow preserves
+held movement. Superseding a gesture/facing request preserves unrelated pending
+input such as a jump press. Workshop paths retain on-demand loading; automatic moments and facing follow
+§13.3, and suspended pickup follows §13.4.
+
+### 13.2 Landing-page initial animation readiness
+
+The landing page keeps its static fallback until every initial idle page is decoded
+and retained for playback. Initial preparation fetches idle only; rotation and other
+clips remain on demand. The live readiness callback and first painted handoff occur
+only after complete idle preparation. Input and visibility changes before readiness
+do not cancel initial preparation. Teardown cancels it and prevents a late handoff.
+An asset failure reports the existing contextual error and preserves the fallback;
+a later explicit boot attempt may retry. Idle pages remain available through cache
+eviction and later playback changes through the shared idle lease, with
+current/outgoing pose ownership preserved.
+
+### 13.3 Automatic gesture and facing readiness
+
+Automatic moments and facing actions wait for all requested, idle and rotation
+pages before delivering input. Their post-delivery clock starts only when complete
+preparation succeeds. The existing eight-second pre-delivery wait bounds loading;
+expiry cancels that task without reporting an asset failure. Geometry probes remain
+metadata-only and share existing loads. Publication requires the exact prepared
+candidate, or the same complete active owner with no newer candidate/delivery.
+Task replacement, manual takeover, reset/reflow and teardown release obsolete
+metadata/preparation consumers. Cancellation removes a matching queued delivery,
+but cannot release a newer manual request or active/current/outgoing playback.
+An automatic asset failure reports once. Failed requested or shared idle/rotation
+assets suppress later automatic attempts that need them, including other actions,
+until explicit preparation clears the relevant failure state. Unchanged paint ticks
+cannot retry or republish a failed or superseded task. Walking remains on demand.
+
+### 13.4 Landing-page pickup readiness
+
+Pickup takes pointer/keyboard control immediately while the current drawable clip
+continues playing. Suspended wriggle (or zero-gravity fallback) starts at time zero
+only after all its sheets and idle/rotation dependencies are ready and owned by
+that drag. Pointer movement preserves preparation. Drop, pause, reset, reflow and
+teardown cancel pending pickup; a late completion cannot start obsolete playback.
+Current/outgoing poses remain retained. Failure reports once for the current drag;
+movement and painting do not retry, but a new drag may retry. Falling and landing
+transitions retain their existing on-demand behavior.

package/prd/14-conformance.md

@@ -36,10 +36,11 @@ Each criterion has:
 | C-API-16 | §5.1 | Omitted `initialSize` defaults to a 189 column by 48 row terminal. |
 | C-API-17 | §5.4 | Hook dispatch emits adapter-neutral hook-result activity, and hook failures also appear in the activity stream. |
 | C-API-18 | §5.1 | Claude and Codex start/resume options expose `autotrust` for opt-in workspace trust prompt automation. |
+| C-API-58 | §5.3 | The session control queue bounds outstanding work, including in-flight input, to 1,024 operations and 8 MiB UTF-8 text. Excess admissions reject with `input_queue_full` without attachment or input; cancellation and physical settlement release capacity, while closed sessions retain `session_not_running` precedence. Loop rejection keeps the existing failed-submission retry policy; physical loop completion frees capacity before `fired` observers. Oversized startup personas reject before preflight or spawn. |
 | C-API-19 | §5.3 | Calling `sendMessage` while the session is alive but not ready queues the message until the next ready transition and rejects only if the session terminates first. |
-| C-API-20 | §5.7 | Codex transcript activity is flushed before terminal exit and terminal lifecycle status are emitted. |
+| C-API-20 | §5.3 §5.7 §8.1 §9.4 | Claude and Codex transcript activity is flushed before terminal exit and terminal lifecycle status are emitted; reentrant shutdown joins observed natural-exit finalization. Within the same process, a validated successor resume revokes the old launch's shared-state mutation authority, including deferred and repeated teardown. |
 | C-API-21 | §5.1 §5.5 | A caller-provided `persona` is submitted as the session's first user message on the first ready transition, ahead of caller-queued messages; it is not persisted and not re-sent on resume. |
-| C-API-22 | §5.3 §5.7 | `compact()` submits the adapter's `/compact` command through the readiness queue, resolves on the adapter's `PostCompact` hook, rejects with `compact_failed` on timeout, and rejects with `session_not_running` if the session terminates first. |
+| C-API-22 | §5.3 §5.7 | `compact()` submits the adapter's `/compact` command through the readiness queue, resolves on the adapter's `PostCompact` hook, rejects with `compact_failed` on timeout, and rejects with `session_not_running` if the session terminates first. The one recovery Enter for a swallowed submission is a queued write: it waits behind a model operation that owns the input queue, is dropped once compaction settles, and is withheld from blocking dialogs and from any visible model dialog. |
 | C-API-23 | §5.3 §5.7 | `listModels()` parses the adapter's rendered model picker into typed options with current/default markers, cancels with Escape, and leaves the session model unchanged. |
 | C-API-24 | §5.3 §5.7 | `setModel(id)` switches the session model through cursor navigation; Elwood itself never persists a new default into user-owned configuration (Claude uses the session-only key; the Codex CLI persists its own picker selection, documented as a §4.5 deviation) and unknown ids reject with `model_automation_failed` listing available ids. When Claude interposes its built-in model- or effort-cache warning, Elwood selects the affirmative row from one bottom-most contiguous live dialog across numbered/unnumbered layouts, revalidates it before confirmation, and resolves only after the idle composer returns; transcript text cannot participate and a `PreModelSwitch` hook confirmation remains human-controlled. |
 | C-API-35 | §5.3 §5.7 | `listModels()`/`setModel()` dispatch the picker command even while a turn is in flight (they do not wait for `ready`), so picker automation is not stalled by an in-flight turn such as an MCP-server boot spinner; `compact` and messages still wait for the active turn. Ordering is FIFO except for the documented overtaking of a readiness-waiting head by an immediate operation (a picker command, a `sendPrompt`, or already-ready running-turn guidance); same-class and post-ready ordering stays FIFO, and no two submissions interleave. |
@@ -47,34 +48,36 @@ Each criterion has:
 | C-API-37 | §5.3 §5.7 | Claude and Codex expose `sendGuidance(message)`: before first readiness and while blocked it queues safely like `sendMessage`; during a post-ready running turn it overtakes readiness-waiting operations and enters the TUI immediately. Guidance serializes with queue-backed prompt/message/command submissions and resolves only after the submitting Enter is dispatched; raw `sendKeys` intentionally bypasses that queue. |
 | C-API-38 | §5.3 §5.7 | `interrupt()` bypasses the control queue and writes a single Escape immediately while the session is `running` or `blocked` AND has reached initial readiness at least once, resolving when the session next reaches `ready`; with no turn in flight — an idle `ready` session or the pre-readiness startup `running` window — it resolves without writing anything; concurrent calls coalesce into one Escape; it rejects with `interrupt_failed` after `timeoutMs` (default 10000 ms) and with `session_not_running` when the session terminates first or is already terminal. |
 | C-API-39 | §5.3 §5.7 | When restoring the latest requested size at Claude's initial-ready transition fails with a real (non-closed) native PTY resize error, Elwood keeps the safe bootstrap width, does not report the resize as applied, and surfaces a typed `resize_restore_failed` warning (content-free: only the requested size and an allowlisted error code), while still releasing the queued persona/caller message so input is never starved; a closed-fd resize at that transition stays a silent no-op. |
-| C-API-25 | §5.3 | Promise-returning session methods called after a terminal status reject with `session_not_running` instead of throwing synchronously. |
+| C-API-25 | §5.3 | Promise-returning session methods called after a terminal status reject with `session_not_running` instead of throwing synchronously; expired Stop input retains the earlier `wait_timeout` admission rejection (C-HOOK-04). |
 | C-API-26 | §5.2 §5.6 | `startOrResumeClaude`/`startOrResumeCodex` resume when possible, fall back to a fresh start only on `state_not_found`, `resume_unavailable`, or `adapter_mismatch`, rethrow all other errors, and report `resumed` in the result. |
 | C-API-27 | §5.7 | `ElwoodAgentSession` is exported and both `ClaudeSessionApi` and `CodexSessionApi` (the raw live sessions the `ClaudeSession`/`CodexSession` classes wrap) are assignable to it, covering common events, io, commands, and lifecycle. |
-| C-API-28 | §5.3 | Initial readiness fires from the adapter's pre-input readiness hook — Codex's `SessionStart`, Claude's `InstructionsLoaded`. On a COLD start the rendered composer is never a readiness signal — the boot-time composer placeholder alone never releases the first queued message (it is painted before the input loop is live and would be swallowed). On a RESUME the CLI reattaches to an existing conversation without re-firing its pre-input hook and its input loop is live when the composer paints, so a resumed session fires initial readiness on the FIRST rendered composer marker (or on the readiness hook if it re-fires, whichever is first), reaching readiness in ~1s instead of the full deadline. A blocking dialog's option caret is byte-identical to the composer marker, so the resume-composer path does NOT fire while a blocking dialog is on screen — readiness waits for the dialog to clear, so a draining queued message can never approve it. This dialog gate applies to EVERY readiness source, not just the resume-composer path: a blocking dialog on screen — including one that first rendered while the session was still `starting`, before it could latch the `blocked` status — defers a hook OR deadline readiness mark too, so no readiness source ever drains the queue into a dialog. The deferred mark is reconciled the moment a rendered frame shows the dialog cleared (readiness is neither drained into the dialog nor permanently starved by it). A bounded deadline after the first rendered frame is the ultimate fallback on BOTH adapters and BOTH start/resume, so a missing/failed readiness hook (and, on cold start, an absent composer signal) cannot starve queued persona/messages forever. Readiness fires exactly once (idempotent): whichever of hook, resume-composer signal, or deadline comes first releases the first queued message, and the others are no-ops. |
+| C-API-28 | §5.3 | Initial readiness fires from the adapter's pre-input readiness hook — Codex's `SessionStart`, Claude's `InstructionsLoaded`. On a COLD start the rendered composer is never a readiness signal — the boot-time composer placeholder alone never releases the first queued message (it is painted before the input loop is live and would be swallowed). On a RESUME the CLI reattaches to an existing conversation without re-firing its pre-input hook and its input loop is live when the composer paints, so a resumed session fires initial readiness on the FIRST rendered composer marker (or on the readiness hook if it re-fires, whichever is first), reaching readiness in ~1s instead of the full deadline. A blocking dialog's option caret is byte-identical to the composer marker, so the resume-composer path does NOT fire while a blocking dialog is on screen — readiness waits for the dialog to clear, so a draining queued message can never approve it. This dialog gate applies to EVERY readiness source, not just the resume-composer path: a blocking dialog on screen — including one that first rendered while the session was still `starting`, before it could latch the `blocked` status — defers a hook OR deadline readiness mark too, so no readiness source ever drains the queue into a dialog. The deferred mark is reconciled only when a rendered frame shows a nonblocking idle composer; ongoing work and blank or partial repaints retain the hold. A bounded deadline after the first rendered frame is the ultimate fallback on BOTH adapters and BOTH start/resume, so a missing/failed readiness hook (and, on cold start, an absent composer signal) cannot starve queued persona/messages forever. Readiness fires exactly once (idempotent): whichever of hook, resume-composer signal, or deadline comes first releases the first queued message, and the others are no-ops. |
 | C-TURN-01 | §5.3 | While a turn runs the session is `running`; when the turn ends by any means — completion, Escape interrupt, or otherwise — the session transitions to `ready` and emits the corresponding `status` activity, on both adapters. |
 | C-TURN-02 | §5.3 | An Escape interrupt of a running turn produces the `ready` transition from rendered TUI state alone, with no dependency on a `Stop` hook. |
 | C-TURN-03 | §5.3 | Turn-state detection uses documented per-adapter indicator constants over `snapshot().text`; redundant edges are idempotent, and screens showing neither indicator hold state. Watching activates only after initial readiness. On resume, rendered edges remain suppressed through transcript replay until the first quiet, non-blocking composer; explicit running evidence releases that suppression immediately and synchronizes the watcher, and the CURRENT frame is still evaluated so the real turn's rendered end is retained even when it is the first frame after release (the turn ended exactly as the evidence arrived). |
-| C-TURN-04 | §5.3 | The interrupt `ready` transition fires at any terminal width: via the working-token edge where the footer fits, and via the adapter's interrupt end banner (which Claude's footer elision below ~66 columns makes necessary) on narrow screens. |
-| C-TURN-05 | §5.3 | Turn-state detection also consumes the OSC window title as a width-independent working signal: both adapters render a braille-spinner glyph (U+2800–U+28FF) in the title while a turn runs, so a turn `started` edge can fire from the title alone when the on-screen footer token is elided. The title is exposed on the terminal handle and is not persisted. |
+| C-TURN-04 | §5.3 | The interrupt `ready` transition fires at any terminal width: via the working-token edge where the footer fits, and via the adapter's interrupt end banner (which Claude's footer elision below ~66 columns makes necessary) on narrow screens. Retained pre-submission frames cannot complete newer physical input; a fresh interrupt banner absent at submission still works without a working footer. |
+| C-TURN-05 | §5.3 | Turn-state detection also consumes the OSC window title as a width-independent working signal: both adapters render a braille-spinner glyph (U+2800–U+28FF), and Claude also renders the observed `◐ ` prefix while a turn runs, so a turn `started` edge can fire from the title alone when the on-screen footer token is elided. The title is exposed on the terminal handle and is not persisted. |
 | C-ATTN-01 | §5.3 | A tool permission dialog rendered mid-turn transitions the session to `blocked` and emits an `attention` activity whose label names the matched screen-fact rule ids, on both adapters. |
-| C-ATTN-02 | §5.3 | A session enters `blocked` from either `running` or `ready` when a blocking dialog appears, and settles to `ready` when the dialog resolves; blocking evidence never moves a session out of a terminal status. |
-| C-ATTN-03 | §5.3 | Startup prompts Elwood answers automatically never produce `blocked`; a workspace trust prompt left unanswered because `autotrust` is false does. |
+| C-ATTN-02 | §5.3 | A session enters `blocked` from either `running` or `ready` when a blocking dialog appears, and clears directly to `running` when the current frame shows work, or to `ready` when idle; working clearance emits no intermediate readiness and leaves queued input suspended, including deferred initial readiness. A held caller prompt restores running at physical submission before a follow-up can dispatch, without repeating caller intent bookkeeping. Blocking evidence never moves a session out of a terminal status. |
+| C-ATTN-03 | §5.3 | Startup prompts successfully answered within the automation bound never produce `blocked`; unauthorized trust candidates block immediately. An off-allowlist gate inside the §5.4 grammar (recognized native header prefix, non-empty header, selectable options, frame-ending native footer, no conversation row above) is hold-only under every `autotrust` value: it holds readiness and queued input, never receives automated input, and blocks with attention rule id `<agent>-unknown_gate-prompt`; a dialog another blocking rule names keeps that label alone. Gates outside that grammar, conversation-quoted copies, footer-less or header-less shapes, and the native composer are not held. An authorized trust candidate that remains unsupported or uncleared after five seconds produces recoverable `blocked` and existing human attention, without requiring another frame; raw input and a later valid layout can recover it (C-TRUST-01). A blocking prompt painted while `starting` blocks once the session is live AND emits its attention activity then. While still blocked, a changed set of blocking rule ids emits updated attention without another blocking status decision; identical sets do not re-emit. |
 | C-ATTN-04 | §5.3 | Claude's model/effort switch confirmation dialogs are blocking prompts even though their selection caret resembles the composer marker. The built-in cache warning is automatically confirmed only as part of `setModel`; hook-requested confirmations remain blocked for a human decision. |
+| C-ATTN-05 | §5.3 | Native Claude questionnaires remain blocking when question copy contains composer-like carets, header-like rows, fences, or navigation-footer text. A completed questionnaire quoted above a later native composer does not supply questionnaire-blocking evidence. |
 | C-API-33 | §5.3 | `statusDecisions()` returns a live-only log of at most the 50 most recent status decisions, oldest first, each recording the evidence, the from/to statuses (`to` undefined when ignored), and a human-readable reason; it is never persisted and carries no prompt, terminal, or hook payload content. |
 | C-API-34 | §5.3 | `waitForStatus`/`waitForActivity` resolve from current state or the next matching event, reject with `wait_timeout` after the timeout (default 60000 ms), and reject with `session_not_running` when the session reaches an unwaited terminal status first; both unsubscribe on settle. |
 | C-API-29 | §5.2 §5.6 | Resume accepts the same launch-policy options as start and forwards them into the relaunched command: `resumeClaude` forwards `permissionMode`, `allowedTools`, `disallowedTools`, `tools`, and `reasoningEffort`; `resumeCodex` forwards `sandbox`, `approvalPolicy`, and `reasoningEffort`. A resumed agent stays exactly as privileged and as tool-restricted as it started, and applies a re-supplied reasoning effort (which Elwood does not persist across resume). |
 | C-API-32 | §5.2 §5.6 | Resume defaults launch-policy options from the record's persisted posture; explicit resume options override field by field, and the effective posture is re-persisted. |
 | C-API-30 | §5.4 | `tool_call` activity carries the tool's input as a serialized `toolInput` and `tool_result` activity carries the tool's output as a serialized `toolOutput`, sourced from the committed transcript for Claude (`tool_use.input`/`tool_result.content`, per C-CLAUDE-15) and from the transcript for Codex (`arguments`/`output`); absent sources leave the field absent. |
-| C-API-31 | §5.3 | The submitting Enter is a separate PTY write after a settle delay, and bounded re-Enters fire while the rendered composer still shows the staged paste, so a first long prompt cannot be left staged-but-unsubmitted. |
+| C-API-31 | §5.3 | Submitting Enter is a separate settled PTY write. Ordinary recovery permits at most two re-Enters over four one-second observations; initial/replay ergonomic recovery instead wakes on completed renders and retains cancellable ownership, with two paced retries and no ambiguous-frame polling budget. Retry requires live idle staged input; empty retirement requires positive empty input. Both need completed native output after the latest Enter, excluding cached/resize/scroll changes. Working/unknown frames consume no Enter budget. Native user-message activity, including during first Enter, revokes retry; optimistic status does not. |
+| C-API-56 | §5.3 | Queued paste, command text, Enter, recovery and non-trust startup writes observe all received PTY output (including arrivals during observation), recheck holds, then write before further output. Ordinary observation timeout (1s) or permanent render failure withholds/retries cancellably. Cancelled drafts retain safe cleanup before successor input/images: clear keys need fresh positive empty input within 1s; failure rejects the successor with `wait_timeout`; raw `sendKeys`/`terminal.sendInput`/`xterm.input` revokes authority and rejects awaited initial/replay ergonomic input with a submission-specific `wait_timeout`; close drops deferred cleanup. Initial/replay ergonomic input retains its slot/draft until fresh completed post-latest-Enter output proves empty input; geometry, missing draft text, activity and write fulfillment cannot acknowledge it. It shares staged/freshness guards, observes the final bounded retry before acceptance or `wait_timeout`, and retains pending physical writes through cancellation/close. Compact recovery/cleanup uses the same guard; successor dispatch cancels compact recovery. `sendKeys` never waits. Codex update skip/retries and Claude browser-tools decline stay silent/retryable when held; Claude disposal permanently cancels write/retry/success/warning (C-CLAUDE-22). Trust responders are exempt. |
 | C-API-40 | §5.3 | `sendPrompt`/`sendMessage`/`sendGuidance` text is sanitized before it is framed as a bracketed paste: the `ESC [ 200~`/`ESC [ 201~` sentinels and all other C0/C1 control characters except tab, newline, and carriage return are removed, so caller/model text cannot escape paste mode and inject live keystrokes (e.g. an Enter that confirms a permission dialog). `sendKeys` is the raw escape hatch and is never sanitized. |
 | C-API-41 | §5.3 | `listClaudeModels(options)`/`listCodexModels(options)` return the available models WITHOUT a caller-held session: each starts a throwaway session with `autotrust: true` (a documented §5.1 exception — the probe only opens/cancels the picker and never runs a turn), waits for first readiness, calls `listModels`, and ALWAYS removes ALL probe state afterward — on success, on a readiness/picker failure, AND on an adapter start failure that has already allocated a state directory or runtime files — so no probe session, process tree, socket, or state directory is leaked. A readiness/picker error is the error surfaced to the caller; teardown still runs, and when teardown ITSELF fails (which can leave a probe process tree alive) a bounded diagnostic naming the teardown failure — an allowlisted errno or the error's name, never a raw message — is attached to the surfaced error's `cause`, so a leaked probe is never silently invisible. The rows are exactly `listModels`' output and the probe leaves the user's saved MODEL default untouched (the picker is opened and cancelled, never applied), just as `listModels` does on a live session. |
-| C-API-42 | §5.3 §5.7 | When recording a session's one-shot initial-ready transition throws (a lifecycle-event listener) — on EITHER adapter — Elwood still releases the control queue directly FIRST so queued persona/caller input is never starved, then surfaces a typed, content-free `initial_ready_fallback` warning (`agent: "claude" \| "codex"`) whose delivery is itself isolated so a rogue warning sink cannot re-starve the queue. |
+| C-API-42 | §5.3 §5.7 | When recording a session's one-shot initial-ready transition throws — on EITHER adapter — Elwood still releases the control queue directly FIRST so queued persona/caller input is never starved, then surfaces a typed, content-free `initial_ready_fallback` warning (`agent: "claude" \| "codex"`) whose delivery is itself isolated so a rogue warning sink cannot re-starve the queue. Codex's returned status/activity Promise rejections from standalone readiness report `initial_ready_observer_failed` without delaying that transition; hook-triggered readiness shares the enclosing C-HOOK-22 warning boundary. |
 | C-API-43 | §5.3 | `ClaudeSession.login(options)` drives the interactive `/login` re-authentication flow to recover a session whose login lapsed (per C-CLAUDE-18) without a caller-held restart. It submits `/login` as a picker command, selects the requested login `method` (default `claudeai`) from the "Select login method" list if that list renders, and scrapes the authorization URL off screen and reports it via the optional `onAuthUrl` callback. Because the default account flow completes with a human-entered authorization code, Elwood awaits the CLI's "paste code" prompt and, when it renders, calls the required `provideCode` callback and submits the returned code as raw input; a flow that self-completes without prompting for a code never calls `provideCode`. `login` resolves once the CLI reports login success AND the session is usable again, and rejects with `login_failed` on an explicit failure/invalid-code banner or with `login_timeout` after `timeoutMs` (default 300000 ms); like every other command method it rejects with `session_not_running` when the session is terminal. It serializes with other queued commands and never sends raw keystrokes into a blocking dialog. |
-| C-API-44 | §5.3 | `sendPrompt`/`sendMessage`/`sendGuidance` accept an optional `images` list (file paths or `{data,format}` bytes) attached to the submission. Images have no position within the text, but the list is ORDERED (array order = attachment/chip order). Elwood attaches every image through the CLI's own native ingestion path, as part of the SAME serialized queue operation that submits the text and BEFORE that text's submitting Enter, so one call yields one agent turn carrying text and all images. Inputs are validated and bounded before any temp file is written or any input reaches the composer: at most 16 images, ≤25 MiB per image and ≤50 MiB total; an unsupported/empty `format`, a `path` that is not a readable regular file (its readability checked, not merely its existence), or any count/size past the limits rejects with `invalid_image`. A non-array `images`, an entry that is not exactly one of `{path}`/`{data,format}`, a non-string `path`, or non-`Uint8Array` `data` also rejects with `invalid_image` (never a raw type error). Every input is defensively SNAPSHOTTED — byte buffers cloned, paths absolutized — SYNCHRONOUSLY at the public send boundary, BEFORE the op is enqueued, so a caller that mutates its buffer (or changes `cwd`) after the call cannot change what is attached; the shape, format, count, and byte-size limits are enforced in that same synchronous pass, so a malformed or over-limit input rejects with `invalid_image` before it ever occupies a queue slot. The remaining filesystem checks that need I/O — a path's readability, regular-file-ness, and size against the per-image and shared aggregate ceilings — run inside the queued op at dispatch (so a path made unreadable after the call still rejects, and no temp file is written for a still-queued submission). The synchronous snapshot completes before the queue insertion, so an image submission is still enqueued in call order and a later plain submission cannot overtake it. Beyond the per-submission 50 MiB ceiling, a PER-SESSION aggregate ceiling (200 MiB) bounds the cloned image bytes held across ALL not-yet-attached queued submissions at once: a submission whose clone would push the session past that ceiling rejects with `invalid_image`, and each submission's reserved bytes are released when it settles (attach done, reject, or the session closing), so a slow paste/confirmation cannot let a caller retain unbounded queued-clone memory. Because a send on a TERMINAL session is guarded first, a malformed/over-limit `images` on a stopped/killed/torn-down session rejects with `session_not_running` (the terminal contract), not `invalid_image`. The lifecycle turn transition is deferred until AFTER a successful attach, so an attach rejection leaves readiness untouched and never wedges the queue; a raw materialization failure (e.g. disk-full) is surfaced as the typed `image_attach_failed`, not a raw platform error. Each image's attach is CONFIRMED by its `[Image #N]` chip on the composer prompt-glyph line (so unrelated screen text cannot spoof it); an unconfirmed image (chip not seen within 10 s) or a clipboard read/write failure rejects with `image_attach_failed`, submits no text, and best-effort clears the composer draft so staged images do not leak into a later turn (a session that terminates mid-attach rejects with `session_not_running`). Bytes are written to a short-lived temp file Elwood attempts to remove after the submission is attached (best-effort; a persistently failing removal falls to OS temp reaping). |
+| C-API-44 | §5.3 | `sendPrompt`/`sendMessage`/`sendGuidance` accept an optional `images` list (file paths or `{data,format}` bytes) attached to the submission. Images have no position within the text, but the list is ORDERED (array order = attachment/chip order). Elwood attaches every image through the CLI's own native ingestion path, as part of the SAME serialized queue operation that submits the text and BEFORE that text's submitting Enter, so one call yields one agent turn carrying text and all images. Inputs are validated and bounded before any temp file is written or any input reaches the composer: at most 16 images, ≤25 MiB per image and ≤50 MiB total; an unsupported/empty `format`, a `path` that is not a readable regular file (its readability checked, not merely its existence), or any count/size past the limits rejects with `invalid_image`. A non-array `images`, an entry that is not exactly one of `{path}`/`{data,format}`, a non-string `path`, or non-`Uint8Array` `data` also rejects with `invalid_image` (never a raw type error). Every input is defensively SNAPSHOTTED — byte buffers cloned, paths absolutized — SYNCHRONOUSLY at the public send boundary, BEFORE the op is enqueued, so a caller that mutates its buffer (or changes `cwd`) after the call cannot change what is attached; the shape, format, count, and byte-size limits are enforced in that same synchronous pass, so a malformed or over-limit input rejects with `invalid_image` before it ever occupies a queue slot. The remaining filesystem checks that need I/O — a path's readability, regular-file-ness, and size against the per-image and shared aggregate ceilings — run inside the queued op at dispatch (so a path made unreadable after the call still rejects, and no temp file is written for a still-queued submission). The synchronous snapshot completes before the queue insertion, so an image submission is still enqueued in call order and a later plain submission cannot overtake it. Beyond the per-submission 50 MiB ceiling, a PER-SESSION aggregate ceiling (200 MiB) bounds the cloned image bytes held across ALL not-yet-attached queued submissions at once: a submission whose clone would push the session past that ceiling rejects with `invalid_image`, and each submission's reserved bytes are released when it settles (attach done, reject, or the session closing), so a slow paste/confirmation cannot let a caller retain unbounded queued-clone memory. The ceiling is ONE budget per session, shared by the §5.8 facade and the raw session it exposes through `session`, so a caller mixing both surfaces is still bounded by 200 MiB in total. Ergonomic `send`/`stream` facade turns retain their reservation through the real turn boundary to cover acceptance replay (§5.8); raw facade submissions release it when submission settles. Because a send on a TERMINAL session is guarded first, a malformed/over-limit `images` on a stopped/killed/torn-down session rejects with `session_not_running` (the terminal contract), not `invalid_image`. The lifecycle turn transition is deferred until AFTER a successful attach, so an attach rejection leaves readiness untouched and never wedges the queue; a raw materialization failure (e.g. disk-full) is surfaced as the typed `image_attach_failed`, not a raw platform error. Each image's attach is CONFIRMED by its `[Image #N]` chip on the composer prompt-glyph line (so unrelated screen text cannot spoof it); an unconfirmed image (chip not seen within 10 s) or a clipboard read/write failure rejects with `image_attach_failed`, submits no text, and best-effort clears the composer draft so staged images do not leak into a later turn (a session that terminates mid-attach rejects with `session_not_running`). Bytes are written to a short-lived temp file Elwood attempts to remove after the submission is attached (best-effort; a persistently failing removal falls to OS temp reaping). |
 | C-API-45 | §5.3 | Claude attaches an image by bracketed-pasting its ABSOLUTE path into the composer (the delivery a terminal produces on drag-and-drop); Claude reads and encodes the file itself and shows an `[Image #N]` chip. This is pure PTY text and works on every platform. |
 | C-API-46 | §5.3 | Codex attaches an image from the OS clipboard: Elwood snapshots the user's clipboard ONCE (rejecting with `image_attach_failed` if the snapshot fails, before mutating anything), then for each image in order writes it onto the macOS `NSPasteboard` as a native image (`public.tiff`), sends Ctrl+V, and waits for the `[Image #N]` chip; after all images it restores the single snapshotted clipboard (best-effort, text contents). The whole snapshot/set/paste/confirm/restore sequence holds a process-wide clipboard lock so concurrent Codex sessions cannot cross-attach. A pasted path is NOT an image on Codex. Codex image attachment is macOS-only: `images` on a non-macOS Codex session rejects with `unsupported_platform` and submits nothing. |
 | C-API-47 | §5.8 | The ergonomic `ClaudeSession`/`CodexSession` construct synchronously with the same options as `startClaude`/`startCodex` (with `cwd` defaulting to `process.cwd()`), do NOT start the underlying session at construction, and start it lazily on the first `send`/`stream` or on an explicit `start()`. `start()` is idempotent and concurrent-safe (a second `start()`, or a `send`/`stream` during startup, awaits the same in-flight start), and a startup failure rejects the triggering call with the same typed `ElwoodError` the factory would throw. The started underlying session is exposed via a read-only `session` accessor (undefined until started). |
-| C-API-48 | §5.8 | `stream(prompt, options?)` returns an async iterable that yields the SIMPLIFIED typed events of exactly one turn in arrival order — `{type:"text"}` for `assistant_message`, `{type:"thinking"}` for `reasoning`, `{type:"tool_call",name,input?,toolCallId?}` for `tool_call`, `{type:"tool_result",name?,output?,toolCallId?}` for `tool_result` — and no other activity kind. A tool event carries the adapter's normalized `toolUseId` as `toolCallId` when available so calls and results can be correlated. The facade subscribes to `activity` BEFORE submitting the prompt (no early event of the turn is missed); turn isolation rests on SERIALIZATION — the serialized slot is held until the agent reaches its real boundary (not until the consumer stops reading) so a prior turn's activity never bleeds into the next — with `turnId` binding as an additional refinement where the adapter tags it (Codex; Claude transcript activity has none). An idle `ready` may complete the turn only after positive acceptance from `UserPromptSubmit`, turn content, or `Stop`; an unaccepted idle transition waits the no-oracle quiet window, replays the same submission at most twice, and then fails with `wait_timeout` instead of reporting an empty success. The iterator ends via the completeness oracle: once an accepted `ready` is observed, it ends the instant the collected assistant text contains the `Stop` hook's `last_assistant_message` (used as a completeness signal only, never displayed); with no such signal it ends after a bounded quiet window; a terminal status ends it IMMEDIATELY. There is NO whole-turn timeout by default (a live turn may run for hours); a caller may pass an opt-in `timeoutMs` ceiling, ARMED ONLY AFTER submission (a turn begins on submission, so the ceiling never rejects a prompt still queued behind readiness that then submits), and a `catchUpMs` cap (default 10000 ms) armed once an accepted `ready` fires throws `wait_timeout` if the transcript never catches up — including when a NON-EMPTY expected text never appears (a promised completion that never arrives is a failure, not a quiet settle). |
+| C-API-48 | §5.8 | `stream` yields one turn's ordered text/thinking/tool-call/tool-result events with the §5.8 fields and `toolUseId` correlation. It subscribes before submission and serializes through native completion/drain, beyond consumer settlement. Codex binds only authenticated post-owned-Enter UserPromptSubmit with adapter-normalized payload correlation; pre-acceptance content and prior Stop cannot bind/finish. Tagged content and confirmed Stop match that generation; untagged content relies on serialization. Hookless completion requires its classified native end, fresh post-Enter output and no block; interrupt return is insufficient. Selected loops reserve before staging; persona/loop boundaries drain before caller collection. Claude is untagged. Passive idle completion requires positive UPS/content/Stop acceptance; unaccepted idle waits the quiet window, replays at most twice, then fails `wait_timeout`. Initial/replay input awaits fresh empty evidence; consumer settlement cancels recovery, while slot/images survive until native boundary/drain and physical cleanup. Blocked cleanup precedes successor writes; pre-replay ready cannot release a later running replay after consumer failure. Accepted ready completes when collected text contains its Stop oracle (never displayed), or after bounded quiet without an oracle; terminal status ends immediately. Whole-turn timeout defaults off; optional `timeoutMs` arms once at first physical Enter, before empty confirmation and never while queued. `catchUpMs` (default 10000ms) starts at accepted ready and fails `wait_timeout` if promised text, including nonempty text, never arrives. |
 | C-API-49 | §5.8 | `send(prompt, options?)` resolves with the turn's assistant text: the `text` of every `type:"text"` stream event, in order, joined by `\n\n` between distinct assistant messages, and NOTHING else (no thinking or tool text). A turn with no assistant text resolves to the empty string. `send` and `stream` share one turn boundary, so a `send` resolves exactly when the equivalent `stream` iterator ends. |
 | C-API-50 | §5.8 | Ergonomic turns are SERIALIZED: overlapping `send`/`stream` calls queue and run one at a time in call order, so one turn's yielded/collected activity never interleaves with another's. |
 | C-API-51 | §5.8 | `close()` stops the underlying session (falling back to `kill` on a stop failure) and is a no-op when the session never started, so it is safe to call in a `finally`. When a lazy start is IN FLIGHT, `close()` awaits that same start and stops the resulting session (never orphaning a session whose launch resolves after `close()` returned); a launch that REJECTS leaves nothing to close. When BOTH stop and kill fail, `close()` throws `termination_failed` carrying BOTH the stop `cause` and the kill `killCause` (neither diagnostic is lost). |
@@ -93,7 +96,7 @@ Each criterion has:
 | C-LOOP-05 | §5.9 | A fixed loop first becomes due after its full interval plus delay-only jitter and submits only through the ordinary readiness-safe path. |
 | C-LOOP-06 | §5.9 | Idle loops use five continuous non-loop-activity-free minutes plus jitter; non-loop activity resets all, while a completed loop turn rearms only its origin and leaves peers eligible. |
 | C-LOOP-07 | §5.9 | Stable jitter is derived from ID at creation, falls in `0..min(10% cadence, 30s)`, never advances a due time, and is persisted as restore authority. |
-| C-LOOP-08 | §5.9 | A due loop blocked by liveness/readiness submits at most once at the next ready transition; missed occurrences do not accumulate and stop/exit discards transient due state. |
+| C-LOOP-08 | §5.9 | A due loop blocked by liveness/readiness submits at most once at the next eligible ready transition; ergonomic turns hold loop delivery from before initial submission through their real boundary without blocking caller recovery. Nested holds release independently; missed occurrences do not accumulate and stop/exit discards transient due state. |
 | C-LOOP-09 | §5.9 | Due loops commit serially, one per ready transition, ordered by due time then ID; fixed clocks restart from submission and idle origin clocks from completing readiness. |
 | C-LOOP-10 | §5.9 | Live scheduling/submission failure emits redacted failure evidence and rearms fresh unless the session is non-live, when the persisted definition waits for resume. |
 | C-LOOP-11 | §8.2 | The loop sidecar stores stable identity, cadence, exact prompt, jitter, creation, and expiry but no live timer or transient scheduling state. |
@@ -127,8 +130,9 @@ Each criterion has:
 |---|---|---|
 | C-PERF-01 | §9.2 | Version/capability probes run asynchronously and never block the host process's event loop, so a roster of concurrent spawns does not serialize on a single thread. |
 | C-PERF-02 | §9.2 | Each adapter's `--version` is read at most once per parent process; concurrent first reads share a single subprocess, later reads reuse the cached result, and the cache is invalidated after every coordinated `autoupdate` attempt, including a failed or peer-owned attempt. |
-| C-PERF-03 | §9.2 | Any non-PTY probe (`--version`, `--help`, `update`) that exceeds the default runtime timeout (15s) or per-stream byte cap (1,000,000 bytes) is killed. A killed/failed `--version`/`--help` probe surfaces through `*_start_failed` with `cause`/`errno` (`ETIMEDOUT`/`E2BIG`) preserved in `details`; a killed/failed `update` probe is best-effort and instead surfaces the live `agent_update_failed` warning (same bounded diagnostics) without blocking startup. Probes that exit or fail to spawn on their own are not signaled. |
-| C-PERF-04 | §9.2 | With `autoupdate`, concurrent callers in one parent process share one update, and separate Elwood parent processes for the same macOS user and adapter serialize through an atomic lease in a stable account cache independent of `TMPDIR`. A contender waits asynchronously for the active updater, skips its duplicate attempt, invalidates its local caches, and validates the installed version; none races a second global update. The lease records owner identity and a unique generation: a live owner is never evicted solely because the stale bound elapsed, dead-owner recovery is serialized, and cleanup cannot remove a successor generation. |
+| C-PERF-03 | §9.2 | Any non-PTY probe (`--version`, `--help`, `update`) that exceeds the default runtime timeout (15s) or per-stream byte cap (1,000,000 bytes) is killed. A killed/failed `--version`/`--help` probe surfaces through `*_start_failed` with `cause`/`errno` (`ETIMEDOUT`/`E2BIG`) preserved in `details`; a killed/failed `update` probe is best-effort and instead surfaces the live `agent_update_failed` warning (same bounded diagnostics) without blocking startup. Abort cleanup retries process-group termination, falls back to the direct child after repeated group-signal failure, and awaits exit within an additional one-second bound. A group id is signaled only while its leader (the direct child) is unreaped; once the leader is reaped the possibly-reissued number is observed, never signaled. Unresolved aborted groups retain an asynchronous in-process reaper without prolonging host shutdown or retaining captured output. Cleanup confirmed within the bound reports no cleanup error; unconfirmed cleanup adds a content-free `cleanupErrorCode` and a diagnostic-only `cleanupProcessGroupId` to the probe's typed error details. Probes that exit or fail to spawn on their own are not signaled. |
+| C-PERF-04 | §9.2 | With `autoupdate`, concurrent callers in one parent process share one update, and separate Elwood parent processes for the same macOS user and adapter serialize through an atomic lease in a stable account cache independent of `TMPDIR`. A contender waits asynchronously for the active updater, skips its duplicate attempt, invalidates its local caches, and validates the installed version; none races a second global update. The lease records owner identity and a unique generation: a live owner is never evicted solely because the stale bound elapsed, dead-owner recovery is serialized, and cleanup cannot remove a successor generation. The lease is published atomically by renaming a staged directory that already holds the complete owner record, so a claimant killed mid-claim cannot leave an ownerless or partially written lease that suppresses later updates; the lease is retired atomically on release — renamed away before deletion — so a contender polling during release sees a whole lease or none, never an ownerless one it would recover as stale and follow with a duplicate update. A release that cannot rename removes the lease in place instead of leaving a live owner's lease standing. Each lease holder removes a bounded number of that adapter's leftovers of both kinds, claim staging and retired lease directories, under one shared budget. Contenders stop waiting after 60 seconds with an `update_active` warning and never evict a still-live lease. An aborted update probe's process group that cannot be confirmed gone is observed for one further second without being signaled, and if still live is recorded as the lease's only holder: contenders skip immediately with `update_active`, and recovery removes the lease only once every recorded group has exited, whatever its age. A group record that cannot be written is retried and the lease released once the groups exit, so it never holds exclusion for the owner's lifetime. |
+| C-PERF-06 | §4.1 | PTY rendering preserves byte order without a per-chunk timer delay; adjacent chunks may be coalesced into batches of at most 64 KiB with a 4 ms flush window and one completed-frame observation per batch. Real PTYs pause at 1 MiB unrendered UTF-8 data and resume below 512 KiB, without dropping bytes; one delivered chunk may exceed the threshold, and a paused PTY resumes at child exit and is not paused again. Dispose settles pending render promises and suppresses subsequent render notifications. |
 
 #### C-CLAUDE: Claude Startup And Settings (§4, §7, §9)
 
@@ -147,14 +151,16 @@ Each criterion has:
 | C-CLAUDE-11 | §5.1 | Claude's browser tools onboarding prompt is declined through PTY input regardless of `autotrust`, with `startup_prompt` activity emitted under the `browser_tools` label. |
 | C-CLAUDE-12 | §5.1 | `startClaude` forwards `model` to Claude's `--model` launch flag. |
 | C-CLAUDE-13 | §4.3 | `tools` emits Claude's `--tools` allowlist flag as one comma-separated value, with an empty array encoding `--tools ""` (all tools disabled); it is forwarded across resume like the other tool options. |
-| C-CLAUDE-14 | §5.1 | Under `autotrust`, Claude's allowlisted skill/plugin/MCP trust prompts are each answered once and emit `startup_prompt` activity under their `skill_trust`/`plugin_trust`/`mcp_trust` labels. Recognition is the only guard: a prompt is recognized solely by its HEADER wording outside the numbered or cursor-selectable option region (so an option-only trust phrase cannot spoof one), and once recognized Elwood sends or navigates to the first affirmative option in the current frame — the agent is never left waiting. When a recognized prompt's affirmative option has not rendered in the current frame yet, Elwood emits a fire-once transient `attention` activity and keeps watching so a later frame carrying the option is still answered; this render-delay state is TRANSIENT and no warning is emitted for it. An off-allowlist first-run prompt is never auto-answered. Per the say-yes policy there is deliberately no per-dialog region binding, so a second stacked dialog's affirmative in the same frame is an accepted consequence, not a defended boundary. |
+| C-CLAUDE-14 | §5.1 | Under `autotrust`, Claude's allowlisted skill/plugin/MCP trust gates receive bounded safe automation, with `startup_prompt` emitted only after confirmed clearance. Header, native rows, and affirmative bind to one active dialog; transcript/option-only phrases and unrelated options never authorize writes. Partial rendering remains retryable, with at most one transient attention per generation. Unsupported or expired gates remain input-blocking and use the recoverable fallback in C-TRUST-01; off-allowlist prompts are never answered. |
 | C-CLAUDE-15 | §5.4 | Claude `assistant_message`, `tool_call`, and `tool_result` activities are sourced from the committed transcript the CLI writes at `transcript_path`, never from the `Stop` hook's `last_assistant_message`; an un-sent ghost-text / composer draft therefore never becomes an `assistant_message`. |
-| C-CLAUDE-16 | §5.1 §5.4 §5.7 | A Claude startup prompt Elwood auto-answers is marked settled and emits its `startup_prompt` activity only after its PTY `sendInput` write fulfills. A rejected write emits NO `startup_prompt` activity, leaves the prompt un-settled so a later frame re-attempts it, and surfaces a bounded, content-free `startup_prompt_write_failed` warning carrying only the prompt label. |
+| C-CLAUDE-16 | §5.1 §5.4 §5.7 | A Claude startup prompt Elwood auto-answers is marked settled and emits its `startup_prompt` activity only after its PTY `sendInput` write fulfills; trust automation with live frames also confirms the native dialog cleared. A write rejected while the session remains live emits NO `startup_prompt` activity, leaves the prompt un-settled so a later frame re-attempts it, and surfaces a bounded, content-free `startup_prompt_write_failed` warning carrying only the prompt label. Browser-tools disposal cancels undelivered diagnostics under C-CLAUDE-22. |
 | C-CLAUDE-17 | §5.1 | A Claude startup banner showing a lapsed, revoked, or absent login that only directs the user to re-run `/login` (`Login expired`, `Session expired`, `OAuth token revoked`, or `Not logged in`, each paired with a `run /login` recovery hint) is treated as an authentication failure and rejects `startClaude` with `claude_not_authenticated`, exactly like the explicit `not authenticated` banners — the session is torn down rather than reported as usable. Matching is anchored on the `/login` recovery directive so an unrelated mention of "login" does not trip it. |
 | C-CLAUDE-18 | §5.3 §5.7 | When a lapsed/revoked-login banner (per C-CLAUDE-17) appears on a Claude session that has ALREADY reached readiness — i.e. login expires mid-session — Elwood surfaces a typed, content-free `login_expired` warning (and its `warning` activity) carrying only a bounded `recoveryCommand` of `/login`. Detection is edge-based so a banner persisting across many frames does not re-emit, so a session warns at most once for its login expiring; the session is left ALIVE (no forced terminal transition) so the caller can recover in place via `session.login()`, tear down, or re-authenticate out of band. |
 | C-CLAUDE-19 | §5.4 §7A.4 | A committed Claude assistant `thinking` content block surfaces its plaintext extended-thinking as a `reasoning` activity carrying that text, sourced from the committed transcript exactly like `assistant_message` (C-CLAUDE-15) — no hook exposes it. Only ASSISTANT thinking is surfaced and empty thinking is dropped; a `redacted_thinking` block (opaque encrypted `data`, no readable text) produces no activity. |
 | C-CLAUDE-20 | §5.1 §5.2 | `reasoningEffort`, when supplied to `startClaude`/`resumeClaude`, is validated against the `ClaudeReasoningEffort` enum (`low`, `medium`, `high`, `xhigh`, `max`) before spawn — an out-of-enum value rejects with `claude_invalid_reasoning_effort` (message listing the valid values) and no process is spawned — and a valid value is forwarded to Claude's `--effort` launch flag. It is independent of `model`, applies to the launched session only, and is not persisted across resume (a resume must re-supply it). |
 | C-CLAUDE-21 | §5.1 §5.4 | Claude's one-time bypass-permissions acceptance dialog (header wording `Claude Code running in Bypass Permissions mode`, affirmative `Yes, I accept`, decline `No, exit`) is an allowlisted trust prompt: under `autotrust` it is recognized by its header wording outside the option region, answered once by selecting the affirmative in numbered or cursor layouts, and reported as `startup_prompt` activity with label `bypass_permissions`; with `autotrust` off it is a blocking prompt. The persistent `bypass permissions on` footer of a running session never matches, and a CLI refusal of bypass mode surfaces as the ordinary start failure. |
+| C-CLAUDE-22 | §5.1 §5.4 §9 | Non-trust Claude startup automation (the browser-tools `Esc` decline) is bound to session disposal, exactly as trust automation already is. After the session begins closing (`stop()`, `kill()`, or PTY exit) no decline is attempted, and a decline already in flight settles as a cancellation. The PHYSICAL write is bound too, not just its reported outcome: the non-trust automation barrier parks on render settlement, so it re-checks disposal after that await and abandons `sendInput` rather than delivering a stale key to a closed PTY. For the browser-tools decline, neither `startup_prompt` nor an undelivered `startup_prompt_write_failed` is emitted after close; each warning is checked at delivery even if an earlier warning listener starts shutdown. |
+| C-CLAUDE-23 | §5.7 | Native Claude login-renewal notices emit `login_expiring` warning and activity with `expiresInDays` and `/login`, including startup and resume. Welcome banners and empty-composer footers support wrapped rows; conversation/draft text is excluded. Each countdown value emits once per live session. Early warnings reach immediate post-start subscribers. Status and input remain usable; no automatic login or persistence occurs. |
 
 #### C-CODEX: Codex Startup And Config (§4, §7A, §9)
 
@@ -165,22 +171,23 @@ Each criterion has:
 | C-CODEX-03 | §5.5 | `model`, `profile`, `sandbox`, `approvalPolicy`, and `configOverrides` options are reflected in Codex launch policy. |
 | C-CODEX-04 | §9.2 | Startup checks Codex CLI version and fails with `codex_version_unsupported` when below the configured minimum. |
 | C-CODEX-05 | §10 | Missing `codex` fails with `codex_not_found` and a useful message. |
-| C-CODEX-06 | §4.4 | Codex hooks are trusted by `hookTrust="trust-all"`, the bypass flag when supported, or by answering the allowlisted `Hooks need review` TUI prompt once regardless of `autotrust` (hook trust is Elwood's own integration; see C-CODEX-15). |
+| C-CODEX-06 | §4.4 | Codex hooks are trusted by `hookTrust="trust-all"`, the bypass flag when supported, or by answering the allowlisted `Hooks need review` TUI prompt once regardless of `autotrust` (the bypass trusts all configured hooks, including third-party hooks; see C-CODEX-15). |
 | C-CODEX-07 | §5.6 | `resumeCodex` fails explicitly when Elwood has not persisted a Codex resume id. |
 | C-CODEX-08 | §5.5 | `autoupdate: true` runs `codex update` before spawning Codex. |
 | C-CODEX-09 | §5.7 | Codex MCP startup warnings are parsed from terminal output into typed warning events with server names and recovery commands. |
 | C-CODEX-10 | §9.2 | `autoupdate: true` rechecks the Codex version after running `codex update`. |
 | C-CODEX-11 | §5.5 | `autotrust: true` answers Codex's directory trust prompt through PTY input and emits `startup_prompt` activity. |
-| C-CODEX-12 | §5.5 | If Codex still shows an interactive update prompt inside the TUI, Elwood selects the skip/continue-without-updating option by label. The skip is EDGE-triggered: a persistent update screen starts one bounded response operation (not one per rendered frame), but that operation re-reads the current rendered frame before every retry and writes only when the original first-party prompt generation remains active and the frame exposes its safe numbered choice. It stops without writing when the generation clears or changes and fails boundedly if that prompt loses its safe choice or exhausts retries; the CLI converts an unanswerable blocked update into `blocked_prompt` even without a whole-run timeout. The skip RE-ARMS once the update screen leaves the frame, so an update prompt that REAPPEARS after Codex restarts (e.g. the update did not take and the same screen returns) is skipped again rather than leaving the session stuck on it. Every recognized update screen is input-blocking until its rendered frame clears: a captured first-party banner blocks before its options render, and a following safe-option-only continuation frame stays latched as the same prompt. Generic agent prose containing "update available" and Codex's passive installation notice do not activate the blocker. Readiness and queued persona/caller input therefore cannot select the default "Update now" action. |
+| C-CODEX-12 | §5.5 | If Codex still shows an interactive update prompt inside the TUI, Elwood selects the skip/continue-without-updating option by label only when a validated first-party banner remains in the current frame before every automated write. Bannerless frames never authorize selection, including previously observed option bindings; retained input blocking remains until positive native composer clearance. Current bounded first-party option snapshots replace old bindings rather than accumulate them. Removal or renumbering of a safe binding invalidates the old retry before frame observation; a valid bannered replacement starts a fresh generation. When the update action is visible, the selected safe option must follow it and must not itself perform the update; without that action, no ordering constraint applies. Choices belong to one current native numbered block; numbered pre-banner prefixes, duplicate or restarted numbering, unknown option labels, and unrelated surrounding rows withhold automation while a recognized banner remains blocking. Such recognized ambiguity permanently revokes its active attempt; bannerless choices cannot restore it, and fresh unambiguous first-party banner evidence with a valid current safe choice starts a new attempt. After revocation, banner-only or action-only repaints cannot reauthorize later bannerless choices or renew grace. An unknown or blank replacement permanently revokes its attempt; bannerless choices cannot reauthorize it, and fresh first-party banner with a current safe choice is required. Authoritative positive native composer clearance preserves the completed attempt’s settlement; live sessions decide after the current retained input hold is classified, never from composer text alone. One unambiguous changed first-party version banner supersedes the prior appearance without needing an intervening clear; old retries reject it before writing, while the new appearance may start its own bounded attempt. Generation-tagged `codex-update-prompt` attention renews CLI grace once for an unambiguous changed banner or a fresh unambiguous banner with a current safe choice after revocation, including the same version pair; redraws and duplicate or stale generations never extend it. The skip is EDGE-triggered: a persistent update screen starts one bounded response operation (not one per rendered frame), but that operation re-reads the current rendered frame before every retry and writes only when the original first-party prompt generation remains active and the frame exposes its safe numbered choice. It stops without writing when the generation clears or changes and fails boundedly if that prompt loses its safe choice or exhausts retries; an exhausted operation stays latched until the update screen clears, and a completion from an earlier generation never re-arms the current one — once superseded by a later appearance, its late success or rejected write settles as a quiet cancellation (no `startup_prompt`, no `startup_prompt_write_failed`), as does a write rejected after its own screen has already cleared; the CLI converts an unanswerable blocked update into `blocked_prompt` even without a whole-run timeout. The skip RE-ARMS after authoritative positive native composer clearance or a fresh first-party banner with a current safe choice, so an update prompt that REAPPEARS after Codex restarts (e.g. the update did not take and the same screen returns) is skipped again rather than leaving the session stuck on it. Every recognized update screen is input-blocking until its rendered frame clears: a captured first-party banner blocks before its options render, and bannerless continuation choices remain withheld even if they match previously observed bindings. Bannerless frames cannot introduce bindings or authorize input. Evidence is bounded to 32 options and 200 characters per label; overflow withholds automation for that appearance, while a later validated first-party banner with a safe option block within both limits may supersede it once; redraws cannot restart that fresh attempt. Changed bindings invalidate captured retries; a valid bannered replacement with a safe choice owns a fresh generation and grace. Generic agent prose containing "update available" and Codex's passive installation notice do not activate the blocker. Readiness and queued persona/caller input therefore cannot select the default "Update now" action. After a recognized update is replaced, input remains held through unknown or partial frames until completed live native-composer clearance. A continuously visible pre-update composer cannot clear replacement text above it; after it disappears, a newly appearing native composer may clear with resumed history. The retained hold does not start without a prior recognized update and reports `codex-unidentified-dialog` only when no specific blocking rule matches. Closing cancels retry timers and pending automated keys; disposal prevents new attempts and late success or write-failure telemetry. A fulfilled skip write reports answered only after positive native composer clearance; missing readers and unknown replacements cancel quietly. |
 | C-CODEX-13 | §10 | An immediately failing or unusable Codex process fails with `codex_start_failed` or a more specific typed error. |
-| C-CODEX-14 | §5.3 | `setModel` on Codex restores the user's prior `config.toml` default via compare-and-swap after the CLI persists its picker selection, skipping with the `codex_default_model_persisted` warning instead of clobbering concurrent edits. The restore is written atomically (sibling temp file + rename, mode preserved, a symlinked config written through to its target) so a crash mid-restore can never leave the user's config truncated. When no `config.toml` existed before the switch and the CLI created one, there is no snapshot to restore: the new file is left in place and the same warning code carries a message saying so (not a false "changed in other ways"). |
-| C-CODEX-15 | §5.5 | Codex's directory-trust prompt is answered only under `autotrust` (blocking on the human when off); Codex hook trust — Elwood's own integration — is answered regardless of `autotrust` and is NOT classified as blocking. Each is recognized only by its HEADER wording on a non-option line (so an option-only phrase cannot spoof it) and, once recognized, answered from the frame's affirmative option — the agent is never left waiting. When a recognized prompt's affirmative option has not rendered yet, a fire-once transient `attention` activity is emitted and Elwood keeps watching so a later frame answers it; this render-delay state is TRANSIENT and no warning is emitted for it. Each is answered once, from the shared allowlist. |
+| C-CODEX-14 | §5.3 | `setModel` on Codex restores the user's prior `config.toml` default via compare-and-swap after the CLI persists its picker selection, skipping with the `codex_default_model_persisted` warning instead of clobbering concurrent edits. The restore is written atomically (sibling temp file + rename, mode preserved, a symlinked config written through to its target) so a crash mid-restore can never leave the user's config truncated. When no `config.toml` existed before the switch and the CLI created one, there is no snapshot to restore: the new file is left in place and the same warning code carries a message saying so (not a false "changed in other ways"). Raw input taking over the picker revokes restore authority; a changed config stays intact with the same warning explaining the takeover. When the session terminates during the switch, the call rejects at once while the restore and the configuration lock wait for the CLI process to exit (bounded at five seconds) so a dying CLI cannot persist its selection after the restore. |
+| C-CODEX-15 | §5.5 | Codex directory trust is automated only under `autotrust`; hook trust remains enabled for all configured hooks regardless of `autotrust`. Successful bounded automation does not produce a human block. Each native header and affirmative belong to the same current dialog; partial rendering stays retryable. Unsupported or expired gates use C-TRUST-01's recoverable blocked fallback; no generic affirmative or stale input may answer another gate. |
 | C-CODEX-16 | §5.1 | Codex `assistant_message`, `tool_call`, and `tool_result` activities are sourced only from the committed transcript, never re-projected from the `Stop`/`PreToolUse`/`PostToolUse` hook payloads; those hooks emit plain `hook` activity, so a single reply or tool step is surfaced exactly once (mirrors C-CLAUDE-15). |
-| C-CODEX-17 | §5.4 §5.5 §5.7 | A Codex startup prompt Elwood auto-answers (directory/hook trust, `update` skip) is marked settled and emits its `startup_prompt` activity only after its PTY `sendInput` write fulfills. A rejected write emits NO `startup_prompt` activity, leaves the prompt un-settled so a later frame re-attempts it, and surfaces a bounded, content-free `startup_prompt_write_failed` warning carrying only the prompt label (mirrors C-CLAUDE-16). |
+| C-CODEX-17 | §5.4 §5.5 §5.7 | A Codex startup prompt Elwood auto-answers (directory/hook trust, `update` skip) is marked settled and emits its `startup_prompt` activity only after its PTY `sendInput` write fulfills; trust automation with live frames also confirms the native dialog cleared. A rejected write emits NO `startup_prompt` activity, leaves the prompt un-settled so a later frame re-attempts it, and surfaces a bounded, content-free `startup_prompt_write_failed` warning carrying only the prompt label (mirrors C-CLAUDE-16). For the Codex `update` skip this applies only while that update screen is still the current generation (C-CODEX-12). |
 | C-CODEX-18 | §5.4 §7A.4 | A committed Codex `reasoning` transcript item surfaces its human-readable text on the `reasoning` activity's `text` field: the `text` of every `summary[]` entry of type `summary_text`, or — when the reasoning is un-summarized — every `content[]` entry of type `reasoning_text`, joined by newlines. The always-present `encrypted_content` blob is never readable and is never surfaced. When neither carries prose (the common case with reasoning summaries disabled), the activity carries no `text`, exactly as a bare reasoning marker. |
 | C-CODEX-19 | §5.4 §7A.4 | A committed Codex shell/exec transcript item surfaces the ACTUAL command it ran as `tool_call` activity with its `toolInput`, and its output as `tool_result` activity with its `toolOutput`, across every representation the CLI emits — and the command is UNWRAPPED from the CLI's invocation machinery so consumers see the bare command, not the harness. The modern `exec` tool is a `custom_tool_call` whose `input` is a JavaScript snippet wrapping the call (e.g. `const r = await tools.exec_command({"cmd":"echo hi","workdir":…,"yield_time_ms":…}); text(r.output);`): Elwood extracts the inner `cmd`/`command` string (a `command` array is joined with spaces) and surfaces THAT as `toolInput`, discarding the JS wrapper and the non-command fields (`workdir`, `yield_time_ms`, `max_output_tokens`). A `function_call` (`shell`/`exec_command`) whose command is a JSON string in `arguments` is likewise unwrapped to its `command`/`cmd`. When the wrapper cannot be parsed, the raw `input`/`arguments` is surfaced unchanged rather than dropped. A `custom_tool_call_output` is classified as `tool_result` (not `other`), and a result's `output` — a plain string OR an array of `{ type: "input_text", text }` entries — is surfaced as `toolOutput` with the array entries' text joined; the `tool_result` `label` carries the `call_id` correlating it to its `tool_call`. So the real command and its output are surfaced as a clean paired call/result, never the JS harness and never a content-free `other` row. |
 | C-CODEX-21 | §5.5 §5.6 | `reasoningEffort`, when supplied to `startCodex`/`resumeCodex`, is validated against the `CodexReasoningEffort` enum (`none`, `minimal`, `low`, `medium`, `high`, `xhigh`, `max`) before spawn — an out-of-enum value rejects with `codex_invalid_reasoning_effort` (message listing the valid values) and no process is spawned — and a valid value is forwarded as the reserved `-c model_reasoning_effort=<value>` override, applied AFTER caller `configOverrides` so it wins over a hand-rolled duplicate. It is independent of `model`, applies to the launched session only, and is not persisted across resume (a resume must re-supply it). |
-| C-CODEX-20 | §5.4 | The Codex transcript reader is BOUNDED like Claude's: it reads in fixed-size chunks, discards any un-terminated record past a max-pending ceiling as an `"oversized"` drop, streams a large backlog across poll ticks under a per-scan chunk budget, and at PTY-exit drains only within a bounded chunk budget and wall-clock slice — accounting leftover bytes as an `"unread_backlog"` drop — so a hundreds-of-MiB transcript never OOMs or blocks the event loop. An unblocked `Stop` reads the committed turn with the per-pass scan budget, never the PTY-exit drain budget, so an arbitrarily long session (hundreds of turns) never exhausts that budget into false `unread_backlog` drops. Lost data is surfaced as the content-free, count-free `transcript_records_dropped` warning (a live event, cause-tagged, not persisted or counted) and a scan that throws is contained as `transcript_poll_stopped` (both `agent: "codex" | "claude"`). `finish()` is idempotent and terminal — a late `observe()` never restarts polling past `terminal:exit`. |
+| C-CODEX-20 | §5.4 | The Codex transcript reader is BOUNDED like Claude's: it reads in fixed-size chunks, discards any un-terminated record past a max-pending ceiling as an `"oversized"` drop, streams a large backlog across poll ticks under a per-scan chunk budget, and at PTY-exit drains only within a bounded chunk budget and wall-clock slice — accounting leftover bytes as an `"unread_backlog"` drop — so a hundreds-of-MiB transcript never OOMs or blocks the event loop. An unblocked `Stop` reads the committed turn with the per-pass scan budget, never the PTY-exit drain budget, so an arbitrarily long session (hundreds of turns) never exhausts that budget into false `unread_backlog` drops. Lost data is surfaced as the content-free, count-free `transcript_records_dropped` warning (a live event, cause-tagged, not persisted or counted) and a scan that throws is contained as `transcript_poll_stopped` (both `agent: "codex" | "claude"`). `finish()` is idempotent and terminal — a late `observe()` never restarts polling past `terminal:exit`. Codex transcript listener exceptions are isolated per delivery channel: raw and projected activity delivery are both attempted, later records and polls continue, and only the first failure per channel per watcher emits a content-free `transcript_listener_error` with `channel: "codex:transcript" | "activity"` (at most two). Diagnostics run in a microtask after synchronous transcript delivery, and final-flush diagnostics may follow `terminal:exit`. A warning listener failure cannot stop delivery. |
+| C-CODEX-22 | §5.4 §7A.4 | Committed Codex commentary response messages expose normalized `assistant_progress` with readable text, including ordered `output_text` arrays. Explicit non-final legacy agent-message mirrors remain `other` without text, preventing duplicate progress or false final replies. Final-answer behavior is preserved; analysis/unknown phases and encrypted reasoning do not become progress. Multiple progress updates precede the final reply without ending working state or entering ergonomic response text. |
 
 #### C-HOOK: Hook Bridge Coverage And Semantics (§6)
 
@@ -189,20 +196,26 @@ Each criterion has:
 | C-HOOK-01 | §6.1 | Generated Claude settings include bridge handlers for every supported Claude hook event. |
 | C-HOOK-02 | §6.2 | Hook bridge invocations route to the correct Elwood session using session-scoped identity. |
 | C-HOOK-03 | §6.3 | A hook event with no registered parent handler returns no decision to Claude. |
-| C-HOOK-04 | §6.3 | A timed-out hook handler returns no decision to Claude and emits `hookError`. |
+| C-HOOK-04 | §6.3 §7A.4 | A timed-out hook handler returns no decision and emits `hookError`. Finalizing Stop expires same-runtime-instance queue-backed input admission from context-preserving async continuations of its registered handler and hook-scoped observers of `hook`, `activity`, `hookError`/`hook_error`, and `hook_observer_failed`; late raw-session or lazy-facade queue-backed calls reject asynchronously with `wait_timeout` before image capture and terminal-state rejection. Prior admissions, unrelated callers/sessions (even with a reused Elwood ID), independently dispatched callbacks on pre-existing event sources, non-Stop hooks, raw keys, internal queue/loop work, and persistent transcript polling remain unaffected. |
 | C-HOOK-05 | §6.3 | A throwing/rejecting hook handler returns no decision to Claude and emits `hookError`. |
 | C-HOOK-06 | §6.3 | An invalid handler result returns no decision to Claude and emits `hookError`. |
 | C-HOOK-07 | §6.4 | Hook IPC input is runtime-validated before dispatch to parent handlers. |
 | C-HOOK-08 | §6.4 | `hook_event_name` narrows valid handler response types at compile time. |
 | C-HOOK-09 | §6.4 | Known Claude built-in tool names narrow `tool_input` types at compile time. |
 | C-HOOK-10 | §6.4 | Unknown or MCP tool names are represented through a safe extensibility path. |
-| C-HOOK-11 | §6.5 | `Stop` marks the session ready only when the Stop event is not blocked. |
+| C-HOOK-11 | §6.5 | `Stop` marks the session ready only when the Stop event is not blocked and no newer queue-backed caller prompt was physically submitted while its callbacks ran. Immediate callback input, including awaited `sendPrompt()`, must progress without waiting for Stop completion. |
 | C-HOOK-12 | §7A.1 | Generated Codex config includes bridge handlers for every supported Codex hook event. |
 | C-HOOK-13 | §7A.2 | Codex hook IPC input is runtime-validated before dispatch to parent handlers. |
 | C-HOOK-14 | §7A.2 | Codex `hook_event_name` narrows valid handler response types at compile time. |
-| C-HOOK-15 | §7A.3 | Codex `Stop` marks the session ready only when the Stop event is not blocked. |
+| C-HOOK-15 | §7A.3 | Codex `Stop` marks the session ready only when the Stop event is not blocked and no newer queue-backed caller prompt was physically submitted while its callbacks ran. Immediate callback input, including awaited `sendPrompt()`, must progress without waiting for Stop completion. |
 | C-HOOK-16 | §6.2 | Hook IPC waits for a complete framed request before dispatching and fails open on malformed complete requests. A single request is capped at exactly 8 MiB (8,388,608 bytes) measured on the ENCODED wire envelope (`{token, elwoodSessionId, input}` JSON plus its framing newline) — the identical byte count in the child bridge script (before it connects) and the parent server (as bytes arrive), so an escape-heavy input whose JSON encoding expands past the cap is rejected by both, never accepted by one and dropped by the other. An over-cap request fails open before auth/parse (child exits with no decision; server responds no-decision and closes) and does not emit a `hookError`. |
 | C-HOOK-17 | §6.4 | Claude hook IPC input validates event-specific payload fields and known tool input schemas before dispatch. |
+| C-HOOK-18 | §6.4 | Numeric hook fields must be FINITE. `NaN` and `±Infinity` are rejected at ingress and in `updatedInput` rewrites — for concrete tool schemas by their field checks, and for SCHEMA-LESS tools (MCP, generic, future) structurally over the whole value including nested records and arrays — so the bridge answers with no decision rather than serializing the `null` that `JSON.stringify` would emit for them. Structural validation rejects cycles without throwing and permits at most 128 edges from the root and 100,000 value visits counting primitives and each repeated child occurrence. Shared non-cyclic children remain valid within these limits. Structural values reject bigints, functions, symbols, boxed primitives, custom prototypes/callable serializers, proxies, and enumerable accessors without invoking them; child descriptors are not read beyond the visit budget. Invalid rewrites emit `invalid_response` and return no decision. |
+| C-HOOK-19 | §7A.2 | Codex tool-keyed hook routing resolves both the exact tool name and the `unknown` fallback from OWN properties only, so an inherited member is never dispatched as a handler. |
+| C-HOOK-20 | §6.1 | StopFailure ingress validates the common envelope while admitting absent or drifted diagnostic fields as optional unknown values; other hooks remain strict. Diagnostics use bounded nonblank details, the named error, or a generic rejection, never assistant text. |
+| C-HOOK-21 | §6.4 | Claude result validation and serialization use one detached snapshot of own enumerable data, rejecting accessors, custom serializers, proxies, boxed primitives, non-JSON values, cycles, and shapes exceeding 128 edges or 100,000 visits from the response root. Invalid responses fail open with `invalid_response`; later handler or activity-listener mutation cannot alter validated wire output or blocking decisions. |
+| C-HOOK-22 | §6.4 §5.7 §7A.2 | Claude hook inputs are deeply frozen before observation. Throwing Claude or Codex hook observers cannot truncate later hook-scoped notifications, replace validated wire or blocking decisions or skip readiness/Stop bookkeeping; Codex's initial-ready transition retains its separate synchronous C-API-42 fallback while returned listener Promise rejections use the bounded lifecycle warning sink. Each hook invocation or bridge-error delivery emits at most one bounded, content-free `hook_observer_failed` warning for the first failed phase; warning delivery failures do not recurse. Native observer Promises with normal reaction-attachment metadata have pending diagnostic retention capped at the newest 1,024 registrations per emitter; evicted rejections remain contained. Attachment throws are reported and do not cache an unattached Promise. |
+| C-HOOK-23 | §7A.2 | Codex hook inputs, including nested tool input, are frozen before parent observation or handler routing. Handler-owned responses are detached before validation; invalid data fails open. Native wire output and Stop blocking decisions are fixed before result activity observers, so later mutation cannot rewrite the decision or readiness. |
 
 #### C-HRESP: Hook Response Mapping (§6, §7)
 
@@ -251,6 +264,7 @@ Each criterion has:
 | C-LIFE-05 | §5.3 | A live `ClaudeSessionApi` (the started session) owns exactly one main Claude process; the lazy `ClaudeSession` wrapper (§5.8) owns none before start and that one after. |
 | C-LIFE-10 | §5.3 | `stop()`, `kill()`, and `teardown()` reap the full PTY process tree by SIGKILLing the leader's process group, so a descendant reparented to PID 1 after the leader exits (e.g. the CLI-spawned `hook-bridge.mjs`) is still killed and no process tree leaks across launch/quit cycles. |
 | C-LIFE-11 | §5.3 | A `teardown()` that rejects in-flight control-queue operations still completes: the rejected `sendMessage`/`compact`/model operation does not skip the process-group reap or remaining teardown steps. |
+| C-LIFE-12 | §9.4 | Runtime cleanup on stop, kill, teardown, and unsolicited exit drains received terminal output before disposing the renderer, so the final `terminal:data` tail is delivered (possibly after `terminal:exit`) instead of dropped. The drain ends only when a settle pass completes with no new PTY output received, shares one one-second budget after which a stalled renderer or never-quiet PTY is disposed anyway, never delays process-exit notification, terminal status, or the process-group reap, always disposes even when draining fails, and readiness cancelled at exit cannot be re-armed or submitted by a drained frame. |
 
 #### C-ERR: Error Model (§10)
 
@@ -301,15 +315,16 @@ Each criterion has:
 | C-CLI-15 | §12A.4 §12A.5 | Config and state reads and writes enforce private ownership, regular-file, symlink-safety, and atomicity constraints. |
 | C-CLI-16 | §12A.5 | CLI state defaults to the absolute XDG state base or `~/.local/state/elwood`, never the workspace, and one session identity has at most one live owner. |
 | C-CLI-17 | §12A.5 | Success, agent/cleanup failure, usage/config failure, timeout, and interruption map to statuses 0, 1, 2, 124, and 130 without cleanup masking a primary status. |
-| C-CLI-18 | §12A.6 | `--head` fails before launch without terminal stdin/stderr and rejects stream/verbose/debug/JSONL; otherwise it mirrors ordered raw PTY bytes (including full-screen VT/ANSI control sequences) only to terminal stderr, uses and follows its size, keeps final text/JSON stdout clean, treats raw Ctrl-C like SIGINT, and restores terminal input/display modes before final output on every handled outcome. Outstanding mirror work is capped at 4 MiB or 1,024 frames; overflow fails the run after draining accepted bytes and restoring the terminal instead of growing memory without bound. A terminal-gone error from an input handle already closed by its host is contained because only that host can then restore the terminal, and it does not replace a completed result. |
+| C-CLI-18 | §12A.6 | `--head` fails before launch without terminal stdin/stderr and rejects stream/verbose/debug/JSONL; otherwise it mirrors ordered raw PTY bytes (including full-screen VT/ANSI control sequences) only to terminal stderr, uses and follows its size, keeps final text/JSON stdout clean, treats raw Ctrl-C like SIGINT, stays attached through session cleanup so output received before the run ended (including the §9.4 drained tail) is mirrored, and then restores terminal input/display modes before final output on every handled outcome. Outstanding mirror work is capped at 4 MiB or 1,024 frames; overflow fails the run after draining accepted bytes and restoring the terminal instead of growing memory without bound. A terminal-gone error from an input handle already closed by its host is contained because only that host can then restore the terminal, and it does not replace a completed result. |
 | C-CLI-19 | §12A.4 | `config effective` prints validated effective launch/output values (including `head` and the full Claude tool posture) with config location/load state and per-setting provenance (including `auto-detected` for a probed agent), supports exact stored resume inspection using the same posture merge as launch, reads no prompt input, and starts no agent. |
 | C-CLI-20 | §12A.5 | Text validation errors use user-facing language, identify relevant paths and inherited-setting sources, suggest an unambiguous nearby long option, and retain the stable structured error code. |
 | C-CLI-21 | §12A.1 §12A.4 | When no flag, environment variable, or config key selects an agent, a new session (and `config effective`) probes the user's login shell for `claude` and `codex` concurrently and uses the first in that order whose command resolves, reporting source `auto-detected`; the probe never runs an agent, resume never probes, and when neither resolves the invocation fails before launch with code `no_agent_found` and status 2, naming both agents, an install hint, and the `--agent`/`ELWOOD_AGENT`/config selection paths. A probe that cannot run (missing or broken login shell, probe timeout) fails with the same code and status but names the shell and underlying error rather than claiming no agent is installed; adapter-option conflicts with an auto-detected agent say so and offer `--agent` for the other adapter. |
 | C-CLI-22 | §12A.2 §12A.4 | `--high-trust` / `--no-high-trust`, `ELWOOD_HIGH_TRUST` (strict boolean), and the `highTrust` config key layer with normal precedence and expand, for the effective adapter, to Claude `bypassPermissions` or Codex `danger-full-access` + `never`; an effective flag/environment `true` combined with an explicit per-agent posture flag or variable is a usage error naming both sources on new and resumed runs; saved per-agent posture keys are overridden by high trust while a saved `highTrust` yields field by field to explicit per-agent flags/variables; and `config effective` reports `highTrust` plus posture values whose source is the deciding high-trust source. |
 | C-CLI-23 | §12A.7 | `elwood resume <id> [options] [prompt...]` is a parse-time rewrite of `elwood run --resume <id>` sharing one resolution/execution path: stored adapter and workspace loading, `--cwd`/explicit-adapter/`--keep`/persona/`--ephemeral` rules, and positional-plus-piped prompt composition are identical; a missing id or an additional `--resume` is a usage error. |
-| C-CLI-24 | §12A.8 | `elwood sessions` lists private, owner-matched session records under the effective state directory without launching an agent, reporting id, adapter, workspace, ISO-8601 `createdAt`/`lastUsedAt`, `resumable`, and socket-presence `live`, ordered by most recent use; unreadable records are skipped with a stderr warning, an empty or absent state directory is a status-0 empty listing (stderr notice in text, empty array in JSON), text is an aligned header table, JSON is one version-1 `sessions` document, and JSONL, prompt words, or other run options are usage errors. |
-| C-CLI-25 | §12A.9 | `elwood interactive [id]` spawns the selected agent's own CLI in the foreground with inherited stdio, no PTY/bridge/automation/state, `SIGINT` passed through, and the agent's exit status; it fails with status 2 before spawning without terminal stdin and stdout or with `--output json|jsonl`, `--stream`, `--verbose`, `--debug`, `--head`, `--timeout`, `--persona`, `--image`, `--keep`, `--ephemeral`, `--resume`, or extra positionals; explicitly selected agent, model, effort, workspace, and posture map through the adapters' shared launch-argument builders while built-in posture defaults are omitted; and `[id]` loads the stored record with `--resume` semantics, merges stored posture field by field, and passes the agent's own conversation id or fails as `resume_unavailable`. |
-| C-CLI-26 | §12A.10 | `elwood models` without explicit `--agent` probes Claude then Codex sequentially despite environment/config agent defaults, associates each catalog with its adapter, applies each adapter’s settings and one shared timeout budget, retains partial successes alongside per-agent errors in one aggregate JSON document or an AGENT-column table, exits nonzero on incomplete results, and stops before launching another adapter after SIGINT. Explicit `--agent` preserves the single-agent contract: it starts a fresh headless session with normal setting precedence, lists models through the public picker operation without changing the model, always tears the session and its state down, prints an aligned table (`*` current, `(default)`) or one version-1 `models` document of `AgentModelOption` rows, maps timeout/interruption/blocked-prompt/agent-exit/picker failures to the existing error conventions and statuses, and rejects stream, head, persona, image, keep, resume, ephemeral, positional, and JSONL inputs as usage errors. |
+| C-CLI-24 | §12A.8 | `elwood sessions` lists private, owner-matched session records under the effective state directory without launching an agent, reporting id, adapter, workspace, ISO-8601 `createdAt`/`lastUsedAt`, `resumable`, and socket-presence `live`, ordered by most recent use; unreadable records are skipped with a stderr warning, an empty or absent state directory is a status-0 empty listing (stderr notice in text, empty array in JSON), text is an aligned header table, JSON is one version-1 `sessions` document, and JSONL, prompt words, or other run options (including `--show-session-id`) are usage errors. |
+| C-CLI-25 | §12A.9 | `elwood interactive [id]` spawns the selected agent's own CLI in the foreground with inherited stdio, no PTY/bridge/automation/state, `SIGINT` passed through, and the agent's exit status; it fails with status 2 before spawning without terminal stdin and stdout or with `--output json|jsonl`, `--stream`, `--verbose`, `--debug`, `--head`, `--timeout`, `--persona`, `--image`, `--keep`, `--show-session-id`, `--ephemeral`, `--resume`, or extra positionals; explicitly selected agent, model, effort, workspace, and posture map through the adapters' shared launch-argument builders while built-in posture defaults are omitted; and `[id]` loads the stored record with `--resume` semantics, merges stored posture field by field, and passes the agent's own conversation id or fails as `resume_unavailable`. |
+| C-CLI-26 | §12A.10 | `elwood models` without explicit `--agent` probes Claude then Codex sequentially despite environment/config agent defaults, associates each catalog with its adapter, applies each adapter’s settings and one shared timeout budget, retains partial successes alongside per-agent errors in one aggregate JSON document or an AGENT-column table, exits nonzero on incomplete results, and stops before launching another adapter after SIGINT. Explicit `--agent` preserves the single-agent contract: it starts a fresh headless session with normal setting precedence, lists models through the public picker operation without changing the model, always tears the session and its state down, prints an aligned table (`*` current, `(default)`) or one version-1 `models` document of `AgentModelOption` rows, maps timeout/interruption/blocked-prompt/agent-exit/picker failures to the existing error conventions and statuses, and rejects stream, head, persona, image, keep, show-session-id, resume, ephemeral, positional, and JSONL inputs as usage errors. |
+| C-CLI-27 | §12A.1 §12A.3 | Successful text runs print only the agent response by default, while retaining sessions. `--show-session-id` opts into the retained ID footer on stderr after successful cleanup; ephemeral runs emit none. JSON/JSONL retain their existing sessionId field. The flag is accepted by run/resume and rejected by interactive/models/sessions. |
 
 #### C-E2E: Real Adapter Flows (§12)
 
@@ -331,3 +346,42 @@ Each criterion has:
 | C-E2E-14 | §5.8 | Against a REAL Claude (or Codex) CLI, a lazily-started `ClaudeSession`/`CodexSession` answers two sequential `send` calls: the first returns non-empty assistant text, and the second — referring back to the first — returns text consistent with retained conversation context, proving `send` collects a turn's assistant text and the ergonomic layer preserves multi-turn context (C-API-47, C-API-49). |
 | C-E2E-15 | §5.8 | Against a REAL CLI, `stream(prompt)` for a task that DETERMINISTICALLY uses a workspace tool (reading a planted file) yields the turn's simplified typed events in arrival order — a `tool_call` FOLLOWED by its `tool_result`, and at least one `text` — and ends when the turn settles, verified against the installed CLI (C-API-48). |
 | C-E2E-16 | §5.1 §5.5 | Against the REAL CLIs, a session started with `highTrust: true` reaches `ready` on both adapters: Claude's rendered composer shows its bypass-permissions footer with no acceptance dialog left visible (answered when the installed CLI renders one), and Codex's persisted launch posture is `danger-full-access` / `never` (C-API-54, C-CLAUDE-21). |
+| C-E2E-17 | §5.4 §7A.4 | An isolated real Codex turn emits readable `assistant_progress` before its final `assistant_message`, retains running/ready lifecycle, and returns only final text through ergonomic `send()`, without tools or changes to parent configuration. |
+| C-E2E-18 | §5.10 §7 | Two isolated native Claude public-API turns accept grouped single/multiple choices and multiline alternative text, confirm complete native answers and answered closures, return only final replies, exclude submitted answer markers from question telemetry and Elwood-owned state, remove private artifacts and homes, and preserve parent configuration/authentication/environment. |
+| C-E2E-19 | §5.10 §7A.5 | In two isolated native Codex public-API turns, one asynchronous call raises three independently answerable queued questions and one Plan-mode call raises a three-question modal. `answerQuestions()` submits the queued long note, literal `Type your answer`, then color choice while the original turn remains running; the modal accepts None of the above, a named choice with long notes, and literal `Add notes`. Full committed native free-text answers and notes must match newline-normalized, outer-whitespace-trimmed values while preserving interior tabs, trailing spaces, multiline indentation, and more than 700 characters; queued selected labels are trimmed and modal selected labels remain exact, as specified in §5.10. Question events and normalized activities exclude submitted answers; Elwood-owned state stays answer-free, and private artifacts, native homes, and parent configuration are cleaned up or preserved as appropriate. |
+
+#### C-REVIEW: Maintainer automation (§16)
+
+| ID | Section | Criterion |
+|---|---:|---|
+| C-REVIEW-01 | §16 | Opening a same-repository PR produces one automatic review; pushes, edits, reopenings, and ready transitions do not start another review. |
+| C-REVIEW-02 | §16 | An already-approved head is skipped; minors and nits may be fixed without another review. |
+| C-REVIEW-03 | §16 | Only exact newly-created `/review` PR comments from current human writers qualify; authorization checks both author and requester before secrets, checkout, or review cancellation. |
+| C-REVIEW-04 | §16 | A complete validated twelve-dimension report with zero blockers and majors can approve. Publication preserves existing approvals, includes the run link and `/review`, and does not suppress a report or verdict when the head or base changes. |
+| C-REVIEW-05 | §16 | Both head and base must belong to this repository, with no base-branch trigger filter; current human writers and the official Dependabot author qualify, while forks and outside contributors do not. |
+
+### Launch hardening
+
+| ID | Spec | Criterion |
+| --- | --- | --- |
+| C-API-55 | §5.3 | Model-picker operations own the input queue until they settle. Overlapping model calls and messages cannot interleave; the queue wait and the operation share `timeoutMs`, so a timed-out operation still queued never opens a picker; the deadline and termination prevent later writes. A failed operation's own dialog is cancelled within one additional second before the slot is released: one Escape per stage (a cancelled follow-up returns to the picker), never repeated, none after termination. A dialog that survives keeps queued input, commands, and `/login` held while visible. Only a bottom-most dialog region counts; dialog text above a conversation or composer row is never cancelled or held on. A partially painted Claude switch dialog holds input and is never written to, and `setModel` does not settle while one is visible. When a submitted picker command has not rendered its dialog by the failure, or an accepted stage can still paint its follow-up, the slot is held for that same second and a dialog appearing in it is cancelled; a dialog repainting after a clear frame gets its own Escape. Model picker text already visible when the operation begins rejects it with `model_automation_failed` and no writes or hold. Initial command dispatch revalidates foreign-picker absence; public raw input revokes the active operation and its cleanup authority. Foreign-picker holds survive partial repaints and require five consecutive positive native-composer observations to release ordinary input. |
+| C-TRUST-01 | §5.4 | Automatic trust writes require one current native dialog with allowlisted header, native explanatory/path/option rows, and exact affirmative; where the native dialog has explanatory copy, a header without it never authorizes a write. Candidate trust headers hold readiness and queued input even when unsupported; transcript provenance is retained. Human-owned candidates retain their hold through partial or unknown replacements until positive composer/successor clearance. Live Codex clearance requires the visible native input cursor, text, and title from one completed render; newly received output invalidates that proof until rendered, and native approval headers override a stale visible composer cursor. One session-owned coordinator gives generations separate reservations and a five-second deadline from first candidate. Every numbered/cursor write revalidates generation, header, and choice; partial native painting and cursor movement remain supported. A fulfilled confirmation settles answered only on verified native composer/successor clearance. Replacements and stale completions cannot settle or release a newer generation. Expiry produces existing recoverable blocked/attention without waiting for a frame, keeps input held, and does not warn as a PTY failure. New validity/generation re-arms bounded automation; unchanged redraws cannot reset expiry; raw human input can clear the gate. Stop/kill/teardown/startup cleanup/PTY exit cancel attempts and timers quietly. Only a live matching rejected write emits startup_prompt_write_failed. |
+
+#### C-SITE: Documentation Site Controls (§13)
+
+| ID | Section | Criterion |
+|---|---:|---|
+| C-SITE-01 | §13.1 | Landing gesture/front-back controls deliver only after complete requested/idle/rotation readiness and current eligibility, including absence of pending jump/wind-up. Pending loading suppresses autonomy. Recovery queues retain delivered ownership until activation or replacement; activation owns opening-turn resources before paint. Held movement, reset, reflow and supersession release obsolete delivery without closing active/outgoing poses, losing held movement on reflow, or dropping unrelated pending jump input. |
+| C-SITE-02 | §13.2 | Initial landing handoff waits for all retained idle pages without fetching rotation. Pre-ready input/visibility changes preserve preparation; teardown prevents late readiness/paint. Failure retains the fallback and reports the asset error; explicit boot retry can recover. After successful complete animation preparation, up to two idle pages remain renderable and reusable through playback switches and cache eviction until bank disposal. Failed or cancelled preparation establishes no shared lease; larger idle manifests use ordinary ownership. |
+| C-SITE-03 | §13.3 | Automatic moments/facing wait for complete requested/idle/rotation pages and start their delivery clock on success, within the eight-second pre-delivery wait. Publication revalidates exact prepared ownership without superseding a newer candidate/delivery. Obsolete task probes/preparation and matching queued delivery cancel without releasing newer manual or active pose owners. Requested and shared dependency failures report once and suppress automatic retries across actions until explicit preparation clears their failure state; geometry probes stay metadata-only. |
+| C-SITE-04 | §13.4 | Pickup control is immediate, but suspended playback waits for all owned sheets; movement preserves preparation, lifecycle cancellation prevents late delivery, and failures retry only on a new drag. |
+
+## Native questions
+
+| ID | Contract | Criterion |
+| --- | --- | --- |
+| C-QUESTION-01 | §5.10 | Immutable live snapshots and typed question/activity events share opaque IDs, deduplicate redraws, close from native evidence and never persist. |
+| C-QUESTION-02 | §5.10 | Complete answer validation rejects invalid/stale batches before writes; native controls bypass blocked ordinary writers, verify every physical write, revoke on human input/close, and resolve only on native acceptance. Unconfirmed physical writes retire the API request as unavailable while reserving native ownership, rejecting stale retries without replay until native closure. |
+| C-QUESTION-03 | §5.10 §7 | Claude grouped choices, checkboxes, alternative text and final review use matching native frames; direct hook answers retain precedence, unsupported layouts hold ordinary input without speculative writes. Completion requires matching AskUserQuestion identity, using matching ordered question definitions only when the completion omits a native ID. |
+| C-QUESTION-04 | §5.10 §7A.5 | Codex modal groups and independently accepted queued questions retain native identities across mirrors, require confirmed current editors, retire from native evidence without invented expiry, remain distinct from final replies, and do not reopen historical requests on resume. Every question must omit `isSecret` or use boolean `false`; unsupported or malformed flags prevent publication of the complete request. |
+| C-QUESTION-05 | §7A.5 | Codex question metadata and retired identities obey bounded count/UTF-8 budgets; overflow closes requests as unavailable and disables automation for the session without guessing input; opaque identities hold ordinary automation until explicit native turn end. Unchanged high-volume redraws do not republish candidates or repeatedly scan/copy the registry. |