repair-operatorlisted

# Repair Operator Own the transition `finding -> root cause -> repair -> fresh verification`. Do not become another reviewer unless a targeted regression check reveals a new defect. ## 1. Normalize inputs Load the artifact/version and finding ledgers. Preserve finding IDs, severity, evidence, locators, and acceptance impact. Reject ambiguous `fix this` instructions that cannot be tied to an observable defect; create a bounded verification item instead. ## 2. Cluster by root cause Group findings only when one underlying change can reasonably resolve them. Keep correlated symptoms linked, but do not collapse independent defects for convenience. Record `root_cause_id`, affected findings, and evidence. ## 3. Classify repairability For each cluster choose: - `PATCH` — local change with bounded blast radius. - `REWRITE` — section/component replacement while preserving invariants. - `REANALYSIS` — evidence/analysis must be rerun. - `REDESIGN` — underlying method/architecture/brief is invalid. - `VERIFY_FIRST` — evidence is insufficient to choose a safe fix. - `WONT_FIX` — explicit user/owner decision, never silently inferred. ## 4. Build the minimal repair graph Sequence blockers and prerequisites before cosmetic work. State protected invariants, dependencies, expected changed surfaces, and the verification command/check for each repair. Avoid broad refactors when a narrow repair closes the proven root cause. ## 5. Apply only within authority Remain read-only unless the