dev-refactor

1# Refactor
2 
3Use for structural refactors. Use `dev-simplify` for local readability, dead code, or small logic cleanup.
4 
5## Rules
6 
7- Preserve behavior and public contracts unless changes are explicit.
8- Classify first: small = local/no public movement; medium = multi-file/extraction/boundary/export touch; large = package/cross-package/staged migration/broad consumers.
9- For medium/large refactors, write a brief before editing: evidence, pressure, remaining delta, do/defer/avoid ranking, non-goals, contracts, target shape, validation, compatibility.
10- Do not propose target trees without current-code evidence: tree, file size/mixed concerns, imports/exports, consumers, validation commands.
11- Separate moves/renames from logic changes and design/API behavior questions.
12- Prefer existing conventions, provider locality, and the smallest structure that solves observed pressure.
13- Subtract before adding: remove dead wrappers, redundant validators, stale exports, and unused paths before introducing new structure.
14- Avoid taste refactors, premature abstractions, and thin one-file directories unless staged or conventional.
15- Validate with fresh command output.
16 
17## Workflow
18 
191. Discover stack, configs, entry points, exact validation commands, and prior decisions when available.
202. Map contracts: exports, APIs, routes, CLI, config, schemas, events, files, docs, examples, consumers.
21…