@project-ava-supernova/core 0.2.71

package/dist/agent/intent-classifier.d.ts

@@ -0,0 +1,51 @@
+/**
+ * Intent Classifier — heuristic gate between user input and tool use.
+ *
+ * Runs once per user message (at the top of agent.run) and returns one
+ * of three labels. The result drives a "Style note" injected into the
+ * system prompt for that turn — conversational/ambiguous classifications
+ * nudge the model toward worded replies; task classifications leave
+ * tool-use posture unchanged.
+ *
+ * Why heuristic rather than LLM:
+ *   The previous implementation called Qwen Flash on every turn — ~50
+ *   tokens in, 1 token out, with a 2-second timeout. On the extension
+ *   surface that round-trip ran *before* stream_start fired, so users saw
+ *   a 0.5–2 second pause before Ava began thinking. The IDE sidecar
+ *   never wired the classifier and felt instant by comparison.
+ *
+ *   The classification task is binary-ish — most messages fall cleanly
+ *   into "verb-led imperative" or "short reaction / meta-question" with
+ *   no genuine ambiguity. A regex set captures the same signal at sub-
+ *   millisecond cost, runs identically on both surfaces, and removes the
+ *   only synchronous LLM hop on the per-turn hot path.
+ *
+ * Labels:
+ *   task          — user wants concrete action (code, commands, build)
+ *   conversational — user is talking, asking, reacting, giving feedback
+ *   ambiguous     — empty input only; everything else defaults to task
+ *                   (the LLM prompt's own rule: "When in doubt, classify
+ *                   task. A false 'task' on a chatty message wastes one
+ *                   turn; a false 'conversational' on a real task blocks
+ *                   tools and produces broken output.")
+ *
+ * Cost: 0 tokens, 0 RPCs. Same shape as the previous classifier — same
+ * call site, same async return type, same UserIntent labels — so the
+ * agent's intent-gate code at agent.ts is unchanged.
+ */
+import type { Provider } from '../providers/types.js';
+import type { ModelDefinition } from '../core/types.js';
+export type UserIntent = 'task' | 'conversational' | 'ambiguous';
+export interface IntentClassifierOptions {
+    /** Retained for API compatibility — the heuristic classifier ignores it. */
+    provider?: Provider;
+    /** Retained for API compatibility — the heuristic classifier ignores it. */
+    model?: ModelDefinition;
+    /** Retained for API compatibility — no network call to time out. */
+    timeoutMs?: number;
+}
+export declare class IntentClassifier {
+    constructor(_opts?: IntentClassifierOptions);
+    classify(userMessage: string): Promise<UserIntent>;
+}
+//# sourceMappingURL=intent-classifier.d.ts.map

package/dist/agent/intent-classifier.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"intent-classifier.d.ts","sourceRoot":"","sources":["../../src/agent/intent-classifier.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAkCG;AAEH,OAAO,KAAK,EAAE,QAAQ,EAAE,MAAM,uBAAuB,CAAC;AACtD,OAAO,KAAK,EAAE,eAAe,EAAE,MAAM,kBAAkB,CAAC;AAExD,MAAM,MAAM,UAAU,GAAG,MAAM,GAAG,gBAAgB,GAAG,WAAW,CAAC;AAEjE,MAAM,WAAW,uBAAuB;IACtC,4EAA4E;IAC5E,QAAQ,CAAC,EAAE,QAAQ,CAAC;IACpB,4EAA4E;IAC5E,KAAK,CAAC,EAAE,eAAe,CAAC;IACxB,oEAAoE;IACpE,SAAS,CAAC,EAAE,MAAM,CAAC;CACpB;AAsDD,qBAAa,gBAAgB;gBAGf,KAAK,GAAE,uBAA4B;IAOzC,QAAQ,CAAC,WAAW,EAAE,MAAM,GAAG,OAAO,CAAC,UAAU,CAAC;CAGzD"}

package/dist/agent/intent-classifier.js

@@ -0,0 +1,125 @@
+/**
+ * Intent Classifier — heuristic gate between user input and tool use.
+ *
+ * Runs once per user message (at the top of agent.run) and returns one
+ * of three labels. The result drives a "Style note" injected into the
+ * system prompt for that turn — conversational/ambiguous classifications
+ * nudge the model toward worded replies; task classifications leave
+ * tool-use posture unchanged.
+ *
+ * Why heuristic rather than LLM:
+ *   The previous implementation called Qwen Flash on every turn — ~50
+ *   tokens in, 1 token out, with a 2-second timeout. On the extension
+ *   surface that round-trip ran *before* stream_start fired, so users saw
+ *   a 0.5–2 second pause before Ava began thinking. The IDE sidecar
+ *   never wired the classifier and felt instant by comparison.
+ *
+ *   The classification task is binary-ish — most messages fall cleanly
+ *   into "verb-led imperative" or "short reaction / meta-question" with
+ *   no genuine ambiguity. A regex set captures the same signal at sub-
+ *   millisecond cost, runs identically on both surfaces, and removes the
+ *   only synchronous LLM hop on the per-turn hot path.
+ *
+ * Labels:
+ *   task          — user wants concrete action (code, commands, build)
+ *   conversational — user is talking, asking, reacting, giving feedback
+ *   ambiguous     — empty input only; everything else defaults to task
+ *                   (the LLM prompt's own rule: "When in doubt, classify
+ *                   task. A false 'task' on a chatty message wastes one
+ *                   turn; a false 'conversational' on a real task blocks
+ *                   tools and produces broken output.")
+ *
+ * Cost: 0 tokens, 0 RPCs. Same shape as the previous classifier — same
+ * call site, same async return type, same UserIntent labels — so the
+ * agent's intent-gate code at agent.ts is unchanged.
+ */
+// Pure reactions, fillers, meta-questions, continuation prompts, and
+// feedback on prior work. Each pattern is anchored or scoped tightly so
+// it doesn't catch verb-led imperatives that happen to start with the
+// same word ("ok fix this" → not conversational; "ok" alone → is).
+const CONVERSATIONAL_PATTERNS = [
+    // Standalone reactions / fillers
+    /^(really\??|wow|ok|okay|alright|cool|nice|sure|fine|got it)\W*$/i,
+    /^(hi|hello|hey|yo|sup|howdy)\b\W*$/i,
+    /^(thanks?|thank you|thx|ty|cheers|appreciated)\W*$/i,
+    /^(no thanks?|nah|yeah|yep|yes|nope|nvm|never ?mind)\W*$/i,
+    /^(hmm+|huh\??|oh\W?|ah+|aha|haha+|lol)\W*$/i,
+    // Meta-questions about the agent itself
+    /\bwhat (do|are|did) you think\b/i,
+    /\bwhat'?s your (take|opinion|view|sense)\b/i,
+    /\bwho are you\b/i,
+    /\bare you (sure|ok|okay|alright|there)\b/i,
+    // Continuation prompts
+    /^(go on|go ahead|continue|carry on|keep going|tell me more)\W*$/i,
+    // Reactions to prior work
+    /^(you('?re| are)\s+(right|wrong|correct))\b/i,
+    /^(that('?s| is)\s+(right|wrong|good|bad|cool|nice|fine|ok|okay|perfect|great))\b/i,
+];
+// Imperative verbs that strongly imply concrete action on files / commands /
+// the project. The set mirrors the examples block of the prior LLM prompt.
+const TASK_VERBS = '(fix|build|run|test|deploy|ship|create|add|remove|delete|edit|update|modify|refactor|investigate|audit|review|analy[sz]e|check|scan|find|debug|implement|write|make|install|rename|move|generate|search|inspect|explore|assess|spot|lint|format|migrate|patch|fork|clone|init|setup|configure|wire|hook|expose|merge|rebase|commit|push|pull|stash|revert|bump|publish|release)';
+// Common preambles users put in front of a task verb. Matching against
+// this set lets "can you fix the bug" classify as task while keeping
+// short polite responses ("could you?", "please") from doing so.
+const TASK_VERB_AT_START = new RegExp(`^(can you |could you |would you |please |let'?s |let us |i (need|want) you to |i'?d like you to )?${TASK_VERBS}\\b`, 'i');
+const TASK_AS_INFINITIVE = new RegExp(`\\b(want to|need to|trying to|going to|gonna|let'?s|help me|gotta) ${TASK_VERBS}\\b`, 'i');
+// "Look at" / "take a look" / "peek at" — investigative task verbs not
+// covered by the simple verb list above because they're phrasal.
+const LOOK_AT_PATTERN = /\b(look (at|into)|take a (look|peek)|have a look|peek at|dig into)\b/i;
+// Code-context phrases that disambiguate borderline cases toward task.
+const CODE_CONTEXT_PATTERNS = [
+    /\b\w+\.(ts|tsx|js|jsx|mjs|cjs|py|rs|go|java|kt|swift|cpp|cc|c|h|hpp|md|json|yaml|yml|toml|css|scss|sass|html|xml|sh|bash|sql|prisma|graphql)\b/i,
+    /\b(package\.json|package-lock|pnpm-lock|yarn\.lock|node_modules|tsconfig|webpack|vite\.config|next\.config|tailwind\.config|README|Dockerfile|Makefile)\b/i,
+    /\b(the bug|this error|the issue|this code|the function|the class|the method|the file|the test|the build|the migration)\b/i,
+];
+export class IntentClassifier {
+    // Constructor accepts options purely for backwards compatibility with
+    // call sites that still pass provider/model/timeoutMs. None are read.
+    constructor(_opts = {}) {
+        void _opts;
+    }
+    // Async signature retained so the call site can still `await` it. The
+    // body is synchronous — there's no network hop, no timeout, no retry.
+    async classify(userMessage) {
+        return classifyHeuristic(userMessage);
+    }
+}
+function classifyHeuristic(userMessage) {
+    const trimmed = userMessage.trim();
+    // Empty input — only true ambiguous case. Everything else defaults to
+    // task per the original prompt's "when in doubt" rule.
+    if (!trimmed)
+        return 'ambiguous';
+    // Very short messages are almost always conversational. Length 6
+    // covers "ok", "yes", "no", "wait", "stop" etc. without catching
+    // one-word task requests like "test" or "build".
+    if (trimmed.length <= 6 &&
+        !/^(test|build|run|fix|ship|start|launch|lint)$/i.test(trimmed)) {
+        return 'conversational';
+    }
+    // Pure conversational signals first — these are tight enough that
+    // false positives on real tasks are rare. Order matters: check
+    // conversational before task-verb so "thanks" (anchored ^thanks$)
+    // wins over "thank" being matched as part of a longer string.
+    for (const pattern of CONVERSATIONAL_PATTERNS) {
+        if (pattern.test(trimmed))
+            return 'conversational';
+    }
+    // Task signals — verb-led imperatives, infinitive phrases, "look at",
+    // and code-context disambiguators.
+    if (TASK_VERB_AT_START.test(trimmed))
+        return 'task';
+    if (TASK_AS_INFINITIVE.test(trimmed))
+        return 'task';
+    if (LOOK_AT_PATTERN.test(trimmed))
+        return 'task';
+    for (const pattern of CODE_CONTEXT_PATTERNS) {
+        if (pattern.test(trimmed))
+            return 'task';
+    }
+    // Default per the original LLM rule. Blocking tools on a real task
+    // produces broken output (model emits text-format tool calls);
+    // running tools on a chatty message just wastes one turn.
+    return 'task';
+}
+//# sourceMappingURL=intent-classifier.js.map

package/dist/agent/intent-classifier.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"intent-classifier.js","sourceRoot":"","sources":["../../src/agent/intent-classifier.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAkCG;AAgBH,qEAAqE;AACrE,wEAAwE;AACxE,sEAAsE;AACtE,mEAAmE;AACnE,MAAM,uBAAuB,GAAsB;IACjD,iCAAiC;IACjC,kEAAkE;IAClE,qCAAqC;IACrC,qDAAqD;IACrD,0DAA0D;IAC1D,6CAA6C;IAC7C,wCAAwC;IACxC,kCAAkC;IAClC,6CAA6C;IAC7C,kBAAkB;IAClB,2CAA2C;IAC3C,uBAAuB;IACvB,kEAAkE;IAClE,0BAA0B;IAC1B,8CAA8C;IAC9C,mFAAmF;CACpF,CAAC;AAEF,6EAA6E;AAC7E,2EAA2E;AAC3E,MAAM,UAAU,GACd,iXAAiX,CAAC;AAEpX,uEAAuE;AACvE,qEAAqE;AACrE,iEAAiE;AACjE,MAAM,kBAAkB,GAAG,IAAI,MAAM,CACnC,qGAAqG,UAAU,KAAK,EACpH,GAAG,CACJ,CAAC;AAEF,MAAM,kBAAkB,GAAG,IAAI,MAAM,CACnC,sEAAsE,UAAU,KAAK,EACrF,GAAG,CACJ,CAAC;AAEF,uEAAuE;AACvE,iEAAiE;AACjE,MAAM,eAAe,GAAG,uEAAuE,CAAC;AAEhG,uEAAuE;AACvE,MAAM,qBAAqB,GAAsB;IAC/C,iJAAiJ;IACjJ,4JAA4J;IAC5J,2HAA2H;CAC5H,CAAC;AAEF,MAAM,OAAO,gBAAgB;IAC3B,sEAAsE;IACtE,sEAAsE;IACtE,YAAY,QAAiC,EAAE;QAE7C,KAAK,KAAK,CAAC;IACb,CAAC;IAED,sEAAsE;IACtE,sEAAsE;IACtE,KAAK,CAAC,QAAQ,CAAC,WAAmB;QAChC,OAAO,iBAAiB,CAAC,WAAW,CAAC,CAAC;IACxC,CAAC;CACF;AAED,SAAS,iBAAiB,CAAC,WAAmB;IAC5C,MAAM,OAAO,GAAG,WAAW,CAAC,IAAI,EAAE,CAAC;IAEnC,sEAAsE;IACtE,uDAAuD;IACvD,IAAI,CAAC,OAAO;QAAE,OAAO,WAAW,CAAC;IAEjC,iEAAiE;IACjE,iEAAiE;IACjE,iDAAiD;IACjD,IACE,OAAO,CAAC,MAAM,IAAI,CAAC;QACnB,CAAC,gDAAgD,CAAC,IAAI,CAAC,OAAO,CAAC,EAC/D,CAAC;QACD,OAAO,gBAAgB,CAAC;IAC1B,CAAC;IAED,kEAAkE;IAClE,+DAA+D;IAC/D,kEAAkE;IAClE,8DAA8D;IAC9D,KAAK,MAAM,OAAO,IAAI,uBAAuB,EAAE,CAAC;QAC9C,IAAI,OAAO,CAAC,IAAI,CAAC,OAAO,CAAC;YAAE,OAAO,gBAAgB,CAAC;IACrD,CAAC;IAED,sEAAsE;IACtE,mCAAmC;IACnC,IAAI,kBAAkB,CAAC,IAAI,CAAC,OAAO,CAAC;QAAE,OAAO,MAAM,CAAC;IACpD,IAAI,kBAAkB,CAAC,IAAI,CAAC,OAAO,CAAC;QAAE,OAAO,MAAM,CAAC;IACpD,IAAI,eAAe,CAAC,IAAI,CAAC,OAAO,CAAC;QAAE,OAAO,MAAM,CAAC;IACjD,KAAK,MAAM,OAAO,IAAI,qBAAqB,EAAE,CAAC;QAC5C,IAAI,OAAO,CAAC,IAAI,CAAC,OAAO,CAAC;YAAE,OAAO,MAAM,CAAC;IAC3C,CAAC;IAED,mEAAmE;IACnE,+DAA+D;IAC/D,0DAA0D;IAC1D,OAAO,MAAM,CAAC;AAChB,CAAC"}

package/dist/agent/post-edit-verify.d.ts

@@ -0,0 +1,79 @@
+/**
+ * Post-edit verification — universal hook that runs verify_change against
+ * files mutated during the trajectory, regardless of mode (Maestro,
+ * Supernova, Aurora, BYOK direct-model). Lives in the agent layer rather
+ * than the AutoCoordinator so single-model BYOK chats get the same
+ * enforcement that orchestrated modes have always had.
+ *
+ * Flow:
+ *   1. Tool post-hook (recordEditFromTool) — every successful file_write
+ *      / file_edit adds the file path to pendingVerifyFiles on the
+ *      trajectory.
+ *   2. Tool-tick check (shouldVerifyAfterTool) — every Nth tool call,
+ *      if pendingVerifyFiles is non-empty, fire verify_change
+ *      opportunistically. Catches errors mid-task before they snowball.
+ *   3. Closure guard (pendingFilesAtClosure) — when the model attempts
+ *      to end its turn, the agent checks for pending files and either
+ *      runs the verify (passing → close) or refuses the close and
+ *      injects a nudge (failing → fix-and-retry path).
+ *
+ * Pass result clears the pending set and adds files to verifiedFiles.
+ * Fail result clears pending too — verify happened, regardless of
+ * outcome — and the failure is recorded on verifyFailureHistory by
+ * the error-loop detector. Subsequent edits to the same files re-add
+ * them to pending automatically.
+ */
+import type { TrajectoryContext } from '../dataset/emitter.js';
+import type { ToolExecutionContext } from '../tools/types.js';
+/**
+ * Hook called from the agent's tool-execution path after every tool
+ * completes. Adds the touched file path to pendingVerifyFiles when the
+ * tool was a mutation and succeeded. Returns the path added (or null).
+ */
+export declare function recordEditFromTool(traj: TrajectoryContext, toolName: string, args: Record<string, unknown>, success: boolean): string | null;
+/**
+ * Decide whether the agent should fire an opportunistic verify_change run
+ * now. Only true when (a) there are pending files and (b) the tool count
+ * is on a multiple of the tick. Avoids over-verifying — verify_change
+ * itself is fast on typecheck-only paths but route_curl / migration_dry_run
+ * have real cost.
+ */
+export declare function shouldVerifyAfterTool(traj: TrajectoryContext, threshold?: number): boolean;
+/**
+ * If the trajectory has unverified file edits, return them. Caller (the
+ * agent's pre-closure logic) uses the return to decide whether to refuse
+ * a turn-ending response and nudge the model to verify first.
+ */
+export declare function pendingFilesAtClosure(traj: TrajectoryContext): string[] | null;
+/**
+ * Run verify_change against the trajectory's pending files and update
+ * trajectory state based on the result. Returns the structured outcome
+ * the caller uses to inject the failure report (on fail) or proceed
+ * with closure (on pass).
+ *
+ * Side effects:
+ *   - On pass: pending files move to verifiedFiles
+ *   - On fail: pending files are cleared (verify happened, errors get
+ *     surfaced via the failure report; if the model edits again, those
+ *     edits re-populate pending automatically)
+ */
+export declare function runPendingVerify(traj: TrajectoryContext, ctx: ToolExecutionContext): Promise<{
+    passed: boolean;
+    output: string;
+    metadata: Record<string, unknown>;
+    files: string[];
+}>;
+/**
+ * Format the failure report into a user-role context message the model
+ * sees on its next turn. Mirrors AutoCoordinator's retry-context shape
+ * so models that have learned the orchestrated retry pattern recognise
+ * the same format here.
+ */
+export declare function buildVerifyFailureNudge(report: string, files: string[]): string;
+/**
+ * Format the closure-time nudge for when the model tries to end its
+ * turn with unverified edits. Encourages running verify itself rather
+ * than just declaring done.
+ */
+export declare function buildClosureVerifyNudge(files: string[]): string;
+//# sourceMappingURL=post-edit-verify.d.ts.map

package/dist/agent/post-edit-verify.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"post-edit-verify.d.ts","sourceRoot":"","sources":["../../src/agent/post-edit-verify.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;GAwBG;AAEH,OAAO,KAAK,EAAE,iBAAiB,EAAE,MAAM,uBAAuB,CAAC;AAE/D,OAAO,KAAK,EAAE,oBAAoB,EAAE,MAAM,mBAAmB,CAAC;AAc9D;;;;GAIG;AACH,wBAAgB,kBAAkB,CAChC,IAAI,EAAE,iBAAiB,EACvB,QAAQ,EAAE,MAAM,EAChB,IAAI,EAAE,MAAM,CAAC,MAAM,EAAE,OAAO,CAAC,EAC7B,OAAO,EAAE,OAAO,GACf,MAAM,GAAG,IAAI,CAUf;AAED;;;;;;GAMG;AACH,wBAAgB,qBAAqB,CACnC,IAAI,EAAE,iBAAiB,EACvB,SAAS,GAAE,MAA4B,GACtC,OAAO,CAIT;AAED;;;;GAIG;AACH,wBAAgB,qBAAqB,CAAC,IAAI,EAAE,iBAAiB,GAAG,MAAM,EAAE,GAAG,IAAI,CAG9E;AAED;;;;;;;;;;;GAWG;AACH,wBAAsB,gBAAgB,CACpC,IAAI,EAAE,iBAAiB,EACvB,GAAG,EAAE,oBAAoB,GACxB,OAAO,CAAC;IAAE,MAAM,EAAE,OAAO,CAAC;IAAC,MAAM,EAAE,MAAM,CAAC;IAAC,QAAQ,EAAE,MAAM,CAAC,MAAM,EAAE,OAAO,CAAC,CAAC;IAAC,KAAK,EAAE,MAAM,EAAE,CAAA;CAAE,CAAC,CA2BlG;AAED;;;;;GAKG;AACH,wBAAgB,uBAAuB,CAAC,MAAM,EAAE,MAAM,EAAE,KAAK,EAAE,MAAM,EAAE,GAAG,MAAM,CAO/E;AAED;;;;GAIG;AACH,wBAAgB,uBAAuB,CAAC,KAAK,EAAE,MAAM,EAAE,GAAG,MAAM,CAQ/D"}

package/dist/agent/post-edit-verify.js

@@ -0,0 +1,143 @@
+/**
+ * Post-edit verification — universal hook that runs verify_change against
+ * files mutated during the trajectory, regardless of mode (Maestro,
+ * Supernova, Aurora, BYOK direct-model). Lives in the agent layer rather
+ * than the AutoCoordinator so single-model BYOK chats get the same
+ * enforcement that orchestrated modes have always had.
+ *
+ * Flow:
+ *   1. Tool post-hook (recordEditFromTool) — every successful file_write
+ *      / file_edit adds the file path to pendingVerifyFiles on the
+ *      trajectory.
+ *   2. Tool-tick check (shouldVerifyAfterTool) — every Nth tool call,
+ *      if pendingVerifyFiles is non-empty, fire verify_change
+ *      opportunistically. Catches errors mid-task before they snowball.
+ *   3. Closure guard (pendingFilesAtClosure) — when the model attempts
+ *      to end its turn, the agent checks for pending files and either
+ *      runs the verify (passing → close) or refuses the close and
+ *      injects a nudge (failing → fix-and-retry path).
+ *
+ * Pass result clears the pending set and adds files to verifiedFiles.
+ * Fail result clears pending too — verify happened, regardless of
+ * outcome — and the failure is recorded on verifyFailureHistory by
+ * the error-loop detector. Subsequent edits to the same files re-add
+ * them to pending automatically.
+ */
+import { VerifyChangeTool } from '../tools/verify-change.js';
+/**
+ * Tools whose successful execution mutates a file at args.file_path. Limited
+ * to the two universal file-mutation tools — bash and migration tools also
+ * mutate files but their target paths are buried inside command strings, so
+ * tracking them robustly would need a parser per shell-tool. Out of scope;
+ * the user can declare those manually via a follow-up file_edit if needed.
+ */
+const FILE_MUTATING_TOOLS = new Set(['file_write', 'file_edit']);
+/** Default opportunistic-verify cadence — every Nth tool call. */
+const DEFAULT_VERIFY_TICK = 6;
+/**
+ * Hook called from the agent's tool-execution path after every tool
+ * completes. Adds the touched file path to pendingVerifyFiles when the
+ * tool was a mutation and succeeded. Returns the path added (or null).
+ */
+export function recordEditFromTool(traj, toolName, args, success) {
+    if (!success)
+        return null;
+    if (!FILE_MUTATING_TOOLS.has(toolName))
+        return null;
+    const filePath = typeof args.file_path === 'string' ? args.file_path : null;
+    if (!filePath)
+        return null;
+    if (!traj.pendingVerifyFiles)
+        traj.pendingVerifyFiles = new Set();
+    traj.pendingVerifyFiles.add(filePath);
+    // Re-edit invalidates any prior verified state for this file.
+    traj.verifiedFiles?.delete(filePath);
+    return filePath;
+}
+/**
+ * Decide whether the agent should fire an opportunistic verify_change run
+ * now. Only true when (a) there are pending files and (b) the tool count
+ * is on a multiple of the tick. Avoids over-verifying — verify_change
+ * itself is fast on typecheck-only paths but route_curl / migration_dry_run
+ * have real cost.
+ */
+export function shouldVerifyAfterTool(traj, threshold = DEFAULT_VERIFY_TICK) {
+    if (!traj.pendingVerifyFiles || traj.pendingVerifyFiles.size === 0)
+        return false;
+    const count = traj.toolsSoFar.length;
+    return count > 0 && count % threshold === 0;
+}
+/**
+ * If the trajectory has unverified file edits, return them. Caller (the
+ * agent's pre-closure logic) uses the return to decide whether to refuse
+ * a turn-ending response and nudge the model to verify first.
+ */
+export function pendingFilesAtClosure(traj) {
+    if (!traj.pendingVerifyFiles || traj.pendingVerifyFiles.size === 0)
+        return null;
+    return Array.from(traj.pendingVerifyFiles);
+}
+/**
+ * Run verify_change against the trajectory's pending files and update
+ * trajectory state based on the result. Returns the structured outcome
+ * the caller uses to inject the failure report (on fail) or proceed
+ * with closure (on pass).
+ *
+ * Side effects:
+ *   - On pass: pending files move to verifiedFiles
+ *   - On fail: pending files are cleared (verify happened, errors get
+ *     surfaced via the failure report; if the model edits again, those
+ *     edits re-populate pending automatically)
+ */
+export async function runPendingVerify(traj, ctx) {
+    const files = Array.from(traj.pendingVerifyFiles ?? []);
+    if (files.length === 0) {
+        return { passed: true, output: 'No pending files.', metadata: {}, files: [] };
+    }
+    const tool = new VerifyChangeTool();
+    const result = await tool.execute({ files }, ctx);
+    if (result.success) {
+        if (!traj.verifiedFiles)
+            traj.verifiedFiles = new Set();
+        for (const f of files) {
+            traj.pendingVerifyFiles?.delete(f);
+            traj.verifiedFiles.add(f);
+        }
+    }
+    else {
+        // Failure path: clear pending (the verify is done) and let the
+        // caller handle the failure report. Subsequent edits re-add files.
+        traj.pendingVerifyFiles?.clear();
+    }
+    return {
+        passed: result.success,
+        output: result.output,
+        metadata: result.metadata ?? {},
+        files,
+    };
+}
+/**
+ * Format the failure report into a user-role context message the model
+ * sees on its next turn. Mirrors AutoCoordinator's retry-context shape
+ * so models that have learned the orchestrated retry pattern recognise
+ * the same format here.
+ */
+export function buildVerifyFailureNudge(report, files) {
+    return (`[verification failed]\n\n${report}\n\n` +
+        `The previous edit(s) to ${files.join(', ')} did not pass verification. ` +
+        `Read the failure above carefully — fix the actual issue (don't paper over it), ` +
+        `then re-edit the file(s) and let verification re-run.`);
+}
+/**
+ * Format the closure-time nudge for when the model tries to end its
+ * turn with unverified edits. Encourages running verify itself rather
+ * than just declaring done.
+ */
+export function buildClosureVerifyNudge(files) {
+    return (`[verification required before close]\n\n` +
+        `You're about to end the turn but ${files.length} file(s) you edited haven't been verified: ${files.join(', ')}.\n\n` +
+        `Run typecheck / tests on the changes before closing — call verify_change with the file list, ` +
+        `or run the project's test command via bash. If you're certain the edits don't need verification ` +
+        `(prose-only, config comments, etc.), say so explicitly so the user knows. Don't silently skip.`);
+}
+//# sourceMappingURL=post-edit-verify.js.map

package/dist/agent/post-edit-verify.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"post-edit-verify.js","sourceRoot":"","sources":["../../src/agent/post-edit-verify.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;GAwBG;AAGH,OAAO,EAAE,gBAAgB,EAAE,MAAM,2BAA2B,CAAC;AAG7D;;;;;;GAMG;AACH,MAAM,mBAAmB,GAAG,IAAI,GAAG,CAAC,CAAC,YAAY,EAAE,WAAW,CAAC,CAAC,CAAC;AAEjE,kEAAkE;AAClE,MAAM,mBAAmB,GAAG,CAAC,CAAC;AAE9B;;;;GAIG;AACH,MAAM,UAAU,kBAAkB,CAChC,IAAuB,EACvB,QAAgB,EAChB,IAA6B,EAC7B,OAAgB;IAEhB,IAAI,CAAC,OAAO;QAAE,OAAO,IAAI,CAAC;IAC1B,IAAI,CAAC,mBAAmB,CAAC,GAAG,CAAC,QAAQ,CAAC;QAAE,OAAO,IAAI,CAAC;IACpD,MAAM,QAAQ,GAAG,OAAO,IAAI,CAAC,SAAS,KAAK,QAAQ,CAAC,CAAC,CAAC,IAAI,CAAC,SAAS,CAAC,CAAC,CAAC,IAAI,CAAC;IAC5E,IAAI,CAAC,QAAQ;QAAE,OAAO,IAAI,CAAC;IAC3B,IAAI,CAAC,IAAI,CAAC,kBAAkB;QAAE,IAAI,CAAC,kBAAkB,GAAG,IAAI,GAAG,EAAE,CAAC;IAClE,IAAI,CAAC,kBAAkB,CAAC,GAAG,CAAC,QAAQ,CAAC,CAAC;IACtC,8DAA8D;IAC9D,IAAI,CAAC,aAAa,EAAE,MAAM,CAAC,QAAQ,CAAC,CAAC;IACrC,OAAO,QAAQ,CAAC;AAClB,CAAC;AAED;;;;;;GAMG;AACH,MAAM,UAAU,qBAAqB,CACnC,IAAuB,EACvB,YAAoB,mBAAmB;IAEvC,IAAI,CAAC,IAAI,CAAC,kBAAkB,IAAI,IAAI,CAAC,kBAAkB,CAAC,IAAI,KAAK,CAAC;QAAE,OAAO,KAAK,CAAC;IACjF,MAAM,KAAK,GAAG,IAAI,CAAC,UAAU,CAAC,MAAM,CAAC;IACrC,OAAO,KAAK,GAAG,CAAC,IAAI,KAAK,GAAG,SAAS,KAAK,CAAC,CAAC;AAC9C,CAAC;AAED;;;;GAIG;AACH,MAAM,UAAU,qBAAqB,CAAC,IAAuB;IAC3D,IAAI,CAAC,IAAI,CAAC,kBAAkB,IAAI,IAAI,CAAC,kBAAkB,CAAC,IAAI,KAAK,CAAC;QAAE,OAAO,IAAI,CAAC;IAChF,OAAO,KAAK,CAAC,IAAI,CAAC,IAAI,CAAC,kBAAkB,CAAC,CAAC;AAC7C,CAAC;AAED;;;;;;;;;;;GAWG;AACH,MAAM,CAAC,KAAK,UAAU,gBAAgB,CACpC,IAAuB,EACvB,GAAyB;IAEzB,MAAM,KAAK,GAAG,KAAK,CAAC,IAAI,CAAC,IAAI,CAAC,kBAAkB,IAAI,EAAE,CAAC,CAAC;IACxD,IAAI,KAAK,CAAC,MAAM,KAAK,CAAC,EAAE,CAAC;QACvB,OAAO,EAAE,MAAM,EAAE,IAAI,EAAE,MAAM,EAAE,mBAAmB,EAAE,QAAQ,EAAE,EAAE,EAAE,KAAK,EAAE,EAAE,EAAE,CAAC;IAChF,CAAC;IAED,MAAM,IAAI,GAAG,IAAI,gBAAgB,EAAE,CAAC;IACpC,MAAM,MAAM,GAAG,MAAM,IAAI,CAAC,OAAO,CAAC,EAAE,KAAK,EAAE,EAAE,GAAG,CAAC,CAAC;IAElD,IAAI,MAAM,CAAC,OAAO,EAAE,CAAC;QACnB,IAAI,CAAC,IAAI,CAAC,aAAa;YAAE,IAAI,CAAC,aAAa,GAAG,IAAI,GAAG,EAAE,CAAC;QACxD,KAAK,MAAM,CAAC,IAAI,KAAK,EAAE,CAAC;YACtB,IAAI,CAAC,kBAAkB,EAAE,MAAM,CAAC,CAAC,CAAC,CAAC;YACnC,IAAI,CAAC,aAAa,CAAC,GAAG,CAAC,CAAC,CAAC,CAAC;QAC5B,CAAC;IACH,CAAC;SAAM,CAAC;QACN,+DAA+D;QAC/D,mEAAmE;QACnE,IAAI,CAAC,kBAAkB,EAAE,KAAK,EAAE,CAAC;IACnC,CAAC;IAED,OAAO;QACL,MAAM,EAAE,MAAM,CAAC,OAAO;QACtB,MAAM,EAAE,MAAM,CAAC,MAAM;QACrB,QAAQ,EAAE,MAAM,CAAC,QAAQ,IAAI,EAAE;QAC/B,KAAK;KACN,CAAC;AACJ,CAAC;AAED;;;;;GAKG;AACH,MAAM,UAAU,uBAAuB,CAAC,MAAc,EAAE,KAAe;IACrE,OAAO,CACL,4BAA4B,MAAM,MAAM;QACxC,2BAA2B,KAAK,CAAC,IAAI,CAAC,IAAI,CAAC,8BAA8B;QACzE,iFAAiF;QACjF,uDAAuD,CACxD,CAAC;AACJ,CAAC;AAED;;;;GAIG;AACH,MAAM,UAAU,uBAAuB,CAAC,KAAe;IACrD,OAAO,CACL,0CAA0C;QAC1C,oCAAoC,KAAK,CAAC,MAAM,8CAA8C,KAAK,CAAC,IAAI,CAAC,IAAI,CAAC,OAAO;QACrH,+FAA+F;QAC/F,kGAAkG;QAClG,gGAAgG,CACjG,CAAC;AACJ,CAAC"}

package/dist/agent/recover-written-calls.d.ts

@@ -0,0 +1,90 @@
+/**
+ * When a model WRITES a tool call instead of making one.
+ *
+ * Every model we serve supports native tool calls, and they are always offered.
+ * Some still occasionally emit the call as text — an XML-ish tag wrapping a JSON
+ * argument block:
+ *
+ *   <present_plan>
+ *   { "title": "Inventory System Completion Plan", "steps": [ … ] }
+ *   </present_plan>
+ *
+ * That is a shape several open-weight models were trained on, and they fall back
+ * to it under uncertainty even when the schemas are right there. Nothing in our
+ * prompt shows them the format; they arrive with it.
+ *
+ * Untreated, the user gets a wall of raw JSON where a plan card should be, and
+ * the turn ends "successfully" — the agent sees no tool_calls, so it closes.
+ * Seen 2026-08-19 on a Plan-mode turn: a complete, correct plan, rendered as
+ * markup.
+ *
+ * Instructing the model not to do this is unreliable, because the models that do
+ * it are the ones least likely to follow that instruction. Recovering is
+ * reliable, so we recover.
+ *
+ * DELIBERATELY CONSERVATIVE. Only a tag whose name is a tool actually offered
+ * this turn counts, and only when the body parses as a JSON object. Anything
+ * else is left exactly where it is — prose that merely looks like a call is far
+ * more likely than a real one, and turning a sentence into a tool call is a much
+ * worse failure than showing one badly.
+ */
+import type { ToolCall } from '../core/types.js';
+export interface RecoveredCalls {
+    /** Calls lifted out of the text, ready to run. */
+    calls: ToolCall[];
+    /** The reply with those blocks removed. */
+    text: string;
+}
+/**
+ * Lift written tool calls out of an assistant reply.
+ *
+ * @param content   the assistant's visible text
+ * @param offered   names of tools offered this turn — the allowlist for recovery
+ * @param makeId    id generator, injected so tests are deterministic
+ */
+export declare function recoverWrittenToolCalls(content: string, offered: ReadonlySet<string>, makeId?: () => string): RecoveredCalls;
+/**
+ * The same rule, applied WHILE the reply streams.
+ *
+ * `recoverWrittenToolCalls` runs on the finished message, which is too late to
+ * matter to the person watching. Seen live 2026-08-19, one turn after the
+ * recovery shipped: the whole `<present_plan>{…}</present_plan>` block streamed
+ * onto the screen delta by delta, and only once the stream ended did the call
+ * get lifted and the card appear. The operator saw the JSON, then the plan.
+ *
+ * Two more faults are the same fault. The approval prompt arrived AFTER the
+ * plan had finished writing — it could not have come sooner, because the call
+ * did not exist until the stream closed. And denying it did not take the plan
+ * away, because what was on screen was never the card; it was text, already
+ * painted, and no longer ours to withdraw.
+ *
+ * So the block has to be held back as it arrives. This gate sits between the
+ * accumulating content and the delta events: it emits everything that cannot be
+ * part of a written call, and holds anything that might be until it knows.
+ *
+ * It agrees with `recoverWrittenToolCalls` by construction — same allowlist,
+ * same "body must be a JSON object" rule — so it never hides text the recovery
+ * would have left in place. Raw content still accumulates in full behind it;
+ * only the view is filtered.
+ */
+export declare class WrittenCallStreamFilter {
+    private readonly offered;
+    /** Text withheld because it might be, or might be inside, a written call. */
+    private held;
+    /** The opening tag, kept so it can be released if the body turns out to be prose. */
+    private tag;
+    constructor(offered: ReadonlySet<string>);
+    /** Is `partial` (the text after `<`, no `>` yet) still on its way to a tool name? */
+    private viable;
+    /** Feed a chunk of visible text; returns the part that is safe to show. */
+    push(chunk: string): string;
+    /**
+     * The stream ended. Release anything held that never became a call.
+     *
+     * A confirmed call in flight is dropped: `recoverWrittenToolCalls` lifts it
+     * out of the accumulated content, so showing it here would put back exactly
+     * what this class exists to withhold.
+     */
+    flush(): string;
+}
+//# sourceMappingURL=recover-written-calls.d.ts.map

package/dist/agent/recover-written-calls.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"recover-written-calls.d.ts","sourceRoot":"","sources":["../../src/agent/recover-written-calls.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GA6BG;AACH,OAAO,KAAK,EAAE,QAAQ,EAAE,MAAM,kBAAkB,CAAC;AAEjD,MAAM,WAAW,cAAc;IAC7B,kDAAkD;IAClD,KAAK,EAAE,QAAQ,EAAE,CAAC;IAClB,2CAA2C;IAC3C,IAAI,EAAE,MAAM,CAAC;CACd;AAiDD;;;;;;GAMG;AACH,wBAAgB,uBAAuB,CACrC,OAAO,EAAE,MAAM,EACf,OAAO,EAAE,WAAW,CAAC,MAAM,CAAC,EAC5B,MAAM,GAAE,MAAM,MAAqE,GAClF,cAAc,CAmEhB;AAED;;;;;;;;;;;;;;;;;;;;;;;GAuBG;AACH,qBAAa,uBAAuB;IAMtB,OAAO,CAAC,QAAQ,CAAC,OAAO;IALpC,6EAA6E;IAC7E,OAAO,CAAC,IAAI,CAAM;IAClB,qFAAqF;IACrF,OAAO,CAAC,GAAG,CAAuB;gBAEL,OAAO,EAAE,WAAW,CAAC,MAAM,CAAC;IAEzD,qFAAqF;IACrF,OAAO,CAAC,MAAM;IAOd,2EAA2E;IAC3E,IAAI,CAAC,KAAK,EAAE,MAAM,GAAG,MAAM;IAiE3B;;;;;;OAMG;IACH,KAAK,IAAI,MAAM;CAehB"}