nexrall-code 0.5.116 → 0.5.117

package/dist/ui/inkTerminal.js

@@ -1,1097 +0,0 @@
-import React, { useState, useCallback, useRef } from 'react';
-import { render, Box, Text, Static, useInput, useApp, useCursor, useBoxMetrics, } from 'ink';
-import { colors, visibleLen } from './theme';
-import { createResizeDebouncer } from './resizeRepaint';
-import { fillerRowCount, rowsOccupied } from './screen';
-// Exported so padToBottom (ui/screen.ts) can measure how many rows the footer
-// really occupies at the current terminal width instead of assuming one — it
-// wraps below ~56 columns, and a wrong count scrolls the banner off-screen.
-export function footerText(info) {
-    const modeLabel = info.autoApprove
-        ? 'yolo mode on'
-        : info.mode === 'plan' ? 'plan mode on'
-            : info.mode === 'edit' ? 'edit mode on'
-                : info.mode === 'ask' ? 'ask mode on'
-                    : 'auto mode on';
-    // `Ctrl+J for newline` is spelled out here, not left to /help, because it is
-    // the ONLY newline key that works with no terminal configuration at all —
-    // and on some terminals it is the only one available, period. Apple Terminal
-    // below macOS 27 is the case that forced this: its keymap
-    // (Terminal.app/Contents/Resources/keyMappings.plist) can only rebind
-    // codepoints in the U+F700–F8FF function-key range, and Return is U+000D, so
-    // Shift+Return is not bindable there by any means — `claude` reaches the same
-    // conclusion and falls back to Option+Enter on those versions. A user on such
-    // a terminal who never opens /help would otherwise have no way to discover
-    // that a multi-line prompt is possible at all.
-    //
-    // `/agents for agents` was dropped to make room. It is still listed in
-    // /help, so nothing became undiscoverable — whereas Ctrl+J was documented
-    // nowhere the user would look, which is the asymmetry that decided it.
-    //
-    // Length matters: this string feeds bottomChromeRows(), which padToBottom()
-    // uses to decide how many filler rows to print. Swapping one hint for the
-    // other leaves it at exactly 55 cells — the same width as before — so the
-    // measured wrap behaviour is unchanged (one row down to 55 columns, two at
-    // 40). See bottomChrome.test.ts, which pins both ends of that boundary.
-    return `${modeLabel} · /help for shortcuts · Ctrl+J for newline`;
-}
-/**
- * Content string that renders as exactly `rows` blank Static rows.
- *
- * Not simply `'\n'.repeat(rows - 1)` for every case — verified against a
- * standalone Ink probe (Static items bracketed by marker rows, counting
- * exact printed lines) that a Static item's content string does NOT follow
- * the same "N newlines = N+1 rows" rule `console.log` uses. Specifically:
- *
- *   • `''` (empty string) contributes ZERO rows — <Static> renders nothing
- *     for it at all, unlike `console.log('')` which always prints a blank
- *     line. So `rows <= 0` must special-case to `''`, and there is no
- *     N-newlines formula that also covers `rows === 1` correctly (0
- *     newlines there would be `''`, which is 0 rows, not 1).
- *   • A single space (`' '`) reliably contributes exactly ONE row.
- *   • From 2 rows up, `'\n'.repeat(rows - 1)` behaves exactly like the
- *     console.log case and contributes exactly `rows` rows — confirmed for
- *     2, 3, 5, and 8.
- */
-export function fillerContent(rows) {
-    if (rows <= 0)
-        return '';
-    if (rows === 1)
-        return ' ';
-    return '\n'.repeat(rows - 1);
-}
-const IntlWithSegmenter = Intl;
-const graphemeSegmenter = typeof IntlWithSegmenter.Segmenter === 'function'
-    ? new IntlWithSegmenter.Segmenter(undefined, { granularity: 'grapheme' })
-    : null;
-// ─── Cursor-aware grapheme navigation ──────────────────────────────────────
-//
-// The input box used to have no concept of a cursor position at all — every
-// keystroke appended to the end of the line and Backspace only ever removed
-// the LAST character, with left/right arrow explicitly no-ops ("not wired
-// yet"). That is fine for pure ASCII typed in order, but it is exactly the
-// editing pattern Vietnamese/CJK IME users need most: type a word, notice the
-// wrong tone/diacritic partway through, arrow back to it, fix it in place.
-// Without cursor movement that correction is impossible without deleting and
-// retyping everything after the mistake — which reads identically to "the
-// input box doesn't work" even though every individual keystroke is captured
-// correctly.
-//
-// All positions here are grapheme-cluster boundaries (via Intl.Segmenter,
-// same primitive as dropLastGrapheme above), not UTF-16 code-unit offsets —
-// so arrowing over an accented Vietnamese character or an emoji moves the
-// cursor exactly one visual character, never landing mid-cluster.
-function graphemeBoundaries(text) {
-    if (graphemeSegmenter) {
-        const bounds = [0];
-        for (const { index } of graphemeSegmenter.segment(text)) {
-            if (index > 0)
-                bounds.push(index);
-        }
-        bounds.push(text.length);
-        return bounds;
-    }
-    // Fallback mirroring dropLastGrapheme's manual surrogate/combining-mark
-    // handling: walk forward collecting boundaries the same way it walks back.
-    const bounds = [0];
-    let i = 0;
-    while (i < text.length) {
-        let next = i + 1;
-        const code = text.charCodeAt(i);
-        if (code >= 0xd800 && code <= 0xdbff && next < text.length) {
-            const low = text.charCodeAt(next);
-            if (low >= 0xdc00 && low <= 0xdfff)
-                next++;
-        }
-        while (next < text.length && /[\u0300-\u036F\u1AB0-\u1AFF\u20D0-\u20F0]/.test(text[next]))
-            next++;
-        bounds.push(next);
-        i = next;
-    }
-    return bounds;
-}
-/** The grapheme boundary immediately before `pos` (for leftArrow/backspace-at-cursor). */
-export function prevGraphemeBoundary(text, pos) {
-    const bounds = graphemeBoundaries(text);
-    let prev = 0;
-    for (const b of bounds) {
-        if (b >= pos)
-            break;
-        prev = b;
-    }
-    return prev;
-}
-/** The grapheme boundary immediately after `pos` (for rightArrow/delete-at-cursor). */
-export function nextGraphemeBoundary(text, pos) {
-    const bounds = graphemeBoundaries(text);
-    for (const b of bounds) {
-        if (b > pos)
-            return b;
-    }
-    return text.length;
-}
-/**
- * Splits the input line into the three pieces the input box draws: the text
- * before the caret, the ONE character the caret sits on (rendered inverted),
- * and the text after it.
- *
- * This exists as a named, exported function purely so it can be tested. It
- * used to be three inline `line.slice(...)` expressions in the JSX below, and
- * the middle one was `line.slice(cursorPos, cursorPos + 1)` — a UTF-16
- * CODE-UNIT offset, which is exactly the mistake every helper above this
- * point goes to some length to avoid. All the grapheme-aware cursor
- * navigation was therefore thrown away at the last step, in the render:
- *
- *   • "chào" typed via Telex arrives DECOMPOSED ("a" + U+0300). With the
- *     caret on it, `+ 1` highlighted the bare "a" and left the combining
- *     accent at the head of the trailing slice, where it reattached to
- *     nothing — the character visibly came apart under the cursor.
- *   • For any non-BMP character (emoji, and every ZWJ sequence or flag)
- *     `+ 1` cut a SURROGATE PAIR in half, so the inverted cell held a lone
- *     unpaired surrogate — the classic � — and the tail began with the other
- *     half. Measured before this fix: 1 of 4 caret positions in decomposed
- *     "chào" rendered a broken glyph, and 1 of 1 in "👨‍👩‍👧" / "🇻🇳".
- *
- * Advancing to the next grapheme BOUNDARY instead keeps the highlighted cell
- * one whole user-perceived character, which is also the unit the caret
- * already moves by, so the two can no longer disagree.
- *
- * `atCursor` is a single space when the caret sits at end-of-line, matching
- * the block-caret look the input box has always had there.
- */
-export function renderInputSlices(line, cursorPos) {
-    const end = nextGraphemeBoundary(line, cursorPos);
-    return {
-        before: line.slice(0, cursorPos),
-        atCursor: line.slice(cursorPos, end) || ' ',
-        after: line.slice(end),
-    };
-}
-export function caretPosition(opts) {
-    // A zero/negative width would make the wrap arithmetic divide by zero. Ink
-    // itself falls back to 80 when the terminal reports nothing usable; clamping
-    // to at least 1 here keeps this pure function total for any input.
-    const columns = Math.max(1, opts.columns);
-    const logicalLines = opts.line.split('\n');
-    // Which logical line the caret sits on, and how far into it — derived from
-    // the text BEFORE the caret so it cannot disagree with renderInputSlices,
-    // which slices the drawn text at the very same offset.
-    const beforeLines = opts.line.slice(0, opts.cursorPos).split('\n');
-    const caretLineIndex = beforeLines.length - 1;
-    const widthBeforeCaret = (caretLineIndex === 0 ? opts.promptWidth : 0) +
-        visibleLen(beforeLines[caretLineIndex] ?? '');
-    // Rows consumed by the logical lines ABOVE the caret's own, each wrapped at
-    // the full terminal width (and each occupying at least one row, since an
-    // empty line still takes a row).
-    let rowsAboveCaretLine = 0;
-    for (let i = 0; i < caretLineIndex; i++) {
-        const width = (i === 0 ? opts.promptWidth : 0) + visibleLen(logicalLines[i] ?? '');
-        rowsAboveCaretLine += Math.max(1, Math.ceil(width / columns));
-    }
-    return {
-        x: widthBeforeCaret % columns,
-        // Where the input box begins (measured), plus however far down its own
-        // wrapped/multi-line content the caret has reached.
-        y: opts.inputRowTop + rowsAboveCaretLine + Math.floor(widthBeforeCaret / columns),
-    };
-}
-/**
- * Decides whether a keypress means "submit the line", "insert a newline", or
- * "this is just text". Pure and exported so the table above is testable — the
- * terminal-dependent half of this is impossible to cover otherwise.
- *
- * `char`/`key` are exactly what Ink's `useInput` passes through.
- */
-export function decideEnterKey(char, key) {
-    // A chunk that is EXACTLY one linefeed, with no modifier, is Ctrl+J: the
-    // universal, zero-config "insert a newline" key. Requiring the whole chunk
-    // to equal '\n' (rather than merely to contain one) is what keeps this from
-    // swallowing a multi-line paste — a paste arrives as one chunk with text
-    // around its newlines, and must still submit its first line.
-    if (char === '\n' && !key.meta && !key.return)
-        return { kind: 'newline' };
-    // Option+Enter, and the sequence /terminal-setup binds to Shift+Enter in
-    // VS Code. Both arrive as ESC-prefixed CR, which Ink reports as
-    // return+meta. `key.shift` is accepted too so that a terminal which DOES
-    // negotiate the Kitty protocol (or a future one sending CSI-u natively)
-    // keeps working — it costs nothing and is the semantically intended key.
-    if ((key.return || char === '\r' || char === '\n') && (key.meta || key.shift)) {
-        return { kind: 'newline' };
-    }
-    // Scan for an embedded newline ANYWHERE in the chunk, not just at its
-    // start. Ink's docs: "if the user pastes text and it's more than one
-    // character, the callback will be called only once, and the whole string
-    // will be passed as input" — which applies to any multi-byte read, not only
-    // bracketed pastes. Typing fast enough (or a harness writing "h\r" in one
-    // syscall) delivers char as e.g. "h\r" in a SINGLE callback with every
-    // key.* flag false, so matching only `key.return`/`char === '\r'` would
-    // miss the most common fast-typing submit.
-    const newlineIdx = char.search(/[\r\n]/);
-    if (key.return || newlineIdx !== -1)
-        return { kind: 'submit', splitAt: newlineIdx };
-    return { kind: 'text' };
-}
-// ─── Ctrl+C: confirm before quitting ───────────────────────────────────────
-//
-// Pressing Ctrl+C once while idle used to exit the session instantly — no
-// confirmation, no message. Verified in a pty before this change: a single
-// \x03 at the `> ` prompt ended the process immediately
-// (@@@PROCESS_EXITED_ON_FIRST_CTRL_C). That is a bad default for a REPL that
-// holds conversation state, and it is a very easy key to hit by reflex when
-// the intent was "stop what you're doing" or "clear this line" — the
-// muscle-memory meaning of Ctrl+C in most shells.
-//
-// Now a first press ARMS a quit and shows a hint; a second press within the
-// window actually exits. Anything else the user does (typing, Enter,
-// Backspace, arrows) disarms it, so a stray Ctrl+C followed by real work can
-// never quit the session later.
-//
-// The window matters: without a timeout, a Ctrl+C pressed now and another
-// pressed ten minutes later would still quit, which is the same surprise in
-// slow motion. 3s is long enough for a deliberate double-tap and short enough
-// that the armed state never outlives the user's awareness of it.
-export const CTRL_C_QUIT_WINDOW_MS = 3_000;
-export const CTRL_C_HINT = 'Press Ctrl+C again to exit';
-/**
- * Decides what a Ctrl+C press means, given what else is going on. Pure and
- * exported so the precedence rules are testable — this used to be an
- * if/else chain inline in `useInput` with no coverage at all.
- *
- * Precedence is deliberate and matches the Enter handler's own ordering:
- *
- *  1. An outstanding askLine() question (a permission y/n, /init overwrite…)
- *     wins even while busy — Ctrl+C there means "no", which is the safe
- *     answer, and must not be reinterpreted as a session quit.
- *  2. A running agent turn means "interrupt the turn", never "exit" — losing
- *     a long run to a misplaced keystroke is exactly what this ordering
- *     prevents. Note this needs NO confirmation: interrupting is cheap and
- *     recoverable, so requiring a double-tap there would just make stopping
- *     a runaway turn harder.
- *  3. Otherwise (idle at the prompt) the first press arms, the second quits.
- */
-export function decideCtrlC(state) {
-    if (state.hasPendingQuestion)
-        return 'answer-prompt';
-    if (state.busy)
-        return 'interrupt-turn';
-    if (state.quitArmedAt !== null && state.now - state.quitArmedAt <= CTRL_C_QUIT_WINDOW_MS) {
-        return 'quit';
-    }
-    return 'arm-quit';
-}
-let handle = null;
-let inkInstance = null;
-let idCounter = 0;
-let resizeDebouncer = null;
-let resizeListenerAttached = false;
-// How long to wait, after the LAST 'resize' event, before treating a drag as
-// finished. Long enough that a continuous drag (which fires events every few
-// milliseconds — verified: a 100→60 column drag fired multiple events well
-// under 50ms apart) never fires the repaint mid-drag; short enough that
-// letting go of the terminal edge feels instant, not delayed.
-const RESIZE_SETTLE_MS = 120;
-/**
- * Cleans up stray leftover rows below the bottom chrome once a resize burst
- * has settled — see resizeRepaint.ts for the full mechanism, summarized here:
- *
- * `log-update.js`'s repaint on every 'resize' event is
- * `eraseLines(previousLineCount) + newFrame`, where `previousLineCount`
- * comes from counting literal '\n's in the PREVIOUS frame it wrote — not
- * the terminal rows that frame actually occupied once wrapped at the width
- * the terminal was reporting at that instant. During a drag, each
- * intermediate event's frame is computed and erased against a width that
- * has already moved on by the next event, so `eraseLines` can clear FEWER
- * rows than the previous frame actually used. Those un-erased rows aren't
- * inside the region the next frame overwrites (that region starts at the
- * cursor position `eraseLines` leaves behind, which sits at the TOP of
- * what it erased) — they end up sitting just below the newly written
- * frame instead, which is exactly the reported symptom: blank/torn rows
- * appearing under the input box, accumulating with repeated drags.
- *
- * This used to erase from the cursor to the bottom of the screen
- * (`\x1b[0J`, "erase in display, cursor to end") right here, before the
- * full redraw below. That write is now GONE, for two independent reasons —
- * it became both unnecessary and actively destructive:
- *
- *  1. Unnecessary: when this function was first written (commit 5c83c19) the
- *     `\x1b[0J` was the ONLY cleanup it did. A later commit (190a5fe) added
- *     the forceFullRedraw() call below, which begins by writing
- *     `\x1b[2J\x1b[H` — a clear of the ENTIRE visible screen, which
- *     subsumes "from the cursor down" completely. Verified by replaying both
- *     byte streams through a real terminal emulator (pyte): a frame plus a
- *     stray leftover row, cleaned with `[2J` alone versus `[0J` then `[2J`,
- *     produce the identical final screen.
- *  2. Destructive: `\x1b[0J` erases from wherever the cursor IS, and the
- *     cursor is no longer parked after the frame's last row. It now sits ON
- *     the caret inside the input box (see caretPosition / useCursor above,
- *     which exists so IME composition renders in the right place), i.e. in
- *     the MIDDLE of the chrome. Replayed through pyte with the cursor parked
- *     at the caret, `[0J` wiped the rest of the input row, the rule below it
- *     and the footer — leaving a truncated UI after every single resize.
- *     The `[2J` full clear is immune to this because it does not depend on
- *     the cursor position at all.
- *
- * Note the surviving `\x1b[2J` deliberately still is NOT
- * `ansiEscapes.clearTerminal` (`\x1b[2J\x1b[3J`) — `\x1b[3J` wipes the
- * terminal's OWN scrollback (see vadimdemedes/ink#935, which documents
- * exactly this complaint against Claude Code and Codex CLI), destroying
- * every earlier turn's transcript. Clearing only the visible screen and
- * having `<Static>` reprint the transcript is what keeps scrollback intact.
- *
- * Waiting for `waitUntilRenderFlush()` first (same primitive `flushInkFrame`
- * below uses) still matters: Ink's own `resized()` handler (ink.js) queues a
- * render in response to the same burst of events, and clearing before that
- * pending render commits would race it — the clear could land while Ink is
- * mid-write and corrupt that frame. Flushing first guarantees this runs
- * strictly after Ink's own last resize-triggered render for the settle window.
- */
-function repaintAfterResizeSettle() {
-    const instance = inkInstance;
-    if (!instance || !process.stdout.isTTY)
-        return;
-    void instance.waitUntilRenderFlush().then(() => {
-        // The instance may have been unmounted while the flush was pending
-        // (session ending mid-resize) — re-check before writing to a stream
-        // whose renderer has already torn down.
-        if (inkInstance !== instance)
-            return;
-        // Full-transcript reflow (and, as of the doc above, the ONLY cleanup this
-        // path does): fixes the banner/transcript ABOVE the live chrome, which Ink
-        // never touches on resize at all (its resize handler only re-lays-out the
-        // currently-mounted component tree — the already-scrolled `<Static>`
-        // output is gone from that tree the instant it's written, by design), and
-        // its `\x1b[2J` also clears any stray rows Ink's own erase-math race left
-        // behind during the drag.
-        forceFullRedrawRef?.();
-    });
-}
-// Set by the App component once mounted (see its own effect below) — module
-// scope is required because `attachResizeCleanup`/`repaintAfterResizeSettle`
-// run OUTSIDE any component, same reason `inkInstance`/`handle` are already
-// module-level here.
-let forceFullRedrawRef = null;
-const DEFAULT_PROMPT = colors.primary.bold('> ');
-const App = ({ onReady }) => {
-    const [items, setItems] = useState([]);
-    // Bumped on every resize-settle to force React to treat <Static> as a BRAND
-    // NEW instance (see the `key` prop below) instead of the same one with an
-    // unchanged items array. <Static> only ever emits items it has not already
-    // committed — passing the identical array back a second time is a no-op as
-    // far as it's concerned, so there is no other way to make it re-print
-    // everything already on screen. See forceFullRedraw's own comment for why
-    // this whole mechanism exists at all.
-    const [staticKey, setStaticKey] = useState(0);
-    const [footer, setFooterState] = useState({ mode: 'auto', autoApprove: false });
-    // Whether an agent turn is currently running. This used to be called
-    // `inputEnabled` and, when false, made `useInput` bail out on EVERY key —
-    // typing, cursor movement, Ctrl+C, and even the permission y/n prompt asked
-    // mid-turn via askLine(). That combination meant a running turn could never
-    // be interrupted from the keyboard at all (raw mode disables the kernel's
-    // own Ctrl+C→SIGINT translation, so Ink's own handling was the only path
-    // left), and a permission question fired during that same turn hung
-    // forever waiting for a keypress the input box had stopped accepting.
-    // `busy` still exists to change ONE thing — what a submitted line without
-    // an outstanding askLine() question does (queue vs. dispatch immediately,
-    // see the Enter branch in useInput below) — but it never gates whether a
-    // key is processed at all.
-    const [busy, setBusyState] = useState(false);
-    const [line, setLineState] = useState('');
-    // 0-based grapheme-cluster index of the caret within `line`. Left/right
-    // arrow move this without touching the text; typing/backspace/delete act
-    // AT this position instead of always at the end.
-    const [cursorPos, setCursorPosState] = useState(0);
-    const [prompt, setPrompt] = useState(DEFAULT_PROMPT);
-    const { exit } = useApp();
-    // ─── Why the typed line lives in a ref, not just React state ─────────────
-    //
-    // `useInput`'s callback closes over the `line` value from the render it was
-    // created in. React state updates are asynchronous, so within a SINGLE
-    // keypress callback a `setLine(...)` is NOT visible to a subsequent read of
-    // `line` in that same callback — it still holds the previous render's value.
-    //
-    // That is a real, reproducible data-loss bug on the submit path, not a
-    // theoretical one: pressing Enter has to first commit any
-    // just-typed-but-not-yet-committed text and then read the full line to
-    // submit it. Reading the stale `line` there meant the text typed since the
-    // last render was silently dropped — confirmed in a pty test where typing
-    // "chào" and pressing Enter within ~50ms submitted an EMPTY string.
-    //
-    // `lineRef` is the authoritative, always-current value, updated
-    // synchronously; `line` state exists purely to trigger re-renders. Every
-    // mutation goes through `setLine()` below so the two can never drift.
-    // `cursorRef` mirrors it for the same reason, now that caret position is
-    // also read-then-written within a single keypress callback.
-    const lineRef = useRef('');
-    const setLine = useCallback((next) => {
-        const value = typeof next === 'function' ? next(lineRef.current) : next;
-        lineRef.current = value;
-        setLineState(value);
-    }, []);
-    const cursorRef = useRef(0);
-    const setCursorPos = useCallback((next) => {
-        const value = typeof next === 'function' ? next(cursorRef.current) : next;
-        cursorRef.current = value;
-        setCursorPosState(value);
-    }, []);
-    // One-off question resolver (permission y/n, /init overwrite confirm…).
-    // Takes priority over the persistent onLine/onQueuedLine subscriptions for
-    // one submit — checked FIRST in the Enter branch below regardless of
-    // `busy`, which is what lets a permission prompt fired mid-turn actually
-    // be answered.
-    const askResolverRef = useRef(null);
-    // Persistent handler for ordinary REPL messages (chat.ts's rl.on('line')).
-    const onLineRef = useRef(null);
-    // Persistent handler for a line submitted WHILE busy (no askLine pending) —
-    // a follow-up typed during a running turn, folded in as a queued message.
-    const onQueuedLineRef = useRef(null);
-    // Always-current mirror of `busy` for the same stale-closure reason as
-    // lineRef/cursorRef — useEffectEvent gives useInput a fresh closure per
-    // render regardless, but reading a ref keeps this branch consistent with
-    // the rest of the submit path and avoids relying on that Ink internal.
-    const busyRef = useRef(false);
-    // Timestamp of a Ctrl+C that armed a quit, or null when nothing is armed.
-    // Mirrored into a ref for the same stale-closure reason as lineRef: the
-    // Ctrl+C branch READS the armed state and WRITES it within a single
-    // keypress callback, so reading React state there would see the previous
-    // render's value and the second press would arm again instead of quitting.
-    const [quitArmed, setQuitArmedState] = useState(null);
-    const quitArmedAtRef = useRef(null);
-    const setQuitArmed = useCallback((at) => {
-        quitArmedAtRef.current = at;
-        setQuitArmedState(at);
-    }, []);
-    const [live, setLiveState] = useState('');
-    const print = useCallback((text, opts) => {
-        setItems((prev) => [...prev, { id: idCounter++, content: text, isBanner: opts?.isBanner }]);
-    }, []);
-    // See AppHandle.setBannerRegenerator's own doc for what this is for. A ref
-    // (not state) because it's only ever READ from the resize-settle path below,
-    // never rendered — there is nothing here for React to re-render over.
-    const bannerRegeneratorRef = useRef(null);
-    const setBannerRegenerator = useCallback((fn) => {
-        bannerRegeneratorRef.current = fn;
-    }, []);
-    // Mirrors `footer` for the same stale-closure reason as lineRef/busyRef:
-    // repadBottomChrome (below) is a useCallback with an empty dep array, so it
-    // must read the CURRENT footer through a ref rather than closing over
-    // whatever `footer` was at the render it was created in.
-    const footerRef = useRef({ mode: 'auto', autoApprove: false });
-    const setFooter = useCallback((info) => {
-        footerRef.current = info;
-        setFooterState(info);
-    }, []);
-    const setLive = useCallback((text) => setLiveState(text), []);
-    const setBusy = useCallback((value) => {
-        busyRef.current = value;
-        setBusyState(value);
-    }, []);
-    const askLine = useCallback((promptText) => {
-        setPrompt(promptText || DEFAULT_PROMPT);
-        setLine('');
-        setCursorPos(0);
-        return new Promise((resolve) => {
-            askResolverRef.current = (answer) => {
-                setPrompt(DEFAULT_PROMPT);
-                resolve(answer);
-            };
-        });
-    }, []);
-    const onLine = useCallback((cb) => {
-        onLineRef.current = cb;
-    }, []);
-    const onQueuedLine = useCallback((cb) => {
-        onQueuedLineRef.current = cb;
-    }, []);
-    // Fired when Ctrl+C is pressed WHILE an agent turn is running (busy===true
-    // and no askLine() question is outstanding). chat.ts subscribes to this to
-    // set its abortSignal, mirroring the VS Code panel's stopGeneration —
-    // interrupt the turn, don't kill the whole session. Left null when idle:
-    // in that case Ctrl+C falls through to Ink's own exit()/process teardown,
-    // unchanged from before.
-    const onInterruptRef = useRef(null);
-    const onInterrupt = useCallback((cb) => {
-        onInterruptRef.current = cb;
-    }, []);
-    // Notified when the session is being torn down deliberately, so chat.ts can
-    // save the conversation first — see AppHandle.onExit.
-    const onExitRef = useRef(null);
-    const onExit = useCallback((cb) => {
-        onExitRef.current = cb;
-    }, []);
-    // Both the confirmed-Ctrl+C path and `close()` route through here so the
-    // save can never be attached to only one of them. Guarded against running
-    // twice: chat.ts's 'close' handler calls process.exit(), but a double fire
-    // would otherwise save the same session twice on the way out.
-    //
-    // `notify` distinguishes WHO initiated the teardown, and it matters:
-    //
-    //  • true  — the USER quit from inside the UI (confirmed Ctrl+C). chat.ts
-    //    doesn't know yet, so it must be told in order to save the session.
-    //  • false — chat.ts called `close()` ITSELF (`/exit`, `/update`). It has
-    //    already done whatever saving it wants and is mid-shutdown, so firing
-    //    onExit would re-enter its own 'close' handler. For `/exit` that meant
-    //    a duplicate save and a second "Goodbye."; for `/update` it was worse —
-    //    that handler calls process.exit(0), which would have killed the
-    //    process BEFORE `await updateCommand()` ever ran, silently breaking
-    //    self-update.
-    const exitedRef = useRef(false);
-    const requestExit = useCallback((notify) => {
-        if (exitedRef.current)
-            return;
-        exitedRef.current = true;
-        if (notify)
-            onExitRef.current?.();
-        exit();
-        // eslint-disable-next-line react-hooks/exhaustive-deps
-    }, []);
-    // ─── IME (Vietnamese Telex/VNI, CJK) input ───────────────────────────────
-    //
-    // An earlier revision buffered "IME-like" (non-ASCII) input here for 50ms
-    // before committing it, mirroring the shape of an unmerged upstream Ink PR
-    // (vadimdemedes/ink#865) that was written against the widely-reported IME
-    // character-loss bug (vadimdemedes/ink#759, anthropics/claude-code#22853).
-    // That buffering is deliberately GONE, for two reasons:
-    //
-    // 1. It is no longer necessary. Those upstream reports predate Ink's
-    //    current input pipeline. Ink 7's `input-parser.js` splits backspace
-    //    bytes — BOTH 0x7F (DEL, macOS/Linux IMEs) and 0x08 (BS, Windows IMEs,
-    //    cf. anthropics/claude-code#33891) — into their own key events, and
-    //    delivers the accented text that follows as an intact chunk. Verified
-    //    directly against ink@7.1.1: the Telex backspace-then-recompose
-    //    sequence "\x7Fá" arrives as [backspace, "á"], which the plain handler
-    //    below already resolves correctly (delete "a", insert "á").
-    //
-    // 2. It actively caused the very data loss it was meant to prevent. Holding
-    //    text in a side buffer for 50ms means Enter can arrive while text is
-    //    still uncommitted, which combined with the stale-closure problem
-    //    described at `lineRef` above submitted an EMPTY line — reproduced in a
-    //    pty test by typing "chào" and pressing Enter within 50ms. It also added
-    //    a visible 50ms lag to every accented character.
-    //
-    // So: no buffering, no timers, no non-ASCII special-casing. Every keystroke
-    // is committed synchronously to `lineRef`, exactly like ASCII input.
-    //
-    // NOTE ON `busy`: unlike the removed `inputEnabled` gate, `busy` is never
-    // checked at the TOP of this callback — every branch below (Ctrl+C,
-    // backspace, cursor movement, typing) runs identically whether or not an
-    // agent turn is in flight. `busy` only changes what a completed submit
-    // (the Enter branch) does with the finished line, and only when no
-    // askLine() question is currently outstanding.
-    useInput((char, key) => {
-        if (key.ctrl && char === 'c') {
-            // Precedence (answer a prompt > interrupt a turn > arm/confirm quit)
-            // lives in decideCtrlC so it can be tested — see that function.
-            const action = decideCtrlC({
-                hasPendingQuestion: askResolverRef.current !== null,
-                busy: busyRef.current && onInterruptRef.current !== null,
-                quitArmedAt: quitArmedAtRef.current,
-                now: Date.now(),
-            });
-            if (action === 'answer-prompt') {
-                const askResolve = askResolverRef.current;
-                askResolverRef.current = null;
-                setLine('');
-                setCursorPos(0);
-                askResolve('n');
-                return;
-            }
-            if (action === 'interrupt-turn') {
-                // Interrupting is cheap and recoverable, so it stays a SINGLE press —
-                // and it clears any armed quit, so "stop this turn" can never be the
-                // first half of an accidental exit.
-                setQuitArmed(null);
-                onInterruptRef.current?.();
-                return;
-            }
-            if (action === 'arm-quit') {
-                setQuitArmed(Date.now());
-                return;
-            }
-            // Confirmed quit. The user initiated this from inside the UI, so
-            // notify chat.ts (notify=true) to persist the conversation first.
-            requestExit(true);
-            return;
-        }
-        // ANY other key disarms a pending quit: an accidental Ctrl+C followed by
-        // real work must not leave the session one keystroke from exiting.
-        if (quitArmedAtRef.current !== null)
-            setQuitArmed(null);
-        if (key.backspace || key.delete) {
-            // Backspace acts on the char BEFORE the cursor, Delete on the char
-            // AFTER it — both grapheme-cluster-aware. Previously this always
-            // dropped the LAST character in the line regardless of cursor
-            // position because there was no cursor position at all; the line
-            // itself is unaffected here whenever the cursor already sits at the
-            // relevant edge (start for backspace, end for delete).
-            if (key.delete) {
-                setLine((s) => {
-                    const pos = cursorRef.current;
-                    const end = nextGraphemeBoundary(s, pos);
-                    return s.slice(0, pos) + s.slice(end);
-                });
-                return;
-            }
-            setLine((s) => {
-                const pos = cursorRef.current;
-                if (pos === 0)
-                    return s;
-                const start = prevGraphemeBoundary(s, pos);
-                setCursorPos(start);
-                return s.slice(0, start) + s.slice(pos);
-            });
-            return;
-        }
-        if (key.leftArrow) {
-            setCursorPos((pos) => prevGraphemeBoundary(lineRef.current, pos));
-            return;
-        }
-        if (key.rightArrow) {
-            setCursorPos((pos) => nextGraphemeBoundary(lineRef.current, pos));
-            return;
-        }
-        if (key.upArrow || key.downArrow || key.tab) {
-            return; // history not wired yet — out of scope for this pass
-        }
-        // What Enter, Ctrl+J, Option+Enter and Shift+Enter each mean is decided
-        // by decideEnterKey — see its own doc comment for the measured
-        // byte/`key.*` table behind those rules, and for why `key.shift` alone
-        // could never work.
-        const enterAction = decideEnterKey(char, key);
-        if (enterAction.kind === 'newline') {
-            const pos = cursorRef.current;
-            setLine((s) => s.slice(0, pos) + '\n' + s.slice(pos));
-            setCursorPos(pos + 1);
-            return;
-        }
-        if (enterAction.kind === 'submit') {
-            const newlineIdx = enterAction.splitAt;
-            const before = newlineIdx === -1 ? char : char.slice(0, newlineIdx);
-            const after = newlineIdx === -1 ? '' : char.slice(newlineIdx + 1).replace(/^[\r\n]/, '');
-            // Read the line from `lineRef`, NOT from the `line` state variable —
-            // see the comment at `lineRef` above. The state variable holds whatever
-            // the last render saw, which omits anything typed since; using it here
-            // is what silently submitted empty/truncated lines. Insert `before` AT
-            // the cursor (not always appended) so text typed after arrowing back
-            // into the middle of the line submits in the right order.
-            const pos = cursorRef.current;
-            const submitted = lineRef.current.slice(0, pos) + before + lineRef.current.slice(pos);
-            setLine(after);
-            setCursorPos(0);
-            // Echo the submitted line into the permanent transcript ourselves —
-            // Ink's input box doesn't leave a trace once cleared/replaced.
-            print(prompt + submitted);
-            const askResolve = askResolverRef.current;
-            if (askResolve) {
-                askResolverRef.current = null;
-                askResolve(submitted);
-            }
-            else if (busyRef.current) {
-                // A follow-up sent while the agent is still working — fold it into
-                // the running turn instead of trying to start a second one. Matches
-                // the VS Code panel's queueMessage behavior.
-                onQueuedLineRef.current?.(submitted);
-            }
-            else {
-                onLineRef.current?.(submitted);
-            }
-            return;
-        }
-        setLine((s) => {
-            const pos = cursorRef.current;
-            setCursorPos(pos + char.length);
-            return s.slice(0, pos) + char + s.slice(pos);
-        });
-    });
-    // ── Full-transcript reflow on resize-settle ───────────────────────────────
-    //
-    // Mirrors Claude Code's own resize handling exactly (verified directly
-    // against a real `claude` binary in a pty harness: a plain 100→50 column
-    // resize, both with an empty session and with a completed conversation
-    // turn on screen, writes `\x1b[2J\x1b[H` then reprints EVERY line —
-    // banner, transcript, input, footer — recomputed for the new width).
-    //
-    // This exists because Ink's own resize handling (ink.js `resized()`) only
-    // re-lays-out the CURRENTLY MOUNTED component tree — the live chrome
-    // (separator/input/footer) below. Anything already flushed through
-    // `<Static>` (the banner, every printed transcript line) is gone from that
-    // tree the instant it's written, by design — `<Static>` exists specifically
-    // so Ink never has to re-render old output. Ink is therefore structurally
-    // incapable of reflowing it, and the terminal is left to auto-wrap
-    // whatever bytes are already sitting in its buffer at the OLD width. For a
-    // plain transcript line that is usually harmless (soft-wrapped prose reflows
-    // fine either way), but for the banner's fixed-width box-drawing frame it
-    // visibly tears — the `╭─...─╮` border was built for the OLD column count
-    // and does not divide evenly into the new one.
-    //
-    // The fix: raw-clear the screen and force <Static> to re-emit every item it
-    // already committed, by giving it a NEW `key` (React then mounts a brand
-    // new instance, which has committed nothing yet — see the `key={staticKey}`
-    // prop below). Verified in an isolated Ink probe before wiring this in: a
-    // resize event, `\x1b[2J\x1b[H`, then bumping the key reprinted every
-    // existing item as fresh output, wrapped at the CURRENT terminal width
-    // (border rule length matched the new column count exactly, not the one it
-    // was originally drawn at).
-    //
-    // The banner specifically needs MORE than a reflow, which is why it also
-    // gets regenerated from source (bannerRegeneratorRef) rather than just
-    // replayed verbatim: its box-drawing frame is fixed-width ASCII art
-    // (`'─'.repeat(N)`), not prose. Auto-wrap alone would break the frame's
-    // corners across two lines instead of producing a correctly-proportioned
-    // SMALLER box, which is exactly the tearing this whole feature exists to
-    // fix. Recomputing it at the new width and swapping it in (by id, so this
-    // never depends on the banner always being items[0]) is what makes it look
-    // identical to Claude Code's own resize behavior instead of merely
-    // "not obviously broken".
-    //
-    // Deliberately does NOT touch scrollback (no `\x1b[3J`) — see the long
-    // comment on repaintAfterResizeSettle's own `\x1b[0J` for why that matters;
-    // the same reasoning applies here. `\x1b[2J` only clears the CURRENTLY
-    // VISIBLE screen, which Claude Code's own behavior confirms is an accepted,
-    // deliberate trade-off for this feature (losing what's on the visible
-    // screen at the moment of resize, in exchange for the banner/transcript
-    // always matching the current terminal width) — not a scrollback-destroying
-    // regression like the `\x1b[3J` case that comment warns against.
-    // ── Keep the footer pinned to the terminal's LAST row across a raw-clear ──
-    //
-    // Both forceFullRedraw (resize) and collapseStartupPadding (first message)
-    // do the SAME `\x1b[2J\x1b[H` + <Static> remount, and that remount replays
-    // ONLY what is in `items` — so any blank filler rows padToBottom() (screen.ts)
-    // printed via plain `console.log` at startup are NOT in `items` and are
-    // permanently wiped the first time either path runs. Verified by pty capture
-    // (headless terminal emulation, not a screenshot guess): before this fix,
-    // the footer sat at the true last row right after boot, then jumped up to
-    // mid-screen — leaving a dozen-plus blank rows below it — the instant
-    // EITHER the first message was sent OR the terminal was resized, and never
-    // returned to the bottom for the rest of the session. Both call sites share
-    // this exact defect because both share this exact redraw mechanism, so the
-    // fix lives in one place and both call it.
-    //
-    // The fix: recompute the SAME filler amount padToBottom would have printed
-    // (fillerRowCount — same formula, factored out so the two can't drift
-    // apart) against the terminal's CURRENT dimensions and the items that will
-    // actually survive the remount, then push that filler as a FILLER ITEM
-    // into `items` itself — so it rides along with every future remount instead
-    // of being plain stdout output that only the CURRENT remount replays.
-    //
-    // Only counts rows that will actually be replayed: this must run AFTER any
-    // content mutation for this redraw (e.g. forceFullRedraw's banner
-    // regeneration) has been queued, and BEFORE the remount, so the row tally
-    // matches what <Static> is about to emit. Uses `setItems`'s updater form to
-    // read the truly-current items array rather than a stale `items` closed
-    // over at the time this useCallback was created (same class of bug the
-    // busyRef/lineRef refs elsewhere in this file exist to avoid) — the updater
-    // callback always receives React's latest committed state, ref or not.
-    //
-    // A previous filler item (tagged `isFiller`) is REMOVED before recomputing,
-    // not just replaced in place: leaving a stale one and adding a second would
-    // silently double the padding on every subsequent resize, and its row count
-    // is stale the instant the terminal is resized again anyway.
-    const repadBottomChrome = useCallback(() => {
-        if (!process.stdout.isTTY)
-            return;
-        setItems((prev) => {
-            const withoutOldFiller = prev.filter((it) => !it.isFiller);
-            const printedRows = withoutOldFiller.reduce((sum, it) => sum + rowsOccupied(it.content, process.stdout.columns || 80), 0);
-            const filler = fillerRowCount(printedRows, footerRef.current ? footerText(footerRef.current) : '');
-            if (filler <= 0)
-                return withoutOldFiller;
-            return [...withoutOldFiller, { id: idCounter++, content: fillerContent(filler), isFiller: true }];
-        });
-    }, []);
-    const forceFullRedraw = useCallback(() => {
-        process.stdout.write('\x1b[2J\x1b[H');
-        const regen = bannerRegeneratorRef.current;
-        if (regen) {
-            const columns = process.stdout.columns || 80;
-            setItems((prev) => prev.map((it) => it.isBanner ? { ...it, content: regen(columns) } : it));
-        }
-        repadBottomChrome();
-        setStaticKey((k) => k + 1);
-    }, [repadBottomChrome]);
-    React.useEffect(() => {
-        forceFullRedrawRef = forceFullRedraw;
-        return () => { forceFullRedrawRef = null; };
-    }, [forceFullRedraw]);
-    // See AppHandle.collapseStartupPadding's own doc for the full "why" — this
-    // is the SAME raw-clear + <Static> remount forceFullRedraw uses for resize,
-    // deliberately WITHOUT the banner regenerator step: the terminal's column
-    // count hasn't changed here (only its scrollback contents have), so the
-    // banner's existing box-drawing frame is already correctly sized and
-    // reprinting it verbatim (rather than recomputing it) is both correct and
-    // one fewer moving part. `items` itself is untouched — this only changes
-    // WHERE `<Static>` re-emits them (the current cursor row, which sits right
-    // after the banner once the raw clear runs) rather than WHAT it emits.
-    //
-    // Awaits `inkInstance?.waitUntilRenderFlush()` FIRST (2026-08-14 fix — see
-    // AppHandle.collapseStartupPadding's own doc for the exact race this closes):
-    // the caller (chat.ts's `rl.on('line', …)`) fires from inkTerminal's own Enter
-    // branch immediately after that branch calls `print()` to echo the just-typed
-    // line, a state update Ink may not have flushed to the terminal yet. Clearing
-    // synchronously there could raw-clear + remount `<Static>` before Ink ever
-    // committed that echoed line to a frame, losing it — exactly the same class of
-    // bug repaintAfterResizeSettle's own doc warns `\x1b[0J` against firing before
-    // a pending render commits. Mirrors that function's ordering exactly.
-    const collapseStartupPadding = useCallback(async () => {
-        await inkInstance?.waitUntilRenderFlush();
-        // `\x1b[3J` (erase scrollback) is the fix for the "two banners after the
-        // first message" bug — see this function's own doc on the AppHandle
-        // interface above for the full xterm.js-verified root cause. Without it,
-        // real terminals scroll the erased pre-clear frame into scrollback
-        // instead of deleting it, so the <Static> remount below writes a second,
-        // fresh copy of the banner right after the stale one.
-        process.stdout.write('\x1b[2J\x1b[3J\x1b[H');
-        repadBottomChrome();
-        setStaticKey((k) => k + 1);
-    }, [repadBottomChrome]);
-    // ── Route console.log/console.error through `items` instead of raw stdout ─
-    //
-    // Ink's own patchConsole (installed by render(), see ink.js's `patchConsole()`)
-    // writes console.log/error output DIRECTLY to the terminal — it erases Ink's
-    // current frame, writes the line, then repaints the frame below, but the
-    // line ITSELF never enters `items`. That is fine for a frame Ink never has
-    // to reproduce later, but forceFullRedraw (resize) and collapseStartupPadding
-    // (first message) both raw-clear the screen and remount `<Static>`, and a
-    // remount replays ONLY `items`. Every agent reply (MarkdownStreamRenderer),
-    // every tool-use/result line (formatToolUse/formatToolResult), and every
-    // startup diagnostic (permission rules, loaded skills, MCP connection
-    // status) goes through plain console.log/console.error in chat.ts and
-    // theme.ts — none of it is in `items` — so ALL of it was silently erased
-    // the instant either raw-clear path fired, not merely scrolled off-screen.
-    //
-    // Verified via pty (headless terminal emulation) against a real full turn:
-    // sending "reply with exactly ZEBRA_REPLY_ONLY" then resizing left the
-    // echoed prompt line (which DOES go through print()) on screen, but the
-    // agent's actual reply line was gone — 0 occurrences of the marker where
-    // the reply used to be, not 1. Comparing against the real `claude` binary
-    // in the identical scenario (two full turns, then a resize) confirmed
-    // `claude` keeps BOTH replies fully intact — this is a real regression to
-    // fix, not an accepted trade-off.
-    //
-    // Re-patching console.log/console.error HERE, inside this effect, runs
-    // AFTER Ink's own patchConsole (installed synchronously by render(), before
-    // this component's effects ever run) — so `console.log` at this point is
-    // already Ink's wrapped version, and this replaces it with one that routes
-    // through `print()` (→ `items` → survives every future remount) instead.
-    // This must NOT run before startRowCount() (chat.ts) does its OWN
-    // console.log/error patching for the startup-padding tally — the ordering
-    // there is: startInkTerminal() (mounts this component, its effects run
-    // synchronously as part of that commit) THEN startRowCount() in chat.ts.
-    // So by the time startRowCount() installs ITS wrapper, this one is already
-    // in place underneath it, and startRowCount's wrapper calls `originalLog`
-    // (this function) after tallying — exactly the same layering Ink's own
-    // patchConsole already established one level down. Three layers deep,
-    // each calling into the next, each doing its own job once.
-    React.useEffect(() => {
-        const inkPatchedLog = console.log;
-        const inkPatchedError = console.error;
-        console.log = (...args) => {
-            // console.log() with no arguments prints a single blank line — matches
-            // the convention every call site in this codebase already relies on
-            // (chat.ts's bare `console.log();` between sections).
-            print(args.length === 0 ? ' ' : args.map(String).join(' '));
-        };
-        console.error = (...args) => {
-            print(args.length === 0 ? ' ' : args.map(String).join(' '));
-        };
-        return () => {
-            console.log = inkPatchedLog;
-            console.error = inkPatchedError;
-        };
-    }, [print]);
-    React.useEffect(() => {
-        onReady({
-            print, setFooter, setBannerRegenerator, setLive, askLine, onLine, onQueuedLine, onInterrupt,
-            onExit, setBusy, close: () => requestExit(false), collapseStartupPadding,
-        });
-        // eslint-disable-next-line react-hooks/exhaustive-deps
-    }, []);
-    // The three pieces the input row draws (text before the caret, the single
-    // grapheme under it, the text after). Computed once per render rather than
-    // inline in the JSX so the grapheme-boundary logic lives in one tested
-    // place — see renderInputSlices for what went wrong when this was inline.
-    const slices = renderInputSlices(line, cursorPos);
-    // ── Park the terminal's REAL cursor on the caret, every render ────────────
-    //
-    // See caretPosition's own doc for the full reasoning and the pty evidence:
-    // in short, terminals draw IME composition (VS Code's xterm.js overlay,
-    // Terminal.app's marked text) at the REAL cursor, and Ink hides it and never
-    // moves it, so it sat on the footer — which is why composing Vietnamese
-    // appeared a row BELOW the input box and only jumped up once Space committed
-    // it. `useCursor` is Ink's own API for exactly this ("essential for IME
-    // support, where the composing character is displayed at the cursor
-    // location"), and it also SHOWS the cursor at that cell, matching what the
-    // real `claude` binary does at the end of every frame.
-    //
-    // Called unconditionally during render, not from an effect: the hook records
-    // the position and flushes it in a useInsertionEffect that runs as part of
-    // the same commit Ink renders the frame from (use-cursor.js), so setting it
-    // here is what keeps the cursor and the drawn caret in the same frame rather
-    // than one frame apart.
-    //
-    // ── Why the input row's offset is MEASURED, not computed ─────────────────
-    //
-    // Everything above the input box (the streaming `live` region, then the rule)
-    // has to be counted to know which frame row the caret is on. Computing that
-    // with rowsOccupied() — the helper the padding math already uses — is WRONG
-    // here, and not just theoretically: rowsOccupied wraps by CELL COUNT
-    // (`ceil(width / columns)`, i.e. character wrap), while the live region is a
-    // plain <Text> that Ink lays out with wrap-ansi's WORD wrap, which can spend
-    // strictly more rows on the same string. Found with an Ink probe comparing
-    // the prediction against Yoga's own computed layout at 20 columns: the live
-    // string "aaaaaaaaaaa bbbbbbbbbbb ccccccccccc" (three 11-cell words) really
-    // occupies 4 rows but rowsOccupied predicts 3 — a one-row error, which would
-    // put the cursor (and therefore the IME composition overlay) one row above
-    // the caret for exactly as long as a long status line was streaming.
-    //
-    // `useBoxMetrics` reads the position straight out of the Yoga layout Ink just
-    // computed for the very frame being rendered, so it cannot disagree with what
-    // Ink actually drew, whatever wrapping mode any sibling above uses. It
-    // returns 0 until the first layout pass completes (`hasMeasured` false), and
-    // hiding the cursor for that single first frame is better than showing it at
-    // a guessed position.
-    const inputRowRef = useRef(null);
-    const inputMetrics = useBoxMetrics(inputRowRef);
-    const { setCursorPosition } = useCursor();
-    setCursorPosition(inputMetrics.hasMeasured
-        ? caretPosition({
-            promptWidth: visibleLen(prompt),
-            line,
-            cursorPos,
-            columns: process.stdout.columns || 80,
-            inputRowTop: inputMetrics.top,
-        })
-        : undefined);
-    // ── Why the bottom chrome is NOT pinned with Ink layout ──────────────────
-    //
-    // The separator/input/footer render immediately after whatever has already
-    // been printed, rather than being forced to the terminal's last row by a
-    // full-height flex container. Two attempts at the latter (0.5.36, and again
-    // while investigating this) both regressed startup by scrolling the banner
-    // off-screen. Measured with three standalone Ink probes under a real pty:
-    //
-    //   1. height={rows}   + a flexGrow spacer → footer pushed one row
-    //      OFF-SCREEN (full-height frame plus Ink's trailing newline overflows).
-    //   2. height={rows-1} + spacer, no <Static> → footer correctly pinned.
-    //   3. height={rows-1} + spacer WITH <Static> → footer pinned, but the first
-    //      transcript lines scrolled away permanently — both when <Static>
-    //      committed three times (as real startup does) and when it committed
-    //      once with every item present in the first frame.
-    //
-    // Probe 3 isolates the cause: <Static> is `position: 'absolute'` and
-    // contributes no layout height, so the spacer always expands as though the
-    // transcript were empty, making the frame taller than the room left beneath
-    // the already-printed transcript.
-    //
-    // The bottom gap is instead closed at startup by padToBottom() (ui/screen.ts),
-    // which prints the right number of blank rows through Ink's patched
-    // console.log so the chrome comes to rest near the last row without any
-    // full-height frame being involved.
-    return (React.createElement(Box, { flexDirection: "column" },
-        React.createElement(Static, { items: items, key: staticKey }, (item) => React.createElement(Text, { key: item.id }, item.content)),
-        live ? React.createElement(Text, null, live) : null,
-        React.createElement(Box, { borderStyle: "single", borderTop: false, borderBottom: true, borderLeft: false, borderRight: false, borderDimColor: true }),
-        React.createElement(Box, { ref: inputRowRef },
-            React.createElement(Text, { wrap: "hard" },
-                React.createElement(Text, null, prompt),
-                React.createElement(Text, null, slices.before),
-                React.createElement(Text, { inverse: true }, slices.atCursor),
-                React.createElement(Text, null, slices.after))),
-        React.createElement(Box, { borderStyle: "single", borderTop: false, borderBottom: true, borderLeft: false, borderRight: false, borderDimColor: true }),
-        quitArmed !== null
-            ? React.createElement(Text, { color: "yellow" }, CTRL_C_HINT)
-            : React.createElement(Text, { dimColor: true },
-                footerText(footer),
-                busy ? '  · agent working…' : '')));
-};
-/** Boots the Ink app once, at interactive-session start. Idempotent no-op if already running. */
-export function startInkTerminal() {
-    if (handle)
-        return Promise.resolve(handle);
-    return new Promise((resolve) => {
-        inkInstance = render(React.createElement(App, { onReady: (h) => {
-                handle = h;
-                attachResizeCleanup();
-                resolve(h);
-            } }), {
-            exitOnCtrlC: false,
-            // `kittyKeyboard` is deliberately OMITTED — no option object at all,
-            // matching the real `claude` binary exactly (verified: capturing
-            // claude's raw startup bytes in a pty shows no `\x1b[>1u` enable
-            // sequence and no `\x1b[?u` query anywhere in its output; it relies
-            // purely on ordinary UTF-8 keystrokes). Ink's own opt-in check
-            // (`if (!this.options.kittyKeyboard) return;` in ink.js) then does
-            // nothing at all: no enable sequence is ever written to the terminal.
-            //
-            // This used to be `{ mode: 'enabled', flags: [...] }`, to populate
-            // `key.shift` on Enter for Shift+Enter detection. That traded away
-            // more than the tradeoff docs here previously accounted for: the
-            // protocol doesn't just risk an inert unrecognised escape sequence on
-            // unsupporting terminals — on a REAL Mac Terminal.app with the
-            // system's built-in Vietnamese Telex input source active, enabling it
-            // broke typing accented characters entirely (reported: chào/việt
-            // could be typed in `claude` but not in `nex`, same machine, same
-            // input source, only the enable sequence differed between the two
-            // binaries — confirmed by pty-capturing both). The Kitty protocol
-            // shifts key delivery from "already-composed UTF-8 text" to
-            // raw keycodes, which is exactly the layer an IME's composition
-            // depends on; some terminals that don't fully implement the protocol
-            // still react to the enable sequence by changing how they hand off
-            // composed IME text, rather than silently ignoring it as intended.
-            //
-            // Shift+Enter therefore no longer gets a distinguishable `key.shift`
-            // on any terminal — it always submits, same as plain Enter, exactly
-            // matching claude's own behavior. The existing "\" continuation for
-            // multi-line input (chat.ts) remains the way to enter a literal
-            // newline, unchanged.
-        });
-    });
-}
-/**
- * Attaches the resize-settle cleanup (see repaintAfterResizeSettle above).
- * Deliberately separate from Ink's OWN `stdout.on('resize', …)` listener —
- * this one only debounces and, once quiet, erases stray leftover rows; it
- * never touches layout or triggers a React render itself, so it cannot
- * introduce a second source of "what should this frame look like" for
- * Ink's own resize handling to race against (the exact failure mode
- * documented on the borderBottom rules above, which this deliberately does
- * NOT repeat).
- *
- * Idempotent: startInkTerminal() is itself idempotent (returns the existing
- * handle without re-rendering), so this guards against attaching a second
- * 'resize' listener if it's ever called again for the same process.
- */
-function attachResizeCleanup() {
-    if (resizeListenerAttached || !process.stdout.isTTY)
-        return;
-    resizeListenerAttached = true;
-    resizeDebouncer = createResizeDebouncer(RESIZE_SETTLE_MS, repaintAfterResizeSettle);
-    process.stdout.on('resize', resizeDebouncer.notify);
-}
-export function stopInkTerminal() {
-    if (resizeDebouncer) {
-        process.stdout.off('resize', resizeDebouncer.notify);
-        resizeDebouncer.dispose();
-        resizeDebouncer = null;
-    }
-    resizeListenerAttached = false;
-    inkInstance?.unmount();
-    inkInstance = null;
-    handle = null;
-}
-/**
- * Resolves once Ink has flushed its pending frame to stdout.
- *
- * Ink batches renders and commits them on a timer (maxFps, 30 by default), so
- * immediately after a `console.log` the frame on screen may still be one
- * revision behind. Anything that reasons about the CURRENT cursor row — such
- * as padToBottom deciding how many blank rows are needed — has to wait for
- * that flush, otherwise it measures against a stale frame. Without this the
- * startup padding was nondeterministic: the same terminal size would keep the
- * banner on some runs and scroll its top row away on others.
- */
-export async function flushInkFrame() {
-    await inkInstance?.waitUntilRenderFlush();
-}
-export function getInkTerminal() {
-    return handle;
-}