## Frozen classification (hard rule, never relaxed)

This skill **never** edits a finding's `severity`, `class`, or `route`, and
never moves a finding out of fix-now. Those fields belong to `review-change` /
`audit-pr`, the skills that produced the verdict — reopening them here would
let a fix turn into a reclassification. If, while investigating, the finding
genuinely looks wrong (not reproducible, already fixed elsewhere, or the
axis/severity is mistaken), that is **evidence for a dispute**, not a
license to edit the row: mark it `DISPUTED` with the evidence and stop for a
user decision — the row's `severity`/`class`/`route` stay exactly as written.

## Definition of fixed (checklist — every box, every finding)

A finding is `FOLDED` only when **all** of these hold:

```
✓ A root-cause diff exists — the actual defect is fixed, not worked around
✓ The gate is green (type-check + tests + build actually RUN, exit codes
  pasted — never assumed)
✓ If the finding was behavioral (a bug, not a style/debt nit): a test or
  check was added/updated that fails without the fix and passes with it
✓ The ledger row is ticked `folded: yes`, in the same commit as the fix
✓ The commit is made AND pushed — an unpushed fix does not exist for CI, the
  reviewer, or the merge gate (skip the push only if the branch has no PR yet
  and the unit's own workflow says push happens later, at the PR step)
```

## Forbidden (never — even if it "would resolve the finding")

```
✗ Adding a known-issues.md / backlog entry instead of fixing the code
✗ A decisions.md tradeoff note that accepts the defect as-is
✗ Deleting, skipping (.skip, .only elsewhere), or loosening a test to make it pass
✗ Editing an existing test's expectation to match behaviour — a setup repair
  may only keep assertions at least as strong and never touch expectations
✗ eslint-disable / @ts-ignore / equivalent suppression AS the fix
✗ A TODO/FIXME stub left in place of the actual fix
✗ Ticking `folded: yes` without a reviewer-mappable diff behind it
✗ Fixing anything NOT on the ledger (or not in the explicit finding-ID
  scope this turn was given) — record an independent proposal for explicit
  user triage, never bundle it silently or create an issue
```

Something forbidden looks like the only option → stop, do not apply it, and
mark the finding `DISPUTED` or `BLOCKED` with the reason instead.

Never edit an existing test's expectation to match behaviour: a setup repair may
only keep assertions at least as strong and never touch expectations; the
test-immutability contract (`verification-contract`) owns the sole amendment
path.

## Reproducer handoff (materialize, never re-derive)

Before repairing a **behavioral** finding, read the row's `finding-mark@1`
`recheck` cell (method + reproducer, written by `review-change` at verification
time) and materialize it as the regression check — the method as written (red
test first, reproducible command output, or direct read). The fold runner
**never invents or re-derives** the reproducer; it consumes the cell as the
allowed materialization.

- A `recheck` cell that cannot be materialized as a runnable check yields
  `BLOCKED <missing input>` and names the missing input.
- Never substitute a weaker re-derived check for the recorded reproducer.