DIDP Phase Model v1.0

Overview

DIDP uses a deterministic phase model to ensure predictable progress through development iterations. Each phase has specific purposes, allowed actions, and exit criteria.

Canonical Phases

planning → analysis → spec_lock → implementation → testing → archive → merge → complete

Phase Descriptions

Phase	Purpose	Key Activities
planning	Open exploration	Scope definition, requirements gathering, architecture discussion
analysis	Validate assumptions	Hypothesis testing, feasibility checks, risk identification
spec_lock	Freeze specification	Finalize requirements, lock scope, create implementation plan
implementation	Execute the plan	Write code, create artifacts, minimal conversation
testing	Proof and validation	Run tests, verify requirements, identify defects
archive	Preserve state	Archive artifacts, update documentation
merge	Integrate work	Merge to main branch, resolve conflicts
complete	Close iteration	Retrospective, lessons learned, handoff notes

Allowed Transitions

planning      → analysis
analysis      → spec_lock
analysis      → planning     (ONLY when replan_required: true)
spec_lock     → implementation
implementation → testing
testing       → archive
archive       → merge
merge         → complete

Transition Rules

Forward Transitions

• Require all exit criteria to be satisfied
• Must update iteration_state.yaml
• Must commit state changes to git

Back Transitions

• Only one is allowed: analysis → planning
• Requires explicit replan_required: true in analysis outcome
• Must document the reason for replan
• Triggers formal replan protocol

Prohibited Transitions

• Skipping phases (e.g., planning → implementation)
• Arbitrary back-transitions (e.g., testing → analysis)
• Transitions without exit criteria satisfaction

Conversation Modes

Each phase has an appropriate conversation style:

• planning: Back-and-forth exploration is expected and encouraged
• analysis: Clarifying questions allowed, but scope changes forbidden
• spec_lock: Structured finalization only
• implementation: Minimal conversation, execution focus
• testing: Defect-focused only
• archive/merge: Mechanical operations only
• complete: Retrospective only

Notes

• Back-and-forth conversation is expected in planning
• Analysis validates planning hypotheses
• Spec is frozen at spec_lock
• Testing is layered; the dedicated testing phase is proof/validation