commandmate 0.44.1 → 0.44.3

package/dist/server/server.js

@@ -71,7 +71,7 @@ const ws_server_1 = require("./src/lib/ws-server");
 const worktrees_1 = require("./src/lib/git/worktrees");
 const db_instance_1 = require("./src/lib/db/db-instance");
 const response_poller_1 = require("./src/lib/polling/response-poller");
-const auto_yes_manager_1 = require("./src/lib/polling/auto-yes-manager");
+const auto_yes_lifecycle_1 = require("./src/lib/auto-yes-lifecycle");
 const schedule_manager_1 = require("./src/lib/schedule-manager");
 const timer_manager_1 = require("./src/lib/timer-manager");
 const resource_cleanup_1 = require("./src/lib/resource-cleanup");
@@ -825,8 +825,10 @@ app.prepare().then(() => {
         }
         // Stop polling first
         (0, response_poller_1.stopAllPolling)();
-        // Issue #138: Stop all auto-yes pollers
-        (0, auto_yes_manager_1.stopAllAutoYesPolling)();
+        // Issue #138: Stop all auto-yes pollers. Issue #3184: the `server-shutdown`
+        // row of the Auto-Yes lifecycle table — the state itself is in memory and
+        // goes with the process; nothing is persisted for the next start.
+        (0, auto_yes_lifecycle_1.releaseAutoYes)('server-shutdown', { scope: 'all' });
         // Issue #294: Stop all scheduled executions (SIGKILL fire-and-forget)
         (0, schedule_manager_1.stopAllSchedules)();
         // Issue #534: Stop all timer-based delayed messages

package/dist/server/src/cli/types/api-responses.js

@@ -3,7 +3,9 @@
  * CLI-side API Response Type Definitions
  * Issue #518: [DR1-06] All types include Mirrors comments for server-side traceability
  *
- * These types mirror server-side response shapes. Phase 2 will migrate to
- * shared types in src/types/api-contracts.ts.
+ * These types mirror server-side response shapes. Where a server module has no
+ * imports of its own (e.g. `lib/session/prompt-view`), it is imported here by
+ * relative path instead of restated, so the CLI build compiles it and there is
+ * no second definition to drift (see `promptView` below).
  */
 Object.defineProperty(exports, "__esModule", { value: true });

package/dist/server/src/config/cli-tool-timing-config.js

@@ -20,7 +20,7 @@
  * All values are preserved from the original literals (no behavior change).
  */
 Object.defineProperty(exports, "__esModule", { value: true });
-exports.LIVENESS_CONFIRM_DELAY_MS = exports.CLAUDE_RESTART_DELAY_MS = exports.CLAUDE_ENV_SANITIZE_WAIT_MS = exports.OPENCODE_V2_COMPOSER_WAIT_MS = exports.OPENCODE_V2_EXIT_WAIT_MS = exports.COMMAND_CODE_INIT_WAIT_MS = exports.VIBE_LOCAL_DOUBLE_ENTER_WAIT_MS = exports.COPILOT_EXIT_WAIT_MS = exports.OPENCODE_INTERRUPT_SECOND_ESCAPE_DELAY_MS = exports.OPENCODE_EXIT_WAIT_MS = exports.CODEX_DIALOG_SETTLE_MS = exports.TUI_EXIT_WAIT_MS = exports.TUI_INTERRUPT_SETTLE_MS = exports.TUI_MESSAGE_PROCESSED_WAIT_MS = exports.TUI_TEXT_INPUT_WAIT_MS = exports.TUI_SESSION_CREATE_WAIT_MS = void 0;
+exports.LIVENESS_CONFIRM_DELAY_MS = exports.CLAUDE_ENV_SANITIZE_WAIT_MS = exports.OPENCODE_V2_COMPOSER_WAIT_MS = exports.OPENCODE_V2_EXIT_WAIT_MS = exports.COMMAND_CODE_INIT_WAIT_MS = exports.VIBE_LOCAL_DOUBLE_ENTER_WAIT_MS = exports.COPILOT_EXIT_WAIT_MS = exports.OPENCODE_INTERRUPT_SECOND_ESCAPE_DELAY_MS = exports.OPENCODE_EXIT_WAIT_MS = exports.CODEX_DIALOG_SETTLE_MS = exports.TUI_EXIT_WAIT_MS = exports.TUI_INTERRUPT_SETTLE_MS = exports.TUI_MESSAGE_PROCESSED_WAIT_MS = exports.TUI_TEXT_INPUT_WAIT_MS = exports.TUI_SESSION_CREATE_WAIT_MS = void 0;
 /**
  * Wait (ms) after `createSession()` before sending the first keys, giving tmux
  * time to spin up the session.
@@ -162,11 +162,6 @@ exports.OPENCODE_V2_COMPOSER_WAIT_MS = 15000;
  * Site: session-key-sender sanitizeSessionEnvironment().
  */
 exports.CLAUDE_ENV_SANITIZE_WAIT_MS = 100;
-/**
- * Wait (ms) before restarting a Claude session, after the old session is stopped.
- * Site: claude-session restartClaudeSession().
- */
-exports.CLAUDE_RESTART_DELAY_MS = 1000;
 /**
  * Wait (ms) between the two liveness readings that must agree before a reuse
  * path re-sends a launch command (Issue #2070).

package/dist/server/src/config/uat-isolation.js

@@ -0,0 +1,246 @@
+"use strict";
+/**
+ * `CM_UAT_ISOLATION=1` — the mode a UAT / daily-check server and its CLI run in
+ * (Issue #3360).
+ *
+ * A UAT server is isolated from production by its own port, DB, tmux socket and
+ * state directories (`.commandmate/uat.yaml`). Three paths were left that those
+ * do not cover, because they are keyed by the user's login rather than by
+ * anything the UAT can move:
+ *
+ *  1. **codex's shared files.** `$CODEX_HOME/hooks.json`, the relay under
+ *     `$CODEX_HOME/commandmate/` and the hook trust in `config.toml` live beside
+ *     codex's login (`auth.json`), so moving `CODEX_HOME` logs codex out. In this
+ *     mode the server writes none of them: it reuses the shared file only when it
+ *     is already byte-identical to what this build would write (the per-session
+ *     URL travels in the environment, so the hooks then reach THIS server), and
+ *     otherwise refuses the launch ({@link UatIsolationLaunchRefusedError}) —
+ *     a bare codex would still read the shared file and run production's hooks.
+ *     antigravity's `~/.gemini/config/hooks.json` and copilot's
+ *     `~/.copilot/settings.json` (Issue #3391) are handled the same way. It
+ *     also never answers the hook review with *trust*, which is codex writing
+ *     `config.toml`.
+ *  2. **claude's user-level hooks.** `--settings` is added to
+ *     `~/.claude/settings.json`, not substituted for it, so the user's own hooks
+ *     (which post to production) would run in a UAT session too. Moving
+ *     `CLAUDE_CONFIG_DIR` logs claude out (measured, `-p` and interactive). In
+ *     this mode claude is launched with `--setting-sources project,local`, which
+ *     drops the user source and keeps `--settings` (measured on 2.1.289) — the
+ *     interactive launch and `claude -p` (Schedules, daily summary) alike.
+ *  3. **the CLI's `.env`.** A client in this mode reads no `.env` file at all and
+ *     refuses to fall back to port 3000: it dials only the `CM_PORT` the caller
+ *     exported.
+ *
+ * Unset (or any value other than `1` / `own-home`) changes nothing anywhere.
+ *
+ * ## `CM_UAT_ISOLATION=own-home` (Issue #3312)
+ *
+ * For a run under a dedicated OS user (the daily product-path check), whose
+ * HOME holds nobody else's CLI config. Everything above still holds — the
+ * launch is refused rather than started bare when hook setup fails, the
+ * receiver URL travels in the launch environment, headless `codex exec` /
+ * `agy -p` are refused, claude reads no user-level settings, the CLI reads no
+ * `.env` and never falls back to 3000 — with one difference: the shared hook
+ * files (codex's `hooks.json`, relay and trust, antigravity's and copilot's
+ * hook files, the claude settings under `CM_AGENT_HOOKS_DIR`) are WRITTEN by
+ * this build, instead of being reused read-only. Only after
+ * {@link assertUatOwnHomeWriteTargets} has checked, before each launch, that
+ * this process runs as `CM_UAT_DEDICATED_USER`, that HOME is that user's, and
+ * that every file it is about to write resolves (symlinks followed) to a place
+ * inside that HOME owned by that user. {@link sharedHookWritePolicy} is the one
+ * rule each tool's launch path calls.
+ *
+ * `docs/user-guide/uat-isolation.md` has the measurement table and the skip
+ * conditions for what cannot be isolated.
+ *
+ * @module config/uat-isolation
+ */
+var __importDefault = (this && this.__importDefault) || function (mod) {
+    return (mod && mod.__esModule) ? mod : { "default": mod };
+};
+Object.defineProperty(exports, "__esModule", { value: true });
+exports.UAT_OWN_HOME_FIX = exports.UAT_SAME_BUILD_FIX = exports.UatIsolationLaunchRefusedError = exports.CLAUDE_UAT_SETTING_SOURCES = exports.UAT_DEDICATED_USER_ENV_VAR = exports.UAT_ISOLATION_OWN_HOME = exports.UAT_ISOLATION_ENV_VAR = void 0;
+exports.getUatIsolationMode = getUatIsolationMode;
+exports.isUatIsolationEnabled = isUatIsolationEnabled;
+exports.checkUatOwnHomeWriteTargets = checkUatOwnHomeWriteTargets;
+exports.assertUatOwnHomeWriteTargets = assertUatOwnHomeWriteTargets;
+exports.sharedHookWritePolicy = sharedHookWritePolicy;
+const fs_1 = __importDefault(require("fs"));
+const os_1 = __importDefault(require("os"));
+const path_1 = __importDefault(require("path"));
+/** The switch. Only the exact values `1` and `own-home` turn it on. */
+exports.UAT_ISOLATION_ENV_VAR = 'CM_UAT_ISOLATION';
+/** The value of {@link UAT_ISOLATION_ENV_VAR} for a run under a dedicated OS user (Issue #3312). */
+exports.UAT_ISOLATION_OWN_HOME = 'own-home';
+/** The login name `own-home` must run as (Issue #3312). Compared with `os.userInfo().username`. */
+exports.UAT_DEDICATED_USER_ENV_VAR = 'CM_UAT_DEDICATED_USER';
+/**
+ * `--setting-sources` for a claude session in this mode: the user source
+ * (`$CLAUDE_CONFIG_DIR/settings.json`, hooks and plugins included) is dropped;
+ * the repository's own `project` / `local` settings and `--settings` stay.
+ */
+exports.CLAUDE_UAT_SETTING_SOURCES = 'project,local';
+/** Which isolation mode this process runs in. */
+function getUatIsolationMode(env = process.env) {
+    const value = env[exports.UAT_ISOLATION_ENV_VAR];
+    if (value === '1')
+        return 'shared-read-only';
+    if (value === exports.UAT_ISOLATION_OWN_HOME)
+        return 'own-home';
+    return 'off';
+}
+/**
+ * Whether this process runs in UAT isolation mode — `1` or `own-home`. Every
+ * protection except "never write the shared hook files" keys off this.
+ */
+function isUatIsolationEnabled(env = process.env) {
+    return getUatIsolationMode(env) !== 'off';
+}
+/**
+ * Thrown by a launch that would otherwise start an agent which reads a shared
+ * hook config this server did not (and in this mode may not) write.
+ *
+ * Starting the agent "without hooks" is not an option for codex, antigravity
+ * or copilot: the shared file is read regardless of what this server passes,
+ * so the production server's hooks — already trusted — would run in the UAT
+ * session and post to production. So the launch is refused, and the message says what
+ * makes it start.
+ */
+class UatIsolationLaunchRefusedError extends Error {
+    constructor(tool, reason, fix) {
+        super(getUatIsolationMode() === 'own-home'
+            ? `${exports.UAT_ISOLATION_ENV_VAR}=${exports.UAT_ISOLATION_OWN_HOME}: refusing to start ${tool}: ${reason}. ` +
+                `This server writes the hook config only inside the dedicated user's own HOME, and ${tool} ` +
+                `would otherwise start with hooks this server did not prepare. ${fix}`
+            : `${exports.UAT_ISOLATION_ENV_VAR}=1: refusing to start ${tool}: ${reason}. ` +
+                `This server does not write the shared hook config in UAT isolation, and ${tool} ` +
+                `would read it anyway and run the production hooks. ${fix}`);
+        this.name = 'UatIsolationLaunchRefusedError';
+    }
+}
+exports.UatIsolationLaunchRefusedError = UatIsolationLaunchRefusedError;
+/** The fix for a shared hook config that does not match this build. */
+exports.UAT_SAME_BUILD_FIX = 'Run the UAT with the same CommandMate build as the production server, so the shared file already matches what this build writes.';
+/** The fix for an `own-home` launch whose user, HOME or write targets did not check out. */
+exports.UAT_OWN_HOME_FIX = `Run ${exports.UAT_ISOLATION_ENV_VAR}=${exports.UAT_ISOLATION_OWN_HOME} as the user named by ${exports.UAT_DEDICATED_USER_ENV_VAR}, ` +
+    'with HOME set to that user\'s home and every hook config path (CODEX_HOME, CM_AGENT_HOOKS_DIR, ...) inside it.';
+function currentIdentity() {
+    const info = os_1.default.userInfo();
+    return { username: info.username, uid: info.uid, homedir: info.homedir };
+}
+/**
+ * Where a write to `target` would land, symlinks followed, and whose entry
+ * decides who may write there: the target itself when it exists, else its
+ * nearest existing ancestor (a file not yet created is judged by the directory
+ * it would be created in). A dangling symlink is refused: writing through it
+ * would create a file wherever it points.
+ */
+function resolveWriteTarget(target) {
+    const absolute = path_1.default.resolve(target);
+    let existing = absolute;
+    const rest = [];
+    for (;;) {
+        let entryExists = false;
+        try {
+            fs_1.default.lstatSync(existing);
+            entryExists = true;
+        }
+        catch {
+            entryExists = false;
+        }
+        if (entryExists)
+            break;
+        const parent = path_1.default.dirname(existing);
+        if (parent === existing)
+            return `${target} has no existing ancestor`;
+        rest.unshift(path_1.default.basename(existing));
+        existing = parent;
+    }
+    let real;
+    try {
+        real = fs_1.default.realpathSync(existing);
+    }
+    catch {
+        return `${existing} is a symlink that points nowhere`;
+    }
+    return { real: path_1.default.join(real, ...rest), owner: fs_1.default.statSync(real).uid };
+}
+/**
+ * Why an `own-home` launch may not write `writeTargets`, or null when it may
+ * (Issue #3312). Checks, in this order: `CM_UAT_DEDICATED_USER` is set and is
+ * the user this process runs as; `HOME` resolves to that user's home directory
+ * (from the account database) and is owned by them; each target resolves —
+ * every symlink on the way followed — to a path inside that home, and the entry
+ * that decides the write (the target, or its nearest existing ancestor) is
+ * owned by that user.
+ */
+function checkUatOwnHomeWriteTargets(writeTargets, env = process.env, identity = currentIdentity()) {
+    const dedicated = env[exports.UAT_DEDICATED_USER_ENV_VAR];
+    if (!dedicated)
+        return `${exports.UAT_DEDICATED_USER_ENV_VAR} is not set`;
+    if (identity.username !== dedicated) {
+        return `this process runs as ${identity.username}, not as the dedicated user ${dedicated}`;
+    }
+    const home = env.HOME;
+    if (!home || !path_1.default.isAbsolute(home))
+        return 'HOME is not set to an absolute path';
+    let homeReal;
+    let accountHomeReal;
+    try {
+        homeReal = fs_1.default.realpathSync(home);
+        accountHomeReal = fs_1.default.realpathSync(identity.homedir);
+    }
+    catch {
+        return `HOME (${home}) or ${dedicated}'s home directory (${identity.homedir}) does not exist`;
+    }
+    if (homeReal !== accountHomeReal) {
+        return `HOME (${home}) is not ${dedicated}'s home directory (${identity.homedir})`;
+    }
+    if (fs_1.default.statSync(homeReal).uid !== identity.uid)
+        return `HOME (${home}) is not owned by ${dedicated}`;
+    for (const target of writeTargets) {
+        const resolved = resolveWriteTarget(target);
+        if (typeof resolved === 'string')
+            return resolved;
+        if (resolved.real !== homeReal && !resolved.real.startsWith(`${homeReal}${path_1.default.sep}`)) {
+            return `${target} resolves to ${resolved.real}, outside ${dedicated}'s HOME (${homeReal})`;
+        }
+        if (resolved.owner !== identity.uid) {
+            return `${target} (${resolved.real}) is not owned by ${dedicated}`;
+        }
+    }
+    return null;
+}
+/**
+ * Under `own-home`, refuse the launch of `tool` unless
+ * {@link checkUatOwnHomeWriteTargets} passes for `writeTargets`. A no-op in
+ * every other mode.
+ *
+ * @throws {UatIsolationLaunchRefusedError}
+ */
+function assertUatOwnHomeWriteTargets(tool, writeTargets, env = process.env) {
+    if (getUatIsolationMode(env) !== 'own-home')
+        return;
+    const problem = checkUatOwnHomeWriteTargets(writeTargets, env);
+    if (problem)
+        throw new UatIsolationLaunchRefusedError(tool, problem, exports.UAT_OWN_HOME_FIX);
+}
+/**
+ * The one rule for a hook file shared with the user's other CommandMate
+ * servers (codex, antigravity and copilot call it; Issue #3312):
+ *
+ * - not isolated: `write`
+ * - `CM_UAT_ISOLATION=1`: `read-only` — reuse it only when it already matches
+ * - `CM_UAT_ISOLATION=own-home`: `write`, once
+ *   {@link assertUatOwnHomeWriteTargets} has passed for every path the write
+ *   touches; otherwise the launch is refused
+ *
+ * @throws {UatIsolationLaunchRefusedError} Under `own-home` only
+ */
+function sharedHookWritePolicy(tool, writeTargets, env = process.env) {
+    const mode = getUatIsolationMode(env);
+    if (mode === 'shared-read-only')
+        return 'read-only';
+    assertUatOwnHomeWriteTargets(tool, writeTargets, env);
+    return 'write';
+}

package/dist/server/src/lib/assistant-response-saver.js

@@ -53,6 +53,7 @@ var __importStar = (this && this.__importStar) || (function () {
 })();
 Object.defineProperty(exports, "__esModule", { value: true });
 exports.detectBufferReset = detectBufferReset;
+exports.isCodexCursorAtOrBelowComposer = isCodexCursorAtOrBelowComposer;
 exports.cleanCliResponse = cleanCliResponse;
 exports.advanceCapturedLineForTranscriptTurn = advanceCapturedLineForTranscriptTurn;
 exports.savePendingAssistantResponse = savePendingAssistantResponse;
@@ -62,6 +63,7 @@ const ws_server_1 = require("./ws-server");
 // Issue #571 [DR1-05]: Import directly from response-cleaner instead of barrel re-export
 const response_cleaner_1 = require("./response-cleaner");
 const types_1 = require("./cli-tools/types");
+const cli_patterns_1 = require("./detection/cli-patterns");
 const logger_1 = require("../lib/logger");
 const logger = (0, logger_1.createLogger)('assistant-response-saver');
 /**
@@ -141,6 +143,36 @@ function countCapturedLines(output) {
     }
     return trimmedLength;
 }
+/**
+ * Does a codex cursor start at or below the composer? (Issue #3335)
+ *
+ * Nothing at or below codex's composer is a reply: it is the composer, the
+ * status bar and `? for shortcuts`. On the inline layout (0.15x) a cursor
+ * rarely lands there, because the next turn is printed over the composer band
+ * and the composer moves down. On 0.160.0 it is where the cursor always is.
+ *
+ * codex 0.160.0 draws in the alternate screen: the capture is the pane, 1000
+ * rows, whatever the transcript holds, with the composer pinned to row 996.
+ * The row count this module stores is therefore NOT a read cursor for it — it
+ * settles at 999 or 1000 after the first read (here, or in
+ * {@link advanceCapturedLineForTranscriptTurn}) and never grows again, and
+ * the reply is drawn above it. The screen read does not take codex's reply
+ * from such a pane; the reply reaches History from codex's own transcript
+ * (`hooks/sources/codex/history.ts`). What this rule stops is the flush
+ * saving the chrome past the parked cursor as the reply — before #3335 a
+ * cursor of 999 saved `? for shortcuts`, and 997 or 998 the status bar.
+ *
+ * The composer is located by its SGR attributes (#2310), on the whole pane.
+ * A pane it cannot be found on keeps the reading it had.
+ *
+ * @param lines - The whole capture, ANSI intact
+ * @param cursor - The row the flush would start reading at
+ * @returns True when the rows from `cursor` down are all codex chrome
+ */
+function isCodexCursorAtOrBelowComposer(lines, cursor) {
+    const chromeStart = (0, cli_patterns_1.findCodexChromeStart)(lines);
+    return chromeStart >= 0 && cursor >= chromeStart;
+}
 /**
  * Time offset (in milliseconds) for assistant message timestamp
  * Ensures assistant response appears before user message in chronological order
@@ -167,9 +199,12 @@ const ASSISTANT_TIMESTAMP_OFFSET_MS = 1;
  *
  * @param output - Raw output from CLI tool
  * @param cliToolId - CLI tool identifier
+ * @param paneLines - The whole capture `output` was sliced from, for the
+ *   startup-screen rule of {@link cleanScrollbackResponse} (Issue #3293). Only
+ *   that cleaner reads it; omitted, no tool's cleaning changes
  * @returns Cleaned response content
  */
-function cleanCliResponse(output, cliToolId) {
+function cleanCliResponse(output, cliToolId, paneLines) {
     switch (cliToolId) {
         case 'claude':
             return (0, response_cleaner_1.cleanClaudeResponse)(output);
@@ -183,7 +218,7 @@ function cleanCliResponse(output, cliToolId) {
         case 'command-code':
         case 'antigravity':
         case 'vibe-local':
-            return (0, response_cleaner_1.cleanScrollbackResponse)(output, cliToolId);
+            return (0, response_cleaner_1.cleanScrollbackResponse)(output, cliToolId, paneLines);
         default:
             return output.trim();
     }
@@ -362,7 +397,31 @@ async function savePendingAssistantResponse(db, worktreeId, cliToolId, userMessa
         // 8. Clean the response.
         // Only scrollback-rendering tools reach this point (Issue #1292), so the
         // tool-specific cleaners in cleanCliResponse cover every remaining case.
-        const cleanedResponse = cleanCliResponse(newOutput, cliToolId);
+        //
+        // Issue #3293: the pane goes with the rows. On the first send of a session
+        // the cursor is 0 and "everything past it" is the tool's startup screen —
+        // measured on vibe-local as `response:saved {"fromLine":0,"toLine":1001}`
+        // 30 ms after `started-vibe-local-session`, and on codex as an assistant
+        // row holding the version, the cwd and the logo. A pane no message has been
+        // echoed on yet holds no reply, and that is a fact about the pane: the rows
+        // past the cursor ordinarily carry no echo either. It cleans to '', so the
+        // branch below moves the cursor exactly as the banner save used to.
+        //
+        // Not on a capture that came back at the size it was asked for: the window
+        // has clipped it, and the echo of a turn longer than the window is no longer
+        // in it. This is `isCaptureWindowSaturated` (#1670) against this module's
+        // own window, written out because `lib/tmux` is not imported from here
+        // (#1922).
+        const captureClipped = lines.length >= SESSION_OUTPUT_BUFFER_SIZE;
+        //
+        // Issue #3335: on codex, rows from the composer down are chrome, never a
+        // reply — and on 0.160.0 (alternate screen) that is where the cursor
+        // parks for the life of the session. Read as nothing, so the branch below
+        // moves the cursor as an empty clean would. See isCodexCursorAtOrBelowComposer.
+        const pastCodexComposer = cliToolId === 'codex' && isCodexCursorAtOrBelowComposer(lines, effectiveLastCapturedLine);
+        const cleanedResponse = pastCodexComposer
+            ? ''
+            : cleanCliResponse(newOutput, cliToolId, captureClipped ? undefined : lines);
         // 9. Check if cleaned response is empty
         if (!cleanedResponse || cleanedResponse.trim() === '') {
             // Output exists but cleaned to empty - update position but don't save

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

@@ -0,0 +1,139 @@
+"use strict";
+/**
+ * When Auto-Yes state is released, decided in one table (Issue #3184).
+ *
+ * Auto-Yes lives per worktree x instance with its own expiry, independent of
+ * the session it answers for. Every path that ends that relationship — a killed
+ * session (#3182), a removed instance, a deleted worktree, the orphan sweep,
+ * a poller giving up on errors, server shutdown — used to decide for itself
+ * what to do with the state, and one of them (instance removal) decided
+ * nothing at all, leaving a grant that silently approved the next session to
+ * claim the id. {@link AUTO_YES_LIFECYCLE} is the decision; each path calls
+ * {@link releaseAutoYes} (or its two halves) with the event it is.
+ *
+ * ## disable vs delete
+ *
+ * - `disable` keeps the entry with `enabled: false` (and the `stopReason`), for
+ *   an instance that still exists — the UI can say why Auto-Yes went off.
+ * - `delete` drops the entry, for an instance or worktree that no longer
+ *   exists. Kept, it would never be swept: the orphan sweep works per worktree.
+ *
+ * ## Not in the table
+ *
+ * Manual disable, expiry and the stop pattern are Auto-Yes's own conditions,
+ * not lifecycle events, and stay in `auto-yes-state` / the auto-yes route. A
+ * worktree ID rename MOVES the state (`worktree-session-reconcile`) rather than
+ * releasing it. The "starting" record (#3179) is cleared by kill-session beside
+ * this call, not by it: it has its own token rules (#3195).
+ *
+ * ## Imports go through the auto-yes-manager barrel
+ *
+ * The cleanup modules' tests mock `@/lib/polling/auto-yes-manager`, and so must
+ * this module's imports resolve to it. That barrel re-exports the poller, so
+ * `auto-yes-poller` must NOT import this module (it would be a cycle); its
+ * consecutive-errors path applies the same row directly, and
+ * `tests/unit/lib/auto-yes-lifecycle-3184.test.ts` holds the two equal.
+ *
+ * @module lib/auto-yes-lifecycle
+ */
+Object.defineProperty(exports, "__esModule", { value: true });
+exports.AUTO_YES_LIFECYCLE = void 0;
+exports.stopAutoYesPollersFor = stopAutoYesPollersFor;
+exports.applyAutoYesStateRule = applyAutoYesStateRule;
+exports.releaseAutoYes = releaseAutoYes;
+const auto_yes_manager_1 = require("./polling/auto-yes-manager");
+/**
+ * The table (design §8.2).
+ *
+ * `session-killed` is #3182's decision as #3188 shipped it: disable with no
+ * reason (no new reason was added), for the instance only. `server-shutdown`
+ * deliberately does not persist anything: the state lives in memory, and a
+ * restarted server starting with every grant off is the safe side.
+ *
+ * `consecutive-errors` is for real capture failures only: a session that
+ * exists but cannot be read. A session that does not exist (not started yet,
+ * or not started at all) is not one — the poller waits for it until
+ * `expiresAt`, at the backoff cap (Issue #3329), since the grant is
+ * independent of the session.
+ */
+exports.AUTO_YES_LIFECYCLE = {
+    'session-killed': { state: 'disable', poller: 'stop' },
+    'instance-removed': { state: 'delete', poller: 'stop' },
+    'worktree-deleted': { state: 'delete', poller: 'stop' },
+    'orphan-swept': { state: 'delete', poller: 'stop' },
+    'consecutive-errors': { state: 'disable', stopReason: 'consecutive_errors', poller: 'stop' },
+    'server-shutdown': { state: 'none', poller: 'stop' },
+};
+/**
+ * Stop the pollers the event's target names (the poller half of the table).
+ * Separate from {@link applyAutoYesStateRule} so a caller that reports the two
+ * failures apart (`session-cleanup`) can keep doing so.
+ */
+function stopAutoYesPollersFor(event, target) {
+    if (exports.AUTO_YES_LIFECYCLE[event].poller !== 'stop')
+        return;
+    switch (target.scope) {
+        case 'instance':
+            (0, auto_yes_manager_1.stopAutoYesPolling)((0, auto_yes_manager_1.buildCompositeKey)(target.worktreeId, target.cliToolId, target.instanceId));
+            return;
+        case 'worktree':
+            (0, auto_yes_manager_1.stopAutoYesPollingByWorktree)(target.worktreeId);
+            return;
+        case 'key':
+            (0, auto_yes_manager_1.stopAutoYesPolling)(target.compositeKey);
+            return;
+        case 'all':
+            (0, auto_yes_manager_1.stopAllAutoYesPolling)();
+            return;
+    }
+}
+function disableKey(compositeKey, stopReason) {
+    const cliToolId = (0, auto_yes_manager_1.extractCliToolId)(compositeKey);
+    if (!cliToolId)
+        return;
+    (0, auto_yes_manager_1.disableAutoYes)((0, auto_yes_manager_1.extractWorktreeId)(compositeKey), cliToolId, stopReason, (0, auto_yes_manager_1.extractInstanceId)(compositeKey) ?? undefined);
+}
+/** Apply the event's state rule to its target (the state half of the table). */
+function applyAutoYesStateRule(event, target) {
+    const rule = exports.AUTO_YES_LIFECYCLE[event];
+    if (rule.state === 'none')
+        return;
+    switch (target.scope) {
+        case 'instance':
+            if (rule.state === 'disable') {
+                (0, auto_yes_manager_1.disableAutoYes)(target.worktreeId, target.cliToolId, rule.stopReason, target.instanceId);
+            }
+            else {
+                (0, auto_yes_manager_1.deleteAutoYesState)((0, auto_yes_manager_1.buildCompositeKey)(target.worktreeId, target.cliToolId, target.instanceId));
+            }
+            return;
+        case 'worktree':
+            if (rule.state === 'disable') {
+                (0, auto_yes_manager_1.getCompositeKeysByWorktree)(target.worktreeId).forEach((key) => disableKey(key, rule.stopReason));
+            }
+            else {
+                (0, auto_yes_manager_1.deleteAutoYesStateByWorktree)(target.worktreeId);
+            }
+            return;
+        case 'key':
+            if (rule.state === 'disable') {
+                disableKey(target.compositeKey, rule.stopReason);
+            }
+            else {
+                (0, auto_yes_manager_1.deleteAutoYesState)(target.compositeKey);
+            }
+            return;
+        case 'all':
+            (0, auto_yes_manager_1.getAutoYesStateCompositeKeys)().forEach((key) => rule.state === 'disable' ? disableKey(key, rule.stopReason) : (0, auto_yes_manager_1.deleteAutoYesState)(key));
+            return;
+    }
+}
+/**
+ * Release Auto-Yes for an event: stop the pollers first, then apply the state
+ * rule — the order `session-cleanup` has kept since #404. Both halves are
+ * synchronous, so no poll can run between them.
+ */
+function releaseAutoYes(event, target) {
+    stopAutoYesPollersFor(event, target);
+    applyAutoYesStateRule(event, target);
+}