This is a review task. Write your review to:
  {report_path}

Your prompt may include these context sections: `## Specification`, optional `## Review scope:` or `## Resolution review ask:`, either `## Original plan context (out of scope except for the review scope):`, `## Original plan:`, or `## Original request:`, implementation diff context or `## Resolution Delta Context`, and improve-lineage context.
The provided diff is authoritative - do not use git commands to reconstruct, re-derive, or expand it. You may read unchanged source files when surrounding context is needed to judge correctness (for example, checking call-sites, invariants, or pre-hunk class/function behavior).

Project-specific guidance:
- Start with a repo-rules/learnings pass: compare the diff and behavior against AGENTS.md, REVIEW.md, project docs, and `.gza/learnings.md`; call out violations or regressions explicitly.
- Review current code, diff, and scope only.
- Do not run or evaluate `verify_command`; verification is handled elsewhere.
- Do not create blockers because verification failed, timed out, was skipped, or was unavailable.
- If code has a test-quality issue, cite the concrete code/test issue directly rather than runner verify status.
- Keep this review stack-agnostic. If project verification instructions are missing, state that explicitly in assumptions/risks.
- Severity shorthand: `BLOCKER` means merge-blocking; `FOLLOWUP` means non-gating but task-worthy; `NIT` is omitted from canonical output.

Output format contract (use this exact section order and exact headings):
1. ## Summary
2. ## Blockers
3. ## Follow-Ups
4. ## Questions / Assumptions
5. ## Verdict

Do not rename, omit, or reorder these sections.

Section requirements:
- ## Summary
  - Provide 3-5 bullets summarizing the review.
  - Then answer this checklist with exactly 6 bullets in `Yes/No - ...` form and one short evidence clause each:
    - Did I check the diff against AGENTS.md and `.gza/learnings.md` and flag any violations/regressions?
    - Did I check for silent broad-exception fallbacks that mask errors while changing user/agent-visible state?
    - Did I check for misleading output (contradictory UI/prompt/context signals)?
    - Was a `## Review scope:` section provided, and if so did I grade ask-adherence against that scope while treating sibling slices as non-blocking unless they break an explicit contract? Otherwise, was an `## Original plan:` or `## Original request:` section provided, and did I verify ask-adherence against it while calling out intentional deviations? If neither was provided, did I state "No plan or request provided."?
    - Did I require targeted regression tests that match each failure mode (not generic "add tests")?
    - If config, CLI, or operator-facing behavior changed, did I verify docs/help/release-note impact?
- ## Blockers
  - If there are no blocking issues, write exactly: None.
  - Otherwise list blockers ordered by severity with headings:
    - ### B1
    - ### B2
    - ...
  - Each blocker item must include these labeled fields:
    - Evidence:
    - Open-state citation:
    - Impact:
    - Required fix:
    - Required tests: (name targeted regression coverage tied to the failure mode; avoid generic test asks)
  - Class-of-issue enumeration:
    - When one blocker is an instance of a repeated code-surface pattern (lookup table, classifier, dispatcher, schema/field mapping, multi-field validator, or parallel per-field/per-type handling), audit for analogous gaps before writing the blocker. The audit boundary is the affected file plus any other files in the same module (the same depth-3 path under `src/`) that were touched by the diff, plus any obvious same-module sibling of the affected file.
    - Report all still-open gaps for that same class in one blocker, with every affected `path:line` or `path:start-end` citation included in `Open-state citation:` regardless of file, and a `Required fix:` that closes the whole class.
    - Do not create one blocker per field, branch, case, table row, or file unless the required fixes are materially different.
    - Do not expand the audit beyond the same module, and do not expand isolated one-off defects - this rule applies only after you have found a repeated-pattern blocker shape.
- ## Follow-Ups
  - If there are no non-blocking follow-ups, write exactly: None.
  - Otherwise list follow-ups with headings:
    - ### F1
    - ### F2
    - ...
  - Each follow-up item must include:
    - Evidence:
    - Impact:
    - Recommended follow-up:
    - Recommended tests:
- ## Questions / Assumptions
  - If there are none, write exactly: None.
  - Otherwise provide bullets.
- ## Verdict
  - Include a brief rationale.
  - Final line must be exactly one of:
    - Verdict: APPROVED
    - Verdict: APPROVED_WITH_FOLLOWUPS
    - Verdict: CHANGES_REQUESTED
    - Verdict: NEEDS_DISCUSSION

Severity discipline:
- Use exactly three severity tiers conceptually: BLOCKER, FOLLOWUP, NIT.
- BLOCKER findings go in `## Blockers` and are the only gating findings.
- FOLLOWUP findings go in `## Follow-Ups` and are actionable but non-gating.
- Omit NIT findings from the canonical output entirely (do not add a nits section).
- Do not add a per-finding `Severity:` line; the `## Blockers` and `## Follow-Ups` sections are the severity field.
- Derive the final verdict from the findings:
  - no blockers and no follow-ups -> `APPROVED`
  - no blockers and one or more follow-ups -> `APPROVED_WITH_FOLLOWUPS`
  - one or more blockers -> `CHANGES_REQUESTED`
  - cannot classify safely -> `NEEDS_DISCUSSION`

Blocking discipline:
- Request changes only for concrete, actionable blockers.
- Reserve BLOCKER for: correctness defects, behavior regressions, repository/rules violations, missing observability for user/agent-visible fallbacks, and misleading output/contradictory signals.
- Treat unexplained deviations from the provided review scope, plan, or request as BLOCKER.
- If `## Review scope:` is present, grade ask-adherence against that section only. Use any original plan context section only to understand boundaries and integration contracts.
- If `## Resolution review ask:` / `## Resolution Delta Context` are present, review only the rebase-introduced conflict-resolution delta and its provenance. Do not widen the review into a whole-implementation regrade.
- Do not raise blockers solely because deferred sibling slices from the original plan are not implemented; only raise blockers when in-scope work is missing/broken or the diff violates an explicit integration contract described in the review scope or plan context.
- Treat silent broad-exception fallbacks as BLOCKER when they can alter user/agent-visible state without clear warning/error surfacing.
- Treat misleading output (UI/prompt/context contradictions) as BLOCKER when it can cause incorrect operator or agent decisions.
- If config/CLI/operator-facing behavior changed, missing or incorrect docs/help/release-note updates are BLOCKER when they can mislead operators.
- Use FOLLOWUP for actionable low-risk debt that should be tracked but should not block merge.
- For each blocker, give a clear closure condition so an improve task can resolve all blockers in one pass.
- For class-of-issue blockers, the closure condition must cover every enumerated instance across all cited paths, not just the first example.
- Every BLOCKER must be falsifiable: `Evidence:` and `Open-state citation:` must show the current still-open state, and `Required fix:` must describe the concrete change needed to close it.
- Do not write a `BLOCKER` unless you can cite the current code or current diff proving the issue is still open.
- Prior review text, improve lineage, or task history are not sufficient evidence for a blocker.
- Improve-lineage context may justify a narrow current-source anti-regression check for repeated blocker shapes the latest improve was expected to close, but it is only a pointer to inspect the current code/diff. It is not independent blocker evidence and must not substitute for current proof on this diff.
- `Open-state citation:` must contain one or more current-source references in `path:line` or `path:start-end` form; backticked citations and comma-separated multiple citations are allowed.
- Borderline cases must include a one-sentence rubric justification in `Impact:`, `Required fix:`, or `Recommended follow-up:` explaining why the item is a `BLOCKER` or a `FOLLOWUP`.
- Calibration examples:
  - A broad exception that can mask visible state or swallow a user/agent-visible failure is a `BLOCKER`.
  - An adjacent-path coverage sweep that would strengthen confidence without proving the current slice unsafe is a `FOLLOWUP`.

Historical review files may use older formats; keep this output contract for all new reviews.
