commandmate 0.44.1 → 0.44.3

package/dist/server/src/lib/session/current-output-builder.js

@@ -7,64 +7,20 @@
  * over WebSocket (terminal streaming), keeping the pull (HTTP) and push (WS)
  * paths byte-for-byte consistent (DRY).
  */
-var __createBinding = (this && this.__createBinding) || (Object.create ? (function(o, m, k, k2) {
-    if (k2 === undefined) k2 = k;
-    var desc = Object.getOwnPropertyDescriptor(m, k);
-    if (!desc || ("get" in desc ? !m.__esModule : desc.writable || desc.configurable)) {
-      desc = { enumerable: true, get: function() { return m[k]; } };
-    }
-    Object.defineProperty(o, k2, desc);
-}) : (function(o, m, k, k2) {
-    if (k2 === undefined) k2 = k;
-    o[k2] = m[k];
-}));
-var __setModuleDefault = (this && this.__setModuleDefault) || (Object.create ? (function(o, v) {
-    Object.defineProperty(o, "default", { enumerable: true, value: v });
-}) : function(o, v) {
-    o["default"] = v;
-});
-var __importStar = (this && this.__importStar) || (function () {
-    var ownKeys = function(o) {
-        ownKeys = Object.getOwnPropertyNames || function (o) {
-            var ar = [];
-            for (var k in o) if (Object.prototype.hasOwnProperty.call(o, k)) ar[ar.length] = k;
-            return ar;
-        };
-        return ownKeys(o);
-    };
-    return function (mod) {
-        if (mod && mod.__esModule) return mod;
-        var result = {};
-        if (mod != null) for (var k = ownKeys(mod), i = 0; i < k.length; i++) if (k[i] !== "default") __createBinding(result, mod, k[i]);
-        __setModuleDefault(result, mod);
-        return result;
-    };
-})();
 Object.defineProperty(exports, "__esModule", { value: true });
-exports.mergeStructuredStatus = mergeStructuredStatus;
+exports.mergeStructuredStatus = exports.resetChatTurnProgressState = exports.emitChatTurnProgress = exports.buildChatTurnProgress = void 0;
 exports.buildCurrentOutput = buildCurrentOutput;
-exports.resetChatTurnProgressState = resetChatTurnProgressState;
-exports.buildChatTurnProgress = buildChatTurnProgress;
-exports.emitChatTurnProgress = emitChatTurnProgress;
 const db_1 = require("../../lib/db");
-// Issue #2429: the send ledger, read directly from `chat-db` rather than from
-// the `@/lib/db` barrel because that barrel does not re-export it. It is the
-// SAME row `commandmate wait` asks for over
-// `GET /api/worktrees/:id/messages?limit=1&unit=pairs` (see `readNewestPromptAt`
-// in `cli/commands/wait.ts`), so the server and the CLI cannot disagree about
-// when this instance was last handed a prompt.
-const chat_db_1 = require("../../lib/db/chat-db");
 const unclassified_frame_tracker_1 = require("../../lib/detection/unclassified-frame-tracker");
 const session_starting_state_1 = require("../../lib/session/session-starting-state");
 const composer_text_1 = require("../../lib/detection/composer-text");
 const upstream_faults_1 = require("../../lib/detection/upstream-faults");
 const opencode_pane_obstruction_1 = require("../../lib/detection/opencode-pane-obstruction");
-const types_1 = require("../../lib/realtime/types");
-const models_1 = require("../../types/models");
 const logger_1 = require("../../lib/logger");
 const manager_1 = require("../../lib/cli-tools/manager");
-const types_2 = require("../../lib/cli-tools/types");
+const types_1 = require("../../lib/cli-tools/types");
 const registry_1 = require("../../lib/hooks/sources/registry");
+const hook_turn_hold_1 = require("../../lib/session/hook-turn-hold");
 const define_source_1 = require("../../lib/hooks/sources/define-source");
 const subscription_1 = require("../../lib/hooks/sources/opencode/subscription");
 const permission_decision_state_1 = require("../../lib/hooks/permission-decision-state");
@@ -77,6 +33,7 @@ const cli_session_1 = require("../../lib/session/cli-session");
 const status_detector_1 = require("../../lib/detection/status-detector");
 const auto_yes_manager_1 = require("../../lib/polling/auto-yes-manager");
 const auto_yes_suppression_state_1 = require("../../lib/polling/auto-yes-suppression-state");
+const auto_yes_enter_fallback_1 = require("../../lib/polling/auto-yes-enter-fallback");
 const prompt_dedup_state_1 = require("../../lib/polling/prompt-dedup-state");
 const status_capture_config_1 = require("../../config/status-capture-config");
 const tmux_capture_cache_1 = require("../../lib/tmux/tmux-capture-cache");
@@ -86,509 +43,25 @@ const prompt_waiting_composition_1 = require("../../lib/session/prompt-waiting-c
 const provisional_turn_1 = require("../../lib/session/provisional-turn");
 const status_evidence_1 = require("../../lib/session/status-evidence");
 const ask_user_question_prompt_1 = require("../../lib/session/ask-user-question-prompt");
+const prompt_view_1 = require("../../lib/session/prompt-view");
 const auto_yes_dialog_gate_1 = require("../../lib/polling/auto-yes-dialog-gate");
 const layer_disagreement_1 = require("../../lib/session/layer-disagreement");
 const structured_prompt_1 = require("../../lib/session/structured-prompt");
+const chat_turn_progress_1 = require("./chat-turn-progress");
+const structured_status_merge_1 = require("./structured-status-merge");
+const current_output_history_writers_1 = require("./current-output-history-writers");
+const detection_divergence_1 = require("./detection-divergence");
+// Issue #3215: chat turn progress lives in `chat-turn-progress`. Re-exported
+// under the same names so every existing import of this module keeps resolving.
+var chat_turn_progress_2 = require("./chat-turn-progress");
+Object.defineProperty(exports, "buildChatTurnProgress", { enumerable: true, get: function () { return chat_turn_progress_2.buildChatTurnProgress; } });
+Object.defineProperty(exports, "emitChatTurnProgress", { enumerable: true, get: function () { return chat_turn_progress_2.emitChatTurnProgress; } });
+Object.defineProperty(exports, "resetChatTurnProgressState", { enumerable: true, get: function () { return chat_turn_progress_2.resetChatTurnProgressState; } });
+// Issue #3215: the status merge lives in `structured-status-merge`. Re-exported
+// under the same names so every existing import of this module keeps resolving.
+var structured_status_merge_2 = require("./structured-status-merge");
+Object.defineProperty(exports, "mergeStructuredStatus", { enumerable: true, get: function () { return structured_status_merge_2.mergeStructuredStatus; } });
 const logger = (0, logger_1.createLogger)('current-output-builder');
-/**
- * Write the "detection failed on this frame" row (Issue #1708).
- *
- * Stored as a `prompt` message so `capture --prompts` — the audit trail that
- * exists precisely to answer "why did this stall?" — lists it alongside the
- * prompts that WERE detected. It must never read as one of them, so the
- * promptData carries `type: 'unclassified'` and `status: 'unclassified'`; the
- * latter is also what keeps it out of `markPendingPromptsAsAnswered()`, whose
- * SQL selects `status = 'pending'`. A frame nobody could read must not end up
- * stamped "(answered via terminal)" the moment the flag clears.
- *
- * Not broadcast: this is a record for after the fact, and the prompt-answering
- * UI has nothing to render for a frame with no parsed options.
- *
- * REACH, stated plainly because it is a real limit: this is driven by
- * observation, not by the server's own loops. `buildCurrentOutput` has exactly
- * two callers — the current-output route and `broadcastTerminalSnapshot`, which
- * returns immediately when the room has no subscribers. So a row is written
- * while `commandmate wait` is polling (every POLL_INTERVAL_MS), while a browser
- * has the terminal open, or on a `capture --json`. A stall that nobody is
- * watching at all writes nothing, and `capture --prompts` afterwards will not
- * show it. That is tolerable because the stalls this exists to explain are the
- * ones something WAS waiting on — but it means the Auto-Yes poller running
- * alone is not enough. Feeding the tracker from that loop would need a second
- * producer of `isUnclassifiedActive`, i.e. either duplicating its definition or
- * adding a detectSessionStatus pass to a hot path; deliberately not done here.
- *
- * Best effort — a failed insert must never break the payload the caller is
- * waiting on. The tracker has already marked the run as recorded, so a failure
- * costs this one row, not a retry storm.
- */
-/**
- * The sentence that turns "nothing could read this frame" into "here is what is
- * on it, and here is the key that removes it" (Issue #2095).
- *
- * Empty string when there is no obstruction, so every caller can concatenate it
- * unconditionally and the #1708 wording is byte-identical on a frame that has
- * none.
- *
- * English, like the rest of {@link recordUnclassifiedFrame}'s row and unlike the
- * UI banner this pairs with. The row is read in `capture --prompts` as often as
- * in the history pane, and `commandmate` has no locale to read it in.
- */
-function describePaneObstruction(obstruction) {
-    if (!obstruction)
-        return '';
-    return (` Cause: opencode's sidebar is sharing rows with the transcript ` +
-        `(paneObstruction=${obstruction.id}, second column reads ` +
-        `${JSON.stringify(obstruction.matchedText)}), which covers the marker that ends a ` +
-        `turn. Press \`${opencode_pane_obstruction_1.OPENCODE_SIDEBAR_RECOVERY_CHORD}\` in the pane to close it.`);
-}
-/**
- * Push a history row this module just wrote to the worktree room (Issue #2214).
- *
- * Always `'message'`: both callers INSERT a brand-new row, so nothing has been
- * delivered for it before and the client appends rather than replaces.
- *
- * Detached on purpose, and for two reasons that both matter here:
- *
- *  - the `ws-server` import stays dynamic, which is the same bargain
- *    {@link emitChatTurnProgress} strikes — this module's *other* callers (the
- *    `/current-output` route and the terminal push) must not pull the WebSocket
- *    server into their graph just by building a payload;
- *  - the row is already committed when this runs, so a socket write can never
- *    turn a written row into a failed one. The two record functions below are
- *    best-effort by contract and their callers are waiting on a payload.
- *
- * #2214 recorded a limitation here — a route bundle holding its own empty copy
- * of `ws-server`'s `rooms` under `next dev` — and added that "production runs
- * one custom-server bundle and is unaffected". **That last clause was wrong.**
- * `npm run dev` and `npm start` run the *same* custom server (`tsx server.ts`
- * vs `node dist/server/server.js`); what differs is only whether Next evaluates
- * a route handler from a dev compilation or from `.next/server`. Either way the
- * route handler's copy of this module and of `ws-server` is not the custom
- * server's, so this push was silent in production too. #2220 bridged it: the
- * `broadcastMessage` below now reaches the socket owner through
- * `lib/realtime/publisher-registry` regardless of which graph called it.
- */
-function broadcastRecordedRow(worktreeId, message) {
-    void Promise.resolve().then(() => __importStar(require('../../lib/ws-server'))).then(({ broadcastMessage }) => {
-        broadcastMessage('message', { worktreeId, message });
-    })
-        .catch((error) => {
-        logger.warn('history-row-broadcast-failed', {
-            worktreeId,
-            error: error instanceof Error ? error.message : String(error),
-        });
-    });
-}
-function recordUnclassifiedFrame(db, params) {
-    const dwellSeconds = Math.round(params.dwellMs / 1000);
-    const statusReason = `${params.sessionStatus}/${params.sessionStatusReason}`;
-    const question = `Unclassified interactive frame (${statusReason}) held for ${dwellSeconds}s. ` +
-        `The detection layer could not parse it, so no prompt was published and ` +
-        `nothing could answer it. Inspect the raw pane with ` +
-        `\`commandmate capture ${params.worktreeId} --pane\`.` +
-        // Issue #2095: appended rather than substituted. Everything above is still
-        // true — the frame really was unreadable — and a caller matching on the
-        // #1708 wording keeps matching. What follows turns "we could not read it"
-        // into "here is why, and here is the key that fixes it".
-        describePaneObstruction(params.obstruction);
-    const record = {
-        type: models_1.UNCLASSIFIED_PROMPT_TYPE,
-        status: 'unclassified',
-        question,
-        options: [],
-        dwellSeconds,
-        sessionStatusReason: statusReason,
-    };
-    try {
-        const message = (0, db_1.createMessage)(db, {
-            worktreeId: params.worktreeId,
-            role: 'assistant',
-            content: question,
-            messageType: 'prompt',
-            // Not a PromptData: nothing may answer this row, which is why the record
-            // type is kept out of that union (see UnclassifiedFrameRecord). The column
-            // is shared, so the cast is confined to this one write.
-            promptData: record,
-            timestamp: new Date(),
-            cliToolId: params.cliToolId,
-            instanceId: params.instanceId,
-        });
-        logger.info('unclassified-frame-recorded', {
-            worktreeId: params.worktreeId,
-            cliToolId: params.cliToolId,
-            dwellSeconds,
-            statusReason,
-        });
-        // `cliToolId` / `instanceId` are already the explicit values passed above —
-        // `createMessage` hands back the caller's own object — so the published row
-        // addresses the same instance the column does.
-        broadcastRecordedRow(params.worktreeId, message);
-    }
-    catch (error) {
-        logger.warn('unclassified-frame-record-failed', {
-            worktreeId: params.worktreeId,
-            error: error instanceof Error ? error.message : String(error),
-        });
-    }
-}
-/**
- * Write the "the agent said a dialog is open and we could not read it" row
- * (Issue #1725, continuing #1708's proposal 2).
- *
- * Written once per waiting episode, and ONLY while the scraper is publishing no
- * prompt of its own. Both halves matter:
- *
- *  - once, because `buildCurrentOutput` runs on every poll and a row per poll
- *    would turn one blocked dialog into a wall of identical history;
- *  - only when the scraper is blind, because when it is not, the existing
- *    prompt writers already record that prompt with its options and its answer.
- *    A second row would double-count the audit trail `capture --prompts` prints
- *    and put a "nobody could read this" line next to the parsed prompt that
- *    proves somebody could.
- *
- * So a row here means exactly one thing, which is the thing #1708 asked to be
- * recorded: a prompt existed and the detection layer did not see it.
- *
- * Best effort, for the same reason as {@link recordUnclassifiedFrame}: the
- * caller is waiting on a payload, and a failed insert must cost this row and
- * nothing else.
- */
-function recordStructuredPrompt(db, params) {
-    const record = (0, structured_prompt_1.buildStructuredPromptHistoryRecord)(params.worktreeId, params.facts);
-    try {
-        const message = (0, db_1.createMessage)(db, {
-            worktreeId: params.worktreeId,
-            role: 'assistant',
-            content: record.question,
-            summary: `structured prompt · source=${params.state.source}${params.state.toolName ? ` · tool=${params.state.toolName}` : ''}`,
-            messageType: 'prompt',
-            // Not a PromptData: it has no options and nothing may answer it by
-            // number. The column is shared, so the cast is confined to this write —
-            // the same arrangement UnclassifiedFrameRecord uses.
-            promptData: record,
-            timestamp: new Date(),
-            cliToolId: params.cliToolId,
-            instanceId: params.instanceId,
-        });
-        logger.info('structured-prompt-recorded', {
-            worktreeId: params.worktreeId,
-            cliToolId: params.cliToolId,
-            instanceId: params.instanceId,
-            source: params.state.source,
-            toolName: params.state.toolName,
-        });
-        broadcastRecordedRow(params.worktreeId, message);
-    }
-    catch (error) {
-        logger.warn('structured-prompt-record-failed', {
-            worktreeId: params.worktreeId,
-            error: error instanceof Error ? error.message : String(error),
-        });
-    }
-}
-/**
- * The `AskUserQuestion` call as the degraded prompt can describe it
- * (Issue #1726).
- *
- * Only the first question, and no option numbers — see
- * {@link StructuredAskUserQuestionSummary} for why a layer that cannot see the
- * screen must not publish numbers for it.
- */
-function summarizeAskUserQuestion(episode) {
-    const first = episode?.spec.questions[0];
-    if (!first)
-        return null;
-    return {
-        question: first.question,
-        labels: first.choices.map((choice) => choice.label),
-        questionCount: episode.spec.questions.length,
-        // Issue #2951: a question that takes a typed answer, so the panel and the
-        // phone sheet can offer an input for it.
-        ...(first.custom ? { custom: true } : {}),
-    };
-}
-/**
- * Prefer the agent's own account of what it is doing over the screen scrape
- * (Issue #1723).
- *
- * Pure, and exported so the whole precedence table can be tested without a tmux
- * session behind it.
- *
- * ## Why the scraper still wins in two cases
- *
- * **`waiting` on the scraper's side always wins.** A frame the detector reads
- * as a prompt, a selection list or a pager is a frame a human has to act on,
- * and this Issue deliberately does not touch `isPromptWaiting` / `promptData` /
- * `isSelectionListActive` (they are #1725's). Letting a structured `running`
- * overwrite `sessionStatus` while those three still said "answer me" would
- * publish a self-contradicting payload. It is also the empirically necessary
- * rule: the live capture found that Claude emits **no event at all** while an
- * `AskUserQuestion` selection or "Ready to submit your answers?" screen is up
- * (`agent-hooks-live-verification.md` §5.6), so the newest structured fact
- * there is the `user_prompt_submit` that opened the turn — `running` — while
- * the truth on screen is "waiting for a human". That is precisely the #1708
- * stall, and the scraper is the only layer that can see it.
- *
- * **A structured `waiting` is applied only through the prompt-waiting state**
- * (Issue #1725). #1723 recorded `Notification(permission_prompt)` and stopped
- * there, for a reason that had to be answered before it could be promoted:
- * nothing marks a permission prompt as *answered*, so a verdict read off the
- * last event alone would stick until the next `Stop` and describe a session
- * that went back to work minutes ago. `getStructuredPromptWaiting` is that
- * answer — it is released by `Stop` / `user_prompt_submit` / a generation
- * change, by the scraper reporting the frame it corroborated has cleared, and
- * by expiry. So the `waiting` promoted here is the one that survives all of
- * those, passed in explicitly; the raw `structured.status === 'waiting'` still
- * decides nothing on its own.
- *
- * ## `isUnclassifiedActive` is not this function's to move (Issue #2011)
- *
- * The flag is carried through from the scraper on every path. It answers "could
- * the detection layer read this frame?", and no amount of knowledge about the
- * TURN changes the answer for the FRAME:
- *
- *  - a static overlay left on screen after a turn (`/help`, #1497) reads as
- *    `running`/`no_recent_output` while the structured layer says `ready` — the
- *    structured layer adds nothing about the screen, and clearing the flag would
- *    take away the navigation hatch the user needs to escape;
- *  - a frame nobody can classify while the structured layer says `running` is
- *    still a frame nobody can classify. `wait`'s unclassified dwell (exit 10)
- *    is the last hatch for a screen that produces no events at all, and #1708
- *    exists because it was missing. A structured `running` does not prove a
- *    human is not needed — see the AskUserQuestion case above.
- *
- * `#1723`'s reported case — `Stop` arrives while the spinner is still painted —
- * needs no help from here: that frame reads `running`/`thinking_indicator`, which
- * is classified, so the flag was already down and `wait` completes on the
- * structured `ready` alone.
- *
- * What this function DOES move is `evidence`, and only upwards: see
- * {@link hookClosedTurn}.
- *
- * @param turn - The published turn record for this instance, or null. Read only
- *   for {@link hookClosedTurn}; `structured` remains the status authority.
- */
-function mergeStructuredStatus(scraper, structured, promptWaiting = null, turn = null, lastPromptAt = null) {
-    if (scraper.status === 'waiting') {
-        return { ...scraper, structuredApplied: false };
-    }
-    // Issue #1725, the OR rule at the status level: the scraper reads this frame
-    // as running or ready, and the agent has told us a dialog is in front of it.
-    // Publishing `running` next to `isPromptWaiting: true` would be a payload
-    // that contradicts itself, and every consumer of `sessionStatus` — the
-    // sidebar dot, `deriveSessionStatus`, the worktrees API — would show a worker
-    // that needs a human as one that is busy.
-    if (promptWaiting !== null) {
-        return {
-            status: 'waiting',
-            reason: (0, prompt_waiting_composition_1.structuredWaitingReason)(promptWaiting),
-            thinking: false,
-            // Untouched: what the scraper could read about this frame does not change
-            // because the agent told us a dialog is open (Issue #1924).
-            evidence: scraper.evidence,
-            isUnclassifiedActive: scraper.isUnclassifiedActive,
-            structuredApplied: true,
-        };
-    }
-    if (structured === null || structured.status === 'waiting') {
-        return { ...scraper, structuredApplied: false };
-    }
-    // Issue #2429: the structured `ready` is about a turn older than the prompt
-    // this instance is currently answering, and the screen says so. See
-    // {@link structuredReadyPredatesPrompt} for why that combination is the only
-    // one in which the scraper wins a `running`.
-    if (structuredReadyPredatesPrompt(scraper, structured, turn, lastPromptAt)) {
-        return { ...scraper, structuredApplied: false };
-    }
-    const thinking = structured.status === 'running';
-    // Issue #2011 (対応 2): the agent's own turn close IS positive evidence.
-    //
-    // #1927 (DR2-003) guarded this override with `scraper.evidence === 'positive'`
-    // to stop a structured `ready` clearing `isUnclassifiedActive` on a frame
-    // nobody could read. It over-corrected twice over. First, the conjunct made
-    // the whole expression a no-op: `evidence = cond ? 'positive' : scraper.evidence`
-    // where `cond` requires `scraper.evidence === 'positive'` returns
-    // `scraper.evidence` on both arms, so the branch could not change a value in
-    // any direction. Second, the fix it was reaching for belonged one field over —
-    // the hatch is held open by {@link ScraperVerdict.isUnclassifiedActive}, which
-    // is carried through below rather than re-derived, so the evidence no longer
-    // has to be understated to protect it.
-    //
-    // What that leaves is a payload that stopped contradicting itself. A pane
-    // whose `reason` reads `hook_stop` while `statusEvidence` reads `'none'` is
-    // denying, in one field, the strongest positive signal this server can get: a
-    // `Stop` from the agent, for a turn this server watched open. `closedAt >
-    // openedAt` is what narrows it to that case — a `Stop` that arrived with no
-    // turn open publishes `openedAt: null` (see `recordAgentEvent`), and a close
-    // the SCREEN inferred carries one of the other {@link TurnCloseReason} values.
-    // Freshness needs no bound of its own: `getStructuredSessionState` answered
-    // null above once the display event passed STRUCTURED_STATE_MAX_AGE_MS.
-    //
-    // `scraper.status === 'running'` is deliberately NOT required. The session this
-    // Issue was reported from sat at `ready`/`input_prompt` with `closedBy: 'stop'`
-    // — the agent had said it was done and the frame agreed — and the old conjunct
-    // is what kept publishing `'none'` for it.
-    const evidence = structured.status === 'ready' && hookClosedTurn(turn) ? 'positive' : scraper.evidence;
-    return {
-        status: structured.status,
-        reason: structured.reason,
-        thinking,
-        evidence,
-        // Issue #2011: what the structured layer knows about the TURN says nothing
-        // about whether this FRAME could be read. #1708's dwell and the nav hatch
-        // are the last way out of a pane nothing can drive, and a `Stop` does not
-        // make an unreadable pane readable — see the `/help` overlay fixture in
-        // `tests/unit/lib/detection/fixtures/claude-live-2011/`.
-        isUnclassifiedActive: scraper.isUnclassifiedActive,
-        structuredApplied: true,
-    };
-}
-/**
- * Whether the agent's own `Stop` closed a turn this server watched open
- * (Issue #2011, 対応 2).
- *
- * Both halves are required. `closedBy: 'stop'` rules out the five close reasons
- * that are the server's inference rather than the agent's word (`stale`,
- * `generation`, `session_end`, `scraper_evidence`, `resync_idle`), and
- * `closedAt > openedAt` rules out a `Stop` whose turn was never observed
- * opening — `recordAgentEvent` publishes `openedAt: null` for that, and a close
- * with nothing behind it is not a completion anybody watched.
- */
-function hookClosedTurn(turn) {
-    if (turn === null)
-        return false;
-    const { closedBy, closedAt, openedAt } = turn;
-    return closedBy === 'stop' && closedAt !== null && openedAt !== null && closedAt > openedAt;
-}
-/**
- * Whether a structured `ready` could be about a turn that ended before the
- * prompt now on screen (Issue #2429).
- *
- * The cheap half of {@link structuredReadyPredatesPrompt}, split out because
- * `buildPayload` asks it FIRST: it is the gate on the one database read this
- * rule needs, and a session that is not in this state must not pay for the send
- * ledger on every poll. One expression, two callers — the alternative is the
- * "two expressions for one fact" the merge's own docblock says is how this
- * layer drifts.
- *
- * Three conjuncts, and all three are about the same instant:
- *
- *  - **the screen is positively generating.** `ScraperVerdict.thinking` is
- *    `isGeneratingStatus`, i.e. `running` with `thinking_indicator` /
- *    `opencode_processing_indicator` behind it — a spinner, `✻ Thinking…` or
- *    `esc to interrupt` that a tool's own pattern matched. It is deliberately
- *    NOT `scraper.status === 'running'`: the `no_recent_output` and
- *    `unknown_frame` floors are also `running`, and neither is evidence of
- *    anything. A frame that merely stopped changing must never retire a `Stop`
- *    the agent actually sent.
- *  - **the structured layer says `ready`.** `running` and `waiting` already win
- *    on their own paths and are not in question here.
- *  - **that `ready` came from the agent's own `Stop`.**
- *    `getStructuredSessionState` publishes `ready / hook_stop` exactly when the
- *    turn record carries `closedBy: 'stop'` with a `closedAt`, so the record is
- *    read rather than the folded reason.
- *
- * `openedAt` is deliberately not required, which is what separates this from
- * {@link hookClosedTurn}. A `Stop` that arrived with no turn open publishes
- * `openedAt: null`, and for the tool this Issue was reported from that is the
- * ORDINARY shape: Command Code cannot emit `UserPromptSubmit` (its loader
- * validates the event name against a closed list) and emits no
- * `PreToolUse` / `PostToolUse` on a turn that calls no tool, so nothing ever
- * opens the turn. Requiring an `openedAt` here would exclude precisely the case
- * this rule exists for.
- */
-function staleReadyCandidate(scraper, structured, turn) {
-    if (!scraper.thinking)
-        return false;
-    if (structured === null || structured.status !== 'ready')
-        return false;
-    if (turn === null)
-        return false;
-    return turn.closedBy === 'stop' && turn.closedAt !== null;
-}
-/**
- * Whether the structured layer's `ready` has been outlived by the newest prompt
- * this instance was handed (Issue #2429).
- *
- * ## The defect this closes
- *
- * The merge above prefers the agent's own account to the screen, and until this
- * Issue the only exception was a scraper `waiting` (#1708). That is correct for
- * every tool that can say when a turn BEGINS — claude, codex, copilot, gemini
- * and antigravity all post a turn-opening event, so a live turn replaces the
- * previous turn's `stop` before the first generating frame is ever read.
- *
- * Command Code can post neither: no `UserPromptSubmit`, and no `PreToolUse` /
- * `PostToolUse` on a turn that calls no tool. The previous turn's `ready /
- * hook_stop` therefore stays the newest structured fact for the whole of the
- * next turn, and the merge published it over a pane that was visibly generating.
- * Measured 2026-09-08 on a 19 s turn: `sessionStatus` read `ready / hook_stop`
- * from 4 s to 18 s while the status row said `esc to interrupt`. `commandmate
- * wait` reads that field — not the frame — for "is at its composer", so #1975's
- * 60 s unanswered-prompt hold was the only thing standing between a long turn
- * and a `basis=scraper_ready` completion reported before the reply existed.
- *
- * ## Why a comparison rather than a timer
- *
- * The same comparison `wait` already makes (`outstandingPrompt`), against the
- * same two server-stamped facts: the turn's `closedAt`, and the timestamp of
- * the newest user row in the chat ledger. A `Stop` that POSTDATES the newest
- * prompt is this turn's own — the agent finished, the spinner on the frame is a
- * repaint that has not settled, and the structured `ready` keeps winning. A
- * `Stop` that predates it has reported neither the start nor the end of the
- * work now on screen, and about that work it says nothing at all.
- *
- * Shortening #1975's hold would have been the other repair, and the Issue rules
- * it out for a reason worth restating here: the hold is what stops a false
- * completion during a turn nobody has reported yet, so a shorter one moves the
- * false completion earlier rather than removing it.
- *
- * @param lastPromptAt - Epoch ms of the newest prompt handed to this instance,
- *   or null when the ledger was not read or holds none. Null decides nothing:
- *   an unreadable ledger is not evidence that nothing was sent, so the
- *   structured verdict stands exactly as it did before this Issue.
- */
-function structuredReadyPredatesPrompt(scraper, structured, turn, lastPromptAt) {
-    if (lastPromptAt === null)
-        return false;
-    if (!staleReadyCandidate(scraper, structured, turn))
-        return false;
-    const closedAt = turn?.closedAt ?? null;
-    return closedAt !== null && closedAt < lastPromptAt;
-}
-/**
- * When this instance was last handed a prompt, or null (Issue #2429).
- *
- * The server's half of the comparison `commandmate wait` makes over HTTP. Both
- * sides read the same row — the newest `role: 'user'` message scoped to this
- * (worktree, tool, instance) — so the field this function feeds and the notice
- * `wait` prints cannot describe different sends.
- *
- * Best effort, like {@link recordUnclassifiedFrame} and
- * {@link recordStructuredPrompt}: the caller is building a payload, and a
- * ledger that cannot be read must cost this one comparison and nothing else.
- * Null is reported rather than a guess, and null leaves the pre-#2429
- * precedence in place — an unreadable ledger is not evidence that nothing was
- * sent, which is the position `wait` takes on the same read.
- */
-function readNewestPromptAt(db, worktreeId, cliToolId, instanceId) {
-    try {
-        const row = (0, chat_db_1.getLastUserMessageForInstance)(db, worktreeId, cliToolId, instanceId);
-        if (!row)
-            return null;
-        const at = row.timestamp instanceof Date ? row.timestamp.getTime() : NaN;
-        return Number.isFinite(at) ? at : null;
-    }
-    catch (error) {
-        logger.debug('newest-prompt-read-failed', {
-            worktreeId,
-            cliToolId,
-            instanceId,
-            error: error instanceof Error ? error.message : String(error),
-        });
-        return null;
-    }
-}
 /**
  * Build the current-output payload for a worktree session.
  *
@@ -616,7 +89,7 @@ async function buildCurrentOutput(db, worktreeId, cliToolId, instanceId, resolut
         // inside, so what is waited for is a worktree row and a Map lookup. What it
         // buys is that the frame's outcome is logged against the tick that produced
         // it rather than whenever the event loop got round to the detached tail.
-        await publishChatTurnProgress(db, worktreeId, cliToolId, instanceId);
+        await (0, chat_turn_progress_1.publishChatTurnProgress)(db, worktreeId, cliToolId, instanceId);
     }
     if (!resolution)
         return payload;
@@ -630,17 +103,12 @@ async function buildCurrentOutput(db, worktreeId, cliToolId, instanceId, resolut
     };
 }
 /**
- * The payload itself, with no knowledge of how its (tool, instance) pair was
- * chosen. Split from {@link buildCurrentOutput} so the resolution fields are
- * appended in one place instead of at both of the two return sites below.
+ * The agent's own events for this session, read before the pane is looked at
+ * (Issue #3215). Split out of {@link buildPayload} in the order it ran there:
+ * nothing here awaits, and `structuredEvents` is the object both of its return
+ * paths publish.
  */
-async function buildPayload(db, worktreeId, cliToolId, instanceId) {
-    const resolvedInstanceId = instanceId ?? cliToolId;
-    const manager = manager_1.CLIToolManager.getInstance();
-    const cliTool = manager.getTool(cliToolId);
-    // Issue #2886: read once, independent of `isRunning`, so both return paths
-    // below publish the same value the pane is (or would be) reached at.
-    const sessionName = cliTool.getSessionName(worktreeId, instanceId);
+function readAgentEvents(worktreeId, cliToolId, instanceId, resolvedInstanceId) {
     const stopEventAt = (0, agent_event_state_1.getLastStopEventAt)(worktreeId, cliToolId, instanceId);
     const lastEvent = (0, agent_event_state_1.getLastAgentEvent)(worktreeId, cliToolId, instanceId);
     // Issue #1924: the registry answers for every tool — a real implementation
@@ -744,12 +212,377 @@ async function buildPayload(db, worktreeId, cliToolId, instanceId) {
         // tool's status poll grows a field or a request.
         sessionDiff: (0, diff_1.ensureOpencodeSessionDiff)({ worktreeId, cliToolId, instanceId }),
     };
+    return { stopEventAt, eventSource, askUserQuestion, structuredEvents };
+}
+/**
+ * The prompt this payload publishes and the replies an approval accepts
+ * (Issue #3215). Split out of {@link buildPayload} in the order it ran there;
+ * every value below is derived from the arguments, and nothing is assigned
+ * outside this function.
+ */
+function composePromptData({ worktreeId, cliToolId, output, statusResult, startingSince, promptWaiting, askUserQuestion, eventSource, }) {
+    const scraperPromptWaiting = statusResult.hasActivePrompt;
+    // Issue #1726: the agent's own account of what it asked. It contributes only
+    // where some other layer has already established that a dialog is on screen —
+    // this record decides no status of its own, because Claude emits nothing at
+    // all while an AskUserQuestion picker is up (§5.6) and a record that asserted
+    // `waiting` from the invocation would go on asserting it long after a human
+    // answered in the terminal.
+    // Issue #2040 moved the read to the top of `buildPayload` — `readAgentEvents`
+    // takes it there today (the decision entries publish the same episode's
+    // choices) — and this line now re-uses it, so the two surfaces cannot describe
+    // different instants.
+    const scraperPromptData = statusResult.promptDetection.promptData;
+    const correctedPromptData = scraperPromptData && askUserQuestion
+        ? (0, ask_user_question_prompt_1.applyAskUserQuestion)(scraperPromptData, askUserQuestion.spec)
+        : null;
+    // The degraded form, for a dialog only the structured layer can see. Enriched
+    // with the question text when one is in flight — that turns "a dialog is open
+    // and nobody could read it" into "a dialog is open and here is what it asks".
+    //
+    // Issue #1898 adds the replies the dialog accepts, for the sources that can be
+    // answered without touching the pane. The gate is `eventIdentity`: a source
+    // that publishes a per-decision id is a source whose approval can be answered
+    // by that id, which is what makes an option NUMBER here mean something other
+    // than a line on a screen nobody parsed. `source === 'notification'` narrows
+    // it to a dialog the agent actually reported — a `permission-request` record
+    // is a prediction, and a question is answered with a choice rather than with
+    // one of these three verdicts.
+    //
+    // Issue #2031 adds the fourth conjunct and folds the whole gate into ONE
+    // value — today `promptWaiting !== null` here and the other three inside
+    // `isApiAnswerableStructuredWait` (Issue #3215).
+    // The three verdicts and the id they are delivered to are now derived
+    // from the same expression, so they cannot be published apart — and "apart"
+    // is not hypothetical, it is the state #1932 shipped: options were published
+    // on the capability alone while `decisionId` was published nowhere at all, so
+    // the panel drew no buttons and the only way out of an opencode approval in a
+    // browser was the arrow-key safety net. Options WITHOUT an id is the worse
+    // half of that pair — the numbers would reach the keystroke path, where a
+    // bare "1" selects whatever the picker happens to be highlighting (#1681).
+    const addressableDecisionId = promptWaiting !== null &&
+        (0, prompt_waiting_composition_1.isApiAnswerableStructuredWait)(promptWaiting, eventSource.capabilities.eventIdentity)
+        ? promptWaiting.decisionId
+        : null;
+    // Issue #2100 splits the two halves of #2031's single expression, because an
+    // addressable decision is now of two KINDS. The id is published for both — it
+    // is what `POST /respond` names, and a question needs it exactly as much as an
+    // approval does — but the three verdicts belong to an approval alone.
+    //
+    // Publishing both for a question is not a cosmetic error: it is precisely what
+    // #2039's third gate refuses. `readPromptQuestionChoices` returns null the
+    // moment `decisionOptions` is non-empty, so a question carrying them would
+    // draw `Allow once / Allow always / Reject` over the agent's own choices, and
+    // a verdict sent to a question is refused at the source
+    // (`question-needs-answer-verdict`). The kind is recovered from the record the
+    // same way `structuredEvents.pendingDecisions[].kind` is, through the one
+    // reader in `pending-decision-kind`.
+    const addressesQuestion = promptWaiting !== null && (0, pending_decision_kind_1.pendingDecisionKind)(promptWaiting.toolName) === 'question';
+    const decisionOptions = addressableDecisionId !== null && !addressesQuestion
+        ? // Issue #2951: in the tool's own words (OpenCode V2: `Always allow`).
+            (0, structured_prompt_1.structuredDecisionOptionsFor)(cliToolId)
+        : null;
+    const structuredFacts = promptWaiting === null
+        ? null
+        : {
+            ...promptWaiting,
+            askUserQuestion: (0, structured_status_merge_1.summarizeAskUserQuestion)(askUserQuestion),
+            decisionOptions,
+            // Explicit, though the spread above already carries a `decisionId`
+            // off the record: the spread's copy is the raw one, and what may be
+            // published is the GATED one. Letting the record's value through
+            // would put an id on a payload whose verdicts were withheld, which is
+            // the biconditional this Issue exists to hold.
+            decisionId: addressableDecisionId,
+            // Gated on the same value, for a reason of its own: `patterns` is
+            // what the `Allow always` BUTTON grants, so publishing it where no
+            // button is drawn adds a rule list to a panel that is telling the
+            // user to go and answer in the terminal. Every source but opencode
+            // therefore keeps the exact payload it had before this Issue, plus
+            // the one `decisionId: null`.
+            //
+            // Issue #2100 moves the gate onto `decisionOptions` rather than the
+            // id, which is the same value for every approval and the honest one
+            // for a question: a question draws no `Allow always`, so it may not
+            // carry the rules one would have saved. (`reportQuestionPending`
+            // records `patterns: null` anyway; the two agree by construction now
+            // instead of by coincidence.)
+            patterns: decisionOptions !== null ? promptWaiting.patterns : null,
+        };
+    const promptData = startingSince !== null
+        ? null
+        : scraperPromptWaiting
+            ? correctedPromptData ??
+                scraperPromptData ??
+                (structuredFacts ? (0, structured_prompt_1.buildStructuredPromptData)(worktreeId, structuredFacts) : null)
+            : structuredFacts
+                ? (0, structured_prompt_1.buildStructuredPromptData)(worktreeId, structuredFacts)
+                : null;
+    // Issue #2870: whether `/prompt-response` would answer the prompt published
+    // above, read by the SAME function it re-verifies with. In #2868 `promptData`
+    // came off the generic parser alone, the route refused it, and the UI's Send
+    // did nothing. Only for a parser-read prompt: the structured form (hook
+    // `decisionId`, degraded) is answered by id or not by number at all, so the
+    // key is left out there, as it is when no prompt is up. `isPromptWaiting` /
+    // `promptData` / `sessionStatus` are untouched — `wait`'s exit 10, Auto-Yes
+    // and push notifications keep reading exactly what they read before.
+    const promptAnswerable = scraperPromptWaiting && (correctedPromptData ?? scraperPromptData)
+        ? (0, auto_yes_dialog_gate_1.assessPromptAnswerability)(cliToolId, output).refusal === null
+        : undefined;
+    return { structuredFacts, promptData, promptAnswerable };
+}
+/**
+ * The scraper's verdict on the frame and the flags read off it (Issue #3272).
+ * Split out of {@link buildPayload} in the order it ran there; nothing here
+ * awaits.
+ */
+function judgeFrame(worktreeId, cliToolId, instanceId, output) {
+    // The sequence from here to `startingStatusResult` is the same as in
+    // worktree-status-helper.ts; what follows differs on purpose and is not shared
+    // (#3215 "not touched").
+    // These six expressions are deliberately kept identical to the same sequence in
+    // worktree-status-helper.ts, not shared (#3319 item 37 decision).
+    const compositeKey = (0, auto_yes_manager_1.buildCompositeKey)(worktreeId, cliToolId, instanceId);
+    const lastServerResponseTimestamp = (0, auto_yes_manager_1.getLastServerResponseTimestamp)(compositeKey);
+    const lastOutputTimestamp = lastServerResponseTimestamp ? new Date(lastServerResponseTimestamp) : undefined;
+    const rawStatusResult = (0, status_detector_1.detectSessionStatus)(output, cliToolId, lastOutputTimestamp);
+    // Issue #3179: a launch in progress. The frame is a shell prompt and the
+    // launch line, or a dialog the launch is about to answer, and none of the
+    // flags below may be read off it: the floor verdict raised the Navigate pad,
+    // the trust dialog raised the selection list / prompt sheet. A dialog that
+    // outstays the launch's own answer releases the record (a login, an unknown
+    // dialog), and from then on this is the ordinary verdict again.
+    const startingSince = (0, session_starting_state_1.observeSessionStartingFrame)(worktreeId, cliToolId, instanceId, rawStatusResult.status === 'waiting' || rawStatusResult.hasActivePrompt);
+    const statusResult = startingSince === null
+        ? rawStatusResult
+        : (0, session_starting_state_1.startingStatusResult)(rawStatusResult);
+    // Issue #1912: every `running` reason that means "the agent is producing
+    // output", not just `thinking_indicator`. opencode answers
+    // `opencode_processing_indicator` for its `esc interrupt` footer, which is
+    // the only signal it gives between the submitted prompt and the first
+    // transcript row — on a scraper-only session that stretch showed no
+    // thinking indicator at all.
+    const thinking = (0, status_detector_1.isGeneratingStatus)(statusResult);
+    const scraperPromptWaiting = statusResult.hasActivePrompt;
+    const isSelectionListActive = statusResult.status === 'waiting' && status_detector_1.SELECTION_LIST_REASONS.has(statusResult.reason);
+    const isPagerActive = statusResult.reason === status_detector_1.STATUS_REASON.CODEX_PAGER;
+    // Issue #2369: an overlay whose ONLY exit is the dismiss — Command Code's
+    // `/usage` panel, whose last row is `Press Esc to close`.
+    //
+    // A THIRD flag rather than a member of `SELECTION_LIST_REASONS`, and the
+    // separation is the fix rather than a nicety: `isSelectionListActive` is what
+    // the arrow pad is drawn from, and this screen has no highlight to move. Nor
+    // is it `isUnclassifiedActive` any more — the detector answers `waiting` for
+    // it, and `isUnclassifiedFrame` only ever says yes to `running` — which is
+    // exactly what stops the chat surface offering the eighteen-button
+    // hatch + answer-key card to a panel that accepts one key.
+    //
+    // `status === 'waiting'` is checked as well as the reason, the same shape
+    // `isSelectionListActive` above uses, so a future producer that publishes the
+    // token with some other status cannot silently turn the card into an Esc
+    // button.
+    const isDismissablePanelActive = statusResult.status === 'waiting'
+        && statusResult.reason === status_detector_1.STATUS_REASON.COMMAND_CODE_DISMISSABLE_PANEL;
+    // Issue #1497: the detection-independent nav hatch (#1017/#1494) is gated on
+    // isUnclassifiedActive. A static, unrecognized TUI overlay (e.g. Claude `/help`)
+    // whose frame stops changing degrades from `running`/`default` to
+    // `no_recent_output` once the Auto-Yes poller has stamped lastOutputTimestamp
+    // (its sole writer, auto-yes-poller.ts). That is still an interactive-but-
+    // unclassified frame — a real idle prompt (`❯`) is classified earlier as
+    // `input_prompt`, never as `no_recent_output` — so treat the timed-out fallback
+    // as unclassified too and keep the hatch open instead of stranding the user.
+    // Issue #1924, §4 D1 decision 2: stated as evidence. Issue #1927 moved that
+    // PRODUCER into the detector, because only the detector knows which rule
+    // answered — `input_prompt` is positive for a tool whose idle rule vouched for
+    // the frame and `'none'` for one whose rule declined, with the same status and
+    // the same reason on the wire.
+    const evidence = statusResult.evidence;
+    // Issue #2011: the flag is NOT that fact, and deriving it from `evidence` is
+    // the regression this Issue fixes. `'none'` is "I could not prove this pane is
+    // idle" — an ordinary Claude composer with no completion marker above it
+    // qualifies, and 7 of 8 live idle panes did on 2026-08-24. The flag's three
+    // consumers all ask the older, narrower question instead: `TerminalEscapeHatch`
+    // opens on a frame a human has to drive by hand, `wait` suppresses its
+    // completion check and eventually exits 10 on one, and `unclassified_frames`
+    // records it as a detection failure worth capturing as a fixture. That is
+    // `isUnclassifiedFrame` — the reason vocabulary, not the strength of the
+    // evidence behind a readable verdict.
+    const isUnclassifiedActive = (0, status_evidence_1.isUnclassifiedFrame)(statusResult.status, statusResult.reason);
+    return {
+        compositeKey,
+        lastServerResponseTimestamp,
+        statusResult,
+        startingSince,
+        thinking,
+        scraperPromptWaiting,
+        isSelectionListActive,
+        isPagerActive,
+        isDismissablePanelActive,
+        evidence,
+        isUnclassifiedActive,
+    };
+}
+/**
+ * The detection-divergence log lines (Issue #3272). Split out of
+ * {@link buildPayload} in the order it ran there; it only logs and tracks.
+ */
+function logDetectionDivergence(worktreeId, cliToolId, resolvedInstanceId, statusResult, structured, merged) {
+    // Issue #1723 §3: the field data this Epic is being built on. Every line is
+    // one poll where the screen and the agent disagreed about what the agent was
+    // doing, which is the only way to answer "how wrong was the scraper?" with a
+    // number instead of an anecdote. Emitted only on disagreement — a session
+    // where the two layers agree is silent — and including the disagreements this
+    // merge deliberately does NOT act on (`applied: false`), because those are
+    // exactly the cases the next Issues in the Epic have to decide about.
+    const diverging = structured !== null && structured.status !== statusResult.status;
+    if (diverging) {
+        logger.info('detection-divergence', {
+            worktreeId,
+            cliToolId,
+            instanceId: resolvedInstanceId,
+            scraperStatus: statusResult.status,
+            scraperReason: statusResult.reason,
+            structuredStatus: structured.status,
+            structuredReason: structured.reason,
+            structuredEvent: structured.event,
+            structuredEventAt: structured.at,
+            applied: merged.structuredApplied,
+        });
+    }
+    // Issue #3311: the length of a disagreement, said once when it ends. The line
+    // above is per poll and cannot carry it — see `detection-divergence.ts`.
+    const resolvedDivergence = (0, detection_divergence_1.trackDetectionDivergence)(worktreeId, cliToolId, resolvedInstanceId, diverging);
+    if (resolvedDivergence !== null) {
+        logger.info('detection-divergence-resolved', {
+            worktreeId,
+            cliToolId,
+            instanceId: resolvedInstanceId,
+            durationMs: resolvedDivergence.durationMs,
+            polls: resolvedDivergence.polls,
+        });
+    }
+}
+/**
+ * The payload of a running session (Issue #3272). Split out of
+ * {@link buildPayload} as it stood there, so the keys keep their order and the
+ * reads inside it keep theirs.
+ */
+function buildRunningPayload({ worktreeId, cliToolId, instanceId, sessionName, published, merged, newContent, output, realtimeSnippet, totalLines, lastCapturedLine, isPromptWaiting, promptData, promptAnswerable, autoYesState, lastEnterFallback, isSelectionListActive, isPagerActive, isDismissablePanelActive, startingSince, lastKnown, lastServerResponseTimestamp, compositeKey, stopEventAt, structuredEvents, model, effort, upstreamFaultMatch, paneObstruction, composer, }) {
+    return {
+        isRunning: true,
+        sessionName,
+        cliToolId,
+        sessionStatus: published.status,
+        sessionStatusReason: published.reason,
+        content: newContent,
+        fullOutput: output,
+        realtimeSnippet,
+        lineCount: totalLines,
+        lastCapturedLine,
+        isComplete: isPromptWaiting,
+        isGenerating: published.thinking,
+        thinking: published.thinking,
+        // Issue #2607: named after the tool actually running. A fixed "Claude" was
+        // published for every agent, and `capture --json` readers took it at its word.
+        thinkingMessage: published.thinking ? `${(0, types_1.getCliToolDisplayName)(cliToolId)} is thinking...` : null,
+        isPromptWaiting,
+        promptData,
+        ...(promptAnswerable !== undefined ? { promptAnswerable } : {}),
+        // Issue #3184: appended next to the value it is derived from, not at the end
+        // — it is a reading of `promptData`, and only of it.
+        promptView: (0, prompt_view_1.derivePromptView)(promptData),
+        autoYes: {
+            enabled: autoYesState?.enabled ?? false,
+            expiresAt: autoYesState?.enabled ? autoYesState.expiresAt : null,
+            stopReason: autoYesState?.stopReason,
+            lastSuppression: (0, auto_yes_suppression_state_1.getLastPolicySuppression)(worktreeId, cliToolId, instanceId),
+            // Issue #1694: undefined (so the key is absent from the JSON) unless a
+            // stop pattern actually fired — the state clears it on every other path.
+            stopMatchedText: autoYesState?.stopMatchedText,
+            // Issue #3397: appended last, after the published fields above. Null when
+            // Auto-Yes never sent its Enter to an unreadable choice screen here.
+            lastEnterFallback,
+        },
+        isSelectionListActive,
+        isPagerActive,
+        isDismissablePanelActive,
+        isUnclassifiedActive: startingSince === null && merged.isUnclassifiedActive,
+        startingSince,
+        // Issue #1926: evidence strength, named the way §4 D1 names it. Not the same
+        // fact as `isUnclassifiedActive` (Issue #2011); published from the merged
+        // verdict so it agrees with the status it accompanies.
+        statusEvidence: published.evidence,
+        lastKnownStatus: lastKnown?.status ?? null,
+        lastKnownStatusAt: lastKnown?.at ?? null,
+        lastServerResponseTimestamp,
+        serverPollerActive: (0, auto_yes_manager_1.isPollerActive)(compositeKey),
+        lastStopEventAt: stopEventAt,
+        structuredEvents,
+        // Issue #1785: straight from the retention layer, unparsed. See the field
+        // docs on CurrentOutputPayload for why nothing is normalised on the way out.
+        model,
+        reasoningEffort: effort,
+        // Issue #1695: appended last on purpose — every field above is a published
+        // CLI contract and reordering them churns the diff for no reader's benefit.
+        promptDedup: (0, prompt_dedup_state_1.getPromptDedupSkips)(worktreeId, cliToolId, instanceId),
+        // Issue #1839: read from `realtimeSnippet`, the same rows an operator sees
+        // in `capture --json`, so what the field claims can be checked against what
+        // is printed next to it.
+        upstreamFault: upstreamFaultMatch
+            ? {
+                id: upstreamFaultMatch.fault.id,
+                matchedText: upstreamFaultMatch.matchedText,
+                at: Date.now(),
+            }
+            : null,
+        // Issue #2095: the same three keys as `upstreamFault`, read from the same
+        // rows, so an operator comparing the two is comparing like with like. The
+        // detector's `boxRight` / `rows` stay off the wire — they are how the rule
+        // decided, not what a caller acts on, and the payload is already a published
+        // contract wide enough to be hard to change.
+        paneObstruction: paneObstruction
+            ? {
+                id: paneObstruction.id,
+                matchedText: paneObstruction.matchedText,
+                at: Date.now(),
+            }
+            : null,
+        // Issue #1879: read from `output` — the RAW capture, still carrying the SGR
+        // attributes `capture-pane -e` fetched. Everything else in this function
+        // works on stripped text; this one deliberately does not, because dim is the
+        // only thing that separates Claude's ghost suggestion from text a human
+        // typed. Do not "tidy" this to read a stripped variable.
+        composerText: composer.state === 'content' ? composer.text : null,
+        composerState: composer.state,
+    };
+}
+/**
+ * The payload itself, with no knowledge of how its (tool, instance) pair was
+ * chosen. Split from {@link buildCurrentOutput} so the resolution fields are
+ * appended in one place instead of at both of the two return sites below.
+ */
+async function buildPayload(db, worktreeId, cliToolId, instanceId) {
+    const resolvedInstanceId = instanceId ?? cliToolId;
+    const manager = manager_1.CLIToolManager.getInstance();
+    const cliTool = manager.getTool(cliToolId);
+    // Issue #2886: read once, independent of `isRunning`, so both return paths
+    // below publish the same value the pane is (or would be) reached at.
+    const sessionName = cliTool.getSessionName(worktreeId, instanceId);
+    const { stopEventAt, eventSource, askUserQuestion, structuredEvents } = readAgentEvents(worktreeId, cliToolId, instanceId, resolvedInstanceId);
     const running = await cliTool.isRunning(worktreeId, instanceId);
     if (!running) {
         // Issue #1926: the latch describes a process, and this one is gone. Dropped
         // rather than aged out so the next session on this key starts with no
         // history instead of inheriting the last one's verdict.
         (0, status_evidence_1.forgetLastKnownStatus)((0, auto_yes_manager_1.buildCompositeKey)(worktreeId, cliToolId, instanceId));
+        // Issue #3300: nothing read off a frame is published here, and that includes
+        // `autoYes` — the key is absent, not `enabled: false`. Auto-Yes can still be
+        // armed for this instance (it is kept per worktree x instance, not per
+        // session); `GET /api/worktrees/:id/auto-yes` answers for it, which is what
+        // `commandmate instances` reads and what the browser re-seeds its toggles
+        // from (#902). Publishing the key here would make the browser's poll
+        // re-seed the toggle, and raise its stop-reason toast, from a session that
+        // is not running.
         return {
             isRunning: false,
             // Issue #3179: `beginAgentSession` runs before the pane is created, so a
@@ -818,85 +651,20 @@ async function buildPayload(db, worktreeId, cliToolId, instanceId) {
     // capture layer will ever fetch — captureSessionOutput() reads at most
     // CACHE_MAX_CAPTURE_LINES regardless of the request.
     const captureWindowSaturated = (0, tmux_capture_cache_1.isCaptureWindowSaturated)(totalLines, Math.min(status_capture_config_1.STATUS_CAPTURE_LINES, tmux_capture_cache_1.CACHE_MAX_CAPTURE_LINES));
-    // Issue #1910: saturation of the capture WINDOW is only one of the two ways
-    // the cursor dies, and it is the one that never fires for the alternate-screen
-    // tools — their pane is 1000 rows (claude / copilot) or 200 (opencode), so a
-    // 10000-line window is never reached and the branch above stayed false
-    // forever. Meanwhile the poller stores `lastCapturedLine` for them too
-    // (`updateSessionState` is called unconditionally; only the DEDUP comparison
-    // is gated on the tool, response-checker.ts), so after one turn the stored
-    // value is the pane height, `slice()` starts past the last row, and `content`
-    // — the field `commandmate capture <id>` prints — was an empty string.
-    // `capturedLineCountIsCursor` states both conditions in one place.
-    const lineCountIsCursor = (0, types_2.capturedLineCountIsCursor)(cliToolId, captureWindowSaturated);
-    const newLines = lineCountIsCursor ? lines.slice(Math.max(0, lastCapturedLine)) : lines;
-    const newContent = newLines.join('\n');
-    const compositeKey = (0, auto_yes_manager_1.buildCompositeKey)(worktreeId, cliToolId, instanceId);
-    const lastServerResponseTimestamp = (0, auto_yes_manager_1.getLastServerResponseTimestamp)(compositeKey);
-    const lastOutputTimestamp = lastServerResponseTimestamp ? new Date(lastServerResponseTimestamp) : undefined;
-    const rawStatusResult = (0, status_detector_1.detectSessionStatus)(output, cliToolId, lastOutputTimestamp);
-    // Issue #3179: a launch in progress. The frame is a shell prompt and the
-    // launch line, or a dialog the launch is about to answer, and none of the
-    // flags below may be read off it: the floor verdict raised the Navigate pad,
-    // the trust dialog raised the selection list / prompt sheet. A dialog that
-    // outstays the launch's own answer releases the record (a login, an unknown
-    // dialog), and from then on this is the ordinary verdict again.
-    const startingSince = (0, session_starting_state_1.observeSessionStartingFrame)(worktreeId, cliToolId, instanceId, rawStatusResult.status === 'waiting' || rawStatusResult.hasActivePrompt);
-    const statusResult = startingSince === null
-        ? rawStatusResult
-        : (0, session_starting_state_1.startingStatusResult)(rawStatusResult);
-    // Issue #1912: every `running` reason that means "the agent is producing
-    // output", not just `thinking_indicator`. opencode answers
-    // `opencode_processing_indicator` for its `esc interrupt` footer, which is
-    // the only signal it gives between the submitted prompt and the first
-    // transcript row — on a scraper-only session that stretch showed no
-    // thinking indicator at all.
-    const thinking = (0, status_detector_1.isGeneratingStatus)(statusResult);
-    const scraperPromptWaiting = statusResult.hasActivePrompt;
-    const isSelectionListActive = statusResult.status === 'waiting' && status_detector_1.SELECTION_LIST_REASONS.has(statusResult.reason);
-    const isPagerActive = statusResult.reason === status_detector_1.STATUS_REASON.CODEX_PAGER;
-    // Issue #2369: an overlay whose ONLY exit is the dismiss — Command Code's
-    // `/usage` panel, whose last row is `Press Esc to close`.
-    //
-    // A THIRD flag rather than a member of `SELECTION_LIST_REASONS`, and the
-    // separation is the fix rather than a nicety: `isSelectionListActive` is what
-    // the arrow pad is drawn from, and this screen has no highlight to move. Nor
-    // is it `isUnclassifiedActive` any more — the detector answers `waiting` for
-    // it, and `isUnclassifiedFrame` only ever says yes to `running` — which is
-    // exactly what stops the chat surface offering the eighteen-button
-    // hatch + answer-key card to a panel that accepts one key.
-    //
-    // `status === 'waiting'` is checked as well as the reason, the same shape
-    // `isSelectionListActive` above uses, so a future producer that publishes the
-    // token with some other status cannot silently turn the card into an Esc
-    // button.
-    const isDismissablePanelActive = statusResult.status === 'waiting'
-        && statusResult.reason === status_detector_1.STATUS_REASON.COMMAND_CODE_DISMISSABLE_PANEL;
-    // Issue #1497: the detection-independent nav hatch (#1017/#1494) is gated on
-    // isUnclassifiedActive. A static, unrecognized TUI overlay (e.g. Claude `/help`)
-    // whose frame stops changing degrades from `running`/`default` to
-    // `no_recent_output` once the Auto-Yes poller has stamped lastOutputTimestamp
-    // (its sole writer, auto-yes-poller.ts). That is still an interactive-but-
-    // unclassified frame — a real idle prompt (`❯`) is classified earlier as
-    // `input_prompt`, never as `no_recent_output` — so treat the timed-out fallback
-    // as unclassified too and keep the hatch open instead of stranding the user.
-    // Issue #1924, §4 D1 decision 2: stated as evidence. Issue #1927 moved that
-    // PRODUCER into the detector, because only the detector knows which rule
-    // answered — `input_prompt` is positive for a tool whose idle rule vouched for
-    // the frame and `'none'` for one whose rule declined, with the same status and
-    // the same reason on the wire.
-    const evidence = statusResult.evidence;
-    // Issue #2011: the flag is NOT that fact, and deriving it from `evidence` is
-    // the regression this Issue fixes. `'none'` is "I could not prove this pane is
-    // idle" — an ordinary Claude composer with no completion marker above it
-    // qualifies, and 7 of 8 live idle panes did on 2026-08-24. The flag's three
-    // consumers all ask the older, narrower question instead: `TerminalEscapeHatch`
-    // opens on a frame a human has to drive by hand, `wait` suppresses its
-    // completion check and eventually exits 10 on one, and `unclassified_frames`
-    // records it as a detection failure worth capturing as a fixture. That is
-    // `isUnclassifiedFrame` — the reason vocabulary, not the strength of the
-    // evidence behind a readable verdict.
-    const isUnclassifiedActive = (0, status_evidence_1.isUnclassifiedFrame)(statusResult.status, statusResult.reason);
+    // Issue #1910: saturation of the capture WINDOW is only one of the two ways
+    // the cursor dies, and it is the one that never fires for the alternate-screen
+    // tools — their pane is 1000 rows (claude / copilot) or 200 (opencode), so a
+    // 10000-line window is never reached and the branch above stayed false
+    // forever. Meanwhile the poller stores `lastCapturedLine` for them too
+    // (`updateSessionState` is called unconditionally; only the DEDUP comparison
+    // is gated on the tool, response-checker.ts), so after one turn the stored
+    // value is the pane height, `slice()` starts past the last row, and `content`
+    // — the field `commandmate capture <id>` prints — was an empty string.
+    // `capturedLineCountIsCursor` states both conditions in one place.
+    const lineCountIsCursor = (0, types_1.capturedLineCountIsCursor)(cliToolId, captureWindowSaturated);
+    const newLines = lineCountIsCursor ? lines.slice(Math.max(0, lastCapturedLine)) : lines;
+    const newContent = newLines.join('\n');
+    const { compositeKey, lastServerResponseTimestamp, statusResult, startingSince, thinking, scraperPromptWaiting, isSelectionListActive, isPagerActive, isDismissablePanelActive, evidence, isUnclassifiedActive, } = judgeFrame(worktreeId, cliToolId, instanceId, output);
     // Issue #1723: the two-layer merge. Everything above this line is the string
     // analysis, unchanged and still the only source on a machine where no hook
     // ever fires — `getStructuredSessionState` answers null there, and
@@ -913,8 +681,18 @@ async function buildPayload(db, worktreeId, cliToolId, instanceId) {
     // the scraper's to describe. What it deliberately does NOT do is complete a
     // `commandmate wait` — see SCRAPER_COMPLETION_POLLS, and #1839's measurement
     // of a 529 storm returning Claude to exactly this frame having run nothing.
-    (0, agent_event_state_1.observeScraperCompletionEvidence)(worktreeId, cliToolId, instanceId, statusResult.status === 'ready' && evidence === 'positive');
-    const structured = (0, agent_event_state_1.getStructuredSessionState)(worktreeId, cliToolId, instanceId);
+    //
+    // Issue #3337: and, for codex, not while its hooks speak for the pane,
+    // unless the frame shows the turn was interrupted (`■ Conversation
+    // interrupted`, after which no `Stop` comes). A misread frame of a live codex
+    // turn closed it here and published `ready` mid-turn; the hook's own `Stop`
+    // is the end of the turn there, and `stale` stays the bound on a lost `Stop`.
+    // Other tools, Claude included, are closed by the screen as before.
+    // The rule is `hook-turn-hold`'s, which the relay's readiness check reads too.
+    (0, agent_event_state_1.observeScraperCompletionEvidence)(worktreeId, cliToolId, instanceId, statusResult.status === 'ready' && evidence === 'positive', undefined, (0, hook_turn_hold_1.screenMayEndTurn)(structuredEvents.source.kind, cliToolId, output));
+    // Issue #3377: on a frame that shows the hook turn was abandoned, the record's
+    // `running` is not published — the rule the list reads too.
+    const structured = (0, hook_turn_hold_1.structuredStateForFrame)(worktreeId, cliToolId, instanceId, structuredEvents.source.kind, output);
     // Issue #1725: the open-dialog half of the same merge, resolved before the
     // status merge because it decides one of its inputs. The rule itself — the
     // asymmetric release and the OR below — lives in `prompt-waiting-composition`
@@ -947,10 +725,10 @@ async function buildPayload(db, worktreeId, cliToolId, instanceId) {
     // cannot disagree about when this read is needed — and every other poll (an
     // idle pane, a turn the agent has opened, a tool that reports its own start)
     // costs exactly what it did before this Issue, which is nothing.
-    const lastPromptAt = staleReadyCandidate(scraperVerdict, structured, structuredEvents)
-        ? readNewestPromptAt(db, worktreeId, cliToolId, resolvedInstanceId)
+    const lastPromptAt = (0, structured_status_merge_1.staleReadyCandidate)(scraperVerdict, structured, structuredEvents)
+        ? (0, structured_status_merge_1.readNewestPromptAt)(db, worktreeId, cliToolId, resolvedInstanceId)
         : null;
-    const merged = mergeStructuredStatus(scraperVerdict, structured, promptWaiting, 
+    const merged = (0, structured_status_merge_1.mergeStructuredStatus)(scraperVerdict, structured, promptWaiting, 
     // Issue #2011: the same record `structuredEvents` publishes, read once. The
     // merge needs `closedBy` / `closedAt` / `openedAt`, which
     // `StructuredSessionState` folds away into `hook_stop` — and the folded form
@@ -965,133 +743,17 @@ async function buildPayload(db, worktreeId, cliToolId, instanceId) {
     // Issue #3179: not while a launch is in progress. The scraper half is already
     // neutralised above; this also drops a structured wait the launch inherited.
     const isPromptWaiting = startingSince === null && promptResolution.waiting;
-    // Issue #1726: the agent's own account of what it asked. It contributes only
-    // where some other layer has already established that a dialog is on screen —
-    // this record decides no status of its own, because Claude emits nothing at
-    // all while an AskUserQuestion picker is up (§5.6) and a record that asserted
-    // `waiting` from the invocation would go on asserting it long after a human
-    // answered in the terminal.
-    // Issue #2040 moved the read to the top of this function (the decision entries
-    // publish the same episode's choices) and this line now re-uses it, so the two
-    // surfaces cannot describe different instants.
-    const scraperPromptData = statusResult.promptDetection.promptData;
-    const correctedPromptData = scraperPromptData && askUserQuestion
-        ? (0, ask_user_question_prompt_1.applyAskUserQuestion)(scraperPromptData, askUserQuestion.spec)
-        : null;
-    // The degraded form, for a dialog only the structured layer can see. Enriched
-    // with the question text when one is in flight — that turns "a dialog is open
-    // and nobody could read it" into "a dialog is open and here is what it asks".
-    //
-    // Issue #1898 adds the replies the dialog accepts, for the sources that can be
-    // answered without touching the pane. The gate is `eventIdentity`: a source
-    // that publishes a per-decision id is a source whose approval can be answered
-    // by that id, which is what makes an option NUMBER here mean something other
-    // than a line on a screen nobody parsed. `source === 'notification'` narrows
-    // it to a dialog the agent actually reported — a `permission-request` record
-    // is a prediction, and a question is answered with a choice rather than with
-    // one of these three verdicts.
-    //
-    // Issue #2031 adds the fourth conjunct and folds the whole gate into ONE
-    // value. The three verdicts and the id they are delivered to are now derived
-    // from the same expression, so they cannot be published apart — and "apart"
-    // is not hypothetical, it is the state #1932 shipped: options were published
-    // on the capability alone while `decisionId` was published nowhere at all, so
-    // the panel drew no buttons and the only way out of an opencode approval in a
-    // browser was the arrow-key safety net. Options WITHOUT an id is the worse
-    // half of that pair — the numbers would reach the keystroke path, where a
-    // bare "1" selects whatever the picker happens to be highlighting (#1681).
-    const addressableDecisionId = promptWaiting !== null &&
-        promptWaiting.source === 'notification' &&
-        eventSource.capabilities.eventIdentity === 'permission-id' &&
-        (0, structured_prompt_1.isAddressableDecision)(promptWaiting.decisionId)
-        ? promptWaiting.decisionId
-        : null;
-    // Issue #2100 splits the two halves of #2031's single expression, because an
-    // addressable decision is now of two KINDS. The id is published for both — it
-    // is what `POST /respond` names, and a question needs it exactly as much as an
-    // approval does — but the three verdicts belong to an approval alone.
-    //
-    // Publishing both for a question is not a cosmetic error: it is precisely what
-    // #2039's third gate refuses. `readPromptQuestionChoices` returns null the
-    // moment `decisionOptions` is non-empty, so a question carrying them would
-    // draw `Allow once / Allow always / Reject` over the agent's own choices, and
-    // a verdict sent to a question is refused at the source
-    // (`question-needs-answer-verdict`). The kind is recovered from the record the
-    // same way `structuredEvents.pendingDecisions[].kind` is, through the one
-    // reader in `pending-decision-kind`.
-    const addressesQuestion = promptWaiting !== null && (0, pending_decision_kind_1.pendingDecisionKind)(promptWaiting.toolName) === 'question';
-    const decisionOptions = addressableDecisionId !== null && !addressesQuestion
-        ? // Issue #2951: in the tool's own words (OpenCode V2: `Always allow`).
-            (0, structured_prompt_1.structuredDecisionOptionsFor)(cliToolId)
-        : null;
-    const structuredFacts = promptWaiting === null
-        ? null
-        : {
-            ...promptWaiting,
-            askUserQuestion: summarizeAskUserQuestion(askUserQuestion),
-            decisionOptions,
-            // Explicit, though the spread above already carries a `decisionId`
-            // off the record: the spread's copy is the raw one, and what may be
-            // published is the GATED one. Letting the record's value through
-            // would put an id on a payload whose verdicts were withheld, which is
-            // the biconditional this Issue exists to hold.
-            decisionId: addressableDecisionId,
-            // Gated on the same value, for a reason of its own: `patterns` is
-            // what the `Allow always` BUTTON grants, so publishing it where no
-            // button is drawn adds a rule list to a panel that is telling the
-            // user to go and answer in the terminal. Every source but opencode
-            // therefore keeps the exact payload it had before this Issue, plus
-            // the one `decisionId: null`.
-            //
-            // Issue #2100 moves the gate onto `decisionOptions` rather than the
-            // id, which is the same value for every approval and the honest one
-            // for a question: a question draws no `Allow always`, so it may not
-            // carry the rules one would have saved. (`reportQuestionPending`
-            // records `patterns: null` anyway; the two agree by construction now
-            // instead of by coincidence.)
-            patterns: decisionOptions !== null ? promptWaiting.patterns : null,
-        };
-    const promptData = startingSince !== null
-        ? null
-        : scraperPromptWaiting
-            ? correctedPromptData ??
-                scraperPromptData ??
-                (structuredFacts ? (0, structured_prompt_1.buildStructuredPromptData)(worktreeId, structuredFacts) : null)
-            : structuredFacts
-                ? (0, structured_prompt_1.buildStructuredPromptData)(worktreeId, structuredFacts)
-                : null;
-    // Issue #2870: whether `/prompt-response` would answer the prompt published
-    // above, read by the SAME function it re-verifies with. In #2868 `promptData`
-    // came off the generic parser alone, the route refused it, and the UI's Send
-    // did nothing. Only for a parser-read prompt: the structured form (hook
-    // `decisionId`, degraded) is answered by id or not by number at all, so the
-    // key is left out there, as it is when no prompt is up. `isPromptWaiting` /
-    // `promptData` / `sessionStatus` are untouched — `wait`'s exit 10, Auto-Yes
-    // and push notifications keep reading exactly what they read before.
-    const promptAnswerable = scraperPromptWaiting && (correctedPromptData ?? scraperPromptData)
-        ? (0, auto_yes_dialog_gate_1.assessPromptAnswerability)(cliToolId, output).refusal === null
-        : undefined;
-    // Issue #1723 §3: the field data this Epic is being built on. Every line is
-    // one poll where the screen and the agent disagreed about what the agent was
-    // doing, which is the only way to answer "how wrong was the scraper?" with a
-    // number instead of an anecdote. Emitted only on disagreement — a session
-    // where the two layers agree is silent — and including the disagreements this
-    // merge deliberately does NOT act on (`applied: false`), because those are
-    // exactly the cases the next Issues in the Epic have to decide about.
-    if (structured !== null && structured.status !== statusResult.status) {
-        logger.info('detection-divergence', {
-            worktreeId,
-            cliToolId,
-            instanceId: resolvedInstanceId,
-            scraperStatus: statusResult.status,
-            scraperReason: statusResult.reason,
-            structuredStatus: structured.status,
-            structuredReason: structured.reason,
-            structuredEvent: structured.event,
-            structuredEventAt: structured.at,
-            applied: merged.structuredApplied,
-        });
-    }
+    const { structuredFacts, promptData, promptAnswerable } = composePromptData({
+        worktreeId,
+        cliToolId,
+        output,
+        statusResult,
+        startingSince,
+        promptWaiting,
+        askUserQuestion,
+        eventSource,
+    });
+    logDetectionDivergence(worktreeId, cliToolId, resolvedInstanceId, statusResult, structured, merged);
     // Issue #1839 defined this window and Issue #2095 reuses it, so it is computed
     // once, here, above the first reader. The 100 rows are also what the payload
     // publishes, which is the property both fields rest on: what they claim can be
@@ -1135,7 +797,7 @@ async function buildPayload(db, worktreeId, cliToolId, instanceId) {
     // the shell and the launch line — so no row, and the run starts afresh after.
     const unclassifiedVerdict = (0, unclassified_frame_tracker_1.observeUnclassifiedFrame)(compositeKey, merged.isUnclassifiedActive && !answerableOverAgentApi && startingSince === null);
     if (unclassifiedVerdict.shouldRecord) {
-        recordUnclassifiedFrame(db, {
+        (0, current_output_history_writers_1.recordUnclassifiedFrame)(db, {
             worktreeId,
             cliToolId,
             instanceId: resolvedInstanceId,
@@ -1184,7 +846,7 @@ async function buildPayload(db, worktreeId, cliToolId, instanceId) {
         !promptWaiting.recorded &&
         !answerableOverAgentApi) {
         (0, agent_event_state_1.markStructuredPromptRecorded)(worktreeId, cliToolId, instanceId);
-        recordStructuredPrompt(db, {
+        (0, current_output_history_writers_1.recordStructuredPrompt)(db, {
             worktreeId,
             cliToolId,
             instanceId: resolvedInstanceId,
@@ -1230,350 +892,39 @@ async function buildPayload(db, worktreeId, cliToolId, instanceId) {
         evidence: published.evidence,
     });
     const lastKnown = (0, status_evidence_1.getLastKnownStatus)(compositeKey);
-    return {
-        isRunning: true,
-        sessionName,
+    return buildRunningPayload({
+        worktreeId,
         cliToolId,
-        sessionStatus: published.status,
-        sessionStatusReason: published.reason,
-        content: newContent,
-        fullOutput: output,
+        instanceId,
+        sessionName,
+        published,
+        merged,
+        newContent,
+        output,
         realtimeSnippet,
-        lineCount: totalLines,
+        totalLines,
         lastCapturedLine,
-        isComplete: isPromptWaiting,
-        isGenerating: published.thinking,
-        thinking: published.thinking,
-        // Issue #2607: named after the tool actually running. A fixed "Claude" was
-        // published for every agent, and `capture --json` readers took it at its word.
-        thinkingMessage: published.thinking ? `${(0, types_2.getCliToolDisplayName)(cliToolId)} is thinking...` : null,
         isPromptWaiting,
         promptData,
-        ...(promptAnswerable !== undefined ? { promptAnswerable } : {}),
-        autoYes: {
-            enabled: autoYesState?.enabled ?? false,
-            expiresAt: autoYesState?.enabled ? autoYesState.expiresAt : null,
-            stopReason: autoYesState?.stopReason,
-            lastSuppression: (0, auto_yes_suppression_state_1.getLastPolicySuppression)(worktreeId, cliToolId, instanceId),
-            // Issue #1694: undefined (so the key is absent from the JSON) unless a
-            // stop pattern actually fired — the state clears it on every other path.
-            stopMatchedText: autoYesState?.stopMatchedText,
-        },
+        promptAnswerable,
+        autoYesState,
+        // Issue #3397: judged against the screen-read prompt only — the one
+        // `promptAnswerable` is published for, and the one the poller sent its
+        // Enter to. A structured (hook / degraded) prompt is never that screen.
+        lastEnterFallback: (0, auto_yes_enter_fallback_1.publishEnterFallback)((0, auto_yes_enter_fallback_1.getLastEnterFallback)(worktreeId, cliToolId, instanceId), promptAnswerable !== undefined ? statusResult.promptDetection.promptData : null),
         isSelectionListActive,
         isPagerActive,
         isDismissablePanelActive,
-        isUnclassifiedActive: startingSince === null && merged.isUnclassifiedActive,
         startingSince,
-        // Issue #1926: the same fact `isUnclassifiedActive` carries, named the way
-        // §4 D1 names it. Published from the merged verdict so the two cannot
-        // disagree on the wire.
-        statusEvidence: published.evidence,
-        lastKnownStatus: lastKnown?.status ?? null,
-        lastKnownStatusAt: lastKnown?.at ?? null,
+        lastKnown,
         lastServerResponseTimestamp,
-        serverPollerActive: (0, auto_yes_manager_1.isPollerActive)(compositeKey),
-        lastStopEventAt: stopEventAt,
+        compositeKey,
+        stopEventAt,
         structuredEvents,
-        // Issue #1785: straight from the retention layer, unparsed. See the field
-        // docs on CurrentOutputPayload for why nothing is normalised on the way out.
         model,
-        reasoningEffort: effort,
-        // Issue #1695: appended last on purpose — every field above is a published
-        // CLI contract and reordering them churns the diff for no reader's benefit.
-        promptDedup: (0, prompt_dedup_state_1.getPromptDedupSkips)(worktreeId, cliToolId, instanceId),
-        // Issue #1839: read from `realtimeSnippet`, the same rows an operator sees
-        // in `capture --json`, so what the field claims can be checked against what
-        // is printed next to it.
-        upstreamFault: upstreamFaultMatch
-            ? {
-                id: upstreamFaultMatch.fault.id,
-                matchedText: upstreamFaultMatch.matchedText,
-                at: Date.now(),
-            }
-            : null,
-        // Issue #2095: the same three keys as `upstreamFault`, read from the same
-        // rows, so an operator comparing the two is comparing like with like. The
-        // detector's `boxRight` / `rows` stay off the wire — they are how the rule
-        // decided, not what a caller acts on, and the payload is already a published
-        // contract wide enough to be hard to change.
-        paneObstruction: paneObstruction
-            ? {
-                id: paneObstruction.id,
-                matchedText: paneObstruction.matchedText,
-                at: Date.now(),
-            }
-            : null,
-        // Issue #1879: read from `output` — the RAW capture, still carrying the SGR
-        // attributes `capture-pane -e` fetched. Everything else in this function
-        // works on stripped text; this one deliberately does not, because dim is the
-        // only thing that separates Claude's ghost suggestion from text a human
-        // typed. Do not "tidy" this to read a stripped variable.
-        composerText: composer.state === 'content' ? composer.text : null,
-        composerState: composer.state,
-    };
-}
-function newChatTurnProgressState() {
-    return {
-        version: 0,
-        askedAt: Number.NEGATIVE_INFINITY,
-        turnKey: null,
-        body: null,
-        loggedOutcome: null,
-        loggedTurnKey: null,
-    };
-}
-/**
- * On `globalThis` for the reason every shared map in this subsystem is (#1736):
- * under `next dev` the poller's bundle and the opencode subscription's bundle
- * would each get a private copy, and two producers throttling against two
- * different maps is no throttle at all.
- */
-const chatTurnProgressState = (globalThis.__chatTurnProgressState ??= new Map());
-function chatTurnProgressKey(target) {
-    return `${target.worktreeId}:${target.cliToolId}:${target.instanceId ?? target.cliToolId}`;
-}
-/** Forget every instance's progress bookkeeping. Test seam. */
-function resetChatTurnProgressState() {
-    chatTurnProgressState.clear();
-}
-/**
- * Say once, at info, what happened to this instance's progress frames (Issue #2248).
- *
- * ## Why info, and why this file had none
- *
- * Every outcome here was `logger.debug`, including the two that mean the reader
- * is watching a blank space: a push that threw, and a room with no subscribers.
- * Issue #2248 was opened after a live session where the body reached the browser
- * — or did not — and the server logs could not answer which, because debug is
- * off in the builds people run. An unobservable push is a feature that can only
- * be debugged by reproducing it.
- *
- * ## Why once
- *
- * The publisher runs on EVERY poll tick of a generating session. Logging each
- * tick at info would put a line per second per agent into the operator's log and
- * make the level useless, so this collapses a run of identical ticks into its
- * first: the outcome and the turn it happened on are the identity, and a repeat
- * of the pair says nothing the first line did not.
- *
- * The consequences of that identity, both deliberate:
- *
- *  - **a new turn always logs**, because `turnKey` is part of the pair. That is
- *    the acceptance criterion — one info line per turn — and the reason
- *    `loggedTurnKey` exists at all rather than a bare boolean;
- *  - **a CHANGE of outcome always logs**, so "the subscriber left" and "it
- *    started failing" are both visible the tick they happen, without the
- *    steady state that follows repeating them.
- *
- * `no-subscribers` and `failed` carry no turn key — neither knows one; the first
- * returns before the source is asked and the second is why there is no frame —
- * so for them the pair is `(outcome, null)` and the run collapses to one line
- * until something else happens.
- */
-function logChatTurnProgressOutcome(target, outcome, turnKey, extra = {}) {
-    const key = chatTurnProgressKey(target);
-    const state = chatTurnProgressState.get(key) ?? newChatTurnProgressState();
-    chatTurnProgressState.set(key, state);
-    if (state.loggedOutcome === outcome && state.loggedTurnKey === turnKey)
-        return;
-    state.loggedOutcome = outcome;
-    state.loggedTurnKey = turnKey;
-    // Written out rather than interpolated: these strings are what an operator
-    // greps the log for, and an interpolated name cannot be found in the source.
-    const message = outcome === 'published'
-        ? 'chat-turn-progress-published'
-        : outcome === 'no-subscribers'
-            ? 'chat-turn-progress-no-subscribers'
-            : 'chat-turn-progress-failed';
-    logger.info(message, {
-        worktreeId: target.worktreeId,
-        cliToolId: target.cliToolId,
-        instanceId: target.instanceId ?? target.cliToolId,
-        turnKey,
-        ...extra,
+        effort,
+        upstreamFaultMatch,
+        paneObstruction,
+        composer,
     });
 }
-/**
- * Decide whether this instance has a new progress frame, and build it.
- *
- * The single generator both tools go through, on the same argument
- * {@link buildCurrentOutput} makes for the terminal payload: two producers of one
- * wire shape drift, and the drift is invisible because each of them is
- * individually correct. Three rules, in this order, and each of them is a way
- * this feature goes wrong if it is missing:
- *
- *  1. **Throttle.** At most one *ask* per {@link CHAT_TURN_PROGRESS_MIN_INTERVAL_MS}
- *     per instance. It gates the ask rather than the send because the source is
- *     the expensive half (see {@link ChatTurnProgressSource}); a gate on the send
- *     alone would re-read a 4 MiB transcript to discover it had not changed.
- *  2. **No-change suppression.** Same turn, same body → no frame. A reply that
- *     has stopped growing must not keep waking every subscribed browser.
- *  3. **Monotonic version**, per instance and NOT per turn. A client drops
- *     anything at or below what it has already rendered, and restarting the
- *     counter on a new turn would make the first frame of turn N+1 look stale
- *     against the last frame of turn N.
- *
- * The body is bounded by {@link truncateChatTurnProgressBody}, whose cut is
- * folded into `partial` together with the reader's own — see
- * {@link ChatTurnProgressEvent.partial} for why one flag answers both.
- *
- * Never throws: a source that throws is a turn with nothing to show, not a
- * broken poll tick.
- *
- * @param target - The instance
- * @param source - Asked only when the throttle allows it
- * @param now - Epoch ms; injected by the tests
- * @returns The frame to broadcast, or null when there is nothing new to say
- */
-async function buildChatTurnProgress(target, source, now = Date.now()) {
-    const key = chatTurnProgressKey(target);
-    const state = chatTurnProgressState.get(key) ?? newChatTurnProgressState();
-    if (now - state.askedAt < types_1.CHAT_TURN_PROGRESS_MIN_INTERVAL_MS)
-        return null;
-    state.askedAt = now;
-    chatTurnProgressState.set(key, state);
-    let draft;
-    try {
-        draft = await source();
-    }
-    catch {
-        // The readers already promise never to throw; this is the belt for the
-        // dynamic import that reaches them.
-        return null;
-    }
-    if (!draft || draft.body.length === 0)
-        return null;
-    const bounded = (0, types_1.truncateChatTurnProgressBody)(draft.body);
-    if (draft.turnKey === state.turnKey && bounded.body === state.body)
-        return null;
-    state.turnKey = draft.turnKey;
-    state.body = bounded.body;
-    state.version += 1;
-    return {
-        type: types_1.CHAT_TURN_PROGRESS_EVENT_TYPE,
-        worktreeId: target.worktreeId,
-        cliToolId: target.cliToolId,
-        instanceId: target.instanceId ?? target.cliToolId,
-        turnKey: draft.turnKey,
-        body: bounded.body,
-        partial: bounded.truncated || draft.partial === true,
-        version: state.version,
-        done: false,
-    };
-}
-/**
- * Build a progress frame and push it to the worktree room.
- *
- * Subscribers are checked FIRST, before the throttle state is touched and long
- * before the source is asked, so a session nobody is watching costs one map
- * lookup per tick — the same bargain `broadcastTerminalSnapshot` strikes, and
- * the reason a 4 MiB transcript read does not happen for every claude session on
- * the machine.
- *
- * The `ws-server` import is dynamic so this module's *other* callers — the
- * `/current-output` route and `commandmate capture` — do not pull the WebSocket
- * server into their graph just by building a payload.
- *
- * Never throws; a failed push is a moment of staleness on a surface that has the
- * settled row coming anyway.
- *
- * @returns Whether a frame was broadcast
- */
-async function emitChatTurnProgress(target, source, now = Date.now()) {
-    try {
-        const { broadcast, hasRoomSubscribers } = await Promise.resolve().then(() => __importStar(require('../../lib/ws-server')));
-        if (!hasRoomSubscribers(target.worktreeId)) {
-            // Issue #2248. Reported, not silent: "the body never reached the browser"
-            // and "nobody was listening" look identical from a screenshot, and this is
-            // the only place that can tell them apart.
-            logChatTurnProgressOutcome(target, 'no-subscribers', null);
-            return false;
-        }
-        const event = await buildChatTurnProgress(target, source, now);
-        // Not logged: null is the throttle, an unchanged body, or a turn with no
-        // text yet — the quiet, correct majority of ticks.
-        if (!event)
-            return false;
-        broadcast(target.worktreeId, event);
-        logChatTurnProgressOutcome(target, 'published', event.turnKey, {
-            version: event.version,
-            bodyLength: event.body.length,
-            partial: event.partial,
-        });
-        return true;
-    }
-    catch (error) {
-        logChatTurnProgressOutcome(target, 'failed', null, {
-            error: error instanceof Error ? error.message : String(error),
-        });
-        return false;
-    }
-}
-/**
- * Ask the tool that has a transcript for the body of its open turn (Issue #2199).
- *
- * claude only, and that is a statement about which tools have a *pull* reader
- * rather than a list to extend by hand. opencode's body arrives on its own SSE
- * stream and is published from `sources/opencode/history` at the moment a part
- * lands — polling for it here would be a second producer of the same frames.
- * codex and antigravity have neither, and stay on the indicator (#2197 / #2198).
- *
- * The reader is imported dynamically so `sources/claude/history` — and through
- * it `fs/promises`, the session-pointer latch and `user-turn-recorder` — stays
- * out of the module graph of the `/current-output` route and of `commandmate
- * capture`, both of which reach this file for a payload and nothing else.
- *
- * ## Which half the caller waits for (Issue #2248)
- *
- * The caller awaits the CHEAP half — the worktree row and "is anybody watching"
- * — and not the expensive one. That split is what `void` was protecting in the
- * first place: the 4 MiB transcript read, the JSONL parse, the render and the
- * broadcast still run detached, so no poll tick and no WebSocket snapshot waits
- * on them.
- *
- * What awaiting the prelude buys is the reason this Issue exists: the line that
- * says whether anybody received the frame is written while the tick it belongs
- * to is still the tick in progress. Left inside the detached half it landed
- * wherever the event loop happened to get to it, next to some unrelated
- * request's output, which is not a log an operator can read backwards.
- *
- * Never throws: `emitChatTurnProgress` swallows, and so does this.
- */
-async function publishChatTurnProgress(db, worktreeId, cliToolId, instanceId) {
-    if (cliToolId !== 'claude')
-        return;
-    const target = { worktreeId, cliToolId, instanceId };
-    try {
-        // The slug the transcript directory is named after is a function of the
-        // worktree's path, so the row is what makes the file findable at all. Read
-        // before the throttle only because it is a single indexed lookup against a
-        // connection this function was handed; everything expensive is behind the
-        // gate.
-        const { getWorktreeById } = await Promise.resolve().then(() => __importStar(require('../../lib/db/worktree-db')));
-        const worktreePath = getWorktreeById(db, worktreeId)?.path;
-        if (!worktreePath)
-            return;
-        // Issue #2248. Hoisted out of `emitChatTurnProgress` — which still makes the
-        // same check for its other caller — so the answer, and the line that reports
-        // it, are settled before this function returns. Costs one Map lookup on the
-        // sessions nobody is watching, which is the bargain that was already being
-        // struck one frame later.
-        const { hasRoomSubscribers } = await Promise.resolve().then(() => __importStar(require('../../lib/ws-server')));
-        if (!hasRoomSubscribers(worktreeId)) {
-            logChatTurnProgressOutcome(target, 'no-subscribers', null);
-            return;
-        }
-        // Detached on purpose: everything past this point is the transcript read.
-        void emitChatTurnProgress(target, async () => {
-            const { readClaudeTurnProgress } = await Promise.resolve().then(() => __importStar(require('../../lib/hooks/sources/claude/history')));
-            return readClaudeTurnProgress({ worktreeId, cliToolId, instanceId: instanceId ?? cliToolId }, { worktreePath });
-        });
-    }
-    catch (error) {
-        // Issue #2248: the reader's half of the same failure — the worktree row or
-        // one of the dynamic imports — on the same once-per-run gate as the push's.
-        logChatTurnProgressOutcome(target, 'failed', null, {
-            error: error instanceof Error ? error.message : String(error),
-        });
-    }
-}