commandmate 0.27.1 → 0.29.0

package/dist/server/src/lib/polling/structured-history-gate.js

@@ -0,0 +1,75 @@
+"use strict";
+/**
+ * Whether somebody better-informed is already recording this turn (Issue #2041).
+ *
+ * The poller's job has always been to be the only writer of conversation
+ * history, because for five of the six tools the terminal is the only place the
+ * reply exists. opencode is the exception: since #1763 CommandMate holds an SSE
+ * connection to the agent's own server, and since this Issue that connection
+ * carries the reply's Markdown source. Two writers for one turn would put the
+ * same answer in History twice — once as the agent wrote it and once as its TUI
+ * drew it — so one of them has to stand down, and it is the one reading the
+ * screen.
+ *
+ * ## Why this is a module and not an `if`
+ *
+ * Two reasons, and the second is the one that matters. The obvious one is that
+ * `response-checker` is 1,000 lines with a single tool-agnostic spine, and a
+ * `cliToolId === 'opencode' && …` in the middle of the save path is exactly the
+ * kind of branch that gets copied to the next tool that grows a server. The
+ * real one is the import: `@/lib/hooks/sources/opencode/subscription` reaches
+ * the whole opencode client through its module graph, and the poller's tests
+ * replace that graph wholesale. One named seam is one thing to stub.
+ *
+ * ## What is NOT gated
+ *
+ * Only the two calls that *record the reply* — the `chat_messages` row and the
+ * Markdown conversation log. Prompt rows, Auto-Yes, the waiting-episode edges,
+ * push notifications, task events and the session-state cursor all stay on the
+ * scraper, because none of them are things the event stream duplicates: a
+ * `permission.asked` becomes a pending decision, never a history row, and the
+ * push fan-out has no second producer at all. Gating them would trade a
+ * duplicated reply for a silent notification, which is the worse failure.
+ *
+ * @module lib/polling/structured-history-gate
+ */
+Object.defineProperty(exports, "__esModule", { value: true });
+exports.isStructuredHistoryWriterLive = isStructuredHistoryWriterLive;
+const logger_1 = require("../../lib/logger");
+const subscription_1 = require("../../lib/hooks/sources/opencode/subscription");
+const logger = (0, logger_1.createLogger)('lib/polling/structured-history-gate');
+/**
+ * Whether the agent's own server is recording this instance's replies.
+ *
+ * False for every tool but opencode, and false for an opencode instance whose
+ * subscription is anything other than `live` — see
+ * {@link isOpencodeStructuredHistoryLive} for why `lost` counts as "nobody is
+ * writing this down" rather than as "somebody will". The fallback direction is
+ * the safe one: two writers duplicate a reply, no writer loses it.
+ *
+ * Never throws. A source that cannot be asked is one that is not writing.
+ *
+ * @param worktreeId - The worktree
+ * @param cliToolId - The tool driving the pane
+ * @param instanceId - The agent instance; defaults to the primary
+ */
+function isStructuredHistoryWriterLive(worktreeId, cliToolId, instanceId) {
+    if (cliToolId !== 'opencode')
+        return false;
+    try {
+        return (0, subscription_1.isOpencodeStructuredHistoryLive)({
+            worktreeId,
+            cliToolId,
+            instanceId: instanceId ?? cliToolId,
+        });
+    }
+    catch (error) {
+        logger.warn('structured-history-gate-unavailable', {
+            worktreeId,
+            cliToolId,
+            instanceId: instanceId ?? cliToolId,
+            error: error instanceof Error ? error.message : String(error),
+        });
+        return false;
+    }
+}

package/dist/server/src/lib/prompt-answer-sender.js

@@ -7,13 +7,150 @@
  * the promptType/defaultOptionNumber fallback introduced in Bug1).
  */
 Object.defineProperty(exports, "__esModule", { value: true });
+exports.PromptAnswerRejectedError = exports.ANSWER_MODE_KEYS_REASON = void 0;
 exports.sendPromptAnswer = sendPromptAnswer;
 const tmux_1 = require("./tmux/tmux");
+const frame_1 = require("../lib/detection/tools/frame");
+const registry_1 = require("../lib/detection/tools/registry");
 const models_1 = require("../types/models");
 const tmux_capture_cache_1 = require("./tmux/tmux-capture-cache");
 const cli_tool_timing_config_1 = require("../config/cli-tool-timing-config");
 /** Regex pattern to detect checkbox-style multi-select options */
 const CHECKBOX_OPTION_PATTERN = /^\[[ x]\] /;
+/**
+ * The reason code a caller gets back when a digit meets a `keys`-mode dialog
+ * (Issue #2033).
+ *
+ * Spelled as a constant because it crosses two boundaries: the API refusal body
+ * `respond` reads (`/prompt-response`), and the assertions that pin it.
+ */
+exports.ANSWER_MODE_KEYS_REASON = 'answer_mode_keys';
+/**
+ * The only {@link DialogAnswerMode} a typed digit can actually drive.
+ *
+ * Named rather than compared inline so the test that would have to change is
+ * the one that states the rule, not five call sites of `=== 'keys'`.
+ */
+const TEXT_ANSWERABLE_ANSWER_MODE = 'numbered';
+/**
+ * How much scrollback the guard reads when the caller supplied no frame.
+ *
+ * The dialog rules window the LAST rows of the pane (`STATUS_CHECK_LINE_COUNT`
+ * for the strips, the content run for the pickers), so this only has to be
+ * comfortably larger than a screen — not the 1000-row default `capturePane`
+ * would otherwise take on a path that runs before every keystroke.
+ */
+const GUARD_CAPTURE_LINES = 200;
+/**
+ * A prompt answer that was refused BEFORE any key reached the pane.
+ *
+ * The distinction matters to every caller: a throw from `sendKeys` leaves the
+ * terminal in an unknown state, whereas this one is a guarantee that nothing was
+ * typed and the dialog is still exactly as the operator left it.
+ */
+class PromptAnswerRejectedError extends Error {
+    /** Machine-readable code, currently always {@link ANSWER_MODE_KEYS_REASON}. */
+    reason;
+    /** The dialog family the tool vouched for, e.g. `permission` / `picker`. */
+    dialogKind;
+    /** How that dialog actually takes its answer. */
+    answerMode;
+    constructor(cliToolId, answer, dialog) {
+        super(`Refused to send "${answer}" to ${cliToolId}: its ${dialog.kind} dialog takes `
+            + `'${dialog.answerMode}' input, not a typed number (${exports.ANSWER_MODE_KEYS_REASON}). `
+            + 'The digit would be swallowed and the Enter after it would confirm whatever is '
+            + 'highlighted. Nothing was sent.');
+        this.name = 'PromptAnswerRejectedError';
+        this.reason = exports.ANSWER_MODE_KEYS_REASON;
+        this.dialogKind = dialog.kind;
+        this.answerMode = dialog.answerMode;
+    }
+}
+exports.PromptAnswerRejectedError = PromptAnswerRejectedError;
+/**
+ * The pane to judge the tool's own dialog rules against.
+ *
+ * Prefers the capture the caller already took — `/prompt-response` captures a
+ * fresh frame two statements before it calls in, and re-reading the pane there
+ * would be a second tmux round trip AND a second, later frame, i.e. a different
+ * screen from the one whose prompt was verified.
+ *
+ * Falls back to reading the pane here so that a caller with no frame (the chat
+ * button route, `auto-yes-manager`) is still covered: the point of Issue #2033
+ * is that this function must not be dangerous on its own.
+ *
+ * Returns null when the pane cannot be read at all. That is deliberately
+ * fail-OPEN, and it is the same call `/prompt-response` already makes for its
+ * own pre-send verification ("If capture fails, proceed with caution - don't
+ * block manual responses"): a session whose pane is unreadable is far more often
+ * a mocked or racing transport than an open dialog, and turning every such case
+ * into a refusal would make the operator's only way out stop working.
+ */
+async function readGuardFrame(params) {
+    if (params.frame !== undefined)
+        return params.frame;
+    try {
+        return await (0, tmux_1.capturePane)(params.sessionName, GUARD_CAPTURE_LINES);
+    }
+    catch {
+        return null;
+    }
+}
+/**
+ * Refuse a numeric answer the tool's own dialog cannot take (Issue #2033).
+ *
+ * ## Why this is keyed on `answerMode` and not on the tool id
+ *
+ * The branch below has always asked "which tool is this?", and the comment above
+ * it classified opencode as a tool that "accepts N + Enter as text". That was
+ * measured to be false (#1893): opencode's permission strip is a row of
+ * unnumbered buttons driven by ←/→, the digit is swallowed, and the Enter after
+ * it confirms whatever is HIGHLIGHTED — which defaults to `Allow once`. So
+ * `respond <id> 3`, meaning Reject, approved.
+ *
+ * Fixing that by adding `opencode` to a list would have re-opened on the eighth
+ * tool. `answerMode` is the measurement itself, declared per DIALOG by the
+ * module that read the tool's own frames (`DialogVerdict.answerMode`), and it is
+ * already what {@link evaluateAutoYesDialogGate} gates Auto-Yes on. Reading the
+ * same field here puts the operator's `respond` behind the same measurement that
+ * Auto-Yes is behind, instead of behind a second opinion about tool names.
+ *
+ * Per-dialog rather than per-tool is load-bearing, not pedantry: copilot reports
+ * `numbered` for its permission block and `keys` for its picker
+ * (`detection/tools/copilot/prompt.ts`), so any per-tool verdict would be wrong
+ * for one of the two.
+ *
+ * ## What it deliberately does NOT do
+ *
+ * - It judges only NUMERIC answers. `y` / `no` / free text on a `keys` dialog is
+ *   a different failure and a different fix (`resolvePromptAnswer`, #1681).
+ * - It never fires for a tool with no measured dialog rules
+ *   (`hasDialogRules === false`: gemini, antigravity, vibe-local). Gating on
+ *   rules that do not exist would silence those tools, which is the rollout
+ *   mistake `auto-yes-dialog-gate` documents.
+ * - It does not MAP the answer onto the dialog's buttons. Turning "3" into the
+ *   two ←/→ presses that reach `Reject` is Issue P1-7's structured-decision
+ *   work; this Issue only stops the wrong keystroke.
+ *
+ * @throws {PromptAnswerRejectedError} when the tool vouched for a dialog on this
+ *   frame whose `answerMode` is not {@link TEXT_ANSWERABLE_ANSWER_MODE}.
+ */
+async function assertAnswerModeAcceptsNumber(params) {
+    if (!/^\d+$/.test(params.answer))
+        return;
+    const detector = (0, registry_1.getToolStatusDetector)(params.cliToolId);
+    if (!detector.hasDialogRules)
+        return;
+    const frame = await readGuardFrame(params);
+    if (frame === null)
+        return;
+    const dialog = detector.detectDialog((0, frame_1.normalizeFrame)(frame));
+    if (dialog === null)
+        return;
+    if (dialog.answerMode === TEXT_ANSWERABLE_ANSWER_MODE)
+        return;
+    throw new PromptAnswerRejectedError(params.cliToolId, params.answer, dialog);
+}
 /**
  * Resolve the effective SubmitMode from promptData, fallback, and default.
  * Resolution order: promptData.submitMode -> fallbackSubmitMode -> 'answer_then_enter'.
@@ -60,11 +197,25 @@ function buildNavigationKeys(offset) {
  */
 async function sendPromptAnswer(params) {
     const { sessionName, answer, cliToolId, promptData, fallbackPromptType, fallbackDefaultOptionNumber } = params;
+    // Issue #2033: before ANY key is chosen, let the tool's own dialog rules
+    // refuse a digit its dialog cannot take. Placed above the branch rather than
+    // inside the text arm because the number->offset arithmetic the cursor arm
+    // does is just as meaningless on an unnumbered button strip as typing the
+    // digit is.
+    await assertAnswerModeAcceptsNumber(params);
     // Determine if this is an arrow-key-navigated multiple-choice prompt.
     // Claude Code and Antigravity (agy) both render selection menus that only
     // respond to cursor navigation + Enter, not to typed option numbers
-    // ([Issue #999] agy's "Do you want to proceed?" permission menu). Everything
-    // else (codex/gemini/copilot/opencode) accepts "N" + Enter as text.
+    // ([Issue #999] agy's "Do you want to proceed?" permission menu).
+    //
+    // [Issue #2033] The comment that used to sit here said "everything else
+    // (codex/gemini/copilot/opencode) accepts 'N' + Enter as text". That was
+    // measured to be wrong for opencode (#1893) and for copilot's picker (#1895),
+    // and the correction is NOT another tool id in this condition: it is
+    // `assertAnswerModeAcceptsNumber` above, which asks the tool's own
+    // `detectDialog` what the dialog ON SCREEN takes. This condition is now only
+    // about which INPUT METHOD to use for a dialog that was already cleared as
+    // answerable by number.
     const isCursorNavMultiChoice = (cliToolId === 'claude' || cliToolId === 'antigravity')
         && (promptData?.type === 'multiple_choice' || fallbackPromptType === 'multiple_choice')
         && /^\d+$/.test(answer);

package/dist/server/src/lib/push/delivery-health.js

@@ -0,0 +1,237 @@
+"use strict";
+/**
+ * Per-device Web Push delivery health (Issues #2124 / #2123, extensible for #2126).
+ *
+ * ## Why this exists
+ *
+ * `push-sender` has always answered a failed send in the log and nowhere else:
+ *
+ *   404 / 410  -> the row is deleted (the endpoint is gone at the push service)
+ *   anything    -> `logger.warn('push-send-failed')`, and the subscription stays
+ *
+ * Both are the right handling. Neither is observable by the person holding the
+ * phone. Measured by the orchestrator during the Epic #2002 device UAT
+ * (2026-08-27, develop e8d09989): an APNs 403 caused by the old default
+ * `CM_VAPID_SUBJECT` (#2124) silenced an iPad for an entire session while
+ * Android kept receiving, and a 410 removed the Android subscription without a
+ * single line reaching the UI — the reader's whole experience was "notifications
+ * stopped at some point". This module is the state that lets the More screen say
+ * "this device is not receiving" instead.
+ *
+ * ## What it records, and what it deliberately does not
+ *
+ * One row per endpoint that is CURRENTLY unhealthy. A successful send deletes the
+ * row, so the store holds failures only and a device that recovers leaves nothing
+ * behind. It is not a history and not a metric: the UI question is "is this phone
+ * getting notifications right now, and if not, what did the push service say".
+ *
+ * `state` separates the two outcomes the sender already distinguishes:
+ *
+ *   'removed' — 404/410; the subscription row is gone and the device must
+ *               re-subscribe. The health row OUTLIVES the subscription on
+ *               purpose: it is the only remaining evidence of why the device
+ *               went quiet, and `GET /api/push/subscriptions` reads it for an
+ *               endpoint that no longer has a subscription.
+ *   'failing' — everything else (403 from APNs over a bad `sub`, and the 4xx
+ *               #2126 is about). The subscription is untouched — a configuration
+ *               mistake must never delete a reader's subscription — so the row
+ *               is purely advisory.
+ *
+ * ## Why `app_settings`, and why the SQL is here
+ *
+ * The same trade `escalation-settings` and `prompt-card-state` made in this
+ * directory: `app_settings` (migration v27) is the generic key-value table, so
+ * this needs **no migration**, and the accessor lives beside its only two
+ * consumers. One row per unhealthy endpoint rather than one JSON map, so record
+ * and clear are single statements with no read-modify-write between processes
+ * sharing the database file.
+ *
+ * ## Why the key is a hash
+ *
+ * A push endpoint is a bearer capability — anyone holding it can send to that
+ * device — which is why this repository never logs one. An `app_settings` key is
+ * plainly readable by anything that opens the database, and `commandmate` shows
+ * that database to the user, so the key is `sha256(endpoint)` and the endpoint
+ * itself is never stored. Lookup still works because every reader (the sender,
+ * and the API route serving a client that knows its own endpoint) has the
+ * endpoint in hand and can hash it.
+ *
+ * Every database call here is total: an unopenable database, a missing table or
+ * a malformed value all resolve to "healthy" rather than throwing. The callers
+ * are a push fan-out and a settings route; neither may be disturbed by storage.
+ *
+ * @module lib/push/delivery-health
+ */
+Object.defineProperty(exports, "__esModule", { value: true });
+exports.PUSH_DELIVERY_HEALTH_MAX_AGE_MS = exports.PUSH_DELIVERY_HEALTH_KEY_PREFIX = void 0;
+exports.getPushDeliveryHealth = getPushDeliveryHealth;
+exports.recordPushDeliveryFailure = recordPushDeliveryFailure;
+exports.clearPushDeliveryHealth = clearPushDeliveryHealth;
+exports.clearAllPushDeliveryHealth = clearAllPushDeliveryHealth;
+const crypto_1 = require("crypto");
+const db_instance_1 = require("../../lib/db/db-instance");
+const logger_1 = require("../../lib/logger");
+const logger = (0, logger_1.createLogger)('push/delivery-health');
+/** `app_settings` key prefix for a delivery-health row. */
+exports.PUSH_DELIVERY_HEALTH_KEY_PREFIX = 'push_delivery_health:';
+/**
+ * How long an unhealthy record is kept.
+ *
+ * 30 days: long enough that a phone left in a drawer still gets an explanation
+ * when it is picked up, short enough that a device the reader has abandoned does
+ * not keep a row forever. Pruned lazily on read and on write, so no sweeper task
+ * has to exist.
+ */
+exports.PUSH_DELIVERY_HEALTH_MAX_AGE_MS = 30 * 24 * 60 * 60 * 1000;
+function keyFor(endpoint) {
+    return `${exports.PUSH_DELIVERY_HEALTH_KEY_PREFIX}${(0, crypto_1.createHash)('sha256').update(endpoint).digest('hex')}`;
+}
+function isExpired(record, now) {
+    return now - record.lastFailureAt >= exports.PUSH_DELIVERY_HEALTH_MAX_AGE_MS;
+}
+/** Structural check for a record read back out of `app_settings`. */
+function parseRecord(value) {
+    try {
+        const parsed = JSON.parse(value);
+        if (typeof parsed !== 'object' || parsed === null)
+            return null;
+        const r = parsed;
+        if (r.state !== 'removed' && r.state !== 'failing')
+            return null;
+        if (typeof r.failureCount !== 'number' || !Number.isFinite(r.failureCount))
+            return null;
+        if (typeof r.firstFailureAt !== 'number' || !Number.isFinite(r.firstFailureAt))
+            return null;
+        if (typeof r.lastFailureAt !== 'number' || !Number.isFinite(r.lastFailureAt))
+            return null;
+        const statusCode = typeof r.statusCode === 'number' && Number.isFinite(r.statusCode) ? r.statusCode : null;
+        return {
+            state: r.state,
+            statusCode,
+            failureCount: r.failureCount,
+            firstFailureAt: r.firstFailureAt,
+            lastFailureAt: r.lastFailureAt,
+        };
+    }
+    catch {
+        return null;
+    }
+}
+function writeRow(endpoint, record) {
+    try {
+        (0, db_instance_1.getDbInstance)()
+            .prepare(`
+        INSERT INTO app_settings (key, value, created_at, updated_at)
+        VALUES (?, ?, ?, ?)
+        ON CONFLICT(key) DO UPDATE SET
+          value = excluded.value,
+          updated_at = excluded.updated_at
+      `)
+            .run(keyFor(endpoint), JSON.stringify(record), record.firstFailureAt, record.lastFailureAt);
+    }
+    catch (error) {
+        logger.debug('delivery-health-write-failed', {
+            error: error instanceof Error ? error.message : String(error),
+        });
+    }
+}
+function deleteRow(endpoint) {
+    try {
+        return ((0, db_instance_1.getDbInstance)().prepare('DELETE FROM app_settings WHERE key = ?').run(keyFor(endpoint))
+            .changes > 0);
+    }
+    catch (error) {
+        logger.debug('delivery-health-delete-failed', {
+            error: error instanceof Error ? error.message : String(error),
+        });
+        return false;
+    }
+}
+/**
+ * Whether this endpoint is currently failing, and how.
+ *
+ * @returns The record, or `null` when the device is healthy (or the store cannot
+ *   answer — "healthy" is the fail-open direction: a diagnostic that cannot be
+ *   read must not turn into a warning banner on a working device).
+ */
+function getPushDeliveryHealth(endpoint, now = Date.now()) {
+    try {
+        const row = (0, db_instance_1.getDbInstance)()
+            .prepare('SELECT value FROM app_settings WHERE key = ?')
+            .get(keyFor(endpoint));
+        if (!row)
+            return null;
+        const record = parseRecord(row.value);
+        if (record === null)
+            return null;
+        if (isExpired(record, now)) {
+            deleteRow(endpoint);
+            return null;
+        }
+        return record;
+    }
+    catch (error) {
+        logger.debug('delivery-health-read-failed', {
+            error: error instanceof Error ? error.message : String(error),
+        });
+        return null;
+    }
+}
+/**
+ * Record that a send to this endpoint failed.
+ *
+ * Called from the ONE place that observes the failure (`push-sender.sendToOne`),
+ * for both handlings — the caller says which by passing `removed`.
+ *
+ * The streak continues across restarts: `failureCount` is read back and
+ * incremented, so "403 every time for two days" is distinguishable from "one
+ * blip", which is what #2126 will need when it decides whether a device is
+ * genuinely cut off.
+ *
+ * A `removed` record never re-opens as `failing`: once the push service has said
+ * the endpoint is gone, a later failure on the same endpoint is the same fact.
+ *
+ * Never throws.
+ */
+function recordPushDeliveryFailure(endpoint, options = {}, now = Date.now()) {
+    const previous = getPushDeliveryHealth(endpoint, now);
+    const state = options.removed === true || previous?.state === 'removed' ? 'removed' : 'failing';
+    const record = {
+        state,
+        statusCode: options.statusCode ?? null,
+        failureCount: (previous?.failureCount ?? 0) + 1,
+        firstFailureAt: previous?.firstFailureAt ?? now,
+        lastFailureAt: now,
+    };
+    writeRow(endpoint, record);
+    return record;
+}
+/**
+ * Record that a send to this endpoint succeeded, clearing any streak.
+ *
+ * @returns True when a record was actually cleared, i.e. when the device had been
+ *   failing and has now recovered. The caller logs on that edge — it is the one
+ *   push success worth a line, and the reason `push-sender` was silent about
+ *   successes is that every OTHER success is unremarkable.
+ */
+function clearPushDeliveryHealth(endpoint) {
+    return deleteRow(endpoint);
+}
+/**
+ * Drop every delivery-health row. Test-only helper; the production paths clear
+ * one endpoint at a time.
+ */
+function clearAllPushDeliveryHealth() {
+    try {
+        // GLOB rather than LIKE: the prefix contains `_`, which LIKE treats as a
+        // single-character wildcard and would match neighbouring keys with.
+        (0, db_instance_1.getDbInstance)()
+            .prepare('DELETE FROM app_settings WHERE key GLOB ?')
+            .run(`${exports.PUSH_DELIVERY_HEALTH_KEY_PREFIX}*`);
+    }
+    catch (error) {
+        logger.debug('delivery-health-clear-failed', {
+            error: error instanceof Error ? error.message : String(error),
+        });
+    }
+}

package/dist/server/src/lib/push/failure-push-notifier.js

@@ -11,7 +11,7 @@
  * |---------------------|--------------------------------------------|--------|
  * | verification failed | `lib/verification/gate-runner`              | event  |
  * | upstream API fault  | `lib/polling/response-checker` (#1839 match)| level  |
- * | session start failed| `lib/cli-tools/base` (all 7 tools, #2009)   | event  |
+ * | session start failed| `lib/cli-tools/start-availability` (#2009/#2022)| event |
  *
  * The shape column is the whole design. An **event** fires once by construction
  * — a run closes once, a start attempt throws once — so its only guard is the
@@ -29,6 +29,17 @@
  * `no-fault` — a clean frame — which is the outcome of most polls of most
  * sessions and would drown the log it exists to make readable.
  *
+ * ## The card has to say *which* instance (Issue #2125)
+ *
+ * `push-sender` builds the title as `<worktree>` plus ` (<agentName>)`, and
+ * omits the suffix when the producer has no agent to name. A bare
+ * `commandmate verify <id>` names none, so the failure card carried the branch
+ * name alone while the waiting card next to it said `(claude)` — and a worktree
+ * running `claude` / `claude-2` / `codex` in parallel could not be told which
+ * one had gone red. {@link formatWorktreeWideAgentLabel} is the answer: a run
+ * that named no instance is labelled with the worktree's resolved default
+ * *marked as such*, never substituted for a report that that instance ran.
+ *
  * ## Why none of this goes through `prompt-push-gate`
  *
  * #1999 mutes prompts that Auto-Yes is about to answer. No such claim can be
@@ -45,12 +56,14 @@
  * @module lib/push/failure-push-notifier
  */
 Object.defineProperty(exports, "__esModule", { value: true });
+exports.formatWorktreeWideAgentLabel = formatWorktreeWideAgentLabel;
 exports.notifyVerificationFailurePush = notifyVerificationFailurePush;
 exports.notifyUpstreamFaultPush = notifyUpstreamFaultPush;
 exports.notifySessionStartFailurePush = notifySessionStartFailurePush;
 const db_instance_1 = require("../../lib/db/db-instance");
 const worktree_db_1 = require("../../lib/db/worktree-db");
 const logger_1 = require("../../lib/logger");
+const resolve_session_target_1 = require("../../lib/session/resolve-session-target");
 const session_start_error_1 = require("../../lib/session/session-start-error");
 const failure_episode_state_1 = require("./failure-episode-state");
 const push_sender_1 = require("./push-sender");
@@ -71,6 +84,80 @@ function resolveWorktreeName(worktreeId) {
         return worktreeId;
     }
 }
+/**
+ * Prefix for the title suffix of a run that named no agent instance (#2125).
+ *
+ * Chosen so the label can never be read as an instance id: `isValidInstanceId`
+ * admits only `[A-Za-z0-9_-]{1,64}`, and both the colon and the space are
+ * outside it. A worktree whose operator really did register an instance called
+ * `worktree` therefore still renders differently from a worktree-wide run.
+ */
+const WORKTREE_WIDE_AGENT_PREFIX = 'worktree: ';
+/**
+ * What the label says when not even the worktree's default target can be named.
+ * A question mark rather than an omission, because "we could not tell" and
+ * "there was nothing to tell" are different facts and #2125 is about a title
+ * that dropped one of them silently.
+ */
+const UNKNOWN_AGENT_MARK = '?';
+/**
+ * Title suffix for a verification run that judged the worktree rather than a
+ * named instance (Issue #2125).
+ *
+ * Exported for the tests that pin the two spellings; producers go through
+ * {@link resolveVerificationAgentLabel}.
+ */
+function formatWorktreeWideAgentLabel(instanceId) {
+    return `${WORKTREE_WIDE_AGENT_PREFIX}${instanceId ?? UNKNOWN_AGENT_MARK}`;
+}
+/**
+ * Decide what the failure card should call the agent (Issue #2125).
+ *
+ * ## Why a bare `commandmate verify` had no suffix at all
+ *
+ * `push-sender` renders ` (${agentName})` and omits it when `agentName` is
+ * empty, and `commandmate verify <id>` names no `--instance`, so the run
+ * carried `instanceId: null` all the way from `gate-runner` and the card said
+ * only the worktree name (measured by the orchestrator on 2026-08-27, iPadOS
+ * 18.7 / APNs: `uat/push-2002` with body `検証ゲート不合格：lint`). Silence is
+ * the one thing that could not be read: the reader cannot tell "this run was
+ * about the whole worktree" from "the instance was dropped on the way".
+ *
+ * ## Why the resolved target is labelled rather than substituted
+ *
+ * A run that named no instance is asked about here through
+ * `resolveSessionTarget` — the #1925 authority that `GET
+ * /api/worktrees/:id/resolve-target` is the HTTP face of — so the card can name
+ * the agent the worktree would send to. But the answer is a *default*, not a
+ * report that this agent ran the gates, so it is rendered with the
+ * {@link WORKTREE_WIDE_AGENT_PREFIX} rather than as a plain instance id. The
+ * distinction is what stops a two-instance worktree from blaming whichever one
+ * happens to be the default.
+ *
+ * The resolution deliberately stops here and never reaches
+ * `RunVerificationInput.instanceId`: #2043 rests on an unnamed instance
+ * answering `false` to `namesOpencodeInstance`, so writing a resolved id onto
+ * the run would move a *verdict* (an opencode worktree's work-evidence gate)
+ * for the sake of a title.
+ *
+ * `resolvedBy: 'fallback'` is not a fact about this worktree — it is
+ * `resolve-session-target`'s own last-resort literal, reached when the row is
+ * gone — so it degrades to {@link UNKNOWN_AGENT_MARK} instead of asserting
+ * `claude`.
+ */
+function resolveVerificationAgentLabel(worktreeId, instanceId) {
+    if (instanceId !== undefined)
+        return instanceId;
+    try {
+        const target = (0, resolve_session_target_1.resolveSessionTarget)((0, db_instance_1.getDbInstance)(), worktreeId);
+        return formatWorktreeWideAgentLabel(target.resolvedBy === 'fallback' ? undefined : target.instanceId);
+    }
+    catch {
+        // A database that cannot answer is a reason for a vaguer title, never for
+        // dropping the notification — the position `resolveWorktreeName` takes.
+        return formatWorktreeWideAgentLabel();
+    }
+}
 /**
  * Fan one failure notification out, logging the decision. Never throws.
  *
@@ -81,6 +168,9 @@ async function raiseFailurePush(input) {
     const context = {
         worktreeId: input.worktreeId,
         instanceId: input.instanceId,
+        // Only the verification producer sets one (#2125); logging it unconditionally
+        // would repeat `instanceId` on every other line.
+        ...(input.agentLabel !== undefined ? { agentLabel: input.agentLabel } : {}),
         failureReason: input.reason,
         signature: input.signature,
         ...input.logContext,
@@ -96,12 +186,16 @@ async function raiseFailurePush(input) {
     try {
         await (0, push_sender_1.notifyPushSubscribers)({
             worktreeId: input.worktreeId,
-            worktreeName: resolveWorktreeName(input.worktreeId),
+            // Issue #2022: a subject that is not a worktree row names itself. The
+            // worktree lookup is not merely redundant for one — it would answer with
+            // the raw id, which for Assistant Chat is a uuid nobody recognises.
+            worktreeName: input.subject?.name ?? resolveWorktreeName(input.worktreeId),
             kind: 'failure',
-            agentName: input.instanceId,
+            agentName: input.agentLabel ?? input.instanceId,
             instanceId: input.instanceId,
             excerpt: input.excerpt,
             failure: { reason: input.reason, signature: input.signature },
+            ...(input.subject ? { url: input.subject.url } : {}),
         });
     }
     catch (error) {
@@ -178,6 +272,9 @@ async function notifyVerificationFailurePush(input) {
         reason: 'verification-failed',
         worktreeId: input.worktreeId,
         instanceId,
+        // Resolved here rather than at the suppression checks above: it reads the
+        // database, and a run nobody is going to be told about must not pay for it.
+        agentLabel: resolveVerificationAgentLabel(input.worktreeId, instanceId),
         // The run id, so two runs of the same worktree are two incidents even when
         // the same gates fail with the same wording inside the 30 s window.
         signature: `verification:${input.runId}`,
@@ -307,10 +404,14 @@ function readErrorCode(error) {
 /**
  * Notify that a CLI session could not be started. Never throws.
  *
- * Called from exactly one place — `BaseCLITool.startSession`, the method all
- * seven tools inherit (Issue #2009). Before that it was called from
- * `claude-session`'s throw site, which is why six of the seven agents failed
- * silently: the other six never had a line to call it from.
+ * Called from exactly one place — `reportSessionStartFailure` in
+ * `lib/cli-tools/start-availability` (Issue #2009 / #2022). Before #2009 it was
+ * called from `claude-session`'s throw site, which is why six of the seven
+ * agents failed silently: the other six never had a line to call it from. #2009
+ * moved it to `BaseCLITool.startSession`, the method all seven tools inherit;
+ * #2022 moved the line itself one step further out, because Assistant Chat
+ * never reaches that method — it spawns `claude -p` rather than a tmux session —
+ * and the alternative was a second, private call site.
  *
  * No edge of its own, and deliberately: this is raised from a `throw`, so its
  * rate is bounded by how often something asks to start the session rather than
@@ -340,5 +441,6 @@ async function notifySessionStartFailurePush(input) {
         signature: verdict.signature,
         excerpt: verdict.excerpt,
         logContext: { cliToolId: input.cliToolId },
+        subject: input.subject,
     });
 }