commandmate 0.26.0 → 0.27.0

package/dist/server/src/lib/detection/tools/codex/detect.js

@@ -0,0 +1,343 @@
+"use strict";
+/**
+ * Codex CLI's status detector (Issue #1927, 方針書 §4 D2).
+ *
+ * A verbatim lift of the `cliToolId === 'codex'` blocks (priorities 0.7, 0.75,
+ * 0.8, the #1160 staleness guard and 2.7) out of `detectSessionStatus`.
+ *
+ * codex declares NO `readIdleEvidence`. That is the tool-by-tool rollout of
+ * §4 D1 決定 1 (DR2-002), not an oversight: its idle row is the bare `›`
+ * composer, and telling an empty composer from one holding residual text needs
+ * the two SGR attributes `composer-text.ts` reads, which the ANSI-stripped frame
+ * this chain runs on no longer carries. Until that rule is measured and
+ * fixtured, codex's `input_prompt` keeps the pre-#1927 reading — which the chain
+ * expresses by answering `'positive'` for a tool with no rule.
+ */
+Object.defineProperty(exports, "__esModule", { value: true });
+exports.codexStatusDetector = exports.VERIFIED_AGAINST = void 0;
+exports.isCodexStalePrompt = isCodexStalePrompt;
+const cli_patterns_1 = require("../../cli-patterns");
+const prompt_detector_1 = require("../../prompt-detector");
+const status_reason_1 = require("../../status-reason");
+const prompt_1 = require("./prompt");
+const frame_1 = require("../frame");
+const run_detection_1 = require("../run-detection");
+const verified_against_1 = require("../verified-against");
+const thinking_constants_1 = require("../../../../config/thinking-constants");
+/** codex-cli build these rules were read off (#1628 / #1829 / #1890; value in ../verified-against, #1929). */
+exports.VERIFIED_AGAINST = verified_against_1.CODEX_VERIFIED_AGAINST;
+/**
+ * Issue #1160: anchors for the BOTTOM edge of a Codex approval / numbered-choice
+ * prompt. Used only by isCodexStalePrompt() to distinguish an ACTIVE prompt (the
+ * bottom-most interactive element → waiting) from an already-ANSWERED one lingering
+ * in scrollback with Codex processing below it (→ fall through to running detection).
+ * Detection-wide Codex patterns live in cli-patterns.ts; these stay local to the guard.
+ *
+ * CODEX_CONFIRMATION_FOOTER_PATTERN matches the "press number/enter to confirm" footer
+ * that closes a numbered prompt. CODEX_NUMBERED_OPTION_PATTERN matches an option line
+ * ("1. Yes", optionally prefixed by a ❯/›/● selection indicator). Neither pattern uses
+ * /g (keeps .test() stateless) nor nested quantifiers (ReDoS-safe).
+ */
+const CODEX_CONFIRMATION_FOOTER_PATTERN = /press\s+(?:number|enter)\s+to\s+confirm/i;
+const CODEX_NUMBERED_OPTION_PATTERN = /^\s*[❯›●]?\s*\d{1,2}[.)]\s/;
+/** Index of the Codex status bar within the last 10 content rows, or -1. */
+function findCodexFooterBoundary(contentLines) {
+    for (let ci = contentLines.length - 1; ci >= Math.max(0, contentLines.length - 10); ci--) {
+        if (cli_patterns_1.CODEX_STATUS_BAR_PATTERN.test(contentLines[ci]))
+            return ci;
+    }
+    return -1;
+}
+/**
+ * Exclusive end of the conversation area — the row below the status bar, with
+ * the padding above it walked off (Issue #1928).
+ *
+ * The same boundary branches 0.8 and 2.7 compute inline, named once so
+ * `detectDialog` reads the region THEY read. Falls back to the whole frame when
+ * the bar cannot be located, which is Issue #1150's drift case: there the tail
+ * is the conversation, so the dialog rule still has the right rows.
+ */
+function findCodexContentEnd(contentLines) {
+    const boundary = findCodexFooterBoundary(contentLines);
+    let end = boundary >= 0 ? boundary - 1 : contentLines.length - 1;
+    while (end >= 0 && contentLines[end].trim() === '')
+        end--;
+    return end + 1;
+}
+/**
+ * Issue #1160: decide whether a Codex prompt that detectPrompt() matched is a stale,
+ * already-answered prompt left in the 50-line scan window rather than an active one.
+ *
+ * Codex keeps the answered "1. Yes / 2. No" block + "press number to confirm" footer in
+ * its transcript (it draws on the normal screen, so tmux retains a scrollback for it —
+ * TMUX_HISTORY_LIMIT lines deep) instead of repainting it away like Claude,
+ * so detectPrompt() keeps matching it and the chain reports `waiting` even
+ * after the user answered and Codex resumed — the sidebar status dot then stays orange
+ * forever (the reported bug).
+ *
+ * Position-based guard (mirrors isCodexPromptReady()'s bottom-most-element idea): the
+ * prompt is stale when a Codex thinking indicator (• Working / • Ran / …) sits strictly
+ * BELOW the bottom-most prompt anchor (footer or numbered option) within the content
+ * above the status bar. An UNANSWERED prompt has no running indicator below its block,
+ * so this returns false and the caller keeps reporting `waiting` (Auto-Yes unaffected).
+ *
+ * The bare "›" input-line case ("answered, then › below") is already handled upstream by
+ * detectPrompt()'s user-input barrier (prompt-detect-multiple-choice.ts), which returns
+ * isPrompt=false before this guard runs, so only the thinking-indicator signal is needed
+ * here — keeping the guard conservative against flipping a genuine prompt to running.
+ */
+function isCodexStalePrompt(contentLines) {
+    const footerBoundary = findCodexFooterBoundary(contentLines);
+    const end = footerBoundary >= 0 ? footerBoundary : contentLines.length;
+    let lastPromptIdx = -1;
+    let lastThinkingIdx = -1;
+    for (let i = 0; i < end; i++) {
+        const line = contentLines[i];
+        const trimmed = line.trim();
+        if (trimmed === '') {
+            continue;
+        }
+        if (CODEX_CONFIRMATION_FOOTER_PATTERN.test(trimmed) ||
+            CODEX_NUMBERED_OPTION_PATTERN.test(trimmed)) {
+            lastPromptIdx = i;
+        }
+        // detectThinking('codex', …) requires the "•" activity prefix, so option text that
+        // merely contains a word like "Running" cannot be mistaken for a running indicator.
+        if ((0, cli_patterns_1.detectThinking)('codex', line)) {
+            lastThinkingIdx = i;
+        }
+    }
+    return lastPromptIdx >= 0 && lastThinkingIdx > lastPromptIdx;
+}
+/**
+ * Issue #1628: decide whether a Codex frame that matched CODEX_SELECTION_LIST_PATTERN
+ * is the agent ASKING FOR APPROVAL rather than the user browsing a menu.
+ *
+ * Why this exists: Codex renders both with a "Press enter to confirm" footer, so the
+ * selection-list branch (added for `/model` in Issue #622) also swallowed every approval
+ * request and returned `hasActivePrompt: false`. `isPromptWaiting` is the only
+ * blocked-on-a-human signal the current-output payload carries, so `commandmate wait
+ * --on-prompt agent` could never raise exit 10 for a Codex worker sitting on
+ * "Would you like to run the following command?" — it polled until the timeout while the
+ * agent was stopped. Auto-Yes was unaffected because it calls detectPrompt() directly,
+ * which parses these frames correctly; only the status-detector layer lost them.
+ *
+ * Two OR'd signals, both measured against live codex-cli 0.146.0 captures
+ * (5 approval frames from one real session + 2 `/model` picker frames):
+ *   1. an interrogative question line directly above the options
+ *   2. the approval escape verb ("esc to cancel" vs a menu's "esc to go back")
+ * Either alone covers every measured approval frame, so a rewording of one does not
+ * reopen the bug.
+ *
+ * Gated on `promptDetection.isPrompt` so a frame detectPrompt() could not parse into
+ * options (e.g. the unnumbered "Select a model" list of Issue #619) can never be
+ * promoted to an active prompt.
+ */
+function isCodexApprovalRequest(promptDetection, selectionWindow) {
+    if (!promptDetection.isPrompt)
+        return false;
+    const question = promptDetection.promptData?.question?.trim() ?? '';
+    return question.endsWith('?') || cli_patterns_1.CODEX_APPROVAL_FOOTER_PATTERN.test(selectionWindow);
+}
+exports.codexStatusDetector = (0, run_detection_1.createToolStatusDetector)({
+    tool: 'codex',
+    verifiedAgainst: exports.VERIFIED_AGAINST,
+    beforePrompt(frame) {
+        const { contentLines } = frame;
+        // 0.7. Codex: pager / edit-previous (transcript) mode detection (Issue #1017)
+        // Codex's transcript pager renders scroll / edit key-hint footers, e.g.:
+        //   "↑/↓ to scroll   pgup/pgdn to page   home/end to jump"
+        //   "q to quit   esc/← to edit prev   → to edit next   enter to edit message"
+        // together with a scroll-percentage separator ("─ N% ─") in place of the usual
+        // "model · N% left · path" status bar. So neither CODEX_SELECTION_LIST_PATTERN
+        // (footer is "enter to edit message", not "press enter to confirm/select") nor the
+        // status-bar boundary logic below fires, leaving the read-only TerminalDisplay
+        // with no way to scroll or escape. Detect the pager footer directly — independent of
+        // the "N% left ·" status bar — and surface it as a selection list so NavigationButtons
+        // render (isSelectionListActive via SELECTION_LIST_REASONS). Checked ahead of
+        // detectPrompt/thinking because the pager has no active y/n prompt and its transcript
+        // content must not be misread as one. CODEX_PAGER_FOOTER_PATTERN does not match the
+        // genuine "/model" selection footer, so the 0.8 path below is unaffected (no regression).
+        if (cli_patterns_1.CODEX_PAGER_FOOTER_PATTERN.test(frame.lastLines)) {
+            return {
+                status: 'waiting',
+                confidence: 'high',
+                reason: status_reason_1.STATUS_REASON.CODEX_PAGER,
+                hasActivePrompt: false,
+                evidence: 'positive',
+                promptDetection: (0, prompt_detector_1.detectPrompt)((0, cli_patterns_1.stripBoxDrawing)(frame.clean), (0, cli_patterns_1.buildDetectPromptOptions)('codex')),
+            };
+        }
+        // 0.75. Codex: the hooks review screens (Issue #1829)
+        // codex-cli 0.148.0 answers "1. Review hooks" with a two-screen review UI:
+        //   screen 2 "Press t to trust all; enter to review hooks; esc to close"
+        //   screen 3 "Press t to trust; esc to go back"
+        // Neither carries a numbered option, a "press enter to confirm" footer, or any
+        // thinking indicator, so every branch below falls through to the `running`
+        // default -- which is how two live sessions sat parked on screen 3 while the UI
+        // and `cmate wait` both reported them as busy. They are the bottom-most
+        // interactive element and nothing but a keypress moves them: that is `waiting`.
+        // Checked ahead of prompt detection because the transcript rows on screen 2 are
+        // ordinary text that must not be read as options.
+        const codexLifecycleDialog = (0, cli_patterns_1.getCodexLifecycleDialog)(frame.clean);
+        if (codexLifecycleDialog === 'hooks-list' || codexLifecycleDialog === 'hooks-detail') {
+            return {
+                status: 'waiting',
+                confidence: 'high',
+                reason: status_reason_1.STATUS_REASON.CODEX_HOOKS_REVIEW,
+                hasActivePrompt: false,
+                evidence: 'positive',
+                promptDetection: (0, prompt_detector_1.detectPrompt)((0, cli_patterns_1.stripBoxDrawing)(frame.clean), (0, cli_patterns_1.buildDetectPromptOptions)('codex')),
+            };
+        }
+        // 0.8. Codex: selection list detection BEFORE prompt detection (Issue #622)
+        // CODEX_SELECTION_LIST_PATTERN matches "press enter to confirm/select" footer.
+        // Without this early check, detectPrompt() would detect the numbered
+        // options (e.g., "› 1. gpt-5.4") as a multiple_choice prompt, preventing
+        // NavigationButtons from being shown. This mirrors the Copilot pattern.
+        //
+        // The pattern is scoped to the content window immediately above the Codex status
+        // bar (mirroring branch 2.7's boundary detection). Matching against the full content
+        // would allow stale "Press enter to confirm" text from already-answered approval
+        // prompts high in scrollback to falsely trigger NavigationButtons.
+        //
+        // Issue #1150: the status bar is located via CODEX_STATUS_BAR_PATTERN (version-
+        // independent; matches both legacy "N% left ·" and v0.141 "model · path" bars).
+        const codexFooterBoundary = findCodexFooterBoundary(contentLines);
+        let codexContentEnd = codexFooterBoundary >= 0 ? codexFooterBoundary - 1 : contentLines.length - 1;
+        while (codexContentEnd >= 0 && contentLines[codexContentEnd].trim() === '') {
+            codexContentEnd--;
+        }
+        if (codexContentEnd >= 0) {
+            const codexSelectionWindow = contentLines
+                .slice(Math.max(0, codexContentEnd - frame_1.STATUS_CHECK_LINE_COUNT + 1), codexContentEnd + 1)
+                .join('\n');
+            if (cli_patterns_1.CODEX_SELECTION_LIST_PATTERN.test(codexSelectionWindow)) {
+                const codexPromptDetection = (0, prompt_detector_1.detectPrompt)((0, cli_patterns_1.stripBoxDrawing)(frame.clean), (0, cli_patterns_1.buildDetectPromptOptions)('codex'));
+                // Issue #1628: an approval request wears the same footer as a menu but is the
+                // agent blocked on the human, so it must surface as an active prompt (exit 10
+                // for `wait`, PromptPanel in the UI) instead of a navigable list. The #1160
+                // staleness guard still applies: an ALREADY-ANSWERED approval whose footer is
+                // still inside the window, with Codex running below it, is dead scrollback.
+                if (isCodexApprovalRequest(codexPromptDetection, codexSelectionWindow) &&
+                    !isCodexStalePrompt(contentLines)) {
+                    return {
+                        status: 'waiting',
+                        confidence: 'high',
+                        reason: status_reason_1.STATUS_REASON.PROMPT_DETECTED,
+                        hasActivePrompt: true,
+                        evidence: 'positive',
+                        promptDetection: codexPromptDetection,
+                    };
+                }
+                return {
+                    status: 'waiting',
+                    confidence: 'high',
+                    reason: status_reason_1.STATUS_REASON.CODEX_SELECTION_LIST,
+                    hasActivePrompt: false,
+                    evidence: 'positive',
+                    promptDetection: codexPromptDetection,
+                };
+            }
+        }
+        return null;
+    },
+    isStalePrompt(frame) {
+        return isCodexStalePrompt(frame.contentLines);
+    },
+    // §4 D1 決定 4 (Issue #1928). All three inputs are readings this module
+    // already performs for its status branches, passed rather than recomputed:
+    // the content boundary (0.8 / 2.7), the #1160 staleness guard and the #1829
+    // lifecycle screens. `prompt.ts` therefore needs no import from this file.
+    detectDialog(frame) {
+        return (0, prompt_1.detectCodexDialog)(frame, {
+            contentEnd: findCodexContentEnd(frame.contentLines),
+            stalePrompt: isCodexStalePrompt(frame.contentLines),
+            lifecycleDialog: (0, cli_patterns_1.getCodexLifecycleDialog)(frame.clean),
+        });
+    },
+    afterThinking(frame) {
+        const { contentLines } = frame;
+        // 2.7. Codex TUI content area detection (thinking + idle prompt)
+        // Codex TUI layout: conversation area (top) | empty padding (~30 lines) | input area + status bar (bottom).
+        // Standard windowed checks (last 5/15 lines) only see padding/status bar, missing both:
+        // A. Thinking indicators (• Ran, • Planning) in the conversation area → should show spinner
+        // B. Idle prompt (›) at the end of the conversation area → should show ready
+        // Strategy: find the Codex status bar, extract content above it, then check for thinking/idle.
+        const codexFooterBoundary = findCodexFooterBoundary(contentLines);
+        if (codexFooterBoundary >= 0) {
+            // Find last non-empty content line above footer (skip padding + input area)
+            let lastContentIdx = codexFooterBoundary - 1;
+            while (lastContentIdx >= 0 && contentLines[lastContentIdx].trim() === '') {
+                lastContentIdx--;
+            }
+            if (lastContentIdx >= 0) {
+                // A. Check content area for thinking indicators (wider window than the shared step)
+                const codexThinkingWindow = contentLines
+                    .slice(Math.max(0, lastContentIdx - thinking_constants_1.THINKING_TAIL_LINE_COUNT + 1), lastContentIdx + 1)
+                    .join('\n');
+                if ((0, cli_patterns_1.detectThinking)('codex', codexThinkingWindow)) {
+                    return {
+                        status: 'running',
+                        confidence: 'high',
+                        reason: status_reason_1.STATUS_REASON.THINKING_INDICATOR,
+                        hasActivePrompt: false,
+                        evidence: 'positive',
+                    };
+                }
+                // B. Check if the last content line is the idle › prompt.
+                // The last non-empty line above the status bar is the current active line.
+                // When Codex is idle, this is the › prompt (with optional suggestion text).
+                // When processing, this is command output (not ›), so the check naturally fails.
+                //
+                // The evidence stays `positive` here: codex has no measured idle rule yet
+                // (see the module docstring), so DR2-002 keeps its pre-#1927 reading.
+                if (cli_patterns_1.CODEX_PROMPT_PATTERN.test(contentLines[lastContentIdx].trim())) {
+                    return {
+                        status: 'ready',
+                        confidence: 'high',
+                        reason: status_reason_1.STATUS_REASON.INPUT_PROMPT,
+                        hasActivePrompt: false,
+                        evidence: 'positive',
+                    };
+                }
+                // C. Fallback: status bar present but neither thinking nor idle › detected.
+                // This means Codex is actively processing — command output has pushed the
+                // • Ran/• Working indicators beyond the 5-line thinking window.
+                // The status bar ("model · N% left · path") is always visible during Codex
+                // sessions, and the only idle state (›) was checked in B above.
+                return {
+                    status: 'running',
+                    confidence: 'high',
+                    reason: status_reason_1.STATUS_REASON.THINKING_INDICATOR,
+                    hasActivePrompt: false,
+                    evidence: 'positive',
+                };
+            }
+        }
+        else {
+            // D. Status-bar-independent running detection (Issue #1150, mitigation B).
+            // Defense-in-depth for the next Codex CLI status-bar format drift: if the bar
+            // can't be located (the exact failure that broke Issue #1150), fall back to the
+            // Codex thinking indicator in the wider 15-line footer window — mirroring
+            // Claude's interrupt-hint net. Gated so idle frames are unaffected:
+            // only fires when the tail is NOT the idle › prompt, so an idle session still
+            // falls through to the generic composer check.
+            let codexTailIdx = contentLines.length - 1;
+            while (codexTailIdx >= 0 && contentLines[codexTailIdx].trim() === '') {
+                codexTailIdx--;
+            }
+            const codexTailIsIdlePrompt = codexTailIdx >= 0 && cli_patterns_1.CODEX_PROMPT_PATTERN.test(contentLines[codexTailIdx].trim());
+            if (!codexTailIsIdlePrompt && (0, cli_patterns_1.detectThinking)('codex', frame.lastLines)) {
+                return {
+                    status: 'running',
+                    confidence: 'high',
+                    reason: status_reason_1.STATUS_REASON.THINKING_INDICATOR,
+                    hasActivePrompt: false,
+                    evidence: 'positive',
+                };
+            }
+        }
+        return null;
+    },
+});

package/dist/server/src/lib/detection/tools/codex/prompt.js

@@ -0,0 +1,104 @@
+"use strict";
+/**
+ * Codex CLI's positive dialog detection (Issue #1928, 方針書 §4 D1 決定 4).
+ *
+ * ## What was measured (codex-cli 0.148.0 / 0.146.0, 200x1000 pane)
+ *
+ * Codex draws every numbered dialog the same way — a `›` cursor on the
+ * highlighted option and a `Press enter to confirm …` footer — and encodes the
+ * DIFFERENCE between "the agent is asking you for permission" and "you opened a
+ * menu" in the escape verb of that footer
+ * (`tests/unit/lib/detection/fixtures/codex-live-1628/`):
+ *
+ * | frame                       | footer                                     | family     |
+ * |-----------------------------|--------------------------------------------|------------|
+ * | `approval-run-command.txt`  | `Press enter to confirm or esc to cancel`  | permission |
+ * | `approval-apply-patch.txt`  | `Press enter to confirm or esc to cancel`  | permission |
+ * | `model-picker-step1.txt`    | `Press enter to confirm or esc to go back` | picker     |
+ * | `model-picker-step2.txt`    | `Press enter to confirm or esc to go back` | picker     |
+ *
+ * That is the same pair of anchors Issue #1628 measured for `detect.ts`'s
+ * selection-list branch, and they are deliberately the same anchors here: two
+ * readings of "is this codex's dialog?" would be two chances to disagree, and
+ * this one is the one Auto-Yes acts on.
+ *
+ * ## Why the footer and not the numbers
+ *
+ * Codex draws on the NORMAL screen, so its pane keeps scrollback: an approval
+ * the operator answered five minutes ago is still on the frame, options and
+ * footer intact. That is Issue #1160, and the guard for it already exists —
+ * `isCodexStalePrompt` — so this module takes its verdict rather than inventing
+ * a second one. Without it a `detectDialog` that only looked at the rows would
+ * vouch for a dead prompt and Auto-Yes would answer it again.
+ */
+Object.defineProperty(exports, "__esModule", { value: true });
+exports.detectCodexDialog = detectCodexDialog;
+const cli_patterns_1 = require("../../cli-patterns");
+const dialog_block_1 = require("../dialog-block");
+/**
+ * The dialog family each lifecycle screen belongs to (Issue #1829).
+ *
+ * They are dialogs by any reading — the pane is blocked on a keypress — so this
+ * module reports them. Auto-Yes never reaches the report: `detectAndRespondToPrompt`
+ * suppresses a lifecycle screen with `agent-launch-dialog` BEFORE consulting the
+ * gate, because answering one is `CodexTool.waitForReady()`'s job and its
+ * answers differ from the defaults. Naming them anyway keeps `respond` and the
+ * UI able to say what is on screen.
+ */
+const LIFECYCLE_DIALOG_KINDS = {
+    'hooks-review': 'permission',
+    'hooks-list': 'picker',
+    'hooks-detail': 'picker',
+    update: 'update',
+    trust: 'trust',
+};
+/** How many non-blank rows above the options may hold the question. */
+const QUESTION_SCAN_ROWS = 4;
+function readContextAbove(lines, firstRow) {
+    const rows = [];
+    for (let i = firstRow - 1; i >= 0 && rows.length < QUESTION_SCAN_ROWS; i--) {
+        const row = lines[i].trim();
+        if (row === '')
+            continue;
+        rows.push(row);
+    }
+    return rows.join('\n');
+}
+/**
+ * Does this frame carry a Codex dialog?
+ *
+ * @param frame - The normalised capture
+ * @param context - What `detect.ts` measured; see {@link CodexDialogContext}
+ */
+function detectCodexDialog(frame, context) {
+    const lines = (0, cli_patterns_1.stripBoxDrawing)(frame.clean).split('\n');
+    const block = (0, dialog_block_1.findNumberedOptionBlock)(lines, context.contentEnd);
+    if (context.lifecycleDialog) {
+        return {
+            kind: LIFECYCLE_DIALOG_KINDS[context.lifecycleDialog],
+            options: block?.options ?? [],
+            answerMode: 'numbered',
+        };
+    }
+    if (!block)
+        return null;
+    // The footer is the whole guard. It is positional as well as textual: only the
+    // rows between the options and the status bar are looked at, so the same words
+    // quoted inside a transcript hundreds of rows up cannot reach it.
+    if (!cli_patterns_1.CODEX_SELECTION_LIST_PATTERN.test(block.footer))
+        return null;
+    // Issue #1160: an already-answered block still inside the window is not a
+    // dialog. Codex keeps it on screen and goes on working underneath it.
+    if (context.stalePrompt)
+        return null;
+    const question = readContextAbove(lines, block.firstRow);
+    const isApproval = cli_patterns_1.CODEX_APPROVAL_FOOTER_PATTERN.test(block.footer) || question.split('\n')[0]?.endsWith('?');
+    return {
+        kind: isApproval ? 'permission' : 'picker',
+        options: block.options,
+        // Measured: codex takes the digit as text. `sendPromptAnswer` types it for
+        // this tool, and the hooks-review screens confirm the digit lands
+        // immediately (reference: codex 0.148 review flow).
+        answerMode: 'numbered',
+    };
+}

package/dist/server/src/lib/detection/tools/copilot/detect.js

@@ -0,0 +1,185 @@
+"use strict";
+/**
+ * GitHub Copilot CLI's status detector (Issue #1927, 方針書 §4 D2).
+ *
+ * Every branch here is a verbatim lift of the `cliToolId === 'copilot'` blocks
+ * that were interleaved with six other tools' branches inside
+ * `detectSessionStatus`. Nothing about the reading changed — copilot's rules
+ * were already the §4 D1 shape after #1885 and #1895, which is why it is one of
+ * the three tools shipping with `enforce` (see `detection-evidence-config.ts`).
+ */
+Object.defineProperty(exports, "__esModule", { value: true });
+exports.copilotStatusDetector = exports.VERIFIED_AGAINST = void 0;
+exports.readIdleEvidence = readIdleEvidence;
+const cli_patterns_1 = require("../../cli-patterns");
+const prompt_detector_1 = require("../../prompt-detector");
+const status_reason_1 = require("../../status-reason");
+const prompt_1 = require("./prompt");
+const run_detection_1 = require("../run-detection");
+const verified_against_1 = require("../verified-against");
+/** copilot-cli build these rules were read off (#1885 / #1895; value in ../verified-against, #1929). */
+exports.VERIFIED_AGAINST = verified_against_1.COPILOT_VERIFIED_AGAINST;
+/**
+ * §4 D1 決定 1: copilot's idle evidence is the bottom row of the pane.
+ *
+ * Recorded here for completeness rather than for effect: branch 2.9 below
+ * already refuses to publish `ready` unless `readCopilotStatusBar` says `idle`,
+ * and copilot opts out of the generic composer check, so no `ready` verdict can
+ * reach the chain's evidence gate without this having been true. Stating it
+ * anyway keeps the tool table honest — `detection-evidence-config.ts` says
+ * copilot has a measured rule, and this is the rule.
+ *
+ * Do NOT widen this to a window. `status-vocabulary-in-response.txt` is a live
+ * frame in which copilot printed ` ● Working esc interrupt` as body text; a
+ * window match would pin a finished session to `running` forever.
+ */
+function readIdleEvidence(frame) {
+    return (0, cli_patterns_1.readCopilotStatusBar)(frame.contentLines) === 'idle' ? 'positive' : 'none';
+}
+exports.copilotStatusDetector = (0, run_detection_1.createToolStatusDetector)({
+    tool: 'copilot',
+    verifiedAgainst: exports.VERIFIED_AGAINST,
+    beforePrompt(frame) {
+        // 0. Copilot: picker detection BEFORE thinking detection
+        // COPILOT_THINKING_PATTERN includes "Reasoning\s+[■▪▮]" which matches the
+        // "Reasoning ■■■ medium" UI element shown in /model selection lists.
+        // Without this early check, the selection list would be misdetected as thinking.
+        // However, yes/no prompts also contain "to navigate · enter to select" footer,
+        // so we must check detectPrompt first — if a prompt is detected, it takes priority
+        // over selection list (prompts show PromptPanel with Yes/No buttons). That branch
+        // is not hypothetical on 1.0.80: `/permissions` is a picker whose body is a
+        // two-option numbered list, and it is the one of the eleven that belongs on
+        // PromptPanel rather than on NavigationButtons.
+        //
+        // Issue #1895 replaced what this reads. The 30-row window it used to match
+        // `COPILOT_SELECTION_LIST_PATTERN` against was wrong in both directions at once:
+        // it matched none of 1.0.80's eleven pickers (so `/model` fell through to the
+        // `running`/`default` floor with no NavigationButtons and `wait` sat on it until
+        // the operator closed the picker), and it matched copilot's own prose whenever a
+        // reply mentioned "Select Model" or "Search models..." (so a finished turn was
+        // published as `waiting`). `isCopilotSelectionFrame` is positional instead: a
+        // picker is what copilot draws INSTEAD of its bottom chrome, so the evidence is
+        // the bottom row of the pane -- the same row the status-bar branches read -- and
+        // never the transcript. Ordering against them is therefore settled inside the
+        // helper: it declines any frame that still has a status bar.
+        if ((0, cli_patterns_1.isCopilotSelectionFrame)(frame.contentLines)) {
+            const promptOptions = (0, cli_patterns_1.buildDetectPromptOptions)('copilot');
+            const promptDetection = (0, prompt_detector_1.detectPrompt)((0, cli_patterns_1.stripBoxDrawing)(frame.clean), promptOptions);
+            if (promptDetection.isPrompt) {
+                // Distinguish yes/no prompts (2-3 options, e.g., "Do you want to run this command?")
+                // from ask_user multi-select prompts (4+ options). Yes/no prompts should show
+                // PromptPanel with buttons; ask_user prompts need NavigationButtons for ↑↓ selection.
+                const optionsCount = promptDetection.promptData?.options?.length ?? 0;
+                if (optionsCount <= 3) {
+                    return {
+                        status: 'waiting',
+                        confidence: 'high',
+                        reason: status_reason_1.STATUS_REASON.PROMPT_DETECTED,
+                        hasActivePrompt: true,
+                        evidence: 'positive',
+                        promptDetection,
+                    };
+                }
+                // 4+ options: treat as selection list (NavigationButtons)
+            }
+            return {
+                status: 'waiting',
+                confidence: 'high',
+                reason: status_reason_1.STATUS_REASON.COPILOT_SELECTION_LIST,
+                hasActivePrompt: false,
+                evidence: 'positive',
+                promptDetection,
+            };
+        }
+        // 0.5. Copilot: the bottom status bar carries the running half of the turn
+        // (Issue #547 put a thinking check here; Issue #1885 replaced what it reads).
+        //
+        // Copilot keeps the "❯" composer drawn between its two full-width rules even
+        // while it generates, so prompt detection matches every frame and the running
+        // state has to be resolved before it -- that part is unchanged since #547.
+        // What changed is the evidence. `COPILOT_THINKING_PATTERN` was written for
+        // copilot's pre-1.0.79 vocabulary and matches NOTHING that 1.0.80 draws
+        // (measured: 0 of 44 live generating frames), which is how every frame of a
+        // generating session reached the composer check and was published as
+        // `ready`/`input_prompt` -- the sidebar showed no glow and `wait` reported the
+        // running agent as Completed on its first poll.
+        //
+        // 1.0.80 puts the state in the bottom row of the pane: " ◉ Working · 1.5 KiB
+        // esc interrupt" while the turn runs, key hints when it does not. Reading that
+        // ROW rather than a 15-line window is what makes this safe to keep ahead of
+        // `detectPrompt`: a dialog takes the row away entirely (its box occupies the
+        // bottom of the pane), so a frame with a permission prompt on it cannot reach
+        // this branch and still lands on `waiting` at the shared prompt step. The
+        // window form would also have matched copilot's own response text -- see
+        // `status-vocabulary-in-response.txt`.
+        if ((0, cli_patterns_1.readCopilotStatusBar)(frame.contentLines) === 'working') {
+            const promptOptions = (0, cli_patterns_1.buildDetectPromptOptions)('copilot');
+            const promptDetection = (0, prompt_detector_1.detectPrompt)((0, cli_patterns_1.stripBoxDrawing)(frame.clean), promptOptions);
+            return {
+                status: 'running',
+                confidence: 'high',
+                reason: status_reason_1.STATUS_REASON.THINKING_INDICATOR,
+                hasActivePrompt: false,
+                evidence: 'positive',
+                promptDetection,
+            };
+        }
+        return null;
+    },
+    afterThinking(frame) {
+        // 2.9. Copilot: the idle status bar is the completion evidence (Issue #1885)
+        //
+        // The other rendering of the row branch 0.5 read. Copilot has no completion
+        // marker of its own -- no `▣ Build · model · duration` -- and its composer is
+        // drawn throughout a turn, so this bar is the only thing on the screen that
+        // changes when the turn ends. Seeing the key hints is therefore an affirmative
+        // observation that copilot is not working, which is what design rule D1
+        // (`docs/design/multi-agent-state-architecture.md` §4 D1 decision 1, item 2)
+        // requires before `ready` may be published; the old route to `ready` here was
+        // the generic composer check matching an always-visible `❯`, which is the
+        // "absence of a busy marker" inference D1 forbids and Issue #1885 reported.
+        //
+        // Placed after prompt detection, unlike its running counterpart: a `waiting`
+        // verdict must never be overtaken by an idle bar, even though no measured
+        // 1.0.80 frame draws a dialog and the status bar at once.
+        //
+        // The wire value stays `ready`/`input_prompt` (DR3-002) -- this is the same
+        // verdict claude's `❯` row and codex's `›` row publish, so nothing downstream
+        // has to learn a new reason code.
+        if ((0, cli_patterns_1.readCopilotStatusBar)(frame.contentLines) === 'idle') {
+            return {
+                status: 'ready',
+                confidence: 'high',
+                reason: status_reason_1.STATUS_REASON.INPUT_PROMPT,
+                hasActivePrompt: false,
+                evidence: 'positive',
+            };
+        }
+        return null;
+    },
+    // Issue #1885: copilot opts out of the generic composer check. Its `❯` row is
+    // drawn during generation as well as after it, so that check answered `ready`
+    // for every frame of a running turn -- the reported bug. Leaving it in would
+    // also make branch 2.9 unobservable: every frame the status bar declined to
+    // vouch for would be re-admitted with the same verdict, and the anchor would
+    // stop being load-bearing.
+    skipGenericInputPrompt: true,
+    readIdleEvidence,
+    // §4 D1 決定 4 (Issue #1928). Both inputs are the SAME two readings the status
+    // branches above use, passed rather than recomputed: the bottom row is
+    // copilot's only positional evidence, and a second reading of it would be a
+    // second chance to disagree about whether a dialog is on screen.
+    detectDialog(frame) {
+        return (0, prompt_1.detectCopilotDialog)(frame, {
+            statusBar: (0, cli_patterns_1.readCopilotStatusBar)(frame.contentLines),
+            selectionFrame: (0, cli_patterns_1.isCopilotSelectionFrame)(frame.contentLines),
+            contentEnd: frame.contentLines.length,
+        });
+    },
+    // With the generic check off, this module's own rules are the ONLY rules that
+    // run for copilot. A frame that reaches the floor is one they could not read
+    // -- a `/model` picker this build draws differently, an unrecognised overlay --
+    // and saying so names something an operator can act on (capture it as a
+    // fixture) where `default` would only say "nothing matched".
+    unreadableReason: status_reason_1.STATUS_REASON.UNKNOWN_FRAME,
+});