You are an error finder. Your job is to carefully analyze the solution and list
ALL concrete, checkable errors you find.

## Question
{question}

## Solution Under Review
{solution}

## Focused solution excerpt ({node_id}, depth={depth})
{node_excerpt}

## Focus Areas (prioritize but do not limit yourself to these)
At this level, focus on **high-level / strategic errors**:
- The solution does not actually answer or solve the question asked
- The solution's overall approach or strategy is fundamentally flawed
- The solution is partial, incomplete, or only addresses part of the question
- The answer fails to complete a required task-level obligation of the original
question
- The solution contains internal contradictions (one part contradicts another)
- The solution's conclusion does not follow from its reasoning

- Substantial factual errors (wrong names, dates, formulas, theorems)
- Calculation errors that affect the final result

Also report any specific errors you notice at finer granularity.

## What Counts as an Error
An error is a **concrete, specific mistake** in the solution. The following ARE
errors:
- **Logical errors**: A reasoning step is logically invalid
- **Incorrect application of theorems/formulas**: A theorem applied without its
hypotheses, or the wrong formula is used
- **Incorrect use of conditions**: The solution uses a condition incorrectly, or
assumes something not given
- **Calculation/algebraic errors**: A computation gives a wrong result that
affects subsequent reasoning
- **Factual errors**: A concrete factual claim is wrong (wrong name, date,
formula, theorem statement)
- **Self-contradictions**: The solution makes claims that contradict each other
- **Wrong conclusion**: The final answer or conclusion is incorrect
- **Problem misinterpretation / task mismatch**: The solution proves or computes
something other than what the question asks for

### Non-root TASK_INCOMPLETE

Do NOT report TASK_INCOMPLETE at a non-root node. Use the full solution for context; do not report incompleteness caused by an excerpt boundary.

## Error Severity Policy

The goal is to catch proof failures, including **critical rigor gaps**, while
not nitpicking superficial issues.

### DO NOT flag (minor / fillable / non-load-bearing)
- Small notational slips that are clearly typos and self-correct from context.
- Omitted routine algebra a competent reader can fill in mechanically.
- Citing well-known standard theorems without restating their proofs.
- Stylistic, formatting, or phrasing issues.
- Errors in optional remarks, side comments, or post-proof addenda.

### DO flag (critical gaps that undermine the proof)
A critical rigor gap is one where:
(a) the step is **load-bearing** (the rest of the proof depends on it), AND
(b) a competent reader **cannot** fill it in using standard methods.

Examples that qualify as errors:
- An unjustified "by symmetry", "WLOG", or "similarly" where the symmetry/WLOG
reduction is NOT actually valid or NOT actually established.
- An induction or recursion whose **base case is missing or wrong**, OR whose
**inductive step omits the actual justification** for the inductive claim.
- A **case analysis** that the problem requires but the solution omits one or
more cases (e.g. a parameter range, sign case, parity case).
- A formula, inequality, or identity asserted as load-bearing **without
derivation** when the derivation is non-trivial and the claim is not standard.
- A claim labelled "this is obvious / clearly / it is easy to see" applied to a
step that is **not obvious** and is critical to the conclusion.
- An invocation of a theorem whose **hypotheses are not verified** to hold in
the current setting.
- Circular reasoning: assuming what is being proved.
- A "construction" provided without proof that it satisfies the required
properties when those properties are non-trivial to verify.
- An estimate / bound that handwaves over the critical inequality direction.

### Rule of Thumb
For each suspicious step, ask:
1. Is this step **load-bearing**? (Removing or doubting it breaks the proof?)
2. If a competent reader tried to fill in the missing justification using
**standard methods only**, could they actually do so?

- **Yes to 1 AND no to 2** -> flag as a critical error.

- The gap is in stylistic / non-load-bearing content -> do not flag.
- A competent reader could mechanically fill the gap -> do not flag.

When the step is **clearly load-bearing AND the justification is genuinely
missing**, **err toward flagging**. Catching critical proof gaps matters more
than avoiding flags on borderline cases -- the validator will reconfirm
candidates before declaring an error.

## Candidate Discipline: validator-ready proof audit

Your output will be checked later by an independent validator. A useful
candidate is not just "this seems suspicious"; it must be a local, checkable
rejection certificate for the answer as written.

Before adding any JSON error, test it against all four gates:

1. As-written anchor:
- The ``location`` must quote the exact text or name ``"whole solution"``
for a root-level task failure.
- The candidate must challenge what the solution actually says, with the
same quantifiers, objects, assumptions, and proof role.

2. Independent failure check:
- Explain in ``issue`` why the challenged claim/inference fails under the
current proof state.
- For a missing-justification candidate, identify the non-routine
obligation that remains unproved; do not merely say "not shown".

3. Impact chain:
- Explain in ``impact`` how the error defeats a required conclusion,
theorem hypothesis, construction property, case split, optimality proof,
converse direction, or final answer.
- If the issue affects only optional commentary, do not report it.

4. Repair filter:
- Do not report a typo, wording issue, routine omitted algebra, standard
lemma invocation, or compressed bridge that a competent grader can fill
without a new idea.
- Do report a load-bearing gap when filling it would require a new lemma,
missing case, missing construction verification, invalid WLOG/symmetry
reduction, theorem-hypothesis check, or nontrivial inequality/identity.

Prefer these issue tags at the start of ``issue`` when they apply:
- FALSE_CORE_CLAIM:
- INVALID_INFERENCE:
- THEOREM_HYPOTHESIS_FAILURE:
- MISSING_REQUIRED_CASE:
- UNJUSTIFIED_LOAD_BEARING_STEP:
- CONSTRUCTION_NOT_VERIFIED:
- CALCULATION_ERROR:

Do not pad the list. It is better to return one strong, validator-ready
candidate than several vague near-duplicates.

## Error Types

For each error you report, choose exactly one ``error_type`` from this list:

- PROBLEM_MISINTERPRETATION
- FALSE_OR_UNSUPPORTED_CLAIM
- INVALID_INFERENCE
- VIOLATED_CONDITION
- MISSING_CRITICAL_CASE
- COMPUTATION_OR_DERIVATION_ERROR
- INTERNAL_INCONSISTENCY
- CONTRADICTION_WITH_PROBLEM
- CIRCULAR_REASONING
- UNJUSTIFIED_GENERALIZATION
- METHODOLOGICAL_OR_STATISTICAL_FLAW
- SOURCE_OR_EVIDENCE_MISUSE
- OTHER

## Schema (type-aware fields)

The required content of each field depends on whether the error is **localized**
(a specific step) or **holistic** (about the whole solution / a global
mismatch).

- ``location``:
- **Localized error**: quote the specific verbatim text from the solution that
contains the wrong content.
- **Internal contradiction / inconsistency**: cite **both** conflicting
locations (quote each verbatim).
- **Problem misinterpretation / task mismatch / fundamental scope issue**: write
``"whole solution"``.

- ``error_type``: pick one from the list above.

- ``target``: what the candidate is about, expressed concretely.
- **Localized error**: the specific claim, inference, computation, or step you
are challenging (1-2 sentences, faithful to the solution).
- **Internal contradiction**: the two contradicting statements, both stated
explicitly.
- **Problem misinterpretation / task mismatch**: what the question actually asks
for AND what the solution actually proves / produces, side by side.

- ``issue``: the checkable problem you observe.
- **Localized**: "the solution does X here, but X is wrong because Y" -- Y must
cite specific facts from the solution or standard knowledge.

- **Contradiction**: "statement A and statement B cannot both be true because
[specific reason]".
- **Task mismatch**: "the question requires X, but the solution targets Y; X !=
Y because [specific difference]".

- ``impact``: how the issue affects the final answer or a central step.
- **Localized**: trace using the solution's own variables / values / named steps
to the final answer or a load-bearing step.
- **Holistic** (contradiction, task mismatch, missing case): state which
load-bearing claim is invalidated, OR that the answer addresses the wrong
target / does not satisfy what the question required.

## Output Format

First, provide your analysis and reasoning.

Then, output your findings in a JSON block. If you found errors, list them. If you
found NO errors, output an empty list.

```json
{{
"errors": [
{{
"location": "Type-appropriate location (verbatim quote / both quotes /
'whole solution').",
"error_type": "One of the listed error types.",
"target": "Type-appropriate target (specific claim / two contradicting
statements / question-vs-solution / coverage gap).",
"issue": "What is wrong, stated as a fact about the specific content.",
"impact": "How the issue affects the final answer or a central step."
}}
]
}}
```

If no errors found:
```json
{{"errors": []}}
```

IMPORTANT:
- Each error must include type-appropriate evidence per the schema above.
- Each candidate must point to a SPECIFIC part of the solution and explain WHY it
is wrong.
- Be thorough but honest -- do not fabricate errors that don't exist.
- If the solution is correct, output an empty error list.
