commandmate 0.16.0 → 0.17.0

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

@@ -0,0 +1,117 @@
+"use strict";
+/**
+ * Auto-Yes policy lookup — resolves the `autoYes` block of the execution
+ * contract governing one agent instance (Issue #1547).
+ *
+ * Server-only: reads the database. Kept out of auto-yes-state.ts so that module
+ * stays free of a database dependency, and out of auto-yes-resolver.ts because
+ * that one is bundled into the client.
+ *
+ * The result is cached per composite key with a short TTL. Without it, a prompt
+ * the policy suppresses would be re-read from SQLite on every poll for as long
+ * as it stays on screen: the poller's duplicate guard only remembers prompts it
+ * *answered*, so a suppressed prompt is re-evaluated every POLLING_INTERVAL_MS
+ * indefinitely. The TTL is what bounds staleness — a task that starts or ends is
+ * picked up within it, without this module having to observe task transitions.
+ *
+ * @module lib/polling/auto-yes-policy
+ */
+Object.defineProperty(exports, "__esModule", { value: true });
+exports.AUTO_YES_POLICY_CACHE_TTL_MS = void 0;
+exports.getSessionAutoYesPolicy = getSessionAutoYesPolicy;
+exports.invalidateSessionAutoYesPolicy = invalidateSessionAutoYesPolicy;
+exports.clearAutoYesPolicyCache = clearAutoYesPolicyCache;
+const db_1 = require("../../lib/db");
+const db_instance_1 = require("../../lib/db/db-instance");
+const auto_yes_state_1 = require("../../lib/auto-yes-state");
+const logger_1 = require("../../lib/logger");
+const logger = (0, logger_1.createLogger)('auto-yes-policy');
+/** How long a resolved policy is reused before the task is looked up again. */
+exports.AUTO_YES_POLICY_CACHE_TTL_MS = 5000;
+/**
+ * Cache ceiling. Above it, expired entries are dropped on write, so a long-lived
+ * server cannot accumulate one entry per worktree ever polled.
+ */
+const MAX_CACHE_ENTRIES = 200;
+/**
+ * Plain module-level Map rather than the globalThis pattern used for auto-yes
+ * *state*: losing a cache on hot reload costs one database read, while losing
+ * state would silently disable auto-yes.
+ */
+const policyCache = new Map();
+function purgeExpired(now) {
+    for (const [key, entry] of policyCache.entries()) {
+        if (entry.expiresAt <= now) {
+            policyCache.delete(key);
+        }
+    }
+}
+/**
+ * Read the policy from the active task, or null when no contract governs this
+ * instance.
+ *
+ * A database failure yields null — the unconstrained behaviour. Failing closed
+ * here would suppress auto-yes for every user who has no contract at all, which
+ * is the population this feature must not touch; the suppressing decisions
+ * (`off`, deny patterns) are made inside the resolver only once a contract has
+ * actually been read.
+ */
+function readPolicy(worktreeId, cliToolId, instanceId) {
+    try {
+        const task = (0, db_1.getActiveTaskForInstance)((0, db_instance_1.getDbInstance)(), worktreeId, cliToolId, instanceId);
+        if (!task)
+            return null;
+        // Assignment, not a cast: a drift in TaskContractAutoYes fails the build here.
+        const policy = task.contract.autoYes;
+        return policy;
+    }
+    catch (error) {
+        logger.warn('policy-lookup-failed', {
+            worktreeId,
+            cliToolId,
+            instanceId,
+            error: error instanceof Error ? error.message : String(error),
+        });
+        return null;
+    }
+}
+/**
+ * The auto-answer policy for an agent instance, cached for
+ * {@link AUTO_YES_POLICY_CACHE_TTL_MS}.
+ *
+ * @param worktreeId - Worktree identifier
+ * @param cliToolId - CLI tool being polled
+ * @param instanceId - Agent instance id (defaults to the primary, i.e. cliToolId)
+ * @returns The contract's autoYes block, or null when no contract governs this instance
+ */
+function getSessionAutoYesPolicy(worktreeId, cliToolId, instanceId) {
+    const resolvedInstanceId = instanceId ?? cliToolId;
+    const key = (0, auto_yes_state_1.buildCompositeKey)(worktreeId, cliToolId, resolvedInstanceId);
+    const now = Date.now();
+    const cached = policyCache.get(key);
+    if (cached && cached.expiresAt > now) {
+        return cached.policy;
+    }
+    const policy = readPolicy(worktreeId, cliToolId, resolvedInstanceId);
+    if (policyCache.size >= MAX_CACHE_ENTRIES) {
+        purgeExpired(now);
+    }
+    policyCache.set(key, { policy, expiresAt: now + exports.AUTO_YES_POLICY_CACHE_TTL_MS });
+    return policy;
+}
+/**
+ * Drop the cached policy for a composite key, so the next lookup re-reads the
+ * task. Called when a poller starts or stops.
+ *
+ * @param compositeKey - Composite key (worktreeId:cliToolId[:instanceId])
+ */
+function invalidateSessionAutoYesPolicy(compositeKey) {
+    policyCache.delete(compositeKey);
+}
+/**
+ * Clear the whole cache.
+ * @internal Exported for testing and worktree teardown.
+ */
+function clearAutoYesPolicyCache() {
+    policyCache.clear();
+}

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

@@ -2,20 +2,44 @@
 /**
  * Auto Yes Resolver - Determines automatic answer for prompt data
  *
- * Rules:
+ * Base rules (unchanged since Issue #479):
  * - yes/no prompt -> 'y'
  * - multiple_choice with default option -> default option number
  * - multiple_choice without default -> first option number
  * - option requiring text input -> null (skip)
  * - unknown type -> null (skip)
+ *
+ * Issue #1547: an optional {@link AutoYesPolicy} — the `autoYes` block of an
+ * execution contract — can withhold an answer the base rules would have sent.
+ * The policy can only ever suppress: it never turns a null into an answer, and
+ * omitting it (or passing one that states nothing) reproduces the pre-#1547
+ * behaviour exactly, which is what keeps contract-less operation untouched.
+ *
+ * Client-safe: no server-only imports, because a 'use client' hook
+ * (`hooks/useAutoYes.ts`) imports this module.
  */
 Object.defineProperty(exports, "__esModule", { value: true });
+exports.MAX_DENY_MATCH_TEXT_LENGTH = exports.MAX_DENY_PATTERN_LENGTH = void 0;
+exports.resolveAutoAnswerWithPolicy = resolveAutoAnswerWithPolicy;
 exports.resolveAutoAnswer = resolveAutoAnswer;
+const auto_yes_config_1 = require("../../config/auto-yes-config");
 /**
- * Resolve the automatic answer for a given prompt
- * @returns The answer string to send, or null if auto-answer is not possible
+ * Upper bound on a deny pattern, mirroring MAX_PATTERN_LENGTH in
+ * lib/tasks/contract-parser (asserted equal by the unit tests). Contracts are
+ * validated on load, so this is defence in depth for a contract snapshot that
+ * reached the database some other way.
+ */
+exports.MAX_DENY_PATTERN_LENGTH = 200;
+/**
+ * Upper bound on the text a deny pattern is matched against, per field.
+ *
+ * A prompt question or option label is a few hundred characters; the bound only
+ * exists so a pathological pane cannot make every poll scan megabytes with 32
+ * patterns. Matching is over the head of the field, deterministically.
  */
-function resolveAutoAnswer(promptData) {
+exports.MAX_DENY_MATCH_TEXT_LENGTH = 20_000;
+/** The pre-policy resolution: the rules as they were before Issue #1547. */
+function resolveBaseAnswer(promptData) {
     if (promptData.type === 'yes_no') {
         return 'y';
     }
@@ -32,3 +56,119 @@ function resolveAutoAnswer(promptData) {
     }
     return null;
 }
+/**
+ * Every piece of prompt text a deny pattern is matched against.
+ *
+ * `instructionText` is included because that is where the dangerous part
+ * usually is — Claude's permission prompts put the command being approved in the
+ * lines above the question, not in the question itself.
+ */
+function collectDenyMatchTexts(promptData) {
+    const texts = [promptData.question];
+    if (promptData.instructionText) {
+        texts.push(promptData.instructionText);
+    }
+    if (promptData.type === 'multiple_choice') {
+        for (const option of promptData.options) {
+            texts.push(option.label);
+        }
+    }
+    else {
+        texts.push(...promptData.options);
+    }
+    return texts.map(text => text.length > exports.MAX_DENY_MATCH_TEXT_LENGTH ? text.slice(0, exports.MAX_DENY_MATCH_TEXT_LENGTH) : text);
+}
+/**
+ * Test the prompt against every deny pattern.
+ *
+ * Patterns are screened by {@link validateStopPattern} (length, safe-regex2
+ * catastrophic-backtracking detection, syntax) before execution, which is the
+ * same ReDoS defence the stop-pattern path uses. A pattern that fails screening
+ * — or whose execution throws — is reported as `unusable`, not skipped.
+ */
+function evaluateDenyPatterns(promptData, patterns) {
+    if (patterns.length === 0) {
+        return { outcome: 'no-match' };
+    }
+    const texts = collectDenyMatchTexts(promptData);
+    for (const pattern of patterns) {
+        if (pattern.length > exports.MAX_DENY_PATTERN_LENGTH || !(0, auto_yes_config_1.validateStopPattern)(pattern).valid) {
+            return { outcome: 'unusable', pattern };
+        }
+        const regex = new RegExp(pattern);
+        for (const text of texts) {
+            const matched = (0, auto_yes_config_1.executeRegexWithTimeout)(regex, text);
+            if (matched === null) {
+                return { outcome: 'unusable', pattern };
+            }
+            if (matched) {
+                return { outcome: 'match', pattern };
+            }
+        }
+    }
+    return { outcome: 'no-match' };
+}
+/**
+ * Decide whether the policy forbids answering this prompt.
+ *
+ * Deny patterns are honoured even when `mode` is null: a contract that lists
+ * them has stated a policy, and a listed pattern that quietly did nothing is the
+ * worst failure a contract can have. `mode` null with no deny patterns — what
+ * the parser produces for a contract with no `autoYes` block — reaches none of
+ * these branches and leaves behaviour identical.
+ */
+function evaluatePolicy(promptData, policy) {
+    if (!policy)
+        return null;
+    if (policy.mode === 'off') {
+        return { reason: 'mode-off' };
+    }
+    const deny = evaluateDenyPatterns(promptData, policy.denyPatterns);
+    if (deny.outcome === 'match') {
+        return { reason: 'deny-pattern', pattern: deny.pattern };
+    }
+    if (deny.outcome === 'unusable') {
+        return { reason: 'deny-pattern-unusable', pattern: deny.pattern };
+    }
+    if (policy.mode === 'safe') {
+        return promptData.type === 'yes_no' ? null : { reason: 'type-not-allowed' };
+    }
+    if (policy.mode === 'allow-listed') {
+        return policy.allowPromptTypes.includes(promptData.type)
+            ? null
+            : { reason: 'type-not-allowed' };
+    }
+    return null;
+}
+/**
+ * Resolve the automatic answer, reporting whether a policy withheld it.
+ *
+ * `suppressedBy` is set only when an answer was actually withheld, so the
+ * escalation log records real suppressions and not prompts the base rules were
+ * never going to answer anyway (an empty option list, an option that needs
+ * typing). Those still resolve to null, with `suppressedBy` null.
+ *
+ * @param promptData - Detected prompt
+ * @param policy - Contract auto-answer policy; omit for the unconstrained behaviour
+ */
+function resolveAutoAnswerWithPolicy(promptData, policy) {
+    const answer = resolveBaseAnswer(promptData);
+    if (answer === null) {
+        return { answer: null, suppressedBy: null };
+    }
+    const denial = evaluatePolicy(promptData, policy);
+    if (denial) {
+        return { answer: null, suppressedBy: denial.reason, pattern: denial.pattern };
+    }
+    return { answer, suppressedBy: null };
+}
+/**
+ * Resolve the automatic answer for a given prompt.
+ *
+ * @param promptData - Detected prompt
+ * @param policy - Contract auto-answer policy; omit for the unconstrained behaviour
+ * @returns The answer string to send, or null if auto-answer is not possible
+ */
+function resolveAutoAnswer(promptData, policy) {
+    return resolveAutoAnswerWithPolicy(promptData, policy).answer;
+}

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

@@ -27,6 +27,7 @@ const prompt_dedup_1 = require("./prompt-dedup");
 const response_dedup_1 = require("./response-dedup");
 const response_poller_core_1 = require("./response-poller-core");
 const push_1 = require("../../lib/push");
+const task_transition_service_1 = require("../../lib/tasks/task-transition-service");
 /**
  * Creates an incomplete extraction result with empty response.
  * Centralizes the repeated pattern of returning an in-progress/incomplete state.
@@ -420,6 +421,13 @@ async function checkForResponse(worktreeId, cliToolId, instanceId) {
             });
             (0, db_1.updateSessionState)(db, worktreeId, cliToolId, result.lineCount, resolvedInstanceId);
             (0, ws_server_1.broadcastMessage)('message', { worktreeId, message });
+            // Issue #1548: the agent is blocked on input. Raised after the dedup and
+            // save above, so the task log counts prompts the system actually recorded
+            // rather than every poll that saw the same one still on screen. No-ops
+            // when this instance is not running a contract.
+            (0, task_transition_service_1.applyEventToActiveTask)(db, worktreeId, cliToolId, resolvedInstanceId, 'prompt_detected', {
+                promptType: promptDetection.promptData?.type,
+            });
             // Web Push fan-out (Issue #1125): agent is now waiting for a prompt reply.
             // Fire-and-forget — push is advisory and must never block/break the poller.
             void (0, push_1.notifyPushSubscribers)({

package/dist/server/src/lib/session/agent-event-state.js

@@ -0,0 +1,46 @@
+"use strict";
+/**
+ * In-memory record of the last structured "the agent stopped" event (#1549).
+ *
+ * The agent CLI telling us it stopped is a different kind of fact from the
+ * screen-scraped status: it is exact, but it only exists when someone wired a
+ * hook up. So this is kept beside the detector's output rather than folded into
+ * it — `buildCurrentOutput` exposes the timestamp, and nothing in the completion
+ * decision reads it yet. Phase 3-2 is deliberately observation only; swapping
+ * the wait/poller verdict from string matching to hook events before there is
+ * field data on how often hooks actually fire would trade a known failure mode
+ * for an unknown one.
+ *
+ * In-memory and not in SQLite for the same reason `auto-yes-state` is: the value
+ * describes a live tmux session, and a session does not survive a server restart
+ * for the timestamp to still be about.
+ *
+ * @module lib/session/agent-event-state
+ */
+Object.defineProperty(exports, "__esModule", { value: true });
+exports.recordAgentStopEvent = recordAgentStopEvent;
+exports.getLastStopEventAt = getLastStopEventAt;
+exports.clearAgentStopEvents = clearAgentStopEvents;
+const auto_yes_state_1 = require("../../lib/auto-yes-state");
+/** compositeKey -> epoch ms of the most recent stop event. */
+const lastStopEventAt = new Map();
+/**
+ * Record that `instanceId` reported it stopped.
+ *
+ * @param at - Epoch ms; defaults to now. Passed explicitly by callers that need
+ *   the stored value and their own record of the event to agree exactly.
+ */
+function recordAgentStopEvent(worktreeId, cliToolId, instanceId, at = Date.now()) {
+    lastStopEventAt.set((0, auto_yes_state_1.buildCompositeKey)(worktreeId, cliToolId, instanceId), at);
+}
+/**
+ * @returns Epoch ms of the last stop event, or null when none has been received
+ *   — which is the ordinary case for a session whose agent has no hook set up.
+ */
+function getLastStopEventAt(worktreeId, cliToolId, instanceId) {
+    return lastStopEventAt.get((0, auto_yes_state_1.buildCompositeKey)(worktreeId, cliToolId, instanceId)) ?? null;
+}
+/** Drop every recorded event. Test seam. */
+function clearAgentStopEvents() {
+    lastStopEventAt.clear();
+}

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

@@ -15,6 +15,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 status_capture_config_1 = require("../../config/status-capture-config");
+const agent_event_state_1 = require("../../lib/session/agent-event-state");
 /**
  * Build the current-output payload for a worktree session.
  *
@@ -27,6 +28,7 @@ async function buildCurrentOutput(db, worktreeId, cliToolId, instanceId) {
     const resolvedInstanceId = instanceId ?? cliToolId;
     const manager = manager_1.CLIToolManager.getInstance();
     const cliTool = manager.getTool(cliToolId);
+    const stopEventAt = (0, agent_event_state_1.getLastStopEventAt)(worktreeId, cliToolId, instanceId);
     const running = await cliTool.isRunning(worktreeId, instanceId);
     if (!running) {
         return {
@@ -36,6 +38,7 @@ async function buildCurrentOutput(db, worktreeId, cliToolId, instanceId) {
             cliToolId,
             sessionStatus: 'idle',
             sessionStatusReason: 'session_not_running',
+            lastStopEventAt: stopEventAt,
         };
     }
     const sessionState = (0, db_1.getSessionState)(db, worktreeId, resolvedInstanceId);
@@ -91,5 +94,6 @@ async function buildCurrentOutput(db, worktreeId, cliToolId, instanceId) {
         isUnclassifiedActive,
         lastServerResponseTimestamp,
         serverPollerActive: (0, auto_yes_manager_1.isPollerActive)(compositeKey),
+        lastStopEventAt: stopEventAt,
     };
 }

package/dist/server/src/lib/session/status-mapping.js

@@ -0,0 +1,146 @@
+"use strict";
+/**
+ * Session status vocabulary mapping (Issue #1550).
+ *
+ * The same session reality is expressed in several vocabularies:
+ *
+ * | Vocabulary          | Defined in                          | Values                                    |
+ * |---------------------|-------------------------------------|-------------------------------------------|
+ * | `SessionStatus`     | `lib/detection/status-detector.ts`  | idle / ready / running / waiting          |
+ * | `BranchStatus`      | `types/sidebar.ts`                  | idle / ready / running / waiting / generating |
+ * | boolean triple      | `lib/session/worktree-status-helper.ts` | isRunning / isWaitingForResponse / isProcessing |
+ * | `UIPhase`           | `types/ui-state.ts`                 | idle / waiting / receiving / prompt / complete |
+ *
+ * This module is the single place where those vocabularies are converted into
+ * one another, so the correspondence cannot drift between call sites. It is a
+ * pure module (type-only imports) and is therefore safe to import from client
+ * components.
+ *
+ * ## The live conversion chain
+ *
+ *   terminal output
+ *     -> detectSessionStatus()                  (status-detector, NOT touched here)
+ *     -> SessionStatus
+ *     -> sessionStatusToActivityFlags()         (this module)
+ *     -> boolean triple (+ isRunning from tmux session existence)
+ *     -> deriveCliStatus()                      (this module)
+ *     -> BranchStatus                           (sidebar / header / tab dots)
+ *
+ * `deriveSessionStatus()` is the reverse edge of that chain: the worktrees API
+ * folds the boolean triple back into a `SessionStatus` for its JSON payload.
+ *
+ * ## Why `UIPhase` has no mapping function here
+ *
+ * `UIPhase` is a state machine, not a projection of `SessionStatus`: `waiting`
+ * -> `receiving` -> `complete` is a sequence driven by user sends and streamed
+ * output, and the same `SessionStatus` can legitimately correspond to several
+ * phases depending on history. The only edge that is a pure table lookup is
+ * "an active prompt was detected -> phase `prompt`", and that edge is already
+ * expressed exactly once, by the `SHOW_PROMPT` case of `worktreeUIReducer`
+ * (`hooks/useWorktreeUIState.ts`). Re-encoding it here would add an indirection
+ * with no second call site, so the reducer stays the single owner.
+ */
+Object.defineProperty(exports, "__esModule", { value: true });
+exports.sessionStatusToActivityFlags = sessionStatusToActivityFlags;
+exports.deriveCliStatus = deriveCliStatus;
+exports.deriveSessionStatus = deriveSessionStatus;
+exports.deriveBranchStatus = deriveBranchStatus;
+/**
+ * Project a detected `SessionStatus` onto the activity flags.
+ *
+ * `isRunning` is deliberately NOT derived here: it comes from tmux session
+ * existence (plus the Claude health check), which is independent of what the
+ * terminal output says.
+ *
+ * | SessionStatus | isWaitingForResponse | isProcessing |
+ * |---------------|----------------------|--------------|
+ * | `idle`        | false                | false        |
+ * | `ready`       | false                | false        |
+ * | `running`     | false                | true         |
+ * | `waiting`     | true                 | false        |
+ */
+function sessionStatusToActivityFlags(status) {
+    switch (status) {
+        case 'waiting':
+            return { isWaitingForResponse: true, isProcessing: false };
+        case 'running':
+            return { isWaitingForResponse: false, isProcessing: true };
+        case 'idle':
+        case 'ready':
+            return { isWaitingForResponse: false, isProcessing: false };
+        default:
+            // exhaustive check: SessionStatus extensions cause a compile error [DR2-005]
+            status;
+            return { isWaitingForResponse: false, isProcessing: false };
+    }
+}
+/**
+ * Derive `BranchStatus` from one session's boolean triple.
+ *
+ * Shared by the sidebar (`toBranchItem`), the worktree detail tab dots, the
+ * desktop header status row, Sessions and Review.
+ *
+ * Precedence is waiting > running > ready > idle: a session that is both
+ * waiting for an answer and processing is shown as `waiting`, because the user
+ * action it needs is the more significant fact.
+ *
+ * Note that `generating` is never produced here — it exists in `BranchStatus`
+ * but has no boolean-triple source. Resolving that asymmetry is out of scope
+ * for Issue #1550 (this issue only moves the conversions to one place).
+ */
+function deriveCliStatus(toolStatus) {
+    if (!toolStatus)
+        return 'idle';
+    if (toolStatus.isWaitingForResponse)
+        return 'waiting';
+    if (toolStatus.isProcessing)
+        return 'running';
+    if (toolStatus.isRunning)
+        return 'ready';
+    return 'idle';
+}
+/**
+ * Fold a worktree-level boolean triple back into a `SessionStatus` for the
+ * worktrees API payload — the reverse edge of `sessionStatusToActivityFlags`.
+ *
+ * Returns `null` (not `'idle'`) when no session is running, because the API
+ * contract distinguishes "no session" from "a session that reports idle".
+ */
+function deriveSessionStatus(status) {
+    if (!status.isSessionRunning)
+        return null;
+    if (status.isWaitingForResponse)
+        return 'waiting';
+    if (status.isProcessing)
+        return 'running';
+    return 'ready';
+}
+/**
+ * The `SessionStatus` -> `BranchStatus` correspondence, as one table.
+ *
+ * Composed from the two conversions the live chain actually uses, so it can
+ * never drift from them.
+ *
+ * | isRunning | SessionStatus | BranchStatus |
+ * |-----------|---------------|--------------|
+ * | false     | (any / null)  | `idle`       |
+ * | true      | `null`        | `ready`      |
+ * | true      | `idle`        | `ready`      |
+ * | true      | `ready`       | `ready`      |
+ * | true      | `running`     | `running`    |
+ * | true      | `waiting`     | `waiting`    |
+ *
+ * The `idle` -> `ready` row is not a mistake: once a tmux session exists, the
+ * sidebar shows `ready` (the user can send a message) even while the detector
+ * still reports `idle` for the terminal contents.
+ */
+function deriveBranchStatus(sessionStatus, isRunning) {
+    if (!isRunning)
+        return 'idle';
+    return deriveCliStatus({
+        isRunning: true,
+        ...(sessionStatus
+            ? sessionStatusToActivityFlags(sessionStatus)
+            : { isWaitingForResponse: false, isProcessing: false }),
+    });
+}