pullfrog 0.0.201 → 0.0.203

package/dist/internal/index.d.ts

@@ -3,7 +3,7 @@
  * Re-exports shared types, values, and utilities needed by the Next.js app.
  */
 export type { AuthorPermission, ModelAlias, ModelProvider, Payload, PayloadEvent, ProviderConfig, PushPermission, ShellPermission, ToolPermission, WriteablePayload, } from "../external.ts";
-export { getModelEnvVars, getModelProvider, getProviderDisplayName, modelAliases, parseModel, providers, pullfrogMcpName, resolveCliModel, resolveModelSlug, } from "../external.ts";
+export { getModelEnvVars, getModelProvider, getProviderDisplayName, modelAliases, parseModel, providers, pullfrogMcpName, resolveCliModel, resolveDisplayAlias, resolveModelSlug, resolveOpenRouterModel, } from "../external.ts";
 export type { Mode } from "../modes.ts";
 export { modes } from "../modes.ts";
 export type { BuildPullfrogFooterParams, WorkflowRunFooterInfo, } from "../utils/buildPullfrogFooter.ts";

package/dist/internal.js

@@ -11,8 +11,8 @@ var providers = {
     models: {
       "claude-opus": {
         displayName: "Claude Opus",
-        resolve: "anthropic/claude-opus-4-6",
-        openRouterResolve: "openrouter/anthropic/claude-opus-4.6",
+        resolve: "anthropic/claude-opus-4-7",
+        openRouterResolve: "openrouter/anthropic/claude-opus-4.7",
         preferred: true
       },
       "claude-sonnet": {
@@ -31,16 +31,38 @@ var providers = {
     displayName: "OpenAI",
     envVars: ["OPENAI_API_KEY"],
     models: {
+      gpt: {
+        displayName: "GPT",
+        resolve: "openai/gpt-5.5",
+        openRouterResolve: "openrouter/openai/gpt-5.5",
+        preferred: true
+      },
+      "gpt-pro": {
+        displayName: "GPT Pro",
+        resolve: "openai/gpt-5.5-pro",
+        openRouterResolve: "openrouter/openai/gpt-5.5-pro"
+      },
+      "gpt-mini": {
+        displayName: "GPT Mini",
+        resolve: "openai/gpt-5.4-mini",
+        openRouterResolve: "openrouter/openai/gpt-5.4-mini"
+      },
+      // legacy aliases — openai unified the codex line into the main GPT family
+      // and is shutting down every "-codex" snapshot on 2026-07-23. transparently
+      // upgrade existing users via the fallback chain. UI display sites resolve
+      // to the terminal alias's label (so dropdown trigger + PR footers show
+      // "GPT" / "GPT Mini", not the historical name).
       "gpt-codex": {
         displayName: "GPT Codex",
         resolve: "openai/gpt-5.3-codex",
         openRouterResolve: "openrouter/openai/gpt-5.3-codex",
-        preferred: true
+        fallback: "openai/gpt"
       },
       "gpt-codex-mini": {
         displayName: "GPT Codex Mini",
-        resolve: "openai/codex-mini-latest",
-        openRouterResolve: "openrouter/openai/gpt-5.1-codex-mini"
+        resolve: "openai/gpt-5.1-codex-mini",
+        openRouterResolve: "openrouter/openai/gpt-5.1-codex-mini",
+        fallback: "openai/gpt-mini"
       },
       o3: {
         displayName: "O3",
@@ -91,16 +113,30 @@ var providers = {
     displayName: "DeepSeek",
     envVars: ["DEEPSEEK_API_KEY"],
     models: {
+      "deepseek-pro": {
+        displayName: "DeepSeek Pro",
+        resolve: "deepseek/deepseek-v4-pro",
+        openRouterResolve: "openrouter/deepseek/deepseek-v4-pro",
+        preferred: true
+      },
+      "deepseek-flash": {
+        displayName: "DeepSeek Flash",
+        resolve: "deepseek/deepseek-v4-flash",
+        openRouterResolve: "openrouter/deepseek/deepseek-v4-flash"
+      },
+      // legacy aliases — deepseek retires these on 2026-07-24; transparently
+      // upgrade existing users to the v4 family via the fallback chain.
       "deepseek-reasoner": {
         displayName: "DeepSeek Reasoner",
         resolve: "deepseek/deepseek-reasoner",
         openRouterResolve: "openrouter/deepseek/deepseek-v3.2",
-        preferred: true
+        fallback: "deepseek/deepseek-pro"
       },
       "deepseek-chat": {
         displayName: "DeepSeek Chat",
         resolve: "deepseek/deepseek-chat",
-        openRouterResolve: "openrouter/deepseek/deepseek-v3.2"
+        openRouterResolve: "openrouter/deepseek/deepseek-v3.2",
+        fallback: "deepseek/deepseek-flash"
       }
     }
   }),
@@ -110,8 +146,8 @@ var providers = {
     models: {
       "kimi-k2": {
         displayName: "Kimi K2",
-        resolve: "moonshotai/kimi-k2.5",
-        openRouterResolve: "openrouter/moonshotai/kimi-k2.5",
+        resolve: "moonshotai/kimi-k2.6",
+        openRouterResolve: "openrouter/moonshotai/kimi-k2.6",
         preferred: true
       }
     }
@@ -129,8 +165,8 @@ var providers = {
       },
       "claude-opus": {
         displayName: "Claude Opus",
-        resolve: "opencode/claude-opus-4-6",
-        openRouterResolve: "openrouter/anthropic/claude-opus-4.6"
+        resolve: "opencode/claude-opus-4-7",
+        openRouterResolve: "openrouter/anthropic/claude-opus-4.7"
       },
       "claude-sonnet": {
         displayName: "Claude Sonnet",
@@ -142,15 +178,33 @@ var providers = {
         resolve: "opencode/claude-haiku-4-5",
         openRouterResolve: "openrouter/anthropic/claude-haiku-4.5"
       },
+      gpt: {
+        displayName: "GPT",
+        resolve: "opencode/gpt-5.5",
+        openRouterResolve: "openrouter/openai/gpt-5.5"
+      },
+      "gpt-pro": {
+        displayName: "GPT Pro",
+        resolve: "opencode/gpt-5.5-pro",
+        openRouterResolve: "openrouter/openai/gpt-5.5-pro"
+      },
+      "gpt-mini": {
+        displayName: "GPT Mini",
+        resolve: "opencode/gpt-5.4-mini",
+        openRouterResolve: "openrouter/openai/gpt-5.4-mini"
+      },
+      // legacy aliases — see openai provider above for context.
       "gpt-codex": {
         displayName: "GPT Codex",
         resolve: "opencode/gpt-5.3-codex",
-        openRouterResolve: "openrouter/openai/gpt-5.3-codex"
+        openRouterResolve: "openrouter/openai/gpt-5.3-codex",
+        fallback: "opencode/gpt"
       },
       "gpt-codex-mini": {
         displayName: "GPT Codex Mini",
         resolve: "opencode/gpt-5.1-codex-mini",
-        openRouterResolve: "openrouter/openai/gpt-5.1-codex-mini"
+        openRouterResolve: "openrouter/openai/gpt-5.1-codex-mini",
+        fallback: "opencode/gpt-mini"
       },
       "gemini-pro": {
         displayName: "Gemini Pro",
@@ -164,8 +218,8 @@ var providers = {
       },
       "kimi-k2": {
         displayName: "Kimi K2",
-        resolve: "opencode/kimi-k2.5",
-        openRouterResolve: "openrouter/moonshotai/kimi-k2.5"
+        resolve: "opencode/kimi-k2.6",
+        openRouterResolve: "openrouter/moonshotai/kimi-k2.6"
       },
       "gpt-5-nano": {
         displayName: "GPT Nano",
@@ -185,12 +239,6 @@ var providers = {
         resolve: "opencode/minimax-m2.5-free",
         envVars: [],
         isFree: true
-      },
-      "nemotron-3-super-free": {
-        displayName: "Nemotron 3 Super",
-        resolve: "opencode/nemotron-3-super-free",
-        envVars: [],
-        isFree: true
       }
     }
   }),
@@ -200,8 +248,8 @@ var providers = {
     models: {
       "claude-opus": {
         displayName: "Claude Opus",
-        resolve: "openrouter/anthropic/claude-opus-4.6",
-        openRouterResolve: "openrouter/anthropic/claude-opus-4.6",
+        resolve: "openrouter/anthropic/claude-opus-4.7",
+        openRouterResolve: "openrouter/anthropic/claude-opus-4.7",
         preferred: true
       },
       "claude-sonnet": {
@@ -214,15 +262,33 @@ var providers = {
         resolve: "openrouter/anthropic/claude-haiku-4.5",
         openRouterResolve: "openrouter/anthropic/claude-haiku-4.5"
       },
+      gpt: {
+        displayName: "GPT",
+        resolve: "openrouter/openai/gpt-5.5",
+        openRouterResolve: "openrouter/openai/gpt-5.5"
+      },
+      "gpt-pro": {
+        displayName: "GPT Pro",
+        resolve: "openrouter/openai/gpt-5.5-pro",
+        openRouterResolve: "openrouter/openai/gpt-5.5-pro"
+      },
+      "gpt-mini": {
+        displayName: "GPT Mini",
+        resolve: "openrouter/openai/gpt-5.4-mini",
+        openRouterResolve: "openrouter/openai/gpt-5.4-mini"
+      },
+      // legacy aliases — see openai provider for context.
       "gpt-codex": {
         displayName: "GPT Codex",
         resolve: "openrouter/openai/gpt-5.3-codex",
-        openRouterResolve: "openrouter/openai/gpt-5.3-codex"
+        openRouterResolve: "openrouter/openai/gpt-5.3-codex",
+        fallback: "openrouter/gpt"
       },
       "gpt-codex-mini": {
         displayName: "GPT Codex Mini",
         resolve: "openrouter/openai/gpt-5.1-codex-mini",
-        openRouterResolve: "openrouter/openai/gpt-5.1-codex-mini"
+        openRouterResolve: "openrouter/openai/gpt-5.1-codex-mini",
+        fallback: "openrouter/gpt-mini"
       },
       "o4-mini": {
         displayName: "O4 Mini",
@@ -244,15 +310,28 @@ var providers = {
         resolve: "openrouter/x-ai/grok-4",
         openRouterResolve: "openrouter/x-ai/grok-4"
       },
+      "deepseek-pro": {
+        displayName: "DeepSeek Pro",
+        resolve: "openrouter/deepseek/deepseek-v4-pro",
+        openRouterResolve: "openrouter/deepseek/deepseek-v4-pro"
+      },
+      "deepseek-flash": {
+        displayName: "DeepSeek Flash",
+        resolve: "openrouter/deepseek/deepseek-v4-flash",
+        openRouterResolve: "openrouter/deepseek/deepseek-v4-flash"
+      },
+      // legacy alias — deepseek retires this on 2026-07-24; transparently
+      // upgrade existing users to the v4 family via the fallback chain.
       "deepseek-chat": {
         displayName: "DeepSeek Chat",
         resolve: "openrouter/deepseek/deepseek-v3.2",
-        openRouterResolve: "openrouter/deepseek/deepseek-v3.2"
+        openRouterResolve: "openrouter/deepseek/deepseek-v3.2",
+        fallback: "openrouter/deepseek-flash"
       },
       "kimi-k2": {
         displayName: "Kimi K2",
-        resolve: "openrouter/moonshotai/kimi-k2.5",
-        openRouterResolve: "openrouter/moonshotai/kimi-k2.5"
+        resolve: "openrouter/moonshotai/kimi-k2.6",
+        openRouterResolve: "openrouter/moonshotai/kimi-k2.6"
       }
     }
   })
@@ -299,7 +378,7 @@ function resolveModelSlug(slug) {
   return modelAliases.find((a) => a.slug === slug)?.resolve;
 }
 var MAX_FALLBACK_DEPTH = 10;
-function resolveCliModel(slug) {
+function resolveDisplayAlias(slug) {
   let current = slug;
   const visited = /* @__PURE__ */ new Set();
   for (let i = 0; i < MAX_FALLBACK_DEPTH; i++) {
@@ -307,11 +386,17 @@ function resolveCliModel(slug) {
     visited.add(current);
     const alias = modelAliases.find((a) => a.slug === current);
     if (!alias) return void 0;
-    if (!alias.fallback) return alias.resolve;
+    if (!alias.fallback) return alias;
     current = alias.fallback;
   }
   return void 0;
 }
+function resolveCliModel(slug) {
+  return resolveDisplayAlias(slug)?.resolve;
+}
+function resolveOpenRouterModel(slug) {
+  return resolveDisplayAlias(slug)?.openRouterResolve;
+}
 
 // external.ts
 var pullfrogMcpName = "pullfrog";
@@ -326,6 +411,9 @@ function formatMcpToolRef(agentId, toolName) {
   }
 }
 
+// agents/reviewer.ts
+var REVIEWER_AGENT_NAME = "reviewfrog";
+
 // modes.ts
 var PR_SUMMARY_FORMAT = `### Default format
 
@@ -368,7 +456,7 @@ GitHub's markdown parser requires a blank line between ALL block-level elements.
 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. Compute anchors by running \`echo -n 'path/to/file.ts' | sha256sum\` via shell for each file. NEVER fabricate hex strings \u2014 run the actual command. If shell is unavailable, omit the #diff- anchor rather than guessing.
+- 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
@@ -397,9 +485,36 @@ function computeModes(agentId) {
    - 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**: delegate a read-only subagent to review your diff. the subagent must ONLY read files, grep, and search \u2014 no MCP tools, no writes, no shell commands, no side effects. provide it with the output of \`git diff\` and instruct it to look for bugs, logic errors, missing edge cases, and unintended changes. review its findings, address any valid points, and discard nitpicks or false positives. then:
-   - verify only intended changes are present, no debug artifacts or commented-out code remain, and no unrelated files were modified
-   - commit locally via shell (\`git add . && git commit -m "..."\`)
+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)
@@ -423,11 +538,12 @@ For simple, well-defined tasks, skip the plan phase and go straight to build.`
 
 3. For each comment:
    - understand the feedback
-   - make the code change using your native tools
-   - record what was done
+   - 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, and the changes are clean enough that a senior engineer would approve without hesitation
+   - 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:
@@ -438,28 +554,94 @@ For simple, well-defined tasks, skip the plan phase and go straight to build.`
 
 ${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 the PR via \`${t("checkout_pr")}\` \u2014 this returns PR metadata and a \`diffPath\`. Read the diff to identify the major areas of change.
-
-2. For each area of change:
-   - read the diff and trace data flow, check boundaries, and verify assumptions
-   - plan your investigation: identify the highest-risk areas (tricky state transitions, boundary crossings, assumption chains) and prioritize depth over breadth
-   - use \`${t("get_pull_request")}\` and other read-only GitHub tools for additional context
-   - if the PR removes features, deletes exports, renames identifiers, or changes architectural patterns, run a dedicated impact analysis: list what changed, then use grep across code, tests, docs (\`docs/\`, \`wiki/\`), comments, configs, and UI to find stale references
-   - report impact-analysis findings in the summary body, ordered by severity (runtime breakage > incorrect docs > stale comments)
-   - draft inline comments with NEW line numbers from the diff \u2014 every comment must be actionable (2-3 sentences max)
-   - use GitHub permalink format for code references
-   - for large or cross-cutting PRs that touch disparate subsystems, consider delegating read-only subagents to investigate areas in parallel. subagents must ONLY read files, grep, and search \u2014 no MCP tools, no writes, no shell commands, no side effects. collect their findings and use them to draft comments.
-
-3. Self-critique: review all drafted comments and drop any that are praise, style preferences, speculative/unverified claims, about pre-existing code unrelated to the PR, or not actionable.
-
-4. Submit \u2014 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.
+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.:
@@ -472,35 +654,63 @@ ${learningsStep(t, 6)}`
    - **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 the PR via \`${t("checkout_pr")}\` \u2014 this returns PR metadata, \`diffPath\` (full diff), and \`incrementalDiffPath\` (changes since last reviewed version, if available).
+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.
 
-2. 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.
+   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.
 
-3. 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.
+   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)
 
-4. For each area of the new changes:
-   - review the incremental diff while using the full diff for context
-   - check whether prior review feedback was addressed by the new commits
-   - trace data flow, check boundaries, verify assumptions, consider lifecycle, spot performance issues
-   - if the new commits remove, rename, or deprecate anything, run impact analysis with grep across code/tests/docs/comments/configs to find stale references and include those findings in the summary body
-   - never repeat prior feedback. only comment on genuinely new issues introduced by the new commits.
-   - draft inline comments with NEW line numbers from the full PR diff \u2014 every comment must be actionable (2-3 sentences max)
-   - for large or cross-cutting PRs, consider delegating read-only subagents for parallel investigation. subagents must ONLY read files, grep, and search \u2014 no MCP tools, no writes, no shell commands, no side effects. collect their findings and use them to draft comments.
+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.
 
-5. Self-critique: drop any comments that are praise, style preferences, speculative, about pre-existing code, or not actionable.
+   then check: which prior review comments were addressed by the new commits? track the addressed ones for step 6b.
 
-6. **Summarize**: build two distinct sections for the review body:
+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).
@@ -611,7 +821,7 @@ var modes = computeModes("opencode");
 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 formatModelLabel(slug) {
-  const alias = modelAliases.find((a) => a.slug === slug);
+  const alias = resolveDisplayAlias(slug);
   if (!alias) return `\`${slug}\``;
   return alias.isFree ? `\`${alias.displayName}\` (free)` : `\`${alias.displayName}\``;
 }
@@ -676,6 +886,8 @@ export {
   providers,
   pullfrogMcpName,
   resolveCliModel,
+  resolveDisplayAlias,
   resolveModelSlug,
+  resolveOpenRouterModel,
   stripExistingFooter
 };

package/dist/lifecycle.d.ts

@@ -1,2 +1,2 @@
 /** timeout for lifecycle hook scripts */
-export declare const LIFECYCLE_HOOK_TIMEOUT_MS = 120000;
+export declare const LIFECYCLE_HOOK_TIMEOUT_MS = 600000;