commandmate 0.44.1 → 0.44.3

package/dist/server/src/lib/detection/cli-patterns.js

@@ -4,1638 +4,156 @@
  * Shared between response-poller.ts and API routes
  */
 Object.defineProperty(exports, "__esModule", { value: true });
-exports.findOpencodeV2DialogTitle = exports.OPENCODE_V2_DIALOG_TITLE_PATTERN = exports.OPENCODE_V2_THINKING_PATTERN = exports.OPENCODE_V2_FOOTER_PATTERN = exports.OPENCODE_V2_IDLE_COMPOSER_PATTERN = exports.OPENCODE_SKIP_PATTERNS = exports.OPENCODE_SEPARATOR_PATTERN = exports.CLAUDE_SELECTION_LIST_FOOTER = exports.CLAUDE_MODEL_OVERLAY_FOOTER_PATTERN = exports.OPENCODE_SELECTION_LIST_PATTERN = exports.OPENCODE_FOOTER_STATUS_PATTERN = exports.OPENCODE_USER_ECHO_PATTERN = exports.OPENCODE_GUTTER_ROW_PATTERN = exports.OPENCODE_COMPOSER_BOTTOM_BORDER = exports.OPENCODE_PROCESSING_INDICATOR = exports.OPENCODE_PERMISSION_PATTERN = exports.OPENCODE_TURN_COMPLETE_PATTERN = exports.OPENCODE_RESPONSE_COMPLETE = exports.OPENCODE_LOADING_PATTERN = exports.OPENCODE_THINKING_PATTERN = exports.OPENCODE_PROMPT_AFTER_RESPONSE = exports.OPENCODE_IDLE_COMPOSER_PATTERN = exports.OPENCODE_PROMPT_PATTERN = exports.GEMINI_THINKING_PATTERN = exports.GEMINI_PROMPT_PATTERN = exports.MAX_PASTED_TEXT_RETRIES = exports.PASTED_TEXT_DETECT_DELAY = exports.PASTED_TEXT_PATTERN = exports.CODEX_USER_ECHO_PATTERN = exports.CODEX_TRAILED_STATUS_BAR_PATTERN = exports.CODEX_STATUS_BAR_PATTERN = exports.CODEX_PAGER_FOOTER_PATTERN = exports.CODEX_EFFORT_PICKER_FOOTER_PATTERN = exports.CODEX_PICKER_FOOTER_PATTERN = exports.CODEX_FORM_SUBMIT_FOOTER_PATTERN = exports.CODEX_APPROVAL_FOOTER_PATTERN = exports.CODEX_SELECTION_LIST_PATTERN = exports.CODEX_SEPARATOR_PATTERN = exports.CODEX_HOOKS_REVIEW_ANCHORS = exports.CODEX_DIALOG_PATTERN = exports.CODEX_TRUST_QUESTION_PATTERN = exports.CODEX_PROMPT_PATTERN = exports.CLAUDE_TRUST_DIALOG_PATTERN = exports.CLAUDE_SEPARATOR_PATTERN = exports.CLAUDE_PROMPT_PATTERN = exports.CODEX_INTERRUPT_HINT_PATTERN = exports.CODEX_THINKING_PATTERN = exports.CLAUDE_INTERRUPT_HINT_PATTERN = exports.CLAUDE_THINKING_PATTERN = exports.CLAUDE_SPINNER_CHARS = void 0;
-exports.CLAUDE_SESSION_ERROR_REGEX_PATTERNS = exports.CLAUDE_SESSION_ERROR_PATTERNS = exports.extractAnsiSequences = exports.stripAnsi = exports.COMMAND_CODE_SKIP_PATTERNS = exports.COMMAND_CODE_HOOK_NOTICE_PATTERN = exports.COMMAND_CODE_BANNER_PATTERNS = exports.COMMAND_CODE_MODE_INDICATOR_PATTERN = exports.COMMAND_CODE_COMPLETION_PATTERN = exports.COMMAND_CODE_RESPONSE_MARKER_PATTERN = exports.COMMAND_CODE_THINKING_PATTERN = exports.COMMAND_CODE_INTERRUPT_HINT_PATTERN = exports.COMMAND_CODE_SEPARATOR_PATTERN = exports.COMMAND_CODE_PROMPT_PATTERN = exports.COMMAND_CODE_SPINNER_CHARS = exports.ANTIGRAVITY_SKIP_PATTERNS = exports.ANTIGRAVITY_SURVEY_PATTERN = exports.ANTIGRAVITY_DIALOG_MAX_ROWS = exports.ANTIGRAVITY_DIALOG_BOUNDARY_PATTERN = exports.ANTIGRAVITY_SWITCH_MODEL_HEADER_PATTERN = exports.ANTIGRAVITY_NUMBERED_OPTION_PATTERN = exports.ANTIGRAVITY_NAVIGATE_FOOTER_PATTERN = exports.ANTIGRAVITY_SELECTION_LIST_PATTERN = exports.ANTIGRAVITY_SEPARATOR_PATTERN = exports.ANTIGRAVITY_THINKING_PATTERN = exports.ANTIGRAVITY_PROMPT_PATTERN = exports.ANTIGRAVITY_COMPOSER_MODE_BANNER_PATTERN = exports.ANTIGRAVITY_COMPOSER_MODE_BANNER_SOURCE = exports.VIBE_LOCAL_THINKING_PATTERN = exports.VIBE_LOCAL_PROMPT_PATTERN = exports.COPILOT_SKIP_PATTERNS = exports.COPILOT_FOLDER_TRUST_ANSWER_KEY = exports.COPILOT_FOLDER_TRUST_SESSION_OPTION_PATTERN = exports.COPILOT_FOLDER_TRUST_ANCHORS = exports.COPILOT_SELECTION_FOOTER_PATTERN = exports.COPILOT_BOOT_BANNER_ANCHORS = exports.COPILOT_TRANSCRIPT_CONTINUATION_PATTERN = exports.COPILOT_TOOL_ROW_PATTERN = exports.COPILOT_TOOL_VERBS = exports.COPILOT_TRANSCRIPT_DIVIDER_PATTERN = exports.COPILOT_USER_ECHO_PATTERN = exports.COPILOT_REASONING_HEADER_PATTERN = exports.COPILOT_BOX_ROW_PATTERN = exports.COPILOT_SEPARATOR_PATTERN = exports.COPILOT_IDLE_STATUS_PATTERN = exports.COPILOT_WORKING_STATUS_PATTERN = exports.COPILOT_THINKING_PATTERN = exports.COPILOT_PROMPT_PATTERN = exports.OPENCODE_V2_SKIP_PATTERNS = void 0;
-exports.isCodexTurnActive = isCodexTurnActive;
-exports.findClaudeChromeStart = findClaudeChromeStart;
-exports.resolveClaudeTrustDialogKeys = resolveClaudeTrustDialogKeys;
-exports.isClaudeTrustDialogOpen = isClaudeTrustDialogOpen;
-exports.isShellPaneCommand = isShellPaneCommand;
-exports.isCodexPromptReady = isCodexPromptReady;
-exports.getCodexActiveDialog = getCodexActiveDialog;
-exports.getCodexLifecycleDialog = getCodexLifecycleDialog;
-exports.findCodexChromeStart = findCodexChromeStart;
-exports.findCodexUserEchoIndex = findCodexUserEchoIndex;
-exports.findOpenCodeChromeStart = findOpenCodeChromeStart;
-exports.findOpenCodeUserEchoEnd = findOpenCodeUserEchoEnd;
-exports.findOpenCodeComposerRows = findOpenCodeComposerRows;
-exports.stripOpenCodeGutter = stripOpenCodeGutter;
-exports.isOpencodeV2ComposerVisible = isOpencodeV2ComposerVisible;
-exports.readCopilotStatusBar = readCopilotStatusBar;
-exports.findCopilotChromeStart = findCopilotChromeStart;
-exports.isCopilotSelectionFrame = isCopilotSelectionFrame;
-exports.isCopilotFolderTrustDialog = isCopilotFolderTrustDialog;
-exports.locateAntigravityDialogRegion = locateAntigravityDialogRegion;
-exports.isAntigravityNumberedDialog = isAntigravityNumberedDialog;
-exports.findCommandCodeChromeStart = findCommandCodeChromeStart;
+exports.CLAUDE_SPINNER_CHARS = exports.OPENCODE_V2_SKIP_PATTERNS = exports.isOpencodeV2ComposerVisible = exports.OPENCODE_V2_THINKING_PATTERN = exports.OPENCODE_V2_FOOTER_PATTERN = exports.OPENCODE_V2_IDLE_COMPOSER_PATTERN = exports.OPENCODE_SKIP_PATTERNS = exports.OPENCODE_SEPARATOR_PATTERN = exports.OPENCODE_SELECTION_LIST_PATTERN = exports.stripOpenCodeGutter = exports.findOpenCodeComposerRows = exports.findOpenCodeUserEchoEnd = exports.findOpenCodeChromeStart = exports.OPENCODE_FOOTER_STATUS_PATTERN = exports.OPENCODE_USER_ECHO_PATTERN = exports.OPENCODE_GUTTER_ROW_PATTERN = exports.OPENCODE_COMPOSER_BOTTOM_BORDER = exports.OPENCODE_PROCESSING_INDICATOR = exports.OPENCODE_PERMISSION_PATTERN = exports.OPENCODE_TURN_COMPLETE_PATTERN = exports.OPENCODE_RESPONSE_COMPLETE = exports.OPENCODE_LOADING_PATTERN = exports.OPENCODE_THINKING_PATTERN = exports.OPENCODE_PROMPT_AFTER_RESPONSE = exports.OPENCODE_IDLE_COMPOSER_PATTERN = exports.OPENCODE_PROMPT_PATTERN = exports.findCodexUserEchoIndex = exports.CODEX_USER_ECHO_PATTERN = exports.findCodexChromeStart = exports.CODEX_TRAILED_STATUS_BAR_PATTERN = exports.CODEX_STATUS_BAR_PATTERN = exports.CODEX_PAGER_FOOTER_PATTERN = exports.CODEX_EFFORT_PICKER_FOOTER_PATTERN = exports.CODEX_PICKER_FOOTER_PATTERN = exports.CODEX_FORM_SUBMIT_FOOTER_PATTERN = exports.CODEX_APPROVAL_FOOTER_PATTERN = exports.CODEX_SELECTION_LIST_PATTERN = exports.CODEX_SEPARATOR_PATTERN = exports.getCodexLifecycleDialog = exports.CODEX_HOOKS_REVIEW_ANCHORS = exports.getCodexActiveDialog = exports.findCodexComposerRow = exports.isCodexPromptReady = exports.CODEX_GENUINE_PROMPT_LINE = exports.CODEX_DIALOG_PATTERN = exports.CODEX_TRUST_QUESTION_PATTERN = exports.CODEX_PROMPT_PATTERN = exports.isCodexTurnActive = exports.CODEX_INTERRUPT_HINT_PATTERN = exports.CODEX_THINKING_PATTERN = void 0;
+exports.ANTIGRAVITY_SURVEY_PATTERN = exports.ANTIGRAVITY_DIALOG_MAX_ROWS = exports.ANTIGRAVITY_DIALOG_BOUNDARY_PATTERN = exports.ANTIGRAVITY_SWITCH_MODEL_HEADER_PATTERN = exports.ANTIGRAVITY_NUMBERED_OPTION_PATTERN = exports.ANTIGRAVITY_NAVIGATE_FOOTER_PATTERN = exports.ANTIGRAVITY_SELECTION_LIST_PATTERN = exports.ANTIGRAVITY_SEPARATOR_PATTERN = exports.ANTIGRAVITY_THINKING_PATTERN = exports.ANTIGRAVITY_PROMPT_PATTERN = exports.ANTIGRAVITY_COMPOSER_MODE_BANNER_PATTERN = exports.ANTIGRAVITY_COMPOSER_MODE_BANNER_SOURCE = exports.COPILOT_SKIP_PATTERNS = exports.isCopilotFolderTrustDialog = exports.COPILOT_FOLDER_TRUST_ANSWER_KEY = exports.COPILOT_FOLDER_TRUST_SESSION_OPTION_PATTERN = exports.COPILOT_FOLDER_TRUST_ANCHORS = exports.isCopilotSelectionFrame = exports.COPILOT_SELECTION_FOOTER_PATTERN = exports.COPILOT_BOOT_BANNER_ANCHORS = exports.COPILOT_TRANSCRIPT_CONTINUATION_PATTERN = exports.COPILOT_TOOL_ROW_PATTERN = exports.COPILOT_TOOL_VERBS = exports.COPILOT_TRANSCRIPT_DIVIDER_PATTERN = exports.COPILOT_USER_ECHO_PATTERN = exports.COPILOT_REASONING_HEADER_PATTERN = exports.COPILOT_BOX_ROW_PATTERN = exports.findCopilotChromeStart = exports.COPILOT_SEPARATOR_PATTERN = exports.readCopilotStatusBar = exports.COPILOT_IDLE_STATUS_PATTERN = exports.COPILOT_WORKING_STATUS_PATTERN = exports.COPILOT_THINKING_PATTERN = exports.COPILOT_PROMPT_PATTERN = exports.VIBE_LOCAL_THINKING_PATTERN = exports.VIBE_LOCAL_PROMPT_PATTERN = exports.GEMINI_THINKING_PATTERN = exports.GEMINI_PROMPT_PATTERN = exports.CLAUDE_SESSION_ERROR_REGEX_PATTERNS = exports.CLAUDE_SESSION_ERROR_PATTERNS = exports.CLAUDE_SELECTION_LIST_FOOTER = exports.CLAUDE_MODEL_OVERLAY_FOOTER_PATTERN = exports.isClaudeTrustDialogOpen = exports.resolveClaudeTrustDialogKeys = exports.CLAUDE_TRUST_DIALOG_PATTERN = exports.findClaudeChromeStart = exports.CLAUDE_SEPARATOR_PATTERN = exports.CLAUDE_PROMPT_PATTERN = exports.CLAUDE_INTERRUPT_HINT_PATTERN = exports.CLAUDE_THINKING_PATTERN = void 0;
+exports.stripBoxDrawing = exports.extractAnsiSequences = exports.stripAnsi = exports.findOpencodeV2DialogTitle = exports.OPENCODE_V2_DIALOG_TITLE_PATTERN = exports.MAX_PASTED_TEXT_RETRIES = exports.PASTED_TEXT_DETECT_DELAY = exports.PASTED_TEXT_PATTERN = exports.isShellPaneCommand = exports.COMMAND_CODE_SKIP_PATTERNS = exports.findCommandCodeChromeStart = exports.COMMAND_CODE_HOOK_NOTICE_PATTERN = exports.COMMAND_CODE_BANNER_PATTERNS = exports.COMMAND_CODE_MODE_INDICATOR_PATTERN = exports.COMMAND_CODE_COMPLETION_PATTERN = exports.COMMAND_CODE_RESPONSE_MARKER_PATTERN = exports.COMMAND_CODE_THINKING_PATTERN = exports.COMMAND_CODE_INTERRUPT_HINT_PATTERN = exports.COMMAND_CODE_SEPARATOR_PATTERN = exports.COMMAND_CODE_PROMPT_PATTERN = exports.COMMAND_CODE_SPINNER_CHARS = exports.ANTIGRAVITY_SKIP_PATTERNS = exports.isAntigravityNumberedDialog = exports.locateAntigravityDialogRegion = void 0;
 exports.detectThinking = detectThinking;
 exports.getCliToolPatterns = getCliToolPatterns;
-exports.stripBoxDrawing = stripBoxDrawing;
 exports.buildDetectPromptOptions = buildDetectPromptOptions;
+exports.usesFullFramePrompt = usesFullFramePrompt;
 const logger_1 = require("../../lib/logger");
-const ansi_1 = require("./ansi");
-const composer_text_1 = require("./composer-text");
-const cli_patterns_1 = require("./tools/codex/cli-patterns");
-const thinking_constants_1 = require("../../config/thinking-constants");
+const shell_pane_command_1 = require("./shared/shell-pane-command");
+Object.defineProperty(exports, "isShellPaneCommand", { enumerable: true, get: function () { return shell_pane_command_1.isShellPaneCommand; } });
+const pasted_text_1 = require("./shared/pasted-text");
+Object.defineProperty(exports, "PASTED_TEXT_PATTERN", { enumerable: true, get: function () { return pasted_text_1.PASTED_TEXT_PATTERN; } });
+Object.defineProperty(exports, "PASTED_TEXT_DETECT_DELAY", { enumerable: true, get: function () { return pasted_text_1.PASTED_TEXT_DETECT_DELAY; } });
+Object.defineProperty(exports, "MAX_PASTED_TEXT_RETRIES", { enumerable: true, get: function () { return pasted_text_1.MAX_PASTED_TEXT_RETRIES; } });
+const strip_box_drawing_1 = require("./shared/strip-box-drawing");
+Object.defineProperty(exports, "stripBoxDrawing", { enumerable: true, get: function () { return strip_box_drawing_1.stripBoxDrawing; } });
+const patterns_1 = require("./tools/codex/patterns");
+var patterns_2 = require("./tools/codex/patterns");
+Object.defineProperty(exports, "CODEX_THINKING_PATTERN", { enumerable: true, get: function () { return patterns_2.CODEX_THINKING_PATTERN; } });
+Object.defineProperty(exports, "CODEX_INTERRUPT_HINT_PATTERN", { enumerable: true, get: function () { return patterns_2.CODEX_INTERRUPT_HINT_PATTERN; } });
+Object.defineProperty(exports, "isCodexTurnActive", { enumerable: true, get: function () { return patterns_2.isCodexTurnActive; } });
+Object.defineProperty(exports, "CODEX_PROMPT_PATTERN", { enumerable: true, get: function () { return patterns_2.CODEX_PROMPT_PATTERN; } });
+Object.defineProperty(exports, "CODEX_TRUST_QUESTION_PATTERN", { enumerable: true, get: function () { return patterns_2.CODEX_TRUST_QUESTION_PATTERN; } });
+Object.defineProperty(exports, "CODEX_DIALOG_PATTERN", { enumerable: true, get: function () { return patterns_2.CODEX_DIALOG_PATTERN; } });
+Object.defineProperty(exports, "CODEX_GENUINE_PROMPT_LINE", { enumerable: true, get: function () { return patterns_2.CODEX_GENUINE_PROMPT_LINE; } });
+Object.defineProperty(exports, "isCodexPromptReady", { enumerable: true, get: function () { return patterns_2.isCodexPromptReady; } });
+Object.defineProperty(exports, "findCodexComposerRow", { enumerable: true, get: function () { return patterns_2.findCodexComposerRow; } });
+Object.defineProperty(exports, "getCodexActiveDialog", { enumerable: true, get: function () { return patterns_2.getCodexActiveDialog; } });
+Object.defineProperty(exports, "CODEX_HOOKS_REVIEW_ANCHORS", { enumerable: true, get: function () { return patterns_2.CODEX_HOOKS_REVIEW_ANCHORS; } });
+Object.defineProperty(exports, "getCodexLifecycleDialog", { enumerable: true, get: function () { return patterns_2.getCodexLifecycleDialog; } });
+Object.defineProperty(exports, "CODEX_SEPARATOR_PATTERN", { enumerable: true, get: function () { return patterns_2.CODEX_SEPARATOR_PATTERN; } });
+Object.defineProperty(exports, "CODEX_SELECTION_LIST_PATTERN", { enumerable: true, get: function () { return patterns_2.CODEX_SELECTION_LIST_PATTERN; } });
+Object.defineProperty(exports, "CODEX_APPROVAL_FOOTER_PATTERN", { enumerable: true, get: function () { return patterns_2.CODEX_APPROVAL_FOOTER_PATTERN; } });
+Object.defineProperty(exports, "CODEX_FORM_SUBMIT_FOOTER_PATTERN", { enumerable: true, get: function () { return patterns_2.CODEX_FORM_SUBMIT_FOOTER_PATTERN; } });
+Object.defineProperty(exports, "CODEX_PICKER_FOOTER_PATTERN", { enumerable: true, get: function () { return patterns_2.CODEX_PICKER_FOOTER_PATTERN; } });
+Object.defineProperty(exports, "CODEX_EFFORT_PICKER_FOOTER_PATTERN", { enumerable: true, get: function () { return patterns_2.CODEX_EFFORT_PICKER_FOOTER_PATTERN; } });
+Object.defineProperty(exports, "CODEX_PAGER_FOOTER_PATTERN", { enumerable: true, get: function () { return patterns_2.CODEX_PAGER_FOOTER_PATTERN; } });
+Object.defineProperty(exports, "CODEX_STATUS_BAR_PATTERN", { enumerable: true, get: function () { return patterns_2.CODEX_STATUS_BAR_PATTERN; } });
+Object.defineProperty(exports, "CODEX_TRAILED_STATUS_BAR_PATTERN", { enumerable: true, get: function () { return patterns_2.CODEX_TRAILED_STATUS_BAR_PATTERN; } });
+Object.defineProperty(exports, "findCodexChromeStart", { enumerable: true, get: function () { return patterns_2.findCodexChromeStart; } });
+Object.defineProperty(exports, "CODEX_USER_ECHO_PATTERN", { enumerable: true, get: function () { return patterns_2.CODEX_USER_ECHO_PATTERN; } });
+Object.defineProperty(exports, "findCodexUserEchoIndex", { enumerable: true, get: function () { return patterns_2.findCodexUserEchoIndex; } });
+const patterns_3 = require("./tools/opencode/patterns");
+var patterns_4 = require("./tools/opencode/patterns");
+Object.defineProperty(exports, "OPENCODE_PROMPT_PATTERN", { enumerable: true, get: function () { return patterns_4.OPENCODE_PROMPT_PATTERN; } });
+Object.defineProperty(exports, "OPENCODE_IDLE_COMPOSER_PATTERN", { enumerable: true, get: function () { return patterns_4.OPENCODE_IDLE_COMPOSER_PATTERN; } });
+Object.defineProperty(exports, "OPENCODE_PROMPT_AFTER_RESPONSE", { enumerable: true, get: function () { return patterns_4.OPENCODE_PROMPT_AFTER_RESPONSE; } });
+Object.defineProperty(exports, "OPENCODE_THINKING_PATTERN", { enumerable: true, get: function () { return patterns_4.OPENCODE_THINKING_PATTERN; } });
+Object.defineProperty(exports, "OPENCODE_LOADING_PATTERN", { enumerable: true, get: function () { return patterns_4.OPENCODE_LOADING_PATTERN; } });
+Object.defineProperty(exports, "OPENCODE_RESPONSE_COMPLETE", { enumerable: true, get: function () { return patterns_4.OPENCODE_RESPONSE_COMPLETE; } });
+Object.defineProperty(exports, "OPENCODE_TURN_COMPLETE_PATTERN", { enumerable: true, get: function () { return patterns_4.OPENCODE_TURN_COMPLETE_PATTERN; } });
+Object.defineProperty(exports, "OPENCODE_PERMISSION_PATTERN", { enumerable: true, get: function () { return patterns_4.OPENCODE_PERMISSION_PATTERN; } });
+Object.defineProperty(exports, "OPENCODE_PROCESSING_INDICATOR", { enumerable: true, get: function () { return patterns_4.OPENCODE_PROCESSING_INDICATOR; } });
+Object.defineProperty(exports, "OPENCODE_COMPOSER_BOTTOM_BORDER", { enumerable: true, get: function () { return patterns_4.OPENCODE_COMPOSER_BOTTOM_BORDER; } });
+Object.defineProperty(exports, "OPENCODE_GUTTER_ROW_PATTERN", { enumerable: true, get: function () { return patterns_4.OPENCODE_GUTTER_ROW_PATTERN; } });
+Object.defineProperty(exports, "OPENCODE_USER_ECHO_PATTERN", { enumerable: true, get: function () { return patterns_4.OPENCODE_USER_ECHO_PATTERN; } });
+Object.defineProperty(exports, "OPENCODE_FOOTER_STATUS_PATTERN", { enumerable: true, get: function () { return patterns_4.OPENCODE_FOOTER_STATUS_PATTERN; } });
+Object.defineProperty(exports, "findOpenCodeChromeStart", { enumerable: true, get: function () { return patterns_4.findOpenCodeChromeStart; } });
+Object.defineProperty(exports, "findOpenCodeUserEchoEnd", { enumerable: true, get: function () { return patterns_4.findOpenCodeUserEchoEnd; } });
+Object.defineProperty(exports, "findOpenCodeComposerRows", { enumerable: true, get: function () { return patterns_4.findOpenCodeComposerRows; } });
+Object.defineProperty(exports, "stripOpenCodeGutter", { enumerable: true, get: function () { return patterns_4.stripOpenCodeGutter; } });
+Object.defineProperty(exports, "OPENCODE_SELECTION_LIST_PATTERN", { enumerable: true, get: function () { return patterns_4.OPENCODE_SELECTION_LIST_PATTERN; } });
+Object.defineProperty(exports, "OPENCODE_SEPARATOR_PATTERN", { enumerable: true, get: function () { return patterns_4.OPENCODE_SEPARATOR_PATTERN; } });
+Object.defineProperty(exports, "OPENCODE_SKIP_PATTERNS", { enumerable: true, get: function () { return patterns_4.OPENCODE_SKIP_PATTERNS; } });
+const patterns_5 = require("./tools/opencode-v2/patterns");
+var patterns_6 = require("./tools/opencode-v2/patterns");
+Object.defineProperty(exports, "OPENCODE_V2_IDLE_COMPOSER_PATTERN", { enumerable: true, get: function () { return patterns_6.OPENCODE_V2_IDLE_COMPOSER_PATTERN; } });
+Object.defineProperty(exports, "OPENCODE_V2_FOOTER_PATTERN", { enumerable: true, get: function () { return patterns_6.OPENCODE_V2_FOOTER_PATTERN; } });
+Object.defineProperty(exports, "OPENCODE_V2_THINKING_PATTERN", { enumerable: true, get: function () { return patterns_6.OPENCODE_V2_THINKING_PATTERN; } });
+Object.defineProperty(exports, "isOpencodeV2ComposerVisible", { enumerable: true, get: function () { return patterns_6.isOpencodeV2ComposerVisible; } });
+Object.defineProperty(exports, "OPENCODE_V2_SKIP_PATTERNS", { enumerable: true, get: function () { return patterns_6.OPENCODE_V2_SKIP_PATTERNS; } });
+const patterns_7 = require("./tools/claude/patterns");
+var patterns_8 = require("./tools/claude/patterns");
+Object.defineProperty(exports, "CLAUDE_SPINNER_CHARS", { enumerable: true, get: function () { return patterns_8.CLAUDE_SPINNER_CHARS; } });
+Object.defineProperty(exports, "CLAUDE_THINKING_PATTERN", { enumerable: true, get: function () { return patterns_8.CLAUDE_THINKING_PATTERN; } });
+Object.defineProperty(exports, "CLAUDE_INTERRUPT_HINT_PATTERN", { enumerable: true, get: function () { return patterns_8.CLAUDE_INTERRUPT_HINT_PATTERN; } });
+Object.defineProperty(exports, "CLAUDE_PROMPT_PATTERN", { enumerable: true, get: function () { return patterns_8.CLAUDE_PROMPT_PATTERN; } });
+Object.defineProperty(exports, "CLAUDE_SEPARATOR_PATTERN", { enumerable: true, get: function () { return patterns_8.CLAUDE_SEPARATOR_PATTERN; } });
+Object.defineProperty(exports, "findClaudeChromeStart", { enumerable: true, get: function () { return patterns_8.findClaudeChromeStart; } });
+Object.defineProperty(exports, "CLAUDE_TRUST_DIALOG_PATTERN", { enumerable: true, get: function () { return patterns_8.CLAUDE_TRUST_DIALOG_PATTERN; } });
+Object.defineProperty(exports, "resolveClaudeTrustDialogKeys", { enumerable: true, get: function () { return patterns_8.resolveClaudeTrustDialogKeys; } });
+Object.defineProperty(exports, "isClaudeTrustDialogOpen", { enumerable: true, get: function () { return patterns_8.isClaudeTrustDialogOpen; } });
+Object.defineProperty(exports, "CLAUDE_MODEL_OVERLAY_FOOTER_PATTERN", { enumerable: true, get: function () { return patterns_8.CLAUDE_MODEL_OVERLAY_FOOTER_PATTERN; } });
+Object.defineProperty(exports, "CLAUDE_SELECTION_LIST_FOOTER", { enumerable: true, get: function () { return patterns_8.CLAUDE_SELECTION_LIST_FOOTER; } });
+Object.defineProperty(exports, "CLAUDE_SESSION_ERROR_PATTERNS", { enumerable: true, get: function () { return patterns_8.CLAUDE_SESSION_ERROR_PATTERNS; } });
+Object.defineProperty(exports, "CLAUDE_SESSION_ERROR_REGEX_PATTERNS", { enumerable: true, get: function () { return patterns_8.CLAUDE_SESSION_ERROR_REGEX_PATTERNS; } });
+const patterns_9 = require("./tools/gemini/patterns");
+var patterns_10 = require("./tools/gemini/patterns");
+Object.defineProperty(exports, "GEMINI_PROMPT_PATTERN", { enumerable: true, get: function () { return patterns_10.GEMINI_PROMPT_PATTERN; } });
+Object.defineProperty(exports, "GEMINI_THINKING_PATTERN", { enumerable: true, get: function () { return patterns_10.GEMINI_THINKING_PATTERN; } });
+const patterns_11 = require("./tools/vibe-local/patterns");
+var patterns_12 = require("./tools/vibe-local/patterns");
+Object.defineProperty(exports, "VIBE_LOCAL_PROMPT_PATTERN", { enumerable: true, get: function () { return patterns_12.VIBE_LOCAL_PROMPT_PATTERN; } });
+Object.defineProperty(exports, "VIBE_LOCAL_THINKING_PATTERN", { enumerable: true, get: function () { return patterns_12.VIBE_LOCAL_THINKING_PATTERN; } });
+const patterns_13 = require("./tools/copilot/patterns");
+var patterns_14 = require("./tools/copilot/patterns");
+Object.defineProperty(exports, "COPILOT_PROMPT_PATTERN", { enumerable: true, get: function () { return patterns_14.COPILOT_PROMPT_PATTERN; } });
+Object.defineProperty(exports, "COPILOT_THINKING_PATTERN", { enumerable: true, get: function () { return patterns_14.COPILOT_THINKING_PATTERN; } });
+Object.defineProperty(exports, "COPILOT_WORKING_STATUS_PATTERN", { enumerable: true, get: function () { return patterns_14.COPILOT_WORKING_STATUS_PATTERN; } });
+Object.defineProperty(exports, "COPILOT_IDLE_STATUS_PATTERN", { enumerable: true, get: function () { return patterns_14.COPILOT_IDLE_STATUS_PATTERN; } });
+Object.defineProperty(exports, "readCopilotStatusBar", { enumerable: true, get: function () { return patterns_14.readCopilotStatusBar; } });
+Object.defineProperty(exports, "COPILOT_SEPARATOR_PATTERN", { enumerable: true, get: function () { return patterns_14.COPILOT_SEPARATOR_PATTERN; } });
+Object.defineProperty(exports, "findCopilotChromeStart", { enumerable: true, get: function () { return patterns_14.findCopilotChromeStart; } });
+Object.defineProperty(exports, "COPILOT_BOX_ROW_PATTERN", { enumerable: true, get: function () { return patterns_14.COPILOT_BOX_ROW_PATTERN; } });
+Object.defineProperty(exports, "COPILOT_REASONING_HEADER_PATTERN", { enumerable: true, get: function () { return patterns_14.COPILOT_REASONING_HEADER_PATTERN; } });
+Object.defineProperty(exports, "COPILOT_USER_ECHO_PATTERN", { enumerable: true, get: function () { return patterns_14.COPILOT_USER_ECHO_PATTERN; } });
+Object.defineProperty(exports, "COPILOT_TRANSCRIPT_DIVIDER_PATTERN", { enumerable: true, get: function () { return patterns_14.COPILOT_TRANSCRIPT_DIVIDER_PATTERN; } });
+Object.defineProperty(exports, "COPILOT_TOOL_VERBS", { enumerable: true, get: function () { return patterns_14.COPILOT_TOOL_VERBS; } });
+Object.defineProperty(exports, "COPILOT_TOOL_ROW_PATTERN", { enumerable: true, get: function () { return patterns_14.COPILOT_TOOL_ROW_PATTERN; } });
+Object.defineProperty(exports, "COPILOT_TRANSCRIPT_CONTINUATION_PATTERN", { enumerable: true, get: function () { return patterns_14.COPILOT_TRANSCRIPT_CONTINUATION_PATTERN; } });
+Object.defineProperty(exports, "COPILOT_BOOT_BANNER_ANCHORS", { enumerable: true, get: function () { return patterns_14.COPILOT_BOOT_BANNER_ANCHORS; } });
+Object.defineProperty(exports, "COPILOT_SELECTION_FOOTER_PATTERN", { enumerable: true, get: function () { return patterns_14.COPILOT_SELECTION_FOOTER_PATTERN; } });
+Object.defineProperty(exports, "isCopilotSelectionFrame", { enumerable: true, get: function () { return patterns_14.isCopilotSelectionFrame; } });
+Object.defineProperty(exports, "COPILOT_FOLDER_TRUST_ANCHORS", { enumerable: true, get: function () { return patterns_14.COPILOT_FOLDER_TRUST_ANCHORS; } });
+Object.defineProperty(exports, "COPILOT_FOLDER_TRUST_SESSION_OPTION_PATTERN", { enumerable: true, get: function () { return patterns_14.COPILOT_FOLDER_TRUST_SESSION_OPTION_PATTERN; } });
+Object.defineProperty(exports, "COPILOT_FOLDER_TRUST_ANSWER_KEY", { enumerable: true, get: function () { return patterns_14.COPILOT_FOLDER_TRUST_ANSWER_KEY; } });
+Object.defineProperty(exports, "isCopilotFolderTrustDialog", { enumerable: true, get: function () { return patterns_14.isCopilotFolderTrustDialog; } });
+Object.defineProperty(exports, "COPILOT_SKIP_PATTERNS", { enumerable: true, get: function () { return patterns_14.COPILOT_SKIP_PATTERNS; } });
+const patterns_15 = require("./tools/antigravity/patterns");
+var patterns_16 = require("./tools/antigravity/patterns");
+Object.defineProperty(exports, "ANTIGRAVITY_COMPOSER_MODE_BANNER_SOURCE", { enumerable: true, get: function () { return patterns_16.ANTIGRAVITY_COMPOSER_MODE_BANNER_SOURCE; } });
+Object.defineProperty(exports, "ANTIGRAVITY_COMPOSER_MODE_BANNER_PATTERN", { enumerable: true, get: function () { return patterns_16.ANTIGRAVITY_COMPOSER_MODE_BANNER_PATTERN; } });
+Object.defineProperty(exports, "ANTIGRAVITY_PROMPT_PATTERN", { enumerable: true, get: function () { return patterns_16.ANTIGRAVITY_PROMPT_PATTERN; } });
+Object.defineProperty(exports, "ANTIGRAVITY_THINKING_PATTERN", { enumerable: true, get: function () { return patterns_16.ANTIGRAVITY_THINKING_PATTERN; } });
+Object.defineProperty(exports, "ANTIGRAVITY_SEPARATOR_PATTERN", { enumerable: true, get: function () { return patterns_16.ANTIGRAVITY_SEPARATOR_PATTERN; } });
+Object.defineProperty(exports, "ANTIGRAVITY_SELECTION_LIST_PATTERN", { enumerable: true, get: function () { return patterns_16.ANTIGRAVITY_SELECTION_LIST_PATTERN; } });
+Object.defineProperty(exports, "ANTIGRAVITY_NAVIGATE_FOOTER_PATTERN", { enumerable: true, get: function () { return patterns_16.ANTIGRAVITY_NAVIGATE_FOOTER_PATTERN; } });
+Object.defineProperty(exports, "ANTIGRAVITY_NUMBERED_OPTION_PATTERN", { enumerable: true, get: function () { return patterns_16.ANTIGRAVITY_NUMBERED_OPTION_PATTERN; } });
+Object.defineProperty(exports, "ANTIGRAVITY_SWITCH_MODEL_HEADER_PATTERN", { enumerable: true, get: function () { return patterns_16.ANTIGRAVITY_SWITCH_MODEL_HEADER_PATTERN; } });
+Object.defineProperty(exports, "ANTIGRAVITY_DIALOG_BOUNDARY_PATTERN", { enumerable: true, get: function () { return patterns_16.ANTIGRAVITY_DIALOG_BOUNDARY_PATTERN; } });
+Object.defineProperty(exports, "ANTIGRAVITY_DIALOG_MAX_ROWS", { enumerable: true, get: function () { return patterns_16.ANTIGRAVITY_DIALOG_MAX_ROWS; } });
+Object.defineProperty(exports, "ANTIGRAVITY_SURVEY_PATTERN", { enumerable: true, get: function () { return patterns_16.ANTIGRAVITY_SURVEY_PATTERN; } });
+Object.defineProperty(exports, "locateAntigravityDialogRegion", { enumerable: true, get: function () { return patterns_16.locateAntigravityDialogRegion; } });
+Object.defineProperty(exports, "isAntigravityNumberedDialog", { enumerable: true, get: function () { return patterns_16.isAntigravityNumberedDialog; } });
+Object.defineProperty(exports, "ANTIGRAVITY_SKIP_PATTERNS", { enumerable: true, get: function () { return patterns_16.ANTIGRAVITY_SKIP_PATTERNS; } });
+const patterns_17 = require("./tools/command-code/patterns");
+var patterns_18 = require("./tools/command-code/patterns");
+Object.defineProperty(exports, "COMMAND_CODE_SPINNER_CHARS", { enumerable: true, get: function () { return patterns_18.COMMAND_CODE_SPINNER_CHARS; } });
+Object.defineProperty(exports, "COMMAND_CODE_PROMPT_PATTERN", { enumerable: true, get: function () { return patterns_18.COMMAND_CODE_PROMPT_PATTERN; } });
+Object.defineProperty(exports, "COMMAND_CODE_SEPARATOR_PATTERN", { enumerable: true, get: function () { return patterns_18.COMMAND_CODE_SEPARATOR_PATTERN; } });
+Object.defineProperty(exports, "COMMAND_CODE_INTERRUPT_HINT_PATTERN", { enumerable: true, get: function () { return patterns_18.COMMAND_CODE_INTERRUPT_HINT_PATTERN; } });
+Object.defineProperty(exports, "COMMAND_CODE_THINKING_PATTERN", { enumerable: true, get: function () { return patterns_18.COMMAND_CODE_THINKING_PATTERN; } });
+Object.defineProperty(exports, "COMMAND_CODE_RESPONSE_MARKER_PATTERN", { enumerable: true, get: function () { return patterns_18.COMMAND_CODE_RESPONSE_MARKER_PATTERN; } });
+Object.defineProperty(exports, "COMMAND_CODE_COMPLETION_PATTERN", { enumerable: true, get: function () { return patterns_18.COMMAND_CODE_COMPLETION_PATTERN; } });
+Object.defineProperty(exports, "COMMAND_CODE_MODE_INDICATOR_PATTERN", { enumerable: true, get: function () { return patterns_18.COMMAND_CODE_MODE_INDICATOR_PATTERN; } });
+Object.defineProperty(exports, "COMMAND_CODE_BANNER_PATTERNS", { enumerable: true, get: function () { return patterns_18.COMMAND_CODE_BANNER_PATTERNS; } });
+Object.defineProperty(exports, "COMMAND_CODE_HOOK_NOTICE_PATTERN", { enumerable: true, get: function () { return patterns_18.COMMAND_CODE_HOOK_NOTICE_PATTERN; } });
+Object.defineProperty(exports, "findCommandCodeChromeStart", { enumerable: true, get: function () { return patterns_18.findCommandCodeChromeStart; } });
+Object.defineProperty(exports, "COMMAND_CODE_SKIP_PATTERNS", { enumerable: true, get: function () { return patterns_18.COMMAND_CODE_SKIP_PATTERNS; } });
 const logger = (0, logger_1.createLogger)('cli-patterns');
-/**
- * Claude CLI spinner characters (expanded set)
- * These are shown when Claude is thinking/processing
- */
-exports.CLAUDE_SPINNER_CHARS = [
-    '✻', '✽', '⏺', '·', '∴', '✢', '✳', '✶',
-    '⦿', '◉', '●', '○', '◌', '◎', '⊙', '⊚',
-    '⠋', '⠙', '⠹', '⠸', '⠼', '⠴', '⠦', '⠧', '⠇', '⠏', // Braille spinner
-];
-/**
- * Claude thinking pattern
- * Matches spinner character followed by activity text ending with …
- * The text can contain spaces (e.g., "Verifying implementation (dead code detection)…")
- *
- * Alternative 2: "esc to interrupt" status bar text (Issue #188)
- * Claude Code shows "esc to interrupt" in the terminal status bar during active processing.
- * Previous pattern required closing paren `to interrupt\)` matching `(esc to interrupt)`,
- * but Claude Code v2.x status bar format uses `· esc to interrupt ·` without parens.
- * Updated to match `esc to interrupt` which covers both formats.
- */
-exports.CLAUDE_THINKING_PATTERN = new RegExp(`[${exports.CLAUDE_SPINNER_CHARS.join('')}]\\s+.+…|esc to interrupt`, 'm');
-/**
- * Claude status-bar "esc to interrupt" hint (Issue #805)
- *
- * Claude Code shows "esc to interrupt" in the bottom status bar ONLY while it is
- * actively processing. When idle/ready, the status bar shows shortcut hints
- * (e.g., "? for shortcuts") instead -- so this token is a reliable "running" signal.
- *
- * Why this exists separately from CLAUDE_THINKING_PATTERN's "esc to interrupt"
- * alternative: status detection evaluates the spinner+ellipsis branch of
- * CLAUDE_THINKING_PATTERN within a narrow 5-line window (THINKING_TAIL_LINE_COUNT)
- * to avoid mistaking a completed thinking summary in scrollback for active work
- * (Issue #188). During /pm-auto-dev + subagent runs, the bottom task panel
- * ("⏺ main" / "◯ general-purpose ..." rows) pushes both the "✶ Running…" spinner
- * AND the "esc to interrupt" status bar out of that 5-line window, so the session
- * was misdetected as Ready (Issue #805). Unlike the spinner+ellipsis summary, the
- * status-bar text is repainted live and never lingers in scrollback, so it can be
- * matched in a wider footer window without regressing Issue #188.
- */
-exports.CLAUDE_INTERRUPT_HINT_PATTERN = /esc to interrupt/;
-/**
- * Codex activity-marker pattern
- * Matches activity indicators like "• Planning", "• Searching", etc.
- * T1.1: Extended to include "Ran" and "Deciding"
- *
- * Issue #1671: these are *transcript records*, not a liveness signal. Codex is
- * inline-rendered (no alternate screen), so every "• Ran <cmd>" / "• Running
- * <cmd>" step it ever printed stays in the pane scrollback forever — measured on
- * a live `mcbd-codex-*` pane: 396 "• Ran" and 11 "• Running" rows, all of them
- * from finished steps. Matching this pattern against a fixed tail window
- * therefore answers "did a step happen recently", not "is Codex working now".
- * Use {@link isCodexTurnActive} for the latter.
- */
-exports.CODEX_THINKING_PATTERN = /•\s*(Planning|Searching|Exploring|Running|Thinking|Working|Reading|Writing|Analyzing|Ran|Deciding)/m;
-/**
- * Codex live status-line hint (Issue #1671)
- *
- * While a turn is in flight Codex pins a status row directly above the composer:
- *
- *     • Working (13s • esc to interrupt) · 1 background terminal running · /ps to view
- *
- * It is repainted in place every tick and erased the moment the turn ends, so —
- * unlike the "• Ran"/"• Running" step records — it never lingers in scrollback.
- * Measured on a 11,000-line capture of an idle Codex pane: zero occurrences of
- * "esc to interrupt", against 396 lingering "• Ran" rows. That makes it the one
- * unambiguous "Codex is still generating" token, mirroring Claude's
- * {@link CLAUDE_INTERRUPT_HINT_PATTERN}.
- */
-exports.CODEX_INTERRUPT_HINT_PATTERN = /esc to interrupt/;
-/**
- * How far above the last content row Codex's composer ("› …") may sit.
- *
- * Codex pins the composer and the status bar to the bottom of the pane, so the
- * composer lands 2-3 rows above the last non-blank row in every observed frame.
- * The small allowance keeps the search from walking up into the transcript and
- * latching onto the echoed user message, which uses the same "› " marker.
- */
-const CODEX_COMPOSER_SEARCH_ROWS = 8;
-/**
- * Decide whether a Codex turn is still in flight (Issue #1671).
- *
- * Completion detection used to answer this with {@link CODEX_THINKING_PATTERN}
- * over a fixed 20-row tail. Because "• Ran <cmd>" is a *past-tense record* that
- * never leaves the transcript, a turn that ended with a short final message kept
- * that record inside the tail window and was reported as "still thinking"
- * forever — so its reply was never saved, while a turn whose final message
- * happened to be longer than 20 rows pushed the record out of the window and was
- * saved. Whether a reply reached Message History depended on how long it was.
- *
- * Two signals, both measured against live codex-cli 0.146.0 captures:
- *
- * 1. The live status line ({@link CODEX_INTERRUPT_HINT_PATTERN}) anywhere in the
- *    tail window. Present in every generating frame from 1s onwards, absent from
- *    every idle frame.
- * 2. An activity marker in the rows immediately above the composer — the band
- *    Codex reserves for that status line. Version-agnostic backstop for a Codex
- *    build whose status row drops the "esc to interrupt" wording; deliberately
- *    narrow (THINKING_TAIL_LINE_COUNT rows, matching the window status-detector
- *    already uses) so records further up the transcript cannot reach it.
- *
- * When no composer can be located the frame is not a normal Codex layout (an
- * overlay is up, or the pane is mid-redraw), so signal 2 falls back to the whole
- * tail window — the pre-#1671 behaviour, which errs towards "still active".
- *
- * @param lines - Captured pane lines with trailing blank rows already trimmed
- * @param tailLineCount - Size of the tail window completion detection looks at
- * @returns True while Codex is still generating
- */
-function isCodexTurnActive(lines, tailLineCount) {
-    const tailWindow = (0, ansi_1.stripAnsi)(lines.slice(Math.max(0, lines.length - tailLineCount)).join('\n'));
-    // 1. Live status line — unambiguous, never survives the end of a turn.
-    if (exports.CODEX_INTERRUPT_HINT_PATTERN.test(tailWindow))
-        return true;
-    // 2. Activity marker in the status-line band directly above the composer.
-    //    Searched bottom-up so the composer wins over the echoed user message.
-    let composerIndex = -1;
-    for (let i = lines.length - 1; i >= Math.max(0, lines.length - CODEX_COMPOSER_SEARCH_ROWS); i--) {
-        if (exports.CODEX_PROMPT_PATTERN.test((0, ansi_1.stripAnsi)(lines[i]))) {
-            composerIndex = i;
-            break;
-        }
-    }
-    if (composerIndex < 0)
-        return exports.CODEX_THINKING_PATTERN.test(tailWindow);
-    const bandStart = Math.max(0, composerIndex - thinking_constants_1.THINKING_TAIL_LINE_COUNT + 1);
-    const band = (0, ansi_1.stripAnsi)(lines.slice(bandStart, composerIndex + 1).join('\n'));
-    return exports.CODEX_THINKING_PATTERN.test(band);
-}
-/**
- * Claude prompt pattern (waiting for input)
- * Supports both legacy '>' and new '❯' (U+276F) prompt characters
- * Issue #132: Also matches prompts with recommended commands (e.g., "❯ /work-plan")
- *
- * Matches:
- * - Empty prompt: "❯ " or "> "
- * - Prompt with command: "❯ /work-plan" or "> npm install"
- */
-exports.CLAUDE_PROMPT_PATTERN = /^[>❯](\s*$|\s+\S)/m;
-/**
- * Claude separator pattern
- */
-exports.CLAUDE_SEPARATOR_PATTERN = /^─{10,}$/m;
-/**
- * Locate the start of Claude Code's bottom-pinned footer within a captured pane.
- *
- * Claude Code v2 draws in the alternate screen and reserves the last rows of the
- * pane for a footer that is never transcript content:
- *
- *     <hint row>            ← "◉ xhigh · /effort", "tmux detected · …", or blank
- *     ────────────────────  ← separator
- *     ❯ <input box>         ← one or more rows
- *     ────────────────────  ← separator
- *     ⏸ manual mode on · ? for shortcuts · ← for agents        focus
- *
- * The hint row rotates every few seconds while the conversation sits idle, so
- * keeping the footer in an extracted response makes its content hash change on
- * every poll tick. That defeated the content-based dedup added in #1268 and
- * re-saved the same reply once per tick (#1289).
- *
- * The boundary is found structurally rather than by matching hint text: the hint
- * strings are Claude Code's to change, and pattern-matching them is what let this
- * regression through (`? for shortcuts` was already listed as a skip pattern, but
- * the real status bar embeds it mid-line so the anchors never matched). The row
- * above the opening separator is reserved by Claude Code's layout and stays blank
- * even when a reply fills the whole pane, so it is always safe to drop.
- *
- * @param lines - Captured pane lines; trailing blank rows are tolerated
- * @returns Index of the first footer row, or -1 when no footer is present
- */
-function findClaudeChromeStart(lines) {
-    // Issue #1879: the structural search (closing separator → opening separator →
-    // prompt glyph, including the "is this really the input box and not a reply
-    // fenced by two horizontal rules?" check) moved to `findClaudeInputBox` so the
-    // composer reader locates the same box this trimmer does. Behaviour here is
-    // unchanged; only the caller of the search moved.
-    const box = (0, composer_text_1.findClaudeInputBox)(lines);
-    if (box === null)
-        return -1;
-    // Include the reserved hint row directly above the opening separator.
-    return Math.max(0, box.openingSeparator - 1);
-}
-/**
- * Claude trust dialog pattern (Issue #201)
- *
- * Matches the "Quick safety check" dialog displayed by Claude CLI v2.x
- * when accessing a workspace for the first time.
- *
- * Intentionally uses partial matching (no line-start anchor ^):
- * Other pattern constants (CLAUDE_PROMPT_PATTERN, CLAUDE_SEPARATOR_PATTERN, etc.)
- * use line-start anchors (^), but this pattern needs to match at any position
- * within the tmux output buffer because the dialog text may appear after
- * tmux padding or other output. (SF-001)
- */
-exports.CLAUDE_TRUST_DIALOG_PATTERN = /Yes, I trust this folder/m;
-/** The option row of the trust dialog's cursor: `❯` (or legacy `>`) after the dialog's left padding. */
-const CLAUDE_TRUST_CURSOR_ROW_PATTERN = /^\s*[>❯]\s+\S/;
-/** How far the cursor row may sit from the `Yes, I trust this folder` row (the dialog has two options). */
-const CLAUDE_TRUST_MAX_CURSOR_DISTANCE = 3;
-/**
- * Keys that answer Claude Code's folder-trust dialog with "Yes", or null when
- * no answerable dialog is on screen (Issue #3078).
- *
- * The dialog comes in two layouts, and Enter alone is only right for one:
- *
- *   - default Yes (Issue #201 era, `tests/unit/lib/claude-session.test.ts`):
- *     ` ❯ 1. Yes, I trust this folder` / `   2. No, exit` — Enter confirms Yes.
- *   - default No (2.1.259 `tests/fixtures/chat-dialog-card-2254/claude-trust-2-1-259.txt`,
- *     2.1.287 with a permission allow-list
- *     `tests/fixtures/claude-trust-dialog-3078/allowlist-default-no-2-1-287.txt`):
- *     ` ❯ No, exit` / `   Yes, I trust this folder` — Enter EXITS Claude Code.
- *
- * So the answer is read off the screen: the distance from the cursor row to the
- * Yes row becomes that many `Up`/`Down` presses, then `Enter`. Only the last
- * dialog in the capture counts, and a dialog followed by Claude's input-box
- * separator is history in the scrollback, not an open dialog.
- *
- * @param output - ANSI-stripped pane output
- * @returns tmux key names ending in `Enter` (just `['Enter']` when the cursor is
- *   already on Yes), or null when no open dialog / no readable cursor row
- */
-function resolveClaudeTrustDialogKeys(output) {
-    const lines = output.split('\n');
-    const yesIndex = findOpenClaudeTrustYesRow(lines);
-    if (yesIndex === -1)
-        return null;
-    for (let distance = 0; distance <= CLAUDE_TRUST_MAX_CURSOR_DISTANCE; distance++) {
-        for (const direction of distance === 0 ? [0] : [-1, 1]) {
-            const index = yesIndex + direction * distance;
-            if (index < 0 || index >= lines.length)
-                continue;
-            if (!CLAUDE_TRUST_CURSOR_ROW_PATTERN.test(lines[index]))
-                continue;
-            // Cursor above Yes → move Down; below → move Up.
-            const key = direction < 0 ? 'Down' : 'Up';
-            return [...Array(distance).fill(key), 'Enter'];
-        }
-    }
-    return null;
-}
-/**
- * Whether Claude Code's folder-trust dialog is the open screen (Issue #3078).
- *
- * The dialog's cursor row (` ❯ No, exit`) has the prompt glyph, so the start
- * wait asks this before CLAUDE_PROMPT_PATTERN rather than reading the dialog as
- * a ready prompt.
- *
- * @param output - ANSI-stripped pane output
- */
-function isClaudeTrustDialogOpen(output) {
-    return findOpenClaudeTrustYesRow(output.split('\n')) !== -1;
-}
-/** `#{pane_current_command}` values of an interactive shell, with tmux's `-` login prefix removed. */
-const SHELL_PANE_COMMANDS = new Set(['sh', 'bash', 'zsh', 'fish', 'dash', 'ksh', 'tcsh', 'csh']);
-/**
- * Whether a pane's foreground command is a shell rather than an agent
- * (Issue #3089). Claude Code shows up as `claude`, `node` or its version
- * string (`2.1.287`), never as one of these, so a shell here after the agent
- * was seen running means the agent has exited.
- *
- * @param command - `#{pane_current_command}` of the pane
- */
-function isShellPaneCommand(command) {
-    return SHELL_PANE_COMMANDS.has(command.trim().replace(/^-/, ''));
-}
-/** Row of the last `Yes, I trust this folder`, or -1 when absent or already answered. */
-function findOpenClaudeTrustYesRow(lines) {
-    for (let i = lines.length - 1; i >= 0; i--) {
-        if (!exports.CLAUDE_TRUST_DIALOG_PATTERN.test(lines[i]))
-            continue;
-        // Claude's input box (separator rows) drawn below it: the dialog is scrollback.
-        return lines.slice(i + 1).some((line) => exports.CLAUDE_SEPARATOR_PATTERN.test(line)) ? -1 : i;
-    }
-    return -1;
-}
-/**
- * Codex prompt pattern
- * T1.2: Improved to detect empty prompts as well
- */
-exports.CODEX_PROMPT_PATTERN = /^›\s*/m;
-/**
- * The directory/folder trust dialog's question line, across codex builds
- * (Issue #2884): `Do you trust the contents of this directory?` (<=0.155.1)
- * and `Trust this folder?` (0.157.1, which dropped the "Do you trust" wording
- * entirely -- `tests/fixtures/codex-dialogs-0157/trust.txt`). The two variants
- * are kept as alternatives of one pattern -- rather than duplicated across
- * {@link CODEX_DIALOG_PATTERN}, `getCodexActiveDialog` and
- * `getCodexLifecycleDialog` -- so those three cannot drift into disagreeing
- * about what counts as the trust dialog.
- */
-exports.CODEX_TRUST_QUESTION_PATTERN = /Do you trust|Trust this folder\?/;
-/**
- * Codex INTERACTIVE startup dialog pattern (Issue #890)
- *
- * Codex shows interactive update-notification and trust dialogs on first launch.
- * Their currently-selected option lines render as "› 1. Update now", which ALSO
- * matches CODEX_PROMPT_PATTERN (the bare "^›" input-prompt pattern). So "is the
- * input prompt ready?" cannot be decided by CODEX_PROMPT_PATTERN alone -- it must
- * also confirm no INTERACTIVE dialog is still active. This pattern matches markers
- * that appear ONLY in interactive dialogs:
- *   - Interactive update dialog: "Skip until next version" (the option-3 label)
- *   - Trust dialog:              {@link CODEX_TRUST_QUESTION_PATTERN}
- *   - Dialog confirm footer:     "Press enter to continue"
- *   - Numbered selection option: "› 1. ..." (leading ›, a digit, a dot)
- *
- * IMPORTANT (Issue #890 regression): the substring "Update available" is
- * deliberately NOT a marker. After the update is skipped, codex keeps a
- * non-interactive banner box ("✨ Update available! ... / Run npm install -g
- * @openai/codex to update.") rendered ABOVE the genuine "› " prompt. Matching
- * "Update available" would make isCodexPromptReady() return false for as long as
- * that banner is visible, hanging waitForReady (~30s) and waitForPrompt (15s) on
- * exactly the first-launch + update-pending case this fix targets. The interactive
- * update dialog is still reliably detected via its other three markers above
- * ("› 1. Update now" + "Skip until next version" + "Press enter to continue").
- *
- * No /g flag (would make .test() stateful); no nested quantifiers (ReDoS-safe).
- */
-exports.CODEX_DIALOG_PATTERN = new RegExp(`Skip until next version|${exports.CODEX_TRUST_QUESTION_PATTERN.source}|Press enter to continue|^\\s*›\\s*\\d+\\.\\s`, 'm');
-/**
- * Codex genuine input-prompt line (Issue #892).
- *
- * A line whose first non-space glyph is "›" but which is NOT a numbered dialog
- * option ("› 1. ..."). The selected dialog option renders "›" at column 0 too
- * (same column as the live prompt), so the digit-dot negative lookahead is what
- * distinguishes the genuine input line from a dialog option line. Single-line
- * (no /m, no /g) -- callers test it per line to locate the prompt's position.
- */
-const CODEX_GENUINE_PROMPT_LINE = /^\s*›(?!\s*\d+\.)/;
-/**
- * Decide whether Codex output shows a genuine interactive input prompt rather than
- * a startup dialog (Issue #890, reworked in Issue #892).
- *
- * POSITION-based: capturePane(50) returns scrollback, so a dismissed update/trust
- * dialog lingers ABOVE the live prompt. The original Issue #890 form
- * (`CODEX_PROMPT_PATTERN && !CODEX_DIALOG_PATTERN`) is a whole-window test, so a
- * residual dialog line anywhere in the frame keeps it false forever -- hanging
- * waitForReady/waitForPrompt and (via the re-firing branches) injecting "222...".
- *
- * Instead the frame is ready when a genuine input-prompt line sits BELOW every
- * interactive dialog marker -- i.e. the prompt is the bottom-most active element.
- * CODEX_PROMPT_PATTERN / CODEX_DIALOG_PATTERN are intentionally unchanged here
- * (status-detector.ts / response-checker.ts depend on them).
- *
- * Used by both CodexTool.waitForReady() (startup) and CodexTool.waitForPrompt()
- * (before every send) so a residual dialog is never mistaken for "ready" and, just
- * as importantly, a genuine prompt below stale dialog scrollback IS detected.
- */
-function isCodexPromptReady(output) {
-    const lines = output.split('\n');
-    let lastDialogMarkerIdx = -1;
-    let lastPromptIdx = -1;
-    for (let i = 0; i < lines.length; i++) {
-        const line = lines[i];
-        if (exports.CODEX_DIALOG_PATTERN.test(line)) {
-            // A dialog marker/option line is never itself a genuine prompt.
-            lastDialogMarkerIdx = i;
-            continue;
-        }
-        if (CODEX_GENUINE_PROMPT_LINE.test(line)) {
-            lastPromptIdx = i;
-        }
-    }
-    return lastPromptIdx >= 0 && lastPromptIdx > lastDialogMarkerIdx;
-}
-/**
- * Classify the bottom-most active Codex startup dialog (Issue #892).
- *
- * POSITION-based companion to isCodexPromptReady(): only dialog text appearing
- * BELOW the genuine input-prompt line is considered "active". Dialog lines that
- * remain in scrollback ABOVE a live prompt are ignored, so a dismissed dialog is
- * never re-acted on (this is what stops the update branch from re-sending "2" once
- * the dialog has been skipped -- the root cause of the "222..." prefix).
- *
- * Precedence matches CodexTool.waitForReady()'s historical branch order: the
- * update dialog wins over its own "Press enter to continue" footer, because Enter
- * on the update dialog could confirm the default "1. Update now" (npm install).
- */
-/**
- * The lines of Codex's ACTIVE region: everything strictly below the bottom-most
- * genuine input-prompt line, or the whole frame when there is no prompt line
- * (Issue #892).
- *
- * This is the one rule that keeps every Codex dialog classifier honest.
- * capturePane returns scrollback, so a dialog that was answered minutes ago is
- * still in the frame; only what sits BELOW the live prompt is still awaiting a
- * key. Shared by getCodexActiveDialog and getCodexLifecycleDialog so the two
- * cannot drift into disagreeing about what "active" means.
- */
-function codexActiveRegionLines(output) {
-    const lines = output.split('\n');
-    // Index of the bottom-most genuine input-prompt line (-1 if none).
-    let promptIdx = -1;
-    for (let i = lines.length - 1; i >= 0; i--) {
-        if (CODEX_GENUINE_PROMPT_LINE.test(lines[i])) {
-            promptIdx = i;
-            break;
-        }
-    }
-    return lines.slice(promptIdx + 1);
-}
-function getCodexActiveDialog(output) {
-    // Residual dialog text above a live prompt is excluded, so a dialog lingering
-    // in scrollback is never treated as active.
-    const active = codexActiveRegionLines(output).join('\n');
-    if (active === '') {
-        return null;
-    }
-    if (active.includes('Skip until next version') ||
-        (active.includes('Update') && active.includes('Skip'))) {
-        return 'update';
-    }
-    if (exports.CODEX_TRUST_QUESTION_PATTERN.test(active)) {
-        return 'trust';
-    }
-    if (active.includes('Press enter to continue')) {
-        return 'press-enter';
-    }
-    return null;
-}
-/**
- * Anchors of codex's "Hooks need review" launch dialog — screen 1 of the three
- * it can put in front of a session (Issue #1760, re-measured on codex-cli
- * 0.148.0 for Issue #1829):
- *
- * ```
- *  Hooks need review
- *  4 hooks are new or changed.
- *  Hooks can run outside the sandbox after you trust them.
- *
- * > 1. Review hooks
- *   2. Trust all and continue
- *   3. Continue without trusting (hooks won't run)
- *   Press enter to confirm or esc to go back
- * ```
- *
- * The hook COUNT is data — 0.147.0 said 5, 0.148.0 said 4 — so neither anchor
- * reads it. Both strings are required so a "hooks" mention elsewhere cannot
- * select an option on a live prompt.
- */
-exports.CODEX_HOOKS_REVIEW_ANCHORS = ['Hooks need review', 'Continue without trusting'];
-/**
- * Footer of screen 2, the hooks LIST, new in codex-cli 0.148.0 (Issue #1829):
- * `Press t to trust all; enter to review hooks; esc to close`.
- *
- * The semicolon is what separates it from screen 3's footer — "trust all;" and
- * "trust;" are disjoint — and matching the footer rather than the table above it
- * keeps the two screens distinguishable by a single line each.
- */
-const CODEX_HOOKS_LIST_FOOTER_PATTERN = /press\s+t\s+to\s+trust\s+all\s*;/i;
-/**
- * Footer of screen 3, the per-hook review DETAIL (Issue #1829):
- * `Press t to trust; esc to go back`. Where both live sessions in the Issue were
- * found parked.
- */
-const CODEX_HOOKS_DETAIL_FOOTER_PATTERN = /press\s+t\s+to\s+trust\s*;/i;
-/**
- * How much of the active region {@link getCodexLifecycleDialog} judges, in
- * non-blank lines counted from the bottom (Issue #1829).
- *
- * `getCodexActiveDialog` searches the whole active region, which is right for
- * its caller: `waitForReady` only ever runs during `startSession`, when nothing
- * else can be on screen. This classifier runs on every Auto-Yes poll for the
- * life of the session, where "active region" alone is not enough — a codex
- * approval request renders no `› ` composer line, so an approval that comes up
- * while a dismissed hooks screen is still inside the capture window would have
- * the whole frame as its active region and would be mistaken for the dialog.
- * Requiring the dialog to be in the TAIL is what separates the screen the user
- * is looking at from the one they have already left.
- *
- * 12 lines fits the tallest screen this has to recognise (the review dialog's
- * two anchors sit 6 lines apart) and none of the shorter frames below it.
- */
-const CODEX_LIFECYCLE_TAIL_LINES = 12;
-/**
- * The interactive update dialog, by its option-3 label or its option-1 line.
- *
- * Deliberately stricter than `getCodexActiveDialog`'s `Update` AND `Skip`
- * fallback: that pair can occur in ordinary agent output, and here a false
- * positive silently stops Auto-Yes answering a real prompt. Both anchors below
- * are dialog chrome that agent output does not produce.
- */
-const CODEX_UPDATE_DIALOG_ANCHORS = [
-    /skip until next version/i,
-    /^\s*[›❯]?\s*\d+\.\s*Update now/im,
-];
-/**
- * Classify the bottom-most ACTIVE codex lifecycle screen (Issue #1829).
- *
- * Position-based, via {@link codexActiveRegionLines}: a dialog left in
- * scrollback above a live prompt is not active and returns `null`. That is not
- * a detail — the auto-answer guard in the Auto-Yes poller is built on this
- * function, and a whole-frame version of it would switch Auto-Yes off for the
- * rest of a codex session the moment any launch dialog scrolled past.
- *
- * The two hooks screens are matched FIRST and bottom-up, because a stuck pane
- * holds screen 2 above screen 3 and the way out of each differs. The remaining
- * three are region-level substring tests, which is all their anchors allow:
- * the review dialog's are on two different lines.
- *
- * Deliberately NOT used to decide whether a prompt exists. `detectPrompt` still
- * reports these screens, so a human still sees them; what this function gates is
- * only whether a machine may answer on their behalf.
- *
- * @param output - ANSI-stripped pane capture
- * @returns The active lifecycle screen, or null when none is
- */
-function getCodexLifecycleDialog(output) {
-    const activeLines = codexActiveRegionLines(output);
-    const window = [];
-    for (let i = activeLines.length - 1; i >= 0 && window.length < CODEX_LIFECYCLE_TAIL_LINES; i--) {
-        if (activeLines[i].trim() === '')
-            continue;
-        window.unshift(activeLines[i]);
-    }
-    if (window.length === 0)
-        return null;
-    const text = window.join('\n');
-    // One bottom-up pass, returning on the first line that decides the question --
-    // including the lines that decide it NEGATIVELY. A stuck pane holds screen 2
-    // above screen 3, and an approval request can come up with a hooks screen
-    // still inside the capture window; in both cases the screen the user is
-    // looking at is the lower one.
-    for (let i = window.length - 1; i >= 0; i--) {
-        const line = window[i];
-        if (CODEX_HOOKS_LIST_FOOTER_PATTERN.test(line))
-            return 'hooks-list';
-        if (CODEX_HOOKS_DETAIL_FOOTER_PATTERN.test(line))
-            return 'hooks-detail';
-        // The agent asking the human for permission mid-turn (Issue #1628's
-        // "esc to cancel" footer, which no lifecycle screen wears). This is exactly
-        // the prompt Auto-Yes exists to answer, so whatever lifecycle text is still
-        // above it has been left behind and must not withhold the answer.
-        if (exports.CODEX_APPROVAL_FOOTER_PATTERN.test(line))
-            return null;
-        if (CODEX_UPDATE_DIALOG_ANCHORS.some((pattern) => pattern.test(line)))
-            return 'update';
-        if (exports.CODEX_TRUST_QUESTION_PATTERN.test(line))
-            return 'trust';
-        // Both anchors required, so a stray "hooks" mention cannot claim the screen.
-        if (line.includes(exports.CODEX_HOOKS_REVIEW_ANCHORS[1]) && text.includes(exports.CODEX_HOOKS_REVIEW_ANCHORS[0])) {
-            return 'hooks-review';
-        }
-    }
-    return null;
-}
-/**
- * Codex separator pattern
- */
-exports.CODEX_SEPARATOR_PATTERN = /^─.*Worked for.*─+$/m;
-/**
- * Codex CLI selection list footer pattern (Issue #619, #622)
- * Detects Codex CLI's interactive selection prompts that use arrow key
- * navigation (e.g., /model command's model and reasoning level selection steps).
- *
- * Matches:
- *   - Step 1 (model selection): "Press enter to select reasoning effort, or esc to dismiss."
- *   - Step 2 (reasoning level): "Press enter to confirm or esc to go back"
- *   - Legacy: "press enter to confirm or esc to cancel"
- * Does NOT match: "press number to confirm" (handled by detectMultipleChoicePrompt)
- *
- * The distinction is important: "press enter to confirm/select" indicates an arrow-key
- * selection list (NavigationButtons), while "press number to confirm" indicates
- * a numbered prompt (PromptPanel with buttons).
- */
-exports.CODEX_SELECTION_LIST_PATTERN = /press\s+enter\s+to\s+(?:confirm|select)/i;
-/**
- * Codex CLI approval-request footer pattern (Issue #1628).
- *
- * Codex renders an approval request ("Would you like to run the following
- * command?" / "Would you like to make the following edits?") with the SAME
- * "Press enter to confirm" footer as a `/model`-style menu, which is why
- * CODEX_SELECTION_LIST_PATTERN swallows it. The two differ in the escape verb:
- * an approval request can be *cancelled* (it is the agent asking the human for
- * permission), a menu can only be *gone back* from.
- *
- * Measured on codex-cli 0.146.0 (five consecutive live approval frames captured
- * from a real session, plus two live `/model` picker frames):
- *   - approval : "Press enter to confirm or esc to cancel"
- *   - /model   : "Press enter to confirm or esc to go back"
- *   - /model   : "Press enter to select reasoning effort, or esc to dismiss."
- *
- * Used only as one of two OR'd approval signals (see isCodexApprovalRequest in
- * status-detector.ts); the other is an interrogative question line, so a future
- * rewording of either signal alone does not reopen Issue #1628.
- *
- * No /g flag (keeps .test() stateless), no nested quantifiers (ReDoS-safe).
- */
-exports.CODEX_APPROVAL_FOOTER_PATTERN = /esc\s+to\s+cancel/i;
-/**
- * Codex CLI tool-call approval FORM footer (Issue #2609).
- *
- * Codex asks for some tool calls through a form rather than the classic
- * approval list, and closes it with a different sentence. Measured on a live
- * Browser use approval (2026-09-17, twice in one session):
- *
- * ```text
- * • Calling 修正前の専用GUIを開く
- *
- *   Field 1/1
- *   Allow Browser use to access http://127.0.0.1:60311?
- *
- *   origin: http://127.0.0.1:60311
- *
- *   › 1. Allow         Run the tool and continue.
- *     2. Always allow  Run the tool and remember this choice for future tool calls.
- *     3. Cancel        Cancel this tool call
- *   enter to submit | esc to cancel
- * ```
- *
- * No `press enter to confirm/select`, so {@link CODEX_SELECTION_LIST_PATTERN}
- * misses it and `detectCodexDialog` returned null for a dialog the status
- * detector reported as `waiting` — which `/prompt-response` read as
- * `prompt_no_longer_active` and Auto-Yes as `unclassified-frame`.
- *
- * Deliberately a separate constant rather than another alternative in
- * CODEX_SELECTION_LIST_PATTERN: that one also drives `detect.ts` branch 0.8, and
- * this footer is consumed ONLY by `detectCodexDialog`'s entry gate. It is the
- * whole measured row and nothing looser — `/m` + `^…$` against the trimmed
- * footer rows `findNumberedOptionBlock` returns, so a sentence that merely
- * contains "enter to submit", or "esc to cancel" on its own (the #1928 mutation
- * that rewords the approval footer), still does not vouch for a block.
- *
- * No /g flag (keeps .test() stateless), no nested quantifiers (ReDoS-safe).
- */
-exports.CODEX_FORM_SUBMIT_FOOTER_PATTERN = /^enter\s+to\s+submit\s*\|\s*esc\s+to\s+cancel$/im;
-/**
- * Codex CLI 0.157 picker footer pattern (Issue #2868).
- *
- * codex-cli 0.157.1 retitled `/model` ("Select Model and Effort") and replaced
- * its "Press enter to confirm or esc to go back" footer with the terse
- * `enter select · esc back` row (measured: `tests/fixtures/codex-dialogs-0157/`).
- * CODEX_SELECTION_LIST_PATTERN no longer matched, so branch 0.8 missed the
- * picker and the dialog entry gate refused the answer (`prompt_no_longer_active`).
- *
- * Same construction as CODEX_FORM_SUBMIT_FOOTER_PATTERN: the whole measured row
- * (`/m` + `^…$`), tested only against a trimmed single footer row — never a
- * window — so a transcript quoting the words does not vouch for anything.
- * CODEX_SELECTION_LIST_PATTERN is deliberately left as is (#2774 / #2841).
- *
- * No /g flag (keeps .test() stateless), no nested quantifiers (ReDoS-safe).
- */
-exports.CODEX_PICKER_FOOTER_PATTERN = /^enter\s+select\s*·\s*esc\s+back$/im;
-/**
- * Codex CLI 0.157 effort-picker footer pattern (Issue #2868).
- *
- * The second `/model` step ("Select Reasoning Level for …") closes with
- * `enter default · s session · esc back` (measured:
- * `tests/fixtures/codex-dialogs-0157/model-picker-effort.txt`). Same
- * construction and rules as CODEX_PICKER_FOOTER_PATTERN: the whole row, tested
- * only against a single trimmed footer row.
- *
- * No /g flag (keeps .test() stateless), no nested quantifiers (ReDoS-safe).
- */
-exports.CODEX_EFFORT_PICKER_FOOTER_PATTERN = /^enter\s+default\s*·\s*s\s+session\s*·\s*esc\s+back$/im;
-/**
- * Codex CLI pager / edit-previous (transcript) mode footer pattern (Issue #1017)
- *
- * When Codex enters its transcript pager / "edit previous message" mode, the
- * bottom of the frame shows scroll / edit key hints INSTEAD of the usual
- * "model · N% left · path" status bar, 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% ─", NOT "N% left ·").
- *
- * Neither CODEX_SELECTION_LIST_PATTERN (which needs "press enter to
- * confirm/select") nor the "N% left ·" status-bar boundary logic in
- * status-detector.ts fires here, so the read-only TerminalDisplay is left with no
- * way to scroll or escape (the reported bug). This pattern recognizes the pager
- * footer directly — independent of the status bar — so the selection window
- * (NavigationButtons) can be rendered.
- *
- * Matches any of the pager-specific hints (either footer line is sufficient):
- *   - scroll/page/jump hints: "↑/↓ to scroll" / "pgup/pgdn to page" / "home/end to jump"
- *   - edit-previous hints:    "esc/← to edit prev" / "→ to edit next" / "enter to edit message"
- * The two branches are independent so a mangled unicode-arrow footer line is still
- * caught by the ASCII "to edit prev/next/message" and "pgup/pgdn"/"home/end" hints.
- *
- * Does NOT match the genuine "/model" selection list ("press enter to select") —
- * that footer has no scroll/page/jump or edit-prev/next/message hint — so the
- * existing CODEX_SELECTION_LIST_PATTERN path is unaffected (no regression).
- *
- * No /g flag (S4-5: keeps test() stateless). No nested quantifiers (SEC4-001: ReDoS-safe).
- */
-exports.CODEX_PAGER_FOOTER_PATTERN = /(?:↑\/↓|pgup\/pgdn|home\/end)\s+to\s+(?:scroll|page|jump)|to\s+edit\s+(?:prev|next|message)/i;
-/**
- * Codex CLI status-bar line pattern (Issue #1150)
- *
- * The Codex TUI renders a status bar as the bottom-most content line, just above
- * the input area. status-detector.ts uses it as the footer boundary that separates
- * the conversation content (thinking indicators / idle "›" prompt) from the input
- * area, so both the selection-list check (priority 0.8) and the running/idle check
- * (priority 2.7) depend on locating it.
- *
- * The format drifted across Codex versions — the "N% left ·" token was DROPPED in
- * v0.141 (gpt-5.5), which is exactly what broke Issue #1150:
- *   - v0.141 (gpt-5.5): "gpt-5.5 xhigh · ~/share/work/github_kewton/commandmate-issue-947"
- *   - legacy (gpt-5.4): "gpt-5.4 high · 21% left · ~/share/work/..."
- *   - legacy (o4-mini): "  o4-mini            50% left · /path/to/project"
- *
- * The previous pattern required "\d+%\s+left\s+·", so v0.141 bars never matched:
- * the footer boundary stayed -1 and the whole Codex running/idle block was skipped,
- * leaving generating sessions misreported as `ready` (static green dot, no glow).
- *
- * Version-independent anchor: a leading model token, a middle-dot "·" separator,
- * and a filesystem path ("~/…" or "/…") at the END of the line. Any "N% left ·"
- * segment (legacy) is absorbed by ".*·" before the trailing path. Requiring the
- * trailing path keeps this Codex-specific (guarded by cliToolId === 'codex' in
- * status-detector.ts) and stops ordinary conversation lines that merely contain a
- * "·" from being mistaken for the status bar.
- *
- * Single-line by design (no /m, no /g): status-detector.ts tests it per content
- * line. No nested quantifiers (ReDoS-safe; adjacent greedy quantifiers only).
- */
-exports.CODEX_STATUS_BAR_PATTERN = /^\s*\S.*·\s*~?\/\S*\s*$/;
-/**
- * Codex status bar with something drawn AFTER the path (Issue #2818) — the
- * second shape `findCodexFooterBoundary` in `tools/codex/detect.ts` accepts.
- *
- * From codex 0.154.0 on, the bar stops ending in the path once the first turn
- * has named the thread, and Plan mode adds a right-aligned badge:
- *
- * ```text
- *   gpt-5.6-terra low · /private/var/…/repo · Run touch probe.txt
- *   gpt-6-astra medium · ~/uat3-…/sandbox-repo                    Plan mode (shift+tab to cycle)
- * ```
- *
- * {@link CODEX_STATUS_BAR_PATTERN} wants the path last, so every such frame had
- * no boundary and fell to the detector's bar-independent branch D (#1150's
- * safety net). That branch reads the 15-row tail, and on an idle frame the tail
- * still holds the finished turn's `• Ran …` record — which is how an idle
- * session read `running` (#2808's `idle-after-declined-approval.txt`; #2818
- * reproduced it on a turn that simply ran one command and answered).
- *
- * Kept a SEPARATE pattern rather than a widened {@link CODEX_STATUS_BAR_PATTERN}
- * so the change stays on the one reader it was measured for: that pattern is
- * also the stripped-capture landmark of {@link findCodexChromeStart} and the
- * value reader's first test in `model-info-extractor.ts`, neither of which
- * this Issue measured.
- *
- * The shape is the one `CODEX_STATUS_BAR_WITH_TRAILER_PATTERN`
- * (`model-info-extractor.ts`, #2592) reads values off, written out here rather
- * than imported: that module's rule is that it must never be the reason this
- * boundary moves. Head segment, `·`, a path, then EITHER a further `·`
- * segment OR a column gap (two spaces) before right-aligned text. `[^·]*` puts
- * the path right after the FIRST `·`, so codex's in-flight row (`• Working (…)
- * · 1 background terminal running · /ps to view`) is not a bar — its first `·`
- * is followed by a count, not a path.
- *
- * Single-line, no /g, no nested quantifiers (ReDoS-safe), as above.
- */
-exports.CODEX_TRAILED_STATUS_BAR_PATTERN = /^\s*\S[^·]*·\s*~?\/\S*(?:\s*·[^\n]*|[^\S\n]{2,}\S[^\n]*)$/;
-/**
- * How far above the last non-blank row {@link findCodexChromeStart} looks for the
- * composer.
- *
- * Same allowance and the same reason as {@link CODEX_COMPOSER_SEARCH_ROWS}: codex
- * pins the composer two to three rows above the bottom in every measured frame
- * (`tests/fixtures/codex-live-2310/`), and a wider band would let the search walk
- * into the transcript and mistake the echoed user message — drawn with the same
- * `›` — for the input box.
- *
- * Wider than the 8 rows of the liveness search because 0.15x can draw notices
- * BELOW the composer (`N background terminal running · /ps to view · /stop to
- * close`) that the liveness search never had to step over.
- */
-const CODEX_CHROME_SEARCH_ROWS = 12;
-/**
- * A row whose first character is codex's `›` glyph, with something after it.
- *
- * Deliberately not {@link CODEX_PROMPT_PATTERN}: that one is multiline and
- * matches a bare `›`, which is right for "is a prompt on screen anywhere?" and
- * wrong for classifying ONE row. Anchored at column 0 because all three of
- * codex's `›` uses are, and an indented `›` in a reply is quoted text.
- */
-const CODEX_CHROME_GLYPH_ROW_PATTERN = /^›(\s|$)/;
-/**
- * Locate the start of codex's bottom-pinned chrome within a captured pane.
- *
- * The fifth reader of this shape, after {@link findClaudeChromeStart} (#1289),
- * {@link findCopilotChromeStart} (#1897), {@link findOpenCodeChromeStart}
- * (#1911) and {@link findCommandCodeChromeStart} (#2250). codex is the tool that
- * never got one, and Issue #2400 is the bill for that.
- *
- * codex renders inline and pins two rows to the bottom of a settled pane:
- *
- * ```text
- * › Ask Codex to do anything                      ← composer (placeholder or typed text)
- *
- *   gpt-6-astra xhigh · ~/share/work/…/CommandMate ← status bar (model · cwd)
- * ```
- *
- * Below the composer codex may also draw its own notices (`N background terminal
- * running · /ps to view`), so the boundary is "the composer row" rather than a
- * list of footer shapes: everything from the composer down is chrome by
- * construction, whatever codex adds there next.
- *
- * ## What went wrong without it (#2400)
- *
- * While the capture window is NOT saturated codex's extraction starts at
- * `lastCapturedLine`, so the composer only ever mattered as the `endIndex` break
- * — which the extraction loop already had. Once the pane outgrows
- * `CACHE_MAX_CAPTURE_LINES` (#1670) the cursor stops being a position in the
- * capture and `resolveExtractionStartIndex` switches to the newest echoed user
- * prompt. With no `contentEnd`, that backwards search started at the very bottom
- * of the pane and the first `›` it met was the COMPOSER. Extraction then began
- * on the row after it, i.e. on the status bar, and the saved "reply" for every
- * turn on a saturated pane was one row:
- *
- * ```text
- * gpt-6-astra xhigh · ~/share/work/github_kewton/CommandAgent-develop
- * ```
- *
- * Identical on every turn, so `isDuplicateResponse` then locked on it and the
- * pane could not record another reply at all. That is #1289's defect verbatim,
- * one tool later — the same reason `findCommandCodeChromeStart` exists.
- *
- * ## Why the attributes and not the placeholder text
- *
- * The codex branch of `findRecentUserPromptIndex` used to exclude the composer by
- * naming its placeholders (`Implement`, `Find and fix`, `Type`, `Summarize`).
- * Those are codex 0.1x wording, and 0.15x draws `Ask Codex to do anything`, so
- * the list silently stopped matching the thing it was written for. Issue #2310
- * measured what actually separates codex's three uses of `›` (U+203A), and it is
- * the SGR attributes, not the text: the composer glyph is bold (`ESC[1m›`), a
- * transcript echo is dim (`ESC[1;2m›`), a dialog option carries a bold label or
- * a label drawn in the glyph's own colour (one span — since #2798 a coloured
- * glyph alone is not enough, because 0.155.1 colours the composer's glyph too).
- * {@link readCodexGlyphRowKind} is that measurement, and this reader is one of
- * its callers.
- *
- * `-1` is returned for a frame whose bottom-most `›` is an option row: codex
- * replaces the composer with the dialog, so there is no chrome to trim and the
- * caller resolves the frame on the prompt path instead.
- *
- * ## The stripped-capture fallback
- *
- * Auto-Yes hands the detection layer a capture that has already been through
- * `stripAnsi`, and there every `›` is the same byte — {@link
- * readCodexGlyphRowKind} answers `null` on purpose rather than guessing. This
- * reader still has to answer for those frames, so it falls back to the one
- * structural landmark codex pins BELOW the composer and nowhere else: the status
- * bar ({@link CODEX_STATUS_BAR_PATTERN}, `model · /path`). Requiring it means a
- * frame with no bar — a pane mid-redraw, an overlay — yields `-1` and the
- * pre-#2400 reading, which is the direction that costs nothing.
- *
- * @param lines - Captured pane lines, ANSI-bearing or not; trailing blanks tolerated
- * @returns Index of the composer row, or -1 when no composer chrome is present
- */
-function findCodexChromeStart(lines) {
-    let lastRow = lines.length - 1;
-    while (lastRow >= 0 && (0, ansi_1.stripAnsi)(lines[lastRow]).trim() === '')
-        lastRow--;
-    if (lastRow < 0)
-        return -1;
-    // Bottom-most `›` row within the band codex reserves for its chrome. Anything
-    // further up is transcript, and latching onto an echo there would cut the
-    // reply this whole reader exists to keep.
-    let glyphRow = -1;
-    for (let i = lastRow; i >= Math.max(0, lastRow - CODEX_CHROME_SEARCH_ROWS); i--) {
-        if (CODEX_CHROME_GLYPH_ROW_PATTERN.test((0, ansi_1.stripAnsi)(lines[i]))) {
-            glyphRow = i;
-            break;
-        }
-    }
-    if (glyphRow < 0)
-        return -1;
-    const kind = (0, cli_patterns_1.readCodexGlyphRowKind)(lines[glyphRow]);
-    if (kind === 'composer')
-        return glyphRow;
-    // A dialog is up (no composer drawn) or the bottom-most `›` is a transcript
-    // echo mid-redraw. Neither is chrome to trim.
-    if (kind !== null)
-        return -1;
-    // Stripped capture: no attributes to read. Accept the row as the composer only
-    // when codex's status bar is drawn below it, which is where it always sits and
-    // where a transcript echo can never be.
-    for (let i = glyphRow + 1; i <= lastRow; i++) {
-        if (exports.CODEX_STATUS_BAR_PATTERN.test((0, ansi_1.stripAnsi)(lines[i])))
-            return glyphRow;
-    }
-    return -1;
-}
-/**
- * The shape of a codex row that could be the echo of a message the user sent.
- *
- * Shape only — `›` at column 0 with text after it — which all three of codex's
- * `›` uses share. {@link findCodexUserEchoIndex} is what tells them apart.
- */
-exports.CODEX_USER_ECHO_PATTERN = /^›\s+\S/;
-/**
- * Find the newest transcript echo of an operator message in a codex capture.
- *
- * The reader `findRecentUserPromptIndex` anchors codex turns on (Issue #2400).
- * It replaces a negative lookahead over composer placeholder strings
- * (`(?!Implement|Find and fix|Type|Summarize)`) written against codex 0.1x:
- * 0.15x draws `Ask Codex to do anything`, so the guard matched nothing it was
- * written for. The composer became the newest "echo", and on a saturated pane —
- * the one path where this anchor decides where extraction STARTS (#1670) — the
- * reply saved for every turn was the single status-bar row below it.
- *
- * ## What the attributes can and cannot separate
- *
- * #2310 measured the three uses of `›` and this reader adds the fourth reading
- * they left open, captured for #2400 on codex-cli 0.153.4
- * (`tests/fixtures/codex-live-2310/turn-submitted-no-status.txt`): the echo of
- * a message the operator has JUST submitted is drawn `ESC[1m› ESC[0m<text>` —
- * bold glyph, plain label — and only becomes the dim `ESC[1;2m› ` of the
- * measured frames once the turn settles. That shape is indistinguishable from a
- * composer holding typed text, so no per-row attribute rule can separate them.
- *
- * What separates them is position, which codex's layout fixes: the composer is
- * the BOTTOM-MOST `›` row of a frame. So the reader takes the boundary from its
- * caller:
- *
- * - `composerTrimmed` — `findCodexChromeStart` located the chrome and `lines`
- *   has already been cut above it, so every `›` row left is transcript and the
- *   newest one wins outright.
- * - otherwise — the composer may still be the bottom-most `›` row, so the first
- *   candidate is stepped over. This is the structural spelling of the guard the
- *   placeholder list used to be, and unlike that list it cannot go stale.
- *
- * Dialog option rows are refused wherever they appear: codex renders inline, so
- * a dialog answered minutes ago is still in the scrollback with its options
- * intact (#1160), and anchoring on one would cut the reply mid-way.
- *
- * @param lines - Captured pane rows, ANSI intact where the caller has it
- * @param contentEnd - Exclusive end of the conversation region
- * @param windowSize - How many rows above `contentEnd` to search
- * @param composerTrimmed - Whether `contentEnd` already excludes the composer
- * @returns Index of the newest echo row, or -1 when none is in the window
- */
-function findCodexUserEchoIndex(lines, contentEnd, windowSize, composerTrimmed) {
-    let composerHandled = composerTrimmed;
-    for (let i = Math.min(contentEnd, lines.length) - 1; i >= Math.max(0, contentEnd - windowSize); i--) {
-        if (!exports.CODEX_USER_ECHO_PATTERN.test((0, ansi_1.stripAnsi)(lines[i])))
-            continue;
-        const kind = (0, cli_patterns_1.readCodexGlyphRowKind)(lines[i]);
-        // An option row of a dialog still sitting in the scrollback.
-        if (kind === 'option')
-            continue;
-        // Positively an echo: codex has settled the row and drawn its glyph dim.
-        if (kind === 'transcript-echo')
-            return i;
-        // `composer` (bold glyph) or `null` (an ANSI-stripped capture, where all
-        // three uses are one byte). Either could be the input box, and the input box
-        // is always the bottom-most `›` row.
-        if (!composerHandled) {
-            composerHandled = true;
-            continue;
-        }
-        return i;
-    }
-    return -1;
-}
-/**
- * Pasted text pattern
- *
- * Claude CLI displays this when it detects multi-line text paste in the
- * ink-based TextInput. The pattern matches the folded display format.
- *
- * @example "[Pasted text #1 +46 lines]"
- * @see Issue #212, #163
- * @designNote PASTE-001: Pattern matches the start of the indicator only.
- *   The line count (+XX lines) is variable, so we match the fixed prefix
- *   to minimize false negatives. False positive risk is low because
- *   "[Pasted text #" is a unique format generated by Claude CLI's ink renderer.
- * @designNote PASTE-001-FP (SF-S4-002): When used in skipPatterns,
- *   line-level matching could filter legitimate response lines if Claude's
- *   answer text happens to contain "[Pasted text #". This is unlikely and
- *   acceptable -- only the affected line would be lost.
- */
-exports.PASTED_TEXT_PATTERN = /\[Pasted text #\d+/;
-/**
- * Pasted text detection delay (milliseconds)
- *
- * Wait time after sendKeys for tmux buffer to reflect [Pasted text] display.
- *
- * @see Issue #212
- * @designNote PASTE-002: 500ms is the empirically measured time for
- *   Claude CLI's ink rendering to complete. capturePane({ startLine: -10 })
- *   reads only the last 10 lines since [Pasted text] appears in the most
- *   recent few lines.
- */
-exports.PASTED_TEXT_DETECT_DELAY = 500;
-/**
- * Pasted text detection max retries
- *
- * @see Issue #212
- * @designNote PASTE-003: 3 retries x 500ms = max 1500ms additional delay.
- *   Typically resolves on the first attempt (+500ms).
- */
-exports.MAX_PASTED_TEXT_RETRIES = 3;
-/**
- * Gemini interactive REPL prompt pattern
- * Gemini CLI shows a `>` or `❯` prompt when waiting for user input in interactive mode.
- *
- * Two branches (Issue #386):
- * - Branch 1: `^[>❯]\s*$` -- bare prompt character (empty input line)
- * - Branch 2: `^\s*[>❯]\s+Type your message.*$` -- new-format prompt with placeholder text
- *   (e.g., " >   Type your message or @path/to/file"). Leading whitespace is allowed
- *   because tmux capture-pane output may include padding.
- *
- * Branch 2 requires "Type your message" after the indicator to avoid false positives
- * on quoted response lines (e.g., "> some quoted text").
- *
- * @see CLAUDE_PROMPT_PATTERN for similar dual-format matching approach
- */
-// [S4-5] /g flag prohibited: would make test() stateful
-exports.GEMINI_PROMPT_PATTERN = /^[>❯]\s*$|^\s*[>❯]\s+Type your message.*$/m;
-/**
- * Gemini thinking/processing pattern
- * Gemini CLI shows braille spinner characters and status text while processing.
- */
-exports.GEMINI_THINKING_PATTERN = /[\u2800-\u28FF]|Thinking\.\.\./;
-/**
- * OpenCode prompt pattern (Issue #379)
- * OpenCode TUI shows "Ask anything..." in the input area when waiting for user input.
- * Unlike Claude/Codex (which use > or ❯), OpenCode uses a text-based prompt indicator.
- */
-exports.OPENCODE_PROMPT_PATTERN = /Ask anything(?:\.\.\.|\u2026)/;
-/**
- * OpenCode idle composer pattern (Issue #1883).
- *
- * The `Ask anything...` placeholder as opencode actually draws it: **inside the
- * input box**, behind the box's own gutter (`\u2503`, or `\u2502` on a lighter
- * border style). Two measured facts make that row positive evidence that the
- * composer is empty, rather than the mere absence of a busy marker (design
- * principle D1 in `docs/design/multi-agent-state-architecture.md`):
- *
- * - opencode paints the placeholder **only while the input buffer is empty**.
- *   The first typed character replaces the whole row — measured live on
- *   opencode 1.18.20, pane 80x200 (`opencode-live-1883/composer-residual.txt`
- *   holds `\u2503  echo PREFILLED` where the idle frame holds the placeholder).
- * - the gutter says the row belongs to the input box. `Ask anything...` printed
- *   in a response body has no gutter, and reading that as an idle composer is
- *   the "the phrase is on screen somewhere" inference D1 forbids.
- *
- * **Match this against the ANSI-stripped frame BEFORE {@link stripBoxDrawing}**,
- * which strips the very gutter this pattern anchors on.
- *
- * The whitespace runs are `[^\S\n]` (horizontal only) on purpose: plain `\s`
- * crosses newlines under the `m` flag, which let the gutter of one row pair up
- * with the phrase several rows below it and matched frames that hold no
- * composer at all (measured on `phrase-in-response.txt`).
- *
- * {@link OPENCODE_PROMPT_PATTERN} stays as it is: `response-checker` and
- * `OPENCODE_SKIP_PATTERNS` want the bare phrase wherever it lands, because they
- * are deleting the row from an extracted response, not judging a session.
- *
- * opencode 1.18.31 以降は見本文を U+2026（`…`）で描く。ASCII の `...` も実行ファイルに
- * 残っているので両方を受け付ける（Issue #2915、2026-09-28 に実行ファイルから確認）。
- */
-exports.OPENCODE_IDLE_COMPOSER_PATTERN = /^[^\S\n]*[\u2502\u2503][^\S\n]*Ask anything(?:\.\.\.|\u2026)/m;
-/**
- * OpenCode prompt pattern after response completion (Issue #379)
- * Shows "tab agents  ctrl+p commands" in the TUI status bar after a response finishes.
- * Used as extraction stop condition in response-poller.ts [D2-003].
- */
-exports.OPENCODE_PROMPT_AFTER_RESPONSE = /tab agents\s+ctrl\+p commands/;
-/**
- * OpenCode thinking/processing pattern (Issue #379)
- * OpenCode TUI shows "Thinking:" prefix while the Ollama model is generating a response.
- * Used by detectThinking() to determine if the tool is actively processing.
- */
-exports.OPENCODE_THINKING_PATTERN = /Thinking:/;
-/**
- * OpenCode loading indicator pattern (Issue #379)
- * Shows a series of 4+ filled square characters (U+2B1D) during initial loading/model warm-up.
- * Filtered from response extraction via OPENCODE_SKIP_PATTERNS.
- */
-exports.OPENCODE_LOADING_PATTERN = /\u2B1D{4,}/;
-/**
- * OpenCode's Build summary LINE, in either of the two forms it is drawn in
- * (Issue #379, corrected by Issue #1893).
- *
- * **This is a line filter, not completion evidence.** It matches
- * `▣ <Action> · <model>` with the duration OPTIONAL, and opencode 1.18 draws
- * that duration-less form on a step that is still in flight -- so a frame this
- * pattern matches may be mid-turn, waiting on a permission dialog, or aborted.
- * Use {@link OPENCODE_TURN_COMPLETE_PATTERN} to decide that a turn has finished.
- *
- * The docstring that stood here until #1893 claimed the opposite ("short
- * responses may omit the timing portion"). Measured against opencode 1.18.21 at
- * the production 80x200 geometry, that is wrong in both directions:
- *
- * - a 2.3-second answer still carries its duration
- *   (`▣  Build · GPT-5.6 Luna · 2.3s`, `opencode-live-1893/turn-complete-short.txt`),
- *   so no completed turn needs the duration-less branch;
- * - the duration-less form is what opencode leaves on screen while a tool call
- *   waits for permission and after a rejected one
- *   (`opencode-live-1893/permission-bash.txt`, `…/turn-aborted-no-duration.txt`).
- *
- * Kept loose because three callers want the LINE rather than the verdict:
- * `tui-accumulator.ts`, `response-cleaner.ts` and `polling/response-checker.ts`
- * all use it to drop the summary row from an extracted response, and the
- * mid-step row has to be dropped too. #1911 removed the one caller that used it
- * as a turn BOUNDARY rather than a line filter (the "second-to-last ▣" anchor,
- * replaced by {@link findOpenCodeUserEchoEnd}); the name is left alone because
- * the remaining three callers all want the line.
- */
-exports.OPENCODE_RESPONSE_COMPLETE = /\u25A3\s+\w+\s+·\s+\S+(?:\s+·\s+(?:[\d]+h\s*)?(?:[\d]+m\s*)?[\d.]+s)?/;
-/**
- * OpenCode's finished-turn marker: the Build summary line WITH its duration
- * (Issue #1893).
- *
- * `▣  Build · GPT-5.6 Luna · 5.2s`. This is the one tool-specific completion
- * marker design rule D1 recognises today
- * (`docs/design/multi-agent-state-architecture.md` §4 D1 decision 1, item 1),
- * and the duration is the whole of what makes it positive evidence: opencode
- * prints the same row without a duration while a step is still open, which is
- * how a session parked on a permission dialog was published as
- * `ready`/`opencode_response_complete` (#1893) and how `isOpenCodeComplete`
- * saved the dialog body as if it were an answer.
- *
- * The model segment is `[^·\n]+` rather than `\S+` because real model names
- * carry spaces (`GPT-5.6 Luna`): with `\S+` the optional-duration group of
- * {@link OPENCODE_RESPONSE_COMPLETE} could never reach the duration on a
- * two-word model, so "with duration" and "without duration" were the same match
- * there. Excluding the middle dot rather than allowing anything keeps the
- * quantifier unable to swallow its own delimiter (no nested/ambiguous
- * quantifier -- ReDoS safe), and `.`/`[^·\n]` never cross a line without the
- * `m` flag, so the duration has to be on the marker's own row.
- *
- * Durations observed: `2.3s`, `5.2s`, `45.2s`; the `Nh`/`Nm` prefixes are
- * inherited from the #379 pattern and kept for long turns.
- */
-exports.OPENCODE_TURN_COMPLETE_PATTERN = /\u25A3\s+\w+\s+·\s+[^·\n]+·\s+(?:\d+h\s*)?(?:\d+m\s*)?[\d.]+s/;
-/**
- * OpenCode's permission dialog, anchored on its button row (Issue #1893).
- *
- * opencode 1.18 asks for tool permission with a bottom-anchored box whose last
- * interactive row is a horizontal button strip:
- *
- * ```
- *   ┃  △   Permission required
- *   ┃    # Shell command
- *   ┃  $ ls -la
- *   ┃   Allow once   Allow always   Reject  ctrl+f fullscreen  ⇆ select  enter con
- * ```
- *
- * Nothing in the detection layer saw it before #1893: it carries no number, no
- * `(y/n)`, and no "press enter to confirm" footer, so `detectPrompt` answers
- * `isPrompt: false` and the status detector fell through to the Build marker
- * above it. The row is matched as POSITIVE evidence that a decision is pending
- * (design rule D1) -- it is the affordance itself, not the absence of a busy
- * marker.
- *
- * **Match this against the ANSI-stripped frame BEFORE {@link stripBoxDrawing}**,
- * exactly like {@link OPENCODE_IDLE_COMPOSER_PATTERN}: the leading `┃` (or
- * `│` on a lighter border style) is what says the row belongs to the dialog box
- * rather than to a response body that happens to quote the labels -- the
- * "the phrase is on screen somewhere" inference #1883 had to remove.
- *
- * Deliberately NOT anchored on:
- *
- * - `enter confirm`, which is truncated to `enter con` at opencode's own 80
- *   column layout (measured);
- * - `△ Permission required` alone, which is a heading rather than an
- *   affordance and survives in the fullscreen (`ctrl+f`) view whose key handling
- *   was not measured.
- *
- * The three labels are the same for the `bash` and the `edit` dialog (measured:
- * `permission-bash.txt`, `permission-edit.txt`), and the strip is repainted away
- * the moment the dialog is answered, so a matched row is never scrollback
- * (`turn-aborted-no-duration.txt` holds no `Allow once`).
- *
- * The whitespace runs are `[^\S\n]` (horizontal only) for the reason #1883
- * documents: plain `\s` crosses newlines under the `m` flag and would pair a
- * gutter on one row with labels several rows below it.
- */
-exports.OPENCODE_PERMISSION_PATTERN = /^[^\S\n]*[\u2502\u2503][^\S\n]*Allow once[^\S\n]+Allow always[^\S\n]+Reject\b/m;
-/**
- * OpenCode's busy footer, in BOTH of the spellings it is drawn in (Issue #379,
- * widened by Issue #1894).
- *
- * opencode 1.18 needs Escape TWICE to abort a turn, and the first press does not
- * abort anything -- it re-labels the footer:
- *
- * ```
- *    ⬝⬝⬝⬝⬝⬝⬝⬝  esc interrupt           6.5K (1%) · $0.00  ctrl+p commands
- *    ⬝■■■■■■⬝  esc again to interrupt  7.2K (1%) · $0.00  ctrl+p commands
- * ```
- *
- * Measured on opencode 1.18.21 at the production 80x200 geometry, sampling the
- * footer every ~360 ms after a single Escape: the second spelling is up from
- * 0.31 s to 4.71 s and the row is back to `esc interrupt` at 5.07 s -- a
- * five-second window, exactly as long as the second-press deadline
- * ({@link OPENCODE_INTERRUPT_SECOND_ESCAPE_DELAY_MS} is sized against it). The
- * generation continues throughout; the turn ran to a natural
- * `▣  Build · GPT-5.6 Luna · 11.3s`, 3 runs out of 3.
- *
- * Before #1894 those five seconds matched nothing at all: `detectSessionStatus`
- * lost branch A and fell through to `running`/`default` while the frame was
- * fresh, and to `ready`/`no_recent_output` once the poller's
- * `lastOutputTimestamp` aged past `STALE_OUTPUT_THRESHOLD_MS` -- both of them
- * `statusEvidence: 'none'`, i.e. a generating session
- * published with no evidence and, on the second path, as FINISHED. That is the
- * "vocabulary changed, so `ready` came back" failure design rule D1 names
- * (`docs/design/multi-agent-state-architecture.md` §4 D1, row #1894), and the
- * row is the same positive busy evidence in either spelling.
- *
- * The optional group is `(?:again to )?` rather than a looser `.*` on purpose:
- * it matches the two measured strings and nothing between an `esc` and an
- * `interrupt` several words apart. Linear, no nested quantifiers -- ReDoS safe.
- *
- * Filtered from response extraction via OPENCODE_SKIP_PATTERNS, which shares
- * this constant: the widened row is dropped from a saved answer for the same
- * reason the narrow one was.
- */
-exports.OPENCODE_PROCESSING_INDICATOR = /esc (?:again to )?interrupt/;
-/**
- * OpenCode's composer bottom border: `  ╹▀▀▀▀▀▀…` (Issue #1911).
- *
- * `╹` (heavy up) is the corner opencode joins the input box's `┃`
- * gutter to, and the `▀` run is the box's bottom edge. It is the one row of
- * the bottom-anchored chrome that can never appear inside a response body, which
- * makes it the anchor {@link findOpenCodeChromeStart} walks up from.
- */
-exports.OPENCODE_COMPOSER_BOTTOM_BORDER = /^[^\S\n]*╹▀{4,}/;
-/**
- * A row that belongs to one of opencode's boxes, matched by its own gutter
- * (Issue #1911).
- *
- * opencode draws three different boxes with the same `┃` gutter (`│`
- * on a lighter border style): the echoed USER PROMPT in the transcript, the
- * COMPOSER pinned to the bottom of the pane, and the PERMISSION DIALOG that
- * replaces the composer. Which one a matched row belongs to is decided by where
- * it sits, not by what it says — see {@link findOpenCodeChromeStart} and
- * {@link findOpenCodeUserEchoEnd}.
- *
- * **Match against the ANSI-stripped frame BEFORE {@link stripBoxDrawing}**,
- * which removes the very gutter this anchors on.
- */
-exports.OPENCODE_GUTTER_ROW_PATTERN = /^[^\S\n]*[│┃]/;
-/**
- * An echoed user prompt row: a gutter row that carries text (Issue #1911).
- *
- * The echo block opencode draws for a submitted message is a blank gutter row,
- * one or more gutter rows holding the message, and another blank gutter row.
- * This matches the middle ones.
- */
-exports.OPENCODE_USER_ECHO_PATTERN = /^[^\S\n]*[│┃][^\S\n]*\S/;
-/**
- * The status cell of opencode's bottom footer (Issue #1911).
- *
- * Measured at the production 80x200 geometry the footer reads
- * `<cwd>    6.4K (1%) · $ctrl+p` / `commands` while idle and
- * `⬝⬝⬝⬝⬝⬝⬝⬝  esc interrupt   6.3K (1%) · $0.00  ctrl+p commands` while running:
- * a context-usage cell followed by the cost sigil. Neither
- * {@link OPENCODE_PROMPT_AFTER_RESPONSE} (`tab agents  ctrl+p commands`, which
- * opencode only prints on the FIRST idle frame, before any turn has run) nor
- * {@link OPENCODE_PROCESSING_INDICATOR} covers the idle form, so this row used
- * to be saved as part of the assistant's reply.
- *
- * This is a SECONDARY net. The cwd that shares the row wraps over up to three
- * further rows that carry no signature at all, so the footer is removed
- * structurally by {@link findOpenCodeChromeStart}; this pattern only catches the
- * signed row when that boundary is not available (e.g. a caller holding a
- * fragment rather than a whole pane).
- *
- * Linear, no nested quantifiers — ReDoS safe.
- */
-exports.OPENCODE_FOOTER_STATUS_PATTERN = /\d+(?:\.\d+)?[KMGT]?\s+\(\d+%\)\s+·\s+\$/;
-/**
- * Locate the start of opencode's bottom-anchored chrome within a captured pane
- * (Issue #1911).
- *
- * opencode runs in the alternate screen and reserves the last rows of the pane
- * for chrome that is never transcript content:
- *
- * ```
- *   ┃                              ← composer box (blank rows + model row),
- *   ┃  Build · GPT-5.6 Luna …        or the permission dialog that replaces it
- *   ╹▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀   ← composer bottom border
- *   /private/tmp/…-share-    6.4K (1%) · $ctrl+p   ← footer, cwd wrapped
- *   work-github-kewton-…                 commands     over up to three rows
- * ```
- *
- * Everything from the returned index down is chrome. This is the opencode twin
- * of {@link findClaudeChromeStart} and exists for the same reason (#1289): the
- * footer's cwd rows and the composer's model row were reaching saved responses,
- * which is defect 1 of #1911.
- *
- * Found structurally rather than by matching footer text, because the footer's
- * text is opencode's to change and two of its four rows (the cwd continuations)
- * are an arbitrary filesystem path with no signature at all.
- *
- * @param lines - Captured pane lines, ANSI-stripped, box drawing intact.
- *   Trailing blank rows are tolerated.
- * @returns Index of the first chrome row, or -1 when no chrome is recognisable.
- */
-function findOpenCodeChromeStart(lines) {
-    let last = lines.length - 1;
-    while (last >= 0 && lines[last].trim() === '')
-        last--;
-    if (last < 0)
-        return -1;
-    const walkUpGutter = (from) => {
-        let top = from;
-        while (top - 1 >= 0 && exports.OPENCODE_GUTTER_ROW_PATTERN.test(lines[top - 1]))
-            top--;
-        return top;
-    };
-    // The composer's bottom border. Searched from the last row upwards over the
-    // WHOLE pane rather than over the few rows the footer occupies: on the boot
-    // screen opencode centres the composer under its banner (row ~99 of 200) while
-    // the footer stays pinned to the bottom, so a window sized for the footer
-    // misses the border entirely (measured, `opencode-live-1883/boot-idle.txt`).
-    for (let i = last; i >= 0; i--) {
-        if (exports.OPENCODE_COMPOSER_BOTTOM_BORDER.test(lines[i])) {
-            return walkUpGutter(i);
-        }
-    }
-    // No border: the permission dialog draws over the composer and its own box
-    // runs to the last row of the pane (measured, `opencode-live-1893/permission-*.txt`).
-    if (exports.OPENCODE_GUTTER_ROW_PATTERN.test(lines[last])) {
-        return walkUpGutter(last);
-    }
-    return -1;
-}
-/**
- * Locate the last row of the NEWEST echoed user prompt in a captured pane
- * (Issue #1911).
- *
- * The turn currently being answered starts on the row after this one, so it is
- * both the extraction anchor (`resolveExtractionStartIndex`'s opencode branch)
- * and the floor the finished-turn marker has to sit below before a frame counts
- * as a completed turn (`isOpenCodeComplete`).
- *
- * Before #1911 the anchor was "the second-to-last `▣ Build` row", which has two
- * measured failure modes: on the first turn of a session there is no second row,
- * so extraction fell back to line 0 and saved the whole pane; and the row it
- * anchors on belongs to the PREVIOUS turn, so the echoed prompt of the current
- * one was always included in the reply.
- *
- * @param lines - Captured pane lines, ANSI-stripped, box drawing intact.
- * @param chromeStart - Result of {@link findOpenCodeChromeStart}; the search
- *   stops above it so the composer's and the permission dialog's own gutter rows
- *   are never read as an echoed prompt. Pass -1 when no chrome was found.
- * @returns Index of the echo block's last row, or -1 when no echo is on screen
- *   (a turn whose head has scrolled out of the alternate-screen pane).
- */
-function findOpenCodeUserEchoEnd(lines, chromeStart) {
-    const limit = chromeStart >= 0 ? chromeStart : lines.length;
-    for (let i = limit - 1; i >= 0; i--) {
-        if (!exports.OPENCODE_USER_ECHO_PATTERN.test(lines[i]))
-            continue;
-        // The block's trailing blank gutter row(s) belong to the echo, not to the reply.
-        let end = i;
-        while (end + 1 < limit && exports.OPENCODE_GUTTER_ROW_PATTERN.test(lines[end + 1]))
-            end++;
-        return end;
-    }
-    return -1;
-}
-/**
- * The rows of opencode's composer that hold the INPUT BUFFER (Issue #1906).
- *
- * opencode has no prompt marker — no `>` / `❯` / `›` anywhere near its input —
- * so "is the message still sitting in the composer?" cannot be asked the way it
- * is asked of every other TUI. What opencode has instead is a box, and the box
- * has a fixed shape, measured at the production 80x200 geometry across every
- * frame in `opencode-live-1883/`, `opencode-live-1893/` and
- * `opencode-live-1906/`:
- *
- * ```
- *   ┃                                     ← buffer rows: blank when empty,
- *   ┃  Review the send path.                one row per (wrapped) line of the
- *   ┃  Check newline handling.              typed message, or the
- *   ┃  Report findings.                     `Ask anything...` placeholder on a
- *   ┃                                       session that has not answered yet
- *   ┃  Build · GPT-5.6 Luna GitHub Copilot ← the agent/model row, ALWAYS last
- *   ╹▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀ ← the box's bottom border
- * ```
- *
- * The agent/model row is what makes a naive "any guttered row with text" read
- * wrong: it always carries text, so the composer would never look empty. It is
- * identified structurally — the last gutter row before the border — rather than
- * by matching `Build ·` or a model name, both of which are opencode's to change
- * and neither of which is stable across agents (`Build`, `Plan`, a custom agent).
- *
- * Anchored on the border, not on the bottom of the pane, because opencode
- * centres the whole box under its banner before the first turn (row ~100 of 200)
- * and only pins it to the bottom afterwards — see {@link findOpenCodeChromeStart},
- * whose upward walk this shares.
- *
- * Returns `null` when no composer is on screen at all. That is the permission
- * dialog (it replaces the composer and draws no bottom border — measured,
- * `opencode-live-1893/permission-*.txt`), a full-screen overlay, or a session
- * still starting.
- *
- * @param lines - Captured pane lines, ANSI-stripped, box drawing intact. Must be
- *   the WHOLE pane: a tail window sized for the other tools does not contain the
- *   box on a pre-first-turn frame.
- * @returns The buffer rows with their gutters intact, or `null` when the
- *   composer is not on screen. An empty array means a box with no buffer row,
- *   which no measured frame produces.
- */
-function findOpenCodeComposerRows(lines) {
-    let border = -1;
-    for (let i = lines.length - 1; i >= 0; i--) {
-        if (exports.OPENCODE_COMPOSER_BOTTOM_BORDER.test(lines[i])) {
-            border = i;
-            break;
-        }
-    }
-    if (border < 0)
-        return null;
-    let top = border;
-    while (top - 1 >= 0 && exports.OPENCODE_GUTTER_ROW_PATTERN.test(lines[top - 1]))
-        top--;
-    // `top .. border - 1` are the box's gutter rows; the last of them is the
-    // agent/model row, which belongs to the chrome rather than to the buffer.
-    const modelRow = border - 1;
-    if (modelRow < top)
-        return null;
-    return lines.slice(top, modelRow);
-}
-/**
- * A composer row with its gutter (and the padding either side) removed
- * (Issue #1906). Blank for an empty buffer row.
- */
-function stripOpenCodeGutter(row) {
-    return row.replace(exports.OPENCODE_GUTTER_ROW_PATTERN, '').trim();
-}
-/**
- * OpenCode TUI selection list pattern (Issue #473, narrowed by Issue #1896).
- *
- * Detects the fuzzy-search picker overlay opencode draws for `/models`,
- * `/providers` and `/connect`, anchored on its HEADER ROW COMPLETE WITH the
- * right-aligned `esc` hatch:
- *
- * ```
- *               Select model                                     esc
- *
- *               Search
- *
- *               Recent
- *             ● GPT-5.6 Luna GitHub Copilot
- * ```
- *
- * The `esc` is the picker's own dismiss affordance -- positive evidence that an
- * overlay is open (design rule D1), rather than the presence of two English
- * words somewhere on the pane. Until #1896 the pattern was the bare phrase, and
- * `status-detector.ts` tests it against the WHOLE content area (up to ~200 rows,
- * because the header can sit far above the last row when the list is long), so
- * an agent that merely wrote `Select model to continue:` in its answer parked the
- * session on `waiting` / `opencode_selection_list` for the rest of the session
- * -- measured live on opencode 1.18.21,
- * `opencode-live-1896/select-model-in-response.txt`.
- *
- * Requiring two or more spaces before `esc` is what separates the header row
- * from prose: the picker right-aligns the hatch across the overlay's width
- * (37 spaces in the measured frame), while a sentence that happens to end in
- * "esc" would not.
- *
- * NOT additionally anchored on the `Search` row below the header: its distance
- * from the header is unmeasured for the `Connect a provider` variant (that
- * overlay needs an unconfigured provider to open, which the live probe could not
- * produce without touching the operator's real credentials), and the header's
- * own hatch is already the affordance.
- *
- * The header allowlist is deliberately unchanged, and Issue #2112 kept it that
- * way rather than adding the five headings it found missing (`Select agent`,
- * `Sessions`, `Timeline`, `Commands`, and the palette's). #1896 left the
- * question as "a separate change with its own live frames"; #2046 supplied the
- * frames and the answer they gave is that a WIDER WORD LIST is the wrong shape.
- * Three of those dialogs published `ready` / `opencode_response_complete` — the
- * marker of the previous turn, still on the pane behind the overlay — so the
- * damage was a false COMPLETION, not a missing NavigationButtons row, and no
- * heading added here would have changed that ordering. The fix is a gate ahead
- * of the completion branch that reads the overlay's LAYOUT
- * (`lib/detection/opencode-modal-overlay.ts`, branch C2 of
- * `tools/opencode/detect.ts`), which is also what keeps the prose false
- * positives this pattern was narrowed for from coming back through a longer
- * list.
- *
- * This pattern still runs, and still first: it is the reading that survives ANSI
- * stripping, where the layout rule cannot see anything at all.
- *
- * The whitespace runs are `[^\S\n]` (horizontal only) for the reason Issue #1883
- * documents: plain `\s` crosses newlines under the `m` flag, which would let a
- * header on one row pair up with an `esc` several rows below it.
- *
- * Linear pattern, no nested quantifiers -- ReDoS safe (S4-001).
- */
-exports.OPENCODE_SELECTION_LIST_PATTERN = /^[^\S\n]*(?:Select[^\S\n]+(?:model|provider)|Connect[^\S\n]+a[^\S\n]+provider)[^\S\n]{2,}esc[^\S\n]*$/m;
-/**
- * [Issue #1495] Footer signature of Claude Code's `/model` local-settings overlay.
- * Verified against a real Claude Code v2.1.218 capture, the footer reads:
- *   "Enter to set as default · s to use this session only · Esc to cancel"
- *
- * The overlay renders a ❯-marked numbered model list ("1. Default … 5. Haiku")
- * under a "Select model" header that detectMultipleChoicePrompt() otherwise
- * matches as a genuine multiple_choice prompt — which let Auto-Yes Enter-confirm
- * a selection and silently change the user's default model. This "set as default"
- * phrasing is unique to the model picker: genuine confirmation prompts never
- * contain it (the trust dialog uses "Enter to confirm · Esc to cancel", Bash-tool
- * approvals use "Esc to cancel · Tab to amend", AskUserQuestion uses
- * "Enter to select · … to navigate"), so it is a safe exclusion signal.
- *
- * Linear pattern, no nested quantifiers — ReDoS safe (S4-001).
- */
-exports.CLAUDE_MODEL_OVERLAY_FOOTER_PATTERN = /Enter\s+to\s+set\s+as\s+default\b/i;
-/**
- * Claude CLI selection list footer pattern
- * Detects Claude CLI's interactive selection prompts that require
- * arrow key navigation and Enter to select/toggle.
- *
- * Matches footer instruction lines (known variants):
- *   "Enter to select · Tab/Arrow keys to navigate · Esc to cancel"
- *   "Enter to select · ↑/↓ to navigate · n to add notes · Esc to cancel"
- *   "Enter to confirm · Esc to exit"  (legacy /model command footer)
- *   "Enter to set as default · s to use this session only · Esc to cancel"
- *     (/model command footer as of Claude Code v2.1.218 — Issue #1495)
- *
- *   "←/→ to adjust · Enter to confirm · s for this session only · Esc to cancel"
- *     (/effort slider footer as of Claude Code v2.1.257 — Issue #3052; before
- *      2.1.257 it was "Enter to confirm · Esc to cancel")
- *
- * The /effort branch keys on "Enter to confirm · s for this session only" rather
- * than "←/→ to adjust": the `s` hint is unique to the pickers (the trust dialog's
- * "Enter to confirm · Esc to cancel" and approval dialogs never carry it), and
- * keeping the match under the `Enter to` prefix leaves the pattern a single
- * linear alternation. Linear, no nested quantifiers — ReDoS safe.
- *
- * The "set as default" branch lets status-detector classify the `/model` overlay
- * as a Claude selection list (NavigationButtons + ESC hatch, hasActivePrompt=false)
- * once detectPrompt() no longer reports it as a prompt (see
- * CLAUDE_MODEL_OVERLAY_FOOTER_PATTERN).
- */
-exports.CLAUDE_SELECTION_LIST_FOOTER = /Enter\s+to\s+(?:select\s+.*to\s+navigate|confirm\s+·\s+(?:Esc|s\s+for\s+this\s+session\s+only)|set\s+as\s+default)/;
-/**
- * OpenCode TUI separator pattern (Issue #379)
- * Matches lines composed entirely of box-drawing / TUI decoration characters.
- * Covers: vertical lines (U+2503), box corners, horizontal lines, and other TUI elements.
- */
-exports.OPENCODE_SEPARATOR_PATTERN = /^[\u2503\u2579\u25A3\u2580\u2500\u250C\u2510\u2514\u2518\u251C\u2524\u252C\u2534\u253C]+$/;
-/**
- * OpenCode skip patterns for response cleaning (Issue #379)
- * Lines matching any of these patterns are filtered from extracted responses.
- * Includes: TUI separators, loading indicators, Build summary prefix,
- * status bar prompts, processing indicators, input prompt, the footer's
- * context/cost status cell (Issue #1911), and pasted text markers.
- */
-exports.OPENCODE_SKIP_PATTERNS = [
-    exports.OPENCODE_SEPARATOR_PATTERN,
-    exports.OPENCODE_LOADING_PATTERN,
-    /^Build\s+/,
-    exports.OPENCODE_PROMPT_AFTER_RESPONSE,
-    exports.OPENCODE_PROCESSING_INDICATOR,
-    exports.OPENCODE_PROMPT_PATTERN,
-    exports.OPENCODE_FOOTER_STATUS_PATTERN,
-    exports.PASTED_TEXT_PATTERN,
-];
-// =============================================================================
-// OpenCode V2 (`opencode2`, Issue #2934)
-// =============================================================================
-//
-// A separate tool id from `opencode` (Epic #2370, decision 1). Its TUI is drawn
-// by the same toolkit and many rows look alike, but v1's constants are v1's:
-// they are left exactly as they are, and v2 names its own here so a change on
-// either side cannot move the other. Phase 1 reads only what the send path and
-// the fallback status reader need; the approval dialog (`Always allow`, the
-// reverse of v1's `Allow always`), the completion row and the session tabs are
-// Phase 3's.
-/**
- * OpenCode V2's empty composer: the input box's `┃` gutter with the
- * `Ask anything…` placeholder on the same row (2.0.18 draws U+2026; the ASCII
- * `...` is accepted too, as for v1 since #2915).
- *
- * Measured on 2.0.18 at 80x200 (2026-09-28):
- * `   ┃  Ask anything… "Fix broken tests"`. Match against the ANSI-stripped
- * frame BEFORE `stripBoxDrawing`, which removes the gutter this anchors on.
- */
-exports.OPENCODE_V2_IDLE_COMPOSER_PATTERN = /^[^\S\n]*[\u2502\u2503][^\S\n]*Ask anything(?:\.\.\.|\u2026)/m;
-/**
- * OpenCode V2's footer, which ends in `ctrl+p commands` on every frame the
- * TUI draws (before a turn: `<path>:<branch>  shift+tab agents  ctrl+p commands`;
- * after one: `<path>:<branch>  8.8K (1%)  ctrl+p commands`, 2.0.18).
- *
- * Proof that the TUI — and so its composer — is on screen, NOT that it is idle:
- * a running turn keeps the footer.
- */
-exports.OPENCODE_V2_FOOTER_PATTERN = /ctrl\+p commands/;
-/**
- * OpenCode V2 working indicator: the footer's `esc interrupt` hint, drawn only
- * while a turn is running (2.0.18).
- */
-exports.OPENCODE_V2_THINKING_PATTERN = /esc interrupt/;
-/**
- * Whether OpenCode V2's composer is on screen, so a send may type into it
- * (Issue #2934, D6): the gutter-anchored placeholder, or the footer.
- *
- * @param text - ANSI-stripped capture, box drawing intact
- */
-function isOpencodeV2ComposerVisible(text) {
-    return exports.OPENCODE_V2_IDLE_COMPOSER_PATTERN.test(text) || exports.OPENCODE_V2_FOOTER_PATTERN.test(text);
-}
 /**
  * The OpenCode V2 dialog title row and its reader (Issue #2971) live in a
  * browser-safe leaf since Issue #2983, because the chat surface's dialog card
@@ -1645,1192 +163,219 @@ function isOpencodeV2ComposerVisible(text) {
 var dialog_title_1 = require("./tools/opencode-v2/dialog-title");
 Object.defineProperty(exports, "OPENCODE_V2_DIALOG_TITLE_PATTERN", { enumerable: true, get: function () { return dialog_title_1.OPENCODE_V2_DIALOG_TITLE_PATTERN; } });
 Object.defineProperty(exports, "findOpencodeV2DialogTitle", { enumerable: true, get: function () { return dialog_title_1.findOpencodeV2DialogTitle; } });
-/** OpenCode V2 rows that are chrome, never reply content. */
-exports.OPENCODE_V2_SKIP_PATTERNS = [
-    exports.OPENCODE_SEPARATOR_PATTERN,
-    exports.OPENCODE_V2_FOOTER_PATTERN,
-    exports.OPENCODE_V2_THINKING_PATTERN,
-    /Ask anything(?:\.\.\.|\u2026)/,
-    /^Build\s+·/,
-    exports.PASTED_TEXT_PATTERN,
-];
-/**
- * Copilot prompt pattern (Issue #545)
- * Copilot CLI shows "❯" followed by cursor/text hint:
- *   - "❯ [7m [0mType @ to mention files, # for issues/PRs, / for commands, or ? for"
- *   - "❯ " (bare prompt)
- * Also matches "? " prefix for question prompts.
- */
-exports.COPILOT_PROMPT_PATTERN = /^[>❯]\s|^\?\s+/m;
-/**
- * Copilot thinking/processing pattern (Issue #545)
- * Copilot CLI shows various action indicators during processing:
- *   - "Exploring repo (Esc to cancel · 2.3 KiB)"
- *   - "Reasoning ■■■ medium"
- *   - "... Thinking"
- *   - Tool use: "● Read package.json" / "◉ Mapping structure (Esc to cancel · 8.4 KiB)"
- * Note: "Esc to cancel" alone is not used because trust dialog footer also contains it.
- * Instead, match the action pattern with parenthesized context: "(Esc to cancel ·"
- * Braille spinner characters (U+2800-U+28FF) are also checked.
- *
- * Issue #1897: the bare words `Generating` and `Processing` were dropped. This
- * constant is also a member of {@link COPILOT_SKIP_PATTERNS}, so every
- * alternative here doubles as a "delete this line from the saved response" rule
- * and as the tail-window liveness test in `extractResponse`. Those two words are
- * ordinary English -- a reply whose last line reads "Processing complete." had
- * the line deleted AND pinned the turn to "still thinking" for as long as it was
- * on screen, so the response was never saved at all. The remaining alternatives
- * are all glyph- or punctuation-shaped and cannot occur in prose by accident.
- * Nothing is lost as a running signal either: #1885 measured 0 matches for this
- * whole pattern across 44 live generating frames of copilot 1.0.80, whose turn
- * state is read from the status bar by {@link readCopilotStatusBar} instead.
- */
-exports.COPILOT_THINKING_PATTERN = /[\u2800-\u28FF]|\(Esc to cancel|Reasoning\s+[■▪▮]|\.\.\.\s+Thinking/;
-/**
- * Copilot CLI's bottom status bar while a turn is in flight (Issue #1885).
- *
- * Measured on copilot 1.0.80 at the production 200x1000 geometry
- * (`tests/unit/lib/detection/fixtures/copilot-live-1885/`). The bar is the
- * bottom row of the pane and reads, across 44 captured generating frames:
- *
- *   " ● Working esc interrupt                              GPT-5.6 Terra"
- *   " ◉ Working · 1.5 KiB esc interrupt                       GPT-5.6 Terra"
- *
- * The leading glyph cycles through ● ◉ ◎ ○ and the byte counter appears only
- * once the turn has produced output, so neither is anchored on. `esc interrupt`
- * is the affordance hint copilot draws for as long as the turn can be
- * interrupted -- it is on every generating frame and on every tool-execution
- * frame -- which makes it the same signal opencode's
- * {@link OPENCODE_PROCESSING_INDICATOR} rests on.
- *
- * It is matched against the STATUS BAR ROW ONLY, never a window
- * (see {@link readCopilotStatusBar}). `status-vocabulary-in-response.txt` is a
- * live frame where copilot was asked to print this vocabulary and answered
- * " ● Working esc interrupt" as body text: a window match would have pinned that
- * finished session to `running` for the rest of its life.
- *
- * No /g flag (S4-5: would make test() stateful). No quantifier over a
- * character class that can match its neighbour (SEC4-001: ReDoS safe).
- */
-exports.COPILOT_WORKING_STATUS_PATTERN = /\besc\s+interrupt\b/;
-/**
- * Copilot CLI's bottom status bar while no turn is running (Issue #1885).
- *
- * The same row as {@link COPILOT_WORKING_STATUS_PATTERN}, in the state copilot
- * paints when it is NOT working:
- *
- *   " ← open sidebar · / commands · ? help · tab next tab            GPT-5.6 Terra"
- *
- * This is copilot's positive completion evidence under design rule D1
- * (`docs/design/multi-agent-state-architecture.md` §4 D1 decision 1, item 2):
- * the key-hint bar and the working bar are two renderings of one row, so seeing
- * the hints is an affirmative observation that the turn is over -- not the
- * absence of a busy marker somewhere on screen. The composer cannot carry that
- * evidence on copilot: `❯` between its two full-width rules is drawn during
- * generation too (measured on every frame of the running fixtures), which is
- * exactly why the always-visible prompt used to win at step 3 of
- * `detectSessionStatus` and report a generating session as ready.
- *
- * Two alternative spellings of one affordance, because copilot has reworded
- * this row before: 1.0.80 shows "? help", and the pre-1.0.79 wording survives
- * in {@link COPILOT_SKIP_PATTERNS} as "? for shortcuts". "/ commands" covers
- * the slash-command hint independently, so a rewording of either half alone
- * does not cost the tool its completion evidence.
- *
- * No /g flag (S4-5). Linear alternation, no nested quantifiers (SEC4-001).
- */
-exports.COPILOT_IDLE_STATUS_PATTERN = /\/\s+commands\b|\?\s+(?:help\b|for\s+shortcuts\b)/;
-/**
- * Read copilot's bottom status bar out of a captured frame (Issue #1885).
- *
- * Takes the whole frame rather than a row so the positional anchor -- "the
- * status bar is the bottom row of the pane" -- cannot be lost at a call site.
- * The scan stops at the first non-blank row from the bottom: if that row is
- * neither state, this returns null and the caller has no evidence, which is the
- * D1-correct answer rather than a guess. Two measured frames rely on it:
- *
- *  - a permission dialog replaces the whole bottom of the pane with its box, so
- *    the bottom row is `╰───…` and neither pattern matches. The dialog then
- *    reaches `detectPrompt` and is reported as `waiting`, unchanged.
- *  - the `/model` picker ends in its own footer
- *    ("↑/↓ to navigate · … · enter to select · esc to cancel"), which is not the
- *    status bar either -- so this reports nothing about it and leaves that
- *    screen to the selection-list branch (Issue #1895's subject).
- *
- * @param contentLines - Frame rows, ANSI already stripped, in pane order
- * @returns The state the bottom row announces, or null when it announces neither
- */
-function readCopilotStatusBar(contentLines) {
-    for (let i = contentLines.length - 1; i >= 0; i--) {
-        const row = contentLines[i];
-        if (row.trim() === '')
-            continue;
-        if (exports.COPILOT_WORKING_STATUS_PATTERN.test(row))
-            return 'working';
-        if (exports.COPILOT_IDLE_STATUS_PATTERN.test(row))
-            return 'idle';
-        return null;
-    }
-    return null;
-}
-/**
- * Copilot separator pattern (Issue #545)
- * Placeholder - to be updated after Phase 1 TUI investigation.
- */
-exports.COPILOT_SEPARATOR_PATTERN = /^─{10,}$/m;
-/** How far above the bottom row copilot's closing rule may sit. */
-const COPILOT_STATUS_BAR_MAX_ROWS = 2;
-/** How many rows copilot's composer may span before the block stops looking like chrome. */
-const COPILOT_COMPOSER_MAX_ROWS = 40;
-/**
- * One of the two rows that fence copilot's composer.
- *
- * Two renderings of one thing, because copilot redrew its composer between the
- * builds this file is measured against (Issue #2269):
- *
- *  - **1.0.80** fences it with a full-width horizontal rule, `─` to the pane's
- *    width, above and below.
- *  - **1.0.82** fences it with a half-block frame instead: `╻` (U+257B) followed
- *    by `▄` to the pane's width above, `╹` (U+2579) followed by `▀` below.
- *
- * The corner glyph is REQUIRED on the 1.0.82 forms and that is load-bearing, not
- * decoration. 1.0.82 also boxes the echoed user prompt in the transcript between
- * two dividers of the same half blocks — `tests/unit/lib/detection/fixtures/
- * copilot-live-2269/turn-complete.txt` rows 10 and 12 — and those carry no
- * corner. Accepting a bare `▄`/`▀` run here would let the newest echo's box be
- * read as the composer, which would put `findCopilotChromeStart` ~985 rows too
- * high and delete the reply along with the chrome.
- */
-const COPILOT_RULE_ROW = /^(?:─{10,}|╻▄{10,}|╹▀{10,})$/;
-/**
- * copilot's composer glyph, at the pane's own indent.
- *
- * `>` is the legacy spelling, `❯` is 1.0.80's. 1.0.82 draws no prompt glyph in
- * the composer at all: the row is the frame's left edge, `┃` (U+2503), and the
- * operator's text follows it (`copilot-live-2269/boot-idle.txt` row 998 is the
- * bare glyph on an empty composer). `┃` is safe to accept here even though the
- * reasoning block's rows also start with a vertical — that one is `│` (U+2502,
- * {@link COPILOT_BOX_ROW_PATTERN}) — and in any case this test is only ever
- * applied to the single row between two fence rows, never to a window.
- */
-const COPILOT_COMPOSER_GLYPH = /^ {0,2}[>❯┃]/;
-/**
- * Locate the start of copilot CLI's bottom-pinned chrome within a captured pane
- * (Issue #1897).
- *
- * copilot 1.0.80 runs on the alternate screen and reserves the last five rows of
- * the pane. Measured at the production 200x1000 geometry
- * (`tests/unit/lib/detection/fixtures/copilot-live-1885/`), with the transcript
- * ~970 rows above and nothing but padding in between:
- *
- *     <cwd> [⎇ <branch>]                    Session: N AIC used
- *     ────────────────────  ← opening rule
- *     ❯ <composer>
- *     ────────────────────  ← closing rule
- *      ◉ Working · 1.5 KiB esc interrupt          GPT-5.6 Terra  ← status bar
- *
- * Issue #2269 re-measured the same five rows on 1.0.82, where the fence and the
- * composer are drawn differently but the layout is unchanged:
- *
- *     <cwd>                                          Session: N AIC used
- *     ╻▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄  ← opening frame
- *     ┃<composer>
- *     ╹▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀  ← closing frame
- *      ← open sidebar · / commands · ? help · tab next tab   GPT-5.6 Terra
- *
- * Both spellings live in {@link COPILOT_RULE_ROW} and
- * {@link COPILOT_COMPOSER_GLYPH}; the search below is unchanged. Until they were
- * added this function returned -1 on every 1.0.82 frame, `contentEnd` fell back
- * to the whole pane, and the saved reply opened with 199 `▀` and ended with the
- * `← open sidebar …` footer -- #2269's headline symptom.
- *
- * The boundary is found structurally -- closing rule, opening rule, composer
- * glyph -- and never by matching the status bar's wording. That is the same
- * reasoning {@link findClaudeChromeStart} records (#1289) plus the measurement
- * behind {@link COPILOT_WORKING_STATUS_PATTERN}: copilot will print its own
- * status-bar vocabulary as body text when asked to
- * (`status-vocabulary-in-response.txt` holds ` ● Working esc interrupt` as a
- * reply), so a vocabulary rule strong enough to delete the real bar also deletes
- * that reply. Position is the only thing that separates them.
- *
- * Without this trim the bar is transcript as far as every consumer is concerned:
- * it reached the TUI accumulator on every poll and was saved to History as the
- * agent's answer (#1897's headline symptom, ` Working esc interrupt GPT-5.6
- * Terra`), and its spinner glyph and byte counter change on every tick, so it
- * also defeats the content dedup the alternate-screen tools rely on (#1268).
- *
- * @param lines - Captured pane rows, ANSI-bearing or not; trailing blanks tolerated
- * @returns Index of the first chrome row, or -1 when the pane carries no chrome
- *   (a permission dialog draws its box over the whole bottom of the pane, so
- *   there is no composer and no bar -- those frames return -1 and are left to
- *   `detectPrompt`, exactly as {@link readCopilotStatusBar} leaves them)
- */
-function findCopilotChromeStart(lines) {
-    const isRule = (line) => COPILOT_RULE_ROW.test((0, ansi_1.stripAnsi)(line).trim());
-    let lastRow = lines.length - 1;
-    while (lastRow >= 0 && (0, ansi_1.stripAnsi)(lines[lastRow]).trim() === '')
-        lastRow--;
-    if (lastRow < 0)
-        return -1;
-    let closingRule = -1;
-    for (let i = lastRow; i >= Math.max(0, lastRow - COPILOT_STATUS_BAR_MAX_ROWS); i--) {
-        if (isRule(lines[i])) {
-            closingRule = i;
-            break;
-        }
-    }
-    if (closingRule < 0)
-        return -1;
-    let openingRule = -1;
-    for (let i = closingRule - 1; i >= Math.max(0, closingRule - COPILOT_COMPOSER_MAX_ROWS); i--) {
-        if (isRule(lines[i])) {
-            openingRule = i;
-            break;
-        }
-    }
-    if (openingRule < 0)
-        return -1;
-    // Confirm the fenced rows are the composer rather than a reply that happens to
-    // sit between two horizontal rules.
-    if (!COPILOT_COMPOSER_GLYPH.test((0, ansi_1.stripAnsi)(lines[openingRule + 1] ?? '')))
-        return -1;
-    // The row above the opening rule is copilot's cwd/branch/session header, which
-    // an overlay (the `/model` picker) replaces with a blank rather than with
-    // transcript -- measured on all five non-dialog fixtures.
-    return Math.max(0, openingRule - 1);
-}
-/**
- * A row copilot draws as part of a box or a collapsed reasoning block
- * (Issue #1897).
- *
- * 1.0.80 renders the model's private reasoning as a `⌄ Thought for 41s` header
- * followed by rows that each begin `│ `, and draws dialogs inside `╭─╮`/`╰─╯`
- * frames. {@link COPILOT_SKIP_PATTERNS} already carries a `[╭╮╰╯│]` rule, but
- * `normalizeCopilotLine` deletes every U+2500..U+257F glyph *before* the skip
- * patterns are applied, so by the time that rule runs the row it is meant to
- * catch reads as ordinary prose -- which is how the TUI accumulator came to save
- * copilot's chain-of-thought as the reply. Matched against the ANSI-stripped row,
- * before normalisation.
- *
- * `─` is deliberately absent: a rule row is {@link COPILOT_SEPARATOR_PATTERN}'s
- * job, and `── heading ──` is content.
- */
-exports.COPILOT_BOX_ROW_PATTERN = /^\s*[│└╰╭╮╯├┤┬┴┼]/;
-/**
- * copilot's collapsed-section header (Issue #1897).
- *
- * Measured on 1.0.80: `⌄ Thinking…` while the reasoning block is live, replaced
- * by `⌄ Thought for 41s` once the turn moves on. Anchored on the `⌄` disclosure
- * glyph rather than on the words, because "Thinking…" also occurs as body text
- * -- `status-vocabulary-in-response.txt` contains exactly that row as a reply,
- * and it must survive cleaning.
- */
-exports.COPILOT_REASONING_HEADER_PATTERN = /^\s*⌄\s/;
-/**
- * copilot's echo of the operator's own prompt in the transcript (Issue #1897).
- *
- * 1.0.80 draws every transcript row at the pane's one-column indent -- ` ❯ Reply
- * with exactly the word: pong` -- while the composer at the bottom of the pane is
- * at column 0. The bare `^[>❯]` form therefore never matched the echo, so
- * `resolveExtractionStartIndex`'s copilot branch found no anchor, fell back to
- * line 0, and handed the launch banner to the cleaner as the turn's reply.
- *
- * Bounded to two leading spaces rather than `\s*` so a quoted `> …` line inside a
- * reply cannot be mistaken for a new turn boundary.
- */
-exports.COPILOT_USER_ECHO_PATTERN = /^ {0,2}[>❯]\s+\S/;
-/**
- * One of the half-block dividers copilot 1.0.82 boxes a transcript row with
- * (Issue #2269).
- *
- * 1.0.80 drew the echoed prompt as a single bare ` ❯ <text>` row. 1.0.82 draws
- * a full-width `▄` run above it and a full-width `▀` run below it
- * (`copilot-live-2269/turn-complete.txt` rows 10 and 12):
- *
- *      ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
- *       ❯ Reply with exactly the word: uat-run1   00:27
- *      ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
- *      ● uat-run1
- *
- * {@link COPILOT_SKIP_PATTERNS}' `/[█▘▝▖▗▔▄▌▐]/` rule already dropped the `▄`
- * row. `▀` (U+2580) was not in that class, so the row BELOW the echo survived --
- * and extraction starts one row past the echo, which made a wall of 199 `▀` the
- * first line of every saved 1.0.82 reply.
- *
- * Deliberately not "add `▀` to that character class": this requires a run of ten
- * or more and nothing else on the row, so a reply that happens to use a single
- * half block as a glyph is untouched. The optional leading corner accepts the
- * composer's own fence rows (`╻▄…` / `╹▀…`) as well, which is defence in depth
- * only -- {@link findCopilotChromeStart} cuts those structurally, and this rule
- * is what stops them reaching History if a future build moves the fence again.
- */
-exports.COPILOT_TRANSCRIPT_DIVIDER_PATTERN = /^\s*[╻╹]?[▀▄]{10,}\s*$/;
-/**
- * The verbs copilot prints on a tool row, as a regex alternation source.
- *
- * One list, shared by {@link COPILOT_TOOL_ROW_PATTERN} here and by
- * `COPILOT_TOOL_ACTION_PATTERN` in `response-cleaner.ts`: the two match the same
- * vocabulary behind different markers, and a verb added to one and not the other
- * is a leak nothing fails on.
- *
- * `Asked user` / `Asking user` are Issue #2269's addition. copilot answers a
- * prompt it cannot act on by calling its ask-user tool, and the row it leaves in
- * the transcript (`● Asked user What would you like me to help with?`, measured
- * in `copilot-live-2269/turn-oneword-echo-askuser.txt`) was being saved as the
- * agent's reply -- the "launch screen as the answer" the Issue reports.
- */
-exports.COPILOT_TOOL_VERBS = 'Get|Read|Run|Search|Write|Edit|Delete|List|Create|Fetch|Explore|Execute|Install|Asked user|Asking user|Model changed to:';
-/**
- * copilot 1.0.82's tool row, whose marker is a file-type badge (Issue #2269).
- *
- * 1.0.80 drew every tool row as `● <Verb> …` and `COPILOT_TOOL_ACTION_PATTERN`
- * reads exactly that. 1.0.82 puts a short badge for the file the tool touched in
- * front of the verb instead, and only falls back to `●` for a type it has no
- * badge for. Measured verbatim over
- * `copilot-live-2269/turn-tool-badges.txt` and `turn-tool-rows.txt`:
- *
- *     / Search "a.ts" 1 file found
- *     MD Read note.md L1:1 (1 line read)
- *     TS Read a.ts 1 line read
- *     PY Read c.py 1 line read
- *     {} Read b.json 1 line read
- *     ● Read d.txt 1 line read          ← plain text keeps the 1.0.80 marker
- *
- * So the badge is `/`, `{}`, or two to four upper-case characters. Two is the
- * floor on purpose: a one-character class would also match the pronoun in an
- * English sentence ("I Read the file"), and no measured badge is one character.
- * `●` is left to `COPILOT_TOOL_ACTION_PATTERN`, which is the rule that already
- * owns it -- copilot's own prose is `● <text>` too (`● done`, `● 対象ファイルを
- * 確認して内容を読み込みます。`), and only the verb list separates the two.
- *
- * The `$` badge is absent for the same reason: `$ Shell Print requested text 2
- * lines…` opens a BLOCK whose command rows follow, which is
- * `COPILOT_TOOL_INVOCATION_PATTERN`'s job, and `Shell` is not in the verb list
- * anyway.
- *
- * No /g flag (S4-5: would make test() stateful). No quantifier nested inside
- * another (SEC4-001: ReDoS safe).
- */
-exports.COPILOT_TOOL_ROW_PATTERN = new RegExp(`^\\s*(?:\\/|\\{\\}|[A-Z][A-Z0-9+#]{1,3})\\s+(?:${exports.COPILOT_TOOL_VERBS})[\\s:]`);
-/**
- * A wrapped continuation of the copilot transcript row above it (Issue #1897).
- *
- * Marker rows (` ❯ `, ` ● `, ` $ `, ` ⌄ `) carry one leading space; the rows they
- * wrap onto are indented further and carry no marker, and a blank row separates
- * one block from the next (measured on 1.0.80 at 200x1000). Used to walk past the
- * tail of a long *user* prompt so the extracted reply does not open with the
- * second half of the operator's own question.
- */
-exports.COPILOT_TRANSCRIPT_CONTINUATION_PATTERN = /^ {2,}\S/;
-/**
- * Rows that only copilot's first-launch screen draws (Issue #1897).
- *
- * The launch screen is a complete, idle frame: the composer is drawn, the status
- * bar shows key hints, and nothing about it says "no turn has happened yet". So
- * `extractResponse` classified it as a finished response and History opened with
- * the banner as the agent's first message -- before the operator's first prompt.
- *
- * These anchors are only ever consulted for a frame that carries no echoed user
- * prompt at all (see the copilot banner guard in `extractResponse`), which is
- * what keeps a reply that quotes any of this wording from being suppressed.
- */
-exports.COPILOT_BOOT_BANNER_ANCHORS = [
-    /No copilot-instructions\.md found/,
-    /Copilot uses AI, so always check for mistakes\./,
-    /Copilot v\d[\w.]*\s+uses AI/,
-    /^\s*(?:●\s+)?GitHub Copilot\s+v\d/m,
-    /^\s*(?:●\s+)?Tip:\s*\//m,
-    /Describe a task to get started/,
-    /Prefer a visual workspace\?/,
-    // Issue #2269: copilot's greeting for a prompt it cannot act on. It arrives
-    // through the ask-user tool, so the row that reaches the transcript is
-    // `● Asked user Hi — what would you like to work on?` and the dialog's own
-    // body repeats the question. Both are chrome for a turn that produced no
-    // answer, and the operator saw the greeting saved as the agent's reply.
-    /what would you like to work on\?/i,
-];
-/**
- * The key-hint footer copilot draws under a picker, matched one ROW at a time
- * (Issue #547; rewritten against live 1.0.80 frames by Issue #1895).
- *
- * The pattern this replaced --
- * `/Search\s+\w+\.\.\.|Select\s+Model|to (?:navigate|select).*Enter to (?:select|confirm)/`
- * -- matched **none** of the eleven pickers 1.0.80 opens (measured; the frames
- * are in `tests/unit/lib/detection/fixtures/copilot-picker-1895/`, and #1885 /
- * #1886 / #1913 reached the same result independently). `/model` renders
- * `❯  Search models…` with U+2026 rather than three periods, no picker carries
- * the words `Select Model`, and every footer spells its verbs in lower case.
- *
- * What all eleven footers do share is the shape of a key-hint bar: `·`-separated
- * hints carrying either arrow-key navigation or a lower-case dismiss verb.
- * Measured verbatim, bottom-most first:
- *
- *   /model       ↑/↓ to navigate · ←/→ reasoning effort · tab context window ·
- *                shift+tab group: recommended · enter to select · esc to cancel
- *   /agent       n new agent · ? learn more · esc cancel
- *   /theme       ↑/↓ to navigate · enter to select · esc to cancel
- *   /permissions 1-2 to select · ↑/↓ to navigate · enter to confirm · esc to cancel
- *   /skills      ↑/↓ to navigate · enter to toggle · esc to close
- *   /mcp         ↑/↓ to select · enter to show · a to add · esc to close
- *   /settings    / search · ↑/↓ navigate · tab switch scope · enter edit ·
- *                ctrl+r reset · ctrl+e editor · esc close
- *   /statusline  ↑/↓ nav · enter toggle · esc close
- *   /subagents   ↑/↓ to navigate · space on/off · r reset · enter to select · esc to cancel
- *   /resume      / search · ↑/↓ navigate · enter select · ←/→ switch tabs · r refresh ·
- *                x delete · s sort:relevance · esc cancel
- *   /session     / search · ↑/↓ navigate · enter open · n new · tab switch tabs · a filter:all
- *
- * Neither half of the alternation is universal -- `/agent` has no list to walk
- * so it prints no `↑/↓`, and `/session` offers no `esc` -- but every footer has
- * one of them, so the union covers 11/11 while each individual disjunct stays
- * specific enough to be worth requiring. The slash in `↑/↓` is optional only as
- * a rewording tolerance: the synthetic frames pinned since Issue #547 spell it
- * `↑↓`, and whether copilot ever drew it that way is not something this Issue
- * measured. Every 1.0.80 footer above has the slash.
- *
- * Three deliberate narrowings keep this off ordinary text:
- *  - the `·` lookahead, so a sentence such as "press esc to cancel" is not a
- *    footer unless it is also a hint bar;
- *  - lower case, which is what 1.0.80 draws. `(Esc to cancel · 2.3 KiB)` -- the
- *    capitalised spelling in {@link COPILOT_THINKING_PATTERN} -- is a *progress*
- *    row, and it would otherwise satisfy both halves of this pattern;
- *  - `cancel|close` only, so the status bar's `esc interrupt`
- *    ({@link COPILOT_WORKING_STATUS_PATTERN}) is not a footer either.
- *
- * The narrowings are defence in depth; the load-bearing guard is positional and
- * lives in {@link isCopilotSelectionFrame} -- copilot's own answer text can and
- * does contain these exact rows (`picker-vocabulary-in-response.txt` is a live
- * frame of it), so no window-scoped match on this vocabulary can be safe.
- *
- * No /g flag (S4-5: would make test() stateful). `[^\n]*` cannot cross a row and
- * no quantifier is nested inside another (SEC4-001: ReDoS safe).
- */
-exports.COPILOT_SELECTION_FOOTER_PATTERN = /^(?=[^\n]*·)[^\n]*(?:↑\/?↓|\besc\s+(?:to\s+)?(?:cancel|close)\b)/m;
-/**
- * How many non-blank rows up from the bottom of the pane may carry the footer.
- *
- * Nine of the eleven pickers put it on the bottom row itself; `/agent` and
- * `/subagents` draw their panel with a closing full-width rule underneath it,
- * which puts the footer two non-blank rows up. Three is that measurement plus
- * one row of slack -- deliberately far short of a window that could reach the
- * transcript, which on the production 200x1000 geometry sits ~950 rows above.
- */
-const COPILOT_SELECTION_FOOTER_SCAN_ROWS = 3;
-/**
- * Whether the pane is sitting on one of copilot's pickers (Issue #1895).
- *
- * Takes the whole frame rather than a window for the same reason
- * {@link readCopilotStatusBar} does: the evidence is positional, and a call site
- * cannot be trusted to preserve "near the bottom of the pane" on its own. Two
- * facts, both measured on 1.0.80, make the position sufficient:
- *
- *  - **A picker replaces copilot's chrome.** In the idle and generating states
- *    the bottom five rows are cwd / rule / composer / rule / status bar; while a
- *    picker is up, none of them are drawn. So a frame whose bottom row is a
- *    status bar is not a picker, whatever its transcript says -- which is the
- *    whole of the false-positive half of Issue #1895. `detectSessionStatus`
- *    reads the same row for the running verdict at step 0.5, so checking it
- *    first here also fixes the order between the two branches: the status bar
- *    wins, and the picker branch only speaks when copilot has taken it away.
- *  - **An answerable dialog is drawn inside a box; a picker is not.** The
- *    folder-trust and permission dialogs wear the same lower-case
- *    `↑/↓ to navigate · enter to select · esc to cancel` footer, but every one of
- *    their rows reads `│ … │` and the bottom row is `╰─…─╯`. Skipping boxed rows
- *    keeps those on the prompt branch, where they belong: they are the agent
- *    blocked on the human (`hasActivePrompt: true`, exit 10 for `wait`), not a
- *    list the operator opened.
- *
- * @param contentLines - Frame rows, ANSI already stripped, in pane order
- * @returns True when the bottom of the pane is a picker's key-hint footer
- */
-function isCopilotSelectionFrame(contentLines) {
-    if (readCopilotStatusBar(contentLines) !== null)
-        return false;
-    let scanned = 0;
-    for (let i = contentLines.length - 1; i >= 0; i--) {
-        const row = contentLines[i];
-        const trimmed = row.trim();
-        if (trimmed === '')
-            continue;
-        if (++scanned > COPILOT_SELECTION_FOOTER_SCAN_ROWS)
-            break;
-        // A boxed row belongs to a dialog, not a picker (see above).
-        if (trimmed.startsWith('│') || trimmed.endsWith('│'))
-            continue;
-        if (exports.COPILOT_SELECTION_FOOTER_PATTERN.test(row))
-            return true;
-    }
-    return false;
-}
-/**
- * Anchors of Copilot CLI's first-launch "Confirm folder trust" dialog (Issue #1886).
- *
- * Recorded from copilot 1.0.80 (`tests/fixtures/copilot-folder-trust-1080.ts`):
- * copilot asks this once per untrusted git repository, before anything else runs,
- * and the whole dialog is drawn inside a box — every row reads `│ <content>`.
- * That is why `COPILOT_PROMPT_PATTERN` (`^[>❯]\s`) does not match the frame at
- * all and `waitForReady` used to spin its full 30-second window against it.
- *
- * Both anchors are required. One of them alone would also match this dialog's
- * text quoted back inside a model response, and a false positive here does not
- * merely mis-report a status: it sends a bare `1` into a live composer.
- *
- * The anchors live here rather than in `cli-tools/copilot` for the same reason
- * codex's do (Issue #1829): the Auto-Yes poller judges the same screen through
- * `detectPrompt`, and two copies of the wording would be two chances to disagree
- * about what this dialog is.
- */
-exports.COPILOT_FOLDER_TRUST_ANCHORS = [
-    'Confirm folder trust',
-    'Do you trust the files in this folder?',
-];
-/**
- * The one option CommandMate may answer on the operator's behalf: `1. Yes`,
- * which grants trust for THIS SESSION only.
- *
- * Matching the option text — not just the dialog — is the fail-safe. Option 2
- * ("Yes, and remember this folder for future sessions") writes `trustedFolders`
- * into `~/.copilot/config.json`, one file shared by every checkout on the
- * machine (measured: answering `1` leaves that file byte-identical). If copilot
- * ever reorders the list so that `1` is the remembering variant, this stops
- * matching, nothing is sent, and the launch degrades to the pre-#1886 stall
- * instead of silently persisting a trust grant.
- *
- * Written against the box-stripped frame, where the row reads `❯ 1. Yes`.
- * `[ \t]*$` rather than `\s*$` so the trailing anchor cannot roll onto a later
- * line and accept `1. Yes, and remember ...`.
- */
-exports.COPILOT_FOLDER_TRUST_SESSION_OPTION_PATTERN = /^[ \t]*(?:[>❯][ \t]*)?1\.[ \t]+Yes[ \t]*$/m;
-/**
- * Key that selects {@link COPILOT_FOLDER_TRUST_SESSION_OPTION_PATTERN}.
- * Measured on 1.0.80: the digit confirms on its own — sending a trailing Enter
- * would land on the composer that the dialog's dismissal reveals.
- */
-exports.COPILOT_FOLDER_TRUST_ANSWER_KEY = '1';
-/**
- * Whether the pane is sitting on the folder-trust dialog with the session-only
- * option in first position.
- *
- * @param output - ANSI-stripped pane capture (box drawing still present)
- * @returns True when both anchors and the `1. Yes` option row are present
- */
-function isCopilotFolderTrustDialog(output) {
-    if (!exports.COPILOT_FOLDER_TRUST_ANCHORS.every((anchor) => output.includes(anchor))) {
-        return false;
-    }
-    return exports.COPILOT_FOLDER_TRUST_SESSION_OPTION_PATTERN.test(stripBoxDrawing(output));
-}
-/**
- * Copilot skip patterns for response cleaning (Issue #545)
- * Placeholder patterns - to be refined after Phase 1 TUI investigation.
- */
-exports.COPILOT_SKIP_PATTERNS = [
-    exports.PASTED_TEXT_PATTERN,
-    exports.COPILOT_SEPARATOR_PATTERN,
-    exports.COPILOT_THINKING_PATTERN,
-    // Issue #1895 replaced COPILOT_SELECTION_LIST_PATTERN with the row-scoped
-    // picker footer; the vocabulary it carried (`Search \w+...` / `Select Model`)
-    // is copilot's prose, not its chrome.
-    exports.COPILOT_SELECTION_FOOTER_PATTERN,
-    // Collapsed reasoning header (Issue #1897): "⌄ Thinking…" / "⌄ Thought for 41s"
-    exports.COPILOT_REASONING_HEADER_PATTERN,
-    // 1.0.82's transcript dividers and badge-marked tool rows (Issue #2269)
-    exports.COPILOT_TRANSCRIPT_DIVIDER_PATTERN,
-    exports.COPILOT_TOOL_ROW_PATTERN,
-    // Issue #2269: the anchored box-row rule, so the raw-row consumer agrees with
-    // the accumulator. `[╭╮╰╯│]` below is unanchored and omits `└`, which is the
-    // glyph copilot opens a detail row with (`   └ Enable all permissions (tools,
-    // paths, and URLs)` under the launch screen's tip). `normalizeCopilotLine`
-    // deletes every U+2500..U+257F glyph, so by the time the skip patterns run in
-    // `cleanCopilotResponse` that row reads as prose -- which is how the ONE row
-    // of the 1.0.82 launch screen that no other rule caught became the agent's
-    // first reply. `extractCopilotContentLines` already tests this pattern before
-    // normalising (#1897); adding it here is what gives `extractResponse`, which
-    // never normalises, the same answer.
-    exports.COPILOT_BOX_ROW_PATTERN,
-    // Logo/banner lines
-    /^GitHub Copilot\s+v/,
-    /[█▘▝▖▗▔▄▌▐]/,
-    /[╭╮╰╯│]/,
-    // Status bar (branch + model display)
-    /\[⎇\s+\w[^\]]*\]/,
-    // Operation guide lines
-    /^shift\+tab\s/,
-    /^\?\s+for\s+shortcuts/,
-    /^ctrl\+[a-z]\s+\w/,
-    // Prompt lines
-    /^[❯>]\s*(Type\s+@|$)/,
-    // Tip/hint lines. Issue #2269 added the `●` marker: 1.0.82 draws the launch
-    // screen's tip as `● Tip: /allow-all`, and `cleanCopilotResponse` strips the
-    // bullet only AFTER the skip patterns have run, so the bare form never
-    // matched and the tip was the one banner row that reached History.
-    /^\s*(?:●\s+)?Tip:\s*\//,
-    // Issue #2269: copilot's own tab bar, the top row of every 1.0.82 frame. It is
-    // the second banner row the launch screen leaked (the logo, the disclaimer and
-    // the tip's `└ …` detail row are all caught by the glyph rules above), and
-    // between them they are the whole difference between "the launch screen cleans
-    // to nothing and cannot be saved" and "History opens with the banner". Spelled
-    // out in full rather than as a keyword so a reply that mentions one of these
-    // words is untouched.
-    /^\s*Current\s+Sessions\s+Issues\s+Pull requests\s+Gists\s*$/,
-    // Initial display text
-    /^Describe a task to get started/,
-    // Issue #571: Disclaimer, initialization message, environment info
-    /^Copilot uses AI, so always check for mistakes\.$/, // Disclaimer (full-line match to avoid filtering user content mentioning Copilot)
-    /^● 💡/, // Initialization hint message
-    /^● Environment loaded:/, // Environment info
-];
-/**
- * Vibe Local prompt pattern
- * vibe-local (vibe-coder) shows `ctx:N% ❯` prompt when waiting for user input.
- * The prompt line includes a context usage percentage prefix.
- * Examples: "ctx:9% ❯", "ctx:30% ❯", "ctx:9% ❯ /model"
- */
-exports.VIBE_LOCAL_PROMPT_PATTERN = /ctx:\d+%\s*[>❯]/m;
-/**
- * Vibe Local thinking/processing pattern
- * vibe-local shows spinner characters and status text while processing.
- * Matches braille spinners, "Thinking", and tool execution indicators.
- */
-exports.VIBE_LOCAL_THINKING_PATTERN = /[\u2800-\u28FF]|Thinking|⠋|⠙|⠹|⠸|⠼|⠴|⠦|⠧|⠇|⠏|Running|Executing/;
-/**
- * The banner agy paints INTO its empty input box while a non-default permission
- * mode is on (Issue #2592).
- *
- * Measured on agy 1.2.4 in the #2592 UAT
- * (`tests/fixtures/agent-mode-2592/antigravity-{accept-edits,plan}.txt`, row 18,
- * between the box's two rules):
- *
- *   `> Accept-edits mode: file edits auto-approved (shift+tab to cycle)`
- *   `> Plan mode: research & plan only (shift+tab to cycle)`
- *
- * It takes the place of the bare `>` an empty box shows in default — it is a
- * placeholder, not typed text — so a reader that only accepts the bare glyph
- * reads an idle accept-edits / plan pane as "no input box at all". Before this
- * pattern existed that is exactly what happened: the status detector fell through
- * to its `default` floor (`running` + `isUnclassifiedActive`), `commandmate ls`
- * showed a resting agent as running, `wait` never completed, and
- * `isAntigravityReady` refused every send. #2592 made those two modes one click
- * away, so the hole had to close with it.
- *
- * The structure is matched rather than the two sentences: `<Name> mode: <text>
- * (shift+tab to cycle)`, anchored on the key hint agy ends every banner with, so
- * a third mode needs no edit here. What stays out is anything a user could have
- * typed into the box — the trailing hint is the part nobody types.
- *
- * Whole-row, no `/g`, no nested quantifiers (`[^\n]*` is followed by a literal).
- */
-exports.ANTIGRAVITY_COMPOSER_MODE_BANNER_SOURCE = '>[^\\S\\n]+[A-Z][A-Za-z-]*[^\\S\\n]mode:[^\\n]*\\(shift\\+tab to cycle\\)[^\\S\\n]*';
-/** {@link ANTIGRAVITY_COMPOSER_MODE_BANNER_SOURCE} as a single-row pattern. */
-exports.ANTIGRAVITY_COMPOSER_MODE_BANNER_PATTERN = new RegExp(`^${exports.ANTIGRAVITY_COMPOSER_MODE_BANNER_SOURCE}$`, 'm');
-/**
- * Antigravity (agy) interactive REPL prompt pattern (Issue #988)
- * agy shows a bare ">" input box line when waiting for user input. The input box
- * is always rendered (even while generating), so prompt presence alone does not
- * mean "ready" — running vs idle is resolved together with the thinking pattern /
- * footer status bar in status-detector.ts. (Confirmed on machine: line is "> ".)
- *
- * Issue #2592: or the mode banner that replaces the bare glyph in an EMPTY box
- * while accept-edits / plan is on ({@link ANTIGRAVITY_COMPOSER_MODE_BANNER_PATTERN}).
- * Every consumer of this pattern is asking "is agy's input box drawn and empty?"
- * — the idle rule in `detection/tools/antigravity/detect.ts`, the survey guard
- * beside it, `isAntigravityReady` (the send gate) and the liveness probe — and
- * the answer does not depend on the permission mode, so the banner is folded in
- * here once rather than at each of them.
- */
-exports.ANTIGRAVITY_PROMPT_PATTERN = new RegExp(`^(?:>\\s*|${exports.ANTIGRAVITY_COMPOSER_MODE_BANNER_SOURCE})$`, 'm');
-/**
- * Antigravity (agy) thinking/processing pattern (Issue #988)
- * While generating, agy shows a braille spinner with "Generating..." in the
- * conversation area and an "esc to cancel" hint in the footer status bar. When
- * idle the footer shows "? for shortcuts" instead, so "esc to cancel" is a
- * reliable running signal. Braille spinner chars (U+2800-U+28FF) also matched.
- */
-exports.ANTIGRAVITY_THINKING_PATTERN = /[\u2800-\u28FF]|Generating|esc to cancel/;
-/**
- * Antigravity (agy) separator pattern (Issue #988)
- * agy draws turn separators and the input-box border with runs of U+2500 (─).
- */
-exports.ANTIGRAVITY_SEPARATOR_PATTERN = /^─{3,}$/m;
-/**
- * Antigravity (agy) selection list pattern (Issue #995, broadened in #997)
- * Detects agy's interactive arrow-key selection TUIs (e.g. the "Switch Model"
- * model picker, the "Do you want to proceed?" permission-approval menu). Their
- * footer status bar renders "esc to cancel", which ANTIGRAVITY_THINKING_PATTERN
- * also matches, so this pattern must be checked BEFORE thinking detection in
- * status-detector.ts to keep the selection screen from being misreported as
- * "generating".
- *
- * Matches (either is sufficient):
- *   - The "Switch Model" header of the model picker.
- *   - The "↑/↓ Navigate" arrow-key navigation hint, common to every agy
- *     selection TUI footer. Issue #995 originally required an "enter Select"
- *     hint too, but the permission-approval menu footer is
- *     "↑/↓ Navigate · tab Amend · ctrl+g … · ctrl+r Review" (no "enter Select"),
- *     so #997 relaxes this to the "↑/↓ Navigate" footer alone. This covers the
- *     Switch Model picker, permission-approval menus, and future agy selection
- *     TUIs in one shot, while staying agy-specific (the cliToolId === 'antigravity'
- *     guard in status-detector.ts keeps other tools unaffected).
- *
- * No /g flag (S4-5: would make test() stateful).
- * No `.*` at all (SEC4-001: ReDoS safe — strictly safer than the #995 form).
- */
-exports.ANTIGRAVITY_SELECTION_LIST_PATTERN = /Switch Model|↑\/↓\s*Navigate/m;
-/**
- * The `↑/↓ Navigate` hint agy draws under every arrow-key screen it owns
- * (Issue #2364; measured on agy 1.1.27, pane 200x1000, 2026-09-06).
- *
- * The same token {@link ANTIGRAVITY_SELECTION_LIST_PATTERN} matches, split out
- * because the numbered-dialog reader anchors on THIS row and reads upward from
- * it. It is the one thing all four measured agy dialogs share — the `Do you want
- * to proceed?` command menu, the `Allow creation of this file?` file menu, the
- * folder-trust screen and the `/model` picker all end on it — while the words
- * after it differ on every one (`tab Amend · f full diff`, `tab Amend · ctrl+g
- * edit/expand command`, `enter Confirm`, `←/→ Effort  enter Select`).
- */
-exports.ANTIGRAVITY_NAVIGATE_FOOTER_PATTERN = /↑\/↓\s*Navigate/;
-/**
- * One numbered option row of agy's dialogs: `> 1. Yes`, `  4. No`,
- * `  2. No, deny creation`.
- *
- * The `>` gutter marks the highlighted row and is optional, because only one
- * of the rows carries it.
- */
-exports.ANTIGRAVITY_NUMBERED_OPTION_PATTERN = /^\s*>?\s*\d+\.\s+\S/m;
-/**
- * The header of agy's `/model` picker (Issue #995).
- *
- * Kept as its own exclusion even though the picker's rows already fail the
- * numbered-row test: the Issue #2364 rule is written as "footer + numbered rows
- * + NOT the Switch Model picker", and the picker is the one agy screen whose
- * misreading has a measured cost (#995: NavigationButtons vanished).
- */
-exports.ANTIGRAVITY_SWITCH_MODEL_HEADER_PATTERN = /^\s*Switch Model\s*$/;
-/**
- * A row that ends the dialog block when reading UPWARD from the footer
- * (Issue #2364).
- *
- * Everything agy draws above its own dialog panel carries one of these:
- *
- *  - a horizontal rule (the turn separator, the input-box border, or the rule
- *    under the `Command` / `Create file` panel header);
- *  - a `>`-prefixed row that is not a numbered option — the echoed user prompt,
- *    the bare composer, the highlighted row of an UNNUMBERED picker (`> Gemini
- *    3.8 Flash`, `> Yes, I trust this folder`) or of the slash-command popup
- *    (`> /add-dir  Add a directory …`);
- *  - a `●` tool-call row, a `⎿` tool-result row or a `▸ Thought for …` row.
- *
- * Bounding the block at the nearest one is what keeps a numbered list in the
- * MODEL'S PROSE, sitting in the transcript above an open picker or popup, from
- * being adopted as that screen's options. Wrapped option labels never start
- * with any of these on the measured frames: agy prints the command text inside
- * the quotes of `… commands that start with '<cmd>'`, indented under the row
- * that opened it.
- *
- * `stripBoxDrawing` blanks the rule rows before the response poller's copy of
- * the frame reaches this rule; the `●` / `>` rows survive it, so the block is
- * bounded the same way on both paths.
- */
-exports.ANTIGRAVITY_DIALOG_BOUNDARY_PATTERN = /^\s*(?:─{3,}\s*$|[●⎿▸]|>(?!\s*\d+\.\s+\S))/;
-/**
- * How many rows above the `↑/↓ Navigate` footer the dialog block may reach.
- *
- * The tallest measured frame (`dialog-bash-wrapped.txt`: header, rule,
- * `Requesting permission for:`, a four-row command, the question and four
- * options of which two wrap onto three rows each) spans 18 rows; the cap leaves
- * room for a longer command without letting a boundary-free frame drag the
- * whole transcript into the block.
- */
-exports.ANTIGRAVITY_DIALOG_MAX_ROWS = 60;
-/**
- * agy's post-answer survey row (Issue #2364).
- *
- * Drawn once, in place of the composer, after some tool decisions:
- *
- * ```
- *  How's the CLI experience so far? Help us improve:
- *  [1] Good  [2] Fine  [3] Bad  [0] Skip
- *
- * ? for shortcuts …
- * ```
- *
- * Every option sits on ONE row in `[N] label` form and the screen takes a
- * typed digit, not the arrow keys; there is no `↑/↓ Navigate` footer and no bare
- * `>` composer, so before this pattern existed the frame reached the `default`
- * floor — `running`, with the chat surface showing "generating" over a screen
- * that was waiting for a keypress. Anchored to the whole row.
- */
-exports.ANTIGRAVITY_SURVEY_PATTERN = /^\s*\[1\]\s*Good\s+\[2\]\s*Fine\s+\[3\]\s*Bad\s+\[0\]\s*Skip\s*$/m;
-/**
- * Find the rows between the last boundary and the last `↑/↓ Navigate` footer
- * (Issue #2364).
- *
- * The footer is searched from the bottom, so an older dialog still in the
- * scrollback above a newer one is never the one read. Returns null when the
- * frame has no footer at all.
- *
- * Also null when agy's input box is drawn BELOW that footer (Issue #2845): agy
- * paints no `>` composer while a dialog is open — the dialog takes its place —
- * so a footer with a composer under it is the model's reply quoting a dialog,
- * or a dialog left in the scrollback, not a screen waiting for a keypress. It is
- * the same reading `isAntigravitySurveyOpen` gives the survey row (#2364), and
- * the composer is recognised by the same {@link ANTIGRAVITY_PROMPT_PATTERN}.
- *
- * @param lines - ANSI-stripped rows, box drawing optional
- */
-function locateAntigravityDialogRegion(lines) {
-    let footer = -1;
-    for (let i = lines.length - 1; i >= 0; i--) {
-        if (exports.ANTIGRAVITY_NAVIGATE_FOOTER_PATTERN.test(lines[i])) {
-            footer = i;
-            break;
-        }
-    }
-    if (footer < 0)
-        return null;
-    for (let i = footer + 1; i < lines.length; i++) {
-        if (exports.ANTIGRAVITY_PROMPT_PATTERN.test(lines[i]))
-            return null;
-    }
-    const floor = Math.max(0, footer - exports.ANTIGRAVITY_DIALOG_MAX_ROWS);
-    let start = floor;
-    for (let i = footer - 1; i >= floor; i--) {
-        if (exports.ANTIGRAVITY_DIALOG_BOUNDARY_PATTERN.test(lines[i])) {
-            start = i + 1;
-            break;
-        }
-    }
-    return { start, footer };
-}
-/**
- * Is this frame one of agy's NUMBERED dialogs rather than one of its
- * arrow-key-only pickers? (Issue #2270, re-measured by Issue #2364)
- *
- * Both kinds of screen share the `↑/↓ Navigate` footer that
- * {@link ANTIGRAVITY_SELECTION_LIST_PATTERN} matches, which is why #997 could
- * widen that pattern to cover the permission menu — and why the menu then
- * resolved as `antigravity_selection_list`, `hasActivePrompt: false`. On the
- * chat surface that reads as "a selection list is open, drive it from the
- * terminal": the arrow buttons can only Enter the highlighted option 1, so
- * options 2-4 became unreachable, while the poller and the push notification
- * described the very same frame as a `multiple_choice` prompt.
- *
- * #2270 told the two apart by the question line, `Do you want to proceed?`,
- * because that was the one dialog it had measured. #2364 measured a second one
- * — agy 1.1.27's file-creation menu asks `Allow creation of this file?` above
- * `1. Yes, allow creation` / `2. No, deny creation` — and it fell straight back
- * into the selection-list reading. So the rule is now about the STRUCTURE the
- * dialogs share and the pickers lack:
- *
- *  - the `↑/↓ Navigate` footer,
- *  - at least two `N. label` rows between the nearest boundary row and that
- *    footer ({@link ANTIGRAVITY_DIALOG_BOUNDARY_PATTERN}), and
- *  - no `Switch Model` header in that region.
- *
- * The Switch Model picker, the folder-trust screen and the slash-command popup
- * all draw unnumbered rows (`> Gemini 3.8 Flash`, `> Yes, I trust this folder`,
- * `> /add-dir …`), so they keep the #995 reading — and because a `>` row that
- * is not numbered is itself a boundary, a numbered list in the transcript above
- * one of them cannot be counted.
- *
- * True here means "hand the frame to the agy dialog reader"
- * (`tools/antigravity/dialog.ts`), never "this is a prompt": a frame that
- * passes this test and still fails to read is published as an unclassified
- * frame, not as a selection list and never as "generating".
- *
- * Callers pass the same text they hand {@link ANTIGRAVITY_SELECTION_LIST_PATTERN}.
- */
-function isAntigravityNumberedDialog(text) {
-    const lines = text.split('\n');
-    const region = locateAntigravityDialogRegion(lines);
-    if (region === null)
-        return false;
-    let numberedRows = 0;
-    for (let i = region.start; i < region.footer; i++) {
-        const line = lines[i];
-        if (exports.ANTIGRAVITY_SWITCH_MODEL_HEADER_PATTERN.test(line))
-            return false;
-        if (exports.ANTIGRAVITY_NUMBERED_OPTION_PATTERN.test(line))
-            numberedRows++;
-    }
-    return numberedRows >= 2;
+const CLI_TOOL_PATTERN_TABLE = {
+    claude: {
+        promptPattern: patterns_7.CLAUDE_PROMPT_PATTERN,
+        separatorPattern: patterns_7.CLAUDE_SEPARATOR_PATTERN,
+        thinkingPattern: patterns_7.CLAUDE_THINKING_PATTERN,
+        skipPatterns: [
+            /^─{10,}$/, // Separator lines
+            /^[>❯]\s*$/, // Prompt line (legacy '>' and new '❯')
+            patterns_7.CLAUDE_THINKING_PATTERN, // Thinking indicators
+            /^\s*[⎿⏋]\s+Tip:/, // Tip lines
+            /^\s*Tip:/, // Tip lines
+            /^\s*\?\s*for shortcuts/, // Shortcuts hint
+            /to interrupt\)/, // Part of "esc to interrupt" message
+            pasted_text_1.PASTED_TEXT_PATTERN, // [Pasted text #N +XX lines] (Issue #212)
+        ],
+        // Full frame: their multiple-choice prompts with descriptions can exceed 15 lines: Codex
+        // approval prompts with long file lists, Claude "Yes, and don't ask again for:
+        // git commit -m …" options that embed full commit messages. `detectPrompt`
+        // applies its own 50-line window internally.
+        promptOptions: { requireDefaultIndicator: false },
+        fullFramePrompt: true,
+    },
+    codex: {
+        promptPattern: patterns_1.CODEX_PROMPT_PATTERN,
+        separatorPattern: patterns_1.CODEX_SEPARATOR_PATTERN,
+        thinkingPattern: patterns_1.CODEX_THINKING_PATTERN,
+        skipPatterns: [
+            /^─.*─+$/, // Separator lines
+            /^›\s*$/, // Empty prompt line
+            /^›\s+(Implement|Find and fix|Type)/, // New prompt suggestions
+            patterns_1.CODEX_THINKING_PATTERN, // Activity indicators
+            /^\s*\d+%\s+context left/, // Context indicator
+            /^\s*for shortcuts$/, // Shortcuts hint
+            /╭─+╮/, // Box drawing (top)
+            /╰─+╯/, // Box drawing (bottom)
+            // T1.3: Additional skip patterns for Codex
+            /•\s*Ran\s+/, // Command execution lines
+            /^\s*└/, // Tree output (completion indicator)
+            /^\s*│/, // Continuation lines
+            /\(.*esc to interrupt\)/, // Interrupt hint
+            pasted_text_1.PASTED_TEXT_PATTERN, // [Pasted text #N +XX lines] (Issue #212, defensive)
+        ],
+        // Full frame: their multiple-choice prompts with descriptions can exceed 15 lines: Codex
+        // approval prompts with long file lists, Claude "Yes, and don't ask again for:
+        // git commit -m …" options that embed full commit messages. `detectPrompt`
+        // applies its own 50-line window internally.
+        promptOptions: undefined,
+        fullFramePrompt: true,
+    },
+    gemini: {
+        promptPattern: patterns_9.GEMINI_PROMPT_PATTERN,
+        separatorPattern: /^[─━]{3,}$/m,
+        thinkingPattern: patterns_9.GEMINI_THINKING_PATTERN,
+        skipPatterns: [
+            patterns_9.GEMINI_PROMPT_PATTERN, // Prompt line (DRY: shared with GEMINI_PROMPT_PATTERN)
+            patterns_9.GEMINI_THINKING_PATTERN, // Thinking indicators
+            /^\s*$/, // Empty lines
+            /Gemini\s+\d+\.\d+/, // Version line
+            pasted_text_1.PASTED_TEXT_PATTERN, // [Pasted text #N +XX lines]
+        ],
+        promptOptions: undefined,
+        fullFramePrompt: false,
+    },
+    'vibe-local': {
+        promptPattern: patterns_11.VIBE_LOCAL_PROMPT_PATTERN,
+        separatorPattern: /^[·]{10,}$/m, // vibe-local uses middle dot separators
+        thinkingPattern: patterns_11.VIBE_LOCAL_THINKING_PATTERN,
+        skipPatterns: [
+            patterns_11.VIBE_LOCAL_PROMPT_PATTERN, // Prompt line (ctx:N% ❯)
+            patterns_11.VIBE_LOCAL_THINKING_PATTERN, // Thinking indicators
+            /^\s*$/, // Empty lines
+            /vibe-local|vibe-coder/, // Version/banner lines
+            /ctx:\s*\d+%/, // Context usage indicator
+            /Model\s+\w/, // Model info line
+            /Engine\s+\w/, // Engine info line
+            /Mode\s+/, // Mode info line
+            /RAM\s+/, // RAM info line
+            /CWD\s+/, // Working directory line
+            /^[·]{10,}$/, // Middle dot separator lines
+            /✦\s*Ready/, // Status bar "Ready" indicator
+            /ESC:\s*stop/, // Status bar "ESC: stop" hint
+            pasted_text_1.PASTED_TEXT_PATTERN, // [Pasted text #N +XX lines]
+        ],
+        promptOptions: undefined,
+        fullFramePrompt: false,
+    },
+    opencode: {
+        promptPattern: patterns_3.OPENCODE_PROMPT_PATTERN,
+        separatorPattern: patterns_3.OPENCODE_SEPARATOR_PATTERN,
+        thinkingPattern: patterns_3.OPENCODE_THINKING_PATTERN,
+        skipPatterns: patterns_3.OPENCODE_SKIP_PATTERNS,
+        // [D2-006] OpenCode prompt "Ask anything..." does not use standard indicators (> / ❯),
+        // so requireDefaultIndicator must be false to avoid missing prompt detection.
+        //
+        // [Issue #1896] `hasNumberedDialogs: false` -- opencode 1.18 renders NO dialog
+        // that a typed number drives, so the generic numbered-list inference has
+        // nothing to find on its pane and every hit it scored was transcript text.
+        // Its two interactive surfaces were both measured at the production 80x200
+        // geometry and both are cursor-driven:
+        //
+        //  - the permission dialog is a horizontal button strip
+        //    ({@link OPENCODE_PERMISSION_PATTERN}, Issue #1893) driven by ←/→ + Enter;
+        //    typing a number does nothing to it.
+        //  - the pickers (`/models`, `/providers`, `/connect`, and the ctrl+p command
+        //    palette) are fuzzy-search lists driven by ↑/↓ + Enter, with no numbers
+        //    drawn at all. The first three are what
+        //    {@link OPENCODE_SELECTION_LIST_PATTERN} names; the palette shares the
+        //    chrome but not the header allowlist, and lands on `running` / `default`.
+        //
+        // Both keep their own POSITIVE detection in `status-detector.ts`, so `wait`
+        // still stops for them (exit 10 via `isSelectionListActive`) and the UI still
+        // renders NavigationButtons: nothing that could be answered before stops being
+        // answered. What ends is the false positive -- a response whose body ends in
+        // `1. / 2. / 3.` + a question was published as
+        // `waiting`/`prompt_detected`/`hasActivePrompt: true`, and Auto-Yes typed `1`
+        // into the composer and SENT IT as a user utterance (Issue #1896).
+        //
+        // `requireDefaultIndicator` is kept at its D2-006 value: it is the correct
+        // setting for opencode's ❯-less rendering should the numbered path ever be
+        // re-enabled, and it still describes the tool.
+        // Full frame: their multiple-choice prompts with descriptions can exceed 15 lines: Codex
+        // approval prompts with long file lists, Claude "Yes, and don't ask again for:
+        // git commit -m …" options that embed full commit messages. `detectPrompt`
+        // applies its own 50-line window internally.
+        promptOptions: { requireDefaultIndicator: false, hasNumberedDialogs: false },
+        fullFramePrompt: true,
+    },
+    copilot: {
+        promptPattern: patterns_13.COPILOT_PROMPT_PATTERN,
+        separatorPattern: patterns_13.COPILOT_SEPARATOR_PATTERN,
+        thinkingPattern: patterns_13.COPILOT_THINKING_PATTERN,
+        skipPatterns: patterns_13.COPILOT_SKIP_PATTERNS,
+        // [Issue #545] Copilot prompt pattern may not use standard indicators
+        // Full frame: their multiple-choice prompts with descriptions can exceed 15 lines: Codex
+        // approval prompts with long file lists, Claude "Yes, and don't ask again for:
+        // git commit -m …" options that embed full commit messages. `detectPrompt`
+        // applies its own 50-line window internally.
+        promptOptions: { requireDefaultIndicator: false },
+        fullFramePrompt: true,
+    },
+    antigravity: {
+        promptPattern: patterns_15.ANTIGRAVITY_PROMPT_PATTERN,
+        separatorPattern: patterns_15.ANTIGRAVITY_SEPARATOR_PATTERN,
+        thinkingPattern: patterns_15.ANTIGRAVITY_THINKING_PATTERN,
+        skipPatterns: patterns_15.ANTIGRAVITY_SKIP_PATTERNS,
+        // [Issue #999] Antigravity (agy) permission-approval menus highlight the
+        // default with an ASCII ">" (0x3E), not the "❯/●/›" indicators that
+        // DEFAULT_OPTION_PATTERN recognizes, and their footer is "↑/↓ Navigate"
+        // (no "press enter to confirm"). Under the default requireDefaultIndicator=true
+        // the Pass 1 gate rejects these menus, so Auto-Yes never responds. Treat agy
+        // like claude/opencode/copilot so Pass 2 collects its "1. Yes / … / N. No"
+        // options and reports isPrompt=true.
+        //
+        // [Issue #2364] The `↑/↓ Navigate` dialogs themselves no longer reach
+        // `detectPrompt` on either production path: `tools/antigravity/detect.ts`
+        // (status) and `detectPromptWithOptions` (response poller) both read them
+        // with `detectAntigravityNumberedDialogPrompt` first, because the generic
+        // multiple-choice pass reads one row per option and agy wraps a long command
+        // across several rows of one label. What this setting still serves is every
+        // OTHER numbered agy screen — `/feedback`'s `1-6 Select & Continue` menu is
+        // the measured one — which the generic pass reads as before.
+        promptOptions: { requireDefaultIndicator: false },
+        fullFramePrompt: false,
+    },
+    // Issue #2250: Command Code's layout is claude-shaped (inline transcript,
+    // `❯` composer fenced by two full-width rules) but the constants are its
+    // own. Sharing claude's would import the exact defect #2247 had to undo --
+    // claude's rules carry a startup-banner reading that keys on `v\d+\.\d+`
+    // and `|`, and Command Code prints its version into a `# Command Code
+    // v1.40.1` row on every launch.
+    'command-code': {
+        promptPattern: patterns_17.COMMAND_CODE_PROMPT_PATTERN,
+        separatorPattern: patterns_17.COMMAND_CODE_SEPARATOR_PATTERN,
+        thinkingPattern: patterns_17.COMMAND_CODE_THINKING_PATTERN,
+        skipPatterns: patterns_17.COMMAND_CODE_SKIP_PATTERNS,
+        promptOptions: undefined,
+        fullFramePrompt: false,
+    },
+    // Issue #2934: OpenCode V2's own constants (see OPENCODE_V2_* above). The
+    // separator row is the same half-block rule v1 draws, so v1's pattern is
+    // reused as a value; nothing of v1's is changed.
+    'opencode-v2': {
+        promptPattern: patterns_5.OPENCODE_V2_IDLE_COMPOSER_PATTERN,
+        separatorPattern: patterns_3.OPENCODE_SEPARATOR_PATTERN,
+        thinkingPattern: patterns_5.OPENCODE_V2_THINKING_PATTERN,
+        skipPatterns: patterns_5.OPENCODE_V2_SKIP_PATTERNS,
+        promptOptions: undefined,
+        fullFramePrompt: false,
+    },
+};
+/**
+ * The table's own row for an id, or undefined. The table is a plain object, so a
+ * name such as 'constructor' or '__proto__' must not reach Object.prototype.
+ */
+function ownRowFor(cliToolId) {
+    return Object.prototype.hasOwnProperty.call(CLI_TOOL_PATTERN_TABLE, cliToolId)
+        ? CLI_TOOL_PATTERN_TABLE[cliToolId]
+        : undefined;
 }
 /**
- * Antigravity (agy) skip patterns for response cleaning (Issue #988)
- * Filters turn/input-box separators, the bare ">" input prompt, the idle status
- * bar ("? for shortcuts ... <model>"), the thinking footer/spinner, banner block
- * art, and pasted-text markers from extracted responses.
- */
-exports.ANTIGRAVITY_SKIP_PATTERNS = [
-    exports.ANTIGRAVITY_SEPARATOR_PATTERN, // Turn + input-box separators (─ runs)
-    /^>\s*$/, // Bare input prompt line
-    /^\?\s+for\s+shortcuts/, // Idle status bar (model name follows on the same line)
-    exports.ANTIGRAVITY_THINKING_PATTERN, // Spinner / Generating / "esc to cancel" footer
-    /[▄▀█▌▐]/, // Banner block art (defensive; normally above the user-prompt anchor)
-    exports.PASTED_TEXT_PATTERN, // [Pasted text #N +XX lines]
-];
-/**
- * Command Code status-line spinner glyphs (Issue #2250).
- *
- * The complete `getWaveSymbol` frame set, read off the shipped bundle
- * (`command-code@1.40.1`, `dist/cli.mjs`):
- * `["·","○","◇","☆","✧","☆","◇","○","⌘"]` — six distinct glyphs, cycled.
- *
- * Deliberately NOT folded into {@link CLAUDE_SPINNER_CHARS}. Command Code marks
- * every assistant message with `⠶` (U+2836, see
- * {@link COMMAND_CODE_RESPONSE_MARKER_PATTERN}); adding that braille glyph to a
- * shared spinner class would make each reply's own first row read as "still
- * generating", and adding these glyphs to claude's class would do the same to
- * any claude reply that opens with `·`.
- */
-exports.COMMAND_CODE_SPINNER_CHARS = ['·', '○', '◇', '☆', '✧', '⌘'];
-/**
- * Command Code composer / dialog-cursor prompt pattern (Issue #2250).
- *
- * `❯` (U+276F) only — the ASCII `>` claude also accepts is not a glyph Command
- * Code 1.40.1 draws, and accepting it here would make every shell prompt and
- * every quoted diff line in a reply look like a composer.
- *
- * The row is drawn in two places, which is why prompt presence alone is not
- * "ready": the bottom-pinned composer (`❯ Ask your question...` between two
- * full-width rules) and the highlighted option of a permission dialog
- * (`❯ 1. Yes`). Completion is resolved structurally instead — see
- * {@link findCommandCodeChromeStart}.
- */
-exports.COMMAND_CODE_PROMPT_PATTERN = /^❯(\s*$|\s+\S)/m;
-/**
- * Command Code separator pattern (Issue #2250).
- *
- * Full-pane runs of U+2500 fence the composer above and below, and one more is
- * drawn above a permission dialog. Measured at 200 columns on every fixture in
- * `tests/fixtures/command-code-live-2250/`.
- */
-exports.COMMAND_CODE_SEPARATOR_PATTERN = /^─{10,}$/m;
-/**
- * Command Code status-line "esc to interrupt" hint (Issue #2250).
- *
- * The `Status` component renders `esc  to interrupt  •  <elapsed>  •  ↓ <tokens>`
- * only in its `"all"` layout, i.e. at a terminal width of 72 columns or more
- * (read off the bundle's `layoutMode` ladder; CommandMate panes are 200 wide, so
- * production always takes that branch). Below 42 columns the whole tail is
- * dropped and only the spinner + verb remain — which is why
- * {@link COMMAND_CODE_THINKING_PATTERN} keeps the spinner branch as well.
- */
-exports.COMMAND_CODE_INTERRUPT_HINT_PATTERN = /esc to interrupt/;
-/**
- * Command Code thinking/processing pattern (Issue #2250).
- *
- * Three measured alternatives:
- *
- *  1. the status row — a spinner glyph, then a single word ending in `…`
- *     (`⌘ Planning…`, `· Synthesizing…`; the bundle's verb table is 74
- *     single-word entries, all capitalised, but the class is left case-agnostic
- *     because the `status` prop is not restricted to that table). Anchored at
- *     the start of the line with only leading spaces allowed, so the `·` in the
- *     banner's
- *     `# models: … · taste-1` row and in the idle footer's
- *     `? for shortcuts · taste on` cannot reach it;
- *  2. `✻ Thinking…` — the reasoning block's header WHILE it streams. It becomes
- *     `✻ Thought for 1 second [ctrl+o to expand]` once the block is closed, and
- *     that past-tense form must NOT match: it sits in the transcript of every
- *     finished turn (`turn-version.txt`);
- *  3. {@link COMMAND_CODE_INTERRUPT_HINT_PATTERN}, unanchored, for the same
- *     reason claude's pattern carries it.
- */
-exports.COMMAND_CODE_THINKING_PATTERN = new RegExp(`^[^\\S\\n]*[${exports.COMMAND_CODE_SPINNER_CHARS.join('')}][^\\S\\n]+[A-Za-z]+…` +
-    `|^[^\\S\\n]*✻ Thinking…` +
-    `|${exports.COMMAND_CODE_INTERRUPT_HINT_PATTERN.source}`, 'm');
-/**
- * Command Code assistant-message marker (Issue #2250).
- *
- * `⠶` (U+2836) at column 0, one space, then the reply. Fixed, not a spinner
- * frame: the bundle declares it as `Ct() ? "⠶" : "#"`, i.e. one constant with an
- * ASCII fallback for terminals without unicode support. That answers 親 Issue
- * #2249's 未確定事項 1 — the glyph does not rotate — and it is also why the `#`
- * fallback is deliberately NOT matched here: on such a terminal it is
- * indistinguishable from the `# Command Code v1.40.1` banner rows.
- *
- * Continuation rows of a multi-line reply are indented by two spaces (the marker
- * is one column wide and the body box carries `marginLeft: 1`).
- */
-exports.COMMAND_CODE_RESPONSE_MARKER_PATTERN = /^⠶(?:\s|$)/;
-/**
- * Command Code turn-completion marker (Issue #2250).
- *
- * **Advisory only — never require it to declare a turn finished.** Two measured
- * reasons: `WorkedDurationNote` renders nothing for a turn under 1000 ms, and
- * the row belongs to the live turn's UI rather than to the transcript — it is
- * present in `turn-version.txt` and GONE from `dialog-create-file.txt`, which is
- * the same pane one prompt later.
- */
-exports.COMMAND_CODE_COMPLETION_PATTERN = /^[^\S\n]*✻ Worked for /m;
-/**
- * Command Code footer mode indicator (Issue #2250).
- *
- * The row under the composer's closing rule. `? for shortcuts` is only the
- * DEFAULT-mode spelling: the bundle's `ModeIndicator` swaps it for a mode banner
- * in the other four permission modes, so a rule that keys on `? for shortcuts`
- * alone would stop recognising an idle pane the moment the operator pressed
- * shift+tab. All five spellings are listed.
- */
-exports.COMMAND_CODE_MODE_INDICATOR_PATTERN = /\?\s+for\s+shortcuts|»\s+accept edits on|»\s+permission bypass on|»\s+don't-ask on|^[^\S\n]*plan mode\s/m;
-/**
- * Command Code startup banner rows (Issue #2250).
- *
- * The three-row header under the block-art logo — `# Command Code v1.40.1`,
- * `# models: …`, `# <cwd>` — plus the logo itself.
- *
- * The version row matches the tool's own NAME and version together, which is the
- * shape #2247 had to retreat to on claude: a bare `v\d+\.\d+` matched any reply
- * that mentioned a release, and the turn was silently dropped. Nothing here
- * matches a bare version string, a `│` table glyph, or a `Tip:` line.
- */
-exports.COMMAND_CODE_BANNER_PATTERNS = [
-    /^#\s+Command Code v\d/, // Name + version, together
-    /^#\s+models:\s/, // Model line
-    /^#\s+[~/]/, // Working-directory line
-    /^[^\S\n]*[█▀▄▌▐]{3,}/, // Block-art logo rows
-];
-/**
- * Command Code hook notice row (Issue #2250).
- *
- * `◼ Ran 1 session start hook` — emitted into the transcript when SessionStart
- * hooks fire, so it lands ABOVE the first user echo and is chrome, not a reply.
- * Measured on a hooks-enabled 1.40.1 pane while capturing #2249's evidence.
- * Command Code's hook wiring itself is Phase B (#2251); this row only has to be
- * kept out of History.
- */
-exports.COMMAND_CODE_HOOK_NOTICE_PATTERN = /^[^\S\n]*◼\s+Ran\s+\d+\s+.*hooks?\b/;
-/** How far above the last row Command Code's footer row may sit. */
-const COMMAND_CODE_FOOTER_MAX_ROWS = 4;
-/** How many rows the composer may span before the block stops looking like chrome. */
-const COMMAND_CODE_INPUT_BOX_MAX_ROWS = 40;
-/**
- * Locate the start of Command Code's bottom-pinned chrome within a captured pane.
- *
- * Command Code is inline-rendered, so its transcript grows downwards and the
- * last four rows of a settled pane are always the same four (measured on
- * `boot-idle.txt`, `turn-version.txt` and `turn-tool-write.txt`):
- *
- * ```text
- * ────────────────────  ← opening rule
- * ❯ Ask your question…  ← composer (one row per wrapped line)
- * ────────────────────  ← closing rule
- *   ? for shortcuts · taste on
- * ```
- *
- * Everything from the opening rule down is terminal furniture. Two things go
- * wrong if it reaches the extractor, and both are regressions this repository
- * has already paid for once: the composer's placeholder is drawn with the same
- * `❯ <text>` shape as a transcript echo, so the turn anchor lands on the FOOTER
- * and the reply extracts as empty (#1289); and the footer row is repainted while
- * the pane sits idle, so keeping it re-hashes the saved response on every poll
- * tick (#1268 / #1289).
- *
- * Structural, like the three readers next to it, and for the reason spelled out
- * on `findClaudeChromeStart`: the hint strings belong to Command Code and a rule
- * that matches them stops working the moment they are reworded. `-1` is the
- * honest answer for a frame with no composer at all — while a permission dialog
- * is up the whole block is replaced by the dialog, which the caller resolves on
- * the prompt path instead.
- *
- * @param lines - Captured pane lines, ANSI-bearing or not; trailing blanks tolerated
- * @returns Index of the opening rule, or -1 when no composer block is present
+ * Row for a tool id. An id outside CLI_TOOL_IDS (possible at runtime) falls back
+ * to claude's row, as the former `default` branches did.
  */
-function findCommandCodeChromeStart(lines) {
-    const isSeparator = (line) => /^─{10,}$/.test((0, ansi_1.stripAnsi)(line ?? '').trimEnd());
-    let lastRow = lines.length - 1;
-    while (lastRow >= 0 && lines[lastRow].trim() === '')
-        lastRow--;
-    if (lastRow < 0)
-        return -1;
-    // The closing rule sits just above the mode-indicator row.
-    let closingSeparator = -1;
-    for (let i = lastRow; i >= Math.max(0, lastRow - COMMAND_CODE_FOOTER_MAX_ROWS); i--) {
-        if (isSeparator(lines[i])) {
-            closingSeparator = i;
-            break;
-        }
-    }
-    if (closingSeparator < 0)
-        return -1;
-    // Walk up over the composer rows to the opening rule.
-    let openingSeparator = -1;
-    for (let i = closingSeparator - 1; i >= Math.max(0, closingSeparator - COMMAND_CODE_INPUT_BOX_MAX_ROWS); i--) {
-        if (isSeparator(lines[i])) {
-            openingSeparator = i;
-            break;
-        }
-    }
-    if (openingSeparator < 0)
-        return -1;
-    // Confirm the fenced rows are the composer and not a reply that happens to
-    // contain two horizontal rules.
-    if (!/^❯/.test((0, ansi_1.stripAnsi)(lines[openingSeparator + 1] ?? '')))
-        return -1;
-    return openingSeparator;
+function patternRowFor(cliToolId) {
+    return ownRowFor(cliToolId) ?? CLI_TOOL_PATTERN_TABLE.claude;
 }
-/**
- * Command Code skip patterns for response cleaning (Issue #2250).
- *
- * The dedicated cleaner Issue #2250 item 8 asks for: the startup banner, the
- * hook notice, the reasoning and turn summaries (`✻ Thought for` / `✻ Worked
- * for`), the composer, the rules and the footer.
- *
- * Nothing here touches the reply body or a tool block: `⠶ <text>`, ` WRITE
- * [probe.txt]`, ` └  Created probe.txt (1 line)` and `     1 │ hello` all
- * survive (`turn-tool-write.txt`). In particular there is no `^\s*│` rule — the
- * one codex carries — because Command Code renders file previews with it.
- */
-exports.COMMAND_CODE_SKIP_PATTERNS = [
-    /^─{10,}$/, // Composer rules and the dialog's rule
-    /^❯\s*$/, // Bare composer row
-    /^❯\s+Ask your question\.\.\./, // Composer placeholder
-    exports.COMMAND_CODE_MODE_INDICATOR_PATTERN, // Footer mode indicator
-    exports.COMMAND_CODE_THINKING_PATTERN, // Status row
-    /^[^\S\n]*✻\s+(?:Worked|Thought)\s+for\b/, // Turn / reasoning summaries
-    exports.COMMAND_CODE_HOOK_NOTICE_PATTERN, // "◼ Ran N session start hook"
-    ...exports.COMMAND_CODE_BANNER_PATTERNS, // Startup banner
-    exports.PASTED_TEXT_PATTERN, // [Pasted text #N +XX lines]
-];
 /**
  * Detect if CLI tool is showing "thinking" indicator
  */
 function detectThinking(cliToolId, content) {
     const log = logger.withContext({ cliToolId });
     log.debug('detectThinking:check', { contentLength: content.length });
-    let result;
-    switch (cliToolId) {
-        case 'claude':
-            result = exports.CLAUDE_THINKING_PATTERN.test(content);
-            break;
-        case 'codex':
-            result = exports.CODEX_THINKING_PATTERN.test(content);
-            break;
-        case 'gemini':
-            result = exports.GEMINI_THINKING_PATTERN.test(content);
-            break;
-        case 'vibe-local':
-            result = exports.VIBE_LOCAL_THINKING_PATTERN.test(content);
-            break;
-        case 'opencode':
-            result = exports.OPENCODE_THINKING_PATTERN.test(content);
-            break;
-        case 'copilot':
-            result = exports.COPILOT_THINKING_PATTERN.test(content);
-            break;
-        case 'antigravity':
-            result = exports.ANTIGRAVITY_THINKING_PATTERN.test(content);
-            break;
-        case 'command-code':
-            result = exports.COMMAND_CODE_THINKING_PATTERN.test(content);
-            break;
-        case 'opencode-v2':
-            result = exports.OPENCODE_V2_THINKING_PATTERN.test(content);
-            break;
-        default:
-            result = exports.CLAUDE_THINKING_PATTERN.test(content);
-    }
+    const result = patternRowFor(cliToolId).thinkingPattern.test(content);
     log.debug('detectThinking:result', { isThinking: result });
     return result;
 }
@@ -2838,190 +383,20 @@ function detectThinking(cliToolId, content) {
  * Get CLI tool patterns for response extraction
  */
 function getCliToolPatterns(cliToolId) {
-    switch (cliToolId) {
-        case 'claude':
-            return {
-                promptPattern: exports.CLAUDE_PROMPT_PATTERN,
-                separatorPattern: exports.CLAUDE_SEPARATOR_PATTERN,
-                thinkingPattern: exports.CLAUDE_THINKING_PATTERN,
-                skipPatterns: [
-                    /^─{10,}$/, // Separator lines
-                    /^[>❯]\s*$/, // Prompt line (legacy '>' and new '❯')
-                    exports.CLAUDE_THINKING_PATTERN, // Thinking indicators
-                    /^\s*[⎿⏋]\s+Tip:/, // Tip lines
-                    /^\s*Tip:/, // Tip lines
-                    /^\s*\?\s*for shortcuts/, // Shortcuts hint
-                    /to interrupt\)/, // Part of "esc to interrupt" message
-                    exports.PASTED_TEXT_PATTERN, // [Pasted text #N +XX lines] (Issue #212)
-                ],
-            };
-        case 'codex':
-            return {
-                promptPattern: exports.CODEX_PROMPT_PATTERN,
-                separatorPattern: exports.CODEX_SEPARATOR_PATTERN,
-                thinkingPattern: exports.CODEX_THINKING_PATTERN,
-                skipPatterns: [
-                    /^─.*─+$/, // Separator lines
-                    /^›\s*$/, // Empty prompt line
-                    /^›\s+(Implement|Find and fix|Type)/, // New prompt suggestions
-                    exports.CODEX_THINKING_PATTERN, // Activity indicators
-                    /^\s*\d+%\s+context left/, // Context indicator
-                    /^\s*for shortcuts$/, // Shortcuts hint
-                    /╭─+╮/, // Box drawing (top)
-                    /╰─+╯/, // Box drawing (bottom)
-                    // T1.3: Additional skip patterns for Codex
-                    /•\s*Ran\s+/, // Command execution lines
-                    /^\s*└/, // Tree output (completion indicator)
-                    /^\s*│/, // Continuation lines
-                    /\(.*esc to interrupt\)/, // Interrupt hint
-                    exports.PASTED_TEXT_PATTERN, // [Pasted text #N +XX lines] (Issue #212, defensive)
-                ],
-            };
-        case 'gemini':
-            return {
-                promptPattern: exports.GEMINI_PROMPT_PATTERN,
-                separatorPattern: /^[─━]{3,}$/m,
-                thinkingPattern: exports.GEMINI_THINKING_PATTERN,
-                skipPatterns: [
-                    exports.GEMINI_PROMPT_PATTERN, // Prompt line (DRY: shared with GEMINI_PROMPT_PATTERN)
-                    exports.GEMINI_THINKING_PATTERN, // Thinking indicators
-                    /^\s*$/, // Empty lines
-                    /Gemini\s+\d+\.\d+/, // Version line
-                    exports.PASTED_TEXT_PATTERN, // [Pasted text #N +XX lines]
-                ],
-            };
-        case 'vibe-local':
-            return {
-                promptPattern: exports.VIBE_LOCAL_PROMPT_PATTERN,
-                separatorPattern: /^[·]{10,}$/m, // vibe-local uses middle dot separators
-                thinkingPattern: exports.VIBE_LOCAL_THINKING_PATTERN,
-                skipPatterns: [
-                    exports.VIBE_LOCAL_PROMPT_PATTERN, // Prompt line (ctx:N% ❯)
-                    exports.VIBE_LOCAL_THINKING_PATTERN, // Thinking indicators
-                    /^\s*$/, // Empty lines
-                    /vibe-local|vibe-coder/, // Version/banner lines
-                    /ctx:\s*\d+%/, // Context usage indicator
-                    /Model\s+\w/, // Model info line
-                    /Engine\s+\w/, // Engine info line
-                    /Mode\s+/, // Mode info line
-                    /RAM\s+/, // RAM info line
-                    /CWD\s+/, // Working directory line
-                    /^[·]{10,}$/, // Middle dot separator lines
-                    /✦\s*Ready/, // Status bar "Ready" indicator
-                    /ESC:\s*stop/, // Status bar "ESC: stop" hint
-                    exports.PASTED_TEXT_PATTERN, // [Pasted text #N +XX lines]
-                ],
-            };
-        case 'opencode':
-            return {
-                promptPattern: exports.OPENCODE_PROMPT_PATTERN,
-                separatorPattern: exports.OPENCODE_SEPARATOR_PATTERN,
-                thinkingPattern: exports.OPENCODE_THINKING_PATTERN,
-                skipPatterns: [...exports.OPENCODE_SKIP_PATTERNS],
-            };
-        case 'copilot':
-            return {
-                promptPattern: exports.COPILOT_PROMPT_PATTERN,
-                separatorPattern: exports.COPILOT_SEPARATOR_PATTERN,
-                thinkingPattern: exports.COPILOT_THINKING_PATTERN,
-                skipPatterns: [...exports.COPILOT_SKIP_PATTERNS],
-            };
-        case 'antigravity':
-            return {
-                promptPattern: exports.ANTIGRAVITY_PROMPT_PATTERN,
-                separatorPattern: exports.ANTIGRAVITY_SEPARATOR_PATTERN,
-                thinkingPattern: exports.ANTIGRAVITY_THINKING_PATTERN,
-                skipPatterns: [...exports.ANTIGRAVITY_SKIP_PATTERNS],
-            };
-        // Issue #2250: Command Code's layout is claude-shaped (inline transcript,
-        // `❯` composer fenced by two full-width rules) but the constants are its
-        // own. Sharing claude's would import the exact defect #2247 had to undo --
-        // claude's rules carry a startup-banner reading that keys on `v\d+\.\d+`
-        // and `|`, and Command Code prints its version into a `# Command Code
-        // v1.40.1` row on every launch.
-        case 'command-code':
-            return {
-                promptPattern: exports.COMMAND_CODE_PROMPT_PATTERN,
-                separatorPattern: exports.COMMAND_CODE_SEPARATOR_PATTERN,
-                thinkingPattern: exports.COMMAND_CODE_THINKING_PATTERN,
-                skipPatterns: [...exports.COMMAND_CODE_SKIP_PATTERNS],
-            };
-        // Issue #2934: OpenCode V2's own constants (see OPENCODE_V2_* above). The
-        // separator row is the same half-block rule v1 draws, so v1's pattern is
-        // reused as a value; nothing of v1's is changed.
-        case 'opencode-v2':
-            return {
-                promptPattern: exports.OPENCODE_V2_IDLE_COMPOSER_PATTERN,
-                separatorPattern: exports.OPENCODE_SEPARATOR_PATTERN,
-                thinkingPattern: exports.OPENCODE_V2_THINKING_PATTERN,
-                skipPatterns: [...exports.OPENCODE_V2_SKIP_PATTERNS],
-            };
-        default:
-            // Default to Claude patterns
-            return getCliToolPatterns('claude');
-    }
+    const row = patternRowFor(cliToolId);
+    return {
+        promptPattern: row.promptPattern,
+        separatorPattern: row.separatorPattern,
+        thinkingPattern: row.thinkingPattern,
+        skipPatterns: [...row.skipPatterns],
+    };
 }
 // ANSI primitives live in a dependency-free leaf module so client components can
 // reuse the same tested pattern without pulling this file's server-only imports
 // (logger/db) into the browser bundle. Re-exported here for existing importers.
-var ansi_2 = require("./ansi");
-Object.defineProperty(exports, "stripAnsi", { enumerable: true, get: function () { return ansi_2.stripAnsi; } });
-Object.defineProperty(exports, "extractAnsiSequences", { enumerable: true, get: function () { return ansi_2.extractAnsiSequences; } });
-/**
- * Strip box-drawing border characters from CLI output.
- * Gemini CLI wraps Action Required prompts in ╭─╮│╰─╯ borders.
- * Removes │ (U+2502) prefix/suffix and border-only lines (╭╮╰╯─).
- *
- * @param str - Input string (typically after stripAnsi())
- * @returns String with box-drawing borders removed
- */
-function stripBoxDrawing(str) {
-    return str.split('\n').map(line => {
-        // Remove border-only lines (╭──╮, ╰──╯, │ only, ┃ only, ╹▀▀▀, █ scrollbar, etc.)
-        // U+2502 │ (light vertical), U+2503 ┃ (heavy vertical - OpenCode TUI)
-        // U+2579 ╹ (heavy up), U+2580 ▀ (upper half block - OpenCode separator)
-        // U+2588 █ (full block - OpenCode scrollbar)
-        if (/^[\u2502\u2503\u256D\u256E\u256F\u2570\u2500\u2579\u2580\u2588\s]+$/.test(line))
-            return '';
-        // Strip leading whitespace + │/┃ + optional space, trailing space + │/┃/█
-        // OpenCode TUI adds 2-space padding before ┃ borders (e.g., "  ┃  content")
-        // OpenCode scrollbar █ appears at end of content lines
-        return line.replace(/^\s*[\u2502\u2503]\s?/, '').replace(/\s*[\u2502\u2503\u2588]$/, '');
-    }).join('\n');
-}
-/**
- * Error patterns that indicate a Claude session failed to start properly
- * Used by isSessionHealthy() to detect broken sessions (MF-001: SRP)
- * Style: readonly + as const for type safety (SF-S2-001: follows response-poller.ts precedent)
- *
- * SEC-SF-004: Pattern maintenance process:
- * - When Claude CLI is updated, verify that error messages still match these patterns.
- * - Test procedure: Intentionally trigger each error condition (e.g., nested session launch)
- *   and confirm the error message is captured by the patterns.
- * - If Claude CLI introduces localized error messages, add locale-aware patterns or
- *   consider switching to exit code-based detection as a more robust alternative.
- * - Pattern additions should be accompanied by corresponding test cases in
- *   claude-session.test.ts.
- *
- * C-S3-001: Codex/Gemini monitoring note:
- * These patterns are currently Claude-specific. If Codex or Gemini exhibit similar
- * "nested session" or startup failure behaviors, analogous error patterns should be
- * added to their respective tool configurations (codex.ts, gemini.ts) rather than
- * extending these arrays, to maintain SRP per CLI tool type.
- */
-exports.CLAUDE_SESSION_ERROR_PATTERNS = [
-    'Claude Code cannot be launched inside another Claude Code session',
-];
-/**
- * Regex patterns for Claude session errors requiring context matching
- * Used by isSessionHealthy() for multi-condition error detection (MF-001: SRP)
- * Style: readonly + as const for type safety (SF-S2-001: follows response-poller.ts precedent)
- *
- * SEC-SF-004: See CLAUDE_SESSION_ERROR_PATTERNS JSDoc for pattern maintenance process.
- */
-exports.CLAUDE_SESSION_ERROR_REGEX_PATTERNS = [
-    /^Error:.*Claude Code/,
-];
+var ansi_1 = require("./ansi");
+Object.defineProperty(exports, "stripAnsi", { enumerable: true, get: function () { return ansi_1.stripAnsi; } });
+Object.defineProperty(exports, "extractAnsiSequences", { enumerable: true, get: function () { return ansi_1.extractAnsiSequences; } });
 /**
  * Build DetectPromptOptions for a given CLI tool.
  * Centralizes cliToolId-to-options mapping logic (DRY - MF-001).
@@ -3029,73 +404,25 @@ exports.CLAUDE_SESSION_ERROR_REGEX_PATTERNS = [
  * prompt-detector.ts remains CLI tool independent (Issue #161 principle);
  * this function lives in cli-patterns.ts which already depends on CLIToolType.
  *
- * [Future extension memo (C-002)]
- * If CLI tool count grows significantly (currently 6), consider migrating
- * to a CLIToolConfig registry pattern where tool-specific settings
- * (including promptDetectionOptions) are managed in a Record<CLIToolType, CLIToolConfig>.
- * Migration threshold: 7th tool addition triggers registry pattern migration [D1-003].
+ * [Extension memo (C-002) — carried out]
+ * The memo asked for a registry pattern where tool-specific settings
+ * (including promptDetectionOptions) are managed in a Record<CLIToolType, ...>,
+ * with the 7th tool as the migration threshold [D1-003]. There are 9 tools
+ * today, and Issue #3230 made the move: the settings are the `promptOptions`
+ * column of CLI_TOOL_PATTERN_TABLE.
  *
  * @param cliToolId - CLI tool identifier
  * @returns DetectPromptOptions for the tool, or undefined for default behavior
  */
 function buildDetectPromptOptions(cliToolId) {
-    if (cliToolId === 'claude') {
-        return { requireDefaultIndicator: false };
-    }
-    // [D2-006] OpenCode prompt "Ask anything..." does not use standard indicators (> / ❯),
-    // so requireDefaultIndicator must be false to avoid missing prompt detection.
-    //
-    // [Issue #1896] `hasNumberedDialogs: false` -- opencode 1.18 renders NO dialog
-    // that a typed number drives, so the generic numbered-list inference has
-    // nothing to find on its pane and every hit it scored was transcript text.
-    // Its two interactive surfaces were both measured at the production 80x200
-    // geometry and both are cursor-driven:
-    //
-    //  - the permission dialog is a horizontal button strip
-    //    ({@link OPENCODE_PERMISSION_PATTERN}, Issue #1893) driven by ←/→ + Enter;
-    //    typing a number does nothing to it.
-    //  - the pickers (`/models`, `/providers`, `/connect`, and the ctrl+p command
-    //    palette) are fuzzy-search lists driven by ↑/↓ + Enter, with no numbers
-    //    drawn at all. The first three are what
-    //    {@link OPENCODE_SELECTION_LIST_PATTERN} names; the palette shares the
-    //    chrome but not the header allowlist, and lands on `running` / `default`.
-    //
-    // Both keep their own POSITIVE detection in `status-detector.ts`, so `wait`
-    // still stops for them (exit 10 via `isSelectionListActive`) and the UI still
-    // renders NavigationButtons: nothing that could be answered before stops being
-    // answered. What ends is the false positive -- a response whose body ends in
-    // `1. / 2. / 3.` + a question was published as
-    // `waiting`/`prompt_detected`/`hasActivePrompt: true`, and Auto-Yes typed `1`
-    // into the composer and SENT IT as a user utterance (Issue #1896).
-    //
-    // `requireDefaultIndicator` is kept at its D2-006 value: it is the correct
-    // setting for opencode's ❯-less rendering should the numbered path ever be
-    // re-enabled, and it still describes the tool.
-    if (cliToolId === 'opencode') {
-        return { requireDefaultIndicator: false, hasNumberedDialogs: false };
-    }
-    // [Issue #545] Copilot prompt pattern may not use standard indicators
-    if (cliToolId === 'copilot') {
-        return { requireDefaultIndicator: false };
-    }
-    // [Issue #999] Antigravity (agy) permission-approval menus highlight the
-    // default with an ASCII ">" (0x3E), not the "❯/●/›" indicators that
-    // DEFAULT_OPTION_PATTERN recognizes, and their footer is "↑/↓ Navigate"
-    // (no "press enter to confirm"). Under the default requireDefaultIndicator=true
-    // the Pass 1 gate rejects these menus, so Auto-Yes never responds. Treat agy
-    // like claude/opencode/copilot so Pass 2 collects its "1. Yes / … / N. No"
-    // options and reports isPrompt=true.
-    //
-    // [Issue #2364] The `↑/↓ Navigate` dialogs themselves no longer reach
-    // `detectPrompt` on either production path: `tools/antigravity/detect.ts`
-    // (status) and `detectPromptWithOptions` (response poller) both read them
-    // with `detectAntigravityNumberedDialogPrompt` first, because the generic
-    // multiple-choice pass reads one row per option and agy wraps a long command
-    // across several rows of one label. What this setting still serves is every
-    // OTHER numbered agy screen — `/feedback`'s `1-6 Select & Continue` menu is
-    // the measured one — which the generic pass reads as before.
-    if (cliToolId === 'antigravity') {
-        return { requireDefaultIndicator: false };
-    }
-    return undefined; // Default behavior (requireDefaultIndicator = true)
+    // Fresh object per call (callers may mutate); an id outside the table yields undefined.
+    const options = ownRowFor(cliToolId)?.promptOptions;
+    return options === undefined ? undefined : { ...options };
+}
+/**
+ * Whether a tool hands the FULL frame to `detectPrompt` instead of the 15-line tail.
+ * An id outside the table answers false.
+ */
+function usesFullFramePrompt(cliToolId) {
+    return ownRowFor(cliToolId)?.fullFramePrompt ?? false;
 }