refactorlisted

# Refactor Restructure existing code without changing observable behavior. The defining constraint: **no behavior delta** — all existing tests must still pass after the refactor. ## 1. Define the refactor Confirm with the user: - **What** is being refactored (files, modules, or patterns) - **Why** (readability, performance, removing duplication, preparing for a future change) - **What must not change** (public API surface, database behavior, external contracts) Read `docs/CONVENTIONS.md` if it exists. Check `memory/**/*.md` for any decisions about the code being changed. ## 2. git-engineer — branch setup Always first. Confirm the working branch. If on `main` or `master`, ask the user to name the refactor branch before proceeding. ## 3. tech-lead — impact analysis Always invoke tech-lead before any engineer for a refactor. Pass: - The refactor scope and goal - The "must not change" constraints from step 1 The tech-lead will: - Identify all files and call sites affected by the change - Flag whether any public API surface, interface, or contract is at risk - Determine whether the change is safe to parallelize or must be sequential - Produce a sequenced plan Present the plan to the user. If the tech-lead flags the refactor as high-blast-radius or pattern-changing, or if the plan introduces a new pattern (even one extracted from existing code), recommend running devils-advocate on the plan before proceeding. ## 4. devils-advocate (conditional) Invoke if tech-lead flags