commandmate 0.31.2 → 0.32.0

package/dist/server/src/lib/auto-yes-poller.js

@@ -59,7 +59,7 @@ exports.getAutoYesPollerCompositeKeys = getAutoYesPollerCompositeKeys;
 exports.stopAutoYesPollingByWorktree = stopAutoYesPollingByWorktree;
 exports.isAnyPollerActiveForWorktree = isAnyPollerActiveForWorktree;
 const cli_session_1 = require("./session/cli-session");
-const prompt_detector_1 = require("./detection/prompt-detector");
+const response_checker_1 = require("./polling/response-checker");
 const auto_yes_resolver_1 = require("./polling/auto-yes-resolver");
 const auto_yes_policy_1 = require("./polling/auto-yes-policy");
 const auto_yes_suppression_state_1 = require("./polling/auto-yes-suppression-state");
@@ -281,12 +281,27 @@ function processStopConditionDelta(compositeKey, pollerState, cleanOutput) {
 async function detectAndRespondToPrompt(worktreeId, pollerState, cliToolId, cleanOutput, precomputedLines, instanceId) {
     const compositeKey = (0, auto_yes_state_1.buildCompositeKey)(worktreeId, cliToolId, instanceId);
     try {
-        // 1. Detect prompt
-        const promptOptions = (0, cli_patterns_1.buildDetectPromptOptions)(cliToolId);
-        const promptDetection = (0, prompt_detector_1.detectPrompt)(cleanOutput, {
-            ...promptOptions,
-            ...(precomputedLines && { precomputedLines }),
-        });
+        // 1. Detect prompt.
+        //
+        // Issue #2368: through `detectPromptOnCleanFrame`, the entry the status
+        // path and the response poller already read frames on — NOT the generic
+        // `detectPrompt` this used to call. #2364 gave agy its own dialog reader and
+        // wired it into three of the four consumers of one frame; this poller was
+        // the fourth, and it stayed on the generic multiple-choice parser. That
+        // parser folds a wrapped option label only when the continuation row is
+        // indented, short or path-shaped (#372, for codex prose), and agy prints the
+        // approved command INSIDE the label and wraps it at column 0 — so every
+        // Bash approval read as `isPrompt: false` here and Auto-Yes answered
+        // nothing, while `/current-output` published the same screen as a waiting
+        // four-option prompt. Everything after this point is unchanged: the
+        // duplicate key (#306), codex's launch dialogs (#1829), the dialog gate
+        // (#1928) and the contract policy (#1547) all still run. What changed is
+        // only whether the frame can be READ.
+        //
+        // `cleanOutput` is handed over already stripped, and the clean-frame entry
+        // is the one that does not strip again (`stripBoxDrawing` is not
+        // idempotent), so this poller and the response poller judge identical text.
+        const promptDetection = (0, response_checker_1.detectPromptOnCleanFrame)(cleanOutput, cliToolId, precomputedLines);
         if (!promptDetection.isPrompt || !promptDetection.promptData) {
             pollerState.lastAnsweredPromptKey = null;
             pollerState.lastAnsweredAt = null;
@@ -312,7 +327,7 @@ async function detectAndRespondToPrompt(worktreeId, pollerState, cliToolId, clea
         // '2', '1' — each without a trailing Enter), but only during startSession,
         // while this poller runs on its own 2s phase for the life of the session.
         // Whichever sees the dialog first decides, so the fix is to leave them all
-        // to the tool. Auto-answer layer only: detectPrompt above still reports the
+        // to the tool. Auto-answer layer only: the detection above still reports the
         // prompt, so the human keeps seeing the screen and the response poller
         // still notifies them about it.
         const launchDialog = cliToolId === 'codex' ? (0, cli_patterns_1.getCodexLifecycleDialog)(cleanOutput) : null;
@@ -334,7 +349,7 @@ async function detectAndRespondToPrompt(worktreeId, pollerState, cliToolId, clea
             return 'no_answer';
         }
         // 3.5. Issue #1928 (§4 D1 decision 4): the generic numbered-list inference is
-        // not enough to send an answer. `detectPrompt` above judges the ROWS, and the
+        // not enough to send an answer. The detection above judges the ROWS, and the
         // rows of an agent's own reply can be indistinguishable from a dialog's --
         // opencode 1.18 answering "list three options and ask which one" is the
         // reported case (#1896), and the `1` this poller sent in reply was not
@@ -369,8 +384,8 @@ async function detectAndRespondToPrompt(worktreeId, pollerState, cliToolId, clea
             return 'no_answer';
         }
         // 4. Resolve auto answer under the execution contract's policy (Issue #1547).
-        // Auto-Yes calls detectPrompt directly instead of going through
-        // status-detector, so this is the only place the policy can gate an
+        // Auto-Yes reads the frame itself instead of going through status-detector
+        // (it shares the reader, not the verdict), so this is the only place the policy can gate an
         // auto-answer: a prompt the policy withholds is left for a human, and the
         // response poller's prompt path (WS broadcast + Web Push, see
         // polling/response-checker.ts) is what tells them it is waiting.

package/dist/server/src/lib/db/chat-db.js

@@ -6,7 +6,7 @@
  * Issue #479: Extracted from db.ts for single-responsibility separation
  */
 Object.defineProperty(exports, "__esModule", { value: true });
-exports.UNKEYED_USER_MESSAGE_LIMIT = exports.ACTIVE_FILTER = void 0;
+exports.RELAY_SYSTEM_REQUEST_ID_PREFIX = exports.RELAY_REQUEST_ID_PREFIX = exports.MODEL_CHANGE_REQUEST_ID_PREFIX = exports.USER_TURN_CANDIDATE_LIMIT = exports.ACTIVE_FILTER = void 0;
 exports.getLastAssistantMessageAt = getLastAssistantMessageAt;
 exports.createMessage = createMessage;
 exports.updateMessageContent = updateMessageContent;
@@ -28,6 +28,12 @@ exports.getMessageById = getMessageById;
 exports.updatePromptData = updatePromptData;
 exports.markPendingPromptsAsAnswered = markPendingPromptsAsAnswered;
 exports.recordAnsweredPrompt = recordAnsweredPrompt;
+exports.createModelChangeMessage = createModelChangeMessage;
+exports.relayRequestId = relayRequestId;
+exports.parseRelayRequestId = parseRelayRequestId;
+exports.getLastUserMessageForInstance = getLastUserMessageForInstance;
+exports.getLatestOpenPromptMessage = getLatestOpenPromptMessage;
+exports.createRelaySystemMessage = createRelaySystemMessage;
 const crypto_1 = require("crypto");
 const logger_1 = require("../../lib/logger");
 const logger = (0, logger_1.createLogger)('chat-db');
@@ -244,16 +250,17 @@ function findMessageByRequestId(db, worktreeId, requestId) {
     return row ? mapChatMessage(row) : null;
 }
 /**
- * How many candidate rows {@link findUnkeyedUserMessages} returns.
+ * How many candidate rows a user-row candidate lookup returns.
  *
  * The caller compares content in JavaScript, so this bounds the work rather than
  * the correctness. Twenty is far above the number of user rows one instance can
  * accumulate inside the caller's few-minute window and still small enough that
  * the query is never the expensive part of a poll.
  */
-exports.UNKEYED_USER_MESSAGE_LIMIT = 20;
+exports.USER_TURN_CANDIDATE_LIMIT = 20;
 /**
- * User rows for one instance that no producer has claimed yet (Issue #2196).
+ * User rows for one instance that no producer has claimed yet (Issue #2196) —
+ * and, on request, the one keyed row that is a duplicate of one (Issue #2392).
  *
  * The lookup behind "the operator's input is already in History — `/send` put it
  * there". A row qualifies when it is this instance's, is a `user` row, sits in
@@ -277,15 +284,40 @@ exports.UNKEYED_USER_MESSAGE_LIMIT = 20;
  * `ACTIVE_FILTER` applies: an archived row has been cleared out of History, and
  * adopting one would key a turn to a row nobody can see.
  *
+ * ## The one keyed row this will hand back, and only when asked
+ *
+ * Issue #2392. `relay-delivery` writes the answer it types into the requesting
+ * session's composer as a `relay` user row keyed `relay:<ledgerId>`, and that
+ * session's own transcript reader then reads the delivered body back as a prompt
+ * it was handed — 662ms later, measured — and duplicated it, because the row it
+ * should have recognised was keyed and therefore invisible here.
+ *
+ * `includeRelayDelivered` widens the predicate to `request_id IS NULL OR (a
+ * relay row keyed `relay:…`)`. It is an OR and an opt-in, so no existing caller
+ * sees a row it did not see before; `message_type` and the key prefix are both
+ * required, because a relay *prompt* delivery is a `relay` row with no key at
+ * all and stays an ordinary unkeyed candidate, while a `relay-sys:` row is
+ * transcript furniture that is not the delivery.
+ *
+ * **A row that comes back with a `requestId` must not be claimed.** That key is
+ * how `relay-service`'s `findParentRelayHops` reads the ledger back out of the
+ * row (#2387), so re-pointing one at a transcript key would silently un-chain
+ * every relay opened from the session. {@link setMessageRequestId}'s
+ * `request_id IS NULL` predicate refuses the write in any case; the caller is
+ * expected to branch on `requestId` rather than rely on that.
+ *
  * @returns Candidate rows, newest first
  */
 function findUnkeyedUserMessages(db, query) {
+    const keyFilter = query.includeRelayDelivered
+        ? `AND (request_id IS NULL OR (message_type = 'relay' AND request_id LIKE ?))`
+        : 'AND request_id IS NULL';
     const stmt = db.prepare(`
     SELECT id, worktree_id, role, content, summary, timestamp, log_file_name, request_id, message_type, prompt_data, cli_tool_id, instance_id, archived
     FROM chat_messages
     WHERE worktree_id = ?
       AND role = 'user'
-      AND request_id IS NULL
+      ${keyFilter}
       AND COALESCE(cli_tool_id, 'claude') = ?
       AND COALESCE(instance_id, cli_tool_id, 'claude') = ?
       AND timestamp >= ? AND timestamp <= ?
@@ -293,8 +325,14 @@ function findUnkeyedUserMessages(db, query) {
     ORDER BY timestamp DESC
     LIMIT ?
   `);
-    const rows = stmt.all(query.worktreeId, query.cliToolId, query.instanceId, query.fromMs, query.toMs, query.limit ?? exports.UNKEYED_USER_MESSAGE_LIMIT);
-    return rows.map(mapChatMessage);
+    const rows = stmt.all(query.worktreeId, ...(query.includeRelayDelivered ? [`${exports.RELAY_REQUEST_ID_PREFIX}%`] : []), query.cliToolId, query.instanceId, query.fromMs, query.toMs, query.limit ?? exports.USER_TURN_CANDIDATE_LIMIT);
+    // A bare `relay:` names no ledger entry and so is not a delivery — the rule
+    // `parseRelayRequestId` already states for the loop guard, applied here so the
+    // two readers cannot disagree about what counts as one. A no-op without the
+    // option, where nothing that comes back is keyed at all.
+    return rows
+        .map(mapChatMessage)
+        .filter((message) => !message.requestId || parseRelayRequestId(message.requestId) !== null);
 }
 /**
  * Claim an unkeyed row for a producer, without touching anything else on it
@@ -654,3 +692,162 @@ function recordAnsweredPrompt(db, params) {
     });
     return { message, created: true };
 }
+// ============================================================================
+// Model change rows (Issue #2357)
+// ============================================================================
+/**
+ * The `request_id` prefix a model-change row carries (Issue #2357).
+ *
+ * `chat_messages` has no `system` role — `role` is `user | assistant` and every
+ * reader of the column branches on exactly those two — so the sentence "the
+ * model changed" is stored as an assistant row and *identified* by its request
+ * id instead: `model-changed:<epoch ms>`. A reader that wants to style these
+ * rows differently, or a `capture --prompts`-style audit that wants to list
+ * them, matches on this prefix rather than on the wording, which is localized
+ * at write time and would otherwise have to be matched in every language.
+ */
+exports.MODEL_CHANGE_REQUEST_ID_PREFIX = 'model-changed:';
+/**
+ * Persist "the model changed" into the instance's history (Issue #2357).
+ *
+ * One row per transition, written by the model edge's subscriber and nothing
+ * else — the chat transcript and the History tab both read this table, so one
+ * write reaches both, and the same row is what the `message` frame pushes to a
+ * transcript that is open at the time.
+ *
+ * An assistant row, on purpose: the transcript groups an assistant row that
+ * follows no user row as a standalone reply, which is the closest the schema
+ * comes to a system line without a migration. The row is a `normal` message
+ * (not a `prompt`), so nothing that scans for open dialogs will mistake it for
+ * one, and the request id (see {@link MODEL_CHANGE_REQUEST_ID_PREFIX}) is what
+ * marks it.
+ */
+function createModelChangeMessage(db, params) {
+    return createMessage(db, {
+        worktreeId: params.worktreeId,
+        role: 'assistant',
+        content: params.content,
+        messageType: 'normal',
+        timestamp: new Date(params.at),
+        requestId: `${exports.MODEL_CHANGE_REQUEST_ID_PREFIX}${params.at}`,
+        cliToolId: params.cliToolId,
+        instanceId: params.instanceId ?? params.cliToolId,
+    });
+}
+// ===========================================================================
+// Relay rows (Issue #2377)
+// ===========================================================================
+/**
+ * The `request_id` prefix a RELAYED message carries.
+ *
+ * The delivered body is an ordinary user row — session B's answer, typed into
+ * session A's composer — and `relay:<relayId>` is what turns that row back into
+ * a pointer at the ledger entry that produced it. Two readers depend on that
+ * direction:
+ *
+ *  - the ledger's own idempotency, because the id is also
+ *    `session_relays.sent_request_id` and that column carries a UNIQUE index;
+ *  - the loop guard, which asks "was the last thing this session was told a
+ *    relayed message, and if so, whose?" — the answer is the parent relay, and
+ *    its `hops` is what the new relay's depth is measured from.
+ *
+ * Same shape and same reasoning as {@link MODEL_CHANGE_REQUEST_ID_PREFIX}: a
+ * prefix rather than a wording, because the wording is localized at write time.
+ */
+exports.RELAY_REQUEST_ID_PREFIX = 'relay:';
+/** The `request_id` prefix a relay SYSTEM row carries (`relay-sys:<relayId>:<kind>`). */
+exports.RELAY_SYSTEM_REQUEST_ID_PREFIX = 'relay-sys:';
+/** Build the relay message's request id from the ledger id. */
+function relayRequestId(relayId) {
+    return `${exports.RELAY_REQUEST_ID_PREFIX}${relayId}`;
+}
+/**
+ * The ledger id inside a relayed row's request id, or null.
+ *
+ * Null for every other row, including a relay SYSTEM row: those are transcript
+ * furniture, not the delivery, and treating one as the delivery would let a
+ * session's own "delegated, waiting" line count as an inbound relay.
+ */
+function parseRelayRequestId(requestId) {
+    if (!requestId || !requestId.startsWith(exports.RELAY_REQUEST_ID_PREFIX))
+        return null;
+    const id = requestId.slice(exports.RELAY_REQUEST_ID_PREFIX.length);
+    return id === '' ? null : id;
+}
+/**
+ * The newest user-authored row for ONE agent instance.
+ *
+ * {@link getLastUserMessage} answers the same question for a whole worktree,
+ * which is the wrong scope for the loop guard: a worktree runs several sessions
+ * and "was I asked this by a relay?" is a question about one of them.
+ *
+ * `matchResolvedInstance`'s expression is spelled out here rather than reused
+ * through `getMessages` because this read wants the newest USER row and
+ * `getMessages` bounds by rows of every role — a turn with thirty assistant
+ * rows in it would push the user row out of any sane limit.
+ */
+function getLastUserMessageForInstance(db, worktreeId, cliToolId, instanceId) {
+    const stmt = db.prepare(`
+    SELECT id, worktree_id, role, content, summary, timestamp, log_file_name, request_id, message_type, prompt_data, cli_tool_id, instance_id, archived
+    FROM chat_messages
+    WHERE worktree_id = ? AND role = 'user' ${exports.ACTIVE_FILTER}
+      AND COALESCE(cli_tool_id, 'claude') = ?
+      AND COALESCE(instance_id, cli_tool_id, 'claude') = ?
+    ORDER BY timestamp DESC
+    LIMIT 1
+  `);
+    const row = stmt.get(worktreeId, cliToolId, instanceId);
+    return row ? mapChatMessage(row) : null;
+}
+/**
+ * The newest unanswered prompt row for one agent instance, or null.
+ *
+ * What the confirmation notice is written from. `promptData.status` is the
+ * only thing consulted — the row's own wording is what the notice quotes — and
+ * a row whose data is one of #1738's degraded records simply yields no options,
+ * which the notice renders as a question with no choices rather than dropping.
+ */
+function getLatestOpenPromptMessage(db, worktreeId, cliToolId, instanceId) {
+    const stmt = db.prepare(`
+    SELECT id, worktree_id, role, content, summary, timestamp, log_file_name, request_id, message_type, prompt_data, cli_tool_id, instance_id, archived
+    FROM chat_messages
+    WHERE worktree_id = ? AND message_type = 'prompt' ${exports.ACTIVE_FILTER}
+      AND COALESCE(cli_tool_id, 'claude') = ?
+      AND COALESCE(instance_id, cli_tool_id, 'claude') = ?
+    ORDER BY timestamp DESC
+    LIMIT 1
+  `);
+    const row = stmt.get(worktreeId, cliToolId, instanceId);
+    if (!row)
+        return null;
+    const message = mapChatMessage(row);
+    return message.promptData?.status === 'answered' ? null : message;
+}
+/**
+ * Persist "this session delegated / got an answer" into the transcript (#2377).
+ *
+ * An assistant row with a marker request id, exactly as
+ * {@link createModelChangeMessage} writes the model-change line, and for the
+ * same reasons: `chat_messages` has no `system` role, the transcript groups a
+ * leading assistant row as a standalone reply, and the row is `normal` so
+ * nothing scanning for open dialogs mistakes it for one. Writing it here rather
+ * than inventing a fourth history surface is what puts the line in the chat
+ * pane AND the History tab from one write.
+ *
+ * Idempotent by construction at the call site: the request id is
+ * `relay-sys:<relayId>:<kind>` and the callers probe
+ * {@link findMessageByRequestId} before writing, so a retried delivery does not
+ * leave two "waiting for the reply" lines in one transcript.
+ */
+function createRelaySystemMessage(db, params) {
+    return createMessage(db, {
+        worktreeId: params.worktreeId,
+        role: 'assistant',
+        content: params.content,
+        messageType: 'normal',
+        timestamp: new Date(params.at),
+        requestId: `${exports.RELAY_SYSTEM_REQUEST_ID_PREFIX}${params.relayId}:${params.kind}`,
+        cliToolId: params.cliToolId,
+        instanceId: params.instanceId ?? params.cliToolId,
+    });
+}

package/dist/server/src/lib/db/migrations/index.js

@@ -43,6 +43,7 @@ const v56_gate_result_source_1 = require("./v56-gate-result-source");
 const v57_push_subscription_defaults_notice_1 = require("./v57-push-subscription-defaults-notice");
 const v58_agent_session_costs_1 = require("./v58-agent-session-costs");
 const v59_opencode_instance_settings_1 = require("./v59-opencode-instance-settings");
+const v60_session_relays_1 = require("./v60-session-relays");
 /**
  * Complete ordered list of all migrations.
  * Used internally by the barrel file (db-migrations.ts); NOT exported from the barrel (DR2-004).
@@ -89,4 +90,5 @@ exports.migrations = [
     ...v57_push_subscription_defaults_notice_1.v57_migrations,
     ...v58_agent_session_costs_1.v58_migrations,
     ...v59_opencode_instance_settings_1.v59_migrations,
+    ...v60_session_relays_1.v60_migrations,
 ];

package/dist/server/src/lib/db/migrations/runner.js

@@ -17,7 +17,7 @@ const path_1 = __importDefault(require("path"));
  * Current schema version
  * Increment this when adding new migrations
  */
-exports.CURRENT_SCHEMA_VERSION = 59;
+exports.CURRENT_SCHEMA_VERSION = 60;
 /**
  * Get current schema version from database
  */

package/dist/server/src/lib/db/migrations/v60-session-relays.js

@@ -0,0 +1,110 @@
+"use strict";
+/**
+ * Migration v60: the relay ledger (Issue #2377).
+ *
+ * ## What a row is
+ *
+ * One row is one standing instruction: "when session B finishes the turn it is
+ * working on, put its answer into session A's composer". Until this Issue that
+ * instruction existed only as a shape in session A's own control flow — `send`,
+ * then `wait`, then `capture` — which is why A had to stay blocked to collect a
+ * reply it had already asked for. A ledger row is the same intent written down
+ * somewhere the server can act on, so A can go and do something else.
+ *
+ * ## Why `from` is the requester and `to` is the worker
+ *
+ * The row is named after the DELEGATION, not after the delivery: `from` is the
+ * session that asked (and is therefore owed the answer), `to` is the session
+ * that was asked. So `commandmate relays` reads "mine, out" as
+ * `from = me` and "mine, in" as `to = me`, and the badges the Agent pane draws
+ * read the same way round — B's row says it owes A a reply, A's row says it is
+ * waiting on n of them.
+ *
+ * ## The columns that are not just bookkeeping
+ *
+ * - **`sent_request_id`** is the idempotency key the Issue asks for. The turn's
+ *   end is judged by two independent producers (the Stop hook and the poller,
+ *   see `lib/polling/structured-history-gate`), so the delivery has to be
+ *   claimable exactly once. It carries the `relay:<id>` request id of the row
+ *   written into A's history, which is also what makes the delivered message
+ *   findable from the ledger and the ledger findable from the message — that
+ *   second direction is what the loop guard reads.
+ * - **`pending_kind` / `pending_body`** hold a delivery that has been decided
+ *   but not yet made. A is frequently mid-turn when B finishes, and typing into
+ *   a running composer interrupts it (#1737's problem, one layer up), so the
+ *   body waits in the ledger — durable across a restart — and the pump retries.
+ *   `pending_kind IS NULL` is also the "nobody has captured this turn yet"
+ *   guard that makes the two producers cost one delivery.
+ * - **`prompt_signature`** dedupes the confirmation notice. A wait that lasts
+ *   twenty minutes must reach A once, not once per poll.
+ * - **`hops`** is the chain depth. 1 for a relay a human or an unrelated turn
+ *   started; n+1 for one created while answering a relay-delivered message.
+ *
+ * `state` is CHECK-constrained for the reason v50's `tasks.status` is: the five
+ * words are the point of the table, and a typo landing as a sixth would create
+ * a bucket nothing queries.
+ *
+ * Both worktree columns declare a foreign key so `getWorktreeChildTables()`
+ * finds them by introspection — the pair follows a worktree id rename (v54/v55)
+ * and is swept when either side is deleted, which is the right lifetime: a relay
+ * whose requester or whose worker is gone can never be delivered.
+ *
+ * Timestamps are epoch milliseconds (INTEGER), matching v44 onward.
+ */
+Object.defineProperty(exports, "__esModule", { value: true });
+exports.v60_migrations = void 0;
+exports.v60_migrations = [
+    {
+        version: 60,
+        name: 'session-relays',
+        up: (db) => {
+            db.exec(`
+        CREATE TABLE IF NOT EXISTS session_relays (
+          id TEXT PRIMARY KEY,
+          from_worktree_id TEXT NOT NULL,
+          from_instance_id TEXT NOT NULL,
+          to_worktree_id TEXT NOT NULL,
+          to_instance_id TEXT NOT NULL,
+          state TEXT NOT NULL CHECK (state IN ('pending','delivered','prompt','expired','cancelled')),
+          hops INTEGER NOT NULL DEFAULT 1,
+          sent_request_id TEXT,
+          pending_kind TEXT,
+          pending_body TEXT,
+          prompt_signature TEXT,
+          created_at INTEGER NOT NULL,
+          updated_at INTEGER NOT NULL,
+          expires_at INTEGER NOT NULL,
+          delivered_at INTEGER,
+
+          FOREIGN KEY (from_worktree_id) REFERENCES worktrees(id) ON DELETE CASCADE,
+          FOREIGN KEY (to_worktree_id) REFERENCES worktrees(id) ON DELETE CASCADE
+        );
+      `);
+            // The idempotency key, enforced rather than merely intended. Partial so
+            // the many rows that have not been delivered yet do not collide on NULL.
+            db.exec(`
+        CREATE UNIQUE INDEX IF NOT EXISTS idx_session_relays_sent_request
+          ON session_relays(sent_request_id)
+          WHERE sent_request_id IS NOT NULL;
+      `);
+            // The two lookups every reader makes: "what does this session owe" and
+            // "what is this session waiting for".
+            db.exec(`
+        CREATE INDEX IF NOT EXISTS idx_session_relays_to
+          ON session_relays(to_worktree_id, to_instance_id, state);
+      `);
+            db.exec(`
+        CREATE INDEX IF NOT EXISTS idx_session_relays_from
+          ON session_relays(from_worktree_id, from_instance_id, state);
+      `);
+            // The sweep's own read: everything still open, oldest deadline first.
+            db.exec(`
+        CREATE INDEX IF NOT EXISTS idx_session_relays_open
+          ON session_relays(state, expires_at);
+      `);
+        },
+        down: (db) => {
+            db.exec('DROP TABLE IF EXISTS session_relays;');
+        },
+    },
+];