Phase-Gated Commits

Break large features and refactoring into discrete phases. Each phase follows a strict implement -> review -> test -> commit cycle. The result is a clean, bisectable git history where every commit represents a working state.

When to Use

• Multi-file features where changes span 3+ files
• Refactoring that touches shared code used by many modules
• Any work where you want the ability to revert one phase without losing others
• Migrations or upgrades that should be applied incrementally

When NOT to Use

• Single-file changes or small fixes
• Exploratory work where the final shape is unknown
• Prototyping where speed matters more than history

Phase Structure