feat(review): per-batch dimension routing — assemble the review system prompt from only the relevant dimensions [v0.7]

[devops-thiago]

Problem Statement

Every review call carries all 10 review dimensions of PrReviewPrompts.SYSTEM (~600 lines) regardless of what the batch contains: a docs-plus-tests batch still pays for the IaC/config-correctness rules, the pagination rules, the injection-sink severity floor, and the config-key documentation dimension. On the multi-call lane this cost is multiplied by N batches.

The gating pattern already exists in embryo: MOCK_FIDELITY_REQUEST is injected only when the PR changes test files, and HEURISTIC_FAILURE_MODES_REQUEST is decided per batch in FindingPipeline.heuristicFailureModesFor (FindingPipeline.java:1066) precisely because the assembler can't see batch contents (#486 P3). This issue generalizes that pattern to the core dimensions.

Proposed Solution

• Split PrReviewPrompts.SYSTEM into a stable core (identity, untrusted-data rules, output contract, severity/confidence calibration, self-check) plus composable dimension blocks (functional correctness, security, regressions, comment-contradicts-code, quality/complexity, pagination, config/IaC, mock fidelity, producer→consumer, config-key docs).
• Per batch, include only applicable blocks, keyed off cheap deterministic signals from the batch's files (path/category globs, diff content probes like the existing regex probe for heuristic code): e.g. config/IaC + config-key-docs dimensions only when config/IaC files are present; mock fidelity only for test files; pagination only when API/query code appears. Correctness/security/regressions stay always-on.
• Keep the core prefix byte-stable and block ordering deterministic so OpenAI-compatible prompt caching (DeepSeek context caching) still gets prefix hits across batches within a review.
• DiffBudgetPlanner overhead estimation becomes per-batch (today it concatenates the full SYSTEM once, DiffBudgetPlanner.java:305-314) — slimmer prompts also mean more diff fits per batch, i.e. fewer batches for the same PR.
• FindingVerifierPrompts has per-dimension carve-outs mirroring the generator's dimensions; route those the same way so the verifier prompt shrinks in lockstep.

Risk & guardrails

This is the riskiest prompt change in the roadmap — recall must not regress:

• PrReviewPromptsContentTest refactors from pinning one monolith to pinning each block individually, so guidance can't be silently dropped in the split.
• Expand the eval corpus (src/test/resources/evalcorpus, currently 12 cases) with at least one must-find case per routed dimension before flipping routing on, so a mis-gated dimension shows up as a red eval, not a silent miss.
• Config-gate the routing (REVIEW_DIMENSION_ROUTING_ENABLED, default off initially) so the monolithic prompt remains a fallback during bake-in.

Related: #63 proposes parallel specialized agents per concern; this issue is the non-agentic subset — same "dedicated prompt per concern" benefit, deterministic orchestration, no tool-calling dependency.

Touchpoints

review/ai/PrReviewPrompts.java, review/ReviewPromptAssembler.java, review/FindingPipeline.java (per-batch assembly), review/DiffBudgetPlanner.java, review/ai/FindingVerifierPrompts.java, review/ai/PrReviewPromptsContentTest.java, eval corpus.

Acceptance criteria

• Eval corpus green including new per-dimension cases; no pinned guidance lost.
• Measured input-token reduction per batch on mixed-content PRs.
• Prompt-cache hit behavior verified (stable shared prefix across batches).

Alternatives Considered

• One call per dimension (full sharding) — maximum recall but ~10× calls; feat(review): specialized multi-agent review with parallel agentic workflow #63 territory. Routing gets most of the token savings at zero extra calls.