Skill: Refactoring Validation
Purpose
Define the observable contract and the smallest credible evidence needed to prove that structural edits preserved existing frontend behavior.
Procedure
- Record the relevant behavior contract before substantial edits.
- Classify safety-net coverage as A, B, or C.
- Run and record the pre-change baseline.
- Match verification to the current refactoring risk and affected boundary.
- After every structural step, run the narrowest sufficient check immediately.
- If a newly introduced failure appears, revert that step before broader repair.
- At the end, run the broad gates justified by the affected surface.
- Assign PASS, PARTIAL, or NOT PROVEN from evidence, not optimism.
Pure structural work uses GREEN → REFACTOR → GREEN.
Safety-Net Levels
| Level | Evidence | Execution guidance |
|---|---|---|
| A — Strong | Existing tests cover relevant behavior | Use tests as the primary safety net |
| B — Partial | Important behavior is only partly covered | Add focused characterization of current behavior before risky steps |
| C — None | No useful automated behavior coverage | Do not auto-install a framework; keep CAUTION/DANGER plan-only unless a minimal safety net is authorized |
Frontend Contract Checklist
Check relevant items, not every item mechanically:
- function inputs, outputs, exceptions, and error mapping;
- DOM structure that consumers depend on, visible states, focus, keyboard flow, and accessibility semantics;
- props, emits, slots, hook/composable return values, and event ordering;
- requests, payloads, cancellation, retries, cache keys, and loading/error transitions;
- store state, persistence, object identity, memoization, refs/reactivity, and lifecycle timing;
- routes, URLs, guards, package exports, serialized fields, and backend-facing DTOs.
References
- Load behavior-preservation.md for contract construction and proof levels.
- Load refactoring-test-checklist.md for targeted verification by frontend risk.
Constraints
- Passing unrelated tests does not prove preservation.
- A green test written only after the change is weaker evidence than a pre-change baseline or characterization test.
- Do not rewrite expected values simply because the refactor changed behavior.
- Do not hide missing proof behind a PASS label.
- Do not install a new test framework without explicit authorization.
Expected Output
A behavior-preservation record containing baseline status, safety-net level, per-step checks, final validation, unresolved coverage gaps, and a PASS/PARTIAL/NOT PROVEN verdict.