pullfrog 0.0.204 → 0.0.205

package/dist/index.js

@@ -18198,7 +18198,7 @@ var require_summary = __commonJS({
     exports.summary = exports.markdownSummary = exports.SUMMARY_DOCS_URL = exports.SUMMARY_ENV_VAR = void 0;
     var os_1 = __require("os");
     var fs_1 = __require("fs");
-    var { access, appendFile, writeFile: writeFile2 } = fs_1.promises;
+    var { access, appendFile, writeFile: writeFile3 } = fs_1.promises;
     exports.SUMMARY_ENV_VAR = "GITHUB_STEP_SUMMARY";
     exports.SUMMARY_DOCS_URL = "https://docs.github.com/actions/using-workflows/workflow-commands-for-github-actions#adding-a-job-summary";
     var Summary = class {
@@ -18256,7 +18256,7 @@ var require_summary = __commonJS({
         return __awaiter(this, void 0, void 0, function* () {
           const overwrite = !!(options === null || options === void 0 ? void 0 : options.overwrite);
           const filePath = yield this.filePath();
-          const writeFunc = overwrite ? writeFile2 : appendFile;
+          const writeFunc = overwrite ? writeFile3 : appendFile;
           yield writeFunc(filePath, this._buffer, { encoding: "utf8" });
           return this.emptyBuffer();
         });
@@ -62662,8 +62662,8 @@ var require_snapshot_utils = __commonJS({
 var require_snapshot_recorder = __commonJS({
   "node_modules/.pnpm/undici@7.22.0/node_modules/undici/lib/mock/snapshot-recorder.js"(exports, module) {
     "use strict";
-    var { writeFile: writeFile2, readFile, mkdir } = __require("node:fs/promises");
-    var { dirname: dirname4, resolve: resolve3 } = __require("node:path");
+    var { writeFile: writeFile3, readFile: readFile4, mkdir: mkdir2 } = __require("node:fs/promises");
+    var { dirname: dirname5, resolve: resolve3 } = __require("node:path");
     var { setTimeout: setTimeout2, clearTimeout: clearTimeout2 } = __require("node:timers");
     var { InvalidArgumentError, UndiciError } = require_errors4();
     var { hashId, isUrlExcludedFactory, normalizeHeaders, createHeaderFilters } = require_snapshot_utils();
@@ -62864,7 +62864,7 @@ var require_snapshot_recorder = __commonJS({
           throw new InvalidArgumentError("Snapshot path is required");
         }
         try {
-          const data = await readFile(resolve3(path3), "utf8");
+          const data = await readFile4(resolve3(path3), "utf8");
           const parsed2 = JSON.parse(data);
           if (Array.isArray(parsed2)) {
             this.#snapshots.clear();
@@ -62894,12 +62894,12 @@ var require_snapshot_recorder = __commonJS({
           throw new InvalidArgumentError("Snapshot path is required");
         }
         const resolvedPath = resolve3(path3);
-        await mkdir(dirname4(resolvedPath), { recursive: true });
+        await mkdir2(dirname5(resolvedPath), { recursive: true });
         const data = Array.from(this.#snapshots.entries()).map(([hash2, snapshot2]) => ({
           hash: hash2,
           snapshot: snapshot2
         }));
-        await writeFile2(resolvedPath, JSON.stringify(data, null, 2), { flush: true });
+        await writeFile3(resolvedPath, JSON.stringify(data, null, 2), { flush: true });
       }
       /**
        * Clears all recorded snapshots
@@ -97475,14 +97475,14 @@ var require_turndown_cjs = __commonJS({
         } else if (node2.nodeType === 1) {
           replacement = replacementForNode.call(self2, node2);
         }
-        return join16(output, replacement);
+        return join17(output, replacement);
       }, "");
     }
     function postProcess(output) {
       var self2 = this;
       this.rules.forEach(function(rule) {
         if (typeof rule.append === "function") {
-          output = join16(output, rule.append(self2.options));
+          output = join17(output, rule.append(self2.options));
         }
       });
       return output.replace(/^[\t\r\n]+/, "").replace(/[\t\r\n\s]+$/, "");
@@ -97494,7 +97494,7 @@ var require_turndown_cjs = __commonJS({
       if (whitespace.leading || whitespace.trailing) content = content.trim();
       return whitespace.leading + rule.replacement(content, node2, this.options) + whitespace.trailing;
     }
-    function join16(output, replacement) {
+    function join17(output, replacement) {
       var s1 = trimTrailingNewlines(output);
       var s2 = trimLeadingNewlines(replacement);
       var nls = Math.max(output.length - s1.length, replacement.length - s2.length);
@@ -98926,7 +98926,8 @@ var require_fast_content_type_parse = __commonJS({
 // main.ts
 var core6 = __toESM(require_core(), 1);
 import { existsSync as existsSync7, readdirSync } from "node:fs";
-import { join as join15 } from "node:path";
+import { readFile as readFile3 } from "node:fs/promises";
+import { join as join16 } from "node:path";
 
 // node_modules/.pnpm/@ark+util@0.56.0/node_modules/@ark/util/out/arrays.js
 var liftArray = (data) => Array.isArray(data) ? data : [data];
@@ -107422,7 +107423,7 @@ function buildCommitPrompt(status) {
   ].join("\n");
 }
 function hasPostRunIssues(issues) {
-  return issues.stopHook !== void 0 || issues.dirtyTree !== void 0;
+  return issues.stopHook !== void 0 || issues.dirtyTree !== void 0 || issues.summaryStale !== void 0;
 }
 var agent = (input) => {
   return {
@@ -108217,7 +108218,8 @@ var STRING_KEYS = [
   "issueNodeId",
   "reviewNodeId",
   "planCommentNodeId",
-  "summaryCommentNodeId"
+  "summaryCommentNodeId",
+  "summarySnapshot"
 ];
 var NUMBER_KEYS = [
   "inputTokens",
@@ -108937,43 +108939,22 @@ function addFooter(ctx, body) {
 var Comment = type({
   issueNumber: type.number.describe("the issue number to comment on"),
   body: type.string.describe("the comment body content"),
-  type: type.enumerated("Plan", "Summary", "Comment").describe(
-    "Plan: record as the plan for this run. Summary: record as the PR summary comment (one per PR, updated in place). Comment: regular comment (default)."
-  ).optional()
+  type: type.enumerated("Plan", "Comment").describe("Plan: record as the plan for this run. Comment: regular comment (default).").optional()
 });
 function CreateCommentTool(ctx) {
   return tool({
     name: "create_issue_comment",
-    description: "Create a comment on a GitHub issue or PR. For progress/plan updates on the current run use report_progress instead. Use type: 'Plan' for plan comments, type: 'Summary' for PR summary comments.",
+    description: "Create a comment on a GitHub issue or PR. For progress/plan updates on the current run use report_progress instead. Use type: 'Plan' for plan comments.",
     parameters: Comment,
     execute: execute(async ({ issueNumber, body, type: commentType }) => {
       const bodyWithFooter = addFooter(ctx, body);
-      if (commentType === "Summary" && ctx.toolState.existingSummaryCommentId) {
-        log.info(
-          `\xBB redirecting create_issue_comment(Summary) to update existing comment ${ctx.toolState.existingSummaryCommentId}`
-        );
-        const result2 = await ctx.octokit.rest.issues.updateComment({
-          owner: ctx.repo.owner,
-          repo: ctx.repo.name,
-          comment_id: ctx.toolState.existingSummaryCommentId,
-          body: bodyWithFooter
-        });
-        if (result2.data.node_id) {
-          await patchWorkflowRunFields(ctx, { summaryCommentNodeId: result2.data.node_id });
-        }
-        return {
-          success: true,
-          commentId: result2.data.id,
-          url: result2.data.html_url,
-          body: result2.data.body
-        };
-      }
       const result = await ctx.octokit.rest.issues.createComment({
         owner: ctx.repo.owner,
         repo: ctx.repo.name,
         issue_number: issueNumber,
         body: bodyWithFooter
       });
+      ctx.toolState.wasUpdated = true;
       if (commentType === "Plan") {
         if (result.data.node_id) {
           await patchWorkflowRunFields(ctx, { planCommentNodeId: result.data.node_id });
@@ -108994,9 +108975,6 @@ function CreateCommentTool(ctx) {
           body: updateResult.data.body
         };
       }
-      if (commentType === "Summary" && result.data.node_id) {
-        await patchWorkflowRunFields(ctx, { summaryCommentNodeId: result.data.node_id });
-      }
       return {
         success: true,
         commentId: result.data.id,
@@ -109152,15 +109130,15 @@ ${collapsible}`;
         reportParams.target_plan_comment = params.target_plan_comment;
       }
       const result = await reportProgress(ctx, reportParams);
-      if (!params.target_plan_comment) {
-        ctx.toolState.finalSummaryWritten = true;
-      }
       if (result.action === "skipped") {
         return {
           success: true,
           message: "progress recorded (no GitHub comment created - this may occur for workflow_dispatch events or when there is no associated issue/PR)"
         };
       }
+      if (!params.target_plan_comment) {
+        ctx.toolState.finalSummaryWritten = true;
+      }
       return {
         success: true,
         ...result
@@ -142265,7 +142243,7 @@ var import_semver = __toESM(require_semver2(), 1);
 // package.json
 var package_default = {
   name: "pullfrog",
-  version: "0.0.204",
+  version: "0.0.205",
   type: "module",
   bin: {
     pullfrog: "dist/cli.mjs",
@@ -142462,7 +142440,7 @@ function closeBrowserDaemon(toolState) {
 
 // mcp/checkout.ts
 import { createHash as createHash2 } from "node:crypto";
-import { writeFileSync } from "node:fs";
+import { statSync, unlinkSync as unlinkSync2, writeFileSync } from "node:fs";
 import { join as join3 } from "node:path";
 
 // utils/diffCoverage.ts
@@ -142491,7 +142469,10 @@ function createDiffCoverageState(params) {
     totalLines: params.totalLines,
     tocEntries: parseDiffTocEntries({ toc: params.toc }),
     coveredRanges: [],
-    coveragePreflightRan: false
+    // carry forward across checkout_pr refreshes so the nudge stays "once per
+    // review session". coveredRanges are intentionally not carried because
+    // line numbers are tied to the previous diff's content.
+    coveragePreflightRan: params.previous?.coveragePreflightRan ?? false
   };
 }
 function recordDiffReadFromToolUse(params) {
@@ -143295,6 +143276,11 @@ var GitFetch = type({
   ref: type.string.describe("Ref to fetch: branch name, tag, or 'pull/N/head' for PRs"),
   depth: type.number.describe("Fetch depth (for shallow clones)").optional()
 });
+var SHALLOW_UNREACHABLE_PATTERNS = [
+  /Could not read [a-f0-9]{40,64}/,
+  /remote did not send all necessary objects/
+];
+var DEEPEN_RETRY_DEPTH = 1e3;
 function GitFetchTool(ctx) {
   return tool({
     name: "git_fetch",
@@ -143306,9 +143292,20 @@ function GitFetchTool(ctx) {
       if (params.depth !== void 0) {
         fetchArgs.push(`--depth=${params.depth}`);
       }
-      await $git("fetch", fetchArgs, {
-        token: ctx.gitToken
-      });
+      try {
+        await $git("fetch", fetchArgs, { token: ctx.gitToken });
+      } catch (err) {
+        const msg = err instanceof Error ? err.message : String(err);
+        const isShallowUnreachable = SHALLOW_UNREACHABLE_PATTERNS.some((p) => p.test(msg));
+        const isShallow = isShallowUnreachable && $("git", ["rev-parse", "--is-shallow-repository"], { log: false }).trim() === "true";
+        if (!isShallow) throw err;
+        log.info(
+          `\xBB git_fetch hit shallow-unreachable error, retrying with --deepen=${DEEPEN_RETRY_DEPTH}`
+        );
+        await $git("fetch", [`--deepen=${DEEPEN_RETRY_DEPTH}`, "--no-tags", "origin", params.ref], {
+          token: ctx.gitToken
+        });
+      }
       return { success: true, ref: params.ref };
     })
   });
@@ -143673,6 +143670,7 @@ function CreatePullRequestReviewTool(ctx) {
         nodeId: reviewNodeId,
         reviewedSha: actuallyReviewedSha
       };
+      ctx.toolState.wasUpdated = true;
       await deleteProgressComment(ctx).catch((err) => {
         log.debug(`progress comment cleanup after review failed: ${err}`);
       });
@@ -144024,11 +144022,38 @@ async function ensureBeforeShaReachable(params) {
     return false;
   }
 }
+var STALE_LOCK_AGE_MS = 3e4;
+var GIT_LOCK_PATHS = [
+  ".git/shallow.lock",
+  ".git/index.lock",
+  ".git/objects/maintenance.lock"
+];
+function cleanupStaleGitLocks() {
+  const now = Date.now();
+  for (const relPath of GIT_LOCK_PATHS) {
+    let mtimeMs;
+    try {
+      mtimeMs = statSync(relPath).mtimeMs;
+    } catch {
+      continue;
+    }
+    if (now - mtimeMs < STALE_LOCK_AGE_MS) continue;
+    try {
+      unlinkSync2(relPath);
+      log.warning(`\xBB removed stale ${relPath} from prior run`);
+    } catch (e) {
+      log.debug(
+        `\xBB failed to remove stale ${relPath}: ${e instanceof Error ? e.message : String(e)}`
+      );
+    }
+  }
+}
 async function checkoutPrBranch(pr, params) {
   const { octokit, owner, name, gitToken, toolState, beforeSha } = params;
   log.info(`\xBB checking out PR #${pr.number}...`);
   rejectIfLeadingDash(pr.baseRef, "PR base ref");
   rejectIfLeadingDash(pr.headRef, "PR head ref");
+  cleanupStaleGitLocks();
   const isFork = pr.headRepoFullName !== pr.baseRepoFullName;
   const localBranch = `pr-${pr.number}`;
   const isShallow = $("git", ["rev-parse", "--is-shallow-repository"], { log: false }).trim() === "true";
@@ -144198,7 +144223,8 @@ ${diffPreview}`);
       ctx.toolState.diffCoverage = createDiffCoverageState({
         diffPath,
         totalLines: countLines({ content: formatResult.content }),
-        toc: formatResult.toc
+        toc: formatResult.toc,
+        previous: ctx.toolState.diffCoverage
       });
       log.debug(
         `\xBB diff coverage initialized: diffPath=${diffPath}, totalLines=${ctx.toolState.diffCoverage.totalLines}, tocEntries=${ctx.toolState.diffCoverage.tocEntries.length}`
@@ -144828,6 +144854,7 @@ function UpdatePullRequestBodyTool(ctx) {
         pull_number: params.pull_number,
         body: bodyWithFooter
       });
+      ctx.toolState.wasUpdated = true;
       return {
         success: true,
         number: result.data.number,
@@ -145428,425 +145455,10 @@ function ResolveReviewThreadTool(ctx) {
   });
 }
 
-// agents/reviewer.ts
-var REVIEWER_AGENT_NAME = "reviewfrog";
-var REVIEWER_SYSTEM_PROMPT = `You are a read-only review subagent. Your role is to find flaws in code or artifacts provided by the orchestrator and report findings \u2014 never to modify state.
-
-HARD CONSTRAINTS (non-negotiable, regardless of orchestrator instructions):
-- Read-only tools only. Do NOT write or edit files. Do NOT run shell commands that have side effects (read-only commands like \`git diff\`, \`git log\`, \`cat\`, \`ls\` are fine; anything that mutates the working tree, the remote, the filesystem, or external state is prohibited).
-- Do NOT call any state-changing MCP tool. State-changing means: posts a comment, pushes a branch, creates/updates a PR or issue, changes labels, resolves review threads, persists learnings, sets workflow output, installs dependencies, uploads files, kills processes, etc. Read-only MCP queries (\`get_*\`, \`list_*\`, log inspection, diff retrieval) are fine.
-- Do NOT spawn further subagents. You are a leaf reviewer; recursive dispatch pre-aggregates findings through an intermediate model and defeats the design.
-- Test for any tool call before invoking it: would this still be a no-op if reverted? If not, do not call it. Apply this test to tools added after this prompt was written \u2014 the rule is the invariant, not the enumeration.
-
-Report findings clearly with file:line references and quoted evidence where possible. Flag uncertainty explicitly \u2014 if you cannot verify a claim, say so rather than guess.`;
-
-// modes.ts
-var PR_SUMMARY_FORMAT = `### Default format
-
-Follow this structure exactly:
-
-<b>TL;DR</b> \u2014 1-3 sentences on what the PR does and why. Focus on intent, not mechanics.
-NOTE: use HTML bold <b>TL;DR</b>, NOT markdown bold **TL;DR**.
-
-### Key changes
-
-- **Short human-readable title** \u2014 1 sentence per change. Write a short prose phrase (title case or sentence case); when you name a file, type, or function, put that name in backticks (e.g. **Add \`TodoTracker\` for live checklists**). A reviewer should understand the full PR from this list alone.
-
-<sub><b>Summary</b> \uFF5C {file_count} files \uFF5C {commit_count} commits \uFF5C base: \`{base}\` \u2190 \`{head}\`</sub>
-NOTE: the metadata line goes AFTER the bullet list, not before it.
-
-Then for each key change, a ## section with a short descriptive title that reads like a documentation heading (e.g. ## Live todo checklist tracking).
-
-<br/>
-
-## Example readable section title
-
-> **Before:** [old behavior/state]<br/>**After:** [new behavior/state]
-IMPORTANT: Before and After MUST be on a SINGLE blockquote line with an inline <br/> between them. Two separate \`>\` lines creates a double line break.
-
-1-2 sentences of explanation. Break up text with tables, blockquotes, or lists \u2014 NEVER 3+ plain paragraphs in a row.
-
-If a change warrants deeper explanation, use a blockquoted details/summary framed as a question:
-> <details><summary>How does X work?</summary>
-> Extended explanation here.
-> </details>
-
-End each section with a file links trail (3-4 key files max):
-[\`file.ts\`](https://github.com/{owner}/{repo}/pull/{number}/files#diff-{sha256hex_of_filepath}) \xB7 ...
-
-Single-feature PRs: skip the ## sections. Fold before/after and explanation into the header after key changes.
-
-CRITICAL \u2014 GitHub markdown rendering rule:
-GitHub's markdown parser requires a blank line between ALL block-level elements. This includes transitions between: HTML tags (<br/>, <sub>, <details>, <b>, etc.) and markdown syntax (headings, lists, blockquotes, paragraphs). Without a blank line, GitHub treats the following content as a continuation of the HTML block and renders markdown syntax as literal text. ALWAYS separate block-level elements with a blank line.
-
-Rules:
-- \`##\` titles and key-change bullet lead-ins are plain-language summaries; backtick only actual code tokens (files, types, functions) where they appear in the title
-- ALL variable names, identifiers, and file names in body text must be in backticks
-- ALL file references MUST link to the PR Files Changed view. Use the \`diff-<hex>\` anchor precomputed next to each filename in the \`checkout_pr\` TOC \u2014 do NOT run \`sha256sum\` or any other shell command to compute anchors. NEVER fabricate hex strings. If a file is not in the TOC, omit the \`#diff-\` anchor rather than guessing.
-- Add <br/> before each ## heading for visual spacing. Do NOT use horizontal rules (---)
-- Do NOT include raw diff stats like '+123 / -45' or line counts
-- Do NOT include code blocks or repeat diff contents
-- Do NOT include a changelog section \u2014 the key changes list serves this purpose
-- Focus on *intent*, not *what* \u2014 the diff already shows what changed
-- Get the file count and commit count from the checkout_pr metadata, not by counting manually`;
-function learningsStep(t, n) {
-  return `${n}. **learnings** (only if high confidence): if you discovered something about repo setup, test commands, conventions, or patterns that you are confident is correct and would reliably help future runs, call \`${t("update_learnings")}\` to persist it. skip this step if you are unsure or the finding is speculative/one-off. format as a flat bullet list (\`- \` per line, one fact per bullet). merge with existing learnings from the prompt \u2014 pass the FULL merged list. deduplicate, and drop bullets that are clearly wrong or no longer relevant to the current codebase.`;
-}
-function computeModes(agentId) {
-  const t = (toolName) => formatMcpToolRef(agentId, toolName);
-  return [
-    {
-      name: "Build",
-      description: "Implement, build, create, or develop code changes; make specific changes to files or features; execute a plan; or handle tasks with specific implementation details",
-      prompt: `### Checklist
-
-1. **plan** (optional, for complex tasks): analyze requirements, read AGENTS.md and relevant code, produce a step-by-step implementation plan.
-
-2. **setup**: checkout or create the branch:
-   - **PR event, modifying the existing PR**: call \`${t("checkout_pr")}\`
-   - **new branch**: use \`${t("git")}\` to create a branch (\`git checkout -b pullfrog/branch-name\`)
-
-3. **build**: implement changes using your native file and shell tools:
-   - follow the plan (if you ran a plan phase)
-   - plan your approach before writing code: identify which files need to change, key design decisions, and edge cases. for non-trivial changes, consider whether there's a more elegant approach.
-   - run relevant tests/lints before committing
-
-4. **self-review**: judgment call \u2014 does YOUR diff warrant a fresh-eyes pass?
-
-   Skip self-review (commit directly) when the diff is **genuinely trivial**:
-   - doc typos, comment-only edits, whitespace/format-only, import reordering
-   - lockfile or generated-code regeneration, mechanical rename whose only effect is import-path updates (size of diff is irrelevant \u2014 read the *shape*, not the line count)
-   - low-risk dep patch bump from a trusted source
-
-   Run self-review when the diff has **any behavioral surface, however small**:
-   - 1-line changes to SQL operators / comparison logic / regexes / redirects / HTTP methods / response codes
-   - any change to money / tax / currency / billing / fee / refund / payout calculations or constants
-   - any change to auth / permissions / roles / sessions / tokens / signature verification
-   - any change to feature-flag defaults, retry counts, timeouts, rate limits, batch sizes
-   - new endpoints, new code paths, new error branches \u2014 even small ones
-   - mixed diffs (whitespace + a single semantic line) \u2014 the semantic line still triggers self-review
-   - anything you're uncertain about
-
-   Tie-breaker: when in doubt, run self-review. One false-positive subagent dispatch costs cents; one false-negative shipped bug costs much more. There's no value in dispatching for a typo, but there's also no excuse for skipping on a 1-line change to a billing path.
-
-   Otherwise delegate the \`${REVIEWER_AGENT_NAME}\` subagent to review your diff with fresh eyes against YOUR TASK. The subagent's baked-in system prompt enforces a non-mutative + non-recursive contract: read-only file/search/web tools and read-only MCP queries only; no writes, shell side effects, state-changing MCP calls, or nested subagent dispatch. Enforcement is prose-only \u2014 restate the constraint in your dispatch instructions and do not relax it.
-
-   Provide the subagent with YOUR TASK, the output of \`git diff\`, and a tight summary (not raw output) of any lint/typecheck/test failures you fixed during build \u2014 what broke, root cause, the fix \u2014 so it can check that fixes addressed root causes rather than suppressed symptoms; say "no build-phase failures" if the build path was clean. Instruct it to flag bugs, logic errors, missing edge cases, gaps between request and diff, and unintended changes.
-
-   Delegation + research discipline (distilled from \`/anneal\` canonical \u2014 these are codified learnings from many review rounds, not theoretical best practices):
-   - Do NOT summarize what you implemented \u2014 that biases the subagent toward validating the shape of your solution rather than questioning it.
-   - Do NOT curate a reading list of files. Let the subagent discover scope from the diff and codebase.
-   - Do NOT pre-shape output with a severity / category schema. That leaks your hypotheses; severity is your call during evaluation.
-   - Do NOT defect-hunt the diff yourself in parallel with the subagent. Your role is dispatch + evaluation; doing the review yourself reintroduces the implementation bias the subagent is meant to mitigate.
-   - For diffs that rely on third-party API contracts, SDK semantics, framework directives, or DB engine specifics, instruct the subagent to verify load-bearing claims via web search and quote source URLs rather than trust training data \u2014 this is the single most common review-quality failure mode.
-
-   Review the findings, address valid points, and discard nitpicks or false positives. The reviewer is fallible \u2014 it biases toward *recommending additions* (defensive checks for impossible cases, extra logging, new abstractions used once, comments restating code, tests asserting tautologies, "just-in-case" guards). For each finding, ask: would applying it leave the code more sound, correct, AND elegant? Two-out-of-three is not enough \u2014 a fix that improves correctness while degrading elegance still degrades the codebase. Reject bloat-shaped findings without applying them, and after applying the rest re-read your diff and be discerning about what *you just changed*: if any fix turned out to be bloat in context, revert it. The goal is code that is sound and correct *while remaining elegant*; the smallest diff that fixes the real defect almost always wins. Then verify only intended changes are present, no debug artifacts or commented-out code remain, no unrelated files were modified. Commit locally via shell (\`git add . && git commit -m "..."\`).
-
-5. **finalize**:
-   - confirm a clean working tree, then push via \`${t("push_branch")}\` (see *SYSTEM* Git rules if this fails \u2014 prepush errors are usually the repo's tests/lint, not infra timeouts)
-   - create a PR via \`${t("create_pull_request")}\`
-   - call \`${t("report_progress")}\` with the PR link or the exact error if push/PR failed
-
-${learningsStep(t, 6)}
-
-### Notes
-
-For simple, well-defined tasks, skip the plan phase and go straight to build.`
-    },
-    {
-      name: "AddressReviews",
-      description: "Address PR review feedback; respond to reviewer comments; make requested changes to an existing PR",
-      prompt: `### Checklist
-
-1. Checkout the PR branch via \`${t("checkout_pr")}\`.
-
-2. Fetch review comments via \`${t("get_review_comments")}\`.
-
-3. For each comment:
-   - understand the feedback
-   - evaluate whether applying it would leave the code more **sound, correct, AND elegant**. reviewers are fallible and bias toward *recommending additions* (defensive checks for impossible cases, extra abstractions, comments restating obvious code, tests asserting tautologies, "just-in-case" guards). if a request would add bloat \u2014 ceremony without commensurate correctness benefit \u2014 push back in your reply rather than mechanically applying it. two-out-of-three is not enough; improving correctness while degrading elegance still degrades the code.
-   - if the request stands, make the code change using your native tools; otherwise reply explaining why
-   - record what was done (or why nothing was done)
-
-4. Quality check:
-   - test changes, then review the diff before committing \u2014 verify only intended changes are present, no debug artifacts remain, no fix turned out to be bloat in context (revert any that did), and the changes are clean enough that a senior engineer would approve without hesitation
-   - commit locally via shell (\`git add . && git commit -m "..."\`)
-
-5. Finalize:
-   - confirm a clean working tree, then push via \`${t("push_branch")}\` (same push/prepush guidance as Build mode in *SYSTEM*)
-   - reply to each comment using \`${t("reply_to_review_comment")}\`
-   - resolve addressed threads via \`${t("resolve_review_thread")}\`
-   - call \`${t("report_progress")}\` with a brief summary (or the exact push error if push failed)
-
-${learningsStep(t, 6)}`
-    },
-    // Review and IncrementalReview use the multi-lens orchestrator pattern
-    // (canonical source: .claude/commands/anneal.md). The orchestrator does
-    // triage → parallel read-only subagent fan-out → aggregate → draft comments
-    // → submit. For someone else's PR, parallel lenses (correctness, security,
-    // research-validated claims, user-journey, etc.) provide breadth across
-    // angles that a single subagent can't carry coherently. Build mode keeps
-    // a single fresh-eyes subagent (different problem shape — orchestrator
-    // wrote the code and bias-mitigation comes from delegating to one
-    // subagent that doesn't share the implementation context).
-    // Deliberate omission vs canonical /anneal: severity categorization in the
-    // final message (the review body has its own CAUTION/IMPORTANT framing
-    // instead of a severity table).
-    {
-      name: "Review",
-      description: "Review code, PRs, or implementations; provide feedback or suggestions; identify issues; or check code quality, style, and correctness",
-      prompt: `### Checklist
-
-1. **checkout**: call \`${t("checkout_pr")}\` \u2014 this returns PR metadata and a \`diffPath\`. read the diff TOC end-to-end and treat its file line ranges as your coverage checklist.
-
-2. **triage**: orient yourself on the PR \u2014 identify *what kind of thing this is* (domain it touches, seams it crosses, external contracts it depends on, user-facing surfaces it changes). orientation only \u2014 defer specific defect-hunting to the subagents; pre-reviewing biases the lenses you pick. use \`${t("get_pull_request")}\` and other read-only GitHub tools for additional context if needed.
-
-   if the PR is **genuinely trivial**, skip steps 3\u20134 entirely and submit \`Reviewed \u2014 no issues found.\` per step 5. there's no value in dispatching even one lens for a typo.
-
-   "Genuinely trivial" (skip):
-   - single-word doc typo, whitespace/format-only, comment-only across any number of files
-   - lockfile or generated-code regeneration (size of diff is irrelevant \u2014 read the *shape*)
-   - mechanical rename whose only effect is import-path updates
-   - low-risk dep patch bump
-
-   "Looks trivial but isn't" (do **NOT** skip \u2014 small diff, big blast radius):
-   - any 1-line change to SQL / regex / auth / billing / permission / signature-verification code
-   - flipping a feature-flag default, default config value, or retry/timeout constant
-   - changing a money/tax/currency/fee constant by any amount
-   - changing an HTTP method, redirect URL, response code, or status enum
-   - tightening or loosening a comparison operator (\`<\` \u2194 \`<=\`, \`==\` \u2194 \`!=\`)
-   - renaming a public API surface (still trivial in shape, but needs an impact lens)
-   - adding a new direct dependency (supply-chain surface)
-   - any "typo fix" in user-facing copy that changes meaning ("approved" \u2192 "denied")
-   - mixed diffs where a semantic 1-liner is buried in whitespace/formatting changes
-
-   When unsure, treat as non-trivial. The cost of one extra subagent is cents; the cost of a missed billing/auth/data bug is much more.
-
-   otherwise pick lenses by where the PR concentrates risk \u2014 **there's no fixed count**. lens count is judgment, not a formula. concrete shapes to anchor against:
-
-   - **1 lens** \u2014 pure refactor / mechanical rename across many files (impact); new test file with no source change (test-integrity); small isolated bug fix (correctness); doc-only PR with non-trivial technical content (research-validated or holistic)
-   - **2\u20133 lenses (most PRs land here)** \u2014 new CRUD endpoint (correctness + security + test-integrity); new UI flow (user-journey + correctness); a single bug fix in a non-critical subsystem (correctness + test-integrity); design doc covering one domain (research-validated + correctness or holistic)
-   - **4\u20135 lenses (high-stakes subsystem touches)** \u2014 any billing/payments change (billing-subsystem + correctness + security + operational-readiness); new auth flow (auth-subsystem + correctness + security + test-integrity); schema migration (schema-migration-subsystem + correctness + operational-readiness + impact); cross-subsystem PR that touches billing AND auth AND schema (one subsystem lens per domain + correctness)
-   - **6+ lenses** \u2014 almost always a smell; you're either covering overlapping ground or this PR should have been split. push back via the review body rather than expanding lens count.
-
-   lenses come in two flavors, and you can mix them:
-   - **themed lenses** \u2014 a perspective applied across the whole diff (correctness, security, user-journey, performance, etc.).
-   - **subsystem lenses** \u2014 a domain-scoped frame for high-stakes subsystems the PR touches (e.g. "the auth lens", "the billing lens", "the schema-migration lens"). a subsystem lens is "review the PR specifically for what could go wrong in this subsystem" and naturally combines theme + scope. **for high-stakes domains, lead with the subsystem lens rather than the generic themed equivalent** \u2014 "billing-subsystem" outperforms "correctness on billing code" because the framing primes the subagent to remember domain-specific failure modes (double-charges, refund races, currency rounding, dispute flows) the generic lens misses.
-
-   starter menu (combine, omit, or invent your own):
-   - **correctness & invariants** \u2014 bugs, races, error handling, edge cases, state-machine boundaries
-   - **impact** \u2014 when the PR removes features, deletes exports, renames identifiers, or changes architectural patterns: stale references in code, tests, docs (\`docs/\`, \`wiki/\`), comments, configs, UI
-   - **research-validated assumptions** \u2014 third-party API contracts, SDK semantics, framework directives, version-gated behavior. the subagent must verify load-bearing claims via web search and quote source URLs.
-   - **security** \u2014 new endpoints, authZ, input validation, secrets handling, replay/CSRF/injection, cross-tenant isolation
-   - **user-journey** \u2014 UX-touching flows: walk through happy path and failure modes as a user
-   - **operational readiness** \u2014 observability, alerting, migrations (forward + rollback), feature flags, on-call burden
-   - **integration & cross-cutting** \u2014 API contracts between modules, backward-compat of public surfaces, multi-service ordering
-   - **test integrity** \u2014 meaningful coverage for the changed behavior; deterministic; no shared-state pollution
-   - **performance** \u2014 N+1 queries, hot-path allocation, latency budgets, index coverage
-   - **holistic** \u2014 does the PR make sense as a whole? symmetric flows (delete for every create, rollback for every migration)?
-   - **subsystem lenses** (invent as the PR demands) \u2014 auth, billing, payments, schema migration, webhooks, secrets, RBAC, multi-tenant isolation, cron/scheduling, etc.
-
-3. **fan out**: dispatch one \`${REVIEWER_AGENT_NAME}\` subagent per lens \u2014 its baked-in system prompt enforces the non-mutative + non-recursive contract (read-only file/search/web tools and read-only MCP queries; no writes, shell side effects, state-changing MCP calls, or nested subagent dispatch). when picking 2+ lenses, dispatch them in a **single assistant turn with multiple parallel subagent calls**; issuing one and awaiting reply before the next collapses the fan-out into a serial review. if a subagent errors out, times out, or returns nothing usable, retry once with the same lens; if it still fails, proceed with partial coverage and note the missing lens in the review body \u2014 do not skip step 3 entirely on a single subagent failure. each subagent gets:
-   - the diff path / target \u2014 reading the diff and the codebase is its job
-   - **only one lens** \u2014 never a multi-section "review for X, Y, and Z" prompt
-   - **a Task \`description\` set to the lens name** (e.g. \`"security"\`, \`"correctness"\`, \`"billing-subsystem"\`) \u2014 the harness reads this field to label the subagent's log lines so parallel runs can be told apart in CI output. without it, every subagent shows up as \`subagent#N\`.
-   - the read-only contract restated in your dispatch instructions so the rule is present twice (the subagent's system prompt also enforces it). The test: would this call still be a no-op if reverted? If not (PR comments, branch pushes, issue updates, set_output, label changes, dependency installs, etc.), don't make it.
-   - if the lens touches external contracts, instruct the subagent to verify load-bearing claims via web search rather than trust training data, and to quote source URLs in its reasoning. action runs are non-interactive \u2014 there's no human in the loop to catch "I'm pretty sure Stripe does X."
-   - ask the subagent to report findings with file paths and NEW line numbers from the diff so you can anchor inline comments without re-reading the entire diff.
-
-   delegation discipline:
-   - do NOT lens-review the diff yourself in parallel with the subagents (your job is dispatch + comment-drafting; doing the lens work yourself reintroduces the bias the fan-out avoids)
-   - do NOT summarize the PR for them (biases toward a validation frame)
-   - do NOT hand them a curated reading list (let them discover scope)
-   - do NOT pre-shape their output with a finding schema
-   - do NOT mention the other lenses (independence is the point \u2014 overlapping findings are a strong signal)
-
-4. **aggregate & draft**: merge findings; de-dup overlaps (two lenses catching the same issue = higher-confidence signal); trace each finding yourself before accepting it. drop praise, style preferences, speculative/unverified claims, findings about pre-existing code unrelated to the PR (heuristic: if the finding's root cause lives in lines this PR added or modified, it's in scope; otherwise drop unless the PR plausibly introduced or amplified the regression), and anything not actionable. also drop **bloat-shaped findings** \u2014 proposed fixes that would add defensive checks for cases that can't happen, abstractions used once, comments restating obvious code, tests asserting tautologies, or "just-in-case" guards. subagents are fallible and bias toward recommending changes; the bar for an actionable inline comment is sound + correct + elegant. recommending a change that improves only one of the three (or worse, degrades elegance to nominally improve correctness) makes the codebase worse, not better.
-
-   for surviving findings, draft inline comments with NEW line numbers from the diff. every comment must be actionable, 2-3 sentences max. use GitHub permalink format for code references. for impact-analysis findings (stale references after rename/remove), report them in the review body ordered by severity (runtime breakage > incorrect docs > stale comments) rather than as inline comments unless they're anchored to a specific line.
-
-5. **submit**: ALWAYS submit exactly one review via \`${t("create_pull_request_review")}\`. Do NOT call \`report_progress\` \u2014 the review is the final record and the progress comment will be cleaned up automatically.
-
-   note: the first create_pull_request_review submission may error with a one-time diff-coverage nudge listing unread TOC regions. retry the same call to proceed \u2014 optionally after reading the listed ranges. the pre-flight will not block again this session.
-
-   - **critical issues** (blocks merge \u2014 bugs, security, data loss):
-     \`approved: false\`. Body begins with a GitHub alert blockquote, e.g.:
-     \`> [!CAUTION]\\n> This PR introduces a race condition in ...\`
-     Follow with a brief summary if needed. Include all inline comments.
-   - **recommended changes** (non-critical):
-     \`approved: false\`. Body begins with a GitHub alert blockquote, e.g.:
-     \`> [!IMPORTANT]\\n> Consider adding input validation for ...\`
-     Follow with a brief summary if needed. Include all inline comments.
-   - **no actionable issues**:
-     \`approved: true\`, body: "Reviewed \u2014 no issues found."`
-    },
-    // IncrementalReview shares Review's multi-lens orchestrator pattern but
-    // scopes the target to the incremental diff and adds prior-review-feedback
-    // tracking. The "issues must be NEW since the last Pullfrog review" filter
-    // lives at aggregation time (step 5), NOT in the subagent prompt — pushing
-    // the filter into subagents matches the canonical anneal anti-pattern of
-    // "list known pre-existing failures — don't flag these" and suppresses
-    // signal on regressions the new commits amplified. The body-format rules
-    // (Reviewed changes / Prior review feedback) are unchanged from the prior
-    // version. Same severity-table omission as Review.
-    {
-      name: "IncrementalReview",
-      description: "Re-review a PR after new commits are pushed; focus on new changes since the last review",
-      prompt: `### Checklist
-
-1. **checkout**: call \`${t("checkout_pr")}\` \u2014 this returns PR metadata, \`diffPath\` (full diff), and \`incrementalDiffPath\` (changes since last reviewed version, if available). read the diff TOC first and use its line ranges as your coverage checklist.
-
-2. **incremental scope**: if \`incrementalDiffPath\` is present, read it to see what changed since the last review. this is a range-diff that isolates the net changes, filtering out base branch noise. if not present, fall back to reviewing the full PR diff and determine what changed since Pullfrog's most recent review.
-
-3. **prior feedback**: fetch previous reviews via \`${t("list_pull_request_reviews")}\`. for the most recent Pullfrog review, call \`${t("get_review_comments")}\` with the review ID to retrieve specific prior line-level feedback. you'll need this in step 6 to track which prior comments were addressed.
-
-4. **triage & fan out**: orient on the *incremental* changes \u2014 domain, seams, external contracts, user-facing surfaces.
-
-   if the incremental changes are **genuinely trivial**, skip the fan-out entirely and jump to step 7's non-substantive path (do NOT submit a review).
-
-   "Genuinely trivial" (skip): formatting/comment tweaks, import reordering, lockfile regen, mechanical rename of import paths, whitespace-only.
-   "Looks trivial but isn't" (do NOT skip \u2014 same anti-patterns as Review mode): 1-line changes to SQL/regex/auth/billing/permissions/signature-verification code; flipping feature-flag defaults or retry/timeout constants; money/tax/HTTP-method/redirect changes; tightening or loosening a comparison operator; mixed diffs with a semantic line buried in formatting.
-   When unsure, treat as non-trivial.
-
-   otherwise pick lenses by where the new commits concentrate risk \u2014 **there's no fixed count**, same calibration as Review mode (1 lens for pure refactor / isolated fix; 2\u20133 for typical features; 4\u20135 for high-stakes subsystem touches; 6+ is a smell). lens framing follows Review mode: themed lenses (correctness & invariants, impact when new commits remove/rename/deprecate things, research-validated assumptions, security, user-journey, operational readiness, integration & cross-cutting, test integrity, performance, holistic) and subsystem lenses (auth, billing, schema migration, etc.) \u2014 for high-stakes domains lead with the subsystem lens rather than the generic themed equivalent.
-
-   dispatch one \`${REVIEWER_AGENT_NAME}\` subagent per lens \u2014 its baked-in system prompt enforces the non-mutative + non-recursive contract (read-only file/search/web tools and read-only MCP queries; no writes, shell side effects, state-changing MCP calls, or nested subagent dispatch). dispatch them in a **single assistant turn with multiple parallel subagent calls** (serial dispatch collapses the fan-out). if a subagent errors out, times out, or returns nothing usable, retry once with the same lens; if it still fails, proceed with partial coverage and note the missing lens in the review body \u2014 do not skip step 4 entirely on a single subagent failure. each subagent gets:
-   - the diff scope (incremental diff path if available, full diff otherwise). do NOT tell them to skip pre-existing issues \u2014 that suppresses regressions the new commits amplified; the "issues must be NEW" filter lives at aggregation time (step 5), not in the subagent prompt
-   - **only one lens** \u2014 never a multi-section "review for X, Y, and Z" prompt
-   - **a Task \`description\` set to the lens name** (e.g. \`"security"\`, \`"correctness"\`, \`"billing-subsystem"\`) \u2014 the harness reads this field to label the subagent's log lines so parallel runs can be told apart in CI output. without it, every subagent shows up as \`subagent#N\`.
-   - the read-only contract restated in your dispatch instructions so the rule is present twice (the subagent's system prompt also enforces it). The test: would this call still be a no-op if reverted? If not (PR comments, branch pushes, issue updates, set_output, label changes, dependency installs, etc.), don't make it.
-   - if the lens touches external contracts, instruct the subagent to verify load-bearing claims via web search and quote source URLs. action runs are non-interactive \u2014 there's no human to catch "I'm pretty sure Stripe does X."
-   - ask the subagent to report findings with file paths and NEW line numbers from the full PR diff so you can anchor inline comments.
-
-   delegation discipline:
-   - do NOT lens-review the diff yourself in parallel with the subagents
-   - do NOT summarize the changes for them (biases toward validation frame)
-   - do NOT hand them a curated reading list (let them discover scope)
-   - do NOT pre-shape their output with a finding schema
-   - do NOT mention the other lenses (independence is the point)
-
-5. **aggregate, draft, self-critique**: merge findings; de-dup overlaps; trace each finding yourself. drop praise, style preferences, speculative/unverified claims, findings about pre-existing code unrelated to the new commits, anything not actionable, and anything that re-states prior review feedback (heuristic: if the finding's root cause lives in lines the *new commits* added or modified, it's in scope; otherwise drop). also drop **bloat-shaped findings** \u2014 proposed fixes that would add defensive checks for cases that can't happen, abstractions used once, comments restating obvious code, tests asserting tautologies, or "just-in-case" guards. subagents are fallible and bias toward recommending changes; the bar for an actionable inline comment is sound + correct + elegant. recommending a change that improves only one of the three (or degrades elegance to nominally improve correctness) makes the codebase worse, not better. To compute "lines the new commits added or modified": if \`incrementalDiffPath\` from step 1 is present, use it directly. Otherwise, take the prior Pullfrog review's \`commit_id\` (returned alongside each entry from \`${t("list_pull_request_reviews")}\` in step 3) and run \`git diff <prior-review-sha>..HEAD\` to isolate the lines added since that review. draft inline comments with NEW line numbers from the full PR diff \u2014 every comment must be actionable, 2-3 sentences max.
-
-   then check: which prior review comments were addressed by the new commits? track the addressed ones for step 6b.
-
-6. **build the review body** \u2014 two distinct sections:
-   a. **Reviewed changes**: summarize at the logical-change level, not per-file. each bullet starts with a past-tense verb (e.g. \`- Extracted shared CLI runtime into a single module\`, \`- Renamed package to pullfrog\`). avoid file paths unless they add clarity. if the changes can be described in one sentence, use one sentence \u2014 no bullets needed.
-   b. **Prior review feedback** (only if any were addressed): list only the prior review comments that WERE addressed by the new commits (\`- [x] safeParse instead of parse \u2014 addressed\`). omit unaddressed comments. omit this entire section if nothing was addressed. a change can appear in both sections.
-   - no headings, no tables, no prose paragraphs in either section \u2014 just bullets
-   - in some cases you may receive a complete diff for the whole pull request instead of an incremental one. when this happens, you will need to determine what changes have happened since Pullfrog's most recent review.
-
-7. Submit \u2014 Do NOT call \`report_progress\` or \`create_issue_comment\` \u2014 the review is the final record and the progress comment will be cleaned up automatically. the review body always includes the reviewed changes from step 6a. append \`Prior review feedback:\\n\` with the checklist from step 6b only if any prior comments were addressed. Follow these rules:
-   - note: the first create_pull_request_review submission may error with a one-time diff-coverage nudge listing unread TOC regions. retry the same call to proceed \u2014 optionally after reading the listed ranges. the pre-flight will not block again this session.
-   - IF NO NEW ISSUES, NON-SUBSTANTIVE CHANGES ONLY (trivial formatting, import reordering, comment tweaks): do NOT submit a review. Do NOT call \`report_progress\`. Exit \u2014 the progress comment will be cleaned up automatically.
-   - ELSE IF NEW CRITICAL ISSUES (blocks merge): call \`${t("create_pull_request_review")}\` with \`approved: false\`, all comments, and the review body. body opens with a GitHub alert blockquote (e.g. \`> [!CAUTION]\\n> This PR introduces ...\`), then the reviewed changes summary and prior feedback (if any).
-   - ELSE IF NEW RECOMMENDED CHANGES (non-critical): call \`${t("create_pull_request_review")}\` with \`approved: false\`, all comments, and the review body. body opens with \`> [!IMPORTANT]\\n> ...\` alert, then the reviewed changes summary and prior feedback (if any).
-   - ELSE IF NO NEW ISSUES, SUBSTANTIVE CHANGES (new functionality, behavior changes, or fixes to prior review feedback): call \`${t("create_pull_request_review")}\` to create a PR review. If all previous reviews have been properly addressed and no new issues were discovered, you can set \`approved: true\`. body opens with \`No new issues. Reviewed the following changes:\\n\`, then the reviewed changes summary and prior feedback (if any).`
-    },
-    {
-      name: "Plan",
-      description: "Create plans, break down tasks, outline steps, analyze requirements, understand scope of work, or provide task breakdowns",
-      prompt: `### Checklist
-
-1. Analyze the task and gather context:
-   - read AGENTS.md and relevant codebase files
-   - understand the architecture and constraints
-
-2. Produce a structured, actionable plan with clear milestones.
-
-3. Call \`${t("report_progress")}\` with the plan.
-
-${learningsStep(t, 4)}`
-    },
-    {
-      name: "Fix",
-      description: "Fix CI failures; debug failing tests or builds; investigate and resolve check suite failures",
-      prompt: `### Checklist
-
-1. Checkout the PR branch via \`${t("checkout_pr")}\`.
-
-2. Fetch check suite logs via \`${t("get_check_suite_logs")}\`.
-
-3. **CRITICAL**: verify the failure was INTRODUCED BY THIS PR before fixing. If unrelated, abort and report.
-
-4. Diagnose and fix:
-   - read the workflow file, reproduce locally with the EXACT same commands CI runs
-   - fix the issue using your native file and shell tools
-   - verify the fix by re-running the exact CI command
-   - review the diff before committing \u2014 verify only the fix is present, no debug artifacts, no unrelated changes. the fix should be clean enough that a senior engineer would approve without hesitation.
-   - commit locally via shell (\`git add . && git commit -m "..."\`)
-
-5. Finalize:
-   - confirm a clean working tree, then push via \`${t("push_branch")}\` (same push/prepush guidance as Build mode in *SYSTEM*)
-   - call \`${t("report_progress")}\` with the diagnosis and fix summary (or the exact push error if push failed)
-
-${learningsStep(t, 6)}`
-    },
-    {
-      name: "ResolveConflicts",
-      description: "Resolve merge conflicts in a PR branch against the base branch",
-      prompt: `### Checklist
-
-1. **Setup**:
-   - Call \`${t("checkout_pr")}\` to get the PR branch.
-   - Call \`${t("get_pull_request")}\` to identify the base branch (e.g., 'main').
-   - Call \`${t("git_fetch")}\` to fetch the base branch.
-
-2. **Merge Attempt**:
-   - Run \`git merge origin/<base_branch>\` via shell.
-   - If it succeeds automatically, confirm a clean working tree, push via \`${t("push_branch")}\` (same push/prepush guidance as Build mode in *SYSTEM*), and call \`${t("report_progress")}\` with a brief success note or the exact push error if push failed \u2014 **then stop; do not run steps 3\u20134.**
-   - If it fails (conflicts), resolve them manually (continue to steps 3\u20134).
-
-3. **Resolve Conflicts**:
-   - Run \`git status\` or parse the merge output to find the list of conflicting files.
-   - For each conflicting file: read it, find the conflict markers (\`<<<<<<<\`, \`=======\`, \`>>>>>>>\`), understand the code context, and rewrite the file with the correct resolution. Remove all markers.
-   - Verify the file syntax is correct after resolution.
-
-4. **Finalize**:
-   - Run a final verification (build/test) to ensure the resolution works.
-   - \`git add . && git commit -m "resolve merge conflicts"\`
-   - confirm a clean working tree, then push via \`${t("push_branch")}\` (same push/prepush guidance as Build mode in *SYSTEM*)
-   - Call \`${t("report_progress")}\` with a summary of what was resolved (or the exact push error if push failed)`
-    },
-    {
-      name: "Task",
-      description: "General-purpose tasks that don't fit other modes: answering questions, adding comments, labeling, running ad-hoc commands, or any direct request",
-      prompt: `### Checklist
-
-1. Analyze the task. For simple operations (labeling, commenting, answering questions, running a single command), handle directly.
-
-2. For substantial work \u2014 code changes across multiple files, multi-step investigations:
-   - plan your approach before starting
-   - use native file and shell tools for local operations
-   - use ${pullfrogMcpName} MCP tools for GitHub/git operations
-   - if code changes are needed: review your own diff before committing \u2014 verify only intended changes are present, no debug artifacts remain, and the changes are clean enough that a senior engineer would approve without hesitation
-
-3. Finalize:
-   - if code changes were made, push to a pull request (new or existing) using \`${t("push_branch")}\` and \`${t("create_pull_request")}\` as needed. \`git status\` must be clean before you finish (see *SYSTEM* Git rules if push fails).
-   - call \`${t("report_progress")}\` once with results \u2014 include exact tool errors if push or PR creation failed
-   - if the task involved labeling, commenting, or other GitHub operations, perform those directly
-
-${learningsStep(t, 4)}`
-    },
-    {
-      name: "Summarize",
-      description: "Summarize a PR with a structured comment that is updated in place on subsequent pushes",
-      prompt: `### Checklist
-
-1. Checkout the PR via \`${t("checkout_pr")}\` \u2014 this returns PR metadata and a \`diffPath\`.
-2. Read the diff using the TOC to selectively read relevant sections (not the entire file). Produce a structured summary. If EVENT INSTRUCTIONS specify a custom format, follow that instead of the default format below.
-3. Call \`${t("create_issue_comment")}\` with \`type: "Summary"\` and the summary body.
-4. Call \`${t("report_progress")}\` with a brief note (e.g., "Posted PR summary.").
-
-${PR_SUMMARY_FORMAT}`
-    }
-  ];
-}
-var modes = computeModes("opencode");
-
 // mcp/selectMode.ts
 var SelectModeParams = type({
   mode: type.string.describe(
-    "the name of the mode to select (e.g., 'Build', 'Plan', 'Review', 'IncrementalReview', 'Fix', 'AddressReviews', 'Task', 'ResolveConflicts', 'Summarize')"
+    "the name of the mode to select (e.g., 'Build', 'Plan', 'Review', 'IncrementalReview', 'Fix', 'AddressReviews', 'Task', 'ResolveConflicts')"
   ),
   "issue_number?": type("number").describe(
     "optional issue number; when provided with Plan mode, used to look up an existing plan comment for this issue (edit vs create)"
@@ -145867,18 +145479,7 @@ An existing plan comment was found for this issue. Update that comment with the
    - gather relevant codebase context (file paths, architecture notes from AGENTS.md)
    - produce a structured plan with clear milestones
 3. Call \`${t("report_progress")}\` with the full revised plan text and \`{ target_plan_comment: true }\` so it updates the existing plan comment (not the progress comment).
-4. Then post a short note to the progress comment (e.g. "Plan has been updated in the comment above.") via \`${t("report_progress")}\` so it is not left as "Leaping...".`,
-    SummaryUpdate: `### Checklist (updating existing summary)
-
-An existing summary comment was found for this PR. Update it rather than creating a new one.
-
-1. Use \`previousSummaryBody\` from this response as the current summary to revise.
-2. Checkout the PR via \`${t("checkout_pr")}\` \u2014 this returns PR metadata and a \`diffPath\`.
-3. Read the diff using the TOC to selectively read relevant sections. Produce an updated summary reflecting the current state of the PR, using the existing summary (\`previousSummaryBody\`) as a starting point. If EVENT INSTRUCTIONS specify a custom format, follow that instead of the default format below.
-4. Call \`${t("edit_issue_comment")}\` with \`commentId: existingSummaryCommentId\` (from this response) and the updated summary body.
-5. Call \`${t("report_progress")}\` with a brief note (e.g., "Updated PR summary.").
-
-${PR_SUMMARY_FORMAT}`
+4. Then post a short note to the progress comment (e.g. "Plan has been updated in the comment above.") via \`${t("report_progress")}\` so it is not left as "Leaping...".`
   };
 }
 var modeInstructionParent = {
@@ -145911,30 +145512,22 @@ async function fetchExistingPlanComment(ctx, issueNumber) {
     return null;
   }
 }
-async function fetchExistingSummaryComment(ctx, prNumber) {
-  if (!ctx.githubInstallationToken) {
-    log.warning("fetchExistingSummaryComment: no token, skipping");
-    return null;
-  }
-  const path3 = `/api/repo/${ctx.repo.owner}/${ctx.repo.name}/pr/${prNumber}/summary-comment`;
-  try {
-    const response = await apiFetch({
-      path: path3,
-      method: "GET",
-      headers: { authorization: `Bearer ${ctx.githubInstallationToken}` },
-      signal: AbortSignal.timeout(1e4)
-    });
-    const data = await response.json();
-    if (response.ok && "commentId" in data) {
-      return data;
-    }
-    const errMsg = "error" in data ? data.error : "(no error body)";
-    log.warning(`fetchExistingSummaryComment: ${response.status} ${path3} \u2014 ${errMsg}`);
-    return null;
-  } catch (error49) {
-    log.warning("fetchExistingSummaryComment failed:", error49);
-    return null;
-  }
+var SUMMARY_MODES = /* @__PURE__ */ new Set(["Review", "IncrementalReview", "Task"]);
+function buildSummaryAddendum(t, ctx) {
+  const filePath = ctx.toolState.summaryFilePath;
+  if (!filePath) return "";
+  return `### PR summary snapshot \u2014 required step
+
+A rolling PR summary lives at \`${filePath}\`. It is your durable cross-run agent context \u2014 a functional summary of what this PR does, the subsystems and files it touches, the material behavior of its changes, and any risks or open questions worth carrying forward. It is NOT a chronological log of past review runs; commit-level history can already be reconstructed from \`${t("list_pull_request_reviews")}\`.
+
+How to use it:
+
+- read \`${filePath}\` at the START of the run, alongside the diff. it represents what previous agent runs already understood about this PR \u2014 absorb it before picking lenses or crafting subagent dispatch prompts. if it's a fresh seed (file is one or two lines), this is a first review and you'll be filling it in from the diff.
+- let the snapshot inform triage and dispatch. when it already tracks a risk, your lens prompts to subagents are stronger when they reference that context (e.g. "the JSDoc explicitly scopes to code points \u2014 do not flag grapheme-cluster issues" if the snapshot already documents that contract). when something the snapshot tracks is now resolved by new commits, note that. when new commits introduce something the snapshot doesn't yet describe, that's exactly where your fan-out should focus.
+- update the file in place to reflect the PR's CURRENT state. revise stale claims, drop resolved risks, add new behavior or risks. accuracy over breadth \u2014 every claim must be grounded in the diff. write for the next agent run, not for a human.
+- structure however serves THIS PR. there is no required section template. a refactor might organize by renamed export and call-site impact; a feature by capability; a billing change by money path. a compact note of which commit ranges have been reviewed should always be present so future runs scope correctly, but the rest is your call. when the structure works across runs, keep it stable so range-diffs are clean; when the PR's character changes (e.g. scope expands), reshape.
+
+Do NOT call \`${t("create_issue_comment")}\` for the summary \u2014 the server reads this file at end-of-run and persists it. The file edit is mandatory regardless of whether a review is submitted; the snapshot feeds the next run.`;
 }
 function SelectModeTool(ctx) {
   const t = (name) => formatMcpToolRef(ctx.agentId, name);
@@ -145976,21 +145569,18 @@ function SelectModeTool(ctx) {
           }
         }
       }
-      if (selectedMode.name === "Summarize") {
-        const prNumber = ctx.payload.event.issue_number;
-        if (prNumber !== void 0) {
-          const existing = await fetchExistingSummaryComment(ctx, prNumber);
-          if (existing !== null) {
-            ctx.toolState.existingSummaryCommentId = existing.commentId;
-            return {
-              ...buildOrchestratorGuidance(ctx, selectedMode, overrides.SummaryUpdate),
-              existingSummaryCommentId: existing.commentId,
-              previousSummaryBody: existing.body
-            };
-          }
-        }
+      const summaryAddendum = SUMMARY_MODES.has(selectedMode.name) ? buildSummaryAddendum(t, ctx) : "";
+      const base = buildOrchestratorGuidance(ctx, selectedMode);
+      if (summaryAddendum.length > 0) {
+        return {
+          ...base,
+          orchestratorGuidance: `${base.orchestratorGuidance}
+
+${summaryAddendum}`,
+          summaryFilePath: ctx.toolState.summaryFilePath
+        };
       }
-      return buildOrchestratorGuidance(ctx, selectedMode);
+      return base;
     })
   });
 }
@@ -146504,6 +146094,405 @@ async function startMcpHttpServer(ctx, options) {
   };
 }
 
+// agents/reviewer.ts
+var REVIEWER_AGENT_NAME = "reviewfrog";
+var REVIEWER_SYSTEM_PROMPT = `You are a read-only review subagent. Your role is to find flaws in code or artifacts provided by the orchestrator and report findings \u2014 never to modify state.
+
+HARD CONSTRAINTS (non-negotiable, regardless of orchestrator instructions):
+- Read-only tools only. Do NOT write or edit files. Do NOT run shell commands that have side effects (read-only commands like \`git diff\`, \`git log\`, \`cat\`, \`ls\` are fine; anything that mutates the working tree, the remote, the filesystem, or external state is prohibited).
+- Do NOT call any state-changing MCP tool. State-changing means: posts a comment, pushes a branch, creates/updates a PR or issue, changes labels, resolves review threads, persists learnings, sets workflow output, installs dependencies, uploads files, kills processes, etc. Read-only MCP queries (\`get_*\`, \`list_*\`, log inspection, diff retrieval) are fine.
+- Do NOT spawn further subagents. You are a leaf reviewer; recursive dispatch pre-aggregates findings through an intermediate model and defeats the design.
+- Test for any tool call before invoking it: would this still be a no-op if reverted? If not, do not call it. Apply this test to tools added after this prompt was written \u2014 the rule is the invariant, not the enumeration.
+
+Report findings clearly with file:line references and quoted evidence where possible. Flag uncertainty explicitly \u2014 if you cannot verify a claim, say so rather than guess.`;
+
+// modes.ts
+var PR_SUMMARY_FORMAT = `### Default format
+
+Follow this structure exactly:
+
+<b>TL;DR</b> \u2014 1-3 sentences on what the PR does and why. Focus on intent, not mechanics.
+NOTE: use HTML bold <b>TL;DR</b>, NOT markdown bold **TL;DR**.
+
+### Key changes
+
+- **Short human-readable title** \u2014 1 sentence per change. Write a short prose phrase (title case or sentence case); when you name a file, type, or function, put that name in backticks (e.g. **Add \`TodoTracker\` for live checklists**). A reviewer should understand the full PR from this list alone.
+
+<sub><b>Summary</b> \uFF5C {file_count} files \uFF5C {commit_count} commits \uFF5C base: \`{base}\` \u2190 \`{head}\`</sub>
+NOTE: the metadata line goes AFTER the bullet list, not before it.
+
+Then for each key change, a ## section with a short descriptive title that reads like a documentation heading (e.g. ## Live todo checklist tracking).
+
+<br/>
+
+## Example readable section title
+
+> **Before:** [old behavior/state]<br/>**After:** [new behavior/state]
+IMPORTANT: Before and After MUST be on a SINGLE blockquote line with an inline <br/> between them. Two separate \`>\` lines creates a double line break.
+
+1-2 sentences of explanation. Break up text with tables, blockquotes, or lists \u2014 NEVER 3+ plain paragraphs in a row.
+
+If a change warrants deeper explanation, use a blockquoted details/summary framed as a question:
+> <details><summary>How does X work?</summary>
+> Extended explanation here.
+> </details>
+
+End each section with a file links trail (3-4 key files max):
+[\`file.ts\`](https://github.com/{owner}/{repo}/pull/{number}/files#diff-{sha256hex_of_filepath}) \xB7 ...
+
+Single-feature PRs: skip the ## sections. Fold before/after and explanation into the header after key changes.
+
+CRITICAL \u2014 GitHub markdown rendering rule:
+GitHub's markdown parser requires a blank line between ALL block-level elements. This includes transitions between: HTML tags (<br/>, <sub>, <details>, <b>, etc.) and markdown syntax (headings, lists, blockquotes, paragraphs). Without a blank line, GitHub treats the following content as a continuation of the HTML block and renders markdown syntax as literal text. ALWAYS separate block-level elements with a blank line.
+
+Rules:
+- \`##\` titles and key-change bullet lead-ins are plain-language summaries; backtick only actual code tokens (files, types, functions) where they appear in the title
+- ALL variable names, identifiers, and file names in body text must be in backticks
+- ALL file references MUST link to the PR Files Changed view. Use the \`diff-<hex>\` anchor precomputed next to each filename in the \`checkout_pr\` TOC \u2014 do NOT run \`sha256sum\` or any other shell command to compute anchors. NEVER fabricate hex strings. If a file is not in the TOC, omit the \`#diff-\` anchor rather than guessing.
+- Add <br/> before each ## heading for visual spacing. Do NOT use horizontal rules (---)
+- Do NOT include raw diff stats like '+123 / -45' or line counts
+- Do NOT include code blocks or repeat diff contents
+- Do NOT include a changelog section \u2014 the key changes list serves this purpose
+- Focus on *intent*, not *what* \u2014 the diff already shows what changed
+- Get the file count and commit count from the checkout_pr metadata, not by counting manually`;
+function learningsStep(t, n) {
+  return `${n}. **learnings** (only if high confidence): if you discovered something about repo setup, test commands, conventions, or patterns that you are confident is correct and would reliably help future runs, call \`${t("update_learnings")}\` to persist it. skip this step if you are unsure or the finding is speculative/one-off. format as a flat bullet list (\`- \` per line, one fact per bullet). merge with existing learnings from the prompt \u2014 pass the FULL merged list. deduplicate, and drop bullets that are clearly wrong or no longer relevant to the current codebase.`;
+}
+function computeModes(agentId) {
+  const t = (toolName) => formatMcpToolRef(agentId, toolName);
+  return [
+    {
+      name: "Build",
+      description: "Implement, build, create, or develop code changes; make specific changes to files or features; execute a plan; or handle tasks with specific implementation details",
+      prompt: `### Checklist
+
+1. **plan** (optional, for complex tasks): analyze requirements, read AGENTS.md and relevant code, produce a step-by-step implementation plan.
+
+2. **setup**: checkout or create the branch:
+   - **PR event, modifying the existing PR**: call \`${t("checkout_pr")}\`
+   - **new branch**: use \`${t("git")}\` to create a branch (\`git checkout -b pullfrog/branch-name\`)
+
+3. **build**: implement changes using your native file and shell tools:
+   - follow the plan (if you ran a plan phase)
+   - plan your approach before writing code: identify which files need to change, key design decisions, and edge cases. for non-trivial changes, consider whether there's a more elegant approach.
+   - run relevant tests/lints before committing
+
+4. **self-review**: judgment call \u2014 does YOUR diff warrant a fresh-eyes pass?
+
+   Skip self-review (commit directly) when the diff is **genuinely trivial**:
+   - doc typos, comment-only edits, whitespace/format-only, import reordering
+   - lockfile or generated-code regeneration, mechanical rename whose only effect is import-path updates (size of diff is irrelevant \u2014 read the *shape*, not the line count)
+   - low-risk dep patch bump from a trusted source
+
+   Run self-review when the diff has **any behavioral surface, however small**:
+   - 1-line changes to SQL operators / comparison logic / regexes / redirects / HTTP methods / response codes
+   - any change to money / tax / currency / billing / fee / refund / payout calculations or constants
+   - any change to auth / permissions / roles / sessions / tokens / signature verification
+   - any change to feature-flag defaults, retry counts, timeouts, rate limits, batch sizes
+   - new endpoints, new code paths, new error branches \u2014 even small ones
+   - mixed diffs (whitespace + a single semantic line) \u2014 the semantic line still triggers self-review
+   - anything you're uncertain about
+
+   Tie-breaker: when in doubt, run self-review. One false-positive subagent dispatch costs cents; one false-negative shipped bug costs much more. There's no value in dispatching for a typo, but there's also no excuse for skipping on a 1-line change to a billing path.
+
+   Otherwise delegate the \`${REVIEWER_AGENT_NAME}\` subagent to review your diff with fresh eyes against YOUR TASK. The subagent's baked-in system prompt enforces a non-mutative + non-recursive contract: read-only file/search/web tools and read-only MCP queries only; no writes, shell side effects, state-changing MCP calls, or nested subagent dispatch. Enforcement is prose-only \u2014 restate the constraint in your dispatch instructions and do not relax it.
+
+   Provide the subagent with YOUR TASK, the output of \`git diff\`, and a tight summary (not raw output) of any lint/typecheck/test failures you fixed during build \u2014 what broke, root cause, the fix \u2014 so it can check that fixes addressed root causes rather than suppressed symptoms; say "no build-phase failures" if the build path was clean. Instruct it to flag bugs, logic errors, missing edge cases, gaps between request and diff, and unintended changes.
+
+   Delegation + research discipline (distilled from \`/anneal\` canonical \u2014 these are codified learnings from many review rounds, not theoretical best practices):
+   - Do NOT summarize what you implemented \u2014 that biases the subagent toward validating the shape of your solution rather than questioning it.
+   - Do NOT curate a reading list of files. Let the subagent discover scope from the diff and codebase.
+   - Do NOT pre-shape output with a severity / category schema. That leaks your hypotheses; severity is your call during evaluation.
+   - Do NOT defect-hunt the diff yourself in parallel with the subagent. Your role is dispatch + evaluation; doing the review yourself reintroduces the implementation bias the subagent is meant to mitigate.
+   - For diffs that rely on third-party API contracts, SDK semantics, framework directives, or DB engine specifics, instruct the subagent to verify load-bearing claims via web search and quote source URLs rather than trust training data \u2014 this is the single most common review-quality failure mode.
+
+   Review the findings, address valid points, and discard nitpicks or false positives. The reviewer is fallible \u2014 it biases toward *recommending additions* (defensive checks for impossible cases, extra logging, new abstractions used once, comments restating code, tests asserting tautologies, "just-in-case" guards). For each finding, ask: would applying it leave the code more sound, correct, AND elegant? Two-out-of-three is usually a signal to look harder for a fix that gets all three before settling for one that trades elegance for correctness. Reject bloat-shaped findings without applying them, and after applying the rest re-read your diff and be discerning about what *you just changed*: if any fix turned out to be bloat in context, revert it. The goal is code that is sound and correct *while remaining elegant*; the smallest diff that fixes the real defect almost always wins. Then verify only intended changes are present, no debug artifacts or commented-out code remain, no unrelated files were modified. Commit locally via shell (\`git add . && git commit -m "..."\`).
+
+5. **finalize**:
+   - confirm a clean working tree, then push via \`${t("push_branch")}\` (see *SYSTEM* Git rules if this fails \u2014 prepush errors are usually the repo's tests/lint, not infra timeouts)
+   - create a PR via \`${t("create_pull_request")}\`
+   - call \`${t("report_progress")}\` with the PR link or the exact error if push/PR failed
+
+${learningsStep(t, 6)}
+
+### Notes
+
+For simple, well-defined tasks, skip the plan phase and go straight to build.`
+    },
+    {
+      name: "AddressReviews",
+      description: "Address PR review feedback; respond to reviewer comments; make requested changes to an existing PR",
+      prompt: `### Checklist
+
+1. Checkout the PR branch via \`${t("checkout_pr")}\`.
+
+2. Fetch review comments via \`${t("get_review_comments")}\`.
+
+3. For each comment:
+   - understand the feedback
+   - evaluate whether applying it would leave the code more **sound, correct, AND elegant**. reviewers are fallible and bias toward *recommending additions* (defensive checks for impossible cases, extra abstractions, comments restating obvious code, tests asserting tautologies, "just-in-case" guards). if a request would add bloat \u2014 ceremony without commensurate correctness benefit \u2014 push back in your reply rather than mechanically applying it. two-out-of-three is usually a signal to look harder for a fix that gets all three before settling.
+   - if the request stands, make the code change using your native tools; otherwise reply explaining why
+   - record what was done (or why nothing was done)
+
+4. Quality check:
+   - test changes, then review the diff before committing \u2014 verify only intended changes are present, no debug artifacts remain, no fix turned out to be bloat in context (revert any that did), and the changes are clean enough that a senior engineer would approve without hesitation
+   - commit locally via shell (\`git add . && git commit -m "..."\`)
+
+5. Finalize:
+   - confirm a clean working tree, then push via \`${t("push_branch")}\` (same push/prepush guidance as Build mode in *SYSTEM*)
+   - reply to each comment using \`${t("reply_to_review_comment")}\`
+   - resolve addressed threads via \`${t("resolve_review_thread")}\`
+   - call \`${t("report_progress")}\` with a brief summary (or the exact push error if push failed)
+
+${learningsStep(t, 6)}`
+    },
+    // Review and IncrementalReview use the multi-lens orchestrator pattern
+    // (canonical source: .claude/commands/anneal.md). The orchestrator does
+    // triage → parallel read-only subagent fan-out → aggregate → draft comments
+    // → submit. For someone else's PR, parallel lenses (correctness, security,
+    // research-validated claims, user-journey, etc.) provide breadth across
+    // angles that a single subagent can't carry coherently. Build mode keeps
+    // a single fresh-eyes subagent (different problem shape — orchestrator
+    // wrote the code and bias-mitigation comes from delegating to one
+    // subagent that doesn't share the implementation context).
+    // Deliberate omission vs canonical /anneal: severity categorization in the
+    // final message (the review body has its own CAUTION/IMPORTANT framing
+    // instead of a severity table).
+    {
+      name: "Review",
+      description: "Review code, PRs, or implementations; provide feedback or suggestions; identify issues; or check code quality, style, and correctness",
+      prompt: `### Checklist
+
+1. **checkout**: call \`${t("checkout_pr")}\` \u2014 this returns PR metadata and a \`diffPath\`. read the diff TOC end-to-end and treat its file line ranges as your coverage checklist.
+
+2. **triage**: orient yourself on the PR \u2014 identify *what kind of thing this is* (domain it touches, seams it crosses, external contracts it depends on, user-facing surfaces it changes). orientation only \u2014 defer specific defect-hunting to the subagents; pre-reviewing biases the lenses you pick. use \`${t("get_pull_request")}\` and other read-only GitHub tools for additional context if needed.
+
+   if the PR is **genuinely trivial**, skip steps 3\u20134 entirely and submit a \`No new issues found.\` review per step 5. there's no value in dispatching even one lens for a typo.
+
+   "Genuinely trivial" (skip):
+   - single-word doc typo, whitespace/format-only, comment-only across any number of files
+   - lockfile or generated-code regeneration (size of diff is irrelevant \u2014 read the *shape*)
+   - mechanical rename whose only effect is import-path updates
+   - low-risk dep patch bump
+
+   "Looks trivial but isn't" (do **NOT** skip \u2014 small diff, big blast radius):
+   - any 1-line change to SQL / regex / auth / billing / permission / signature-verification code
+   - flipping a feature-flag default, default config value, or retry/timeout constant
+   - changing a money/tax/currency/fee constant by any amount
+   - changing an HTTP method, redirect URL, response code, or status enum
+   - tightening or loosening a comparison operator (\`<\` \u2194 \`<=\`, \`==\` \u2194 \`!=\`)
+   - renaming a public API surface (still trivial in shape, but needs an impact lens)
+   - adding a new direct dependency (supply-chain surface)
+   - any "typo fix" in user-facing copy that changes meaning ("approved" \u2192 "denied")
+   - mixed diffs where a semantic 1-liner is buried in whitespace/formatting changes
+
+   When unsure, treat as non-trivial. The cost of one extra subagent is cents; the cost of a missed billing/auth/data bug is much more.
+
+   otherwise pick lenses by where the PR concentrates risk \u2014 **there's no fixed count**. lens count is judgment, not a formula. concrete shapes to anchor against:
+
+   - **1 lens** \u2014 pure refactor / mechanical rename across many files (impact); new test file with no source change (test-integrity); small isolated bug fix (correctness); doc-only PR with non-trivial technical content (research-validated or holistic)
+   - **2\u20133 lenses (most PRs land here)** \u2014 new CRUD endpoint (correctness + security + test-integrity); new UI flow (user-journey + correctness); a single bug fix in a non-critical subsystem (correctness + test-integrity); design doc covering one domain (research-validated + correctness or holistic)
+   - **4\u20135 lenses (high-stakes subsystem touches)** \u2014 any billing/payments change (billing-subsystem + correctness + security + operational-readiness); new auth flow (auth-subsystem + correctness + security + test-integrity); schema migration (schema-migration-subsystem + correctness + operational-readiness + impact); cross-subsystem PR that touches billing AND auth AND schema (one subsystem lens per domain + correctness)
+   - **6+ lenses** \u2014 almost always a smell; you're either covering overlapping ground or this PR should have been split. push back via the review body rather than expanding lens count.
+
+   lenses come in two flavors, and you can mix them:
+   - **themed lenses** \u2014 a perspective applied across the whole diff (correctness, security, user-journey, performance, etc.).
+   - **subsystem lenses** \u2014 a domain-scoped frame for high-stakes subsystems the PR touches (e.g. "the auth lens", "the billing lens", "the schema-migration lens"). a subsystem lens is "review the PR specifically for what could go wrong in this subsystem" and naturally combines theme + scope. **for high-stakes domains, lead with the subsystem lens rather than the generic themed equivalent** \u2014 "billing-subsystem" outperforms "correctness on billing code" because the framing primes the subagent to remember domain-specific failure modes (double-charges, refund races, currency rounding, dispute flows) the generic lens misses.
+
+   starter menu (combine, omit, or invent your own):
+   - **correctness & invariants** \u2014 bugs, races, error handling, edge cases, state-machine boundaries
+   - **impact** \u2014 when the PR removes features, deletes exports, renames identifiers, or changes architectural patterns: stale references in code, tests, docs (\`docs/\`, \`wiki/\`), comments, configs, UI
+   - **research-validated assumptions** \u2014 third-party API contracts, SDK semantics, framework directives, version-gated behavior. the subagent must verify load-bearing claims via web search and quote source URLs.
+   - **security** \u2014 new endpoints, authZ, input validation, secrets handling, replay/CSRF/injection, cross-tenant isolation
+   - **user-journey** \u2014 UX-touching flows: walk through happy path and failure modes as a user
+   - **operational readiness** \u2014 observability, alerting, migrations (forward + rollback), feature flags, on-call burden
+   - **integration & cross-cutting** \u2014 API contracts between modules, backward-compat of public surfaces, multi-service ordering
+   - **test integrity** \u2014 meaningful coverage for the changed behavior; deterministic; no shared-state pollution
+   - **performance** \u2014 N+1 queries, hot-path allocation, latency budgets, index coverage
+   - **holistic** \u2014 does the PR make sense as a whole? symmetric flows (delete for every create, rollback for every migration)?
+   - **subsystem lenses** (invent as the PR demands) \u2014 auth, billing, payments, schema migration, webhooks, secrets, RBAC, multi-tenant isolation, cron/scheduling, etc.
+
+3. **fan out**: dispatch one \`${REVIEWER_AGENT_NAME}\` subagent per lens \u2014 its baked-in system prompt enforces the non-mutative + non-recursive contract (read-only file/search/web tools and read-only MCP queries; no writes, shell side effects, state-changing MCP calls, or nested subagent dispatch). when picking 2+ lenses, dispatch them in a **single assistant turn with multiple parallel subagent calls**; issuing one and awaiting reply before the next collapses the fan-out into a serial review. if a subagent errors out, times out, or returns nothing usable, retry once with the same lens; if it still fails, proceed with partial coverage and note the missing lens in the review body \u2014 do not skip step 3 entirely on a single subagent failure. each subagent gets:
+   - the diff path / target \u2014 reading the diff and the codebase is its job
+   - **only one lens** \u2014 never a multi-section "review for X, Y, and Z" prompt
+   - **a Task \`description\` set to the lens name** (e.g. \`"security"\`, \`"correctness"\`, \`"billing-subsystem"\`) \u2014 the harness reads this field to label the subagent's log lines so parallel runs can be told apart in CI output. without it, every subagent shows up as \`subagent#N\`.
+   - the read-only contract restated in your dispatch instructions so the rule is present twice (the subagent's system prompt also enforces it). The test: would this call still be a no-op if reverted? If not (PR comments, branch pushes, issue updates, set_output, label changes, dependency installs, etc.), don't make it.
+   - if the lens touches external contracts, instruct the subagent to verify load-bearing claims via web search rather than trust training data, and to quote source URLs in its reasoning. action runs are non-interactive \u2014 there's no human in the loop to catch "I'm pretty sure Stripe does X."
+   - ask the subagent to report findings with file paths and NEW line numbers from the diff so you can anchor inline comments without re-reading the entire diff.
+
+   delegation discipline:
+   - do NOT lens-review the diff yourself in parallel with the subagents (your job is dispatch + comment-drafting; doing the lens work yourself reintroduces the bias the fan-out avoids)
+   - do NOT summarize the PR for them (biases toward a validation frame)
+   - do NOT hand them a curated reading list (let them discover scope)
+   - do NOT pre-shape their output with a finding schema
+   - do NOT mention the other lenses (independence is the point \u2014 overlapping findings are a strong signal)
+
+4. **aggregate & draft**: merge findings; de-dup overlaps (two lenses catching the same issue = higher-confidence signal); trace each finding yourself before accepting it. drop praise, style preferences, speculative/unverified claims, findings about pre-existing code unrelated to the PR (heuristic: if the finding's root cause lives in lines this PR added or modified, it's in scope; otherwise drop unless the PR plausibly introduced or amplified the regression), and anything not actionable. also drop **bloat-shaped findings** \u2014 proposed fixes that would add defensive checks for cases that can't happen, abstractions used once, comments restating obvious code, tests asserting tautologies, or "just-in-case" guards. subagents are fallible and bias toward recommending changes; the bar for an actionable inline comment is sound + correct + elegant. recommending a change that improves only one of the three (or worse, degrades elegance to nominally improve correctness) makes the codebase worse, not better.
+
+   for surviving findings, draft inline comments with NEW line numbers from the diff. every comment must be actionable, 2-3 sentences max. use GitHub permalink format for code references. for impact-analysis findings (stale references after rename/remove), report them in the review body ordered by severity (runtime breakage > incorrect docs > stale comments) rather than as inline comments unless they're anchored to a specific line.
+
+5. **submit**: ALWAYS submit exactly one review via \`${t("create_pull_request_review")}\`. Do NOT call \`report_progress\` \u2014 the review is the final record and the progress comment will be cleaned up automatically.
+
+   note: the first create_pull_request_review submission may error with a one-time diff-coverage nudge listing unread TOC regions. retry the same call to proceed \u2014 optionally after reading the listed ranges. the pre-flight will not block again this session.
+
+   The review body is structured as: \`[optional alert blockquote]\` \u2192 \`[PR summary using the default format below]\`. Inline comments are passed via the \`comments\` parameter, not in the body.
+
+   - **critical issues** (blocks merge \u2014 bugs, security, data loss):
+     \`approved: false\`. Body opens with \`> [!CAUTION]\\n> This PR introduces ...\`, followed by the PR summary. Include all inline comments via \`comments\`.
+   - **recommended changes** (non-critical):
+     \`approved: false\`. Body opens with \`> [!IMPORTANT]\\n> Consider ...\`, followed by the PR summary. Include all inline comments via \`comments\`.
+   - **no actionable issues**:
+     \`approved: true\`. Body opens with \`No new issues found.\` followed by the PR summary.
+
+${PR_SUMMARY_FORMAT}`
+    },
+    // IncrementalReview shares Review's multi-lens orchestrator pattern but
+    // scopes the target to the incremental diff. The "issues must be NEW
+    // since the last Pullfrog review" filter lives at aggregation time
+    // (step 5), NOT in the subagent prompt — pushing the filter into
+    // subagents matches the canonical anneal anti-pattern of "list known
+    // pre-existing failures — don't flag these" and suppresses signal on
+    // regressions the new commits amplified. The review body is just
+    // "Reviewed changes" — a separate "Prior review feedback" checklist
+    // would duplicate the rolling PR summary snapshot's record of what
+    // earlier runs already addressed and add noise to the user-facing
+    // body. Same severity-table omission as Review.
+    {
+      name: "IncrementalReview",
+      description: "Re-review a PR after new commits are pushed; focus on new changes since the last review",
+      prompt: `### Checklist
+
+1. **checkout**: call \`${t("checkout_pr")}\` \u2014 this returns PR metadata, \`diffPath\` (full diff), and \`incrementalDiffPath\` (changes since last reviewed version, if available). read the diff TOC first and use its line ranges as your coverage checklist.
+
+2. **incremental scope**: if \`incrementalDiffPath\` is present, read it to see what changed since the last review. this is a range-diff that isolates the net changes, filtering out base branch noise. if not present, fall back to reviewing the full PR diff and determine what changed since Pullfrog's most recent review.
+
+3. **prior feedback**: fetch previous reviews via \`${t("list_pull_request_reviews")}\`. for the most recent Pullfrog review, call \`${t("get_review_comments")}\` with the review ID to retrieve specific prior line-level feedback. you'll use this to filter your aggregation in step 5 \u2014 anything already flagged in a prior review and not changed by the new commits should not be re-raised. you do NOT need to render this in the review body; the rolling PR summary snapshot is the durable record of what's been addressed.
+
+4. **triage & fan out**: orient on the *incremental* changes \u2014 domain, seams, external contracts, user-facing surfaces.
+
+   if the incremental changes are **genuinely trivial**, skip the fan-out entirely and jump to step 7's non-substantive path (do NOT submit a review).
+
+   "Genuinely trivial" (skip): formatting/comment tweaks, import reordering, lockfile regen, mechanical rename of import paths, whitespace-only.
+   "Looks trivial but isn't" (do NOT skip \u2014 same anti-patterns as Review mode): 1-line changes to SQL/regex/auth/billing/permissions/signature-verification code; flipping feature-flag defaults or retry/timeout constants; money/tax/HTTP-method/redirect changes; tightening or loosening a comparison operator; mixed diffs with a semantic line buried in formatting.
+   When unsure, treat as non-trivial.
+
+   otherwise pick lenses by where the new commits concentrate risk \u2014 **there's no fixed count**, same calibration as Review mode (1 lens for pure refactor / isolated fix; 2\u20133 for typical features; 4\u20135 for high-stakes subsystem touches; 6+ is a smell). lens framing follows Review mode: themed lenses (correctness & invariants, impact when new commits remove/rename/deprecate things, research-validated assumptions, security, user-journey, operational readiness, integration & cross-cutting, test integrity, performance, holistic) and subsystem lenses (auth, billing, schema migration, etc.) \u2014 for high-stakes domains lead with the subsystem lens rather than the generic themed equivalent.
+
+   dispatch one \`${REVIEWER_AGENT_NAME}\` subagent per lens \u2014 its baked-in system prompt enforces the non-mutative + non-recursive contract (read-only file/search/web tools and read-only MCP queries; no writes, shell side effects, state-changing MCP calls, or nested subagent dispatch). dispatch them in a **single assistant turn with multiple parallel subagent calls** (serial dispatch collapses the fan-out). if a subagent errors out, times out, or returns nothing usable, retry once with the same lens; if it still fails, proceed with partial coverage and note the missing lens in the review body \u2014 do not skip step 4 entirely on a single subagent failure. each subagent gets:
+   - the diff scope (incremental diff path if available, full diff otherwise). do NOT tell them to skip pre-existing issues \u2014 that suppresses regressions the new commits amplified; the "issues must be NEW" filter lives at aggregation time (step 5), not in the subagent prompt
+   - **only one lens** \u2014 never a multi-section "review for X, Y, and Z" prompt
+   - **a Task \`description\` set to the lens name** (e.g. \`"security"\`, \`"correctness"\`, \`"billing-subsystem"\`) \u2014 the harness reads this field to label the subagent's log lines so parallel runs can be told apart in CI output. without it, every subagent shows up as \`subagent#N\`.
+   - the read-only contract restated in your dispatch instructions so the rule is present twice (the subagent's system prompt also enforces it). The test: would this call still be a no-op if reverted? If not (PR comments, branch pushes, issue updates, set_output, label changes, dependency installs, etc.), don't make it.
+   - if the lens touches external contracts, instruct the subagent to verify load-bearing claims via web search and quote source URLs. action runs are non-interactive \u2014 there's no human to catch "I'm pretty sure Stripe does X."
+   - ask the subagent to report findings with file paths and NEW line numbers from the full PR diff so you can anchor inline comments.
+
+   delegation discipline:
+   - do NOT lens-review the diff yourself in parallel with the subagents
+   - do NOT summarize the changes for them (biases toward validation frame)
+   - do NOT hand them a curated reading list (let them discover scope)
+   - do NOT pre-shape their output with a finding schema
+   - do NOT mention the other lenses (independence is the point)
+
+5. **aggregate, draft, self-critique**: merge findings; de-dup overlaps; trace each finding yourself. drop praise, style preferences, speculative/unverified claims, findings about pre-existing code unrelated to the new commits, anything not actionable, and anything that re-states prior review feedback (heuristic: if the finding's root cause lives in lines the *new commits* added or modified, it's in scope; otherwise drop). also drop **bloat-shaped findings** \u2014 proposed fixes that would add defensive checks for cases that can't happen, abstractions used once, comments restating obvious code, tests asserting tautologies, or "just-in-case" guards. subagents are fallible and bias toward recommending changes; the bar for an actionable inline comment is sound + correct + elegant. recommending a change that improves only one of the three (or degrades elegance to nominally improve correctness) makes the codebase worse, not better. To compute "lines the new commits added or modified": if \`incrementalDiffPath\` from step 1 is present, use it directly. Otherwise, take the prior Pullfrog review's \`commit_id\` (returned alongside each entry from \`${t("list_pull_request_reviews")}\` in step 3) and run \`git diff <prior-review-sha>..HEAD\` to isolate the lines added since that review. draft inline comments with NEW line numbers from the full PR diff \u2014 every comment must be actionable, 2-3 sentences max.
+
+6. **build the review body** \u2014 a single "Reviewed changes" section: summarize at the logical-change level, not per-file. each bullet starts with a past-tense verb (e.g. \`- Extracted shared CLI runtime into a single module\`, \`- Renamed package to pullfrog\`). avoid file paths unless they add clarity. if the changes can be described in one sentence, use one sentence \u2014 no bullets needed. do NOT include a separate "Prior review feedback" checklist; that's tracked in the rolling PR summary snapshot for the next agent run, and surfacing it in the user-facing body is noise (changes that addressed prior feedback are already covered by the Reviewed-changes bullets). in some cases you may receive a complete diff for the whole pull request instead of an incremental one \u2014 when this happens, you will need to determine what changes have happened since Pullfrog's most recent review.
+
+7. Submit \u2014 Do NOT call \`report_progress\` or \`create_issue_comment\` \u2014 the review is the final record and the progress comment will be cleaned up automatically. Follow these rules:
+   - note: the first create_pull_request_review submission may error with a one-time diff-coverage nudge listing unread TOC regions. retry the same call to proceed \u2014 optionally after reading the listed ranges. the pre-flight will not block again this session.
+   - IF NO NEW ISSUES, NON-SUBSTANTIVE CHANGES ONLY (trivial formatting, import reordering, comment tweaks): do NOT submit a review. Do NOT call \`report_progress\`. Exit \u2014 the progress comment will be cleaned up automatically.
+   - ELSE IF NEW CRITICAL ISSUES (blocks merge): call \`${t("create_pull_request_review")}\` with \`approved: false\`, all comments, and the review body. body opens with a GitHub alert blockquote (e.g. \`> [!CAUTION]\\n> This PR introduces ...\`), then the Reviewed-changes summary.
+   - ELSE IF NEW RECOMMENDED CHANGES (non-critical): call \`${t("create_pull_request_review")}\` with \`approved: false\`, all comments, and the review body. body opens with \`> [!IMPORTANT]\\n> ...\` alert, then the Reviewed-changes summary.
+   - ELSE IF NO NEW ISSUES, SUBSTANTIVE CHANGES (new functionality, behavior changes, or fixes to prior review feedback): call \`${t("create_pull_request_review")}\` to create a PR review. If all previous reviews have been properly addressed and no new issues were discovered, you can set \`approved: true\`. body opens with \`No new issues. Reviewed the following changes:\\n\`, then the Reviewed-changes summary.`
+    },
+    {
+      name: "Plan",
+      description: "Create plans, break down tasks, outline steps, analyze requirements, understand scope of work, or provide task breakdowns",
+      prompt: `### Checklist
+
+1. Analyze the task and gather context:
+   - read AGENTS.md and relevant codebase files
+   - understand the architecture and constraints
+
+2. Produce a structured, actionable plan with clear milestones.
+
+3. Call \`${t("report_progress")}\` with the plan.
+
+${learningsStep(t, 4)}`
+    },
+    {
+      name: "Fix",
+      description: "Fix CI failures; debug failing tests or builds; investigate and resolve check suite failures",
+      prompt: `### Checklist
+
+1. Checkout the PR branch via \`${t("checkout_pr")}\`.
+
+2. Fetch check suite logs via \`${t("get_check_suite_logs")}\`.
+
+3. **CRITICAL**: verify the failure was INTRODUCED BY THIS PR before fixing. If unrelated, abort and report.
+
+4. Diagnose and fix:
+   - read the workflow file, reproduce locally with the EXACT same commands CI runs
+   - fix the issue using your native file and shell tools
+   - verify the fix by re-running the exact CI command
+   - review the diff before committing \u2014 verify only the fix is present, no debug artifacts, no unrelated changes. the fix should be clean enough that a senior engineer would approve without hesitation.
+   - commit locally via shell (\`git add . && git commit -m "..."\`)
+
+5. Finalize:
+   - confirm a clean working tree, then push via \`${t("push_branch")}\` (same push/prepush guidance as Build mode in *SYSTEM*)
+   - call \`${t("report_progress")}\` with the diagnosis and fix summary (or the exact push error if push failed)
+
+${learningsStep(t, 6)}`
+    },
+    {
+      name: "ResolveConflicts",
+      description: "Resolve merge conflicts in a PR branch against the base branch",
+      prompt: `### Checklist
+
+1. **Setup**:
+   - Call \`${t("checkout_pr")}\` to get the PR branch.
+   - Call \`${t("get_pull_request")}\` to identify the base branch (e.g., 'main').
+   - Call \`${t("git_fetch")}\` to fetch the base branch.
+
+2. **Merge Attempt**:
+   - Run \`git merge origin/<base_branch>\` via shell.
+   - If it succeeds automatically, confirm a clean working tree, push via \`${t("push_branch")}\` (same push/prepush guidance as Build mode in *SYSTEM*), and call \`${t("report_progress")}\` with a brief success note or the exact push error if push failed \u2014 **then stop; do not run steps 3\u20134.**
+   - If it fails (conflicts), resolve them manually (continue to steps 3\u20134).
+
+3. **Resolve Conflicts**:
+   - Run \`git status\` or parse the merge output to find the list of conflicting files.
+   - For each conflicting file: read it, find the conflict markers (\`<<<<<<<\`, \`=======\`, \`>>>>>>>\`), understand the code context, and rewrite the file with the correct resolution. Remove all markers.
+   - Verify the file syntax is correct after resolution.
+
+4. **Finalize**:
+   - Run a final verification (build/test) to ensure the resolution works.
+   - \`git add . && git commit -m "resolve merge conflicts"\`
+   - confirm a clean working tree, then push via \`${t("push_branch")}\` (same push/prepush guidance as Build mode in *SYSTEM*)
+   - Call \`${t("report_progress")}\` with a summary of what was resolved (or the exact push error if push failed)`
+    },
+    {
+      name: "Task",
+      description: "General-purpose tasks that don't fit other modes: answering questions, adding comments, labeling, running ad-hoc commands, or any direct request",
+      prompt: `### Checklist
+
+1. Analyze the task. For simple operations (labeling, commenting, answering questions, running a single command), handle directly.
+
+2. For substantial work \u2014 code changes across multiple files, multi-step investigations:
+   - plan your approach before starting
+   - use native file and shell tools for local operations
+   - use ${pullfrogMcpName} MCP tools for GitHub/git operations
+   - if code changes are needed: review your own diff before committing \u2014 verify only intended changes are present, no debug artifacts remain, and the changes are clean enough that a senior engineer would approve without hesitation
+
+3. Finalize:
+   - if code changes were made, push to a pull request (new or existing) using \`${t("push_branch")}\` and \`${t("create_pull_request")}\` as needed. \`git status\` must be clean before you finish (see *SYSTEM* Git rules if push fails).
+   - call \`${t("report_progress")}\` once with results \u2014 include exact tool errors if push or PR creation failed
+   - if the task involved labeling, commenting, or other GitHub operations, perform those directly
+
+${learningsStep(t, 4)}`
+    }
+  ];
+}
+var modes = computeModes("opencode");
+
 // agents/claude.ts
 import { execFileSync as execFileSync3 } from "node:child_process";
 import { mkdirSync as mkdirSync4, writeFileSync as writeFileSync7 } from "node:fs";
@@ -146596,20 +146585,34 @@ async function installFromNpmTarball(params) {
 }
 
 // utils/providerErrors.ts
+var statusKey = `\\b(?:status[_ ]?code|http[_ ]?status|status)["']?\\s*[:=]\\s*["']?`;
 var PROVIDER_ERROR_PATTERNS = [
-  { pattern: "429", label: "rate limited (429)" },
-  { pattern: "RESOURCE_EXHAUSTED", label: "quota exhausted" },
-  { pattern: "quota", label: "quota error" },
-  { pattern: "status: 500", label: "provider 500 error" },
-  { pattern: "INTERNAL", label: "provider internal error" },
-  { pattern: "status: 503", label: "provider unavailable (503)" },
-  { pattern: "UNAVAILABLE", label: "provider unavailable" },
-  { pattern: "rate limit", label: "rate limited" },
-  { pattern: "limit: 0", label: "zero quota" }
+  { regex: new RegExp(`${statusKey}429\\b`, "i"), label: "rate limited (429)" },
+  { regex: new RegExp(`${statusKey}500\\b`, "i"), label: "provider 500 error" },
+  { regex: new RegExp(`${statusKey}503\\b`, "i"), label: "provider unavailable (503)" },
+  // matches `rate limit`, `rate limited`, `rate limits exceeded`,
+  // `rate_limit_error`, `rate_limit_exceeded`. the leading `\b` + `[_ ]`
+  // separator rejects `x-ratelimit-*` / `anthropic-ratelimit-*` response
+  // headers (no separator between "rate" and "limit") which routinely
+  // appear in dumped 401 / 4xx error JSON.
+  { regex: /\brate[_ ]limit/i, label: "rate limited" },
+  { regex: /\bRESOURCE_EXHAUSTED\b/, label: "quota exhausted" },
+  // Google gRPC `INTERNAL` status. word-boundary anchors reject
+  // `INTERNAL_SERVER_ERROR` (HTTP 500 message that may appear in unrelated
+  // log lines) and identifiers like `INTERNALS`.
+  { regex: /\bINTERNAL\b/, label: "provider internal error" },
+  { regex: /\bUNAVAILABLE\b/, label: "provider unavailable" },
+  // matches `quota`, `insufficient_quota`, `quota_exceeded`, `quotaExceeded`.
+  // word-character lookarounds would reject `_quota` / `quotaX`; `quota` is
+  // specific enough that a plain substring match is safe.
+  { regex: /quota/i, label: "quota error" },
+  // explicit zero-quota response, e.g. `{"limit": 0}`. the `\b` anchor
+  // around `limit` rejects keys like `time_limit` or `field_limit`.
+  { regex: /["']?\blimit\b["']?\s*:\s*0\b/, label: "zero quota" }
 ];
 function detectProviderError(text) {
   for (const entry of PROVIDER_ERROR_PATTERNS) {
-    if (text.includes(entry.pattern)) return entry.label;
+    if (entry.regex.test(text)) return entry.label;
   }
   return null;
 }
@@ -146719,6 +146722,7 @@ var ThinkingTimer = class {
 };
 
 // agents/postRun.ts
+import { readFile } from "node:fs/promises";
 var MAX_HOOK_OUTPUT_CHARS = 4096;
 function truncateHookOutput(raw2) {
   if (raw2.length <= MAX_HOOK_OUTPUT_CHARS) return raw2;
@@ -146763,6 +146767,23 @@ function buildStopHookPrompt(failure) {
     "```"
   ].join("\n");
 }
+async function isSummaryUnchanged(filePath, seed) {
+  try {
+    const current = await readFile(filePath, "utf8");
+    return current === seed;
+  } catch {
+    return false;
+  }
+}
+function buildSummaryStalePrompt(filePath) {
+  return [
+    `PR SUMMARY UNTOUCHED \u2014 the rolling PR summary file at \`${filePath}\` is byte-identical to its seed; this run did not edit it.`,
+    "",
+    "review the diff and update the file in place to reflect what changed in the PR. update intent, key changes, and any risks worth flagging \u2014 keep the existing section headings stable so incremental runs produce clean diffs.",
+    "",
+    "if the diff is genuinely too small or noisy to warrant rewriting (e.g. a one-line typo fix, a comment tweak, a formatting-only change), it's fine to leave the structure as-is \u2014 but at minimum confirm you considered it by appending one line to the appropriate section noting the run. silence is not an option; the snapshot is what the next review run reads as context."
+  ].join("\n");
+}
 async function collectPostRunIssues(params) {
   const issues = {};
   if (params.stopScript) {
@@ -146771,12 +146792,17 @@ async function collectPostRunIssues(params) {
   }
   const status = getGitStatus();
   if (status) issues.dirtyTree = status;
+  if (params.summaryFilePath && params.summarySeed !== void 0) {
+    const stale = await isSummaryUnchanged(params.summaryFilePath, params.summarySeed);
+    if (stale) issues.summaryStale = { filePath: params.summaryFilePath };
+  }
   return issues;
 }
 function buildPostRunPrompt(issues) {
   const parts = [];
   if (issues.stopHook) parts.push(buildStopHookPrompt(issues.stopHook));
   if (issues.dirtyTree) parts.push(buildCommitPrompt(issues.dirtyTree));
+  if (issues.summaryStale) parts.push(buildSummaryStalePrompt(issues.summaryStale.filePath));
   return parts.join("\n\n---\n\n");
 }
 function buildLearningsReflectionPrompt(agentId) {
@@ -146799,9 +146825,15 @@ async function runPostRunRetryLoop(params) {
   let finalIssues = {};
   let gateResumeCount = 0;
   let pendingReflection = params.reflectionPrompt;
+  let summaryStaleNudged = false;
   while (gateResumeCount < MAX_POST_RUN_RETRIES) {
     if (!result.success) break;
-    const issues = await collectPostRunIssues({ stopScript: params.stopScript });
+    const issues = await collectPostRunIssues({
+      stopScript: params.stopScript,
+      summaryFilePath: summaryStaleNudged ? void 0 : params.summaryFilePath,
+      summarySeed: summaryStaleNudged ? void 0 : params.summarySeed
+    });
+    if (issues.summaryStale) summaryStaleNudged = true;
     finalIssues = issues;
     if (!hasPostRunIssues(issues)) {
       if (!pendingReflection) break;
@@ -146833,8 +146865,17 @@ async function runPostRunRetryLoop(params) {
     }
     log.info(`\xBB post-run retry (attempt ${gateResumeCount + 1}/${MAX_POST_RUN_RETRIES})`);
     const prompt = buildPostRunPrompt(issues);
+    const onlySummaryStale = issues.summaryStale !== void 0 && issues.stopHook === void 0 && issues.dirtyTree === void 0;
+    const preResume = result;
     result = await params.resume({ prompt, previousResult: result });
     aggregatedUsage = mergeAgentUsage(aggregatedUsage, result.usage);
+    if (!result.success && onlySummaryStale) {
+      log.warning(
+        `\xBB summary-stale resume turn failed (${result.error ?? "unknown error"}), preserving prior successful result`
+      );
+      result = preResume;
+      break;
+    }
     gateResumeCount++;
   }
   if (gateResumeCount > 0 && result.success && hasPostRunIssues(finalIssues)) {
@@ -146971,6 +147012,7 @@ async function runClaude(params) {
   const thinkingTimer = new ThinkingTimer();
   let finalOutput = "";
   let sessionId;
+  let resultErrorSubtype = null;
   let accumulatedTokens = { input: 0, output: 0, cacheRead: 0, cacheWrite: 0 };
   let accumulatedCostUsd = 0;
   let tokensLogged = false;
@@ -147074,9 +147116,14 @@ async function runClaude(params) {
           tokensLogged = true;
         }
       } else if (subtype === "error_max_turns") {
+        resultErrorSubtype = subtype;
         log.info(`\xBB ${params.label} max turns reached: ${JSON.stringify(event)}`);
       } else if (subtype === "error_during_execution") {
+        resultErrorSubtype = subtype;
         log.info(`\xBB ${params.label} execution error: ${JSON.stringify(event)}`);
+      } else if (subtype.startsWith("error")) {
+        resultErrorSubtype = subtype;
+        log.info(`\xBB ${params.label} result: subtype=${subtype}, data=${JSON.stringify(event)}`);
       } else {
         log.info(`\xBB ${params.label} result: subtype=${subtype}, data=${JSON.stringify(event)}`);
       }
@@ -147207,6 +147254,15 @@ ${stderrContext}`);
         sessionId
       };
     }
+    if (resultErrorSubtype) {
+      return {
+        success: false,
+        output: finalOutput || output,
+        error: `result subtype: ${resultErrorSubtype}`,
+        usage,
+        sessionId
+      };
+    }
     return { success: true, output: finalOutput || output, usage, sessionId };
   } catch (error49) {
     params.todoTracker?.cancel();
@@ -147335,6 +147391,8 @@ var claude = agent({
       initialResult: result,
       initialUsage: result.usage,
       stopScript: ctx.stopScript,
+      summaryFilePath: ctx.summaryFilePath,
+      summarySeed: ctx.summarySeed,
       reflectionPrompt: buildLearningsReflectionPrompt("claude"),
       canResume: (r) => Boolean(r.sessionId),
       resume: async (c) => {
@@ -147668,6 +147726,12 @@ async function runOpenCode(params) {
         log.debug(withLabel(label, `tool output: ${outputStr}`));
       }
     },
+    error: (event) => {
+      agentErrorEvent = event;
+      const errorName = event.error?.name || "unknown";
+      const errorMessage = event.error?.data?.message || event.error?.name || JSON.stringify(event);
+      log.info(`\xBB ${params.label} error event: ${errorName}: ${errorMessage}`);
+    },
     result: async (event) => {
       const status = event.status || "unknown";
       const duration4 = event.stats?.duration_ms || 0;
@@ -147688,6 +147752,7 @@ async function runOpenCode(params) {
   };
   const recentStderr = [];
   let lastProviderError = null;
+  let agentErrorEvent = null;
   let output = "";
   let stdoutBuffer = "";
   try {
@@ -147806,6 +147871,17 @@ ${stderrContext}`);
         usage
       };
     }
+    if (agentErrorEvent) {
+      const errorEvent = agentErrorEvent;
+      const errorName = errorEvent.error?.name || "agent error";
+      const errorMessage = errorEvent.error?.data?.message || errorEvent.error?.name || JSON.stringify(errorEvent);
+      return {
+        success: false,
+        output: finalOutput || output,
+        error: `${errorName}: ${errorMessage}`,
+        usage
+      };
+    }
     return { success: true, output: finalOutput || output, usage };
   } catch (error49) {
     params.todoTracker?.cancel();
@@ -147881,6 +147957,8 @@ var opencode = agent({
       initialResult: result,
       initialUsage: result.usage,
       stopScript: ctx.stopScript,
+      summaryFilePath: ctx.summaryFilePath,
+      summarySeed: ctx.summarySeed,
       reflectionPrompt: buildLearningsReflectionPrompt("opencode"),
       resume: async (c) => runOpenCode({
         ...runParams,
@@ -152427,7 +152505,7 @@ When embedding images (e.g. uploaded screenshots) in comments or PR bodies, alwa
 
 **\`report_progress\`**: call this exactly once at the end of every run with a brief final summary (1-3 sentences) unless the mode guidance instructs otherwise. Never call it for intermediate status updates (e.g., "Checking for changes...", "Starting review...") \u2014 the task list handles live progress automatically. Calling \`report_progress\` replaces the task list with your summary and preserves the current task list in a collapsible section. Keep the summary concise \u2014 do not repeat what the task list already shows. Focus on the outcome (what was accomplished, links to artifacts) rather than listing individual steps. If something failed, include the tool's error text even when that makes the summary longer.
 
-Never use \`create_issue_comment\` for task progress \u2014 that creates duplicate comments and leaves the progress comment stuck in its initial state. \`create_issue_comment\` is only for standalone comments unrelated to your current task (e.g., Plan comments, PR Summary comments).
+Never use \`create_issue_comment\` for task progress \u2014 that creates duplicate comments and leaves the progress comment stuck in its initial state. \`create_issue_comment\` is only for standalone comments unrelated to your current task (e.g., Plan comments).
 
 ### If you get stuck
 
@@ -152591,7 +152669,8 @@ var JsonPayload = type({
   "progressComment?": type({
     id: "string",
     type: "'issue' | 'review'"
-  }).or("undefined")
+  }).or("undefined"),
+  "generateSummary?": "boolean | undefined"
 });
 var COLLABORATOR_PERMISSIONS = ["admin", "maintain", "write"];
 function isCollaborator(event) {
@@ -152674,6 +152753,7 @@ function resolvePayload(resolvedPromptInput, repoSettings) {
     timeout: inputs.timeout ?? jsonPayload?.timeout,
     cwd: resolveCwd(inputs.cwd),
     progressComment: jsonPayload?.progressComment,
+    generateSummary: jsonPayload?.generateSummary,
     // permissions: inputs > repoSettings > fallbacks
     push: inputs.push ?? repoSettings.push ?? "restricted",
     shell: resolvedShell,
@@ -152682,6 +152762,40 @@ function resolvePayload(resolvedPromptInput, repoSettings) {
   };
 }
 
+// utils/prSummary.ts
+import { mkdir, readFile as readFile2, writeFile as writeFile2 } from "node:fs/promises";
+import { dirname as dirname4, join as join14 } from "node:path";
+var SUMMARY_FILE_NAME = "pullfrog-summary.md";
+var SUMMARY_SCAFFOLD = `# PR summary
+
+<!-- durable cross-run context. edit in place; the next agent run reads this
+     before reviewing new commits. structure however serves the PR best. -->
+`;
+var MIN_SNAPSHOT_LENGTH = 60;
+var MAX_SNAPSHOT_LENGTH = 32768;
+function summaryFilePath(tmpdir3) {
+  return join14(tmpdir3, SUMMARY_FILE_NAME);
+}
+async function seedSummaryFile(params) {
+  const path3 = summaryFilePath(params.tmpdir);
+  await mkdir(dirname4(path3), { recursive: true });
+  const seed = params.previousSnapshot && params.previousSnapshot.trim().length >= MIN_SNAPSHOT_LENGTH ? params.previousSnapshot : SUMMARY_SCAFFOLD;
+  await writeFile2(path3, seed, "utf8");
+  return path3;
+}
+async function readSummaryFile(path3) {
+  let raw2;
+  try {
+    raw2 = await readFile2(path3, "utf8");
+  } catch {
+    return null;
+  }
+  const trimmed = raw2.trim();
+  if (trimmed.length < MIN_SNAPSHOT_LENGTH) return null;
+  if (trimmed.length > MAX_SNAPSHOT_LENGTH) return trimmed.slice(0, MAX_SNAPSHOT_LENGTH);
+  return trimmed;
+}
+
 // utils/reviewCleanup.ts
 var RE_REVIEW_PREAMBLE = "Incrementally re-review the new commits on this pull request. Use the IncrementalReview mode.";
 async function postReviewCleanup(ctx) {
@@ -152741,11 +152855,16 @@ async function dispatchFollowUpReReview(ctx, reviewedSha) {
   await ctx.octokit.rest.actions.createWorkflowDispatch({
     owner: ctx.repo.owner,
     repo: ctx.repo.name,
-    workflow_id: "pullfrog.yml",
+    workflow_id: getCurrentWorkflowFilename(),
     ref: pr.data.base.repo.default_branch,
     inputs: { prompt: JSON.stringify(payload) }
   });
 }
+function getCurrentWorkflowFilename() {
+  const ref = process.env.GITHUB_WORKFLOW_REF ?? "";
+  const match3 = ref.match(/\/([^/]+)@/);
+  return match3?.[1] ?? "pullfrog.yml";
+}
 
 // utils/run.ts
 async function handleAgentResult(ctx) {
@@ -152885,9 +153004,9 @@ async function resolveRunContextData(params) {
 import { execFileSync as execFileSync5, execSync as execSync3 } from "node:child_process";
 import { mkdtempSync } from "node:fs";
 import { tmpdir as tmpdir2 } from "node:os";
-import { join as join14 } from "node:path";
+import { join as join15 } from "node:path";
 function createTempDirectory() {
-  const sharedTempDir = mkdtempSync(join14(tmpdir2(), "pullfrog-"));
+  const sharedTempDir = mkdtempSync(join15(tmpdir2(), "pullfrog-"));
   process.env.PULLFROG_TEMP_DIR = sharedTempDir;
   log.info(`\xBB created temp dir at ${sharedTempDir}`);
   return sharedTempDir;
@@ -153220,39 +153339,53 @@ var TransientError = class extends Error {
     this.name = "TransientError";
   }
 };
-function formatBillingErrorSummary(error49) {
+function billingConsoleUrl(owner, anchor) {
+  return `https://pullfrog.com/console/${encodeURIComponent(owner)}#${anchor}`;
+}
+function formatBillingErrorSummary(error49, owner) {
   if (error49.code === "router_requires_card") {
     return [
-      "### \u26D4 Pullfrog Router requires a card",
+      "**Add a card to start using Pullfrog Router.**",
       "",
-      "This run was going to use Pullfrog Router, which bills at raw OpenRouter cost and needs a card on file. Runs won't proceed until a card is added.",
+      "Router proxies OpenRouter at raw cost \u2014 no platform markup, and your first $20 of usage is on us.",
       "",
-      "[Add a card \u2192](https://pullfrog.com/console#model-access) \u2014 your first $20 of Router usage is free."
+      `[Add a card \u2192](${billingConsoleUrl(owner, "model-access")})`
     ].join("\n");
   }
   if (error49.needsReauthentication) {
+    const code = error49.declineCode ?? "authentication_required";
     return [
-      "### \u274C Pullfrog billing error \u2014 card requires 3DS on every charge",
+      `**Your card issuer requires 3D Secure on every charge** (\`${code}\`).`,
       "",
-      `Your card issuer requires a 3D Secure challenge on each off-session charge (\`${error49.declineCode ?? "authentication_required"}\`), which we can't run from the agent. Top up your Router credit balance manually \u2014 3DS runs interactively in Stripe Checkout, and subsequent runs draw from the prepaid balance without triggering another off-session charge.`,
+      "Pullfrog can't complete a 3DS challenge from inside a workflow. Top up your Router balance once in Stripe Checkout \u2014 subsequent runs draw from the prepaid balance without re-triggering 3DS.",
       "",
-      "[Top up your Router credit balance \u2192](https://pullfrog.com/console)"
+      `[Top up balance \u2192](${billingConsoleUrl(owner, "billing")})`
     ].join("\n");
   }
-  const codeSuffix = error49.declineCode ? ` (\`${error49.declineCode}\`)` : "";
-  return `### \u274C Pullfrog billing error
-
-${error49.message}${codeSuffix}
-
-[Manage billing \u2192](https://pullfrog.com/console)`;
+  if (error49.declineCode) {
+    return [
+      `**Your card was declined** (\`${error49.declineCode}\`).`,
+      "",
+      "Update your payment method and Pullfrog will retry on the next run.",
+      "",
+      `[Update payment method \u2192](${billingConsoleUrl(owner, "billing")})`
+    ].join("\n");
+  }
+  return [
+    "**Your Pullfrog balance is empty.**",
+    "",
+    "Top up your balance or enable auto-reload to keep runs flowing.",
+    "",
+    `[Manage billing \u2192](${billingConsoleUrl(owner, "billing")})`
+  ].join("\n");
 }
-function formatTransientErrorSummary(error49) {
+function formatTransientErrorSummary(error49, owner) {
   return [
-    "### \u26A0\uFE0F Pullfrog temporarily unavailable",
+    "**Pullfrog billing is temporarily unavailable.**",
     "",
     error49.message,
     "",
-    "This is typically transient \u2014 the next dispatch should succeed. If it persists, check [status.pullfrog.com](https://status.pullfrog.com)."
+    `Usually transient \u2014 the next dispatch should succeed. If it persists, check [status.pullfrog.com](https://status.pullfrog.com) or [your console](${billingConsoleUrl(owner, "billing")}).`
   ].join("\n");
 }
 async function mintProxyKey(ctx) {
@@ -153313,6 +153446,43 @@ async function resolveProxyModel(ctx) {
   const label = ctx.oss ? "oss" : "router";
   log.info(`\xBB proxy: ${label} \u2192 ${ctx.proxyModel}`);
 }
+async function fetchPreviousSnapshot(ctx, prNumber) {
+  if (!ctx.githubInstallationToken) return null;
+  try {
+    const response = await apiFetch({
+      path: `/api/repo/${ctx.repo.owner}/${ctx.repo.name}/pr/${prNumber}/summary-comment`,
+      method: "GET",
+      headers: { authorization: `Bearer ${ctx.githubInstallationToken}` },
+      signal: AbortSignal.timeout(1e4)
+    });
+    if (!response.ok) return null;
+    const data = await response.json();
+    return typeof data.snapshot === "string" && data.snapshot.length > 0 ? data.snapshot : null;
+  } catch {
+    return null;
+  }
+}
+async function persistSummary(ctx) {
+  const filePath = ctx.toolState.summaryFilePath;
+  if (!filePath) return;
+  if (ctx.toolState.summaryPersistAttempted) return;
+  ctx.toolState.summaryPersistAttempted = true;
+  const snapshot2 = await readSummaryFile(filePath);
+  if (!snapshot2) {
+    log.debug(`pr summary tmpfile missing or invalid at ${filePath} \u2014 skipping persist`);
+    return;
+  }
+  const seed = ctx.toolState.summarySeed?.trim();
+  if (seed !== void 0 && snapshot2 === seed) {
+    log.warning(
+      "\xBB pr summary tmpfile unchanged from seed \u2014 skipping persist (agent did not edit it)"
+    );
+    return;
+  }
+  await patchWorkflowRunFields(ctx, { summarySnapshot: snapshot2 }).catch((err) => {
+    log.debug(`pr summary persist failed: ${err instanceof Error ? err.message : String(err)}`);
+  });
+}
 async function writeJobSummary(toolState) {
   const usageSummary = formatUsageSummary(toolState.usageEntries);
   const summaryParts = [toolState.lastProgressBody, usageSummary].filter(Boolean);
@@ -153377,7 +153547,7 @@ async function main() {
       });
     } catch (error49) {
       if (error49 instanceof BillingError) {
-        const summary2 = formatBillingErrorSummary(error49);
+        const summary2 = formatBillingErrorSummary(error49, runContext.repo.owner);
         await writeSummary(summary2).catch(() => {
         });
         await reportErrorToComment({ toolState, error: summary2 }).catch(() => {
@@ -153385,7 +153555,7 @@ async function main() {
         throw error49;
       }
       if (error49 instanceof TransientError) {
-        const summary2 = formatTransientErrorSummary(error49);
+        const summary2 = formatTransientErrorSummary(error49, runContext.repo.owner);
         await writeSummary(summary2).catch(() => {
         });
         await reportErrorToComment({ toolState, error: summary2 }).catch(() => {
@@ -153475,6 +153645,20 @@ async function main() {
         toolContext.mcpServerUrl = mcpHttpServer.url;
         log.info(`\xBB MCP server started at ${mcpHttpServer.url}`);
         timer.checkpoint("mcpServer");
+        if (payload.generateSummary && payload.event.is_pr && payload.event.issue_number) {
+          const previousSnapshot = await fetchPreviousSnapshot(toolContext, payload.event.issue_number);
+          const filePath = await seedSummaryFile({ tmpdir: tmpdir3, previousSnapshot });
+          toolState.summaryFilePath = filePath;
+          try {
+            toolState.summarySeed = await readFile3(filePath, "utf8");
+          } catch {
+          }
+          log.info(
+            `\xBB summary snapshot seeded at ${filePath} (previous=${previousSnapshot ? "yes" : "no"})`
+          );
+          const ctxForExit = toolContext;
+          onExitSignal(() => persistSummary(ctxForExit));
+        }
         startInstallation(toolContext);
         const modelForLog = resolveModelForLog({ payload, resolvedModel });
         const agentForLog = resolveAgentForLog({ agentName: agent2.name, resolvedModel });
@@ -153506,7 +153690,7 @@ ${instructions.user}` : null,
           log.info(instructions.full);
         });
         if (agentId === "opencode") {
-          const pluginDir = join15(process.cwd(), ".opencode", "plugin");
+          const pluginDir = join16(process.cwd(), ".opencode", "plugin");
           const hasPlugins = existsSync7(pluginDir) && readdirSync(pluginDir).some((f) => /\.[jt]sx?$/.test(f));
           if (hasPlugins && toolState.dependencyInstallation?.promise) {
             log.info(
@@ -153565,6 +153749,8 @@ ${instructions.user}` : null,
           instructions,
           todoTracker,
           stopScript: runContext.repoSettings.stopScript,
+          summaryFilePath: toolState.summaryFilePath,
+          summarySeed: toolState.summarySeed,
           onActivityTimeout: onInnerActivityTimeout,
           onToolUse: (event) => {
             const wasTracked = recordDiffReadFromToolUse({
@@ -153619,8 +153805,10 @@ ${instructions.user}` : null,
             log.debug(`post-review cleanup failed: ${error49}`);
           });
         }
-        const trackerWasLastWriter = todoTracker?.hasPublished && !toolState.finalSummaryWritten;
-        if (toolContext && toolState.progressComment && (!toolState.wasUpdated || trackerWasLastWriter)) {
+        if (toolContext) {
+          await persistSummary(toolContext);
+        }
+        if (toolContext && toolState.progressComment && !toolState.finalSummaryWritten) {
           await deleteProgressComment(toolContext).catch((error49) => {
             log.debug(`stranded progress comment cleanup failed: ${error49}`);
           });
@@ -153667,6 +153855,9 @@ ${errorMessage}
           log.debug(`post-review cleanup failed: ${error50}`);
         });
       }
+      if (toolContext) {
+        await persistSummary(toolContext);
+      }
       return {
         success: false,
         error: errorMessage