refactor

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