Forward planning asks: "What should we build in this phase?"
Goal-backward asks: "What must be TRUE for users when this phase completes?"
Forward produces task lists. Goal-backward produces success criteria that tasks must satisfy.
Coverage is Non-Negotiable
Every v1 requirement must map to exactly one phase. No orphans. No duplicates.
If a requirement doesn't fit any phase → create a phase or defer to v2.
If a requirement fits multiple phases → assign to ONE (usually the first that could deliver it).
Goal-Backward Phases
Deriving Phase Success Criteria
For each phase, ask: "What must be TRUE for users when this phase completes?"
Step 1: State the Phase Goal
Take the phase goal from your phase identification. This is the outcome, not the work.
Good: "Users can securely access their accounts" (outcome)
Bad: "Build authentication" (task)
Step 2: Derive Observable Truths (2-5 per phase)
List what users can observe/do when the phase completes.
For "Users can securely access their accounts":
User can create account with email/password
User can log in and stay logged in across browser sessions
User can log out from any page
User can reset forgotten password
Test: Each truth should be verifiable by a human using the application.
Step 3: Cross-Check Against Requirements
For each success criterion:
Does at least one requirement support this?
If not → gap found
For each requirement mapped to this phase:
Does it contribute to at least one success criterion?
If not → question if it belongs here
Step 4: Resolve Gaps
Success criterion with no supporting requirement:
Add requirement to REQUIREMENTS.md, OR
Mark criterion as out of scope for this phase
Requirement that supports no criterion:
Question if it belongs in this phase
Maybe it's v2 scope
Maybe it belongs in different phase
Phase Identification
Deriving Phases from Requirements
Step 1: Group by Category
Requirements already have categories (AUTH, CONTENT, etc.). Start by examining these natural groupings.
Step 2: Identify Dependencies
Which categories depend on others?
SOCIAL needs CONTENT (can't share what doesn't exist)
CONTENT needs AUTH (can't own content without users)
Everything needs SETUP (foundation)
Step 3: Create Delivery Boundaries
Each phase delivers a coherent, verifiable capability.
Good boundaries:
Complete a requirement category
Enable a user workflow end-to-end
Unblocks next phase
Bad boundaries:
Arbitrary technical layers (all models, then all APIs)
Partial features (half of auth)
Artificial splits to hit a number
Step 4: Assign Requirements
Map every v1 requirement to exactly one phase. Track coverage as you go.
Phase Numbering
Integer phases (1, 2, 3): Planned milestone work.
Decimal phases (2.1, 2.2): Urgent insertions after planning.
Created via /gsd:insert-phase
Execute between integers: 1 → 1.1 → 1.2 → 2
Starting number:
New milestone: Start at 1
Continuing milestone: Check existing phases, start at last + 1
Depth Calibration
Read depth from config.json. Depth controls compression tolerance.
Depth
Typical Phases
What It Means
Quick
3-5
Combine aggressively, critical path only
Standard
5-8
Balanced grouping
Comprehensive
8-12
Let natural boundaries stand
Key: Derive phases from work, then apply depth as compression guidance. Don't pad small projects or compress complex ones.
Phase 1: All database models ← Too coupled
Phase 2: All API endpoints ← Can't verify independently
Phase 3: All UI components ← Nothing works until end
Coverage Validation
After phase identification, verify every v1 requirement is mapped.
