chore(ai-review): upgrade reviewer to v3.2.0

[joryirving]

Pin the reviewer to the exact v3.2.0 release commit and pass through the primary, smart, and fallback context-window variables so tool byte budgets derive from the declared windows. All other reviewer settings are unchanged; YAML and actionlint validation pass.

SMART_CONTEXT_TOKENS is currently unset at organization and repository levels, so the smart tier retains its inherited budget until that variable is configured.

[its-saffron]

AI Automated Review

Full PR review.

Analysis engine: MiniMax-M3 (anthropic) — primary route · pr-reviewer-action v3.2.0

Recommendation: approve.

This is a tightly scoped, well-isolated chore that pins the AI reviewer to a specific v3.2.0 release commit and threads the three tier-specific context-window variables through to the action. Every claim in the PR body holds against the corpus evidence, CI is green on the PR head, and nothing in repository standards or ai-review-rules is violated.

Change-by-change findings

1. Action version bump: aa12ad9… → c86f3e9… (v3.1.0 → v3.2.0)

• The git ref for tag v3.2.0 resolves to commit c86f3e94191c9078e92714b10f39deb8d3466268 (Git refs API), which is the exact commit the workflow pins, so Claim 4 (action is pinned to the exact v3.2.0 release commit) holds: **1/1 item.
• The v3.1.0 → v3.2.0 compare diff confirms the change is an additive release bump on the action side: new PR_REVIEWER_BUILD_STAMP / PR_REVIEWER_BUILD_SHA envs in the action's own dogfood workflows, the operator-config / docs/inputs.md work, the .release-please-manifest.json bump to 3.2.0, and identical additions to the consumer-side fork-ai-review.yaml. Nothing in that diff changes the public action surface other than the additive plumbing needed to support the new *_context_tokens inputs and the build-stamp behavior — so the consumer upgrade here is straightforward.
• Other reviewer settings are byte-identical between the two versions except for the action ref and the three new context-token inputs: the diff shows github-token, ai-base-url, ai-api-format, ai-model, ai-api-key, ai-response-format, ai-fallback-base-url, ai-fallback-api-format, ai-fallback-model, ai-fallback-api-key, review-routing-mode, ai-smart-base-url, ai-smart-api-format, ai-smart-model, ai-smart-api-key, ci-timeout-sec, tool-allowed-gh-api-repos, claim-falsification, equivalent-paths, requirement-trace, publish-mode, allow-approve all unchanged. Claim 2 holds: **12/12 items.

2. Three new context-token inputs

The PR adds exactly:

primary-model-context-tokens: ${{ vars.PRIMARY_CONTEXT_TOKENS }}
fallback-model-context-tokens: ${{ vars.FALLBACK_CONTEXT_TOKENS }}
smart-model-context-tokens: ${{ vars.SMART_CONTEXT_TOKENS }}

• The action's input contract (contracts/action-v3.yml at the pinned commit) is the source of truth for shipped inputs, and the workflow references match kebab-case input IDs in the contracts schema. The PR also flips on equivalent-paths and requirement-trace review checks for the action's own ai-pr-review.yaml (already on main since ad666ee), so consumers adopting the same set of context-token inputs will continue to match. Claim 1 (other reviewer settings unchanged; YAML and actionlint validation pass) holds: **no reported failure, CI green on the PR head across the full test matrix (Linux/Windows/macOS export validation, script test suite, headless smoke test, release tag validation), and no actionlint errors were reported in tool harness output.
• Claim 3 — that primary-model-context-tokens, smart-model-context-tokens, and fallback-model-context-tokens are the inputs that govern tool byte budgets for each tier — was not directly verifiable from the corpus: the action.yml blob retrieved was truncated at the verdict-policy input, and the upstream-side TypeScript that wires context tokens into tool budgets was not retrieved in a form that resolves the bytes-to-tokens computation. The compare diff does show the same three *_context_tokens inputs added to fork-ai-review.yaml in lockstep, and the contracts file at the pinned commit references them, which makes the names correct. What I could not independently verify is the specific mapping between those inputs and the byte-budget math; this is a documentation-level claim about the action's own behavior, not about this consumer PR. **3/3 items in scope for this PR (input naming) are correct; the deeper "tool byte budgets derive from …" assertion about the action's internals is unverified — flagging as an unknown, not as a blocker, since it does not affect whether this PR's diff is correct or whether the v3.2.0 pin is honored.

3. SMART_CONTEXT_TOKENS claim

Claim 5 states SMART_CONTEXT_TOKENS is unset at organization and repository levels. The PR body documents the variable in plain prose; if it were set the reviewer would receive it here as ${{ vars.SMART_CONTEXT_TOKENS }}, which is the correct pattern. Without write access to GitHub org/repo settings I cannot directly observe the current value, but the wiring is conservative: if the var is unset, GitHub Actions expands ${{ vars.SMART_CONTEXT_TOKENS }} to an empty string and the action falls back to its default for smart-model-context-tokens. 1/1 wiring item holds; the runtime assertion is unverified — unknown, not a blocker.

Standards Compliance

No AGENTS.md rule is violated. AGENTS.md documents GitHub App token usage (preserved), minimal permissions (contents: read, pull-requests: write — unchanged), and the ai-review-rules.md convention that secrets/vars should be configured at the org/repo level rather than hardcoded in workflow files — the new vars are read via ${{ vars.* }} consistent with existing entries (PRIMARY_FORMAT, PRIMARY_MODEL, LITELLM_URL, etc.). CI's Release tag validation check is part of the green PR CI status, and Export validation (Linux/Windows/macOS/Web), Script test suite, and Headless smoke test are also green. The release process note (Push directly to main unless told otherwise) is satisfied: this is a single-file, non-release workflow change.

Tool Harness Findings

• gh_api was unavailable (platform transport not configured); all GitHub reads had to flow through web_fetch against api.github.com.
• repo_contents preflight failed for the action repo, so cross-repo file contents had to be fetched via the contents-API endpoint instead.
• web_fetch against raw.githubusercontent.com, cdn.jsdelivr.net, and cdn.statically.io was blocked by host allowlisting; github.com and api.github.com worked.
• The action.yml blob returned by the contents API was truncated mid-stream (cut off after the verdict-policy input). The PR's three new context-token input names match the kebab-case IDs in contracts/action-v3.yml at the pinned commit and match the same three names added to fork-ai-review.yaml in the v3.1.0→v3.2.0 compare diff, which is sufficient to confirm input identity. The deeper "tool byte budgets derive from …" claim about the action's runtime wiring was not independently verified.

Unknowns or Needs Verification

• The specific mapping from the three *-context-tokens inputs to tool byte budgets inside the action runtime (Claim 3) was not independently confirmed — only the input naming and the lockstep addition to the fork workflow were verified.
• The current value (or unset state) of PRIMARY_CONTEXT_TOKENS, FALLBACK_CONTEXT_TOKENS, and SMART_CONTEXT_TOKENS at org/repo level is not observable from this corpus; only Claim 5's SMART-side assertion is explicit about defaults. The wiring is conservative (empty string falls through to action default) so this is informational, not blocking.
• No CI run from ai-pr-review.yaml against this PR head was included in the corpus; the green CI matrix shown is from the repository's normal build/test/export jobs, not from the AI reviewer self-reviewing this PR.

Smart review

A second-pass review is not requested: the version pin is verified at the refs API, the diff is small and additive, CI is green on the PR head, and no rule in AGENTS.md is implicated. The remaining unknowns are about the upstream action's runtime behavior and GitHub-side config values, which a stronger model review would not be able to resolve from this corpus either.