commandmate 0.26.1 → 0.27.0

package/dist/server/src/lib/polling/auto-yes-dialog-gate.js

@@ -0,0 +1,184 @@
+"use strict";
+/**
+ * The one position that can stop Issue #1896: Auto-Yes may fire only on a
+ * POSITIVELY detected tool dialog (Issue #1928, 方針書 §4 D1 決定 4).
+ *
+ * ## What goes wrong without it
+ *
+ * `detectPrompt` answers "does this frame look like a numbered choice?" from the
+ * text alone. An agent that lists three deployment options and asks which one
+ * the operator wants satisfies it exactly — and on opencode the `1` Auto-Yes
+ * typed in reply was not answering anything, it was SENT AS A USER UTTERANCE
+ * (#1896). Same shape, different tool: a codex approval the operator answered
+ * five minutes ago is still on the pane, options and footer intact (#1160).
+ *
+ * The generic inference cannot tell any of these from a live dialog, because
+ * nothing in the ROWS distinguishes them — what distinguishes them is position
+ * and chrome, which only the tool's own module knows. So this gate asks that
+ * module, through the `detectDialog` seam §4 D2 declared, and sends nothing when
+ * it declines.
+ *
+ * ## Rollout, and why the table is explicit
+ *
+ * Per tool, exactly like the idle-evidence rollout in
+ * `config/detection-evidence-config.ts`. A tool whose dialogs nobody has
+ * measured must NOT be gated: gating it would turn every one of its prompts into
+ * a suppression and stop Auto-Yes working at all for that tool, which is a
+ * bigger regression than the false positive the gate exists to prevent. The
+ * table states that decision rather than leaving it implicit in which modules
+ * happen to declare `detectDialog` — although the two are cross-checked, because
+ * an `enforce` row for a tool with no rules would silence it.
+ *
+ * ## Which inference is gated
+ *
+ * The NUMBERED-LIST one, and only it. §4 D1 決定 4 names it in as many words
+ * (「`detectPrompt` の汎用な番号リスト推定だけでは撃たない」) and #1896 is an
+ * instance of it, so `multiple_choice` is what this gate judges.
+ *
+ * A `yes_no` prompt is a different inference — `detectPrompt` requires an
+ * explicit `(y/n)`-shaped token in the text rather than deriving it from layout
+ * — and NO tool in the registry has a measured yes/no dialog rule to gate it
+ * against. Gating an inference for which no positive rule exists is the failure
+ * mode the rollout guidance is written to prevent: every such prompt would
+ * become a suppression, and the operator would see a worker that had silently
+ * gone quiet. When a tool's yes/no dialog is measured and fixtured, widen this
+ * the same way a tool is added to the table.
+ *
+ * ## What "allowed" does NOT mean
+ *
+ * It does not mean "send this answer". The contract policy (#1547), the deny
+ * patterns (#1699) and the base rules all still run afterwards and can each
+ * withhold. This gate only removes an answer the tool's own rules cannot vouch
+ * for.
+ *
+ * @module lib/polling/auto-yes-dialog-gate
+ */
+Object.defineProperty(exports, "__esModule", { value: true });
+exports.AUTO_YES_DIALOG_GATE_ENV_VAR = exports.AUTO_YES_DIALOG_GATE_DEFAULT_MODE = exports.AUTO_YES_DIALOG_GATE_MODES = void 0;
+exports.resolveAutoYesDialogGateMode = resolveAutoYesDialogGateMode;
+exports.evaluateAutoYesDialogGate = evaluateAutoYesDialogGate;
+const frame_1 = require("../../lib/detection/tools/frame");
+const registry_1 = require("../../lib/detection/tools/registry");
+/** Every accepted value of {@link AutoYesDialogGateMode}, for parsing and tests. */
+exports.AUTO_YES_DIALOG_GATE_MODES = ['enforce', 'legacy'];
+/**
+ * The rollout state each tool ships in.
+ *
+ * `enforce` is set only for the four tools with a dialog rule measured from
+ * their own live captures, each with a positive fixture and a mutation fixture
+ * (`tests/unit/detection/tools/dialogs.test.ts`):
+ *
+ * | tool     | positive rule                                                        | Issue         |
+ * |----------|----------------------------------------------------------------------|---------------|
+ * | claude   | `❯` cursor on the option run above the chrome, dialog footer or none  | #1708 / #1495 |
+ * | codex    | `Press enter to confirm …` under the options, above the status bar, not stale | #1628 / #1160 |
+ * | copilot  | the bottom status bar is GONE and the option run carries a picker footer | #1885 / #1895 |
+ * | opencode | the `Allow once / Allow always / Reject` strip, or a picker header    | #1893 / #1896 |
+ *
+ * The rest are `legacy` because nobody has measured them:
+ *
+ * - `gemini` and `vibe-local` have no tool module at all
+ *   (`createGenericStatusDetector`), so there is nothing to ask.
+ * - `antigravity` has a module, but its permission menu was measured only well
+ *   enough to answer it (#999: an ASCII `>` cursor, a `↑/↓ Navigate` footer and
+ *   no `press enter to confirm`), and the repository holds no live agy capture
+ *   to write a dialog rule against. Gating it on a rule inferred from another
+ *   tool's frames is the mistake #1979 had to correct; leaving it `legacy` keeps
+ *   agy's Auto-Yes working exactly as it does today.
+ */
+exports.AUTO_YES_DIALOG_GATE_DEFAULT_MODE = {
+    claude: 'enforce',
+    codex: 'enforce',
+    copilot: 'enforce',
+    opencode: 'enforce',
+    gemini: 'legacy',
+    antigravity: 'legacy',
+    'vibe-local': 'legacy',
+};
+/**
+ * The kill switch (§13.1 DR3-016).
+ *
+ * A comma-separated list of `<tool>=<mode>` pairs, with `*` for "every tool",
+ * spelled exactly like `CM_DETECTION_IDLE_EVIDENCE`:
+ *
+ * ```
+ * CM_AUTOYES_DIALOG_GATE=codex=legacy    # one tool back to the pre-#1928 behaviour
+ * CM_AUTOYES_DIALOG_GATE=*=legacy        # the whole gate off
+ * ```
+ *
+ * Read on every poll rather than at module load, for the same reason the
+ * idle-evidence switch is: an operator whose unattended pipeline has stopped
+ * answering prompts must be able to undo this without a redeploy, and a cached
+ * read would put a restart between them and the incident.
+ */
+exports.AUTO_YES_DIALOG_GATE_ENV_VAR = 'CM_AUTOYES_DIALOG_GATE';
+function isMode(value) {
+    return exports.AUTO_YES_DIALOG_GATE_MODES.includes(value);
+}
+/**
+ * Resolve one tool's gate mode.
+ *
+ * Later entries win over earlier ones and a tool-specific entry beats `*` in
+ * either order. An unparseable entry is ignored rather than thrown: this runs on
+ * the Auto-Yes polling path, and a typo in an env var must not take the poller
+ * down.
+ *
+ * @param tool - CLI tool to resolve for
+ * @param env - Environment to read; injectable for tests
+ */
+function resolveAutoYesDialogGateMode(tool, env = process.env) {
+    const raw = env[exports.AUTO_YES_DIALOG_GATE_ENV_VAR];
+    let wildcard = null;
+    let specific = null;
+    if (typeof raw === 'string' && raw.trim() !== '') {
+        for (const entry of raw.split(',')) {
+            const [rawKey, rawValue] = entry.split('=');
+            if (rawValue === undefined)
+                continue;
+            const key = rawKey.trim();
+            const value = rawValue.trim();
+            if (!isMode(value))
+                continue;
+            if (key === '*')
+                wildcard = value;
+            else if (key === tool)
+                specific = value;
+        }
+    }
+    return specific ?? wildcard ?? exports.AUTO_YES_DIALOG_GATE_DEFAULT_MODE[tool] ?? 'legacy';
+}
+/** The only prompt family this gate judges. See the module docstring. */
+const GATED_PROMPT_TYPE = 'multiple_choice';
+/**
+ * May Auto-Yes answer the prompt the generic inference found on this frame?
+ *
+ * @param cliToolId - CLI tool being polled
+ * @param promptType - How `detectPrompt` classified the frame
+ * @param cleanOutput - The capture Auto-Yes judged, i.e. what
+ *   `captureAndCleanOutput` produced: ANSI **and** box drawing already removed.
+ *   Every `detectDialog` implementation is written against that spelling as well
+ *   as the untouched one, so the same frame reaches the same verdict on both
+ *   paths.
+ * @param env - Environment to read the kill switch from; injectable for tests
+ */
+function evaluateAutoYesDialogGate(cliToolId, promptType, cleanOutput, env = process.env) {
+    const detector = (0, registry_1.getToolStatusDetector)(cliToolId);
+    const mode = resolveAutoYesDialogGateMode(cliToolId, env);
+    // A tool nobody has measured is not gated whatever the table says. Belt and
+    // braces on purpose: the failure mode of getting this wrong is Auto-Yes going
+    // permanently silent for that tool, which looks exactly like a hung worker.
+    if (promptType !== GATED_PROMPT_TYPE || !detector.hasDialogRules || mode === 'legacy') {
+        return { allowed: true, dialog: null, mode, gated: false };
+    }
+    const dialog = detector.detectDialog((0, frame_1.normalizeFrame)(cleanOutput));
+    return {
+        // `keys` is a dialog and still not answerable: opencode's button strip takes
+        // ←/→ + Enter, so the digit is swallowed and the Enter confirms whatever is
+        // highlighted — asking to Reject would Approve (#1893). Sending nothing is
+        // the only safe answer, and `wait` still stops for the frame.
+        allowed: dialog !== null && dialog.answerMode === 'numbered',
+        dialog,
+        mode,
+        gated: true,
+    };
+}

package/dist/server/src/lib/polling/response-checker.js

@@ -32,9 +32,69 @@ const push_1 = require("../../lib/push");
 // Issue #1790: imported by deep path, not through `@/lib/push`. Suites that
 // replace the barrel to count notifications (e.g. the #1547 escalation test)
 // would otherwise get `undefined` here and take down module evaluation.
+// Issue #1999: imported from its own module, not from the `@/lib/push` barrel
+// above. Several suites replace that barrel wholesale with a stub that only
+// declares `notifyPushSubscribers`, and a gate reached through it would be
+// `undefined` in exactly those tests — a TypeError this function's catch would
+// report as an ordinary "no response found".
+const prompt_push_gate_1 = require("../../lib/push/prompt-push-gate");
+// Issue #2000: deep path for the same reason as the two imports above.
+const failure_push_notifier_1 = require("../../lib/push/failure-push-notifier");
+const upstream_faults_1 = require("../../lib/detection/upstream-faults");
 const waiting_push_notifier_1 = require("../../lib/push/waiting-push-notifier");
 const waiting_episode_state_1 = require("../../lib/session/waiting-episode-state");
 const task_transition_service_1 = require("../../lib/tasks/task-transition-service");
+/**
+ * How many rows from the bottom of a copilot capture may hold its status bar.
+ *
+ * `readCopilotStatusBar` stops at the first non-blank row from the end, and the
+ * capture handed to it here has already had its trailing blanks trimmed, so one
+ * row is enough in practice. The slack exists so the reader keeps working if that
+ * trim ever changes, without mapping a thousand rows through `stripAnsi` on every
+ * poll tick. (Issue #1897)
+ */
+const COPILOT_STATUS_BAR_SCAN_ROWS = 8;
+/**
+ * How many rows from the bottom of a capture the upstream-fault check reads
+ * (Issue #2000).
+ *
+ * The same 100 as `current-output-builder`'s `realtimeSnippet`, and for the
+ * reason #1839 gives there: the wider capture keeps a banner from an hour ago
+ * in scope, and "is this happening now" is the only question worth ringing a
+ * phone about. Keeping the two windows equal also means the notification and
+ * the `upstreamFault` field an operator reads in `capture --json` are judging
+ * the same rows — a fault that rang but is invisible in the payload next to it
+ * is unverifiable.
+ */
+const UPSTREAM_FAULT_SCAN_ROWS = 100;
+/**
+ * Raise a push notification when this frame shows a NEW upstream fault
+ * (Issue #2000).
+ *
+ * Observed here, on the poller, rather than in `current-output-builder` where
+ * the published `upstreamFault` field is computed. That field is on a read
+ * path: it is evaluated when a browser polls the status API or holds the
+ * WebSocket open, i.e. exactly when the user is already looking. A phone
+ * notification is for the opposite situation, so the observation has to come
+ * from something the server runs on its own — and this poller is it.
+ *
+ * Every decision (new episode / still the same one / inside the cooldown) is
+ * made and logged by `push/failure-push-notifier`; nothing here decides
+ * anything, so the level can be handed over on every poll.
+ */
+function observeUpstreamFaultForPush(worktreeId, cliToolId, instanceId, output) {
+    const snippet = output.split('\n').slice(-UPSTREAM_FAULT_SCAN_ROWS).join('\n');
+    const match = (0, upstream_faults_1.matchUpstreamFault)(snippet);
+    // Fire-and-forget, like every other push call in this file: the poller must
+    // not slow down or break because a notification could not be delivered.
+    void (0, failure_push_notifier_1.notifyUpstreamFaultPush)({
+        worktreeId,
+        cliToolId,
+        instanceId,
+        faultId: match?.fault.id ?? null,
+        matchedText: match?.matchedText,
+    }).catch(() => { });
+}
 // Issue #1790: arm the waiting-edge push subscription.
 //
 // It has to exist before the first edge, and `server.ts` reaches this module at
@@ -134,7 +194,35 @@ function extractResponse(output, lastCapturedLine, cliToolId, captureWindowLines
     // defeating the content dedup from #1268. Completion detection below still
     // reads the untouched buffer: it keys off that very footer (the input box
     // supplies `hasPrompt`, its rules supply `hasSeparator`).
-    const chromeStart = cliToolId === 'claude' ? (0, cli_patterns_1.findClaudeChromeStart)(lines) : -1;
+    //
+    // Issue #1897: copilot pins the same shape of chrome (cwd row, two rules, the
+    // composer, the status bar) to the bottom of its pane, and it is the reason the
+    // agent's saved reply read " Working esc interrupt GPT-5.6 Terra" -- see
+    // findCopilotChromeStart().
+    //
+    // Issue #1911: opencode pins the same kind of chrome to the bottom of its
+    // alternate-screen pane — the composer box (whose model row reads
+    // `Build · GPT-5.6 Luna GitHub Copilot`) and, below its `╹▀▀▀` border, a footer
+    // whose wrapped cwd carries no signature at all. Both were being saved as part
+    // of the assistant's reply, which is defect 1 of #1911; no pattern can remove
+    // the cwd rows, so the boundary has to be structural.
+    //
+    // The three readers stay three functions on purpose. All three answer "where
+    // does the transcript stop?", but each is anchored on a DIFFERENT measured
+    // landmark — claude's two full-width rules around its input box (#1289),
+    // copilot's bottom status-bar row (#1885/#1897), opencode's `╹▀▀▀` composer
+    // border (#1911) — and a landmark is only as good as the frames it was measured
+    // on. Folding them into one reader would let a rewording in one tool's chrome
+    // silently delete another tool's boundary, and a boundary that stops existing
+    // does not fail loudly: it puts terminal furniture back into History.
+    const openCodeCleanLines = cliToolId === 'opencode' ? lines.map(cli_patterns_1.stripAnsi) : null;
+    const chromeStart = cliToolId === 'claude'
+        ? (0, cli_patterns_1.findClaudeChromeStart)(lines)
+        : cliToolId === 'copilot'
+            ? (0, cli_patterns_1.findCopilotChromeStart)(lines)
+            : openCodeCleanLines
+                ? (0, cli_patterns_1.findOpenCodeChromeStart)(openCodeCleanLines)
+                : -1;
     const contentEnd = chromeStart >= 0 ? chromeStart : totalLines;
     const BUFFER_RESET_TOLERANCE = 25;
     const bufferShrank = totalLines > 0 && lastCapturedLine > BUFFER_RESET_TOLERANCE && (totalLines + BUFFER_RESET_TOLERANCE) < lastCapturedLine;
@@ -148,8 +236,8 @@ function extractResponse(output, lastCapturedLine, cliToolId, captureWindowLines
     const checkLineCount = 20;
     const startLine = Math.max(0, totalLines - checkLineCount);
     const linesToCheck = lines.slice(startLine);
-    const outputToCheck = cliToolId === 'opencode'
-        ? (0, cli_patterns_1.stripAnsi)(lines.join('\n'))
+    const outputToCheck = openCodeCleanLines
+        ? openCodeCleanLines.join('\n')
         : linesToCheck.join('\n');
     // Get tool-specific patterns from shared module
     const { promptPattern, separatorPattern, thinkingPattern, skipPatterns } = (0, cli_patterns_1.getCliToolPatterns)(cliToolId);
@@ -158,16 +246,41 @@ function extractResponse(output, lastCapturedLine, cliToolId, captureWindowLines
         if (cliToolId === 'codex') {
             userPromptPattern = /^›\s+(?!Implement|Find and fix|Type|Summarize)/;
         }
-        else if (cliToolId === 'opencode') {
-            let buildCount = 0;
-            for (let i = totalLines - 1; i >= Math.max(0, totalLines - windowSize); i--) {
-                const cleanLine = (0, cli_patterns_1.stripAnsi)(lines[i]);
-                if (cli_patterns_1.OPENCODE_RESPONSE_COMPLETE.test(cleanLine)) {
-                    buildCount++;
-                    if (buildCount === 2) {
-                        return i;
-                    }
+        else if (openCodeCleanLines) {
+            // Issue #1911: anchor on the newest ECHOED USER PROMPT, not on the
+            // second-to-last `▣ Build` row. The old anchor belonged to the PREVIOUS
+            // turn, so the echoed prompt of the current one was always extracted as
+            // part of the reply — and on the first turn of a session, where there is
+            // no second marker, it fell through to line 0 and the whole pane (banner
+            // included) became the answer. `windowSize` is ignored: the alternate
+            // screen has no scrollback, so the whole pane IS the window, and every
+            // caller already passes `totalLines` or more for this tool.
+            return (0, response_extractor_1.resolveOpenCodeTurnRegion)(openCodeCleanLines).echoEnd;
+        }
+        else if (cliToolId === 'copilot') {
+            // Issue #1897: copilot 1.0.80 draws the transcript one column in, so the
+            // bare `^[>❯]` form below never matched the echoed prompt -- every copilot
+            // extraction fell back to line 0, i.e. to the launch banner. The composer,
+            // which IS at column 0, lives below `contentEnd` and so cannot be picked up
+            // as an echo here.
+            //
+            // The scan then walks past the echo's own wrapped rows and returns the LAST
+            // of them, so that callers' `+ 1` lands on the reply rather than on the
+            // second half of the operator's question.
+            //
+            // Same defect as #1911's opencode branch above and the same shape of fix,
+            // but NOT the same code: opencode's echo is a `┃  <text>` gutter row and
+            // copilot's is ` ❯ <text>` at the pane's one-column indent, so the anchor
+            // and the continuation rule are both tool-specific measurements.
+            for (let i = contentEnd - 1; i >= Math.max(0, contentEnd - windowSize); i--) {
+                if (!cli_patterns_1.COPILOT_USER_ECHO_PATTERN.test((0, cli_patterns_1.stripAnsi)(lines[i])))
+                    continue;
+                let echoEnd = i;
+                while (echoEnd + 1 < contentEnd &&
+                    cli_patterns_1.COPILOT_TRANSCRIPT_CONTINUATION_PATTERN.test((0, cli_patterns_1.stripAnsi)(lines[echoEnd + 1]))) {
+                    echoEnd++;
                 }
+                return echoEnd;
             }
             return -1;
         }
@@ -207,8 +320,29 @@ function extractResponse(output, lastCapturedLine, cliToolId, captureWindowLines
     const isThinking = cliToolId === 'codex'
         ? (0, cli_patterns_1.isCodexTurnActive)(lines, checkLineCount)
         : thinkingPattern.test(cleanOutputToCheck);
+    // Issue #1897: copilot's `hasPrompt` is worthless as a completion signal and
+    // its `isThinking` is worthless as a liveness one. The `❯` composer is drawn
+    // between its two rules throughout a turn (measured on every frame of #1885's
+    // running fixtures), and `COPILOT_THINKING_PATTERN` matches nothing copilot
+    // 1.0.80 draws (0 of 44 live generating frames). So `hasPrompt && !isThinking`
+    // was true on the very first poll of a running turn -- the extractor declared
+    // the turn finished, saved the status bar as the reply, and `checkForResponse`
+    // stopped polling, which is why the real answer never reached History.
+    //
+    // 1.0.80 paints the turn's state on the bottom row of the pane and nowhere
+    // else, so that ROW -- never a tail window, which copilot's own reply text can
+    // forge (`status-vocabulary-in-response.txt`) -- is the evidence. `idle` is a
+    // positive observation that the turn is over (design policy §4 D1 decision 1
+    // item 2); `working` and `null` (a dialog box has taken the bar away) both mean
+    // "not finished", and the dialog case is already served by the prompt path
+    // above.
+    const copilotStatusBar = cliToolId === 'copilot'
+        ? (0, cli_patterns_1.readCopilotStatusBar)(lines.slice(Math.max(0, totalLines - COPILOT_STATUS_BAR_SCAN_ROWS)).map(cli_patterns_1.stripAnsi))
+        : null;
     // Prompt-based completion logic
-    const isPromptBasedComplete = (cliToolId === 'codex' || cliToolId === 'gemini' || cliToolId === 'vibe-local' || cliToolId === 'copilot' || cliToolId === 'antigravity') && hasPrompt && !isThinking;
+    const isPromptBasedComplete = cliToolId === 'copilot'
+        ? copilotStatusBar === 'idle'
+        : (cliToolId === 'codex' || cliToolId === 'gemini' || cliToolId === 'vibe-local' || cliToolId === 'antigravity') && hasPrompt && !isThinking;
     const isClaudeComplete = cliToolId === 'claude' && hasPrompt && hasSeparator && !isThinking;
     const isOpenCodeDone = cliToolId === 'opencode' && (0, response_extractor_1.isOpenCodeComplete)(cleanOutputToCheck);
     if (isPromptBasedComplete || isClaudeComplete || isOpenCodeDone) {
@@ -234,7 +368,14 @@ function extractResponse(output, lastCapturedLine, cliToolId, captureWindowLines
                 endIndex = i;
                 break;
             }
-            if (cliToolId === 'opencode') {
+            // Issue #1911: both rows this stops on (`Ask anything...` in the composer,
+            // `tab agents  ctrl+p commands` under its border) live in the chrome, which
+            // `contentEnd` now excludes structurally. Kept only as the fallback for a
+            // frame whose chrome could not be located, because there it is still the
+            // one boundary available — and #1883 measured that a REPLY can contain
+            // `Ask anything...`, so cutting the turn on it is a last resort, not the
+            // primary rule.
+            if (cliToolId === 'opencode' && chromeStart < 0) {
                 if (cli_patterns_1.OPENCODE_PROMPT_PATTERN.test(cleanLine) || cli_patterns_1.OPENCODE_PROMPT_AFTER_RESPONSE.test(cleanLine)) {
                     endIndex = i;
                     break;
@@ -248,8 +389,16 @@ function extractResponse(output, lastCapturedLine, cliToolId, captureWindowLines
         }
         const response = responseLines.join('\n').trim();
         // DR-004: Check only the tail of the response for thinking indicators.
+        //
+        // Issue #1897: not for copilot. This is the same tail-window match the #1671
+        // codex fix removed from the liveness test, and on copilot it is both
+        // redundant and harmful: the status bar above has already made a positive
+        // `idle` observation about THIS frame, while the window here sees transcript
+        // that never scrolls away. `COPILOT_THINKING_PATTERN`'s braille alternative
+        // matches any spinner glyph a reply happens to quote, and the turn would then
+        // be reported unfinished for the rest of the session.
         const responseTailLines = response.split('\n').slice(-thinking_constants_1.THINKING_TAIL_LINE_COUNT).join('\n');
-        if (thinkingPattern.test(responseTailLines)) {
+        if (cliToolId !== 'copilot' && thinkingPattern.test(responseTailLines)) {
             return incompleteResult(totalLines);
         }
         // CRITICAL FIX: Detect and skip Claude Code startup banner/screen
@@ -277,6 +426,25 @@ function extractResponse(output, lastCapturedLine, cliToolId, captureWindowLines
                 return incompleteResult(totalLines);
             }
         }
+        // Issue #1897: copilot's launch screen is a complete, idle frame -- composer
+        // drawn, key hints on the status bar -- so every check above accepts it and
+        // History used to open with the banner ("Current Sessions Issues Pull
+        // requests Gists / No copilot-instructions.md found… / Tip: /app") saved as
+        // the agent's first reply, before the operator had said anything.
+        //
+        // What actually distinguishes it is that no turn has happened: copilot echoes
+        // every prompt into the transcript as ` ❯ <text>`, and the launch screen has
+        // none. The banner anchors are only consulted once that echo is missing, so a
+        // reply that quotes any of this wording is unaffected.
+        if (cliToolId === 'copilot') {
+            const cleanResponse = (0, cli_patterns_1.stripAnsi)(response);
+            const hasUserEcho = cleanResponse
+                .split('\n')
+                .some(line => cli_patterns_1.COPILOT_USER_ECHO_PATTERN.test(line));
+            if (!hasUserEcho && cli_patterns_1.COPILOT_BOOT_BANNER_ANCHORS.some(anchor => anchor.test(cleanResponse))) {
+                return incompleteResult(totalLines);
+            }
+        }
         // Gemini-specific check
         if (cliToolId === 'gemini') {
             const bannerCharCount = (response.match(/[░███]/g) || []).length;
@@ -310,6 +478,12 @@ function extractResponse(output, lastCapturedLine, cliToolId, captureWindowLines
             lineCount: endIndex,
             bufferReset,
             captureWindowSaturated,
+            // Issue #1911: opencode only. `echoEnd < 0` means the turn is longer than
+            // the alternate-screen pane and its head has already scrolled away, so
+            // `response` starts mid-answer. Nothing else in this frame can recover it.
+            turnHeadTruncated: openCodeCleanLines
+                ? (0, response_extractor_1.resolveOpenCodeTurnRegion)(openCodeCleanLines).headTruncated
+                : undefined,
         };
     }
     // Check if this is an interactive prompt
@@ -394,10 +568,21 @@ async function checkForResponse(worktreeId, cliToolId, instanceId) {
         // taken from the same constant extractResponse() measures saturation against
         // (Issue #1670) — a literal here would silently decouple the two.
         const output = await (0, cli_session_1.captureSessionOutput)(worktreeId, cliToolId, tmux_capture_cache_1.CACHE_MAX_CAPTURE_LINES, instanceId);
-        // Layer 2: Accumulate TUI content for full-screen TUI tools (for overlap tracking only).
+        // Issue #2000: the frame is in hand, so this is the cheapest place to ask
+        // whether the model API has stalled the session. Level in, edge out — see
+        // the helper.
+        observeUpstreamFaultForPush(worktreeId, cliToolId, instanceId, output);
+        // Layer 2: Accumulate TUI content for full-screen TUI tools, so a turn that
+        // outgrows the alternate-screen pane keeps the head that has scrolled away.
         if (cliToolId === 'opencode' || cliToolId === 'copilot') {
             const pollerKey = (0, response_poller_core_1.getPollerKey)(worktreeId, cliToolId, instanceId);
-            (0, tui_accumulator_1.accumulateTuiContent)(pollerKey, output, cliToolId);
+            // Issue #1911: opencode is accumulated from the CURRENT TURN'S REGION
+            // rather than the whole frame. Feeding the raw pane seeded the accumulator
+            // with the previous turn's transcript, the echoed prompt and the bottom
+            // chrome on the very first poll, so the accumulated content could never be
+            // used as a response source without re-introducing defect 1.
+            const accumulatorSource = cliToolId === 'opencode' ? (0, response_extractor_1.sliceOpenCodeTurn)(output) : output;
+            (0, tui_accumulator_1.accumulateTuiContent)(pollerKey, accumulatorSource, cliToolId);
         }
         // Extract response
         const result = extractResponse(output, lastCapturedLine, cliToolId, tmux_capture_cache_1.CACHE_MAX_CAPTURE_LINES);
@@ -499,16 +684,30 @@ async function checkForResponse(worktreeId, cliToolId, instanceId) {
             // episode the store opens are the same number.
             const promptObservedAt = Date.now();
             const promptWaitingSince = (0, waiting_episode_state_1.getWaitingEpisode)(worktreeId, cliToolId, instanceId)?.since ?? promptObservedAt;
-            void (0, push_1.notifyPushSubscribers)({
+            // Issue #1999: Auto-Yes is a declaration that this session's prompts are
+            // answered without a human, so notifying for one is telling the reader the
+            // opposite of the truth. Only the notification is gated — the episode
+            // below still opens, so the WebSocket frame, the status API and the #1790
+            // reminder all see the wait exactly as they did before. The gate runs
+            // before the call rather than inside it because `shouldSendWaitingPush`
+            // records the episode the moment it decides to send.
+            if (!(0, prompt_push_gate_1.isPromptPushSuppressed)({
                 worktreeId,
-                worktreeName: worktree.name,
-                kind: 'prompt',
-                agentName: resolvedInstanceId,
-                instanceId: resolvedInstanceId,
-                waitingKind: 'prompt',
+                cliToolId,
+                instanceId,
                 waitingSince: promptWaitingSince,
-                excerpt: promptDetection.promptData?.question ?? promptSaveContent,
-            }).catch(() => { });
+            })) {
+                void (0, push_1.notifyPushSubscribers)({
+                    worktreeId,
+                    worktreeName: worktree.name,
+                    kind: 'prompt',
+                    agentName: resolvedInstanceId,
+                    instanceId: resolvedInstanceId,
+                    waitingKind: 'prompt',
+                    waitingSince: promptWaitingSince,
+                    excerpt: promptDetection.promptData?.question ?? promptSaveContent,
+                }).catch(() => { });
+            }
             (0, waiting_episode_state_1.observeWaitingEdge)({
                 worktreeId,
                 cliToolId,
@@ -548,8 +747,26 @@ async function checkForResponse(worktreeId, cliToolId, instanceId) {
             (0, tui_accumulator_1.clearTuiAccumulator)(pollerKey);
         }
         else if (cliToolId === 'opencode') {
-            cleanedResponse = (0, response_cleaner_1.cleanOpenCodeResponse)(result.response);
             const pollerKey = (0, response_poller_core_1.getPollerKey)(worktreeId, cliToolId, instanceId);
+            // Issue #1911 defect 3: opencode wrote to the Layer-2 accumulator but never
+            // read it, so any turn longer than the pane was saved without its head.
+            //
+            // Read it only when the head is ACTUALLY gone, which is what
+            // `turnHeadTruncated` measures — deliberately NOT copilot's unconditional
+            // `accumulated || response`. The accumulator appends whatever the overlap
+            // check cannot match against the previous poll, and opencode rewrites rows
+            // in place while it works (`+ Thought: … · 12ms` becomes `· 579ms`, a
+            // pending patch row becomes the applied edit). Every such rewrite breaks
+            // the overlap and re-appends the lines above it, so preferring the
+            // accumulator for the common short answer would duplicate content that
+            // `result.response` already holds exactly. When the echo is off screen the
+            // frame is missing content outright, and a possible duplicate beats a
+            // guaranteed truncation.
+            const accumulatedContent = (0, tui_accumulator_1.getAccumulatedContent)(pollerKey);
+            const sourceContent = result.turnHeadTruncated && accumulatedContent
+                ? accumulatedContent
+                : result.response;
+            cleanedResponse = (0, response_cleaner_1.cleanOpenCodeResponse)(sourceContent);
             (0, tui_accumulator_1.clearTuiAccumulator)(pollerKey);
         }
         // If cleaned response is empty or just "[No content]", skip saving