pullfrog 0.1.29 → 0.1.30

package/dist/internal.js

@@ -9,11 +9,20 @@ var providers = {
     displayName: "Anthropic",
     envVars: ["ANTHROPIC_API_KEY", "CLAUDE_CODE_OAUTH_TOKEN"],
     models: {
+      // OpenRouter serves claude-fable-5, but models.dev's OpenRouter mirror
+      // hasn't indexed it yet (shipped 2026-06-09), so the catalog drift gate
+      // can't validate an openRouterResolve. omit it until the mirror catches
+      // up; direct BYOK / Claude Code resolves anthropic/claude-fable-5 fine.
+      "claude-fable": {
+        displayName: "Claude Fable",
+        resolve: "anthropic/claude-fable-5",
+        preferred: true,
+        subagentModel: "claude-sonnet"
+      },
       "claude-opus": {
         displayName: "Claude Opus",
         resolve: "anthropic/claude-opus-4-8",
         openRouterResolve: "openrouter/anthropic/claude-opus-4.8",
-        preferred: true,
         subagentModel: "claude-sonnet"
       },
       "claude-sonnet": {
@@ -79,7 +88,8 @@ var providers = {
       },
       o3: {
         displayName: "O3",
-        resolve: "openai/o3"
+        resolve: "openai/o3",
+        openRouterResolve: "openrouter/openai/o3"
       }
     }
   }),
@@ -679,8 +689,10 @@ Inline comments use the same severity framing as body \`### \` sections, scaled
 - **Don't repeat diff content**, don't include raw \`+123 / -45\` stats, don't include a changelog section, don't use horizontal rules (\`---\`).
 - **Pull file/commit counts from \`checkout_pr\` metadata** \u2014 never count manually.
 - **Legacy headings REMOVED.** Do not use \`### Key changes\`, \`### Issues found\`, \`<b>TL;DR</b>\`, or \`<sub><b>Summary</b>\`. The new structure subsumes them.`;
-function computeModes(agentId) {
+function computeModes(agentId, signedCommits = false) {
   const t = (toolName) => formatMcpToolRef(agentId, toolName);
+  const commitStep = signedCommits ? `commit via \`${t("commit_changes")}\` \u2014 it lands a GitHub-signed commit directly on the remote branch (no push step)` : `commit locally via shell (\`git add . && git commit -m "..."\`)`;
+  const finalizeStep = signedCommits ? `confirm a clean working tree (\`git status\`) \u2014 your \`${t("commit_changes")}\` calls already landed the work on the remote` : `confirm a clean working tree, then push via \`${t("push_branch")}\``;
   return [
     {
       name: "Build",
@@ -751,10 +763,10 @@ 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.
 
-   Be **discerning** about what comes back. The reviewer is an AI subagent and is fallible \u2014 treat every finding as a hypothesis, not a directive, and **verify each one yourself** against the diff and the code before deciding whether to apply. You are searching for a solution that is **complete, minimal, and elegant** \u2014 you may need to think hard to find it. Do not over-engineer, do not be over-defensive, **do not write AI slop**. Reviewers bias toward *recommending additions*, and that bias has a recognizable slop texture: defensive checks for cases that cannot happen, extra logging, new abstractions used once, comments restating code, tests asserting tautologies, "just-in-case" guards, error handlers for cases the type system already rules out. Reject those. For each surviving finding, ask: would applying it leave the code more sound, correct, AND elegant? Two-out-of-three means look harder for a fix that gets all three before settling. After applying the fixes you accept, re-read your diff and be discerning about what *you just changed*: if any fix turned out to be bloat in context, revert it. 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 "..."\`).
+   Be **discerning** about what comes back. The reviewer is an AI subagent and is fallible \u2014 treat every finding as a hypothesis, not a directive, and **verify each one yourself** against the diff and the code before deciding whether to apply. You are searching for a solution that is **complete, minimal, and elegant** \u2014 you may need to think hard to find it. Do not over-engineer, do not be over-defensive, **do not write AI slop**. Reviewers bias toward *recommending additions*, and that bias has a recognizable slop texture: defensive checks for cases that cannot happen, extra logging, new abstractions used once, comments restating code, tests asserting tautologies, "just-in-case" guards, error handlers for cases the type system already rules out. Reject those. For each surviving finding, ask: would applying it leave the code more sound, correct, AND elegant? Two-out-of-three means look harder for a fix that gets all three before settling. After applying the fixes you accept, re-read your diff and be discerning about what *you just changed*: if any fix turned out to be bloat in context, revert it. Then verify only intended changes are present, no debug artifacts or commented-out code remain, no unrelated files were modified. Then ${commitStep}.
 
 6. **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)
+   - ${finalizeStep} (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
 
@@ -782,12 +794,12 @@ For simple, well-defined tasks, skip the plan phase and go straight to build.`
 
 5. 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 "..."\`)
+   - ${commitStep}
 
 6. Finalize. Reply + resolve are paired write actions: do BOTH or NEITHER for each thread.
-   - confirm a clean working tree, then push via \`${t("push_branch")}\` (same push/prepush guidance as Build mode in *SYSTEM*)
-   - **if push fails**, call \`${t("report_progress")}\` with the exact error and STOP \u2014 do NOT reply or resolve any thread until the fix is live on the remote. Resolving a thread without the fix landing misleads the reviewer.
-   - **on push success**, for each thread you acted on:
+   - ${finalizeStep} (same push/prepush guidance as Build mode in *SYSTEM*)
+   - **if the push/commit fails**, call \`${t("report_progress")}\` with the exact error and STOP \u2014 do NOT reply or resolve any thread until the fix is live on the remote. Resolving a thread without the fix landing misleads the reviewer.
+   - **once the fix is live on the remote**, for each thread you acted on:
      - reply ONCE via \`${t("reply_to_review_comment")}\`. The \`comment_id\` parameter takes the root comment's numeric \`id=\` (from the first \`comment author=...\` tag in the \`${t("get_review_comments")}\` output) \u2014 NOT the \`thread=\` value; that's a separate GraphQL ID used by resolve. The runtime dedupes identical bodies within a session.
      - **immediately** call \`${t("resolve_review_thread")}\` with that thread's \`thread=\` value as \`thread_id\`. Resolve every thread where you (a) made the requested code change in full \u2014 partial fixes leave the thread open \u2014 OR (b) replied with a substantive answer the user explicitly asked for. Do NOT resolve threads where you pushed back on the request and the disagreement is unresolved; leave those open for the human to mediate.
    - call \`${t("report_progress")}\` with a brief summary`
@@ -1062,10 +1074,10 @@ ${PR_SUMMARY_FORMAT}`
    - 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 "..."\`)
+   - ${commitStep}
 
 6. Finalize:
-   - confirm a clean working tree, then push via \`${t("push_branch")}\` (same push/prepush guidance as Build mode in *SYSTEM*)
+   - ${finalizeStep} (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)`
     },
     {
@@ -1081,8 +1093,8 @@ ${PR_SUMMARY_FORMAT}`
    - Call \`${t("git_fetch")}\` to fetch the base branch.
 
 3. **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 4\u20135.**
+   - Run \`git merge ${signedCommits ? "--no-commit " : ""}origin/<base_branch>\` via shell.
+   - If it succeeds automatically, ${signedCommits ? `conclude it via \`${t("commit_changes")}\` (it turns the pending merge into a signed merge commit on the remote)` : `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 error if it failed \u2014 **then stop; do not run steps 4\u20135.**
    - If it fails (conflicts), resolve them manually (continue to steps 4\u20135).
 
 4. **Resolve Conflicts**:
@@ -1092,8 +1104,8 @@ ${PR_SUMMARY_FORMAT}`
 
 5. **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*)
+   - ${signedCommits ? `\`git add .\`, then conclude via \`${t("commit_changes")}\` with message "resolve merge conflicts"` : `\`git add . && git commit -m "resolve merge conflicts"\``}
+   - ${finalizeStep} (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)`
     },
     {
@@ -1112,7 +1124,7 @@ ${PR_SUMMARY_FORMAT}`
    - 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
 
 4. 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).
+   - if code changes were made, get them onto a pull request (new or existing) using ${signedCommits ? `\`${t("commit_changes")}\`` : `\`${t("push_branch")}\``} and \`${t("create_pull_request")}\` as needed. \`git status\` must be clean before you finish (see *SYSTEM* Git rules if this 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`
     }
@@ -1123,15 +1135,6 @@ var modes = computeModes("opencode");
 // utils/buildPullfrogFooter.ts
 var PULLFROG_DIVIDER = "<!-- PULLFROG_DIVIDER_DO_NOT_REMOVE_PLZ -->";
 var FROG_LOGO = `<a href="https://pullfrog.com"><picture><source media="(prefers-color-scheme: dark)" srcset="https://pullfrog.com/logos/frog-white-full-18px.png"><img src="https://pullfrog.com/logos/frog-green-full-18px.png" width="9px" height="9px" style="vertical-align: middle; " alt="Pullfrog"></picture></a>`;
-function providerDisplayName(slug) {
-  try {
-    const key = getModelProvider(slug);
-    const meta = providers[key];
-    return meta?.displayName ?? key;
-  } catch {
-    return slug;
-  }
-}
 function formatModelLabel(params) {
   const alias = resolveDisplayAlias(params.model) ?? // reverse-lookup: when the caller passes an effective model (proxy or
   // resolved target like "openrouter/anthropic/claude-opus-4.7") instead of
@@ -1142,9 +1145,7 @@ function formatModelLabel(params) {
   if (params.oss) {
     return `\`${displayName}\` (free via [Pullfrog for OSS](https://pullfrog.com/for-oss))`;
   }
-  const base = alias?.isFree ? `\`${displayName}\` (free)` : `\`${displayName}\``;
-  if (!params.fallbackFrom) return base;
-  return `${base} (credentials for ${providerDisplayName(params.fallbackFrom)} not configured)`;
+  return alias?.isFree ? `\`${displayName}\` (free)` : `\`${displayName}\``;
 }
 function buildPullfrogFooter(params) {
   const parts = [];
@@ -1162,9 +1163,7 @@ function buildPullfrogFooter(params) {
     parts.push("via [Pullfrog](https://pullfrog.com)");
   }
   if (params.model) {
-    parts.push(
-      `Using ${formatModelLabel({ model: params.model, fallbackFrom: params.fallbackFrom, oss: params.oss })}`
-    );
+    parts.push(`Using ${formatModelLabel({ model: params.model, oss: params.oss })}`);
   }
   const allParts = [...parts, "[\u{1D54F}](https://x.com/pullfrogai)"];
   return `

package/dist/mcp/git.d.ts

@@ -15,6 +15,13 @@ export declare function PushBranchTool(ctx: ToolContext): import("fastmcp").Tool
     branchName?: string;
     force?: boolean;
 }>>;
+export declare function CommitChangesTool(ctx: ToolContext): import("fastmcp").Tool<any, import("@standard-schema/spec").StandardSchemaV1<{
+    message: string;
+    files?: string[];
+}, {
+    message: string;
+    files?: string[];
+}>>;
 export declare const AUTH_REQUIRED_REDIRECT: Record<string, string>;
 export declare const NOSHELL_BLOCKED_SUBCOMMANDS: Record<string, string>;
 export declare const NOSHELL_BLOCKED_ARGS: string[];

package/dist/mcp/server.d.ts

@@ -18,6 +18,7 @@ export interface ToolContext {
     postCheckoutScript: string | null;
     prepushScript: string | null;
     prApproveEnabled: boolean;
+    signedCommits: boolean;
     modeInstructions: Record<string, string>;
     toolState: ToolState;
     runId: number | undefined;

package/dist/modes.d.ts

@@ -5,7 +5,7 @@ export interface Mode {
     prompt?: string | undefined;
 }
 export declare const PR_SUMMARY_FORMAT = "### Default format\n\nThe body has at most three parts in this exact order:\n\n1. **Reviewed changes preamble** \u2014 one bolded inline lead-in describing what was reviewed in this run, a bullet list of the substantive changes, and an HTML comment carrying review metadata for downstream agents.\n2. **Cross-cutting issue sections** (zero or more) \u2014 one `### ` heading per concern, with a human-readable problem write-up and a collapsed `<details>Technical details</details>` block underneath.\n3. **`### \u2139\uFE0F Nitpicks`** at the very bottom (only if there are nits worth surfacing in the body) \u2014 a flat bullet list, no technical-details block.\n\nInline-vs-body split: concerns that anchor to a specific line go inline (use the `comments` parameter). Body `### ` sections are reserved for concerns that **have no line to anchor to** \u2014 typically because the concern is about *absence* (something the diff should have done but didn't), *sequencing* (rollout / deletion / migration order), *design decisions only the human can make*, or *scope questions the diff implicitly raises but doesn't address*. A concern that anchors to a line but has broad implications still goes inline (use the technical-details block there to capture the implications \u2014 see Inline technical details below). If you found no non-anchorable concerns, the body has zero `### ` issue sections \u2014 just the preamble + metadata.\n\n## 1. Reviewed changes preamble\n\nOpen with a single bolded inline lead-in followed immediately by the bullet list (no `### Key changes` heading, no `<b>TL;DR</b>`):\n\n```\n**Reviewed changes** \u2014 one sentence on what was reviewed in this run. For Review (initial), this is what the PR does and why. For IncrementalReview, this is what changed since the prior pullfrog review. Focus on intent, not mechanics.\n\n- **Short human-readable title** \u2014 1 sentence per substantive change. Write a short prose phrase; 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 reviewed scope from this list alone \u2014 this IS the dispassionate \"what was reviewed and what changed\" overview, so cover the substantive changes, not just the loudest ones.\n\n<!--\nPullfrog review metadata \u2014 for any agent (or human-with-agent) reading this\nreview. Incorporate the fields below into your understanding of the context\nthis review was made in. The findings below were written against\n{head_sha_short}; if new commits have landed on {head_ref} since this review\nwas submitted, treat any specific bug, file, or line callout as POTENTIALLY\nSTALE \u2014 re-diff against {head_sha_short} (or trigger a fresh review) and\nfactor commits past {head_sha_short} into your understanding of the current\nstate before acting on findings.\n\n- Mode: Review (initial)   or   IncrementalReview (delta against prior pullfrog review)\n- Files reviewed: {file_count}\n- Commits reviewed: {commit_count}\n- Base: {base_ref} ({base_sha_short})\n- Head: {head_ref} ({head_sha_short})\n- Reviewed commits:\n  - {sha_short} \u2014 {commit_subject}\n  - ...\n- Prior pullfrog review: none   or   {prior_sha_short} ({prior_review_html_url})\n- Submitted at: {iso_timestamp}\n-->\n```\n\nPull every metadata field from the `checkout_pr` tool's response \u2014 file count, commit count, base/head ref + SHA, the commit list. For `IncrementalReview` runs, populate `Prior pullfrog review` with the prior review's commit_id (short SHA) and `html_url` from `list_pull_request_reviews`.\n\n## 2. Cross-cutting issue sections (zero or more)\n\nFor each cross-cutting concern, one `### ` section. Use this exact shape:\n\n```\n### {emoji} {short, descriptive title \u2014 what's wrong, not what to do}\n\n{Human-readable problem write-up. Describes the PROBLEM only \u2014 what's broken, what the symptom is, what the blast radius is. NO asks, NO suggested fixes, NO \"the right thing to do is...\". Asks and fixes live in the technical-details block below; the visible part is for the human to *understand* the problem, not to implement it.}\n\n<details><summary>Technical details</summary>\n\n\\`\\`\\`\\`markdown\n# {title repeated}\n\n## Affected sites\n- {file path:line} \u2014 {what's wrong there}\n- ...\n\n## Required outcome\n- {what the fix needs to achieve, not how to achieve it}\n- ...\n\n## Suggested approach (optional)\n{When the fix shape is non-obvious, sketch one or more reasonable directions. Skip when the outcome alone makes the fix obvious.}\n\n## Open questions for the human (optional)\n- {Any decision an implementing agent shouldn't make unilaterally \u2014 pricing thresholds, breaking-change policy, naming, scope of follow-up.}\n\\`\\`\\`\\`\n\n</details>\n```\n\nConcrete example of the visible part of a non-anchored section (technical-details block unchanged from the template above):\n\n```\n### \u2139\uFE0F Legacy `opencode.ts` has no documented deletion plan\n\nThe v2 harness lands alongside the v1 file and imports one helper from it. Worth a follow-up issue or a TODO so the next maintainer doesn't have to re-derive the cleanup plan.\n```\n\nThe example's value is its *shape*: a finding about absence (no deletion plan), not a line-anchored bug. Body sections live or die on whether the concern genuinely doesn't fit on a line.\n\n**Heading severity emoji** \u2014 every `### ` heading carries one:\n\n- \uD83D\uDEA8 critical \u2014 blocks merge (data loss, security, broken core flow)\n- \u26A0\uFE0F important \u2014 must address before merging (regression, missing validation, incorrect behavior)\n- \u2139\uFE0F informational \u2014 surfaced for awareness; mergeable as-is\n\n**Visible problem write-up rules:**\n\n- **No asks, no suggested fixes** in the visible part. The visible portion describes the problem; the technical-details block describes the fix shape and any open questions. The exception: a fix so self-evident that NOT stating it would be weird (e.g. \"the typo is missing an 'r'\") \u2014 in that case, fold it into the problem statement and skip the suggested-approach block in technical details too.\n- **Never two successive plain paragraphs.** Every transition between block-level elements must alternate prose with structure: paragraph \u2192 bullet list \u2192 paragraph; paragraph \u2192 code fence \u2192 bullet list; paragraph \u2192 table \u2192 paragraph. Two consecutive paragraphs in a row create a wall of text that's impossible to digest. If you catch yourself writing one, find a way to split it: pull a list out of it, drop a 2-3 line code fence between them, or merge them into a single tighter paragraph.\n- **Per-paragraph budget:** ~3 sentences max. Past that, you're explaining where you should be structuring.\n- **Identifier discipline still applies** in the visible part. Lead with behavior in plain English; name an identifier only when it's the subject of the concern or a public surface a reader would recognize. The technical-details block is where dense identifier references belong.\n\n**Technical-details block rules:**\n\n- Wrapped in a 4-backtick markdown fence (`\\`\\`\\`\\`markdown ... \\`\\`\\`\\``) so it's visually distinct, one-click copyable, and can contain its own 3-backtick code fences without escape gymnastics. The contents are agent-readable \u2014 a fix-agent will pull the body down and use this block as the brief.\n- File paths and `file:line` refs are encouraged (and necessary) \u2014 the next agent uses these to navigate. Identifier density is fine here.\n- Slightly more verbose than the absolute minimum is OK when it materially helps the next agent: a small code snippet showing the symptom, a short table of mismatched key/column pairs, a one-paragraph \"why CI doesn't catch it\" note. Skip massive regression-test scaffolding or full route rewrites \u2014 the implementing agent writes those.\n- Use the four standard sections (`Affected sites`, `Required outcome`, optional `Suggested approach`, optional `Open questions for the human`). Skip the optional sections when they wouldn't add anything.\n\n## Inline technical details\n\nInline comments are short (~2-3 sentences) by default. When an inline finding has broader implications worth recording for a fix-agent \u2014 e.g. a localized bug whose proper fix requires touching several files, or where the right fix depends on a design decision the human needs to make \u2014 append a collapsed `<details><summary>Technical details</summary>` block to the inline comment's body. Same shape as the body-section technical-details block (4-backtick fenced markdown, `## Affected sites` / `## Required outcome` / optional `## Suggested approach` / optional `## Open questions for the human`).\n\nGitHub renders the same markdown parser in inline comments as in the review body, so the collapsed-details affordance works the same way. The visible part of the inline comment stays scannable; the depth is one click away for any agent that needs it.\n\n## 3. `### \u2139\uFE0F Nitpicks` (optional, last section)\n\nOnly when there are nits that for some reason can't be inlined. Filepaths in nit text are fine \u2014 these are simple enough that a human or agent reads once and acts. No technical-details block.\n\n```\n### \u2139\uFE0F Nitpicks\n\n- {nit, with file path inline if useful, \u2264 ~200 chars}\n- ...\n```\n\n## Inline comment shape\n\nInline comments use the same severity framing as body `### ` sections, scaled down for line-anchored use:\n\n- **Lead with a 1-2 sentence problem statement.** The reader is looking at the line in question, so don't restate what the line says \u2014 describe what's wrong with it. Optionally prefix the visible line with a severity emoji (\uD83D\uDEA8 / \u26A0\uFE0F / \u2139\uFE0F) when severity isn't obvious from context.\n- **Optional `<details><summary>Technical details</summary>...</details>` collapsible** for findings whose technical context (longer file:line references, related-code snippets, suggested approach, regression-risk notes) would overwhelm the human-readable lead-in. Same agent-readable purpose, same 4-backtick fence shape, and same 4-section structure as the body's technical-details block \u2014 see *Inline technical details* above. Encouraged whenever the depth helps a downstream fix-agent; don't force one when the inline lead-in already says everything.\n- **Visible portion \u2264 2-3 sentences.** If you find yourself writing more, that's the cue to split the depth into the `Technical details` collapsible.\n\n## Body-wide rules\n\n- **Inline-vs-body discipline (repeated for emphasis):** anything that anchors to a specific line goes inline (with a `<details>Technical details</details>` block when the implications are broad). The body is for non-anchorable concerns only \u2014 absence, sequencing, design decisions, scope questions, architectural risk.\n- **No `### Issues found` heading** above the issue sections \u2014 each `### ` heading IS the issue.\n- **Severity emoji on every `### ` heading** (\uD83D\uDEA8 / \u26A0\uFE0F / \u2139\uFE0F). No emoji on the preamble lead-in or anywhere else.\n- **GitHub block-level rendering**: GitHub's markdown parser requires a blank line between ALL block-level elements (HTML tags like `<br/>`, `<sub>`, `<details>`, `<b>` and markdown syntax like headings, lists, blockquotes, code fences, paragraphs). Without a blank line, GitHub treats 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.\n- **Backtick-wrap** every variable, identifier, or file name when you mention one (in either visible or technical-details portions).\n- **Don't repeat diff content**, don't include raw `+123 / -45` stats, don't include a changelog section, don't use horizontal rules (`---`).\n- **Pull file/commit counts from `checkout_pr` metadata** \u2014 never count manually.\n- **Legacy headings REMOVED.** Do not use `### Key changes`, `### Issues found`, `<b>TL;DR</b>`, or `<sub><b>Summary</b>`. The new structure subsumes them.";
-export declare function computeModes(agentId: AgentId): Mode[];
+export declare function computeModes(agentId: AgentId, signedCommits?: boolean): Mode[];
 export declare const modes: Mode[];
 /**
  * modes that legitimately never modify the working tree. used by the post-run

package/dist/toolState.d.ts

@@ -105,9 +105,6 @@ export interface ToolState {
     output?: string | undefined;
     usageEntries: AgentUsage[];
     model?: string | undefined;
-    modelFallback?: {
-        from: string;
-    } | undefined;
     oss?: boolean | undefined;
     todoTracker?: TodoTracker | undefined;
     diffCoverage?: DiffCoverageState | undefined;

package/dist/utils/apiCommit.d.ts

@@ -0,0 +1,40 @@
+/** one working-tree change to include in an API commit. */
+export type ChangedFile = {
+    path: string;
+    deleted: boolean;
+};
+/**
+ * all working-tree changes vs HEAD: tracked changes (committed-to-index,
+ * staged, and unstaged all collapse into `git diff HEAD`) plus untracked
+ * files from `git status`. respects .gitignore. throws on unresolved
+ * conflicts — the caller's guidance is to resolve and `git add` first.
+ */
+export declare function detectWorkingTreeChanges(): ChangedFile[];
+/**
+ * refuse content the API path cannot faithfully commit: git-lfs files (the
+ * pointer would be committed without the lfs object upload that the git
+ * pre-push hook performs) and directories (nested repositories / submodule
+ * pointers). other clean filters are fine — blob content goes through
+ * `git hash-object`, which applies them exactly like a local commit.
+ */
+export declare function assertApiCommittable(files: ChangedFile[]): Promise<void>;
+/**
+ * create one GitHub-signed commit on `remoteBranch` containing `files` read
+ * from the working tree, parented on `parents` (first parent supplies the
+ * base tree; a second parent — MERGE_HEAD — makes it a true merge commit so
+ * base-branch integration doesn't pollute the PR diff). empty `files` with
+ * two parents concludes a merge that resolved to the first parent's tree.
+ * creates the remote branch at the new commit when it doesn't exist yet.
+ */
+export declare function createSignedCommit(params: {
+    token: string;
+    owner: string;
+    repo: string;
+    remoteBranch: string;
+    message: string;
+    parents: string[];
+    files: ChangedFile[];
+}): Promise<{
+    sha: string;
+    createdBranch: boolean;
+}>;

package/dist/utils/apiKeys.d.ts

@@ -27,8 +27,23 @@ export declare function validateAgentApiKey(params: {
  *     {"type":"error","error":{"type":"authentication_error", ...
  *     "Invalid bearer token"}}`) emitted by the Claude CLI for revoked /
  *     mistyped / rotated `ANTHROPIC_API_KEY`. see #782.
+ *   - expired credentials (#931): Bedrock 403 `Failed to authenticate. API
+ *     Error: 403 {"Message":"*** has expired"}` (short-lived bearer tokens),
+ *     OpenAI OAuth "Your authentication token has expired", and Codex
+ *     "Token refresh failed: 401". the Bedrock pattern is anchored to the
+ *     Claude CLI emission ("Failed to authenticate. API Error:") so generic
+ *     auth chatter in agent stderr can't misclassify a hang as a key error.
  */
 export declare function isApiKeyAuthError(text: string): boolean;
+/**
+ * Expired OAuth-connection credential shapes (#931) — the fix is to
+ * re-authenticate the provider connection (`pullfrog auth <provider>`), not
+ * to rotate a repo-secret API key, so `formatApiKeyErrorSummary` renders
+ * distinct copy for these. Patterns are deliberately narrow:
+ * "authentication token has expired" (not bare "token has expired") so a
+ * GitHub installation-token expiry can't be misread as an LLM key problem.
+ */
+export declare function isOAuthCredentialExpiredError(text: string): boolean;
 /**
  * Friendly Markdown summary for both the missing-key and invalid-key cases.
  * Used in the catch / result-failure paths in `main.ts` to overwrite the raw

package/dist/utils/buildPullfrogFooter.d.ts

@@ -17,13 +17,6 @@ export interface BuildPullfrogFooterParams {
     customParts?: string[] | undefined;
     /** model slug from payload (e.g., "anthropic/claude-opus"). shown in footer as "Using `Model Name`" */
     model?: string | undefined;
-    /**
-     * When the action engaged the BYOK fallback, this is the slug the user
-     * had configured (e.g. "anthropic/claude-opus") — the footer renders
-     * `Using <free model> (credentials for <configured> not configured)`
-     * so the substitution is visible in PR comments + reviews.
-     */
-    fallbackFrom?: string | undefined;
     /**
      * true when the run's model costs are covered by the Pullfrog for OSS
      * program — the footer renders `Using <model> (free via Pullfrog for OSS)`

package/dist/utils/claudeSubscription.d.ts

@@ -0,0 +1,30 @@
+export type SubscriptionPreflight = {
+    usable: true;
+} | {
+    usable: false;
+    reason: string;
+};
+/**
+ * preflight a Claude subscription OAuth token (`CLAUDE_CODE_OAUTH_TOKEN`)
+ * with a 1-token Messages call, so the agent can fall back to
+ * `ANTHROPIC_API_KEY` when the subscription is exhausted or revoked instead
+ * of failing the whole run at its first model call. rides the same de-facto
+ * OAuth surface Claude Code itself uses: Bearer auth + the
+ * `claude-code-20250219,oauth-2025-04-20` betas + the identity system prompt.
+ *
+ * probes the run's own model when known — subscription limits can be
+ * per-model ("You've hit your Opus limit"), so a cheaper stand-in could pass
+ * preflight and still leave the run dead on arrival.
+ *
+ * fail-open by design: only 401 (revoked/expired token) and 429
+ * (session/weekly/per-model limit) mark the token unusable. network errors,
+ * 5xx, and request-shape drift (400) all keep today's subscription-first
+ * behavior, so the preflight can never fail a run that would have worked —
+ * the worst wrong answer is a run that bills the API key instead of the
+ * subscription.
+ */
+export declare function preflightClaudeSubscription(params: {
+    token: string;
+    /** bare Anthropic model id the run will use (e.g. "claude-fable-5") */
+    model: string | undefined;
+}): Promise<SubscriptionPreflight>;

package/dist/utils/github.d.ts

@@ -1,5 +1,10 @@
 import { throttling } from "@octokit/plugin-throttling";
 import { Octokit } from "@octokit/rest";
+/** GitHub Actions OIDC request credentials, stashed before env wipes */
+export interface OidcCredentials {
+    requestUrl: string;
+    requestToken: string;
+}
 export interface InstallationToken {
     token: string;
     expires_at: string;
@@ -37,7 +42,21 @@ type GitHubAppPermissions = {
 type AcquireTokenOptions = {
     repos?: string[];
     permissions?: GitHubAppPermissions;
+    /**
+     * stashed OIDC credentials for minting after restricted mode deletes
+     * ACTIONS_ID_TOKEN_REQUEST_* from process.env (mid-run token refresh)
+     */
+    oidc?: OidcCredentials | undefined;
 };
+/**
+ * mint a GitHub Actions OIDC ID token from stashed credentials without
+ * touching process.env — `core.getIDToken` reads the env vars directly,
+ * which restricted mode has already deleted by the time a refresh runs.
+ * throws TokenExchangeError on HTTP errors and a "timed out" Error on
+ * timeout so `acquireNewToken`'s retry predicate treats 5xx/429/timeouts
+ * as transient.
+ */
+export declare function fetchIdTokenFromStash(creds: OidcCredentials): Promise<string>;
 /**
  * ensure a GitHub token is available in the environment.
  *
@@ -51,6 +70,13 @@ type AcquireTokenOptions = {
  * main() directly and never calls this.
  */
 export declare function ensureGitHubToken(): Promise<void>;
+/**
+ * retry predicate shared by token mints: 4xx is terminal user state (app not
+ * installed, permissions wrong) — retrying just triples our log noise and the
+ * user's CI bill (see #693). 5xx/429 and network failures are transient
+ * (vercel cold start, github outage, rate limit) and should ride the backoff.
+ */
+export declare function isTransientTokenError(error: unknown): boolean;
 export declare function acquireNewToken(opts?: AcquireTokenOptions): Promise<string>;
 export interface RepoContext {
     owner: string;
@@ -74,5 +100,5 @@ export interface UsageSummary {
     };
 }
 export declare function writeGitHubUsageSummaryToFile(path: string): Promise<void>;
-export declare function createOctokit(token: string): OctokitWithPlugins;
+export declare function createOctokit(token: string, refreshAuth?: (stale: string) => Promise<string>): OctokitWithPlugins;
 export {};

package/dist/utils/instructions.d.ts

@@ -9,6 +9,9 @@ interface InstructionsContext {
     modes: Mode[];
     agentId: AgentId;
     outputSchema?: Record<string, unknown> | undefined;
+    /** commits are created via the GitHub API (commit_changes tool) so GitHub
+     * signs them — flips the Git instructions to the signed-commits flow. */
+    signedCommits: boolean;
     /** absolute path to the seeded learnings tmpfile, or null when the file
      * couldn't be seeded for some reason. main.ts always seeds, so in
      * practice this is always set; the null case keeps the type honest. */

package/dist/utils/openCodeModels.d.ts

@@ -6,6 +6,6 @@ export declare function captureBaselineModels(cliPath: string): void;
  * `» BYOK auth enabled N model(s): …`. */
 export declare function captureAuthorizedModels(cliPath: string): void;
 /** Authorized set captured after Pullfrog-stored auth is applied. Throws if
- * called before `captureAuthorizedModels` — the call sites (fallback gate,
- * api-key validation, auto-select) all run strictly after capture. */
+ * called before `captureAuthorizedModels` — the call sites (api-key
+ * validation, auto-select) all run strictly after capture. */
 export declare function getAuthorizedModels(): Set<string>;

package/dist/utils/proxy.d.ts

@@ -4,7 +4,8 @@
  * billing accounts) or OSS-grant paths.
  *
  * Authenticates one of two ways:
- *   - production: GitHub Actions OIDC token via `core.getIDToken`
+ *   - production: GitHub Actions OIDC token minted from the stashed
+ *     credentials via `fetchIdTokenFromStash` (env-free)
  *   - local dev (`API_URL` is localhost): `x-dev-repo` header bypass
  *
  * `runProxyResolution` is the entrypoint `main.ts` calls. It wraps
@@ -17,11 +18,8 @@
  *   - 503 → `TransientError` (transient sync issue — retry next dispatch)
  */
 import type { ToolState } from "../toolState.ts";
+import { type OidcCredentials } from "./github.ts";
 import type { ResolvedPayload } from "./payload.ts";
-export interface OidcCredentials {
-    requestUrl: string;
-    requestToken: string;
-}
 /**
  * Run `resolveProxyModel`; if it throws a Billing or Transient error, render
  * the user-facing summary, mirror it to the PR progress comment, and rethrow.

package/dist/utils/runContext.d.ts

@@ -31,6 +31,7 @@ export interface RepoSettings {
     push: PushPermission;
     shell: ShellPermission;
     prApproveEnabled: boolean;
+    signedCommits: boolean;
     modeInstructions: Record<string, string>;
     learnings: string | null;
     learningsHeadings: LearningsHeading[];

package/dist/utils/runErrorRenderer.d.ts

@@ -24,8 +24,8 @@
  *      the underlying provider error often lands); `formatApiKeyErrorSummary`
  *      renders provider + console-link copy.
  *
- *   4. ProviderModelNotFoundError — stale free-fallback model id no longer
- *      in the OpenCode catalog; renders a nudge to add a BYOK key.
+ *   4. ProviderModelNotFoundError — configured model id no longer in the
+ *      OpenCode catalog; renders a nudge to pick a different model.
  *
  *   5. Activity-timeout hang — `errorMessage` starts with
  *      `"activity timeout"` or `"agent still pending"` AND none of the

package/dist/utils/token.d.ts

@@ -1,7 +1,12 @@
 import type { PushPermission } from "../external.ts";
-import { acquireNewToken } from "./github.ts";
+import { acquireNewToken, type OidcCredentials } from "./github.ts";
 export { acquireNewToken as acquireInstallationToken };
 export { revokeGitHubInstallationToken as revokeInstallationToken };
+/**
+ * get the refresh function for the MCP token, if re-acquisition is possible.
+ * pass to `createOctokit` so a mid-run 401 triggers a refresh + retry (#891).
+ */
+export declare function getMcpTokenRefresh(): ((stale: string) => Promise<string>) | undefined;
 /**
  * get the job-scoped token from action input.
  * this token has permissions defined by the workflow's permissions block.
@@ -19,6 +24,12 @@ export type TokenRef = {
 };
 type ResolveTokensParams = {
     push: PushPermission;
+    /**
+     * OIDC credentials stashed by main.ts before the restricted-mode env wipe —
+     * the mid-run MCP token refresh mints from this snapshot (#891). null when
+     * OIDC isn't available (local dev, external token).
+     */
+    oidc: OidcCredentials | null;
 };
 /**
  * resolve tokens for the action run.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "pullfrog",
-  "version": "0.1.29",
+  "version": "0.1.30",
   "type": "module",
   "bin": {
     "pullfrog": "dist/cli.mjs",

package/dist/utils/byokFallback.d.ts

@@ -1,44 +0,0 @@
-import type { AgentId } from "../external.ts";
-/**
- * Slug we fall back to when a BYOK-required model is configured but the
- * runner has no provider key in env. Picked because it's free, stable, and
- * currently served by OpenCode Zen without a key.
- *
- * The slug is intentionally hard-coded and not a config knob — the
- * fallback is a safety net, not a user-facing preference, and adding a
- * config surface here would just push the same "what to fall back to"
- * decision into another setting that goes stale the same way.
- */
-export declare const FREE_FALLBACK_SLUG = "opencode/big-pickle";
-export type FallbackDecision = {
-    fallback: false;
-} | {
-    fallback: true;
-    from: string;
-    to: string;
-};
-/**
- * If the resolved model is NOT in OpenCode's `authorized` set (the
- * authoritative "what can OpenCode route right now" snapshot captured
- * after dbSecrets + Codex auth.json are in place), swap to a free
- * OpenCode slug so the run can still produce value. Caller is responsible
- * for surfacing the swap (log line + run summary).
- *
- * Skip cases (return `fallback: false` without consulting `authorized`):
- *   - Router / proxy runs (`proxyModel` set): Pullfrog mints the key.
- *   - No resolved model: auto-select handles it downstream.
- *   - Resolved model is the free fallback already.
- *   - Resolved model is a raw Bedrock / Vertex ID (no `/`): the routing
- *     validators (`validateBedrockSetup` / `validateVertexSetup`) cover
- *     auth + region/location/model-id; `opencode models` does not.
- *   - The selected agent is `claude`: the Claude Code harness brings its own
- *     auth and `resolveAgent` only returns it when that auth is present.
- *     `opencode models` can't see `CLAUDE_CODE_OAUTH_TOKEN`, so without this
- *     an OAuth-subscription run on an Anthropic model would wrongly fall back.
- */
-export declare function selectFallbackModelIfNeeded(input: {
-    resolvedModel: string | undefined;
-    proxyModel: string | undefined;
-    authorized: Set<string>;
-    agentName: AgentId;
-}): FallbackDecision;