pullfrog 0.0.203 → 0.0.205

package/dist/internal/index.d.ts

@@ -9,4 +9,7 @@ export { modes } from "../modes.ts";
 export type { BuildPullfrogFooterParams, WorkflowRunFooterInfo, } from "../utils/buildPullfrogFooter.ts";
 export { buildPullfrogFooter, PULLFROG_DIVIDER, stripExistingFooter, } from "../utils/buildPullfrogFooter.ts";
 export type { ResourceUsage, UsageSummary } from "../utils/github.ts";
+export { isLeapingIntoActionCommentBody, LEAPING_INTO_ACTION_PREFIX, } from "../utils/leapingComment.ts";
+export type { CreateProgressCommentTarget, ProgressComment, ProgressCommentType, } from "../utils/progressComment.ts";
+export { createLeapingProgressComment, deleteProgressCommentApi, getProgressComment, updateProgressComment, } from "../utils/progressComment.ts";
 export { isValidTimeString, parseTimeString, TIMEOUT_DISABLED, } from "../utils/time.ts";

package/dist/internal.js

@@ -93,14 +93,14 @@ var providers = {
     models: {
       grok: {
         displayName: "Grok",
-        resolve: "xai/grok-4",
-        openRouterResolve: "openrouter/x-ai/grok-4",
+        resolve: "xai/grok-4.3",
+        openRouterResolve: "openrouter/x-ai/grok-4.3",
         preferred: true
       },
       "grok-fast": {
         displayName: "Grok Fast",
-        resolve: "xai/grok-4-fast",
-        openRouterResolve: "openrouter/x-ai/grok-4-fast"
+        resolve: "xai/grok-4-1-fast",
+        openRouterResolve: "openrouter/x-ai/grok-4.1-fast"
       },
       "grok-code-fast": {
         displayName: "Grok Code Fast",
@@ -307,8 +307,8 @@ var providers = {
       },
       grok: {
         displayName: "Grok",
-        resolve: "openrouter/x-ai/grok-4",
-        openRouterResolve: "openrouter/x-ai/grok-4"
+        resolve: "openrouter/x-ai/grok-4.3",
+        openRouterResolve: "openrouter/x-ai/grok-4.3"
       },
       "deepseek-pro": {
         displayName: "DeepSeek Pro",
@@ -514,7 +514,7 @@ function computeModes(agentId) {
    - 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 "..."\`).
+   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)
@@ -538,7 +538,7 @@ For simple, well-defined tasks, skip the plan phase and go straight to build.`
 
 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.
+   - 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)
 
@@ -575,7 +575,7 @@ ${learningsStep(t, 6)}`
 
 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.
+   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
@@ -643,26 +643,28 @@ ${learningsStep(t, 6)}`
 
    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 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.
+     \`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 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.
+     \`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: "Reviewed \u2014 no issues found."`
+     \`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 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.
+    // 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",
@@ -672,7 +674,7 @@ ${learningsStep(t, 6)}`
 
 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.
+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.
 
@@ -701,20 +703,14 @@ ${learningsStep(t, 6)}`
 
 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 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.
 
-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:
+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 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).`
+   - 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",
@@ -800,18 +796,6 @@ ${learningsStep(t, 6)}`
    - 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}`
     }
   ];
 }
@@ -857,6 +841,111 @@ function stripExistingFooter(body) {
   return body.substring(0, dividerIndex).trimEnd();
 }
 
+// utils/leapingComment.ts
+var LEAPING_INTO_ACTION_PREFIX = "Leaping into action";
+function isLeapingIntoActionCommentBody(body) {
+  const content = stripExistingFooter(body).trimStart();
+  const firstLine = content.split(/\r?\n/, 1)[0]?.trimEnd() ?? "";
+  return new RegExp(`(^|\\s)${LEAPING_INTO_ACTION_PREFIX}(\\.\\.\\.)?$`).test(firstLine);
+}
+
+// utils/progressComment.ts
+async function getProgressComment(ctx, comment) {
+  const result = await (comment.type === "review" ? ctx.octokit.rest.pulls.getReviewComment({
+    owner: ctx.owner,
+    repo: ctx.repo,
+    comment_id: comment.id
+  }) : ctx.octokit.rest.issues.getComment({
+    owner: ctx.owner,
+    repo: ctx.repo,
+    comment_id: comment.id
+  }));
+  return {
+    id: result.data.id,
+    body: result.data.body ?? void 0,
+    html_url: result.data.html_url
+  };
+}
+async function updateProgressComment(ctx, comment, body) {
+  const result = await (comment.type === "review" ? ctx.octokit.rest.pulls.updateReviewComment({
+    owner: ctx.owner,
+    repo: ctx.repo,
+    comment_id: comment.id,
+    body
+  }) : ctx.octokit.rest.issues.updateComment({
+    owner: ctx.owner,
+    repo: ctx.repo,
+    comment_id: comment.id,
+    body
+  }));
+  return {
+    id: result.data.id,
+    body: result.data.body ?? void 0,
+    html_url: result.data.html_url,
+    node_id: result.data.node_id
+  };
+}
+async function deleteProgressCommentApi(ctx, comment) {
+  if (comment.type === "review") {
+    await ctx.octokit.rest.pulls.deleteReviewComment({
+      owner: ctx.owner,
+      repo: ctx.repo,
+      comment_id: comment.id
+    });
+    return;
+  }
+  await ctx.octokit.rest.issues.deleteComment({
+    owner: ctx.owner,
+    repo: ctx.repo,
+    comment_id: comment.id
+  });
+}
+async function createLeapingProgressComment(ctx, target, body) {
+  if (target.kind === "reviewReply") {
+    try {
+      const result2 = await ctx.octokit.rest.pulls.createReplyForReviewComment({
+        owner: ctx.owner,
+        repo: ctx.repo,
+        pull_number: target.pullNumber,
+        comment_id: target.replyToCommentId,
+        body
+      });
+      return {
+        comment: { id: result2.data.id, type: "review" },
+        body: result2.data.body ?? void 0,
+        html_url: result2.data.html_url
+      };
+    } catch (error) {
+      console.warn(
+        `[progressComment] review reply failed (parent ${target.replyToCommentId} on PR #${target.pullNumber}), falling back to issue comment:`,
+        error
+      );
+      const fallback = await ctx.octokit.rest.issues.createComment({
+        owner: ctx.owner,
+        repo: ctx.repo,
+        issue_number: target.pullNumber,
+        body
+      });
+      return {
+        comment: { id: fallback.data.id, type: "issue" },
+        body: fallback.data.body ?? void 0,
+        html_url: fallback.data.html_url
+      };
+    }
+  }
+  const result = await ctx.octokit.rest.issues.createComment({
+    owner: ctx.owner,
+    repo: ctx.repo,
+    issue_number: target.issueNumber,
+    body
+  });
+  return {
+    comment: { id: result.data.id, type: "issue" },
+    body: result.data.body ?? void 0,
+    html_url: result.data.html_url
+  };
+}
+
 // utils/time.ts
 var TIMEOUT_DISABLED = "none";
 var TIME_STRING_REGEX = /^(?:(\d+)h)?(?:(\d+)m)?(?:(\d+)s)?$/;
@@ -872,12 +961,17 @@ function isValidTimeString(input) {
   return parseTimeString(input) !== null;
 }
 export {
+  LEAPING_INTO_ACTION_PREFIX,
   PULLFROG_DIVIDER,
   TIMEOUT_DISABLED,
   buildPullfrogFooter,
+  createLeapingProgressComment,
+  deleteProgressCommentApi,
   getModelEnvVars,
   getModelProvider,
+  getProgressComment,
   getProviderDisplayName,
+  isLeapingIntoActionCommentBody,
   isValidTimeString,
   modelAliases,
   modes,
@@ -889,5 +983,6 @@ export {
   resolveDisplayAlias,
   resolveModelSlug,
   resolveOpenRouterModel,
-  stripExistingFooter
+  stripExistingFooter,
+  updateProgressComment
 };

package/dist/mcp/comment.d.ts

@@ -1,25 +1,19 @@
 import type { ToolContext } from "./server.ts";
-/**
- * The prefix text for the initial "leaping into action" comment.
- * This is used to identify if a comment is still in its initial state
- * and hasn't been updated with progress or error messages.
- */
-export declare const LEAPING_INTO_ACTION_PREFIX = "Leaping into action";
-export declare function isLeapingIntoActionCommentBody(body: string): boolean;
+export { isLeapingIntoActionCommentBody, LEAPING_INTO_ACTION_PREFIX, } from "../utils/leapingComment.ts";
 export declare function addFooter(ctx: ToolContext, body: string): string;
 export declare const Comment: import("arktype/internal/variants/object.ts").ObjectType<{
     issueNumber: number;
     body: string;
-    type?: "Plan" | "Summary" | "Comment";
+    type?: "Plan" | "Comment";
 }, {}>;
 export declare function CreateCommentTool(ctx: ToolContext): import("fastmcp").Tool<any, import("@standard-schema/spec").StandardSchemaV1<{
     issueNumber: number;
     body: string;
-    type?: "Plan" | "Summary" | "Comment";
+    type?: "Plan" | "Comment";
 }, {
     issueNumber: number;
     body: string;
-    type?: "Plan" | "Summary" | "Comment";
+    type?: "Plan" | "Comment";
 }>>;
 export declare const EditComment: import("arktype/internal/variants/object.ts").ObjectType<{
     commentId: number;
@@ -39,12 +33,15 @@ export declare const ReportProgress: import("arktype/internal/variants/object.ts
 /**
  * Report progress to a GitHub comment.
  *
- * progressCommentId has three states:
+ * progressComment has three states:
  *   - undefined: no comment yet — will create one if an issue/PR target exists
- *   - number:    active comment — will update it in place
+ *   - object:    active comment — will update it in place via the right REST endpoint for its type
  *   - null:      deliberately deleted (e.g. after submitting a PR review) — skips silently
  *
  * The body is always tracked in lastProgressBody for the job summary regardless of comment state.
+ *
+ * The "existing plan comment" path always targets a top-level issue comment (plan comments are
+ * created by create_issue_comment with type:"Plan", never as review-thread replies).
  */
 export declare function reportProgress(ctx: ToolContext, params: {
     body: string;
@@ -66,7 +63,7 @@ export declare function ReportProgressTool(ctx: ToolContext): import("fastmcp").
  * Delete the progress comment if it exists.
  * Used by main.ts for stranded-comment cleanup (orphaned "Leaping into action" or
  * checklist left by the todo tracker when the agent didn't call report_progress).
- * Sets progressCommentId to null so subsequent report_progress calls are no-ops.
+ * Sets progressComment to null so subsequent report_progress calls are no-ops.
  */
 export declare function deleteProgressComment(ctx: ToolContext): Promise<boolean>;
 export declare const ReplyToReviewComment: import("arktype/internal/variants/object.ts").ObjectType<{

package/dist/mcp/git.d.ts

@@ -6,6 +6,8 @@ export declare const PushBranch: import("arktype/internal/variants/object.ts").O
     force: import("arktype/internal/attributes.ts").Default<boolean, false>;
     branchName?: string;
 }, {}>;
+export type PushErrorKind = "concurrent-push" | "transient" | "unknown";
+export declare function classifyPushError(msg: string): PushErrorKind;
 export declare function PushBranchTool(ctx: ToolContext): import("fastmcp").Tool<any, import("@standard-schema/spec").StandardSchemaV1<{
     branchName?: string;
     force?: boolean;

package/dist/mcp/review.d.ts

@@ -52,8 +52,8 @@ export type DuplicateReviewDecision = {
  * the agent is instructed to call create_pull_request_review exactly once per
  * Review-mode session (see action/modes.ts), but in practice it sometimes
  * submits twice — once with substantive feedback, then again with the
- * canonical "Reviewed — no issues found." body when the prompt's branch
- * logic re-classifies non-blocking observations. the second submission is
+ * canonical "No new issues found." body when the prompt's branch logic
+ * re-classifies non-blocking observations. the second submission is
  * always redundant: the first review is the record, and the duplicate just
  * adds noise to the PR.
  *

package/dist/mcp/reviewComments.d.ts

@@ -97,6 +97,35 @@ interface GetReviewDataInput {
     reviewId: number;
     approvedBy?: string | undefined;
 }
+export interface FormatReviewDataInput {
+    review: ReviewResponse;
+    threads: ReviewThread[];
+    prFiles: ReviewPrFile[];
+    pullNumber: number;
+    reviewId: number;
+}
+export type ReviewResponse = {
+    body: string | null | undefined;
+    user: {
+        login: string;
+    } | null | undefined;
+};
+export type ReviewPrFile = {
+    filename: string;
+    patch?: string | undefined;
+};
+export declare function formatReviewData(input: FormatReviewDataInput): {
+    threadBlocks: Array<{
+        path: string;
+        lineRange: string;
+        content: string[];
+    }>;
+    reviewer: string;
+    formatted: {
+        toc: string;
+        content: string;
+    };
+} | undefined;
 export declare function getReviewData(input: GetReviewDataInput): Promise<{
     threadBlocks: Array<{
         path: string;

package/dist/mcp/selectMode.d.ts

@@ -9,12 +9,6 @@ export type PlanCommentResponsePayload = {
     commentId: number;
     body: string;
 };
-export type SummaryCommentResponsePayload = {
-    error: string;
-} | {
-    commentId: number;
-    body: string;
-};
 export declare function SelectModeTool(ctx: ToolContext): import("fastmcp").Tool<any, import("@standard-schema/spec").StandardSchemaV1<{
     mode: string;
     issue_number?: number;

package/dist/mcp/server.d.ts

@@ -6,6 +6,8 @@ import type { PrepResult } from "../prep/index.ts";
 import type { DiffCoverageState } from "../utils/diffCoverage.ts";
 import type { OctokitWithPlugins } from "../utils/github.ts";
 import type { ResolvedPayload } from "../utils/payload.ts";
+import { type ProgressComment, type ProgressCommentType } from "../utils/progressComment.ts";
+import type { AccountPlan } from "../utils/runContext.ts";
 import type { RunContextData } from "../utils/runContextData.ts";
 import type { TodoTracker } from "../utils/todoTracking.ts";
 import type { CommentableLines } from "./review.ts";
@@ -48,14 +50,16 @@ export interface ToolState {
         promise: Promise<PrepResult[]> | undefined;
         results: PrepResult[] | undefined;
     };
-    progressCommentId: number | null | undefined;
+    progressComment: ProgressComment | null | undefined;
     hadProgressComment: boolean;
     lastProgressBody?: string;
     wasUpdated?: boolean;
     finalSummaryWritten?: boolean;
     existingPlanCommentId?: number;
     previousPlanBody?: string;
-    existingSummaryCommentId?: number;
+    summaryFilePath?: string;
+    summarySeed?: string;
+    summaryPersistAttempted?: boolean;
     output?: string;
     usageEntries: AgentUsage[];
     model?: string | undefined;
@@ -63,7 +67,10 @@ export interface ToolState {
     diffCoverage?: DiffCoverageState | undefined;
 }
 interface InitToolStateParams {
-    progressCommentId: string | undefined;
+    progressComment: {
+        id: string;
+        type: ProgressCommentType;
+    } | undefined;
 }
 export declare function initToolState(params: InitToolStateParams): ToolState;
 export interface ToolContext {
@@ -84,6 +91,8 @@ export interface ToolContext {
     jobId: string | undefined;
     mcpServerUrl: string;
     tmpdir: string;
+    oss: boolean;
+    plan: AccountPlan;
     resolvedModel: string | undefined;
 }
 type JsonSchema = Record<string, unknown>;

package/dist/utils/diffCoverage.d.ts

@@ -43,6 +43,7 @@ export declare function createDiffCoverageState(params: {
     diffPath: string;
     totalLines: number;
     toc: string;
+    previous?: DiffCoverageState | undefined;
 }): DiffCoverageState;
 export declare function recordDiffReadFromToolUse(params: {
     state: DiffCoverageState | undefined;

package/dist/utils/leapingComment.d.ts

@@ -0,0 +1,11 @@
+/**
+ * The prefix text for the initial "leaping into action" comment.
+ * Used to detect whether a progress comment is still in its initial state
+ * and hasn't been updated with real progress or error messages.
+ *
+ * Lives in `utils/` (not `mcp/`) so it can be re-exported via `pullfrog/internal`
+ * without dragging the MCP server's transitive imports into the Next.js app's
+ * type-check graph.
+ */
+export declare const LEAPING_INTO_ACTION_PREFIX = "Leaping into action";
+export declare function isLeapingIntoActionCommentBody(body: string): boolean;

package/dist/utils/patchWorkflowRunFields.d.ts

@@ -5,7 +5,7 @@ import type { ToolContext } from "../mcp/server.ts";
  * are created during the run. Strings only (GraphQL node IDs).
  * Keep in sync with `STRING_FIELDS` in `app/api/workflow-run/[runId]/route.ts`.
  */
-export type WorkflowRunArtifactPatchKey = "prNodeId" | "issueNodeId" | "reviewNodeId" | "planCommentNodeId" | "summaryCommentNodeId";
+export type WorkflowRunArtifactPatchKey = "prNodeId" | "issueNodeId" | "reviewNodeId" | "planCommentNodeId" | "summaryCommentNodeId" | "summarySnapshot";
 /**
  * Usage fields — aggregated across all agent calls and PATCHed once at
  * end-of-run. Token counts are Int4 on the DB side (ample for any realistic

package/dist/utils/payload.d.ts

@@ -9,7 +9,11 @@ export declare const JsonPayload: import("arktype/internal/variants/object.ts").
     eventInstructions?: string;
     event?: object;
     timeout?: string | undefined;
-    progressCommentId?: string | undefined;
+    progressComment?: {
+        id: string;
+        type: "issue" | "review";
+    } | undefined;
+    generateSummary?: boolean | undefined;
 }, {}>;
 export declare const Inputs: import("arktype/internal/variants/object.ts").ObjectType<{
     prompt: string;
@@ -33,7 +37,11 @@ export declare function resolvePayload(resolvedPromptInput: ResolvedPromptInput,
     event: PayloadEvent;
     timeout: string | undefined;
     cwd: string | undefined;
-    progressCommentId: string | undefined;
+    progressComment: {
+        id: string;
+        type: "issue" | "review";
+    } | undefined;
+    generateSummary: boolean | undefined;
     push: import("../external.ts").PushPermission;
     shell: import("../external.ts").ShellPermission;
     proxyModel: string | undefined;

package/dist/utils/prSummary.d.ts

@@ -0,0 +1,40 @@
+/**
+ * The PR-level summary snapshot is a markdown file the agent edits in place
+ * during a Review / IncrementalReview run. The server seeds the file with
+ * either the previous run's snapshot (incremental) or a stub scaffold (first
+ * run), lets the agent edit it with its native file-editing tools, then
+ * reads it back at end-of-run and persists it to `WorkflowRun.summarySnapshot`.
+ *
+ * The snapshot is an internal artifact — it is consumed by future agent runs
+ * as durable cross-run context, not surfaced to humans. User-visible summary
+ * content lives in the Review / IncrementalReview review bodies, governed by
+ * `action/modes.ts`.
+ *
+ * Edit-in-place avoids the output-token tax of a tool call that regurgitates
+ * the full snapshot, and gives incremental runs a clean surface that
+ * range-diffs cleanly across runs because the section headings are stable.
+ */
+export declare const SUMMARY_FILE_NAME = "pullfrog-summary.md";
+/**
+ * minimal seed for first-run PRs. just a header + a one-line note about
+ * what this file is for. structure is intentionally NOT prescribed —
+ * different PRs warrant different organization, and the agent should pick
+ * a shape that fits this PR. the agent's prompt (see selectMode.ts
+ * `buildSummaryAddendum`) carries the actual instructions for what to
+ * capture and how.
+ *
+ * keeping the seed short also makes the unchanged-from-seed gate more
+ * sensitive — any meaningful edit moves the file off the seed, so
+ * `persistSummary` can reliably skip the DB write when the agent didn't
+ * touch the file.
+ */
+export declare const SUMMARY_SCAFFOLD = "# PR summary\n\n<!-- durable cross-run context. edit in place; the next agent run reads this\n     before reviewing new commits. structure however serves the PR best. -->\n";
+export declare function summaryFilePath(tmpdir: string): string;
+/** seed the summary file with previous snapshot (incremental) or scaffold (first run). */
+export declare function seedSummaryFile(params: {
+    tmpdir: string;
+    previousSnapshot: string | null;
+}): Promise<string>;
+/** read + validate the summary file written by the agent.
+ * returns null when the file is missing or fails sanity checks. */
+export declare function readSummaryFile(path: string): Promise<string | null>;