Phase Management - johnpeterman72/CursorRIPER.sigma GitHub Wiki

📊 Project Phase Management

CursorRIPER♦Σ organizes project lifecycle into four distinct phases (Π), each with specific characteristics and transitions.

🎯 Phase Overview

Phase	Symbol	Name	Description	Trigger
Phase 1	Π₁ 🌱	UNINITIATED	Framework ready, not started	Installation
Phase 2	Π₂ 🚧	INITIALIZING	Setting up project	`/start`
Phase 3	Π₃ 🏗️	DEVELOPMENT	Active development	Setup complete
Phase 4	Π₄ 🔧	MAINTENANCE	Long-term support	User decision

🌱 Phase 1: Uninitiated (Π₁)

Characteristics

Π₁ = 🌱UNINITIATED ⟶ framework_installed ∧ ¬project_started

State

✅ Framework files present
✅ Rules enabled in Cursor
❌ No memory bank created
❌ No project configuration
❌ No mode active

What Happens

Framework waits for initialization
No memory files exist
No active context
AI recognizes framework but has no project data

Example State

.cursor/
└── rules/
    └── RIPERsigma1.0.5.mdc  ✓ Present

/memory-bank/                  ✗ Not created

Next Step

Type /start to begin initialization

🚧 Phase 2: Initializing (Π₂)

Characteristics

Π₂ = 🚧INITIALIZING ⟶ START_active ∧ setup_ongoing

State

✅ Memory bank created
⏳ Gathering requirements
⏳ Setting up structure
🔄 START process active

START Process (S₁-S₆)

S₁: gather(requirements) ⟶ create(σ₁)
S₂: select(technologies) ⟶ update(σ₃)
S₃: define(architecture) ⟶ create(σ₂)
S₄: scaffold(project) ⟶ create(directories)
S₅: setup(environment) ⟶ update(σ₃)
S₆: initialize(memory) ⟶ create(σ₁-σ₆)

Initialization Workflow

Step 1: Requirements Gathering

"What kind of project are we building?"
"What are the main requirements?"
"Who are the stakeholders?"

→ Updates projectbrief.md

Step 2: Technology Selection

"What programming language?"
"Which frameworks?"
"Database preferences?"

→ Updates techContext.md

Step 3: Architecture Definition

"Monolith or microservices?"
"API structure?"
"Component organization?"

→ Updates systemPatterns.md

Step 4: Project Scaffolding

Creating directory structure...
Setting up initial files...
Configuring environment...

→ Creates project structure

Step 5: Environment Setup

"Development environment requirements?"
"Deployment targets?"
"CI/CD preferences?"

→ Completes techContext.md

Step 6: Memory Initialization

✓ All memory files created
✓ Templates populated
✓ Cross-references established

→ Memory system ready

Duration

Typical: 15-30 minutes
Depends on project complexity
Can be paused and resumed

Completion Trigger

✅completion(START_phase) ⟶ transition(Π₂ → Π₃)

🏗️ Phase 3: Development (Π₃)

Characteristics

Π₃ = 🏗️DEVELOPMENT ⟶ main_development ∧ RIPER_active

State

✅ All systems operational
✅ RIPER modes available
✅ Memory actively updated
✅ Full framework features

Active Systems

Mode Engine

All five modes fully functional:

🔍 Research ↔️ 💡 Innovate ↔️ 📝 Plan ↔️ ⚙️ Execute ↔️ 🔎 Review

Memory System

Continuous updates:

σ₁: Requirements refined
σ₂: Patterns documented
σ₃: Stack evolving
σ₄: Context tracking
σ₅: Progress monitoring
σ₆: Protection growing

Protection System

Active enforcement:

Ψ₁-Ψ₆: Protection levels enforced
Γ₁-Γ₈: Context references tracked
ℙ: Permissions checked

Typical Activities

Week 1-2: Foundation

Core architecture implementation
Database schema design
Basic API structure

Week 3-4: Features

Authentication system
Core business logic
API endpoints

Week 5-6: Integration

Frontend connection
Third-party services
Testing suite

Week 7-8: Polish

Performance optimization
Security hardening
Documentation

Progress Tracking

## 📈 Development Metrics
- Features Complete: 24/30 (80%)
- Test Coverage: 78%
- Performance: ✅ Meeting targets
- Security: ⚠️ Audit pending

Phase Indicators

High mode switching frequency
Rapid memory updates
Active protection additions
Growing context references

🔧 Phase 4: Maintenance (Π₄)

Characteristics

Π₄ = 🔧MAINTENANCE ⟶ long_term_support ∧ RIPER_active

State

✅ Development complete
✅ Production deployed
🔄 Bug fixes only
🔄 Minor enhancements

Transition Trigger

Π₃ ↔️ Π₄: 🔄user_request

Can switch between Development and Maintenance as needed.

Maintenance Activities

Bug Fixes

/research → Investigate issue
/plan → Design fix
/execute → Implement fix
/review → Verify resolution

Performance Tuning

/research → Analyze metrics
/innovate → Optimization ideas
/plan → Improvement strategy
/execute → Apply optimizations

Security Updates

/research → Security audit
/plan → Patch strategy
/execute → Apply updates
/review → Verify security

Memory Focus

σ₅ (progress.md): Issue tracking
σ₆ (protection.md): Critical code
σ₄ (activeContext.md): Current fixes

Typical Workflow

Issue Reported → Research mode
Fix Planned → Plan mode
Fix Implemented → Execute mode
Fix Verified → Review mode
Documentation Updated → Back to standby

🔄 Phase Transitions

Transition Map

Π₁ → Π₂: /start command
Π₂ → Π₃: Automatic on completion
Π₃ ↔️ Π₄: User decision

Π₁ → Π₂ (Start Project)

transition(Π₁ → Π₂) = {
  verify(framework_ready),
  create_memory_bank(),
  enter(RESEARCH_mode),
  begin(START_process)
}

Π₂ → Π₃ (Begin Development)

transition(Π₂ → Π₃) = {
  verify(all_steps_complete),
  validate(memory_files),
  enable(full_features),
  log("Development phase active")
}

Π₃ ↔️ Π₄ (Development ↔️ Maintenance)

transition(Π₃ ↔️ Π₄) = {
  user_command("/maintenance" | "/development"),
  update_phase_marker(),
  adjust_workflow_focus(),
  maintain_all_features()
}

📊 Phase Indicators

How to Identify Current Phase

Π₁ Indicators

No /memory-bank/ folder
Framework responds to /start
No mode indicated

Π₂ Indicators

START process active
Memory files being created
Gathering requirements

Π₃ Indicators

Full mode switching
Active feature development
Rapid progress updates

Π₄ Indicators

Mostly Research/Execute modes
Focus on fixes
Stable memory files

Phase Status Check

"What phase are we in?"
"Show current phase status"
"Check phase indicators"

🎯 Phase-Specific Strategies

Π₁: Preparation

Review framework docs
Prepare requirements
Set up development environment

Π₂: Thoughtful Setup

Don't rush initialization
Provide detailed requirements
Consider future needs

Π₃: Structured Development

Follow RIPER workflow
Maintain protection discipline
Regular progress updates

Π₄: Efficient Maintenance

Quick issue resolution
Minimal disruption
Preserve stability

💡 Best Practices

1. Complete Each Phase

Don't skip initialization steps - they establish critical foundation.

2. Use Phase-Appropriate Modes

Π₂: Mostly Research/Plan
Π₃: All modes actively
Π₄: Research/Execute focus

3. Monitor Phase Health

## Phase Health Check
- Memory files current? ✅
- Protection adequate? ✅
- Context relevant? ⚠️
- Progress tracked? ✅

4. Phase Documentation

Keep phase transitions documented:

## Phase History
- 2024-01-01: Project started (Π₁ → Π₂)
- 2024-01-02: Development began (Π₂ → Π₃)
- 2024-03-15: Moved to maintenance (Π₃ → Π₄)
- 2024-03-20: Hotfix development (Π₄ → Π₃)

🚨 Common Phase Issues

Stuck in Initialization

Problem: START process incomplete Solution: Review missing steps, complete requirements

Premature Maintenance

Problem: Moved to Π₄ too early Solution: Switch back with /development

Phase Confusion

Problem: Unsure of current phase Solution: Check memory files and mode availability

Lost Phase Context

Problem: After long break Solution: Review progress.md and activeContext.md

📈 Phase Metrics

Typical Duration

Π₁: Minutes to days (until /start)
Π₂: 15-60 minutes
Π₃: Weeks to months
Π₄: Ongoing

Phase Efficiency

Track phase performance:

## Phase Metrics
- Initialization Time: 25 minutes
- Development Velocity: 5 features/week
- Maintenance Response: <2 hours
- Phase Transitions: 3 total

🔗 Phase Integration

With Modes

Each phase favors certain modes:

Π₂: Research, Plan
Π₃: All modes equally
Π₄: Research, Execute, Review

With Memory

Phase determines memory focus:

Π₂: Creating foundation
Π₃: Active updates
Π₄: Selective updates

With Protection

Protection strategy by phase:

Π₂: Identify critical areas
Π₃: Apply protection actively
Π₄: Maintain protection integrity

📚 Related Topics

← Symbolic Notation | Home | Features →