@cat-factory/executor-harness 1.62.0 → 1.64.0

package/dist/agent-runner.js

@@ -4,6 +4,7 @@ import { tmpdir } from 'node:os';
 import { dirname, join } from 'node:path';
 import { claudeAssistantContent, claudeCallUsage, isObject, numberOf, redactBody, } from './claude-stream.js';
 import { createCallMetricPublisher, publishCallMetric, } from './pi.js';
+import { ProgressGuard } from './progress-guard.js';
 import { killChildProcess, spawnDetached } from './process.js';
 import { redact, secretsToRedact } from './redact.js';
 import { createSliceTracker, startSubagentWatcher } from './subagents.js';
@@ -58,7 +59,12 @@ function streamCli(cli, prompt, opts, env, secrets, onEvent) {
         let aborted = false;
         let lineBuffer = '';
         const killChild = () => killChildProcess(child);
-        const processLine = (line) => {
+        // `final` marks the at-close flush of a trailing unterminated line: the CLI has already
+        // exited, so an observer must not act on that record in a way that KILLS the run (mirrors
+        // `runPi`'s `runGuard = false` flush — without it, a guard tripping on the last buffered
+        // record could turn a clean exit into a spurious "no progress" failure). The record's
+        // progress/telemetry signal is still delivered; only kill decisions are suppressed.
+        const processLine = (line, final = false) => {
             if (!line.startsWith('{'))
                 return;
             let event;
@@ -69,7 +75,7 @@ function streamCli(cli, prompt, opts, env, secrets, onEvent) {
                 return;
             }
             try {
-                onEvent(event);
+                onEvent(event, { final });
             }
             catch {
                 // A faulty observer must never break the run.
@@ -106,11 +112,14 @@ function streamCli(cli, prompt, opts, env, secrets, onEvent) {
         });
         child.on('close', (code) => {
             opts.signal?.removeEventListener('abort', onAbort);
-            if (lineBuffer.trim())
-                processLine(lineBuffer.trim());
             const stderrTail = redact(stderr, secrets).slice(-700);
+            if (lineBuffer.trim())
+                processLine(lineBuffer.trim(), true);
             if (aborted) {
-                reject(new Error('agent run aborted by watchdog'));
+                // Carry the tail on the rejection so a caller that REPLACES this generic message with a
+                // more specific cause (the no-progress guard's diagnostic) can still append it — the
+                // stderr is often the only evidence of what the CLI was doing when it was killed.
+                reject(Object.assign(new Error('agent run aborted by watchdog'), { stderrTail }));
                 return;
             }
             if (code !== 0) {
@@ -246,7 +255,44 @@ export async function runClaudeCode(opts) {
         if (progress)
             opts.onProgress(progress);
     };
-    const onEvent = (event) => {
+    // No-progress guard on the CLI's own tool stream — the claude-code analogue of runPi's guard,
+    // absent on this path until now. Claude Code reports a tool CALL (its name) on the `assistant`
+    // turn and that call's RESULT (`is_error`) on the following `user` turn, so correlate them by
+    // `tool_use` id to feed the guard a {name,isError} signal. A tripped guard aborts the CLI via
+    // `guardAbort` (folded into streamCli's signal below) and the run then fails with its
+    // diagnostic. Disabled when the caller supplies no limits (only the external watchdog bounds it).
+    const guard = opts.guardLimits
+        ? new ProgressGuard(opts.guardLimits, opts.expectsEdits ?? true)
+        : undefined;
+    const toolNames = new Map();
+    const guardAbort = new AbortController();
+    let guardReason;
+    // Feed a user turn's settled tool calls to the guard, pairing each `tool_result`'s `is_error`
+    // with the name captured for its `tool_use` id on the assistant turn. The FIRST reason trips
+    // it: record the diagnostic and abort the CLI (streamCli's close handler rejects; the catch
+    // below surfaces `guardReason` over the generic abort message). A standalone closure so the
+    // per-block loop doesn't nest onEvent past the readable-depth limit.
+    const feedGuard = (content) => {
+        if (!guard || guardReason)
+            return;
+        for (const block of content) {
+            if (!isObject(block) || block.type !== 'tool_result')
+                continue;
+            const id = typeof block.tool_use_id === 'string' ? block.tool_use_id : undefined;
+            const name = id ? toolNames.get(id) : undefined;
+            if (id)
+                toolNames.delete(id);
+            if (!name)
+                continue;
+            const reason = guard.observeSignal({ name, isError: block.is_error === true });
+            if (reason) {
+                guardReason = reason;
+                guardAbort.abort();
+                return;
+            }
+        }
+    };
+    const onEvent = (event, meta) => {
         const type = event.type;
         if (type === 'assistant' && isObject(event.message)) {
             const message = event.message;
@@ -255,7 +301,14 @@ export async function runClaudeCode(opts) {
             stats.assistantChars += text.length;
             stats.toolCalls += toolUses;
             for (const block of content) {
-                if (isObject(block) && block.type === 'tool_use' && block.name === 'TodoWrite') {
+                if (!isObject(block) || block.type !== 'tool_use')
+                    continue;
+                // Remember each call's name against its id so the guard can pair it with the
+                // `is_error` its `tool_result` carries on the next `user` turn.
+                if (typeof block.id === 'string' && typeof block.name === 'string') {
+                    toolNames.set(block.id, block.name);
+                }
+                if (block.name === 'TodoWrite') {
                     const progress = todosToProgress(block.input?.todos);
                     if (progress)
                         lastTodo = progress;
@@ -288,6 +341,10 @@ export async function runClaudeCode(opts) {
                 sliceTracker.onUser(content);
                 planTracker.onUser(content);
                 emitProgress();
+                // Not on the at-close flush: the CLI has already exited, so tripping the guard there
+                // would kill nothing and only convert a clean exit into a spurious failure.
+                if (!meta?.final)
+                    feedGuard(content);
                 messages.push({ role: 'tool', content });
             }
         }
@@ -350,6 +407,11 @@ export async function runClaudeCode(opts) {
             ...(opts.log ? { log: opts.log } : {}),
         })
         : undefined;
+    // Fold the guard's abort into the run signal so a tripped guard kills the CLI the same way the
+    // external watchdog does; `guardReason` (set above) distinguishes the two at the catch below.
+    const runSignal = opts.signal
+        ? AbortSignal.any([opts.signal, guardAbort.signal])
+        : guardAbort.signal;
     try {
         const { stderrTail } = await streamCli({
             command: 'claude',
@@ -368,7 +430,7 @@ export async function runClaudeCode(opts) {
                 opts.model,
                 ...appendArgs,
             ],
-        }, prompt, opts, env, opts.subscriptionToken ? secretsToRedact(opts.subscriptionToken) : [], onEvent);
+        }, prompt, { ...opts, signal: runSignal }, env, opts.subscriptionToken ? secretsToRedact(opts.subscriptionToken) : [], onEvent);
         return await assembleClaudeOutcome({
             summary,
             stats,
@@ -379,6 +441,17 @@ export async function runClaudeCode(opts) {
             subagents,
         });
     }
+    catch (err) {
+        // A tripped no-progress guard aborted the CLI; streamCli rejects with its generic abort
+        // message, so replace it with the guard's actionable diagnostic — carrying the stderr tail
+        // it attached, since that is usually the only evidence of what the CLI was doing when it was
+        // killed. Byte-for-byte the shape `runPi` fails with.
+        if (guardReason) {
+            const tail = err?.stderrTail;
+            throw new Error(tail ? `${guardReason} Agent stderr: ${tail}` : guardReason);
+        }
+        throw err;
+    }
     finally {
         await subagents?.stop();
         if (configHome) {

package/dist/claude-stream.js

@@ -7,6 +7,24 @@ import { redact } from './redact.js';
 export function isObject(value) {
     return typeof value === 'object' && value !== null;
 }
+/**
+ * The tool names the Claude Code CLI dispatches a parallel subagent under. `Agent` is what the
+ * shipped schema declares (`AgentInput` in `sdk-tools.d.ts`, carrying `description` / `prompt` /
+ * `subagent_type`); `Task` is the older name for the same dispatch. Both are matched because the
+ * harness runs against whatever CLI the image happens to bundle, and matching only the old name
+ * is what left a CLI 2.1.x pr-review reporting no slices at all.
+ *
+ * Note the asymmetry: keeping the legacy `Task` here is the one place a CLI rename could produce a
+ * FALSE signal rather than merely no signal — if a future build were to name a plain task-list
+ * tool `Task`, its writes would be counted as in-flight slices. We accept that because no shipped
+ * build does (the incremental plan tool is `TaskCreate`/`TaskUpdate`, tracked separately in
+ * `progress.ts`), and dropping legacy coverage is the more likely regression.
+ *
+ * Lives here rather than in `subagents.ts` because BOTH the slice tracker and the no-progress
+ * guard (`pi.ts`, which `subagents.ts` imports — so it cannot import back) must agree on what a
+ * subagent dispatch looks like.
+ */
+export const SUBAGENT_TOOL_NAMES = new Set(['Agent', 'Task']);
 export function numberOf(value) {
     return typeof value === 'number' && Number.isFinite(value) ? value : 0;
 }

package/dist/embed.js

@@ -4,5 +4,6 @@
 // repo, write the agent context, point Pi at an OpenAI-compatible endpoint, run
 // it, and inspect what changed. The HTTP server / job lifecycle stays internal;
 // only the reusable primitives are exposed here.
-export { PI_MAX_OUTPUT_TOKENS, DEFAULT_PROGRESS_GUARD_LIMITS, writePiModelsConfig, writeAgentsContext, runPi, summarizePiRun, parsePiOutput, parseTodoProgress, progressGuardLimitsFromEnv, terminalRunError, } from './pi.js';
+export { PI_MAX_OUTPUT_TOKENS, writePiModelsConfig, writeAgentsContext, runPi, summarizePiRun, parsePiOutput, parseTodoProgress, terminalRunError, } from './pi.js';
+export { DEFAULT_PROGRESS_GUARD_LIMITS, progressGuardLimitsFromEnv, } from './progress-guard.js';
 export { cloneRepo, createBranch, changedPathsFromPorcelain, hasAgentChanges, redactSecrets, } from './git.js';

package/dist/pi-workspace.js

@@ -1,9 +1,10 @@
-import { mkdir, mkdtemp, rm } from 'node:fs/promises';
+import { mkdir, mkdtemp, readdir, rm, stat } from 'node:fs/promises';
 import { tmpdir } from 'node:os';
 import { join } from 'node:path';
 import { readEffortReport } from './effort.js';
 import { log } from './logger.js';
-import { CONTEXT_DIR, materializeContextFiles, materializeSkillResources, mergeGuardLimits, progressGuardLimitsFromEnv, runPi, webSearchConfigFromEnv, webSearchProxyEnv, writeAgentsContext, writePiModelsConfig, writeWebToolsConfig, } from './pi.js';
+import { CONTEXT_DIR, materializeContextFiles, materializeSkillResources, runPi, webSearchConfigFromEnv, webSearchProxyEnv, writeAgentsContext, writePiModelsConfig, writeWebToolsConfig, } from './pi.js';
+import { mergeGuardLimits, progressGuardLimitsFromEnv, } from './progress-guard.js';
 import { runSubscriptionHarness } from './agent-runner.js';
 // The thin base every container agent shares: an ephemeral working directory, and
 // one Pi run inside it driven by the harness-written context. The agents differ in
@@ -106,6 +107,29 @@ export async function acquireRepoCheckout(opts, fn) {
         return withPersistentWorkspace(opts.repo, fn);
     return withWorkspace(opts.prefix, fn);
 }
+/**
+ * Whether the run's checkout actually ships a `blueprints/` folder — what gates the blueprint
+ * orientation note in AGENTS.md (an external repo has none, so the note would be ~10 lines of
+ * dead guidance pointing at files that don't exist, re-sent on every turn).
+ *
+ * A MULTI-REPO run's `dir` is the workspace ROOT with each repo checked out as a sibling under
+ * it, so the root itself never holds `blueprints/`: the legs are checked too, and the note is
+ * included when ANY leg ships one (it orients the agent to the concept, and the agent finds the
+ * per-repo folder from there). Best-effort throughout — any stat/readdir failure simply omits
+ * the note rather than failing the dispatch.
+ */
+export async function checkoutHasBlueprints(dir, multiRepo) {
+    const isBlueprintDir = (path) => stat(join(path, 'blueprints'))
+        .then((s) => s.isDirectory())
+        .catch(() => false);
+    if (await isBlueprintDir(dir))
+        return true;
+    if (!multiRepo)
+        return false;
+    const legs = await readdir(dir, { withFileTypes: true }).catch(() => []);
+    const checks = await Promise.all(legs.filter((e) => e.isDirectory()).map((e) => isBlueprintDir(join(dir, e.name))));
+    return checks.some(Boolean);
+}
 /**
  * Write Pi's global agent context (`~/.pi/agent/AGENTS.md`) + provider config,
  * then run Pi once in `spec.dir` and return its summary/stats/stderr. The context
@@ -148,6 +172,13 @@ export async function runAgentInWorkspace(spec, opts = {}) {
             ...(spec.skill ? { skill: spec.skill } : {}),
             ...(opts.agentEnv ? { extraEnv: opts.agentEnv } : {}),
             signal: opts.signal,
+            // Run the SAME no-progress guard Pi gets (previously claude-code/codex had none): env
+            // defaults merged loosen-only with the kind's tuning + the backend's complexity-scaled
+            // no-edit allowance, so a claude-code run that stops making progress is killed early
+            // instead of burning the full wall-clock budget. The claude runner consumes it; codex
+            // ignores it for now (its stream isn't wired to the guard).
+            guardLimits: mergeGuardLimits(progressGuardLimitsFromEnv(), spec.guardLimits),
+            expectsEdits: spec.expectsEdits ?? true,
             onActivity: opts.onActivity,
             onProgress: opts.onProgress,
             // Stream this run's per-call telemetry to the job's live drain. The subscription
@@ -180,11 +211,13 @@ export async function runAgentInWorkspace(spec, opts = {}) {
     const webSearch = webSearchConfigFromEnv({ ...process.env, ...extraEnv });
     if (webSearch)
         await writeWebToolsConfig(webSearch);
+    const hasBlueprints = await checkoutHasBlueprints(spec.dir, spec.multiRepo === true);
     await writeAgentsContext(spec.systemPrompt, {
         webSearch: Boolean(webSearch),
         guidance: spec.webToolsGuidance,
         serviceDirectory: spec.serviceDirectory,
         contextFiles,
+        hasBlueprints,
         ...(spec.multiRepo ? { multiRepo: true } : {}),
     });
     await writePiModelsConfig({ model: spec.model, proxyBaseUrl });

package/dist/pi.js

@@ -7,6 +7,7 @@ import { pathExists } from './fs-utils.js';
 import { redactSecrets } from './redact.js';
 import { HarnessFailure } from './failure.js';
 import { log } from './logger.js';
+import { ProgressGuard, progressGuardLimitsFromEnv, toolCallSignal, } from './progress-guard.js';
 // Drives the Pi coding-agent CLI. Pi is pointed at the Worker's OpenAI-compatible
 // proxy via a custom provider in ~/.pi/agent/models.json, authenticated with the
 // per-job session token (interpolated from $PI_PROXY_TOKEN) — so no provider key
@@ -93,21 +94,12 @@ modules). Do NOT read every module file. Only open \`blueprints/modules/<name>.m
 for a module that is directly relevant to your task, when you need its summary and
 exact code references. \`blueprints/version.json\` is a tiny manifest for quick
 staleness checks. Treat the blueprint as orientation, not a task list.`;
-// Appended to every AGENTS.md so an agent treats the persisted spec as the
-// PRESCRIPTIVE source (what must be true) and the acceptance scenarios its work must
-// satisfy. Harmless when no spec exists yet — the files simply aren't there.
-const SPEC_GUIDANCE = `
-
-## Service specification (the prescriptive spec)
-
-If a \`spec/\` folder exists, it is the specification for this service. It is sharded
-by a module (domain) → feature (group) taxonomy. **Read \`spec/overview.md\` first** —
-it states what MUST be true and indexes the modules and their features (with links).
-Open \`spec/modules/<module>/<feature>.md\` (or its \`.json\` for exact detail) for the
-feature you are working on — it carries that feature's requirements AND the domain
-rules scoped to it. \`spec/features/<module>/<feature>.feature\` are the Gherkin
-acceptance scenarios your work must satisfy — treat them as the source of truth for
-behaviour and tests. Read only the modules/features relevant to your task.`;
+// NOTE: the spec-reading guidance is NOT appended here. It is contributed once, backend-side, by
+// the `spec-aware` trait (`SPEC_AWARE_GUIDANCE` in @cat-factory/agents), which lands in the
+// composed system prompt for every spec-aware kind on BOTH harness paths. This harness used to
+// append a near-duplicate block, so a spec-aware Pi run carried the guidance twice; the claude-code
+// path never appended it. Sourcing it solely from the trait dedupes the Pi prompt and makes the two
+// paths consistent. (A non-spec-aware kind is deliberately not told to read the spec.)
 /**
  * Write the composed system prompt as Pi's GLOBAL agent context
  * (`~/.pi/agent/AGENTS.md`), which Pi reads automatically and concatenates with
@@ -143,7 +135,12 @@ export async function writeAgentsContext(systemPrompt, opts = {}) {
     // Point the agent at any linked context the backend materialised into the checkout
     // (requirements / RFCs / PRDs / tracker issues) so it reads them on demand.
     const context = contextGuidance(opts.contextFiles ?? []);
-    await writeFile(join(dir, 'AGENTS.md'), `${systemPrompt}${BLUEPRINT_GUIDANCE}${SPEC_GUIDANCE}${TODO_GUIDANCE}${monorepo}${multiRepo}${webTools}${context}`, 'utf8');
+    // Only orient the agent to `blueprints/` when the checkout actually has them — otherwise the
+    // note is dead weight re-sent on every turn. The spec-reading guidance is NOT appended here
+    // (see the note above `writeAgentsContext`): it comes solely from the backend `spec-aware`
+    // trait, so a spec-aware run no longer carries it twice.
+    const blueprint = opts.hasBlueprints ? BLUEPRINT_GUIDANCE : '';
+    await writeFile(join(dir, 'AGENTS.md'), `${systemPrompt}${blueprint}${TODO_GUIDANCE}${monorepo}${multiRepo}${webTools}${context}`, 'utf8');
 }
 /** The MULTI-REPO mechanics note appended to AGENTS.md when a run spans sibling checkouts. */
 const MULTI_REPO_GUIDANCE = `
@@ -497,174 +494,8 @@ export function parseTodoProgress(event) {
     }
     return undefined;
 }
-/** Tool-call signal read off a streamed Pi event, or undefined if not a tool call. */
-function toolCallSignal(event) {
-    // `tool_execution_end` is the canonical per-call stream event (statsFromEvents
-    // counts the same one), so the guard reads it and nothing else — no double count.
-    if (event.type !== 'tool_execution_end')
-        return undefined;
-    const name = typeof event.toolName === 'string' ? event.toolName : '';
-    return { name, isError: event.isError === true };
-}
-// `satisfies` (not a type annotation) so each property keeps its concrete `number`
-// type — `maxConsecutiveWebCalls` is optional on the interface (callers may omit it),
-// but the defaults always define it, so consumers reading it off here get a `number`.
-export const DEFAULT_PROGRESS_GUARD_LIMITS = {
-    // Counts only non-exploration, non-planning calls (see EXPLORATION_TOOLS), so the
-    // ceiling can be generous without risking a false kill on a read-heavy large task.
-    maxToolCallsWithoutEdit: 40,
-    maxConsecutiveErrors: 12,
-    // A genuine research burst is a handful of searches; an uninterrupted run of this
-    // many web calls (with no read/edit/bash between) is a search loop, not progress.
-    maxConsecutiveWebCalls: 25,
-};
-// Tool names that mutate files, so a call to one clears the no-edit suspicion. Kept
-// broad on purpose: different models/extensions name the same capability differently
-// (`edit`/`write`, but also `apply_patch`/`patch`/`str_replace`/`multiedit`/`create`),
-// and a false "no edits" reading would kill a run that IS making changes. Matched
-// case-insensitively. NOTE: a file written purely via `bash` (e.g. a heredoc) is not
-// recognised here — broaden or move to a working-tree signal if that becomes common.
-const FILE_EDIT_TOOLS = new Set([
-    'edit',
-    'write',
-    'apply_patch',
-    'patch',
-    'str_replace',
-    'multiedit',
-    'create',
-]);
-// Planning/bookkeeping tools that are neither file edits nor the environment-probing
-// the no-edit bound targets — the todo list the agent maintains as it works. These do
-// NOT count toward `maxToolCallsWithoutEdit`: a run that diligently updates a long
-// todo list before its first edit (common on a large task) would otherwise be killed
-// for "no edits" purely from planning calls. They still reset the consecutive-error
-// streak (a successful call means the agent isn't wedged). Matched case-insensitively.
-const PLANNING_TOOLS = new Set(['todo']);
-// Read-only exploration tools: reading/searching the repo is legitimate work-up to an
-// edit, NOT the environment-probing the no-edit bound targets, so they don't count
-// toward `maxToolCallsWithoutEdit` (a large task may read/search dozens of files
-// before its first edit). The bound thus counts only "action" calls — chiefly `bash`
-// (the credential rabbit-hole's vector) — that have yet to produce an edit. Kept broad
-// since models/extensions name the same capability differently. Matched case-insensitively.
-const EXPLORATION_TOOLS = new Set([
-    'read',
-    'grep',
-    'search',
-    'glob',
-    'ls',
-    'list',
-    'find',
-    'tree',
-    'cat',
-    'view',
-    'head',
-    'tail',
-    'stat',
-    // rpiv-web-tools: querying/reading the web is read-only research up to an edit,
-    // not the environment-probing the no-edit bound targets, so it doesn't count.
-    'web_search',
-    'web_fetch',
-]);
-// The rpiv-web-tools calls, tracked separately so an unbounded run of them (with no
-// other tool call between) can be caught as a search loop — see `maxConsecutiveWebCalls`.
-const WEB_TOOLS = new Set(['web_search', 'web_fetch']);
-/** Read {@link ProgressGuardLimits} from the environment, falling back to the defaults. */
-export function progressGuardLimitsFromEnv(env = process.env) {
-    const num = (raw, fallback) => {
-        const n = Number(raw);
-        return Number.isFinite(n) && n > 0 ? Math.floor(n) : fallback;
-    };
-    return {
-        maxToolCallsWithoutEdit: num(env.JOB_MAX_TOOLCALLS_WITHOUT_EDIT, DEFAULT_PROGRESS_GUARD_LIMITS.maxToolCallsWithoutEdit),
-        maxConsecutiveErrors: num(env.JOB_MAX_CONSECUTIVE_TOOL_ERRORS, DEFAULT_PROGRESS_GUARD_LIMITS.maxConsecutiveErrors),
-        maxConsecutiveWebCalls: num(env.JOB_MAX_CONSECUTIVE_WEB_CALLS, DEFAULT_PROGRESS_GUARD_LIMITS.maxConsecutiveWebCalls),
-    };
-}
-/**
- * Apply per-knob overrides onto a base set of guard limits, ENFORCING loosen-only: an
- * override can only RAISE a knob (more headroom), never lower it below the base. A
- * larger value is more lenient for every knob (more no-edit tool calls / errors / web
- * calls tolerated), so each result is `max(base, override)`. This is a hard guarantee,
- * not a convention — a tuning entry (built-in or a custom kind's, which reaches this via
- * an untrusted job body) that supplies a value TIGHTER than the base is clamped back up
- * to the base rather than aborting a legitimately-progressing run. An absent/undefined
- * knob keeps the base value untouched.
- */
-export function mergeGuardLimits(base, overrides) {
-    if (!overrides)
-        return base;
-    const loosen = (b, o) => typeof o === 'number' ? Math.max(b, o) : b;
-    return {
-        maxToolCallsWithoutEdit: loosen(base.maxToolCallsWithoutEdit, overrides.maxToolCallsWithoutEdit),
-        maxConsecutiveErrors: loosen(base.maxConsecutiveErrors, overrides.maxConsecutiveErrors),
-        // `maxConsecutiveWebCalls` is optional on the interface (callers may omit it), so
-        // fall back to the default before loosening — keeps `loosen`'s base a concrete number.
-        maxConsecutiveWebCalls: loosen(base.maxConsecutiveWebCalls ?? DEFAULT_PROGRESS_GUARD_LIMITS.maxConsecutiveWebCalls, overrides.maxConsecutiveWebCalls),
-    };
-}
-/**
- * Live anti-rabbithole guard: fed each streamed Pi event, it returns a diagnostic
- * reason the moment a run has plainly stopped making progress, so the harness can
- * kill Pi early instead of letting it burn the whole budget (and then surface a
- * useful failure instead of a generic "no file changes"). Pure and incremental so
- * it can be unit-tested over a fixed event sequence.
- */
-export class ProgressGuard {
-    limits;
-    expectsEdits;
-    toolCalls = 0;
-    edits = 0;
-    consecutiveErrors = 0;
-    consecutiveWebCalls = 0;
-    constructor(limits, 
-    /** When false (assess-only runs like the merger), the no-edit bound is skipped. */
-    expectsEdits = true) {
-        this.limits = limits;
-        this.expectsEdits = expectsEdits;
-    }
-    /** Feed one parsed Pi event; returns a diagnostic reason when the run should abort, else null. */
-    observe(event) {
-        const tool = toolCallSignal(event);
-        if (!tool)
-            return null;
-        const name = tool.name.toLowerCase();
-        // The error streak tracks ANY tool call (a planning call still proves the agent
-        // isn't wedged in a failing-op loop), so it's updated before the planning skip.
-        this.consecutiveErrors = tool.isError ? this.consecutiveErrors + 1 : 0;
-        if (this.consecutiveErrors >= this.limits.maxConsecutiveErrors) {
-            return (`no progress: ${this.consecutiveErrors} consecutive failing tool calls — the agent is stuck ` +
-                `retrying a failing operation rather than making progress. Aborting.`);
-        }
-        // Web search/fetch loop: web tools are read-only (they don't count toward the
-        // no-edit bound), so guard them separately — an uninterrupted streak of them is a
-        // research rabbit-hole. Any non-web tool call resets the streak.
-        if (WEB_TOOLS.has(name)) {
-            this.consecutiveWebCalls++;
-            const webCap = this.limits.maxConsecutiveWebCalls ?? DEFAULT_PROGRESS_GUARD_LIMITS.maxConsecutiveWebCalls;
-            if (this.consecutiveWebCalls >= webCap) {
-                return (`no progress: ${this.consecutiveWebCalls} consecutive web search/fetch calls without ` +
-                    `any other action — the agent is stuck researching instead of doing the work. Aborting.`);
-            }
-        }
-        else {
-            this.consecutiveWebCalls = 0;
-        }
-        // Planning and read-only exploration calls don't count toward the no-edit bound
-        // (see PLANNING_TOOLS / EXPLORATION_TOOLS) — only "action" calls without an edit do.
-        if (PLANNING_TOOLS.has(name) || EXPLORATION_TOOLS.has(name))
-            return null;
-        this.toolCalls++;
-        if (FILE_EDIT_TOOLS.has(name))
-            this.edits++;
-        if (this.expectsEdits &&
-            this.edits === 0 &&
-            this.toolCalls >= this.limits.maxToolCallsWithoutEdit) {
-            return (`no progress: ${this.toolCalls} tool calls and not one file edit — the agent is exploring or ` +
-                `probing the environment without implementing anything. Aborting before it burns the whole run.`);
-        }
-        return null;
-    }
-}
+// The no-progress guard (its limits, tool vocabulary and the `ProgressGuard` itself) lives in
+// `progress-guard.ts` — it is shared with the claude-code runner, so it is no longer Pi's.
 /**
  * Run Pi non-interactively against `cwd` and return its assistant summary. Uses
  * print + JSON mode (`-p --mode json`) with `--approve` so it runs unattended.