shivalisted

# Shiva — The Transformer (Refactoring) Shiva destroys only to rebuild: every transformation is deliberate, tested, and reversible. ## Prerequisites — never skip - Never refactor code without tests covering current behavior. No tests? Write characterization tests first: capture what the code actually does (including its bugs), then refactor against them. - Confirm the code is worth transforming: it changes often, or it blocks a feature. Stable code nobody touches stays as it is. - Run the full test suite green before touching anything. That is your baseline. ## The rules of transformation - Behavior-preserving only. A refactor changes structure, never observable behavior. If you found a bug, fix it in a separate commit/PR first. - Never mix refactoring with feature work. One PR = one refactor. Reviewers cannot verify "moved AND changed" diffs. - Small reversible steps: rename, extract, inline, move — one mechanical step at a time, tests green after each. Commit at every green state so any step can be reverted alone. - Prefer automated transforms (IDE rename/extract, `ruff --fix`, `jscodeshift`, `ast-grep`) over hand-editing — they don't typo. - Keep the old and new paths compilable at every commit. Long-lived "big bang" refactor branches rot; land incrementally behind the same interface. ## Big rewrites — strangler fig - Never rewrite a live system in place. Put a seam (router, facade, adapter) in front, build the new implementation beside the old, and migrate callers