hammoc 1.6.0 → 1.7.0

package/packages/server/dist/services/cliGridRegion.d.ts

@@ -0,0 +1,44 @@
+/**
+ * Shared "live footer region" helper for the CLI settled-grid readers (Epic 37).
+ *
+ * claude's interactive UI — the idle input box, the generation spinner + "↓ N tokens" / "esc to
+ * interrupt" footer, the mode status row, and a selection box's nav/cancel footer — all render flush
+ * at the BOTTOM of the screen. Restricting the live-state regexes to this region is the "anchor to
+ * the live footer, not the scrollback body" discipline shared by the grid readers: it stops a
+ * resume-repaint whose prior answer QUOTED any of those markers in the transcript body from
+ * masquerading as a live signal.
+ *
+ * 실측 2026-06-13: a long answer that *discussed* the CLI spinner ("esc to interrupt" / "↓N tokens")
+ * was repainted into the scrollback on resume; the old whole-screen scan matched the quoted phrases,
+ * read the idle input box as "generating", returned `unknown` from the pre-injection classifier, and
+ * the next turn's prompt was withheld → the turn was lost. Anchoring the readers to the bottom region
+ * removes that whole class (idle/generation gate, mode-row read, spinner counter).
+ *
+ * Uses the last NON-EMPTY rows so trailing blank rows below the box don't shrink the window.
+ * Version-fragile like the rest of the CLI screen readers (the bottom UI height can shift across
+ * claude TUI revisions), but a strict improvement over scanning the whole screen.
+ */
+/** How many bottom non-empty rows count as the live UI cluster (box + spinner/footer + status row). */
+export declare const CLI_LIVE_FOOTER_ROWS = 8;
+/** The last non-empty rows of a settled grid — the live UI cluster. Empties are dropped first so a
+ *  few blank rows below the input box don't push the box out of the window. */
+export declare function liveFooterRows(grid: string[]): string[];
+/** `liveFooterRows` joined with '\n', for the line-spanning existence regexes. */
+export declare function liveFooterText(grid: string[]): string;
+/**
+ * The SCROLLBACK BODY — the grid rows strictly ABOVE the live footer CLUSTER (the inverse of
+ * `liveFooterRows`). Story 37.9/37.10: the card parser (`parseGridCards`) folds a trailing non-glyph
+ * row into the open card, so feeding it the footer would pollute the last card — and, worse, fold the
+ * live spinner (whose `Ns`/`↓N tokens` counters change every frame) into a thinking card, making its
+ * text churn and re-emit endlessly (실측 2026-06-16).
+ *
+ * During generation claude renders the footer as a CLUSTER of contiguous rows — the spinner
+ * (`↓N tokens`), the input box (`────` / `❯` / `────`), the `esc to interrupt` row, then the mode/effort
+ * status row at the very bottom. Cutting at only the BOTTOM-most anchor leaves the spinner (the
+ * cluster's TOP) inside the body. So: find the bottom-most anchor, then walk UP through the contiguous
+ * cluster (anchor rows + box-rule chrome — claude draws no blank WITHIN it) to the cluster top, and cut
+ * there. Anything below (incl. the variable status row) is excluded; a blank or content row above the
+ * cluster ends the walk and stays in the body. No anchor at all ⇒ a pure scrollback frame ⇒ all body.
+ */
+export declare function scrollbackBodyRows(grid: string[]): string[];
+//# sourceMappingURL=cliGridRegion.d.ts.map

package/packages/server/dist/services/cliGridRegion.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"cliGridRegion.d.ts","sourceRoot":"","sources":["../../src/services/cliGridRegion.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;GAmBG;AAEH,uGAAuG;AACvG,eAAO,MAAM,oBAAoB,IAAI,CAAC;AAEtC;+EAC+E;AAC/E,wBAAgB,cAAc,CAAC,IAAI,EAAE,MAAM,EAAE,GAAG,MAAM,EAAE,CAGvD;AAED,kFAAkF;AAClF,wBAAgB,cAAc,CAAC,IAAI,EAAE,MAAM,EAAE,GAAG,MAAM,CAErD;AAcD;;;;;;;;;;;;;;GAcG;AACH,wBAAgB,kBAAkB,CAAC,IAAI,EAAE,MAAM,EAAE,GAAG,MAAM,EAAE,CAsB3D"}

package/packages/server/dist/services/cliGridRegion.js

@@ -0,0 +1,94 @@
+/**
+ * Shared "live footer region" helper for the CLI settled-grid readers (Epic 37).
+ *
+ * claude's interactive UI — the idle input box, the generation spinner + "↓ N tokens" / "esc to
+ * interrupt" footer, the mode status row, and a selection box's nav/cancel footer — all render flush
+ * at the BOTTOM of the screen. Restricting the live-state regexes to this region is the "anchor to
+ * the live footer, not the scrollback body" discipline shared by the grid readers: it stops a
+ * resume-repaint whose prior answer QUOTED any of those markers in the transcript body from
+ * masquerading as a live signal.
+ *
+ * 실측 2026-06-13: a long answer that *discussed* the CLI spinner ("esc to interrupt" / "↓N tokens")
+ * was repainted into the scrollback on resume; the old whole-screen scan matched the quoted phrases,
+ * read the idle input box as "generating", returned `unknown` from the pre-injection classifier, and
+ * the next turn's prompt was withheld → the turn was lost. Anchoring the readers to the bottom region
+ * removes that whole class (idle/generation gate, mode-row read, spinner counter).
+ *
+ * Uses the last NON-EMPTY rows so trailing blank rows below the box don't shrink the window.
+ * Version-fragile like the rest of the CLI screen readers (the bottom UI height can shift across
+ * claude TUI revisions), but a strict improvement over scanning the whole screen.
+ */
+/** How many bottom non-empty rows count as the live UI cluster (box + spinner/footer + status row). */
+export const CLI_LIVE_FOOTER_ROWS = 8;
+/** The last non-empty rows of a settled grid — the live UI cluster. Empties are dropped first so a
+ *  few blank rows below the input box don't push the box out of the window. */
+export function liveFooterRows(grid) {
+    const nonEmpty = grid.filter((row) => row.trim().length > 0);
+    return nonEmpty.slice(-CLI_LIVE_FOOTER_ROWS);
+}
+/** `liveFooterRows` joined with '\n', for the line-spanning existence regexes. */
+export function liveFooterText(grid) {
+    return liveFooterRows(grid).join('\n');
+}
+/**
+ * The bottommost live-footer anchor: claude's generation spinner ("… esc to interrupt" / a
+ * "↓/↑ N tokens" counter) or the idle input-box prompt glyph (`❯`). The footer always renders flush
+ * at the BOTTOM, so the BOTTOMMOST match is the live footer (a scrollback line that merely *quotes*
+ * one of these markers sits above it — the same ISSUE-99 anti-poisoning discipline as the readers).
+ */
+const LIVE_FOOTER_ANCHOR_RE = /esc to interrupt|[↑↓]\s*[\d.,]+\s*k?\s*tokens|❯/i;
+/** A pure box-drawing rule row (the input-box top/bottom border `────`, corners, sides) — chrome that
+ *  is part of the live-footer cluster, never a content card. */
+const BOX_RULE_RE = /^[─╭╮╰╯│]+$/;
+/**
+ * The SCROLLBACK BODY — the grid rows strictly ABOVE the live footer CLUSTER (the inverse of
+ * `liveFooterRows`). Story 37.9/37.10: the card parser (`parseGridCards`) folds a trailing non-glyph
+ * row into the open card, so feeding it the footer would pollute the last card — and, worse, fold the
+ * live spinner (whose `Ns`/`↓N tokens` counters change every frame) into a thinking card, making its
+ * text churn and re-emit endlessly (실측 2026-06-16).
+ *
+ * During generation claude renders the footer as a CLUSTER of contiguous rows — the spinner
+ * (`↓N tokens`), the input box (`────` / `❯` / `────`), the `esc to interrupt` row, then the mode/effort
+ * status row at the very bottom. Cutting at only the BOTTOM-most anchor leaves the spinner (the
+ * cluster's TOP) inside the body. So: find the bottom-most anchor, then walk UP through the contiguous
+ * cluster (anchor rows + box-rule chrome — claude draws no blank WITHIN it) to the cluster top, and cut
+ * there. Anything below (incl. the variable status row) is excluded; a blank or content row above the
+ * cluster ends the walk and stays in the body. No anchor at all ⇒ a pure scrollback frame ⇒ all body.
+ */
+export function scrollbackBodyRows(grid) {
+    let bottom = -1;
+    for (let i = grid.length - 1; i >= 0; i--) {
+        if (LIVE_FOOTER_ANCHOR_RE.test(grid[i])) {
+            bottom = i;
+            break;
+        }
+    }
+    if (bottom < 0)
+        return grid;
+    const isCluster = (r) => LIVE_FOOTER_ANCHOR_RE.test(r) || BOX_RULE_RE.test(r.trim());
+    let top = bottom;
+    let i = bottom - 1;
+    while (i >= 0) {
+        if (isCluster(grid[i])) {
+            top = i;
+            i--;
+            continue;
+        }
+        if (grid[i].trim() === '') {
+            // A blank belongs to the cluster only if footer chrome continues ABOVE it (claude pads between
+            // the spinner and the input box); a blank with CONTENT above it is a body↔footer separator and
+            // stays in the body. Peek past the blank run.
+            let j = i - 1;
+            while (j >= 0 && grid[j].trim() === '')
+                j--;
+            if (j >= 0 && isCluster(grid[j])) {
+                top = j;
+                i = j - 1;
+                continue;
+            }
+        }
+        break; // content row (or a separator blank) → the cluster ends here
+    }
+    return grid.slice(0, top);
+}
+//# sourceMappingURL=cliGridRegion.js.map

package/packages/server/dist/services/cliGridRegion.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"cliGridRegion.js","sourceRoot":"","sources":["../../src/services/cliGridRegion.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;GAmBG;AAEH,uGAAuG;AACvG,MAAM,CAAC,MAAM,oBAAoB,GAAG,CAAC,CAAC;AAEtC;+EAC+E;AAC/E,MAAM,UAAU,cAAc,CAAC,IAAc;IAC3C,MAAM,QAAQ,GAAG,IAAI,CAAC,MAAM,CAAC,CAAC,GAAG,EAAE,EAAE,CAAC,GAAG,CAAC,IAAI,EAAE,CAAC,MAAM,GAAG,CAAC,CAAC,CAAC;IAC7D,OAAO,QAAQ,CAAC,KAAK,CAAC,CAAC,oBAAoB,CAAC,CAAC;AAC/C,CAAC;AAED,kFAAkF;AAClF,MAAM,UAAU,cAAc,CAAC,IAAc;IAC3C,OAAO,cAAc,CAAC,IAAI,CAAC,CAAC,IAAI,CAAC,IAAI,CAAC,CAAC;AACzC,CAAC;AAED;;;;;GAKG;AACH,MAAM,qBAAqB,GAAG,kDAAkD,CAAC;AAEjF;gEACgE;AAChE,MAAM,WAAW,GAAG,aAAa,CAAC;AAElC;;;;;;;;;;;;;;GAcG;AACH,MAAM,UAAU,kBAAkB,CAAC,IAAc;IAC/C,IAAI,MAAM,GAAG,CAAC,CAAC,CAAC;IAChB,KAAK,IAAI,CAAC,GAAG,IAAI,CAAC,MAAM,GAAG,CAAC,EAAE,CAAC,IAAI,CAAC,EAAE,CAAC,EAAE,EAAE,CAAC;QAC1C,IAAI,qBAAqB,CAAC,IAAI,CAAC,IAAI,CAAC,CAAC,CAAC,CAAC,EAAE,CAAC;YAAC,MAAM,GAAG,CAAC,CAAC;YAAC,MAAM;QAAC,CAAC;IACjE,CAAC;IACD,IAAI,MAAM,GAAG,CAAC;QAAE,OAAO,IAAI,CAAC;IAC5B,MAAM,SAAS,GAAG,CAAC,CAAS,EAAE,EAAE,CAAC,qBAAqB,CAAC,IAAI,CAAC,CAAC,CAAC,IAAI,WAAW,CAAC,IAAI,CAAC,CAAC,CAAC,IAAI,EAAE,CAAC,CAAC;IAC7F,IAAI,GAAG,GAAG,MAAM,CAAC;IACjB,IAAI,CAAC,GAAG,MAAM,GAAG,CAAC,CAAC;IACnB,OAAO,CAAC,IAAI,CAAC,EAAE,CAAC;QACd,IAAI,SAAS,CAAC,IAAI,CAAC,CAAC,CAAC,CAAC,EAAE,CAAC;YAAC,GAAG,GAAG,CAAC,CAAC;YAAC,CAAC,EAAE,CAAC;YAAC,SAAS;QAAC,CAAC;QACnD,IAAI,IAAI,CAAC,CAAC,CAAC,CAAC,IAAI,EAAE,KAAK,EAAE,EAAE,CAAC;YAC1B,+FAA+F;YAC/F,+FAA+F;YAC/F,8CAA8C;YAC9C,IAAI,CAAC,GAAG,CAAC,GAAG,CAAC,CAAC;YACd,OAAO,CAAC,IAAI,CAAC,IAAI,IAAI,CAAC,CAAC,CAAC,CAAC,IAAI,EAAE,KAAK,EAAE;gBAAE,CAAC,EAAE,CAAC;YAC5C,IAAI,CAAC,IAAI,CAAC,IAAI,SAAS,CAAC,IAAI,CAAC,CAAC,CAAC,CAAC,EAAE,CAAC;gBAAC,GAAG,GAAG,CAAC,CAAC;gBAAC,CAAC,GAAG,CAAC,GAAG,CAAC,CAAC;gBAAC,SAAS;YAAC,CAAC;QACrE,CAAC;QACD,MAAM,CAAC,6DAA6D;IACtE,CAAC;IACD,OAAO,IAAI,CAAC,KAAK,CAAC,CAAC,EAAE,GAAG,CAAC,CAAC;AAC5B,CAAC"}

package/packages/server/dist/services/cliModalDetect.d.ts

@@ -0,0 +1,299 @@
+/**
+ * CLI modal/usage-limit grid detectors (Epic 37 — Story 37.4)
+ *
+ * Pure readers for the permission dialog (Story 32.6), the AskUserQuestion selection
+ * modal (Story 32.8), and the subscription usage-limit notice — moved here, *input
+ * source switched from a linear ANSI-stripped buffer to the settled screen grid*
+ * produced by the headless screen model (Story 37.1). This is the final extraction
+ * surface to leave the linear path: Stories 37.2/37.3 already moved the spinner
+ * progress reader (`cliSpinnerProgress`), and once these modal/limit consumers read
+ * the grid, the linear `stripAnsiForDetect` + rolling-buffer skeleton is deleted (37.4).
+ *
+ * Why the grid matters here (the 32.8 box-chrome fix): claude paints the modal with
+ * *box-drawing borders* (┌─┐ │ └─┘) and *in-place overwrites*. A linear buffer has no
+ * 2D coordinates, so box glyphs fused into option labels ("│"-laden / "──────"-stretched
+ * rows) and same-cell redraws concatenated. The screen grid *applies* claude's cursor
+ * moves, so **each option lands on its own row** — a per-row read keeps every label
+ * intact and fusion is structurally impossible. The per-row `stripBoxChrome` still trims
+ * the left/right border cells, but rows no longer fuse, so the label body survives.
+ *
+ * Two input shapes, same settled grid:
+ *   - *Existence* detectors (`detectPermissionDialog` / `detectUsageLimit` /
+ *     `detectQuestionModal`) and the verb/sentence scrapes (`extractToolName` /
+ *     `extractPromptSentence`) run line-spanning regex → they take `readScreenText()`
+ *     (the grid joined with '\n').
+ *   - *Row-structure* parsers (`parseQuestionModal` / `parsePrecedingText`) read the
+ *     grid ROWS (`readGrid()` → string[]) directly — reading rows is the whole point of
+ *     the box-chrome fix.
+ *
+ * Pure by construction (no node-pty / no engine state), so the screen-less unit tests
+ * exercise them with hand-built grid rows — the pattern Stories 37.2/37.3 established
+ * with `readSpinnerProgress`. Still version-fragile (a TUI revision could reword the
+ * footers/phrases or change the box layout); the grid removes the *fusion / box-chrome*
+ * failure mode, not the wording fragility.
+ *
+ * @see docs/stories/37.4.story.md
+ * [Source: docs/prd/epic-37-cli-terminal-emulation.md#story-374]
+ */
+import type { PermissionMode } from '@hammoc/shared';
+/** A single scraped AskUserQuestion choice. Story 32.8 scraped one of these from a single-question
+ *  modal; ISSUE-99 reuses the same shape per-tab to reconstruct a **multi-question** (tabbed) modal,
+ *  one ParsedQuestion per tab. */
+export interface ParsedQuestion {
+    question: string;
+    header?: string;
+    multiSelect: boolean;
+    /** Each option's label plus the per-option `description` claude paints on the indented row(s)
+     *  directly below its label (실측 2026-06-17). The description is optional — a confirm-style menu
+     *  or a bare option carries none. The web card already renders `description` when present. */
+    options: Array<{
+        label: string;
+        description?: string;
+    }>;
+}
+/**
+ * Conservative permission-dialog matcher. Requires a permission-specific phrase
+ * AND the fully-rendered footer ("Esc to cancel" / "Tab to amend") so a half-drawn
+ * dialog, a spinner, or the echoed prompt can never match — a false positive would
+ * inject a stray Enter/Esc and corrupt the session. On the grid a half-drawn dialog
+ * simply has no footer row yet, so the AND-of-footer naturally withholds detection
+ * until the modal is fully painted. The dialog chrome renders in English regardless of
+ * the model's reply language (observed); a future TUI revision could change these
+ * strings (documented version-fragility).
+ */
+export declare function detectPermissionDialog(text: string): boolean;
+/**
+ * Detect the subscription **usage-limit exhaustion** notice on the screen and return its
+ * scraped sentence (else null). Why this exists: the interactive TUI prints "You've hit your
+ * weekly limit · resets 1am (Asia/Seoul)" ONLY on screen — it is NEVER written to the session
+ * JSONL — so the JSONL watch (how every other turn-completion is detected) never sees it and the
+ * turn would otherwise hang forever waiting for an `end_turn` that never comes. Detecting it lets
+ * the engine fail fast with the exact message claude showed (including the reset time).
+ *
+ * Conservative by construction so it can never stop a healthy turn:
+ *   - requires an exhaustion verb (hit/reached/exceeded) OR "<window> limit reached",
+ *   - requires an explicit window qualifier (weekly / 5-hour / daily / usage / session),
+ *   - requires a nearby "reset" clause (the real notice always has one),
+ *   - and explicitly EXCLUDES the still-usable percentage warning ("used 97% of your weekly
+ *     limit") — at 97% generation continues, so that must NOT stop the turn.
+ * The call site adds the OAuth-usage corroboration + POST-INJECTION gating (preserved in the
+ * engine dispatch). Version-fragile (a TUI revision could reword these) — the same documented
+ * constraint as the permission/question detectors, which also read screen *state*.
+ */
+export declare function detectUsageLimit(text: string): string | null;
+/**
+ * Detect the transient server-side **rate-limit** error on screen — DISTINCT from the weekly usage cap.
+ * claude prints "API Error: Server is temporarily limiting requests (not your usage limit) · Rate limited"
+ * ONLY on the PTY (never the JSONL), so without detection the turn hangs on the spinner waiting for an
+ * end_turn that never comes. Returns the scraped sentence (else null). No OAuth corroboration needed (this
+ * is an explicit error string, not the ambiguous usage-cap prose) — but require BOTH the distinctive phrase
+ * AND the "Rate limited" tag so a stray mention can't trip it. Version-fragile like the other screen-state
+ * detectors. The caller gates it POST-INJECTION (so a pre-injection repaint can't false-fire).
+ */
+export declare function detectRateLimit(text: string): string | null;
+/**
+ * Best-effort tool name from the dialog's question verb (screen scrape — low
+ * fidelity; the structured tool name is not in the JSONL until after approval).
+ */
+export declare function extractToolName(text: string): string;
+/** Best-effort human-readable prompt sentence (the dialog's own words). */
+export declare function extractPromptSentence(text: string): string;
+/**
+ * Conservative AskUserQuestion-modal matcher (Story 32.8). Requires the selection footer
+ * ("Enter to select" + "↑/↓ to navigate") AND the auto-appended "Chat about this"
+ * affordance — together unique to the question modal and absent from a permission dialog
+ * ("Do you want to…" / "Yes, allow all edits", which has no list navigation) and from
+ * ordinary output, so neither can false-trigger a stray keypress. `detectPermissionDialog`
+ * is checked first and is mutually exclusive (it needs a permission phrase this modal lacks;
+ * this needs "to navigate" the dialog lacks), so the two never cross-fire. Version-fragile
+ * (a TUI revision could reword these) — the documented constrained surface.
+ */
+export declare function detectQuestionModal(text: string): boolean;
+/**
+ * Scrape one question + its options from a SINGLE-question modal's screen ROWS (Story 32.8 — low
+ * fidelity, the documented constraint; Story 37.4 — reads the settled grid rows instead of a linear
+ * buffer).
+ *
+ * Returns null when it cannot build a usable *single*-question structure — no options, or a
+ * **multi-question** tabbed modal (more than one header ballot-box tab) which this single-round-trip
+ * reader does not drive. ISSUE-99 added a separate per-tab path (`countQuestionTabs` +
+ * `parseQuestionTabBody`) for the multi-question case; THIS function and its guard are unchanged so
+ * the single-question path stays byte-for-byte identical.
+ */
+export declare function parseQuestionModal(rows: string[]): ParsedQuestion | null;
+/**
+ * Count the question tabs (header ballot boxes ☐/☒) in a detected AskUserQuestion modal (ISSUE-99).
+ * claude renders a single question as one ballot box (`☐ Color`) and a **multi-question** modal as a
+ * tab bar with one box per question plus a Submit tab (`←  ☐ Color  ☐ Size  ✔ Submit  →`). So the
+ * count is the branch signal: 1 ⇒ the single-round-trip `parseQuestionModal` path; >1 ⇒ the tabbed
+ * multi-question driver. 0 ⇒ no header (a confirm-style menu / not a question modal). Pure — counts
+ * the ballot glyphs on the header row only (option checkboxes are `[ ]`, a distinct glyph). */
+export declare function countQuestionTabs(rows: string[]): number;
+/**
+ * The ordered question header labels from a multi-question tab bar (ISSUE-99). For
+ * `←  ☐ Color  ☐ Size  ✔ Submit  →` this returns `['Color', 'Size']` — each label is the text after
+ * a ballot box up to the next box / `✔` Submit / arrow. The Submit tab is excluded (it is not a
+ * question). The labels are positional: the i-th label is the i-th tab the driver visits in order,
+ * so the engine attaches `headers[i]` to the question it scrapes on tab i. Pure. */
+export declare function parseQuestionTabHeaders(rows: string[]): string[];
+/**
+ * Scrape ONE tab of a multi-question modal — the active question's text + multiSelect + options
+ * (ISSUE-99). The tabbed modal shows only the active question's body below the tab bar, so this is
+ * the same body scrape as the single-question path but WITHOUT the single-question guard (the tab
+ * bar legitimately carries >1 ballot box). The header label is NOT read here (it is supplied
+ * positionally by `parseQuestionTabHeaders`), so a multi-box tab bar row is harmless — it is not a
+ * numbered option and is never the last pre-option row (the question text is). Returns null when the
+ * tab has no real options (e.g. a half-painted frame). Pure. */
+export declare function parseQuestionTabBody(rows: string[]): {
+    question: string;
+    multiSelect: boolean;
+    options: Array<{
+        label: string;
+    }>;
+} | null;
+export declare function parseConfirmChoiceMenu(rows: string[]): ParsedQuestion | null;
+/**
+ * Scrape the assistant prose the TUI rendered ABOVE the question modal (the explanation that
+ * leads into the choices), else null. Why this exists (ordering fix): that prose and the
+ * AskUserQuestion are flushed to the session JSONL only AFTER the user answers (the whole
+ * assistant message lands post-selection — verified), while the question CARD is shown the moment
+ * the modal is detected on screen. So reading the prose from the file always puts it AFTER the
+ * card ("선택지 누른 뒤에 설명이 나온다"). The screen is the ONLY pre-answer source, so we scrape
+ * it and emit it first. Best-effort and lossy (collapsed to one line, may catch nothing) — the
+ * turn-end reload replaces it with the authoritative JSONL copy; the caller dedups the matching
+ * JSONL block's live re-emit.
+ *
+ * Reads the same grid rows as parseQuestionModal: it finds where the modal begins (the header
+ * ballot-box tab ☐/☒, or the row above the first numbered option) and returns the trailing
+ * contiguous block of prose rows above it (box chrome stripped, option/footer/affordance rows
+ * excluded). Returns null for a trivial fragment so a bare modal with no lead-in prose never
+ * emits scrape noise.
+ */
+export declare function parsePrecedingText(rows: string[]): string | null;
+/**
+ * Scrape the assistant prose rendered ABOVE a *permission* dialog (Story 32.6) — the sibling of
+ * `parsePrecedingText` for the permission path (Story 37.9, the same "[본문, 선택지]" ordering fix:
+ * claude writes the gated tool's whole assistant message — explanatory prose included — to the JSONL
+ * only AFTER the decision, so the screen is the only pre-decision source).
+ *
+ * The permission dialog has no "to navigate" footer; its gated tool renders as a `● Tool(…)` card
+ * with the "Create file / Do you want to… / 1. Yes / 2. … / Esc to cancel" chrome below it, and the
+ * explanatory prose sits ABOVE that tool card. So the region above the dialog footer is classified
+ * with the single-source `parseGridCards`, and the prose = the trailing contiguous run of TEXT cards
+ * immediately before the gated (last) tool card. Returns null when there is no lead-in prose.
+ * Best-effort / lossy like its sibling — the turn-end reload replaces it with the canonical block.
+ */
+export declare function parsePrecedingPermissionText(rows: string[]): string | null;
+/**
+ * Story 37.5 — permission-mode control (the *write* application of the same settled grid).
+ *
+ * CLI permission modes that map 1:1 onto claude's Shift+Tab (`CSI Z`) cycle, **in cycle order**:
+ * a normal session cycles `default → accept edits on → plan mode on → auto mode on → (wrap)
+ * default` (empirically captured, claude v2.1.162). The forward step count from current→target
+ * is `(targetIdx - curIdx + N) % N`.
+ *
+ * `auto` is claude's classifier mode ("auto mode on"), a DISTINCT mode from `acceptEdits`
+ * ("accept edits on") — they are separate `--permission-mode` values. Earlier code wrongly read
+ * "auto mode on" as `bypassPermissions`; that conflation is fixed here.
+ *
+ * Two values sit OFF this cycle, so `permissionModeCycleIndex` returns -1 and the engine routes
+ * them to the store-only / next-spawn `--permission-mode` path instead of a live closed loop:
+ *   - `bypassPermissions` — claude deliberately keeps it out of a normal session's cycle (it
+ *     surfaces in the cycle only once a session is explicitly STARTED in it). We never drive to it
+ *     live; selecting Bypass applies on the NEXT spawn via `--permission-mode bypassPermissions`.
+ *   - `dontAsk` — headless-only, never on the cycle.
+ *
+ * version-fragile: label wording / cycle order can shift across claude versions (live-verify item).
+ */
+export declare const CLI_PERMISSION_MODE_CYCLE: PermissionMode[];
+/** A session STARTED in bypass renders `bypassPermissions` INSIDE its live Shift+Tab cycle —
+ *  inserted between `plan` and `auto` (empirically captured: `bypass → auto → default → accept
+ *  edits → plan → bypass`, claude v2.1.177). So for such a session bypass IS a live-drivable
+ *  target; a session NOT started in bypass keeps it off the cycle (`CLI_PERMISSION_MODE_CYCLE`
+ *  above) and bypass stays store-only / next-spawn. */
+export declare const CLI_PERMISSION_MODE_CYCLE_WITH_BYPASS: PermissionMode[];
+/** Cycle position of a mode, or -1 when off the Shift+Tab cycle. `includeBypass` selects the
+ *  bypass-started session's cycle (where `bypassPermissions` is reachable live); the default
+ *  (false) keeps `bypassPermissions`/`dontAsk` off-cycle → next-spawn `--permission-mode` path. */
+export declare function permissionModeCycleIndex(mode: PermissionMode, includeBypass?: boolean): number;
+/**
+ * Read claude's current permission mode from the settled screen grid's status row (Story 37.5).
+ * Pure: input is the grid rows, output is the Hammoc `PermissionMode`. A row is accepted as the
+ * mode status row ONLY when it carries the `shift+tab to cycle` footer (AND-gate); among such
+ * rows the bottom-most (freshest rendered) wins, matching `readSpinnerProgress`. When NO mode
+ * status row is present the mode is `default` (normal) — but note this is a *weak* signal (it is
+ * the absence of a row), so the caller MUST read it from a `flush()`-settled grid: a half-drawn
+ * frame whose label has not painted yet would otherwise read transiently as `default`.
+ */
+export declare function readPermissionMode(grid: string[]): PermissionMode;
+/**
+ * Is the settled grid mid-GENERATION? The live footer carries claude's active-generation footer
+ * ("esc to interrupt") or a spinner token counter ("↓ N tokens"). Scanned over the LIVE FOOTER
+ * REGION only (`liveFooterText`) so scrollback prose that quotes these phrases can't poison the
+ * verdict (same discipline as `isIdleInputGrid`).
+ *
+ * Story 37.5 follow-up (owner-confirmed 2026-06-13): the mode status row renders at the very bottom
+ * of the reconstructed grid in BOTH idle and generating states (spinner above, input box + mode row
+ * below), and Shift+Tab cycles the permission mode live in either. So the permission-mode closed
+ * loop drives on this POSITIVE generation signal too — it distinguishes a real generating frame
+ * (safe to read the mode + cycle) from an UNKNOWN boot/loading screen (where blind keys stay
+ * forbidden). Version-fragile like the rest of this module.
+ */
+export declare function isGeneratingGrid(grid: string[]): boolean;
+/**
+ * Is the settled grid showing claude's idle INPUT BOX (ready to accept a keypress), as opposed to a
+ * mid-generation spinner frame? (Story 37.5 — distinguishes idle from generating; both render the
+ * mode status row, but the live Shift+Tab gate treats them separately where it needs to.)
+ *
+ * Heuristic on a settled grid (half-drawn frames are excluded upstream by `flush()`), scanned over
+ * the LIVE FOOTER REGION only (so scrollback prose that quotes these phrases can't poison it):
+ *   - a generation footer/counter (`isGeneratingGrid`) ⇒ NOT idle;
+ *   - else the input-box prompt glyph (❯) present ⇒ idle.
+ *
+ * Left as a shared named helper so Story 37.6's "pre-injection screen classification" (which draws
+ * the same input-box-vs-spinner line, and likewise treats `❯` alone as insufficient) can reuse it
+ * rather than re-deriving it. This story is self-sufficient and does NOT depend on 37.6.
+ */
+export declare function isIdleInputGrid(grid: string[]): boolean;
+/**
+ * Story 37.6 — PRE-INJECTION screen classification (the *read* sibling of 37.4's post-injection
+ * detectors). The boot/resume readiness check used to be a single linear test —
+ * `bootBuffer.includes('❯')` → inject. But `❯` is a *shared* glyph: claude paints it for the idle
+ * input box, for the highlighted row of a selection menu, AND inside the permission dialog. So the
+ * marker is *necessary but not sufficient*; a resume frame that lands on a selection menu reads `❯`
+ * and the old path injected an Enter into the first option (e.g. `/compact`), losing the prompt and
+ * compacting the conversation (실측 2026-06-11).
+ *
+ * This 3-way classifier of the SETTLED grid removes that ambiguity:
+ *   - `selection`  — a recognized selection menu/modal: the 32.6 permission dialog OR the 32.8
+ *                    question modal (both AND-gated detectors, reused verbatim), OR a generic
+ *                    numbered-option list THAT ALSO carries a live selection footer.
+ *   - `input-box`  — no selection signature AND `isIdleInputGrid` holds (an `❯` is present with no
+ *                    mid-generation spinner). This is the ONLY class that injects (AC1).
+ *   - `unknown`    — neither. The caller presses NO blind key and (at the decisive checkpoint) ends
+ *                    the turn with an explicit error ("모르면 치지 않는다", AC3).
+ *
+ * The **footer AND-gate is essential** (AC2): a resume-repaint can quote a prior turn's "❯ 1. Yes"
+ * / numbered list / table in the scrollback BODY, but the *live* nav/cancel footer renders only at
+ * the bottom of an actually-live selection box. Requiring the footer alongside the numbered rows
+ * stops quoted scrollback from being mistaken for a live menu — the same half-drawn / quoted-text
+ * defense the permission/question detectors already use.
+ *
+ * Pure by construction (grid rows in, union out) so the screen-less unit tests drive it with
+ * hand-built rows. **Settled-grid precondition:** the `input-box`/`selection` distinction partly
+ * rests on the *absence* of a row (no footer ⇒ not a live menu), a weak signal that a half-drawn
+ * frame can transiently violate, so the CALLER must classify only an `await flush()`-settled grid
+ * (37.5 weak-signal discipline). Still version-fragile (the option/footer wording can shift across
+ * claude TUI revisions) — the grid removes the *fusion* failure mode, not the wording fragility.
+ *
+ * @see docs/stories/37.6.story.md
+ * [Source: docs/prd/epic-37-cli-terminal-emulation.md#story-376]
+ */
+export type PreInjectScreen = 'input-box' | 'selection' | 'unknown';
+/**
+ * Classify a SETTLED screen grid as input box / selection menu / unknown for the pre-injection
+ * readiness gate (Story 37.6). MUST be called on a `flush()`-settled grid (see the absence-signal
+ * note above). Pure — no node-pty / no engine state.
+ */
+export declare function classifyPreInjectScreen(grid: string[]): PreInjectScreen;
+//# sourceMappingURL=cliModalDetect.d.ts.map

package/packages/server/dist/services/cliModalDetect.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"cliModalDetect.d.ts","sourceRoot":"","sources":["../../src/services/cliModalDetect.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAoCG;AAEH,OAAO,KAAK,EAAE,cAAc,EAAE,MAAM,gBAAgB,CAAC;AAIrD;;kCAEkC;AAClC,MAAM,WAAW,cAAc;IAC7B,QAAQ,EAAE,MAAM,CAAC;IACjB,MAAM,CAAC,EAAE,MAAM,CAAC;IAChB,WAAW,EAAE,OAAO,CAAC;IACrB;;kGAE8F;IAC9F,OAAO,EAAE,KAAK,CAAC;QAAE,KAAK,EAAE,MAAM,CAAC;QAAC,WAAW,CAAC,EAAE,MAAM,CAAA;KAAE,CAAC,CAAC;CACzD;AASD;;;;;;;;;GASG;AACH,wBAAgB,sBAAsB,CAAC,IAAI,EAAE,MAAM,GAAG,OAAO,CAM5D;AAED;;;;;;;;;;;;;;;;;GAiBG;AACH,wBAAgB,gBAAgB,CAAC,IAAI,EAAE,MAAM,GAAG,MAAM,GAAG,IAAI,CAQ5D;AAED;;;;;;;;GAQG;AACH,wBAAgB,eAAe,CAAC,IAAI,EAAE,MAAM,GAAG,MAAM,GAAG,IAAI,CAK3D;AAED;;;GAGG;AACH,wBAAgB,eAAe,CAAC,IAAI,EAAE,MAAM,GAAG,MAAM,CASpD;AAED,2EAA2E;AAC3E,wBAAgB,qBAAqB,CAAC,IAAI,EAAE,MAAM,GAAG,MAAM,CAE1D;AAED;;;;;;;;;GASG;AACH,wBAAgB,mBAAmB,CAAC,IAAI,EAAE,MAAM,GAAG,OAAO,CAGzD;AA2FD;;;;;;;;;;GAUG;AACH,wBAAgB,kBAAkB,CAAC,IAAI,EAAE,MAAM,EAAE,GAAG,cAAc,GAAG,IAAI,CAaxE;AAED;;;;;;+FAM+F;AAC/F,wBAAgB,iBAAiB,CAAC,IAAI,EAAE,MAAM,EAAE,GAAG,MAAM,CAIxD;AAED;;;;;oFAKoF;AACpF,wBAAgB,uBAAuB,CAAC,IAAI,EAAE,MAAM,EAAE,GAAG,MAAM,EAAE,CAYhE;AAED;;;;;;;gEAOgE;AAChE,wBAAgB,oBAAoB,CAAC,IAAI,EAAE,MAAM,EAAE,GAAG;IAAE,QAAQ,EAAE,MAAM,CAAC;IAAC,WAAW,EAAE,OAAO,CAAC;IAAC,OAAO,EAAE,KAAK,CAAC;QAAE,KAAK,EAAE,MAAM,CAAA;KAAE,CAAC,CAAA;CAAE,GAAG,IAAI,CAIzI;AAYD,wBAAgB,sBAAsB,CAAC,IAAI,EAAE,MAAM,EAAE,GAAG,cAAc,GAAG,IAAI,CAsC5E;AAED;;;;;;;;;;;;;;;;GAgBG;AACH,wBAAgB,kBAAkB,CAAC,IAAI,EAAE,MAAM,EAAE,GAAG,MAAM,GAAG,IAAI,CAkBhE;AAED;;;;;;;;;;;;GAYG;AACH,wBAAgB,4BAA4B,CAAC,IAAI,EAAE,MAAM,EAAE,GAAG,MAAM,GAAG,IAAI,CAsB1E;AAED;;;;;;;;;;;;;;;;;;;;GAoBG;AACH,eAAO,MAAM,yBAAyB,EAAE,cAAc,EAA+C,CAAC;AAEtG;;;;uDAIuD;AACvD,eAAO,MAAM,qCAAqC,EAAE,cAAc,EAAoE,CAAC;AAEvI;;mGAEmG;AACnG,wBAAgB,wBAAwB,CAAC,IAAI,EAAE,cAAc,EAAE,aAAa,UAAQ,GAAG,MAAM,CAE5F;AAmBD;;;;;;;;GAQG;AACH,wBAAgB,kBAAkB,CAAC,IAAI,EAAE,MAAM,EAAE,GAAG,cAAc,CAcjE;AAED;;;;;;;;;;;;GAYG;AACH,wBAAgB,gBAAgB,CAAC,IAAI,EAAE,MAAM,EAAE,GAAG,OAAO,CAOxD;AAED;;;;;;;;;;;;;GAaG;AACH,wBAAgB,eAAe,CAAC,IAAI,EAAE,MAAM,EAAE,GAAG,OAAO,CAGvD;AAED;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAiCG;AACH,MAAM,MAAM,eAAe,GAAG,WAAW,GAAG,WAAW,GAAG,SAAS,CAAC;AAQpE;;;;GAIG;AACH,wBAAgB,uBAAuB,CAAC,IAAI,EAAE,MAAM,EAAE,GAAG,eAAe,CAsBvE"}