@aragon-agent/tui 0.0.0-stage → 0.0.1

package/dist/input/keyboard-enhancement.js

@@ -0,0 +1,65 @@
+/**
+ * Keyboard-enhancement lifecycle (the Shift+Enter newline fix).
+ *
+ * WHY A LIFECYCLE MODULE AND NOT ANOTHER `screen.ts` MODE. The alternate
+ * screen is bound to fullscreen rendering; keyboard enhancement must run in
+ * every interactive session, inline included, because the composer is always
+ * there. It still follows the screen module's discipline: bytes are written
+ * ONLY for a TTY stdout, restore is idempotent, and the caller owns every
+ * decision -- this module is told the resolved capability and never derives
+ * one from config or environment.
+ *
+ * PLATFORM SPLIT, DECIDED BY BYTE-LEVEL PROBES (see
+ * docs/diagnoses/shift-enter-newline-dead-by-default):
+ *
+ * - win32: `?9001h` (win32-input-mode). It works through ConPTY on both
+ *   conhost and Windows Terminal; kitty `CSI > 1 u` is swallowed there (a
+ *   `CSI ? u` query never answers) and modifyOtherKeys is a no-op. Gated on
+ *   the SAME `vtInputSupported` measurement the mouse feature uses: on Node
+ *   < 22.17 / < 24.2 libuv never turns on `ENABLE_VIRTUAL_TERMINAL_INPUT`,
+ *   so the records cannot reach the process and the mode would be a lie.
+ * - everything else: kitty disambiguate (`CSI > 1 u`) plus
+ *   `modifyOtherKeys=2`. iTerm2 / kitty / ghostty / WezTerm / foot implement
+ *   at least one; terminals that implement neither ignore both bytes.
+ */
+import { CSI_U_DISABLE, CSI_U_ENABLE, } from './csiu-keys.js';
+import { WIN32_INPUT_DISABLE, WIN32_INPUT_ENABLE } from './win32-input-mode.js';
+const NOOP_HANDLE = { restore() { } };
+/** The handle a gated-out session reads: nothing was pushed, nothing unwinds. */
+export const NOOP_KEYBOARD_ENHANCEMENT = NOOP_HANDLE;
+function safeWrite(stdout, data) {
+    try {
+        stdout.write(data);
+    }
+    catch {
+        // A closed/broken stdout must never crash the exit path.
+    }
+}
+/**
+ * Ask the terminal to report modified keys distinctly. The returned handle's
+ * `restore()` hands the keyboard back; wire it into the same convergence
+ * point the screen restore uses so every exit path unwinds both.
+ *
+ * `vtInputSupported` is the measurement `cli.tsx` already resolves for the
+ * mouse gate; on win32 it decides between `?9001h` and nothing at all.
+ */
+export function enableKeyboardEnhancement(stdout, opts) {
+    if (!stdout || !stdout.isTTY || typeof stdout.write !== 'function')
+        return NOOP_HANDLE;
+    const enable = opts.platform === 'win32'
+        ? (opts.vtInputSupported ? WIN32_INPUT_ENABLE : '')
+        : CSI_U_ENABLE;
+    if (enable.length === 0)
+        return NOOP_HANDLE;
+    const disable = opts.platform === 'win32' ? WIN32_INPUT_DISABLE : CSI_U_DISABLE;
+    safeWrite(stdout, enable);
+    let restored = false;
+    return {
+        restore() {
+            if (restored)
+                return;
+            restored = true;
+            safeWrite(stdout, disable);
+        },
+    };
+}

package/dist/input/keymap.d.ts

@@ -0,0 +1,20 @@
+/**
+ * Editing keymap (spec §3.10). Pure: maps a raw `useInput` `(input, key)` pair
+ * to a line-editing intent. Ink does not surface Home/End/word keys on its
+ * `key` object — those arrive as raw escape sequences in `input` — so this
+ * recognizer inspects both the parsed `key` flags (for Ctrl/Alt combos) and the
+ * raw sequence (for Home/End/word jumps), and returns `null` for anything it
+ * does not own so the caller can drop unknown control bytes instead of
+ * inserting them into the buffer.
+ */
+export type EditIntent = 'home' | 'end' | 'wordLeft' | 'wordRight' | 'deleteWordBack' | 'killToStart' | 'killToEnd';
+/** Minimal shape of Ink's `Key` we consult (structurally compatible). */
+export interface KeyState {
+    ctrl?: boolean;
+    meta?: boolean;
+    shift?: boolean;
+    leftArrow?: boolean;
+    rightArrow?: boolean;
+}
+/** Recognize a line-editing intent, or `null` if this key is not an edit op. */
+export declare function recognize(input: string, key: KeyState): EditIntent | null;

package/dist/input/keymap.js

@@ -0,0 +1,99 @@
+/**
+ * Editing keymap (spec §3.10). Pure: maps a raw `useInput` `(input, key)` pair
+ * to a line-editing intent. Ink does not surface Home/End/word keys on its
+ * `key` object — those arrive as raw escape sequences in `input` — so this
+ * recognizer inspects both the parsed `key` flags (for Ctrl/Alt combos) and the
+ * raw sequence (for Home/End/word jumps), and returns `null` for anything it
+ * does not own so the caller can drop unknown control bytes instead of
+ * inserting them into the buffer.
+ */
+/**
+ * Map a Ctrl-modified key to an intent, if any.
+ *
+ * `Ctrl+K` IS DELIBERATELY NOT HERE (agent-model-kits D-15). That byte belongs
+ * to the Agent-kit picker on the main screen, and this recognizer runs BEFORE
+ * `PromptInput`'s `if (key.ctrl) return` - so keeping the binding would delete
+ * the user's draft in one listener while the other opened the overlay. The
+ * capability moved to `Alt+K` (`fromMeta`) instead of being dropped.
+ */
+function fromCtrl(input, key) {
+    if (key.leftArrow)
+        return 'wordLeft';
+    if (key.rightArrow)
+        return 'wordRight';
+    switch (input) {
+        case 'a':
+            return 'home';
+        case 'e':
+            return 'end';
+        case 'w':
+            return 'deleteWordBack';
+        case 'u':
+            return 'killToStart';
+        default:
+            return null;
+    }
+}
+/** Map an Alt/Meta-modified key to an intent, if any. */
+function fromMeta(input) {
+    if (input === 'b')
+        return 'wordLeft';
+    if (input === 'f')
+        return 'wordRight';
+    // `killToEnd` LIVES HERE NOW (agent-model-kits D-15). `Alt+K` keeps the
+    // capability, and it keeps the kill family together: `M-k` is kill-sentence in
+    // the Emacs tradition this keymap already borrows `Ctrl+W` and `Alt+B/F` from.
+    if (input === 'k')
+        return 'killToEnd';
+    if (input === '\x7f' || input === '\b')
+        return 'deleteWordBack';
+    return null;
+}
+/** Map a raw terminal escape / control sequence to an intent, if any. */
+function fromRaw(input) {
+    switch (input) {
+        case '\x1b[H':
+        case '\x1b[1~':
+        case '\x1bOH':
+        case '\x01': // Ctrl+A (raw)
+            return 'home';
+        case '\x1b[F':
+        case '\x1b[4~':
+        case '\x1bOF':
+        case '\x05': // Ctrl+E (raw)
+            return 'end';
+        case '\x1b[1;5D':
+        case '\x1bb':
+            return 'wordLeft';
+        case '\x1b[1;5C':
+        case '\x1bf':
+            return 'wordRight';
+        case '\x17': // Ctrl+W (raw)
+        case '\x1b\x7f':
+        case '\x1b\b':
+            return 'deleteWordBack';
+        case '\x15': // Ctrl+U (raw)
+            return 'killToStart';
+        case '\x1bk':
+            // Alt+K (raw ESC + k). `\x0b` (Ctrl+K) is deliberately ABSENT: it belongs
+            // to the Agent-kit picker, and a case for it here would be a dead binding
+            // that still looks alive to every future reader.
+            return 'killToEnd';
+        default:
+            return null;
+    }
+}
+/** Recognize a line-editing intent, or `null` if this key is not an edit op. */
+export function recognize(input, key) {
+    if (key.ctrl) {
+        const hit = fromCtrl(input, key);
+        if (hit)
+            return hit;
+    }
+    if (key.meta) {
+        const hit = fromMeta(input);
+        if (hit)
+            return hit;
+    }
+    return fromRaw(input);
+}

package/dist/input/limits.d.ts

@@ -0,0 +1,118 @@
+/**
+ * Structural bounds for paste handling (tui-paste-handling D-10 / section 8).
+ *
+ * THESE ARE STRUCTURAL, NOT POLICY. The package convention recorded in
+ * `.claude-index/index.md` is that `limits.ts` carries the numbers an
+ * implementation needs to stay bounded, while `config/schema.ts` carries the
+ * preferences a user is allowed to have. The only user-facing key this feature
+ * adds is the boolean `paste`; a tunable collapse threshold is a preference
+ * nobody has asked for, and a kill switch is what a bug report actually needs.
+ *
+ * The two framing constants below are the only bytes that cross from the stdin
+ * filter into the composer, so they are load-bearing in a way a threshold is
+ * not: see `PASTE_OPEN`.
+ */
+/**
+ * Ceiling on ONE paste. Above it the body is dropped and the user is told,
+ * never truncated (D-11): a truncated paste loses data and looks like success.
+ */
+export declare const PASTE_MAX_BYTES: number;
+/** Ceiling on every live payload in one draft, summed. Above it a paste is refused. */
+export declare const PASTE_DRAFT_MAX_BYTES: number;
+/** Ceiling on collapsed blocks in one draft. Above it a paste is refused. */
+export declare const PASTE_MAX_BLOCKS = 32;
+/**
+ * Tier 2's single-line rule: a chunk of at least this many printable characters
+ * with no line break is a paste.
+ *
+ * Safe because coalescing a keyboard burst into 25 characters inside one
+ * event-loop turn needs roughly 1 500 WPM. It is a statement about what a
+ * KEYBOARD can emit, not about what text looks like.
+ */
+export declare const PASTE_MIN_BURST_CHARS = 25;
+/** Tier 2 coalescing window. Ordinary typing never opens it, so never pays it. */
+export declare const PASTE_BURST_MS = 15;
+/**
+ * How long an unterminated Tier 1 body is held before it is force-flushed.
+ *
+ * I-4: an unterminated `\x1b[200~` must never be able to wedge keyboard input,
+ * which is the rule `MAX_PENDING_MOUSE_CHARS` already encodes for mouse reports.
+ */
+export declare const PASTE_ASSEMBLY_MAX_MS = 2000;
+/**
+ * How long a paste-marker head that was ALREADY released to the pass-through as
+ * ordinary text may still be recognised as the head of a marker (defect 2: the
+ * torn-marker rescue in `stdin-filter.ts`).
+ *
+ * STRUCTURAL, NOT POLICY: no config key exposes it, because it bounds what the
+ * byte stream can physically do -- a marker split across two reads -- and not
+ * what a user prefers. What it does NOT do is delay a keystroke: the 12 ms
+ * pending-flush window in `stdin-filter.ts` still releases a lone ESC exactly as
+ * before, and this window only governs whether that release may be spliced back
+ * in front of the next chunk so an assembled marker is consumed, not typed.
+ *
+ * THE FALSE POSITIVE IS THE TRADE-OFF, AND IT IS ACCEPTED. Firing the rescue
+ * wrongly needs the user to press Esc and then TYPE the literal characters
+ * `[200~` or `[201~` inside this window -- a sequence no keyboard produces, and
+ * at worst five characters of lost typing. Paying that buys a fix for visible
+ * `[200~` / `[201~` garbage in the draft, which is the failure the whole paste
+ * feature exists to prevent.
+ */
+export declare const PASTE_MARKER_RESCAN_TTL_MS = 250;
+/**
+ * The inline frame the filter writes into the stream Ink reads (D-3 / I-5).
+ *
+ * ON THE SAME STREAM, NOT A SIDE CHANNEL. `wrapper.write(text)` is delivered
+ * asynchronously; a synchronous side-channel emit would apply the paste BEFORE
+ * text that preceded it in the same chunk. Framing preserves order by
+ * construction.
+ *
+ * NUL is the delimiter because no terminal delivers it for any key, and because
+ * `sanitisePaste` strips every NUL out of every payload -- so a payload can
+ * never forge a frame boundary.
+ */
+export declare const PASTE_OPEN = "\0[";
+export declare const PASTE_CLOSE = "\0]";
+/**
+ * The inline frame that carries ONE newline intent from the stdin filter to the
+ * composer (tui-shift-enter-copy-queue 3.2).
+ *
+ * SAME FAMILY AS `PASTE_OPEN`, with the same guarantee and for the same reason:
+ * NUL is the delimiter because no terminal delivers it for any key, and because
+ * `sanitisePaste` strips every NUL out of every payload -- so pasted text can
+ * never forge this frame either. A newline intent is single, atomic and carries
+ * no payload, so one constant replaces the OPEN/CLOSE pair.
+ */
+export declare const ENTER_NEWLINE_FRAME = "\0n";
+/**
+ * The inline frame that carries ONE "Ctrl+I was pressed" intent from the stdin
+ * filter to `App` (project-indexer Ctrl+I trigger).
+ *
+ * WHY A FRAME AND NOT `key.ctrl && input === 'i'`. Legacy terminals encode
+ * Ctrl+I as the same byte as Tab (0x09), so by the time the stream reaches Ink
+ * the two are indistinguishable. Under win32-input-mode (`?9001h`) and kitty
+ * CSI-u the modifiers ARE known at translation time, and both translators emit
+ * this frame instead of the legacy Tab byte. Same NUL-delimiter guarantee as
+ * `ENTER_NEWLINE_FRAME`: no terminal delivers NUL for a key and pasted text is
+ * stripped of NUL, so a payload can never forge it. Terminals without keyboard
+ * enhancement keep the legacy collapse — Ctrl+I there is Tab, documented in the
+ * README keybindings table.
+ */
+export declare const INDEX_KEY_FRAME = "\0i";
+/**
+ * The one channel from the stdin filter to `App`'s notice dispatch (P1-3 / I-15).
+ *
+ * The filter is constructed in `cli.tsx` BEFORE `render()`, so it has no
+ * `dispatch`. Its only other outlet is the logger, and a limit that writes only
+ * to a log file is indistinguishable -- from the user's chair -- from a paste
+ * that silently did nothing, which is exactly what D-11 exists to rule out.
+ *
+ * Same late-bound shape as `selectionBridge` / `updateBridge` / `terminalBridge`:
+ * `cli.tsx` creates the object, `App` assigns `notify` on mount and clears it on
+ * unmount, and the filter calls `bridge.notify?.(...)`.
+ */
+export interface PasteBridge {
+    notify: ((level: 'warn' | 'error', text: string) => void) | null;
+}
+/** Human-readable byte size for the refusal toast (`4.1 MB`, `812.0 KB`, `7 B`). */
+export declare function formatPasteSize(bytes: number): string;

package/dist/input/limits.js

@@ -0,0 +1,109 @@
+/**
+ * Structural bounds for paste handling (tui-paste-handling D-10 / section 8).
+ *
+ * THESE ARE STRUCTURAL, NOT POLICY. The package convention recorded in
+ * `.claude-index/index.md` is that `limits.ts` carries the numbers an
+ * implementation needs to stay bounded, while `config/schema.ts` carries the
+ * preferences a user is allowed to have. The only user-facing key this feature
+ * adds is the boolean `paste`; a tunable collapse threshold is a preference
+ * nobody has asked for, and a kill switch is what a bug report actually needs.
+ *
+ * The two framing constants below are the only bytes that cross from the stdin
+ * filter into the composer, so they are load-bearing in a way a threshold is
+ * not: see `PASTE_OPEN`.
+ */
+/**
+ * Ceiling on ONE paste. Above it the body is dropped and the user is told,
+ * never truncated (D-11): a truncated paste loses data and looks like success.
+ */
+export const PASTE_MAX_BYTES = 2 * 1024 * 1024;
+/** Ceiling on every live payload in one draft, summed. Above it a paste is refused. */
+export const PASTE_DRAFT_MAX_BYTES = 8 * 1024 * 1024;
+/** Ceiling on collapsed blocks in one draft. Above it a paste is refused. */
+export const PASTE_MAX_BLOCKS = 32;
+/**
+ * Tier 2's single-line rule: a chunk of at least this many printable characters
+ * with no line break is a paste.
+ *
+ * Safe because coalescing a keyboard burst into 25 characters inside one
+ * event-loop turn needs roughly 1 500 WPM. It is a statement about what a
+ * KEYBOARD can emit, not about what text looks like.
+ */
+export const PASTE_MIN_BURST_CHARS = 25;
+/** Tier 2 coalescing window. Ordinary typing never opens it, so never pays it. */
+export const PASTE_BURST_MS = 15;
+/**
+ * How long an unterminated Tier 1 body is held before it is force-flushed.
+ *
+ * I-4: an unterminated `\x1b[200~` must never be able to wedge keyboard input,
+ * which is the rule `MAX_PENDING_MOUSE_CHARS` already encodes for mouse reports.
+ */
+export const PASTE_ASSEMBLY_MAX_MS = 2_000;
+/**
+ * How long a paste-marker head that was ALREADY released to the pass-through as
+ * ordinary text may still be recognised as the head of a marker (defect 2: the
+ * torn-marker rescue in `stdin-filter.ts`).
+ *
+ * STRUCTURAL, NOT POLICY: no config key exposes it, because it bounds what the
+ * byte stream can physically do -- a marker split across two reads -- and not
+ * what a user prefers. What it does NOT do is delay a keystroke: the 12 ms
+ * pending-flush window in `stdin-filter.ts` still releases a lone ESC exactly as
+ * before, and this window only governs whether that release may be spliced back
+ * in front of the next chunk so an assembled marker is consumed, not typed.
+ *
+ * THE FALSE POSITIVE IS THE TRADE-OFF, AND IT IS ACCEPTED. Firing the rescue
+ * wrongly needs the user to press Esc and then TYPE the literal characters
+ * `[200~` or `[201~` inside this window -- a sequence no keyboard produces, and
+ * at worst five characters of lost typing. Paying that buys a fix for visible
+ * `[200~` / `[201~` garbage in the draft, which is the failure the whole paste
+ * feature exists to prevent.
+ */
+export const PASTE_MARKER_RESCAN_TTL_MS = 250;
+/**
+ * The inline frame the filter writes into the stream Ink reads (D-3 / I-5).
+ *
+ * ON THE SAME STREAM, NOT A SIDE CHANNEL. `wrapper.write(text)` is delivered
+ * asynchronously; a synchronous side-channel emit would apply the paste BEFORE
+ * text that preceded it in the same chunk. Framing preserves order by
+ * construction.
+ *
+ * NUL is the delimiter because no terminal delivers it for any key, and because
+ * `sanitisePaste` strips every NUL out of every payload -- so a payload can
+ * never forge a frame boundary.
+ */
+export const PASTE_OPEN = '\u0000[';
+export const PASTE_CLOSE = '\u0000]';
+/**
+ * The inline frame that carries ONE newline intent from the stdin filter to the
+ * composer (tui-shift-enter-copy-queue 3.2).
+ *
+ * SAME FAMILY AS `PASTE_OPEN`, with the same guarantee and for the same reason:
+ * NUL is the delimiter because no terminal delivers it for any key, and because
+ * `sanitisePaste` strips every NUL out of every payload -- so pasted text can
+ * never forge this frame either. A newline intent is single, atomic and carries
+ * no payload, so one constant replaces the OPEN/CLOSE pair.
+ */
+export const ENTER_NEWLINE_FRAME = '\u0000n';
+/**
+ * The inline frame that carries ONE "Ctrl+I was pressed" intent from the stdin
+ * filter to `App` (project-indexer Ctrl+I trigger).
+ *
+ * WHY A FRAME AND NOT `key.ctrl && input === 'i'`. Legacy terminals encode
+ * Ctrl+I as the same byte as Tab (0x09), so by the time the stream reaches Ink
+ * the two are indistinguishable. Under win32-input-mode (`?9001h`) and kitty
+ * CSI-u the modifiers ARE known at translation time, and both translators emit
+ * this frame instead of the legacy Tab byte. Same NUL-delimiter guarantee as
+ * `ENTER_NEWLINE_FRAME`: no terminal delivers NUL for a key and pasted text is
+ * stripped of NUL, so a payload can never forge it. Terminals without keyboard
+ * enhancement keep the legacy collapse — Ctrl+I there is Tab, documented in the
+ * README keybindings table.
+ */
+export const INDEX_KEY_FRAME = '\u0000i';
+/** Human-readable byte size for the refusal toast (`4.1 MB`, `812.0 KB`, `7 B`). */
+export function formatPasteSize(bytes) {
+    if (bytes >= 1024 * 1024)
+        return `${(bytes / (1024 * 1024)).toFixed(1)} MB`;
+    if (bytes >= 1024)
+        return `${(bytes / 1024).toFixed(1)} KB`;
+    return `${bytes} B`;
+}

package/dist/input/mouse-events.d.ts

@@ -0,0 +1,87 @@
+/**
+ * Mouse-report parser (mouse-wheel-region-routing §5.1) — pure, stream-free.
+ *
+ * The alternate screen has no native scrollback, so every modern terminal turns
+ * on DEC private mode 1007 (*alternate scroll*) and translates each wheel notch
+ * into a burst of arrow keys. Arrow keys carry NO POINTER POSITION, which is
+ * why region routing is impossible from that channel and why the CLI asks for
+ * real SGR mouse reporting instead (`\x1b[?1000h\x1b[?1006h`).
+ *
+ * Asking for it is only half the job. Ink 5.2.1 has no mouse branch at all:
+ * `parse-keypress.js` fails to match `\x1b[<64;40;12M`, `use-input.js` strips
+ * the leading ESC, and `PromptInput`'s `isControlSeq` guard passes the
+ * remainder (`[` is 0x5B, >= 0x20) straight into `insert()`. So an unfiltered
+ * mouse report is not ignored — it is TYPED INTO THE USER'S MESSAGE. This
+ * module exists so `stdin-mouse-filter.ts` can remove every byte of every
+ * report before Ink ever sees the chunk (invariant I-1).
+ *
+ * Every mouse report is CONSUMED here whatever it turns out to be; what changed
+ * with tui-selection-and-scroll-follow is that press / drag / release are now
+ * EMITTED as well as consumed, so `SelectionController` can build a selection
+ * out of them (§4.4.2). They were previously recognized and thrown away.
+ */
+export interface WheelEvent {
+    readonly kind: 'wheel';
+    readonly dir: 'up' | 'down';
+    /** 1-based terminal column, as reported. */
+    readonly x: number;
+    /** 1-based terminal row, as reported. */
+    readonly y: number;
+    readonly shift: boolean;
+    readonly alt: boolean;
+    readonly ctrl: boolean;
+}
+export interface ButtonEvent {
+    readonly kind: 'press' | 'drag' | 'release';
+    /** 0 = left, 1 = middle, 2 = right. Never 3 — see `decodeReport`. */
+    readonly button: 0 | 1 | 2;
+    /** 1-based terminal column, as reported. */
+    readonly x: number;
+    /** 1-based terminal row, as reported. */
+    readonly y: number;
+    readonly shift: boolean;
+    readonly alt: boolean;
+    readonly ctrl: boolean;
+}
+export type MouseEvent = WheelEvent | ButtonEvent;
+export interface MouseSplit {
+    /** Mouse events, in arrival order. Unrecognized reports are dropped, not returned. */
+    readonly events: MouseEvent[];
+    /** Everything that was not a mouse report — forward this to Ink verbatim. */
+    readonly text: string;
+    /** Trailing strict prefix of a possible report; feed it back in with the next chunk. */
+    readonly pending: string;
+}
+/**
+ * Which wire encoding a report arrived in. It is a PARAMETER rather than a
+ * remembered rule because the rule it expresses is invariant I-11 and the cost
+ * of forgetting it is a permanently frozen viewport (see `decodeReport`).
+ */
+export type MouseEncoding = 'sgr' | 'x10';
+/**
+ * Ceiling on the held-back tail. A malformed sequence that looks like a prefix
+ * forever must never be able to wedge input: past this length the tail is
+ * flushed as ordinary text and parsing resumes from the next byte.
+ */
+export declare const MAX_PENDING_MOUSE_CHARS = 32;
+/**
+ * True when `s` is a PROPER prefix of a possible mouse report (never a full
+ * one). Nothing a keyboard produces matches beyond `\x1b` and `\x1b[`, which is
+ * why the filter's flush timer is a rare path rather than a latency tax on
+ * typing: ordinary text and pasted blocks contain no `\x1b[<`.
+ */
+export declare function isMousePrefix(s: string): boolean;
+/**
+ * Split a decoded stdin chunk into mouse events, passthrough text, and a
+ * trailing prefix to carry into the next chunk.
+ *
+ * The caller is expected to feed `pending + nextChunk` back in; ConPTY does
+ * split writes mid-sequence, and a report torn across two chunks would
+ * otherwise leak its tail into the composer (R-6).
+ *
+ * ONE CHANNEL, NOT TWO (§4.4.2). Widening this list to carry buttons alongside
+ * wheel notches is what keeps ARRIVAL ORDER intact between them; a second
+ * channel would let a press overtake the notch that preceded it, and the
+ * selection would then be anchored against rows that had already scrolled.
+ */
+export declare function splitMouseEvents(buffer: string): MouseSplit;