@cat-factory/executor-harness 1.60.0 → 1.64.0

package/src/host-markdown.ts

@@ -0,0 +1,155 @@
+// ---------------------------------------------------------------------------
+// The TEXT BOUNDARY for agent-authored text the harness writes onto a VCS host.
+//
+// A pull-request description is NOT an inert string sink. The host parses it: `#123` becomes
+// an issue link, `@name` notifies a real person, a closing keyword in front of an issue
+// reference CLOSES that issue when the PR merges, and an unbalanced code fence swallows
+// everything rendered after it — including the fenced JSON block the engine later appends as
+// the verification report's machine-readable contract.
+//
+// The agent's reviewer briefing (`pr-description.ts`) is model-authored prose that lands
+// verbatim on that surface, so it crosses this boundary first. "This closes #42" is idiomatic
+// for a briefing to emit and must not close issue 42; "@alice owns the rounding rule" is
+// idiomatic and must not page whoever holds that handle.
+//
+// This is a deliberate COPY of `hostMarkdown` in `@cat-factory/kernel`
+// (`src/shared/host-markdown.logic.ts`), for the same reason `isSafeTestPath` is copied: the
+// container image is built from `src/` plus typescript alone (the Dockerfile cannot resolve a
+// `workspace:*` dependency), so the harness carries no runtime dependency on any package here.
+// `test/host-markdown.conformity.test.ts` pins the two implementations to byte-identical
+// output over a shared corpus, so the copy cannot drift — change one, change the other.
+// ---------------------------------------------------------------------------
+
+/**
+ * The host's closing keywords. A PR body carrying one of these in front of an issue reference
+ * closes that issue on merge — a side effect the harness must never trigger on the agent's
+ * behalf. Same list on GitHub and GitLab.
+ */
+const CLOSING_KEYWORDS =
+  'close[sd]?|closing|fix|fixe[sd]|fixing|resolve[sd]?|resolving|implement(?:s|ed)?|implementing'
+
+/** An issue/MR URL on either host, in the form a closing keyword can reference. */
+const ISSUE_URL = String.raw`https?://\S+?/(?:issues|-/issues|merge_requests|pull)/\d+`
+
+/**
+ * Every auto-linking trigger, in ONE alternation.
+ *
+ * Deliberately a single pass rather than chained `.replace()` calls: each escape EMITS a `#`,
+ * so a later rule would re-escape the output of an earlier one (`@` → `@` → `@`).
+ * One regex means the replacement text is never rescanned.
+ */
+const AUTO_LINK_TRIGGERS = new RegExp(
+  [
+    // A closing keyword in front of an issue/MR URL. The URL form survives the character
+    // escapes below (nothing in it is a trigger), so the KEYWORD is what gets defused.
+    String.raw`(?<keyword>\b(?:${CLOSING_KEYWORDS}))(?=\s*:?\s+${ISSUE_URL})`,
+    // `@name` / `@org/team` — a mention notifies a real account.
+    String.raw`(?<at>@(?=[A-Za-z0-9]))`,
+    // `#123` and `owner/repo#123` — an issue/PR cross-reference.
+    String.raw`(?<hash>#(?=\d))`,
+    // `!123` — GitLab's merge-request reference.
+    String.raw`(?<bang>!(?=\d))`,
+  ].join('|'),
+  'gi',
+)
+
+/**
+ * Neutralise the host's auto-linking triggers in ONE line of untrusted text, leaving inline
+ * code spans alone (the host does not auto-link inside them, so escaping there would only
+ * show the reader a literal `&#35;`).
+ *
+ * The escapes are numeric HTML entities, which render as the original character but are
+ * invisible to the reference parser — so the reader sees exactly what the agent wrote while
+ * the mention/close side effects are defused.
+ */
+function inertLine(line: string): string {
+  return mapOutsideCodeSpans(line, (text) =>
+    text.replace(AUTO_LINK_TRIGGERS, (match, ...args) => {
+      const groups = args[args.length - 1] as Record<string, string | undefined>
+      // Entity-escaping the FIRST character is enough to break the parser's match while
+      // rendering identically — which matters most for the keyword, whose remaining letters
+      // are ordinary prose the reader should still see.
+      return `&#${match.charCodeAt(0)};${groups.keyword ? match.slice(1) : ''}`
+    }),
+  )
+}
+
+/**
+ * Apply `fn` to the parts of `line` that are NOT inline code spans. Code spans are matched by
+ * a backtick run and its matching closer, which is CommonMark's rule and — more to the point
+ * — the rule the host renderer applies when deciding where to auto-link.
+ */
+function mapOutsideCodeSpans(line: string, fn: (text: string) => string): string {
+  const out: string[] = []
+  let index = 0
+  const span = /(`+)[\s\S]*?\1/g
+  let match: RegExpExecArray | null
+  while ((match = span.exec(line)) !== null) {
+    out.push(fn(line.slice(index, match.index)), match[0])
+    index = match.index + match[0].length
+  }
+  return out.join('') + fn(line.slice(index))
+}
+
+/** A line that opens or closes a fenced code block, with the fence it uses. */
+function fenceAt(line: string): { char: string; length: number; info: boolean } | null {
+  const match = /^ {0,3}(`{3,}|~{3,})(.*)$/.exec(line)
+  if (!match) return null
+  const fence = match[1]!
+  // A ``` fence's info string may not contain a backtick (CommonMark), which is what stops an
+  // inline span from being read as a fence.
+  if (fence.startsWith('`') && match[2]!.includes('`')) return null
+  return { char: fence[0]!, length: fence.length, info: match[2]!.trim().length > 0 }
+}
+
+/**
+ * Walk `lines`, tracking fenced-code state, and hand each line to `visit` together with
+ * whether it sits INSIDE a fenced block. Returns the fence still open at the end, if any.
+ *
+ * One shared walker so the three things that care about fences — leaving code untouched,
+ * closing what the text left open, and finding the briefing's title heading — can never
+ * disagree about where a block starts and ends.
+ */
+export function walkFences(
+  lines: readonly string[],
+  visit: (line: string, insideFence: boolean) => void,
+): { char: string; length: number } | null {
+  let open: { char: string; length: number } | null = null
+  for (const line of lines) {
+    const fence = fenceAt(line)
+    // The fence line itself belongs to the code block, so it is never rewritten.
+    visit(line, open !== null || fence !== null)
+    if (!fence) continue
+    if (!open) open = { char: fence.char, length: fence.length }
+    else if (fence.char === open.char && fence.length >= open.length && !fence.info) open = null
+  }
+  return open
+}
+
+/**
+ * Render untrusted multi-line markdown safe to send to a host: auto-link triggers defused
+ * outside fenced code, and any fence the text leaves open closed again.
+ *
+ * Unlike kernel's `hostMarkdown.prose` this does NOT cap the length — the caller
+ * ({@link import('./pr-description.js')}) applies its own budget with its own visible note
+ * BEFORE calling here, so an escape entity can never be sliced in half. With that one
+ * difference the output is identical, which the conformity test pins.
+ */
+export function inertMarkdown(text: string): string {
+  const normalised = text.replace(/\r\n?/g, '\n')
+  const rewritten: string[] = []
+  const open = walkFences(normalised.split('\n'), (line, insideFence) => {
+    rewritten.push(insideFence ? line : inertLine(line))
+  })
+  const joined = rewritten.join('\n')
+  return open ? `${joined}\n${open.char.repeat(open.length)}` : joined
+}
+
+/**
+ * Render untrusted text INLINE (a pull-request title): newlines folded to spaces because the
+ * surrounding line has its own meaning, and auto-link triggers defused. The caller caps the
+ * length first, for the same reason as {@link inertMarkdown}.
+ */
+export function inertInline(text: string): string {
+  return inertLine(text.replace(/\s+/g, ' '))
+}

package/src/pi-workspace.ts

@@ -1,4 +1,4 @@
-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 type { RepoSpec, SkillSpec } from './job.js'
@@ -8,13 +8,10 @@ import {
   type ContextFileInfo,
   type PiRunOutcome,
   type PiRunStats,
-  type ProgressGuardLimits,
   type RunDiagnostics,
   CONTEXT_DIR,
   materializeContextFiles,
   materializeSkillResources,
-  mergeGuardLimits,
-  progressGuardLimitsFromEnv,
   runPi,
   webSearchConfigFromEnv,
   webSearchProxyEnv,
@@ -22,6 +19,11 @@ import {
   writePiModelsConfig,
   writeWebToolsConfig,
 } from './pi.js'
+import {
+  type ProgressGuardLimits,
+  mergeGuardLimits,
+  progressGuardLimitsFromEnv,
+} from './progress-guard.js'
 import type { RunOptions } from './runner.js'
 import { type SubscriptionHarness, runSubscriptionHarness } from './agent-runner.js'
 
@@ -226,6 +228,31 @@ export interface AgentRunSpec {
   multiRepo?: boolean
 }
 
+/**
+ * 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: string, multiRepo: boolean): Promise<boolean> {
+  const isBlueprintDir = (path: string): Promise<boolean> =>
+    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
@@ -272,6 +299,13 @@ export async function runAgentInWorkspace(
       ...(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
@@ -303,11 +337,13 @@ export async function runAgentInWorkspace(
   }
   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/src/pi.ts

@@ -8,6 +8,12 @@ import { redactSecrets } from './redact.js'
 import { HarnessFailure } from './failure.js'
 import { log } from './logger.js'
 import type { EffortReport } from './effort.js'
+import {
+  ProgressGuard,
+  progressGuardLimitsFromEnv,
+  toolCallSignal,
+  type ProgressGuardLimits,
+} 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
@@ -106,21 +112,12 @@ for a module that is directly relevant to your task, when you need its summary a
 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
@@ -144,6 +141,12 @@ export async function writeAgentsContext(
     serviceDirectory?: string
     contextFiles?: ContextFileInfo[]
     multiRepo?: boolean
+    /**
+     * Whether the checkout actually ships a `blueprints/` folder. The blueprint orientation
+     * note is only appended when it does — otherwise it is ~10 lines of dead guidance (re-sent
+     * every turn) pointing at files that don't exist. Absent/false ⇒ the note is omitted.
+     */
+    hasBlueprints?: boolean
   } = {},
 ): Promise<void> {
   const dir = join(homedir(), '.pi', 'agent')
@@ -167,9 +170,14 @@ export async function writeAgentsContext(
   // 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 ?? [])
+  // 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_GUIDANCE}${SPEC_GUIDANCE}${TODO_GUIDANCE}${monorepo}${multiRepo}${webTools}${context}`,
+    `${systemPrompt}${blueprint}${TODO_GUIDANCE}${monorepo}${multiRepo}${webTools}${context}`,
     'utf8',
   )
 }
@@ -727,242 +735,8 @@ export function parseTodoProgress(event: Record<string, unknown>): TodoProgress
 
   return undefined
 }
-
-/** Tool-call signal read off a streamed Pi event, or undefined if not a tool call. */
-function toolCallSignal(
-  event: Record<string, unknown>,
-): { name: string; isError: boolean } | undefined {
-  // `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 }
-}
-
-/** Tunable bounds for the {@link ProgressGuard}. */
-export interface ProgressGuardLimits {
-  /**
-   * Abort once the agent has made this many NON-exploration tool calls without ever
-   * using a file-editing tool (see `FILE_EDIT_TOOLS`). The signature of the credential
-   * rabbit-hole that motivated this: probing the environment (`bash`/exec) endlessly
-   * without implementing anything. Read-only exploration (`read`/`grep`/… — see
-   * `EXPLORATION_TOOLS`) and planning (`todo`) do NOT count, so a large task that
-   * legitimately reads/searches many files before its first edit is not killed for it.
-   * Disabled when `expectsEdits` is false (e.g. the assess-only merger / Blueprinter,
-   * which legitimately edit nothing). Note this bound only guards the run UNTIL its
-   * first edit: once the agent has edited a file at all, it has demonstrably started
-   * the work, so only `maxConsecutiveErrors` guards a later stall.
-   */
-  maxToolCallsWithoutEdit: number
-  /**
-   * Abort after this many consecutive failing tool calls — the agent is stuck
-   * retrying an operation that keeps failing rather than making progress.
-   */
-  maxConsecutiveErrors: number
-  /**
-   * Abort after this many consecutive web-search/web-fetch calls with no other tool
-   * call in between. Web tools are read-only exploration (they don't count toward the
-   * no-edit bound), so without this a model could rabbit-hole on searches indefinitely
-   * without ever tripping a guard. Any non-web tool call resets the streak. Optional:
-   * defaults to {@link DEFAULT_PROGRESS_GUARD_LIMITS} when a caller builds limits
-   * without it.
-   */
-  maxConsecutiveWebCalls?: number
-}
-
-// `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,
-} satisfies ProgressGuardLimits
-
-// 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: NodeJS.ProcessEnv = process.env,
-): ProgressGuardLimits {
-  const num = (raw: string | undefined, fallback: number): number => {
-    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: ProgressGuardLimits,
-  overrides: Partial<ProgressGuardLimits> | undefined,
-): ProgressGuardLimits {
-  if (!overrides) return base
-  const loosen = (b: number, o: number | undefined): number =>
-    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 {
-  private toolCalls = 0
-  private edits = 0
-  private consecutiveErrors = 0
-  private consecutiveWebCalls = 0
-
-  constructor(
-    private readonly limits: ProgressGuardLimits,
-    /** When false (assess-only runs like the merger), the no-edit bound is skipped. */
-    private readonly expectsEdits: boolean = true,
-  ) {}
-
-  /** Feed one parsed Pi event; returns a diagnostic reason when the run should abort, else null. */
-  observe(event: Record<string, unknown>): string | null {
-    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