refactorlisted

# Refactor Execute a structural method inside an authorised `implement` run. This skill inherits exact paths, non-goals and repair limits; it cannot widen scope, accept the change, release it or turn nearby cleanup into work. ## Entry evidence Before editing, record: - the named cost/risk to remove and the observable behaviours that must not change; - public API, schema, protocol, data, ordering, error and performance invariants; - a green baseline plus characterisation, differential, replay, property or compatibility checks selected by risk; - the dependency cone: callers, exports, registration/configuration, generated artifacts, persistence and mixed-version boundaries; - canonical ownership, duplicate/parallel paths, rollback seam and a move/deletion manifest. Use SOLID and related principles as probes, not success metrics: improve cohesion and single ownership; preserve substitutability and caller contracts; segregate interfaces only where clients carry unused coupling; invert volatile dependencies only when the new seam hides real complexity. Prefer simple, explicit state and information hiding over speculative abstraction, pattern count, DRY-by-text or acronym compliance. If the desired structure or behaviour is undecided, route to `scope`. If a failure's cause is unknown, use `diagnose`. Changed behaviour is a separate TDD slice, never hidden in the refactor. ## Method 1. Establish a seam while green. Do not start by deleting the old path. 2. Move one i