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. If `memory/architecture/repo-map.md` exists, use it to scope the blast radius quickly — it maps which directories own what. Verify its `Verified-at-commit` against HEAD; if the structure has drifted, recommend `/repo-map refresh` before the impact analysis in step 3. ## 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 fl