grace-refactorlisted

Refactor a GRACE project without letting architecture or verification drift. ## When to Use - rename a module, file, symbol, or path - split one module into multiple modules - merge tightly coupled modules - extract helpers or adapters into a new module - move code across layers while preserving behavior - tighten an interface or dependency surface with explicit approval Do not use this skill for greenfield implementation. Use `/grace-plan`, `/build-loop`, or `/build-loop` for new work. ## Prerequisites - `docs/development-plan.xml` must exist - `docs/knowledge-graph.xml` must exist - `docs/verification-plan.xml` should exist - if the refactor introduces new modules, removes modules, or changes contract behavior, stop and get explicit user approval before editing code - if `docs/operational-packets.xml` exists, use its canonical packet and delta shapes ## Core Principle A GRACE refactor is not just a code move. It is an atomic migration across: - source files - test files - semantic markup - `docs/development-plan.xml` - `docs/knowledge-graph.xml` - `docs/verification-plan.xml` The refactor is not done until all six agree again. ## Process ### Step 1: Classify the Refactor Identify the exact refactor type: - `rename` - `move` - `split` - `merge` - `extract` - `interface-tighten` - `path-only` For the requested change, capture: - source module IDs and file paths - target module IDs and file paths - behavior that must remain invariant - approved contract changes, if a