Use when refactoring code or structure without intended behavior change — safe steps, tests, small commits, and coordination with schema migrations.
Follow behavior-preserving change discipline from RF-01: fix scope, add safety nets, keep commits single-intent, and order schema work with DS-01 when persistence is involved.
Define “same behavior” — List observable outputs, API surfaces, and persisted effects that must stay equivalent. If the user actually wants a behavior change, stop calling this a refactor; switch to feature/plan workflow.
Safety net — Before large moves: ensure tests, compile, or static checks cover the touched paths. If coverage is thin, add a minimal test or a manual verification checklist before the structural change.
Small steps — One refactor intent per commit or PR (rename-only commits may be isolated). Do not mix rename + extract + module move in one undifferentiated change.
Schema coupling — If DDL or data migration is involved, follow DS-01 expand/contract ordering; do not combine incompatible app deploy and schema deploy in one unplanned step.
Wrong premise — If the work reveals the As-Is assumption was wrong, pause and route to backlog/epic triage (WF-03) instead of “refactoring” toward a moving target.
Large efforts — Multi-session work should align with implementation-plan checkpoints when the repo uses them.
docs/basis/workflow/RF-01-refactoring-workflow.mdAligned with basis as of 2026-03 — RF-01 (distilled).