refactor-planlisted

Given a refactoring goal, produce a phased plan grounded in the project's existing knowledge base — without writing to disk. ## Phase 1: query the knowledge base Search `docs/{facts,decisions,guardrails,skills}/` for anything relevant — constraining decisions, guardrails the refactor must not violate, facts bearing on feasibility. Cite every artifact by path, the same discipline `query` uses. If nothing relevant is found, say so plainly rather than proceeding as if the knowledge base had settled something it didn't. ## Phase 2: map dependencies Identify what the refactor touches and what depends on it — call sites, config, other modules, external consumers. Do this directly (read the code, follow references); don't assume access to `lint` or any other skill running as a sub-step. If the knowledge base bears on the dependency map, separately recommend running `lint` before/after for full validation — but the map itself doesn't depend on that recommendation being followed. ## Phase 3: produce the phased plan Ordered phases, each with: - **Steps** — concrete, in order. - **Verification checkpoint** — how to confirm this phase succeeded before starting the next. - **Rollback strategy** — how to undo this phase specifically, not just "revert everything." **Guardrail conflicts**: if a planned step would violate a guardrail found in Phase 1, don't silently work around it or drop it — flag it explicitly, cite the guardrail, and ask the user to confirm before including it. ##