commandmate 0.26.1 → 0.27.1

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

@@ -0,0 +1,89 @@
+"use strict";
+/**
+ * GitHub Copilot CLI's positive dialog detection (Issue #1928, 方針書 §4 D1 決定 4).
+ *
+ * ## The one thing that makes copilot safe to read: the bottom row
+ *
+ * copilot 1.0.80 paints a status bar on the bottom row of the pane and nothing
+ * else there — key hints when idle, `● Working … esc interrupt` while it
+ * generates. A dialog or a picker takes that row AWAY (its box, or the picker's
+ * own footer, occupies the bottom of the pane), which is why
+ * `readCopilotStatusBar` answering `null` is the positional guard everything
+ * below rests on.
+ *
+ * It has to be positional, because copilot's own answer text can forge every
+ * textual anchor on this frame. Two live captures in the repository prove it:
+ * `status-vocabulary-in-response.txt` (copilot printed ` ● Working esc
+ * interrupt` as body text) and `picker-vocabulary-in-response.txt` (it printed a
+ * picker's footer as body text). On both, the status bar is still drawn, so this
+ * module declines them before it looks at a single word — the same argument
+ * Issue #1885 made for the status branches and Issue #1895 for the picker one.
+ *
+ * ## What was measured (copilot-cli 1.0.80, 200x1000 pane)
+ *
+ * | frame                                       | bottom row      | block          | footer                                                        |
+ * |---------------------------------------------|-----------------|----------------|---------------------------------------------------------------|
+ * | `copilot-live-1885/permission-dialog.txt`   | box border      | `❯ 1. Yes` ×3  | `↑/↓ to navigate · enter to select · esc to cancel`            |
+ * | `copilot-picker-1895/picker-permissions.txt`| picker footer   | `❯ 1. Manual` ×2 | `1-2 to select · ↑/↓ to navigate · enter to confirm · esc to cancel` |
+ * | `copilot-picker-1895/picker-theme.txt`      | picker footer   | 5 options      | `↑/↓ to navigate · …`                                          |
+ * | `copilot-live-1885/turn-complete.txt`       | **idle bar**    | the agent's own `1. … 4.` essay | prose                                     |
+ *
+ * The last row is the reason the guard is not optional: copilot's finished reply
+ * is a four-item numbered list whose first item carries a `●` bullet, so the
+ * block reader finds a "selected option 1" on it. The status bar is what tells
+ * the two apart, and it costs one comparison.
+ *
+ * `1-2 to select` in the picker footer is also a measurement worth keeping: it
+ * is copilot stating, in its own UI, that these menus take a typed number.
+ */
+Object.defineProperty(exports, "__esModule", { value: true });
+exports.detectCopilotDialog = detectCopilotDialog;
+const cli_patterns_1 = require("../../cli-patterns");
+const dialog_block_1 = require("../dialog-block");
+/** copilot's permission question, in the spelling 1.0.80 draws. */
+const COPILOT_PERMISSION_QUESTION_PATTERN = /do you want to\b/i;
+/** How many non-blank rows above the options may hold the question. */
+const QUESTION_SCAN_ROWS = 4;
+function readContextAbove(lines, firstRow) {
+    const rows = [];
+    for (let i = firstRow - 1; i >= 0 && rows.length < QUESTION_SCAN_ROWS; i--) {
+        const row = lines[i].trim();
+        if (row === '')
+            continue;
+        rows.push(row);
+    }
+    return rows.join('\n');
+}
+/**
+ * Does this frame carry a copilot dialog?
+ *
+ * @param frame - The normalised capture
+ * @param context - What `detect.ts` measured; see {@link CopilotDialogContext}
+ */
+function detectCopilotDialog(frame, context) {
+    // The positional guard. While copilot draws its status bar, whatever else is
+    // on the pane is transcript.
+    if (context.statusBar !== null)
+        return null;
+    const lines = (0, cli_patterns_1.stripBoxDrawing)(frame.clean).split('\n');
+    const block = (0, dialog_block_1.findNumberedOptionBlock)(lines, context.contentEnd);
+    if (block && cli_patterns_1.COPILOT_SELECTION_FOOTER_PATTERN.test(block.footer)) {
+        const question = readContextAbove(lines, block.firstRow);
+        const isTrust = cli_patterns_1.COPILOT_FOLDER_TRUST_ANCHORS.some(anchor => question.includes(anchor));
+        const kind = isTrust
+            ? 'trust'
+            : COPILOT_PERMISSION_QUESTION_PATTERN.test(question)
+                ? 'permission'
+                : 'picker';
+        return { kind, options: block.options, answerMode: 'numbered' };
+    }
+    // A picker copilot draws WITHOUT numbers (`/model`, `/agent`, `/skills` …).
+    // Reported so the frame is not mistaken for one nobody could read, but with
+    // no options and `keys`: nothing here can be answered by sending text, and
+    // Issue #1895's probe measured that a string typed at an open picker is not
+    // swallowed — it starts a session with that string as the prompt.
+    if (context.selectionFrame) {
+        return { kind: 'picker', options: [], answerMode: 'keys' };
+    }
+    return null;
+}

package/dist/server/src/lib/detection/tools/dialog-block.js

@@ -0,0 +1,159 @@
+"use strict";
+/**
+ * The one reader of a numbered option block, shared by every tool's
+ * `prompt.ts` (Issue #1928, 方針書 §4 D1 決定 4).
+ *
+ * Every CLI in the registry draws its dialogs the same shape — a question, a run
+ * of `1. / 2. / 3.` rows with the highlighted one carrying a selection glyph,
+ * and (usually) a footer naming the keys it takes. What differs per tool is
+ * WHERE that block is allowed to sit and WHICH footer vouches for it, and those
+ * are the two things a tool module states for itself. The parsing in between is
+ * identical, and writing it seven times would be seven chances to disagree about
+ * what an option row is.
+ *
+ * ## Why this is not `detectPrompt`
+ *
+ * `detectPrompt` answers "could a human answer something on this frame?" from
+ * the text alone, which is exactly the generic inference §4 D1 決定 4 says
+ * Auto-Yes may not fire on: an agent that *quotes* a numbered list in its reply
+ * satisfies it (#1896). This module is deliberately dumber — it finds a block
+ * and reports what it found, including the selection glyph and the rows
+ * underneath it — and leaves the judgement to the tool module, which is the only
+ * place that knows whether that position and that footer are its own dialog.
+ *
+ * ## Input contract
+ *
+ * Rows must be ANSI-stripped. They MAY still carry box drawing, and they may
+ * equally have had it removed already: the Auto-Yes poller hands the detector a
+ * frame that has been through `stripBoxDrawing(stripAnsi(...))`, while
+ * `detectSessionStatus` hands it one that has not. Nothing here reads a gutter
+ * glyph or an SGR attribute, so both spellings parse to the same block.
+ */
+Object.defineProperty(exports, "__esModule", { value: true });
+exports.findNumberedOptionBlock = findNumberedOptionBlock;
+/**
+ * One numbered option row.
+ *
+ * `[❯›●>]` is the union of the selection glyphs measured across the registry:
+ * claude and copilot draw `❯`, codex draws `›`, antigravity draws the ASCII `>`
+ * (Issue #999), and `●` appears as the filled-radio spelling. The glyph is
+ * OPTIONAL here because only the highlighted row wears it; whether its presence
+ * is required at all is the tool module's call.
+ *
+ * A leading `│`/`┃` is accepted so a frame whose box drawing is still attached
+ * parses to the same block as one whose gutter has been removed.
+ *
+ * No `/g` (keeps `.test()` stateless) and no nested quantifiers (ReDoS-safe).
+ */
+const OPTION_ROW_PATTERN = /^[^\S\n]*[│┃]?[^\S\n]*([❯›●>])?[^\S\n]*(\d{1,2})[.)][^\S\n]+(\S.*?)[^\S\n]*[│┃]?$/;
+/**
+ * How far above `endExclusive` the bottom-most option row may sit.
+ *
+ * Generous because the footer between the block and the region end is a couple
+ * of rows at most on every measured frame, and because a frame captured
+ * mid-repaint can put a blank row or two in there. Bounded at all so a numbered
+ * list hundreds of rows up in a transcript cannot be adopted as "the dialog on
+ * this frame".
+ */
+const DEFAULT_FOOTER_SCAN_ROWS = 8;
+/** How many rows one option block may span, wrapped continuations included. */
+const MAX_BLOCK_ROWS = 60;
+function parseOptionRow(row) {
+    const match = OPTION_ROW_PATTERN.exec(row);
+    if (!match)
+        return null;
+    const number = Number(match[2]);
+    if (!Number.isInteger(number) || number < 1)
+        return null;
+    return { glyph: match[1], number, label: match[3].trim() };
+}
+/**
+ * Find the bottom-most run of numbered options ending at or above
+ * `endExclusive`.
+ *
+ * The run must descend to `1.` without a gap — `3. / 2. / 1.` reading upwards —
+ * and must hold at least two options. Both are guards against the same false
+ * positive: an ordinary sentence beginning `2020. ` is a single row with no `1.`
+ * above it, and a one-option "dialog" is not a choice.
+ *
+ * Blank rows inside the run are skipped (claude puts one between its question
+ * and its options and copilot puts one before its footer). A non-blank row that
+ * is not an option row is taken as the WRAPPED TAIL of the option above it —
+ * codex and copilot both wrap a long command onto a second row, and dropping it
+ * would truncate the label `respond` shows the operator. Nothing bad comes of
+ * being permissive there: the run still has to reach `1.` within
+ * {@link MAX_BLOCK_ROWS}, so prose that merely sits above a `2. / 1.` pair is
+ * bounded, and every caller additionally requires its own footer or selection
+ * glyph before treating the result as a dialog.
+ *
+ * @param lines - ANSI-stripped rows, box drawing optional
+ * @param endExclusive - Exclusive upper bound; the tool module's region end
+ * @param footerScanRows - How many non-blank rows below the block to accept as
+ *   its footer before giving up on finding one
+ * @returns The block, or null when the region holds no numbered choice
+ */
+function findNumberedOptionBlock(lines, endExclusive, footerScanRows = DEFAULT_FOOTER_SCAN_ROWS) {
+    const end = Math.min(endExclusive, lines.length);
+    // 1. Walk up through the footer zone to the bottom-most option row.
+    let cursor = end - 1;
+    let scanned = 0;
+    const footerRows = [];
+    let bottom = null;
+    while (cursor >= 0 && scanned <= footerScanRows) {
+        const row = lines[cursor];
+        if (row.trim() === '') {
+            cursor--;
+            continue;
+        }
+        scanned++;
+        bottom = parseOptionRow(row);
+        if (bottom)
+            break;
+        footerRows.unshift(row.trim());
+        cursor--;
+    }
+    if (!bottom)
+        return null;
+    const lastRow = cursor;
+    // 2. Walk up the run, collecting each option and any wrapped rows above it.
+    const collected = [bottom];
+    let expected = bottom.number - 1;
+    let row = cursor - 1;
+    let spanned = 1;
+    // Rows seen since the last option row. They are the wrapped tail of the option
+    // ABOVE them, which the walk has not reached yet — attaching them to the one
+    // below (the last entry of `collected`) would move a long command onto the
+    // wrong choice, which is the label `respond` shows the operator.
+    let pending = [];
+    while (expected >= 1 && row >= 0 && spanned <= MAX_BLOCK_ROWS) {
+        const text = lines[row];
+        spanned++;
+        if (text.trim() === '') {
+            row--;
+            continue;
+        }
+        const parsed = parseOptionRow(text);
+        if (parsed && parsed.number === expected) {
+            collected.unshift({ ...parsed, label: [parsed.label, ...pending].join(' ').trim() });
+            pending = [];
+            expected--;
+            row--;
+            continue;
+        }
+        if (parsed)
+            break; // a numbered row out of sequence — not this block
+        pending.unshift(text.trim());
+        row--;
+    }
+    if (expected !== 0 || collected.length < 2)
+        return null;
+    const selectedIndex = collected.findIndex(option => option.glyph !== undefined);
+    return {
+        options: collected.map(option => option.label),
+        selectedIndex,
+        selectedGlyph: selectedIndex < 0 ? null : (collected[selectedIndex].glyph ?? null),
+        firstRow: row + 1,
+        lastRow,
+        footer: footerRows.join('\n'),
+    };
+}

package/dist/server/src/lib/detection/tools/frame.js

@@ -0,0 +1,47 @@
+"use strict";
+/**
+ * Normalise a capture once, for every branch of the detection chain
+ * (Issue #1927).
+ *
+ * Lifted verbatim out of the head of `detectSessionStatus`, where the same six
+ * projections were computed inline and then threaded through a thousand lines of
+ * per-tool branches. Nothing about the arithmetic changed; what changed is that
+ * a tool module can now be handed the frame instead of recomputing its own idea
+ * of where the content ends.
+ */
+Object.defineProperty(exports, "__esModule", { value: true });
+exports.STATUS_CHECK_LINE_COUNT = void 0;
+exports.normalizeFrame = normalizeFrame;
+const cli_patterns_1 = require("../cli-patterns");
+const tui_detection_frame_1 = require("../tui-detection-frame");
+const thinking_constants_1 = require("../../../config/thinking-constants");
+/**
+ * Number of lines from the end to check for prompt and input indicators.
+ *
+ * Moved here from `status-detector.ts` (Issue #1927) because it is the window
+ * every tool module measures against; re-exported from the facade so the many
+ * existing importers are unaffected.
+ */
+exports.STATUS_CHECK_LINE_COUNT = 15;
+/** Build the shared {@link NormalizedFrame} for one capture. */
+function normalizeFrame(output) {
+    const clean = (0, tui_detection_frame_1.normalizeTuiFrameForDetection)((0, cli_patterns_1.stripAnsi)(output));
+    const lines = clean.split('\n');
+    // Strip trailing empty lines (tmux terminal padding) before windowing.
+    // tmux buffers often end with many empty padding lines that would otherwise
+    // fill the entire detection window, hiding the actual prompt/status content.
+    let lastNonEmptyIndex = lines.length - 1;
+    while (lastNonEmptyIndex >= 0 && lines[lastNonEmptyIndex].trim() === '') {
+        lastNonEmptyIndex--;
+    }
+    const contentLines = lines.slice(0, lastNonEmptyIndex + 1);
+    return {
+        raw: output,
+        clean,
+        lines,
+        contentLines,
+        lastLines: contentLines.slice(-exports.STATUS_CHECK_LINE_COUNT).join('\n'),
+        // DR-003: Separate thinking detection window (5 lines) from prompt detection window (15 lines)
+        thinkingLines: contentLines.slice(-thinking_constants_1.THINKING_TAIL_LINE_COUNT).join('\n'),
+    };
+}

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

@@ -0,0 +1,242 @@
+"use strict";
+/**
+ * opencode's status detector (Issue #1927, 方針書 §4 D2).
+ *
+ * A verbatim lift of the `cliToolId === 'opencode'` block (branches A0–E) out of
+ * `detectSessionStatus`. opencode is the only tool with a completion marker of
+ * its own (§4 D1 決定 1 item 1) and, since #1883, a gutter-anchored idle
+ * composer rule (item 2) — which is why it ships with `enforce`.
+ */
+Object.defineProperty(exports, "__esModule", { value: true });
+exports.opencodeStatusDetector = exports.VERIFIED_AGAINST = void 0;
+exports.readIdleEvidence = readIdleEvidence;
+const cli_patterns_1 = require("../../cli-patterns");
+const status_reason_1 = require("../../status-reason");
+const prompt_1 = require("./prompt");
+const frame_1 = require("../frame");
+const run_detection_1 = require("../run-detection");
+const verified_against_1 = require("../verified-against");
+const thinking_constants_1 = require("../../../../config/thinking-constants");
+/** opencode build these rules were read off (#1883 / #1893 / #1896; value in ../verified-against, #1929). */
+exports.VERIFIED_AGAINST = verified_against_1.OPENCODE_VERIFIED_AGAINST;
+/**
+ * Where opencode's content area ends in this frame.
+ *
+ * Extract content area by finding TUI footer boundary dynamically.
+ * Footer structure (bottom-up): keybinding hints ("ctrl+t variants..."),
+ * ╹▀▀ separator, model info bar ("Build GPT-5-mini GitHub Copilot"), ┃ padding.
+ * The keybinding line is the anchor; model bar is 2 lines above it.
+ * ┃ padding above the model bar becomes empty after stripBoxDrawing and is
+ * skipped by the lastNonEmpty search.
+ *
+ * `stripBoxDrawing` maps line-for-line — it blanks border-only rows rather than
+ * dropping them — so an index taken here is valid in `frame.lines` too, which is
+ * what branch E relies on to read the input box's own gutter.
+ */
+function findContentEnd(frame) {
+    const strippedForOpenCode = (0, cli_patterns_1.stripBoxDrawing)(frame.clean);
+    const ocLines = strippedForOpenCode.split('\n');
+    let footerBoundary = Math.max(0, ocLines.length - 7); // fallback: skip 7 lines
+    for (let i = ocLines.length - 1; i >= Math.max(0, ocLines.length - 10); i--) {
+        if (/ctrl\+[tp]/.test(ocLines[i])) {
+            // Exclude keybinding line (i), separator (i-1), and model info bar (i-2)
+            footerBoundary = Math.max(0, i - 2);
+            break;
+        }
+    }
+    const candidates = ocLines.slice(0, footerBoundary);
+    let lastIndex = candidates.length - 1;
+    while (lastIndex >= 0 && candidates[lastIndex].trim() === '') {
+        lastIndex--;
+    }
+    return { candidates, lastIndex };
+}
+/**
+ * §4 D1 決定 1: opencode's idle evidence.
+ *
+ * Two positives, both already implemented as branches below and both restated
+ * here so the tool table can point at a rule rather than at an ordering
+ * accident: the finished-turn marker with a duration (item 1) and the
+ * gutter-anchored `Ask anything...` composer (item 2, #1883).
+ *
+ * Like copilot's, this is belt-and-braces — opencode opts out of the generic
+ * composer check, so no `ready` reaches the evidence gate without branch D or E
+ * having already vouched for it.
+ */
+function readIdleEvidence(frame) {
+    const { candidates, lastIndex } = findContentEnd(frame);
+    if (lastIndex < 0)
+        return 'none';
+    const window = candidates
+        .slice(Math.max(0, lastIndex - frame_1.STATUS_CHECK_LINE_COUNT + 1), lastIndex + 1)
+        .join('\n');
+    if (cli_patterns_1.OPENCODE_TURN_COMPLETE_PATTERN.test(window))
+        return 'positive';
+    const composerWindow = frame.lines
+        .slice(Math.max(0, lastIndex - frame_1.STATUS_CHECK_LINE_COUNT + 1), lastIndex + 1)
+        .join('\n');
+    return cli_patterns_1.OPENCODE_IDLE_COMPOSER_PATTERN.test(composerWindow) ? 'positive' : 'none';
+}
+exports.opencodeStatusDetector = (0, run_detection_1.createToolStatusDetector)({
+    tool: 'opencode',
+    verifiedAgainst: exports.VERIFIED_AGAINST,
+    afterThinking(frame) {
+        // 2.5. OpenCode status detection (Issue #379)
+        // OpenCode TUI layout: content area (top) | empty padding (~150 lines) | footer status bar (~6 lines at bottom).
+        // Standard windowed checks (last N lines) only see footer/padding, never the content area.
+        //
+        // Detection strategy:
+        // A0. Permission dialog button strip → waiting (Issue #1893; first, see below)
+        // A. "esc interrupt" in footer → actively processing (running)
+        // B. Find footer boundary via "ctrl+t" keybinding line, extract content above it, check for thinking → running
+        // C. Same content window, check for a selection list → waiting
+        // D. Same content window, check for ▣ Build completion WITH a duration → ready
+        // E. Idle composer placeholder inside the input box gutter → ready (Issue #1883)
+        // A0. Permission dialog (Issue #1893) — ahead of every other opencode branch.
+        //
+        // opencode asks for tool permission with a bottom-anchored box whose button
+        // strip reads "Allow once   Allow always   Reject". It has no number, no
+        // (y/n) and no "press enter to confirm" footer, so `detectPrompt` answered
+        // `isPrompt: false` and this block fell through to branch D — which matched
+        // the `▣ Build · <model>` row opencode draws for the step that is WAITING on
+        // this very dialog and published the blocked session as
+        // `ready`/`opencode_response_complete`. `wait` then reported a false
+        // completion, the sidebar went idle and the send guard opened.
+        //
+        // It is checked before branch A (`esc interrupt`) and before branch D on
+        // purpose: a dialog is the agent blocked on a human whatever else is on the
+        // pane, and `permission-after-complete.txt` is a live frame where the box is
+        // open with a genuinely finished `· 2.3s` marker still in the transcript
+        // above it — branch D would win that frame on ordering alone.
+        //
+        // `hasActivePrompt` stays FALSE and the reason joins SELECTION_LIST_REASONS,
+        // which is the `menu` half of the #1786 taxonomy ("only the terminal can
+        // drive it") rather than the `prompt` half ("the app can answer this for
+        // you"). That is a measurement, not a preference: on opencode 1.18.21 the
+        // strip is driven by ←/→ + Enter and typing a number does nothing at all
+        // (the button row is byte-identical before and after `3` is sent). Synthesising
+        // `1. Allow once / 2. Allow always / 3. Reject` here would have made
+        // `respond <id> 3` send the text "3" — swallowed — followed by Enter, which
+        // confirms whatever is highlighted: asking to REJECT would have APPROVED.
+        // `wait` still stops for it (`isSelectionListActive` → exit 10) and the UI
+        // renders NavigationButtons, which send exactly the keys the strip takes.
+        if (cli_patterns_1.OPENCODE_PERMISSION_PATTERN.test(frame.lastLines)) {
+            return {
+                status: 'waiting',
+                confidence: 'high',
+                reason: status_reason_1.STATUS_REASON.OPENCODE_PERMISSION_PROMPT,
+                hasActivePrompt: false,
+                evidence: 'positive',
+            };
+        }
+        // A. Check footer for processing indicator ("esc interrupt" replaces "ctrl+t variants..." during processing)
+        if (cli_patterns_1.OPENCODE_PROCESSING_INDICATOR.test(frame.lastLines)) {
+            return {
+                status: 'running',
+                confidence: 'high',
+                reason: status_reason_1.STATUS_REASON.OPENCODE_PROCESSING_INDICATOR,
+                hasActivePrompt: false,
+                evidence: 'positive',
+            };
+        }
+        const { candidates, lastIndex } = findContentEnd(frame);
+        if (lastIndex < 0)
+            return null;
+        // B. Check last few content lines for thinking indicators
+        const contentThinkingWindow = candidates
+            .slice(Math.max(0, lastIndex - thinking_constants_1.THINKING_TAIL_LINE_COUNT + 1), lastIndex + 1)
+            .join('\n');
+        if ((0, cli_patterns_1.detectThinking)('opencode', contentThinkingWindow)) {
+            return {
+                status: 'running',
+                confidence: 'high',
+                reason: status_reason_1.STATUS_REASON.THINKING_INDICATOR,
+                hasActivePrompt: false,
+                evidence: 'positive',
+            };
+        }
+        // C. Check content area for selection list (Issue #473: fuzzy-search list detection)
+        // Selection list header ("Select model"/"Select provider") may be far above the
+        // last content line when many items are listed, so check all content candidates.
+        const contentCheckWindow = candidates
+            .slice(Math.max(0, lastIndex - frame_1.STATUS_CHECK_LINE_COUNT + 1), lastIndex + 1)
+            .join('\n');
+        if (cli_patterns_1.OPENCODE_SELECTION_LIST_PATTERN.test(candidates.join('\n'))) {
+            return {
+                status: 'waiting',
+                confidence: 'high',
+                reason: status_reason_1.STATUS_REASON.OPENCODE_SELECTION_LIST,
+                hasActivePrompt: false,
+                evidence: 'positive',
+            };
+        }
+        // D. Check last few content lines for the finished-turn marker.
+        //
+        // Issue #1893 made the duration mandatory here (OPENCODE_TURN_COMPLETE_PATTERN
+        // rather than the line-filter OPENCODE_RESPONSE_COMPLETE). opencode draws
+        // `▣ <Action> · <model>` with no duration for a step that is still open —
+        // notably the one blocked on a permission dialog — and matching that row
+        // was the reported false `ready`. A duration-less row now carries no
+        // verdict at all: an aborted turn (`turn-aborted-no-duration.txt`) falls
+        // through to the heuristics rather than claiming a completion that never
+        // happened, which is what design rule D1 asks for.
+        if (cli_patterns_1.OPENCODE_TURN_COMPLETE_PATTERN.test(contentCheckWindow)) {
+            return {
+                status: 'ready',
+                confidence: 'high',
+                reason: status_reason_1.STATUS_REASON.OPENCODE_RESPONSE_COMPLETE,
+                hasActivePrompt: false,
+                evidence: 'positive',
+            };
+        }
+        // E. Idle composer (Issue #473 found the row; Issue #1883 made it positive).
+        //
+        // `Ask anything...` is a *placeholder*, not a question: opencode paints it
+        // only while the input buffer is empty and replaces it with the first
+        // typed character. Finding it inside the input box is therefore positive
+        // evidence that the composer is empty — the same class of evidence as
+        // claude's completion marker or codex's idle row — and this branch is
+        // opencode's implementation of design rule D1 ("declare a turn finished
+        // only on positive evidence"), not a fallback for "nothing looked busy".
+        //
+        // The row is matched on `frame.lines` (ANSI stripped, box drawing intact)
+        // via OPENCODE_IDLE_COMPOSER_PATTERN, so it must carry the input box's own
+        // gutter. The bare phrase reaching the pane inside a response body is not
+        // read as an idle composer.
+        //
+        // D1's other half — "and the footer shows no processing marker" — is
+        // branch A above, which has already returned `running` for any frame whose
+        // footer carries `esc interrupt`.
+        const composerWindow = frame.lines
+            .slice(Math.max(0, lastIndex - frame_1.STATUS_CHECK_LINE_COUNT + 1), lastIndex + 1)
+            .join('\n');
+        if (cli_patterns_1.OPENCODE_IDLE_COMPOSER_PATTERN.test(composerWindow)) {
+            return {
+                status: 'ready',
+                confidence: 'high',
+                reason: status_reason_1.STATUS_REASON.INPUT_PROMPT,
+                hasActivePrompt: false,
+                evidence: 'positive',
+            };
+        }
+        return null;
+    },
+    // Issue #1883: opencode opts out of the generic composer check. Its
+    // promptPattern is the bare phrase `Ask anything...`, so that check is a
+    // second, looser copy of branch E which answers `ready` for the phrase
+    // appearing anywhere in the last 15 rows — including in a response body, where
+    // it is not a composer at all. Leaving it in would also make E's gutter anchor
+    // unobservable.
+    skipGenericInputPrompt: true,
+    readIdleEvidence,
+    // §4 D1 決定 4 (Issue #1928). The content window is branch C's, passed rather
+    // than recomputed, so the picker the dialog rule reports is the picker the
+    // status branch reports.
+    detectDialog(frame) {
+        const { candidates } = findContentEnd(frame);
+        return (0, prompt_1.detectOpenCodeDialog)(frame, { contentWindow: candidates.join('\n') });
+    },
+    // As with copilot: branches A0–E are the only rules that run for opencode, so
+    // a frame reaching the floor is one they could not read.
+    unreadableReason: status_reason_1.STATUS_REASON.UNKNOWN_FRAME,
+});

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

@@ -0,0 +1,85 @@
+"use strict";
+/**
+ * opencode's positive dialog detection (Issue #1928, 方針書 §4 D1 決定 4).
+ *
+ * This is the module Issue #1896 is about, and the shortest one in the tree,
+ * because opencode 1.18.21's whole interactive surface was measured and **none
+ * of it takes a typed number**:
+ *
+ * | surface            | rendering                                   | driven by | source |
+ * |--------------------|---------------------------------------------|-----------|--------|
+ * | permission dialog  | `Allow once   Allow always   Reject` strip  | ←/→ + Enter | #1893 |
+ * | `/models`, `/providers`, `/connect`, ctrl+p | fuzzy-search list, no numbers drawn | ↑/↓ + Enter | #1896 |
+ *
+ * So every dialog this module can report carries `answerMode: 'keys'`, and the
+ * Auto-Yes gate therefore never fires for opencode. That is the correct reading,
+ * not a degradation: `sendPromptAnswer` types the digit as text for this tool,
+ * and Issue #1893 measured what happens next — the `1` is swallowed by the
+ * button row and the Enter after it confirms whatever is HIGHLIGHTED, so asking
+ * to Reject would have Approved. `wait` still stops for both surfaces
+ * (`isSelectionListActive` → exit 10) and the UI still renders NavigationButtons,
+ * which send the keys the strip actually takes.
+ *
+ * ## Why the numbered path is not re-litigated here
+ *
+ * `buildDetectPromptOptions('opencode')` already declares
+ * `hasNumberedDialogs: false`, which stops `detectPrompt` reporting a numbered
+ * transcript block as a prompt at all. This module is the second half of the
+ * same decision rather than a duplicate of it: the declaration says "there is
+ * nothing numbered to find", and this says "and here is what there IS", so the
+ * gate can tell an unreadable frame from a dialog it must not answer.
+ *
+ * ## The gutter, and the one frame where it is missing
+ *
+ * `OPENCODE_PERMISSION_PATTERN` is anchored on the input box's own `│`/`┃`
+ * gutter — that anchor is Issue #1893's, and weakening it here would let the
+ * strip's words reach the pane inside a response body and be read as a dialog.
+ * The Auto-Yes poller hands this detector a frame whose box drawing has already
+ * been removed (`captureAndCleanOutput`), so on THAT path the permission branch
+ * cannot match and this module answers `null` instead of `permission`. The gate
+ * outcome is identical either way — `null` and `keys` both mean "do not send" —
+ * so the anchor is kept at its measured strength rather than being widened for a
+ * verdict that would not change.
+ */
+Object.defineProperty(exports, "__esModule", { value: true });
+exports.detectOpenCodeDialog = detectOpenCodeDialog;
+const cli_patterns_1 = require("../../cli-patterns");
+/** Splits the button strip into its buttons: two or more spaces separate them. */
+const BUTTON_SEPARATOR = /\s{2,}/;
+/**
+ * Read the buttons out of the row {@link OPENCODE_PERMISSION_PATTERN} matched.
+ *
+ * The MATCH is sliced, not the row: opencode draws its own key hints
+ * (`ctrl+f fullscreen  ⇆ select  enter confirm`) to the right of the strip on
+ * the same line, and they are not choices. Using the pattern's own extent keeps
+ * this from becoming a second, looser statement of where the strip ends.
+ */
+function readPermissionButtons(frame) {
+    for (const line of frame.lines) {
+        const match = cli_patterns_1.OPENCODE_PERMISSION_PATTERN.exec(line);
+        if (!match)
+            continue;
+        return match[0]
+            .replace(/^[^\S\n]*[│┃][^\S\n]*/, '')
+            .trim()
+            .split(BUTTON_SEPARATOR)
+            .map(button => button.trim())
+            .filter(button => button !== '');
+    }
+    return [];
+}
+/**
+ * Does this frame carry an opencode dialog?
+ *
+ * @param frame - The normalised capture
+ * @param context - What `detect.ts` measured; see {@link OpenCodeDialogContext}
+ */
+function detectOpenCodeDialog(frame, context) {
+    if (cli_patterns_1.OPENCODE_PERMISSION_PATTERN.test(frame.lastLines)) {
+        return { kind: 'permission', options: readPermissionButtons(frame), answerMode: 'keys' };
+    }
+    if (cli_patterns_1.OPENCODE_SELECTION_LIST_PATTERN.test(context.contentWindow)) {
+        return { kind: 'picker', options: [], answerMode: 'keys' };
+    }
+    return null;
+}