The assembled harness (golden-fixture assembly): the HarnessSurface app composed end-to-end against a replayed fixture session. This is the first assembled, visually-demoable harness -- no agent lane, fixture events only.

This module is the pure(-ish) core: an init/update/render-shaped state machine over a plain map "model", built entirely from already- merged units. It never depends on raxol_agent (this module's own acceptance: "No agent lane required" -- see the "Command bifurcation" section below). It is deliberately NOT wired through Raxol.start_link/2 / the normal TEA Lifecycle -- the append-path/footer-viewport substrate this app renders through (Raxol.UI.Rendering.PaintAuthority.InlineAuthority/FlatAuthority) is a byte-level pinned-region writer, one layer BELOW the Preparer -> LayoutEngine -> UIRenderer -> ScreenBuffer pipeline the normal TEA runtime drives; there is no Component tree to mount here, so there is nothing for Lifecycle to add. examples/harness_fixture_demo.exs is the process-level driver (real tty, Raxol.Terminal.InlineDriver for raw input) built on top of this module's pure functions.

Glossary (the substrate vocabulary, one line each)

New to this lane? These terms recur, undefended, across this module, Raxol.UI.Rendering.PaintAuthority.InlineAuthority, and Raxol.Terminal.ScrollRegionManager -- this is the one anchor:

• DECSTBM -- the ANSI "set top/bottom margins" control (CSI top;bottom r): confines terminal scrolling to a row range. The harness uses it to split the screen into scrolling history (top) and a pinned footer (bottom).
• The pin / pinned footer -- the bottom N rows placed OUTSIDE the DECSTBM scroll region, so history scrolling never moves them; the only surface the harness ever repaints.
• Seal / seal-once -- writing a finished block into the history region exactly once, never repainted afterward; sealed rows eventually scroll into the terminal's own native scrollback, which this process cannot rewrite.
• Index-at-region-boundary -- a line feed on the scroll region's bottom row scrolls the region up one row (the top row is evicted toward scrollback) instead of moving the cursor; how both sealing and the overlay's footer-grow preserve content.
• Keyframe vs. repaint -- repaint/2 rewrites only footer rows whose content changed (a diff); keyframe/2 rewrites every footer row (the recovery / post-geometry-change path).
• Degenerate geometry -- a terminal too short to hold the footer plus a 2-row-minimum history region: DECSTBM cannot pin, and the harness degrades (or, for overlays, refuses) instead of pretending.

Composition (what this module assembles)

• The append path / footer viewport (InlineAuthority) or the degradation ladder (FlatAuthority, picked by ModeSelect.select/3) -- the paint substrate. :tmux_conservative routes through the same InlineAuthority as :inline_log (per ModeSelect's own moduledoc: there is no separate TmuxConservativeAuthority), so this module only branches on :flat vs. everything else.
• The block builder (Raxol.Harness.Projection) -- journal-fold: durable events become Blocks, item_delta traffic becomes the live tail.
• The block bodies (Raxol.UI.Components.Harness.BlockBody) -- fold-aware per-kind body rendering for expanded blocks.
• The status strip (Raxol.Harness.StatusStrip) -- the pinned status line.
• The composer (Raxol.UI.Components.Harness.Composer) -- the prompt.
• The keybind layer (Raxol.UI.Harness.Keymap) -- canonical event -> command.
• The input normalizer (Raxol.UI.Harness.InputEvent) -- canonical event normalization, the shim every input path goes through first.
• Raxol.Harness.Surface.ViewText -- this unit's own bridge from the Component tree's view maps to the paint authority's flat iodata() rows (see that module's doc for why truncation precedes styling).
• Raxol.Harness.UnreadDivider -- the pure attention-boundary policy behind the "N new since you looked" footer rule (see "The unread divider" section below).

Precondition #2 -- keymap-first dispatch (binding, load-bearing)

handle_input/2 normalizes the raw event exactly once (InputEvent.normalize/1) and calls Keymap.resolve/2 before ever touching the Composer. Only a :passthrough result reaches Composer.handle_event/3. This is the fix for the named failure mode (the composer's catch-all previously delegated every unhandled key into MultiLineInput -- component-first wiring killed ESC-interrupt AND Tab-steer dead): ESC/Tab are :always binds in Keymap.binds/0, so they are intercepted here unconditionally, regardless of composing?.

Precondition #3 -- the focus model

composing? defaults true (the composer starts focused -- matching the spec's own default). ESC (:interrupt) and Tab (:steer) are the documented exceptions: both are :always Keymap binds, firing regardless of composing?, and neither is a focus transition (ESC must never be swallowed as a focus operation, per Keymap's own moduledoc).

Keymap's :not_composing guard (z/j/k) means block-navigation commands only ever resolve once focus has ALREADY left the composer -- Keymap itself has no bind that performs that transition (there is no dedicated "focus transcript" key in Keymap.binds/0 today; a v1 scope note, not a missing precondition -- no keybind spec covers one). This module therefore owns the transition as explicit, directly-callable API: focus_transcript/1 (composing? false, enables jump/fold) and focus_composer/1 (composing? true, the default). A future key or mouse binding (a command palette, a focus-lens hover per ADR-0012) wires one of these directly; today's fixture-only assembly exposes them for a caller (or a test) to invoke. focused_block_id is threaded to Keymap.resolve/2's context from focused_index (see "Fold/jump" below).

Precondition #4 -- context_pct producer semantics

None of the shipped golden fixtures (test/fixtures/harness/sessions/) carry a context-window-size field alongside turn_completed's usage/cost payload -- there is no honest way to derive a percentage from token counts alone without a denominator this producer does not have. So context_pct is never populated by this assembler; the status strip's own — convention (gated on turn_completed) renders exactly that every frame. This is a producer decision (the status strip's moduledoc explicitly reserves it: "the producer decides, not this module"), not a bug -- fabricating a percentage from unrelated data would be the dishonest choice this design deliberately rules out. turn_stage and turn_completed ARE derived (from the last revealed loop event's type and whether a turn_completed event is the most recent one), matching the turn-boundary-snapshot semantics the status strip assumes by default.

Precondition #5 -- the footer contract

Every frame's footer is built as a plain list of lines (status ++ optional live/pending preview ++ Composer's own rendered lines ++ optional one-shot stub notice), run through ViewText.lines/3 for Composer's tree (status/notice lines are already plain strings), then handed to InlineAuthority.repaint/2 -- which pads/truncates the LIST to the current footer row count itself (see that function's doc). This module truncates every individual LINE to width via ViewText.lines/3 (which uses TextMeasure, never String.length) before that call -- the caller contract InlineAuthority.repaint/2's moduledoc documents as NOT enforced by that function itself.

The honest-notice law (priority fit before repaint's truncation)

repaint/2's own pad/truncate is POSITION-BLIND (a tail-drop) -- and the one-shot stub notice is the LAST footer group, so a composed footer that overflows the row budget would silently eat exactly the honest refusal/degradation report the notice channel exists to carry (an integration finding: the overflow only manifests once sibling footer content stacks up). footer_lines/1 therefore fits the list itself BEFORE the handoff (fit_footer_lines/3): display order preserved, discretionary groups yield first (preview, then divider, then the composer's tail, then an overlay's tail, then status -- each trimmed from its tail so a group's leading row survives a partial trim), and a notice is NEVER the row that silently drops -- at a 1-row budget the notice is the row that wins. Pinned by the "honest-notice law under footer overflow" describe in diff_expand_surface_test.exs. On resize, resize/2 composes InlineAuthority.resize/3 |> InlineAuthority.keyframe/2 explicitly (the documented composition -- resize/3 alone never repaints the footer). degenerate?/1 is checked before assuming a pin: a degenerate geometry still calls repaint/2/keyframe/2 (they never crash), just over whatever footer capacity footer_range/1 reports for that geometry.

While an overlay picker is open (see "The overlay picker" section below), the layout is instead status ++ overlay lines (ViewText.lines(OverlayPicker.render(picker), width, :styled)) ++ Composer's lines ++ notice -- the pending/live-tail preview lines are SUPPRESSED for exactly as long as the overlay is open (the space they'd occupy is now claimed by the overlay), and return the moment it closes.

The unread divider (live-region honesty)

Raxol.Harness.UnreadDivider decides, purely from caller-injected block-commit offsets (see that module's own moduledoc), whether a "N new since you looked" rule should render. This module owns two things that policy doesn't: WHEN to feed it an offset (blur/1 and focus/1, the explicit mode-1004 seam; handle_input/2 also feeds UnreadDivider.input_activity/2 on every keystroke as the fallback return signal, and move_focus/2 feeds UnreadDivider.viewed/2 on every jump) and WHERE to render its output: footer_lines/1 inserts unread_divider_lines/1's single dim line between the status strip and the pending/live preview, styled through the same ViewText seam every other footer line uses. The divider is decided at return-time and rendered ONLY in the repaintable footer -- sealed history is never touched (enforced byte-for-byte by the integration suite's sealed-bytes-identical test, not merely asserted in prose), it is suppressed under an open overlay exactly like the pending preview, and it is absent in :flat mode (no footer, no live region, so blur/1/ focus/1 are safe no-ops there). It clears the instant move_focus/2 reaches or passes the boundary block -- jumps skip the divider itself by construction, since focused_index ranges only over projection.blocks. advance/2 reconciles the policy state against every projection rebuild, and the render read is itself reconciled (UnreadDivider.divider/2), so a shrunken rebuild can neither stick the span nor paint it past the live block count.

DORMANT TODAY: nothing in the production input path calls blur/1 -- the terminal side can parse focus bytes but no driver enables mode 1004 or routes them here (see UnreadDivider's "mode-1004 seam" section for the full evidence trail). Until that unit lands, the divider never renders outside the test suites; the keystroke fallback only ever CLOSES an away state, never opens one.

The overlay picker (footer-region overlay)

open_overlay/3 hosts a Raxol.UI.Harness.OverlayPicker by GROWING the DECSTBM footer viewport (InlineAuthority.set_footer_rows/2) -- never a centered modal painted over history, never the alternate screen. The overlay's rows live entirely inside the (now larger) pinned footer, the same substrate the composer/status/preview lines already share.

ESC closes the overlay, not the running turn: Keymap's :overlay guard (see that module's moduledoc) captures ESC as :overlay_dismiss BEFORE the global :always ESC-interrupt bind ever sees it, as long as handle_input/2's context carries overlay_open?: true -- which it does whenever model.overlay is non-nil. Enter, printable characters, and the arrow keys are deliberately NOT added to Keymap.binds/0 for the overlay; they stay :passthrough, and THIS module is what routes a :passthrough event to OverlayPicker.handle_key/2 instead of the Composer while an overlay is open (see handle_input/2's routing, below) -- Enter commits the overlay's current selection instead of submitting the composer's buffer.

open_overlay/3 refuses rather than degrading silently whenever the current geometry cannot safely host even a minimal overlay: history must keep at least 2 rows, and the overlay itself needs at least 2 rows (a query row plus one item row) -- {:error, :insufficient_footer_capacity}, zero bytes, model untouched. A taller item list than the available capacity is CLAMPED to fit (via OverlayPicker's own :max_visible option), not refused -- only a geometry too small for even the 2-row minimum is a hard refusal. model.footer_rows always stays the BASE value the caller originally configured; the grown row count lives only in model.authority for as long as the overlay is open, and close_overlay/1 restores the authority back to exactly that base value on dismiss or commit.

Full-screen diff expansion (footer maximization)

expand_focused_diff/1 hosts a Raxol.Harness.DiffExpansion scrollable window over the focused block's diff, by the same GROW-the-footer mechanism as the overlay picker above (InlineAuthority.set_footer_rows/2) -- never a centered modal over history, never the alternate screen. The difference from the overlay is the CLAIM shape: an overlay claims a small, fixed height (OverlayPicker.height/1); an expansion claims the LARGEST non-degenerate footer the current geometry can host (max_overlay_rows/2, the exact same helper, one source of truth -- history still keeps its 2-row minimum). See DiffExpansion's own moduledoc for the full mechanism ruling -- why this grows the footer instead of visiting the alternate screen (LC-P-NOALT, the seal oracle's unverifiable-vocabulary concern, the missing alt-screen compensation machinery) -- this section only covers the assembly-layer half of that decision.

The e key (Raxol.UI.Harness.Keymap's :expand_diff, a :not_composing bind, same guard class as fold/jump) expands the currently focused block when it is a :diff block. It rides the exact guard fold/jump already use -- suppressed while composing (plain typed text) and while an overlay OR expansion is already open (context's overlay_open? flag is model.overlay != nil or model.expansion != nil -- see handle_input/2's moduledoc) -- so e can never fire a second, nested expansion or steal a keystroke from an open overlay's filter query.

ESC closes the expansion, not the running turn, for the identical reason ESC closes an open overlay: Keymap's :overlay guard captures it as :overlay_dismiss whenever context.overlay_open? is true, which it is for an open expansion too. dispatch_command/2's expansion clause for :overlay_dismiss precedes the overlay clause (load-bearing order, same class of ordering the overlay's own ESC-priority note documents), so an open expansion's ESC always closes the EXPANSION -- the two can never both be open at once (each refuses while the other is), so this is not actually an ambiguous case, just an explicit one. q is a second dismiss key, routed the same way through route_passthrough/3's expansion clause (alongside j/k/arrow-key scrolling) -- Enter, other printable characters, and any other special key are inert while expanded, matching the overlay's own "only the keys the picker actually understands are wired" discipline. Dismissing restores the footer to model.footer_rows via set_footer_rows/2, which latches needs_keyframe -- the trailing paint_footer/1 self-promotes to a full keyframe, the same byte-identical restore discipline close_overlay/1 already relies on.

Honest refusals (see expand_focused_diff/1's doc for the full, ordered list): no footer to grow (:flat mode), no block focused, the focused block is not a :diff block, the geometry cannot host even the 2-row minimum, or the focused block's content fails BodyProvider's :diff schema. Every refusal is zero bytes and an unchanged model; the e keybind path (apply_expand/1) additionally surfaces each one as an honest, visibly-labeled one-frame footer notice through the existing stub_notice channel (precondition #6's stub mechanism), never a silent no-op.

resize/2 mirrors the overlay's force-close discipline for a geometry that can no longer host the expansion at all, but because the expansion's claim is "the maximum available," not a fixed height, a resize that STILL fits does not merely survive unchanged the way an open overlay does -- the claim is RE-DERIVED at the new geometry every time, the footer re-grown or re-shrunk to match, and DiffExpansion.resize_view/3 re-renders the same diff content at the new width/window, clamping the scroll offset. See resize/2's own doc for the exact sequencing.

Precondition #6 -- command bifurcation (fixture mode = honest UI stubs)

:interrupt/:steer are the two commands that cross to the agent lane in the future agent-lane surface (%Command{}, raxol_agent's channel). This module has no agent lane by design, so both are rendered as honest, visibly-labeled stubs instead of silently doing nothing OR pretending to act:

• :interrupt -- sets a one-frame footer notice ("interrupt requested (stub -- no agent lane in fixture mode)"), consumed (cleared) after the next paint so it never lingers as a stale claim.
• :steer -- reuses Composer's OWN already-built queued-steer banner (Composer.update({:set_queued_steer, ...}, composer)) with the composer's current buffer text, mirroring exactly what a real steer would queue (per Keymap's own moduledoc: "the assembly layer that already has the composer's buffer fills payload.text in before dispatch") -- without an agent lane to actually deliver it to. This is the more honest stub of the two: it is real, shipped UI, not an invented notice line.

:fold_toggle/:jump_next/:jump_prev never leave this module -- they are pure UI-local state per Keymap's own documented bifurcation.

While an overlay picker is open (model.overlay != nil), :steer is a documented no-op instead of queuing the composer's buffer: the composer is frozen mid-pick (its buffer is not what the operator is currently interacting with), so queuing a steer built from THAT hidden state would be dishonest UI -- it would claim to queue "what you were about to send" when what's actually on screen is a filter query, not a prompt. :interrupt is unaffected (an overlay is transient UI-local state, not a reason to block the honest interrupt stub).

Fold/jump and the seal-time-only gate -- a translation, not a reuse

The "which blocks may seal" decision itself now lives in Raxol.Harness.SealFrontier (a shared classifier, not restated per consumer). frontier_entries/1 expresses the foldable window described below as the frontier's pending_input? hold on the newest block; the seal pass (paint_pending_blocks/1) walks it via commit_walk/5, and the footer's pending preview (pending_block/1) shows the first block past the walk's own committed cursor (painted_count) -- the post-commit truth, which equals the pre-commit scan's tail_start on every successful frame and stays honest (block still visible) when a seal write is refused. One classifier decides where the frontier stops; the cursor records where it actually got to.

The preview shows ONE block (two lines of it). Today the two never differ: the only frontier hold a shipped producer can create is the foldable window on the NEWEST block, so the unsealed suffix past the cursor is at most one block long. Two tests in test/harness/surface_frontier_feed_test.exs guard this together, and the split matters: the fixture-REPLAY pin only proves the bound holds over today's shipped corpus (it replays .jsonl, so it structurally cannot observe a runtime producer -- on its own it would pass vacuously). Its teeth come from the paired SYNTHETIC test, which builds the exact runtime hold the corpus lacks -- a mid-list awaiting-input :approval holding finalized blocks behind it -- and asserts the frontier genuinely stops there, so more than one block sits past the cursor. That is the multi-block hold the one-block preview cannot honor: the moment a producer wires such a hold into a real advance, the bound breaks and the preview under-reports, forcing the multi-block tail rendering decision (the live-lane / T13b unit's), never silently absorbed here.

Raxol.UI.Components.Harness.Block.seal is an item-LIFECYCLE field: BlockBuilder only ever constructs a block once its source item(s) complete, always with seal: :sealed (see BlockBuilder.build_block/2). That means every block the block builder hands this assembler already reads :sealed by the time it exists at all -- Block.fold_allowed?/2's own post-seal gate would therefore deny EVERY fold toggle, unconditionally, which is not what "fold state flips pre-seal" (this unit's own acceptance criterion) asks for.

The seal-time-only gate this unit actually needs is a DIFFERENT axis: has this block been PHYSICALLY PAINTED to the terminal's history region yet (via InlineAuthority.seal/2/FlatAuthority.seal/2)? That is this module's own painted_count high-water mark, not Block.seal. So every fold toggle here calls Block.toggle_fold(block, fold_after_seal: :allow) -- deliberately overriding Block's own (inapplicable) default -- and this module enforces "no fold after physical paint" itself, by construction: advance/2 always leaves the newest completed block un-painted for exactly one more advance/2 call (see paint_pending_blocks/1), so there is a real, multi-step window in which the trailing block is visible (via the footer's pending-preview line), foldable, and NOT yet irreversibly on-screen. Once painted, its fold state is frozen (assigning further overrides for an already-painted block index is a no-op here, independent of whatever Block.fold_allowed?/2 would say) -- exactly because the substrate cannot repaint sealed history (seal-time-only).

The foldable-before-seal window is honest only for one-block-per-advance

The guarantee above -- "the trailing block is visible, foldable, and NOT yet irreversibly on-screen for at least one advance/2 call" -- holds precisely because paint_pending_blocks/1 always holds back exactly the single NEWEST completed block. If one advance/2 call ever materializes two or more newly-completed blocks in the same step (the block builder's projection batching more than one durable item into a single re-project), every block except the last of that batch seals IMMEDIATELY, in the same step it first appears -- there is no foldable window for those, because paint_pending_blocks/1 has no notion of "the newest N blocks," only "all but the newest one." This is not a defect in this module's own bookkeeping; it is a real limit of the design, worth naming honestly rather than leaving implied by the single-block phrasing above. The actual fix belongs one layer down, in the block builder: a :completed_but_unsealed phase distinguishing "this block is done" from "this block has been offered a foldable window," which the block builder does not currently model (tracked as a follow-up, not part of this unit's scope).

The live tail (delta streaming) has no history-region home

Per the substrate's actual shipped contract, InlineAuthority supports exactly two things: seal-once history (seal/2, never repainted) and a repaintable FOOTER viewport (repaint/2/keyframe/2). There is no third "live, still-mutating history row" primitive in any merged unit -- inventing one is out of this unit's scope (a new substrate primitive, not an assembly). So both projection.tail (in-progress items, still accumulating item_delta chunks) and the one pending-not-yet-painted completed block are rendered as a single preview line INSIDE the footer, which IS a legitimately repaintable surface every frame -- never in history. This keeps every live/mutable thing inside the one viewport built for repainting, and everything sealed forever immutable, which is the seal-time-only contract honestly extended one layer up rather than worked around.

The sub-binary pinning footgun -- :binary.copy/1 at seal

Research feedback on comparable TUI harnesses (Ink's erase-redraw pathology, external audit 2026-07) flagged a BEAM-specific memory footgun this module's own painted_count design is exposed to: a binary produced by pattern-matching, binary_part/3, or a JSON decoder's own unescaped-string fast path (Jason does this) is a SUB-BINARY -- a small header referencing the WHOLE original buffer, not a copy of just its own bytes (:binary.referenced_byte_size/1 reveals the difference; byte_size/1 does not). A Block.content string that is secretly one of these (a stream delta arriving as a slice of one large network-chunk binary is the shape a live, agent-streamed session would hit; a multi-KB .jsonl line decoded by a substring-slicing parser is today's fixture-mode shape) pins the ENTIRE originating buffer in memory for as long as anything holds the slice -- and this module's own blocks, once sealed, are retained in projection.blocks for the life of the session (see "memory residency" in this module's test suite, the companion regression guard this fix exists for).

paint_pending_blocks/1 is where a block permanently transitions from "still mutable, still small in count" to "sealed, retained forever, never touched again" (seal-time-only) -- the boundary this fix cares about. detach_content/1 walks a block's content map (recursing into nested maps/lists -- :args, :options, :blast_radius can all nest) and replaces every binary with :binary.copy/1's independent copy.

One subtlety this module's own full-rebuild-every-advance/2-call architecture forces: Projection.project/2 rebuilds blocks from source_events FROM SCRATCH on every single call (there is no per-block memoization anywhere in the block builder's pipeline), so a detached copy stored into projection.blocks on one call is GONE -- silently replaced by a fresh, un-detached rebuild -- the moment the NEXT advance/2 runs, unless something re-applies the detach every time. detach_up_to/2 is that something: it re-detaches every already-sealed index (not just the ones newly crossing into "about to seal" this step) on EVERY paint_pending_blocks/1 call. This is real, repeated work -- same order as Projection.project/2's own already-O(n) per-call rebuild, so it changes the constant factor, not the complexity class -- but it is what makes the fix actually STICK: a one-shot copy that only touches the newly-sealing block would be silently undone by the very next advance/2's fresh projection for every block sealed in an EARLIER call, which defeats the whole point.

The more foundational fix belongs one layer down, in Raxol.Harness.Projection.BlockBuilder -- copying at first extraction, before a sub-binary content string is ever assigned to a Block struct at all, rather than after the fact here. That module is already merged on master; this Surface-side copy is the surgical stopgap until a block-builder follow-up lands the earlier, more foundational fix. Tracked, not forgotten.

A related, NOT-implemented-here option for a future agent-lane surface (long-running, intermittently-idle sessions): :erlang.hibernate/Process.hibernate between turns compacts the process heap and frees any transient fragmentation the streaming path accumulated while a turn was running -- independent of this fix (hibernation compacts what's ALREADY garbage; it cannot un-pin a buffer still referenced by a live sub-binary), and out of scope for a fixture-replay module that has no live idle period to hibernate during. Noted here as the next thing to reach for, not implemented.

External editor handoff (the :edit_draft command, Ctrl+E)

Long prompts don't belong in a 6-row footer composer. The Ctrl+E chord (Raxol.UI.Harness.Keymap's :edit_draft, an :always bind) hands the composer draft to $VISUAL/$EDITOR via the injected :editor_session (see new/2's options): the session suspends the terminal claim (the canonical suspend bytes release the DECSTBM region, cooked modes come back, the BEAM stdin reader is gated off), runs the editor synchronously attached to the tty, and resumes (raw mode, reader, init bytes). What the session deliberately does NOT do is re-pin the region -- region bytes are owned by THIS model's authority, so every return branch here composes InlineAuthority.resize/3 |> InlineAuthority.reassert/1 (resize/3 alone is geometry-gated: a terminal NOT resized while suspended would get zero region bytes and stay silently un-pinned), and reassert/1's needs_keyframe latch turns the next paint_footer/1 into a full keyframe. On editor exit 0 the edited draft replaces the composer's value (Composer.set_value/2); any other outcome keeps the original draft and surfaces a one-frame footer notice through the existing stub_notice channel.

Sealed history above the footer survives the whole bracket untouched by construction -- no code path here or in the session addresses a history row, and the suspend bytes contain no \e[2J/\e[3J. The one documented residual: an editor that does NOT use the alternate screen may scribble over the not-yet-scrolled on-screen portion of history (cosmetic; content already in native scrollback is unreachable to us and to it). :flat mode has no footer composer to hand a draft back to, so :edit_draft there seals one honest history line saying so instead of pretending.

The pickers (command palette, jump, session, search)

Four more OverlayPicker consumers ride the same footer-overlay substrate as the picker described above. Ctrl+P (Keymap's :open_palette, an :always chord) opens the command palette from anywhere, including mid-compose -- a chord is never typed text, the same reasoning as Ctrl+E. g (:open_jump_picker), s (:open_session_picker), and / (:open_search_picker) are plain printable letters gated :not_composing, the same class as z/j/k: they only resolve in transcript-browse mode, never stealing a letter out of the composer's typed text. open_search_picker/1's entries are labeled from Block.search_text/1 -- a content-derived search corpus (kind, summary, AND body text), not just the summary header open_jump_picker/1's labels use -- clamped per block (see that function's own doc) before Raxol.Harness.Surface.ViewText.lines/3 ever truncates a rendered row to its display-width budget.

The palette's entries are Keymap.palette_binds/0 (the labeled subset of the bind table) plus two commands that exist only at THIS assembly layer, not in Keymap.binds/0 -- "focus transcript" and "focus composer" (the very transition focus_transcript/1/focus_composer/1 already exposes as direct API). Picking any palette entry dispatches through the exact same dispatch_command/2 path a keypress takes -- there is no second, parallel execution mechanism for a palette-picked command. All four pickers (palette, jump, session, search) opt into Raxol.UI.Harness.OverlayPicker.fuzzy_filter/3 as their filter_fn (the Raxol.UI.ListScorer adapter), not the default substring filter -- a fuzzy-ranked query is what a "type a few letters, find the entry" picker needs.

Session-switch semantics (s, switch_session/2) are stated plainly: the abandoned session's sealed history stays byte-identical above -- print-once, the substrate cannot rewrite it -- while its not-yet-painted PENDING blocks (the one-block foldable window) are DROPPED, never sealed late. Replay state (events/revealed/projection/ painted_count/fold_overrides/focused_index/status) resets, the new session's events append below whatever is already sealed, and the composer draft plus authority/geometry survive the switch untouched.

Projection panels (read-only footer overlays)

Three more overlays ride the same hosted-overlay footer slot, but are Raxol.UI.Harness.OverlayPanel instances (never OverlayPicker) -- summonable via the labeled w/m/n panel binds (worktracks/memory/ plan; Keymap's :open_panel command, discriminated by payload.panel), and therefore via the command palette too, same invocation-parity guarantee as every other labeled bind. Content is a read-model folded by Raxol.Harness.PanelProjection from the projection's retained durable extract meta events, recomputed both at summon (open_panel/3) and on every footer repaint while open (refresh_panel_overlay/1, called from paint_footer/1) -- a live projection, not a one-shot snapshot. Same refusal ladder as open_overlay/3 (:overlay_already_open/:no_footer/ :insufficient_footer_capacity), surfaced through the same picker_refusal/2 notice path. Dismissal releases the claimed footer rows and discards only UI-local panel state (scroll offset); re-summoning folds the CURRENT retained events without ever touching the block projection itself.

Merge caveat (see PanelProjection's own moduledoc for the full statement): the panels build against the frozen meta-event contract shapes and a contract-shape fixture (test/fixtures/harness/sessions/projection-panels.jsonl); the per-class item shapes are ASSUMPTIONS pending verification against real agent-emitted extract events before this unit's PR merges.

Precondition #7 -- teardown ownership (this module owns NONE)

new/2 sets the DECSTBM history/footer split via InlineAuthority.new/5 (a CSI 1;(H-N) r write), but this module never releases it -- there is no Surface.stop/1/terminate/2 here, and none of the functions above ever emit CSI r (the full-screen scroll- region release). In the demo (examples/harness_fixture_demo.exs), that release happens for free because the driver embedding this module is Raxol.Terminal.InlineDriver, whose own terminate/2 calls emit_teardown/2 -> Raxol.Terminal.InlineDriver.Sequences.teardown_bytes/1, which writes release_region/0 ("\e[r") -- among the other canonical teardown steps -- before the process exits.

A caller that embeds THIS module directly, without InlineDriver (or any equivalent that already owns scroll-region teardown), inherits no such cleanup: the terminal is left with a permanent DECSTBM split after the process exits, which strands the shell prompt inside the old history/footer region. Such a caller MUST emit the release itself -- at minimum IO.write(device, "\e[r") (CSI r, reset the scroll region to the full screen), or, for the full canonical teardown order (modes off, then region release, then autowrap+cursor restore, then move-to- bottom), call Raxol.Terminal.InlineDriver.Sequences.teardown_bytes/1 directly. This module deliberately exposes no teardown_bytes/1 of its own: it would either duplicate that module's pinned byte order or drift from it, and there is exactly one canonical teardown sequence already shipped for callers to reuse.