```
├── .cursor/
├── rules/
├── isolation_rules/
├── Core/
├── command-execution.mdc
├── complexity-decision-tree.mdc
├── creative-phase-enforcement.mdc
├── creative-phase-metrics.mdc
├── file-verification.mdc
├── platform-awareness.mdc
├── Level3/
├── planning-comprehensive.mdc
├── task-tracking-intermediate.mdc
├── Phases/
├── CreativePhase/
├── creative-phase-architecture.mdc
├── main.mdc
├── visual-maps/
├── archive-mode-map.mdc
├── creative-mode-map.mdc
├── implement-mode-map.mdc
├── plan-mode-map.mdc
├── qa-mode-map.mdc
├── reflect-mode-map.mdc
├── van-mode-map.mdc
├── van_mode_split/
├── van-complexity-determination.mdc
├── van-file-verification.mdc
├── van-mode-map.mdc
├── van-platform-detection.mdc
├── van-qa-checks/
├── build-test.mdc
├── config-check.mdc
├── dependency-check.mdc
├── environment-check.mdc
├── file-verification.mdc
├── van-qa-main.mdc
├── van-qa-utils/
├── common-fixes.mdc
├── mode-transitions.mdc
├── reports.mdc
├── rule-calling-guide.mdc
├── rule-calling-help.mdc
├── van-qa-validation.md.old
├── .gitignore
├── README.md
├── assets/
├── custom_mode_setup_1.png
├── custom_mode_setup_2.png
├── creative_mode_think_tool.md
├── custom_modes/
├── creative_instructions.md
├── implement_instructions.md
```
## /.cursor/rules/isolation_rules/Core/command-execution.mdc
```mdc path="/.cursor/rules/isolation_rules/Core/command-execution.mdc"
---
description: Command execution guidelines for isolation-focused Memory Bank
globs: command-execution.mdc
alwaysApply: false
---
# COMMAND EXECUTION SYSTEM
> **TL;DR:** This system provides guidelines for efficient command execution, balancing clarity and token optimization through appropriate command chaining, with proper documentation of commands and results.
## 🔍 COMMAND EFFICIENCY WORKFLOW
\`\`\`mermaid
graph TD
Start["Command Planning"] --> Analyze["Analyze Command Requirements"]
Analyze --> Balance["Balance Clarity vs. Efficiency"]
Balance --> Complexity{"Command Complexity?"}
Complexity -->|"Simple"| Single["Execute Single Command"]
Complexity -->|"Moderate"| Chain["Use Efficient Command Chaining"]
Complexity -->|"Complex"| Group["Group Into Logical Steps"]
Single & Chain & Group --> Verify["Verify Results"]
Verify --> Document["Document Command & Result"]
Document --> Next["Next Command"]
\`\`\`
## 📋 COMMAND CHAINING GUIDELINES
\`\`\`mermaid
graph TD
Command["Command Execution"] --> ChainApprop{"Is Chaining Appropriate?"}
ChainApprop -->|"Yes"| ChainTypes["Chain Types"]
ChainApprop -->|"No"| SingleCmd["Use Single Commands"]
ChainTypes --> Sequential["Sequential Operations cmd1 && cmd2"]
ChainTypes --> Conditional["Conditional Operations cmd1 || cmd2"]
ChainTypes --> Piping["Piping cmd1 | cmd2"]
ChainTypes --> Grouping["Command Grouping (cmd1; cmd2)"]
Sequential & Conditional & Piping & Grouping --> Doc["Document Commands & Results"]
\`\`\`
## 🚦 DIRECTORY VERIFICATION WORKFLOW
\`\`\`mermaid
graph TD
Command["Command Execution"] --> DirCheck["Check Current Directory"]
DirCheck --> ProjectRoot{"In Project Root?"}
ProjectRoot -->|"Yes"| Execute["Execute Command"]
ProjectRoot -->|"No"| Locate["Locate Project Root"]
Locate --> Found{"Project Root Found?"}
Found -->|"Yes"| Navigate["Navigate to Project Root"]
Found -->|"No"| Error["Error: Cannot Find Project Root"]
Navigate --> Execute
Execute --> Verify["Verify Results"]
\`\`\`
## 📋 DIRECTORY VERIFICATION CHECKLIST
Before executing any npm or build command:
| Step | Windows (PowerShell) | Unix/Linux/Mac | Purpose |
|------|----------------------|----------------|---------|
| **Check package.json** | `Test-Path package.json` | `ls package.json` | Verify current directory is project root |
| **Check for parent directory** | `Test-Path "*/package.json"` | `find . -maxdepth 2 -name package.json` | Find potential project directories |
| **Navigate to project root** | `cd [project-dir]` | `cd [project-dir]` | Move to correct directory before executing commands |
## 📋 REACT-SPECIFIC COMMAND GUIDELINES
For React applications, follow these strict guidelines:
| Command | Correct Usage | Incorrect Usage | Notes |
|---------|---------------|----------------|-------|
| **npm start** | `cd [project-root] && npm start` | `npm start` (from parent dir) | Must execute from directory with package.json |
| **npm run build** | `cd [project-root] && npm run build` | `cd [parent-dir] && npm run build` | Must execute from directory with package.json |
| **npm install** | `cd [project-root] && npm install [pkg]` | `npm install [pkg]` (wrong dir) | Dependencies installed to nearest package.json |
| **npm create** | `npm create vite@latest my-app -- --template react` | Manually configuring webpack | Use standard tools for project creation |
## 🔄 COMMAND CHAINING PATTERNS
Effective command chaining patterns include:
| Pattern | Format | Examples | Use Case |
|---------|--------|----------|----------|
| **Sequential** | `cmd1 && cmd2` | `mkdir dir && cd dir` | Commands that should run in sequence, second only if first succeeds |
| **Conditional** | `cmd1 || cmd2` | `test -f file.txt || touch file.txt` | Fallback commands, second only if first fails |
| **Piping** | `cmd1 \| cmd2` | `grep "pattern" file.txt \| wc -l` | Pass output of first command as input to second |
| **Background** | `cmd &` | `npm start &` | Run command in background |
| **Grouping** | `(cmd1; cmd2)` | `(echo "Start"; npm test; echo "End")` | Group commands to run as a unit |
## 📋 COMMAND DOCUMENTATION TEMPLATE
\`\`\`
## Command Execution: [Purpose]
### Command
\`\`\`
[actual command or chain]
\`\`\`
### Result
\`\`\`
[command output]
\`\`\`
### Effect
[Brief description of what changed in the system]
### Next Steps
[What needs to be done next]
\`\`\`
## 🔍 PLATFORM-SPECIFIC CONSIDERATIONS
\`\`\`mermaid
graph TD
Platform["Platform Detection"] --> Windows["Windows Commands"]
Platform --> Unix["Unix/Linux/Mac Commands"]
Windows --> WinAdapt["Windows Command Adaptations"]
Unix --> UnixAdapt["Unix Command Adaptations"]
WinAdapt --> WinChain["Windows Chaining: Commands separated by &"]
UnixAdapt --> UnixChain["Unix Chaining: Commands separated by ;"]
WinChain & UnixChain --> Execute["Execute Platform-Specific Commands"]
\`\`\`
## 📋 COMMAND EFFICIENCY EXAMPLES
Examples of efficient command usage:
| Inefficient | Efficient | Explanation |
|-------------|-----------|-------------|
| `mkdir dir` `cd dir` `npm init -y` | `mkdir dir && cd dir && npm init -y` | Combines related sequential operations |
| `ls` `grep "\.js$"` | `ls \| grep "\.js$"` | Pipes output of first command to second |
| `test -f file.txt` `if not exists, touch file.txt` | `test -f file.txt \|\| touch file.txt` | Creates file only if it doesn't exist |
| `mkdir dir1` `mkdir dir2` `mkdir dir3` | `mkdir dir1 dir2 dir3` | Uses command's built-in multiple argument capability |
| `npm install pkg1` `npm install pkg2` | `npm install pkg1 pkg2` | Installs multiple packages in one command |
## 📋 REACT PROJECT INITIALIZATION STANDARDS
Always use these standard approaches for React project creation:
| Approach | Command | Benefits | Avoids |
|----------|---------|----------|--------|
| **Create React App** | `npx create-react-app my-app` | Preconfigured webpack & babel | Manual configuration errors |
| **Create React App w/TypeScript** | `npx create-react-app my-app --template typescript` | Type safety + preconfigured | Inconsistent module systems |
| **Vite** | `npm create vite@latest my-app -- --template react` | Faster build times | Complex webpack setups |
| **Next.js** | `npx create-next-app@latest my-app` | SSR support | Module system conflicts |
## ⚠️ ERROR HANDLING WORKFLOW
\`\`\`mermaid
sequenceDiagram
participant User
participant AI
participant System
AI->>System: Execute Command
System->>AI: Return Result
alt Success
AI->>AI: Verify Expected Result
AI->>User: Report Success
else Error
AI->>AI: Analyze Error Message
AI->>AI: Identify Likely Cause
AI->>User: Explain Error & Cause
AI->>User: Suggest Corrective Action
User->>AI: Approve Correction
AI->>System: Execute Corrected Command
end
\`\`\`
## 📋 COMMAND RESULT VERIFICATION
After command execution, verify:
\`\`\`mermaid
graph TD
Execute["Execute Command"] --> Check{"Check Result"}
Check -->|"Success"| Verify["Verify Expected Outcome"]
Check -->|"Error"| Analyze["Analyze Error"]
Verify -->|"Expected"| Document["Document Success"]
Verify -->|"Unexpected"| Investigate["Investigate Unexpected Result"]
Analyze --> Diagnose["Diagnose Error Cause"]
Diagnose --> Correct["Propose Correction"]
Document & Investigate & Correct --> Next["Next Step in Process"]
\`\`\`
## 📝 COMMAND EXECUTION CHECKLIST
\`\`\`
✓ COMMAND EXECUTION CHECKLIST
- Command purpose clearly identified? [YES/NO]
- Appropriate balance of clarity vs. efficiency? [YES/NO]
- Platform-specific considerations addressed? [YES/NO]
- Command documented with results? [YES/NO]
- Outcome verified against expectations? [YES/NO]
- Errors properly handled (if any)? [YES/NO/NA]
- For npm/build commands: Executed from project root? [YES/NO/NA]
- For React projects: Using standard tooling? [YES/NO/NA]
→ If all YES: Command execution complete
→ If any NO: Address missing elements
\`\`\`
## 🚨 COMMAND EXECUTION WARNINGS
Avoid these common command issues:
\`\`\`mermaid
graph TD
Warning["Command Warnings"] --> W1["Excessive Verbosity"]
Warning --> W2["Insufficient Error Handling"]
Warning --> W3["Unnecessary Complexity"]
Warning --> W4["Destructive Operations Without Confirmation"]
Warning --> W5["Wrong Directory Execution"]
W1 --> S1["Use flags to reduce unnecessary output"]
W2 --> S2["Include error handling in command chains"]
W3 --> S3["Prefer built-in command capabilities"]
W4 --> S4["Show confirmation before destructive actions"]
W5 --> S5["Verify directory before npm/build commands"]
\`\`\`
```
## /.cursor/rules/isolation_rules/Core/complexity-decision-tree.mdc
```mdc path="/.cursor/rules/isolation_rules/Core/complexity-decision-tree.mdc"
---
description: complexity decision tree
globs: complexity-decision-tree.mdc
alwaysApply: false
---
# TASK COMPLEXITY DETERMINATION
> **TL;DR:** This document helps determine the appropriate complexity level (1-4) for any task. Use the decision tree and indicators to select the right process level, then load the corresponding process map.
## 🌳 COMPLEXITY DECISION TREE
\`\`\`mermaid
graph TD
Start["New Task"] --> Q1{"Bug fix or error correction?"}
Q1 -->|Yes| Q1a{"Affects single component?"}
Q1a -->|Yes| L1["Level 1: Quick Bug Fix"]
Q1a -->|No| Q1b{"Affects multiple components?"}
Q1b -->|Yes| L2["Level 2: Simple Enhancement"]
Q1b -->|No| Q1c{"Affects system architecture?"}
Q1c -->|Yes| L3["Level 3: Intermediate Feature"]
Q1c -->|No| L2
Q1 -->|No| Q2{"Adding small feature or enhancement?"}
Q2 -->|Yes| Q2a{"Self-contained change?"}
Q2a -->|Yes| L2
Q2a -->|No| Q2b{"Affects multiple components?"}
Q2b -->|Yes| L3
Q2b -->|No| L2
Q2 -->|No| Q3{"Complete feature requiring multiple components?"}
Q3 -->|Yes| Q3a{"Architectural implications?"}
Q3a -->|Yes| L4["Level 4: Complex System"]
Q3a -->|No| L3
Q3 -->|No| Q4{"System-wide or architectural change?"}
Q4 -->|Yes| L4
Q4 -->|No| L3
L1 --> LoadL1["Load Level 1 Map"]
L2 --> LoadL2["Load Level 2 Map"]
L3 --> LoadL3["Load Level 3 Map"]
L4 --> LoadL4["Load Level 4 Map"]
\`\`\`
## 📊 COMPLEXITY LEVEL INDICATORS
Use these indicators to help determine task complexity:
### Level 1: Quick Bug Fix
- **Keywords**: "fix", "broken", "not working", "issue", "bug", "error", "crash"
- **Scope**: Single component or UI element
- **Duration**: Can be completed quickly (minutes to hours)
- **Risk**: Low, isolated changes
- **Examples**:
- Fix button not working
- Correct styling issue
- Fix validation error
- Resolve broken link
- Fix typo or text issue
### Level 2: Simple Enhancement
- **Keywords**: "add", "improve", "update", "change", "enhance", "modify"
- **Scope**: Single component or subsystem
- **Duration**: Hours to 1-2 days
- **Risk**: Moderate, contained to specific area
- **Examples**:
- Add form field
- Improve validation
- Update styling
- Add simple feature
- Change text content
- Enhance existing component
### Level 3: Intermediate Feature
- **Keywords**: "implement", "create", "develop", "build", "feature"
- **Scope**: Multiple components, complete feature
- **Duration**: Days to 1-2 weeks
- **Risk**: Significant, affects multiple areas
- **Examples**:
- Implement user authentication
- Create dashboard
- Develop search functionality
- Build user profile system
- Implement data visualization
- Create complex form system
### Level 4: Complex System
- **Keywords**: "system", "architecture", "redesign", "integration", "framework"
- **Scope**: Multiple subsystems or entire application
- **Duration**: Weeks to months
- **Risk**: High, architectural implications
- **Examples**:
- Implement authentication system
- Build payment processing framework
- Create microservice architecture
- Implement database migration system
- Develop real-time communication system
- Create multi-tenant architecture
## 🔍 COMPLEXITY ASSESSMENT QUESTIONS
Answer these questions to determine complexity:
1. **Scope Impact**
- Does it affect a single component or multiple?
- Are there system-wide implications?
- How many files will need to be modified?
2. **Design Decisions**
- Are complex design decisions required?
- Will it require creative phases for design?
- Are there architectural considerations?
3. **Risk Assessment**
- What happens if it fails?
- Are there security implications?
- Will it affect critical functionality?
4. **Implementation Effort**
- How long will it take to implement?
- Does it require specialized knowledge?
- Is extensive testing needed?
## 📊 KEYWORD ANALYSIS TABLE
| Keyword | Likely Level | Notes |
|---------|--------------|-------|
| "Fix" | Level 1 | Unless system-wide |
| "Bug" | Level 1 | Unless multiple components |
| "Error" | Level 1 | Unless architectural |
| "Add" | Level 2 | Unless complex feature |
| "Update" | Level 2 | Unless architectural |
| "Improve" | Level 2 | Unless system-wide |
| "Implement" | Level 3 | Complex components |
| "Create" | Level 3 | New functionality |
| "Develop" | Level 3 | Significant scope |
| "System" | Level 4 | Architectural implications |
| "Architecture" | Level 4 | Major structural changes |
| "Framework" | Level 4 | Core infrastructure |
## 🔄 COMPLEXITY ESCALATION
If during a task you discover it's more complex than initially determined:
\`\`\`
⚠️ TASK ESCALATION NEEDED
Current Level: Level [X]
Recommended Level: Level [Y]
Reason: [Brief explanation]
Would you like me to escalate this task to Level [Y]?
\`\`\`
If approved, switch to the appropriate higher-level process map.
## 🎯 PROCESS SELECTION
After determining complexity, load the appropriate process map:
| Level | Description | Process Map |
|-------|-------------|-------------|
| 1 | Quick Bug Fix | [Level 1 Map](mdc:.cursor/rules/visual-maps/level1-map.mdc) |
| 2 | Simple Enhancement | [Level 2 Map](mdc:.cursor/rules/visual-maps/level2-map.mdc) |
| 3 | Intermediate Feature | [Level 3 Map](mdc:.cursor/rules/visual-maps/level3-map.mdc) |
| 4 | Complex System | [Level 4 Map](mdc:.cursor/rules/visual-maps/level4-map.mdc) |
## 📝 COMPLEXITY DETERMINATION TEMPLATE
Use this template to document complexity determination:
\`\`\`
## COMPLEXITY DETERMINATION
Task: [Task description]
Assessment:
- Scope: [Single component/Multiple components/System-wide]
- Design decisions: [Simple/Moderate/Complex]
- Risk: [Low/Moderate/High]
- Implementation effort: [Low/Moderate/High]
Keywords identified: [List relevant keywords]
Determination: Level [1/2/3/4] - [Quick Bug Fix/Simple Enhancement/Intermediate Feature/Complex System]
Loading process map: [Level X Map]
\`\`\`
```
## /.cursor/rules/isolation_rules/Core/creative-phase-enforcement.mdc
```mdc path="/.cursor/rules/isolation_rules/Core/creative-phase-enforcement.mdc"
---
description: creative phase enforcement
globs: creative-phase-enforcement.md
alwaysApply: false
---
# CREATIVE PHASE ENFORCEMENT
> **TL;DR:** This document implements strict enforcement of creative phase requirements for Level 3-4 tasks, ensuring all design decisions are properly documented and verified before implementation can proceed.
## 🔍 ENFORCEMENT WORKFLOW
\`\`\`mermaid
graph TD
Start["Task Start"] --> Check{"Level 3-4 Task?"}
Check -->|Yes| Analyze["Analyze Design Decision Points"]
Check -->|No| Optional["Creative Phase Optional"]
Analyze --> Decision{"Design Decisions Required?"}
Decision -->|Yes| Gate["🚨 IMPLEMENTATION BLOCKED"]
Decision -->|No| Allow["Allow Implementation"]
Gate --> Creative["Enter Creative Phase"]
Creative --> Verify{"All Decisions Documented?"}
Verify -->|No| Return["Return to Creative Phase"]
Verify -->|Yes| Proceed["Allow Implementation"]
style Start fill:#4da6ff,stroke:#0066cc,color:white
style Check fill:#ffa64d,stroke:#cc7a30,color:white
style Analyze fill:#4dbb5f,stroke:#36873f,color:white
style Gate fill:#d94dbb,stroke:#a3378a,color:white
style Creative fill:#4dbbbb,stroke:#368787,color:white
style Verify fill:#d971ff,stroke:#a33bc2,color:white
\`\`\`
## 🚨 ENFORCEMENT GATES
\`\`\`mermaid
graph TD
subgraph "CREATIVE PHASE GATES"
G1["Entry Gate Verify Requirements"]
G2["Process Gate Verify Progress"]
G3["Exit Gate Verify Completion"]
end
G1 --> G2 --> G3
style G1 fill:#4dbb5f,stroke:#36873f,color:white
style G2 fill:#ffa64d,stroke:#cc7a30,color:white
style G3 fill:#d94dbb,stroke:#a3378a,color:white
\`\`\`
## 📋 ENFORCEMENT CHECKLIST
\`\`\`markdown
## Entry Gate Verification
- [ ] Task complexity is Level 3-4
- [ ] Design decisions identified
- [ ] Creative phase requirements documented
- [ ] Required participants notified
## Process Gate Verification
- [ ] All options being considered
- [ ] Pros/cons documented
- [ ] Technical constraints identified
- [ ] Implementation impacts assessed
## Exit Gate Verification
- [ ] All decisions documented
- [ ] Rationale provided for choices
- [ ] Implementation plan outlined
- [ ] Verification against requirements
\`\`\`
## 🚨 IMPLEMENTATION BLOCK NOTICE
When a creative phase is required but not completed:
\`\`\`
🚨 IMPLEMENTATION BLOCKED
Creative phases MUST be completed before implementation.
Required Creative Phases:
- [ ] [Creative Phase 1]
- [ ] [Creative Phase 2]
- [ ] [Creative Phase 3]
⛔ This is a HARD BLOCK
Implementation CANNOT proceed until all creative phases are completed.
Type "PHASE.REVIEW" to begin creative phase review.
\`\`\`
## ✅ VERIFICATION PROTOCOL
\`\`\`mermaid
graph TD
subgraph "VERIFICATION STEPS"
V1["1. Requirements Check"]
V2["2. Documentation Review"]
V3["3. Decision Validation"]
V4["4. Implementation Readiness"]
end
V1 --> V2 --> V3 --> V4
style V1 fill:#4dbb5f,stroke:#36873f,color:white
style V2 fill:#ffa64d,stroke:#cc7a30,color:white
style V3 fill:#d94dbb,stroke:#a3378a,color:white
style V4 fill:#4dbbbb,stroke:#368787,color:white
\`\`\`
## 🔄 CREATIVE PHASE MARKERS
Use these markers to clearly indicate creative phase boundaries:
\`\`\`markdown
🎨🎨🎨 ENTERING CREATIVE PHASE: [TYPE] 🎨🎨🎨
Focus: [Specific component/feature]
Objective: [Clear goal of this creative phase]
Requirements: [List of requirements]
[Creative phase content]
🎨 CREATIVE CHECKPOINT: [Milestone]
- Progress: [Status]
- Decisions: [List]
- Next steps: [Plan]
🎨🎨🎨 EXITING CREATIVE PHASE 🎨🎨🎨
Summary: [Brief description]
Key Decisions: [List]
Next Steps: [Implementation plan]
\`\`\`
## 🔄 DOCUMENT MANAGEMENT
\`\`\`mermaid
graph TD
Current["Current Document"] --> Active["Active: - creative-phase-enforcement.md"]
Current --> Related["Related: - creative-phase-architecture.md - task-tracking-intermediate.md"]
style Current fill:#4da6ff,stroke:#0066cc,color:white
style Active fill:#4dbb5f,stroke:#36873f,color:white
style Related fill:#ffa64d,stroke:#cc7a30,color:white
\`\`\`
```
## /.cursor/rules/isolation_rules/Core/creative-phase-metrics.mdc
```mdc path="/.cursor/rules/isolation_rules/Core/creative-phase-metrics.mdc"
---
description: creative phase metrics
globs: creative-phase-metrics.md
alwaysApply: false
---
# CREATIVE PHASE METRICS
> **TL;DR:** This document defines comprehensive quality metrics and measurement criteria for creative phases, ensuring that design decisions meet required standards and are properly documented.
## 📊 METRICS OVERVIEW
\`\`\`mermaid
graph TD
subgraph "CREATIVE PHASE METRICS"
M1["Documentation Quality"]
M2["Decision Coverage"]
M3["Option Analysis"]
M4["Impact Assessment"]
M5["Verification Score"]
end
M1 --> Score["Quality Score"]
M2 --> Score
M3 --> Score
M4 --> Score
M5 --> Score
style M1 fill:#4dbb5f,stroke:#36873f,color:white
style M2 fill:#ffa64d,stroke:#cc7a30,color:white
style M3 fill:#d94dbb,stroke:#a3378a,color:white
style M4 fill:#4dbbbb,stroke:#368787,color:white
style M5 fill:#d971ff,stroke:#a33bc2,color:white
style Score fill:#ff71c2,stroke:#c23b8a,color:white
\`\`\`
## 📋 QUALITY METRICS SCORECARD
\`\`\`markdown
# Creative Phase Quality Assessment
## 1. Documentation Quality [0-10]
- [ ] Clear problem statement (2 points)
- [ ] Well-defined objectives (2 points)
- [ ] Comprehensive requirements list (2 points)
- [ ] Proper formatting and structure (2 points)
- [ ] Cross-references to related documents (2 points)
## 2. Decision Coverage [0-10]
- [ ] All required decisions identified (2 points)
- [ ] Each decision point documented (2 points)
- [ ] Dependencies mapped (2 points)
- [ ] Impact analysis included (2 points)
- [ ] Future considerations noted (2 points)
## 3. Option Analysis [0-10]
- [ ] Multiple options considered (2 points)
- [ ] Pros/cons documented (2 points)
- [ ] Technical feasibility assessed (2 points)
- [ ] Resource requirements estimated (2 points)
- [ ] Risk factors identified (2 points)
## 4. Impact Assessment [0-10]
- [ ] System impact documented (2 points)
- [ ] Performance implications assessed (2 points)
- [ ] Security considerations addressed (2 points)
- [ ] Maintenance impact evaluated (2 points)
- [ ] Cost implications analyzed (2 points)
## 5. Verification Score [0-10]
- [ ] Requirements traced (2 points)
- [ ] Constraints validated (2 points)
- [ ] Test scenarios defined (2 points)
- [ ] Review feedback incorporated (2 points)
- [ ] Final verification completed (2 points)
Total Score: [Sum of all categories] / 50
Minimum Required Score: 40/50 (80%)
\`\`\`
## 📈 QUALITY THRESHOLDS
\`\`\`mermaid
graph TD
subgraph "QUALITY GATES"
T1["Minimum 40/50 (80%)"]
T2["Target 45/50 (90%)"]
T3["Excellent 48/50 (96%)"]
end
Score["Quality Score"] --> Check{"Meets Threshold?"}
Check -->|"< 80%"| Block["⛔ BLOCKED Improvements Required"]
Check -->|"≥ 80%"| Pass["✓ PASSED Can Proceed"]
style T1 fill:#4dbb5f,stroke:#36873f,color:white
style T2 fill:#ffa64d,stroke:#cc7a30,color:white
style T3 fill:#d94dbb,stroke:#a3378a,color:white
style Score fill:#4dbbbb,stroke:#368787,color:white
style Check fill:#d971ff,stroke:#a33bc2,color:white
\`\`\`
## 🎯 METRIC EVALUATION PROCESS
\`\`\`mermaid
graph TD
Start["Start Evaluation"] --> Doc["1. Score Documentation"]
Doc --> Dec["2. Assess Decisions"]
Dec --> Opt["3. Review Options"]
Opt --> Imp["4. Evaluate Impact"]
Imp --> Ver["5. Verify Completeness"]
Ver --> Total["Calculate Total Score"]
Total --> Check{"Meets Threshold?"}
Check -->|No| Return["Return for Improvements"]
Check -->|Yes| Proceed["Proceed to Next Phase"]
style Start fill:#4da6ff,stroke:#0066cc,color:white
style Doc fill:#ffa64d,stroke:#cc7a30,color:white
style Dec fill:#4dbb5f,stroke:#36873f,color:white
style Opt fill:#d94dbb,stroke:#a3378a,color:white
style Imp fill:#4dbbbb,stroke:#368787,color:white
style Ver fill:#d971ff,stroke:#a33bc2,color:white
\`\`\`
## 📊 IMPROVEMENT RECOMMENDATIONS
For scores below threshold:
\`\`\`markdown
## Documentation Quality Improvements
- Add clear problem statements
- Include specific objectives
- List all requirements
- Improve formatting
- Add cross-references
## Decision Coverage Improvements
- Identify missing decisions
- Document all decision points
- Map dependencies
- Add impact analysis
- Consider future implications
## Option Analysis Improvements
- Consider more alternatives
- Detail pros/cons
- Assess technical feasibility
- Estimate resource needs
- Identify risks
## Impact Assessment Improvements
- Document system impact
- Assess performance
- Address security
- Evaluate maintenance
- Analyze costs
## Verification Improvements
- Trace requirements
- Validate constraints
- Define test scenarios
- Incorporate feedback
- Complete verification
\`\`\`
## ✅ METRICS VERIFICATION CHECKLIST
\`\`\`markdown
## Pre-Review Verification
- [ ] All sections scored
- [ ] Calculations verified
- [ ] Supporting evidence attached
- [ ] Improvement areas identified
- [ ] Review feedback incorporated
## Final Metrics Verification
- [ ] Minimum score achieved
- [ ] All categories passed
- [ ] Documentation complete
- [ ] Improvements addressed
- [ ] Final approval obtained
\`\`\`
## 🔄 DOCUMENT MANAGEMENT
\`\`\`mermaid
graph TD
Current["Current Document"] --> Active["Active: - creative-phase-metrics.md"]
Current --> Related["Related: - creative-phase-enforcement.md - creative-phase-architecture.md"]
style Current fill:#4da6ff,stroke:#0066cc,color:white
style Active fill:#4dbb5f,stroke:#36873f,color:white
style Related fill:#ffa64d,stroke:#cc7a30,color:white
\`\`\`
```
## /.cursor/rules/isolation_rules/Core/file-verification.mdc
```mdc path="/.cursor/rules/isolation_rules/Core/file-verification.mdc"
---
description: Optimized file verification
globs: file-verification.mdc
alwaysApply: false
---
# OPTIMIZED FILE VERIFICATION SYSTEM
> **TL;DR:** This system efficiently verifies and creates required Memory Bank file structures using batch operations and platform-optimized commands.
## 🔍 OPTIMIZED FILE VERIFICATION WORKFLOW
\`\`\`mermaid
graph TD
Start["Start File Verification"] --> VerifyAll["Verify All Required Components"]
VerifyAll --> MissingCheck{"Missing Components?"}
MissingCheck -->|"Yes"| BatchCreate["Batch Create All Missing Items"]
MissingCheck -->|"No"| Complete["Verification Complete"]
BatchCreate --> Report["Generate Verification Report"]
Report --> Complete
\`\`\`
## 📋 OPTIMIZED DIRECTORY CREATION
\`\`\`mermaid
graph TD
Start["Directory Creation"] --> DetectOS["Detect Operating System"]
DetectOS -->|"Windows"| WinCmd["Batch Create Windows Command"]
DetectOS -->|"Mac/Linux"| UnixCmd["Batch Create Unix Command"]
WinCmd & UnixCmd --> Verify["Verify Creation Success"]
Verify --> Complete["Directory Setup Complete"]
\`\`\`
### Platform-Specific Commands
#### Windows (PowerShell)
\`\`\`powershell
# Create all directories in one command
mkdir memory-bank, docs, docs\archive -ErrorAction SilentlyContinue
# Create all required files
$files = @(".cursorrules", "tasks.md",
"memory-bank\projectbrief.md",
"memory-bank\productContext.md",
"memory-bank\systemPatterns.md",
"memory-bank\techContext.md",
"memory-bank\activeContext.md",
"memory-bank\progress.md")
foreach ($file in $files) {
if (-not (Test-Path $file)) {
New-Item -Path $file -ItemType File -Force
}
}
\`\`\`
#### Mac/Linux (Bash)
\`\`\`bash
# Create all directories in one command
mkdir -p memory-bank docs/archive
# Create all required files
touch .cursorrules tasks.md \
memory-bank/projectbrief.md \
memory-bank/productContext.md \
memory-bank/systemPatterns.md \
memory-bank/techContext.md \
memory-bank/activeContext.md \
memory-bank/progress.md
\`\`\`
## 📝 STREAMLINED VERIFICATION PROCESS
Instead of checking each component separately, perform batch verification:
\`\`\`powershell
# Windows - PowerShell
$requiredDirs = @("memory-bank", "docs", "docs\archive")
$requiredFiles = @(".cursorrules", "tasks.md")
$mbFiles = @("projectbrief.md", "productContext.md", "systemPatterns.md",
"techContext.md", "activeContext.md", "progress.md")
$missingDirs = $requiredDirs | Where-Object { -not (Test-Path $_) -or -not (Test-Path $_ -PathType Container) }
$missingFiles = $requiredFiles | Where-Object { -not (Test-Path $_) -or (Test-Path $_ -PathType Container) }
$missingMBFiles = $mbFiles | ForEach-Object { "memory-bank\$_" } |
Where-Object { -not (Test-Path $_) -or (Test-Path $_ -PathType Container) }
if ($missingDirs.Count -eq 0 -and $missingFiles.Count -eq 0 -and $missingMBFiles.Count -eq 0) {
Write-Output "✓ All required components verified"
} else {
# Create all missing items at once
if ($missingDirs.Count -gt 0) {
$missingDirs | ForEach-Object { mkdir $_ -Force }
}
if ($missingFiles.Count -gt 0 -or $missingMBFiles.Count -gt 0) {
$allMissingFiles = $missingFiles + $missingMBFiles
$allMissingFiles | ForEach-Object { New-Item -Path $_ -ItemType File -Force }
}
}
\`\`\`
## 📝 TEMPLATE INITIALIZATION
Optimize template creation with a single script:
\`\`\`powershell
# Windows - PowerShell
$templates = @{
"tasks.md" = @"
# Memory Bank: Tasks
## Current Task
[Task not yet defined]
## Status
- [ ] Task definition
- [ ] Implementation plan
- [ ] Execution
- [ ] Documentation
## Requirements
[No requirements defined yet]
"@
"memory-bank\activeContext.md" = @"
# Memory Bank: Active Context
## Current Focus
[No active focus defined]
## Status
[No status defined]
## Latest Changes
[No changes recorded]
"@
# Add other templates here
}
foreach ($file in $templates.Keys) {
if (Test-Path $file) {
Set-Content -Path $file -Value $templates[$file]
}
}
\`\`\`
## 🔍 PERFORMANCE OPTIMIZATION BEST PRACTICES
1. **Batch Operations**: Always use batch operations instead of individual commands
\`\`\`
# GOOD: Create all directories at once
mkdir memory-bank docs docs\archive
# BAD: Create directories one at a time
mkdir memory-bank
mkdir docs
mkdir docs\archive
\`\`\`
2. **Pre-Check Optimization**: Check all requirements first, then create only what's missing
\`\`\`
# First check what's missing
$missingItems = ...
# Then create only what's missing
if ($missingItems) { ... }
\`\`\`
3. **Error Handling**: Include error handling in all commands
\`\`\`
mkdir memory-bank, docs, docs\archive -ErrorAction SilentlyContinue
\`\`\`
4. **Platform Adaptation**: Auto-detect platform and use appropriate commands
\`\`\`
if ($IsWindows) {
# Windows commands
} else {
# Unix commands
}
\`\`\`
5. **One-Pass Verification**: Verify directory structure in a single pass
\`\`\`
$requiredPaths = @("memory-bank", "docs", "docs\archive", ".cursorrules", "tasks.md")
$missingPaths = $requiredPaths | Where-Object { -not (Test-Path $_) }
\`\`\`
## 📝 VERIFICATION REPORT FORMAT
\`\`\`
✅ VERIFICATION COMPLETE
- Created directories: [list]
- Created files: [list]
- All components verified
Memory Bank system ready for use.
\`\`\`
```
## /.cursor/rules/isolation_rules/Core/platform-awareness.mdc
```mdc path="/.cursor/rules/isolation_rules/Core/platform-awareness.mdc"
---
description: Platform detection and command adaptation for isolation-focused Memory Bank
globs: platform-awareness.mdc
alwaysApply: false
---
# PLATFORM AWARENESS SYSTEM
> **TL;DR:** This system detects the operating system, path format, and shell environment, then adapts commands accordingly to ensure cross-platform compatibility.
## 🔍 PLATFORM DETECTION PROCESS
\`\`\`mermaid
graph TD
Start["Start Platform Detection"] --> DetectOS["Detect OS Environment"]
DetectOS --> Windows["Windows Detection"]
DetectOS --> Mac["macOS Detection"]
DetectOS --> Linux["Linux Detection"]
Windows & Mac & Linux --> PathCheck["Path Separator Detection"]
PathCheck --> CmdAdapt["Command Adaptation"]
CmdAdapt --> ShellCheck["Shell Type Detection"]
ShellCheck --> Complete["Platform Detection Complete"]
\`\`\`
## 📋 PLATFORM DETECTION IMPLEMENTATION
For reliable platform detection:
\`\`\`
## Platform Detection Results
Operating System: [Windows/macOS/Linux]
Path Separator: [\ or /]
Shell Environment: [PowerShell/Bash/Zsh/Cmd]
Command Adaptation: [Required/Not Required]
Adapting commands for [detected platform]...
\`\`\`
## 🔍 PATH FORMAT CONVERSION
When converting paths between formats:
\`\`\`mermaid
sequenceDiagram
participant Input as Path Input
participant Detector as Format Detector
participant Converter as Format Converter
participant Output as Adapted Path
Input->>Detector: Raw Path
Detector->>Detector: Detect Current Format
Detector->>Converter: Path + Current Format
Converter->>Converter: Apply Target Format
Converter->>Output: Platform-Specific Path
\`\`\`
## 📝 PLATFORM VERIFICATION CHECKLIST
\`\`\`
✓ PLATFORM VERIFICATION
- Operating system correctly identified? [YES/NO]
- Path separator format detected? [YES/NO]
- Shell environment identified? [YES/NO]
- Command set adapted appropriately? [YES/NO]
- Path format handling configured? [YES/NO]
→ If all YES: Platform adaptation complete
→ If any NO: Run additional detection steps
\`\`\`
```
## /.cursor/rules/isolation_rules/Level3/planning-comprehensive.mdc
```mdc path="/.cursor/rules/isolation_rules/Level3/planning-comprehensive.mdc"
---
description: planning comprehensive
globs: planning-comprehensive.mdc
alwaysApply: false
---
# LEVEL 3 COMPREHENSIVE PLANNING
> **TL;DR:** This document provides structured planning guidelines for Level 3 (Intermediate Feature) tasks, focusing on comprehensive planning with creative phases and clear implementation strategies.
## 🏗️ PLANNING WORKFLOW
\`\`\`mermaid
graph TD
Start["Planning Start"] --> Req["📋 Requirements Analysis"]
Req --> Comp["🔍 Component Analysis"]
Comp --> Design["🎨 Design Decisions"]
Design --> Impl["⚙️ Implementation Strategy"]
Impl --> Test["🧪 Testing Strategy"]
Test --> Doc["📚 Documentation Plan"]
Design --> Creative["Creative Phases:"]
Creative --> UI["UI/UX Design"]
Creative --> Arch["Architecture"]
Creative --> Algo["Algorithm"]
style Start fill:#4da6ff,stroke:#0066cc,color:white
style Req fill:#ffa64d,stroke:#cc7a30,color:white
style Comp fill:#4dbb5f,stroke:#36873f,color:white
style Design fill:#d94dbb,stroke:#a3378a,color:white
style Impl fill:#4dbbbb,stroke:#368787,color:white
style Test fill:#d971ff,stroke:#a33bc2,color:white
style Doc fill:#ff71c2,stroke:#c23b8a,color:white
\`\`\`
## 📋 PLANNING TEMPLATE
\`\`\`markdown
# Feature Planning Document
## Requirements Analysis
- Core Requirements:
- [ ] Requirement 1
- [ ] Requirement 2
- Technical Constraints:
- [ ] Constraint 1
- [ ] Constraint 2
## Component Analysis
- Affected Components:
- Component 1
- Changes needed:
- Dependencies:
- Component 2
- Changes needed:
- Dependencies:
## Design Decisions
- Architecture:
- [ ] Decision 1
- [ ] Decision 2
- UI/UX:
- [ ] Design 1
- [ ] Design 2
- Algorithms:
- [ ] Algorithm 1
- [ ] Algorithm 2
## Implementation Strategy
1. Phase 1:
- [ ] Task 1
- [ ] Task 2
2. Phase 2:
- [ ] Task 3
- [ ] Task 4
## Testing Strategy
- Unit Tests:
- [ ] Test 1
- [ ] Test 2
- Integration Tests:
- [ ] Test 3
- [ ] Test 4
## Documentation Plan
- [ ] API Documentation
- [ ] User Guide Updates
- [ ] Architecture Documentation
\`\`\`
## 🎨 CREATIVE PHASE IDENTIFICATION
\`\`\`mermaid
graph TD
subgraph "CREATIVE PHASES REQUIRED"
UI["🎨 UI/UX Design Required: Yes/No"]
Arch["🏗️ Architecture Design Required: Yes/No"]
Algo["⚙️ Algorithm Design Required: Yes/No"]
end
UI --> UITrig["Triggers: - New UI Component - UX Flow Change"]
Arch --> ArchTrig["Triggers: - System Structure Change - New Integration"]
Algo --> AlgoTrig["Triggers: - Performance Critical - Complex Logic"]
style UI fill:#4dbb5f,stroke:#36873f,color:white
style Arch fill:#ffa64d,stroke:#cc7a30,color:white
style Algo fill:#d94dbb,stroke:#a3378a,color:white
\`\`\`
## ✅ VERIFICATION CHECKLIST
\`\`\`mermaid
graph TD
subgraph "PLANNING VERIFICATION"
R["Requirements Complete"]
C["Components Identified"]
D["Design Decisions Made"]
I["Implementation Plan Ready"]
T["Testing Strategy Defined"]
Doc["Documentation Plan Ready"]
end
R --> C --> D --> I --> T --> Doc
style R fill:#4dbb5f,stroke:#36873f,color:white
style C fill:#ffa64d,stroke:#cc7a30,color:white
style D fill:#d94dbb,stroke:#a3378a,color:white
style I fill:#4dbbbb,stroke:#368787,color:white
style T fill:#d971ff,stroke:#a33bc2,color:white
style Doc fill:#ff71c2,stroke:#c23b8a,color:white
\`\`\`
## 🔄 IMPLEMENTATION PHASES
\`\`\`mermaid
graph LR
Setup["🛠️ Setup"] --> Core["⚙️ Core Implementation"]
Core --> UI["🎨 UI Implementation"]
UI --> Test["🧪 Testing"]
Test --> Doc["📚 Documentation"]
style Setup fill:#4da6ff,stroke:#0066cc,color:white
style Core fill:#4dbb5f,stroke:#36873f,color:white
style UI fill:#ffa64d,stroke:#cc7a30,color:white
style Test fill:#d94dbb,stroke:#a3378a,color:white
style Doc fill:#4dbbbb,stroke:#368787,color:white
\`\`\`
## 📚 DOCUMENT MANAGEMENT
\`\`\`mermaid
graph TD
Current["Current Documents"] --> Active["Active: - planning-comprehensive.md - task-tracking-intermediate.md"]
Current --> Next["Next Document: - creative-phase-enforcement.md"]
style Current fill:#4da6ff,stroke:#0066cc,color:white
style Active fill:#4dbb5f,stroke:#36873f,color:white
style Next fill:#ffa64d,stroke:#cc7a30,color:white
\`\`\`
```
## /.cursor/rules/isolation_rules/Level3/task-tracking-intermediate.mdc
```mdc path="/.cursor/rules/isolation_rules/Level3/task-tracking-intermediate.mdc"
---
description: task tracking intermediate
globs: task-tracking-intermediate.mdc
alwaysApply: false
---
# LEVEL 3 INTERMEDIATE TASK TRACKING
> **TL;DR:** This document provides structured task tracking guidelines for Level 3 (Intermediate Feature) tasks, using visual tracking elements and clear checkpoints.
## 🔍 TASK TRACKING WORKFLOW
\`\`\`mermaid
graph TD
Start["Task Start"] --> Init["📋 Initialize Task Entry"]
Init --> Struct["🏗️ Create Task Structure"]
Struct --> Track["📊 Progress Tracking"]
Track --> Update["🔄 Regular Updates"]
Update --> Complete["✅ Task Completion"]
Struct --> Components["Components:"]
Components --> Req["Requirements"]
Components --> Steps["Implementation Steps"]
Components --> Creative["Creative Phase Markers"]
Components --> Check["Checkpoints"]
Track --> Status["Track Status:"]
Status --> InProg["🔄 In Progress"]
Status --> Block["⛔ Blocked"]
Status --> Done["✅ Complete"]
Status --> Skip["⏭️ Skipped"]
style Start fill:#4da6ff,stroke:#0066cc,color:white
style Init fill:#ffa64d,stroke:#cc7a30,color:white
style Struct fill:#4dbb5f,stroke:#36873f,color:white
style Track fill:#d94dbb,stroke:#a3378a,color:white
style Update fill:#4dbbbb,stroke:#368787,color:white
style Complete fill:#d971ff,stroke:#a33bc2,color:white
\`\`\`
## 📋 TASK ENTRY TEMPLATE
\`\`\`markdown
# [Task Title]
## Requirements
- [ ] Requirement 1
- [ ] Requirement 2
- [ ] Requirement 3
## Components Affected
- Component 1
- Component 2
- Component 3
## Implementation Steps
1. [ ] Step 1
2. [ ] Step 2
3. [ ] Step 3
## Creative Phases Required
- [ ] 🎨 UI/UX Design
- [ ] 🏗️ Architecture Design
- [ ] ⚙️ Algorithm Design
## Checkpoints
- [ ] Requirements verified
- [ ] Creative phases completed
- [ ] Implementation tested
- [ ] Documentation updated
## Current Status
- Phase: [Current Phase]
- Status: [In Progress/Blocked/Complete]
- Blockers: [If any]
\`\`\`
## 🔄 PROGRESS TRACKING VISUALIZATION
\`\`\`mermaid
graph TD
subgraph "TASK PROGRESS"
P1["✓ Requirements Defined"]
P2["✓ Components Identified"]
P3["→ Creative Phase In Progress"]
P4["□ Implementation"]
P5["□ Testing"]
P6["□ Documentation"]
end
style P1 fill:#4dbb5f,stroke:#36873f,color:white
style P2 fill:#4dbb5f,stroke:#36873f,color:white
style P3 fill:#ffa64d,stroke:#cc7a30,color:white
style P4 fill:#d94dbb,stroke:#a3378a,color:white
style P5 fill:#4dbbbb,stroke:#368787,color:white
style P6 fill:#d971ff,stroke:#a33bc2,color:white
\`\`\`
## ✅ UPDATE PROTOCOL
\`\`\`mermaid
sequenceDiagram
participant Task as Task Entry
participant Status as Status Update
participant Creative as Creative Phase
participant Implementation as Implementation
Task->>Status: Update Progress
Status->>Creative: Flag for Creative Phase
Creative->>Implementation: Complete Design
Implementation->>Status: Update Status
Status->>Task: Mark Complete
\`\`\`
## 🎯 CHECKPOINT VERIFICATION
| Phase | Verification Items | Status |
|-------|-------------------|--------|
| Requirements | All requirements documented | [ ] |
| Components | Affected components listed | [ ] |
| Creative | Design decisions documented | [ ] |
| Implementation | Code changes tracked | [ ] |
| Testing | Test results recorded | [ ] |
| Documentation | Updates completed | [ ] |
## 🔄 DOCUMENT MANAGEMENT
\`\`\`mermaid
graph TD
Current["Current Documents"] --> Active["Active: - task-tracking-intermediate.md - planning-comprehensive.md"]
Current --> Required["Required Next: - creative-phase-enforcement.md - implementation-phase-reference.md"]
style Current fill:#4da6ff,stroke:#0066cc,color:white
style Active fill:#4dbb5f,stroke:#36873f,color:white
style Required fill:#ffa64d,stroke:#cc7a30,color:white
\`\`\`
```
## /.cursor/rules/isolation_rules/Phases/CreativePhase/creative-phase-architecture.mdc
```mdc path="/.cursor/rules/isolation_rules/Phases/CreativePhase/creative-phase-architecture.mdc"
---
description: creative phase architecture
globs: creative-phase-architecture.md
alwaysApply: false
---
# CREATIVE PHASE: ARCHITECTURE DESIGN
> **TL;DR:** This document provides structured guidance for architectural design decisions during creative phases, ensuring comprehensive evaluation of options and clear documentation of architectural choices.
## 🏗️ ARCHITECTURE DESIGN WORKFLOW
\`\`\`mermaid
graph TD
Start["Architecture Design Start"] --> Req["1. Requirements Analysis"]
Req --> Comp["2. Component Identification"]
Comp --> Options["3. Architecture Options"]
Options --> Eval["4. Option Evaluation"]
Eval --> Decision["5. Decision & Documentation"]
Decision --> Valid["6. Validation & Verification"]
style Start fill:#4da6ff,stroke:#0066cc,color:white
style Req fill:#ffa64d,stroke:#cc7a30,color:white
style Comp fill:#4dbb5f,stroke:#36873f,color:white
style Options fill:#d94dbb,stroke:#a3378a,color:white
style Eval fill:#4dbbbb,stroke:#368787,color:white
style Decision fill:#d971ff,stroke:#a33bc2,color:white
style Valid fill:#ff71c2,stroke:#c23b8a,color:white
\`\`\`
## 📋 ARCHITECTURE DECISION TEMPLATE
\`\`\`markdown
# Architecture Decision Record
## Context
- System Requirements:
- [Requirement 1]
- [Requirement 2]
- Technical Constraints:
- [Constraint 1]
- [Constraint 2]
## Component Analysis
- Core Components:
- [Component 1]: [Purpose/Role]
- [Component 2]: [Purpose/Role]
- Interactions:
- [Interaction 1]
- [Interaction 2]
## Architecture Options
### Option 1: [Name]
- Description: [Brief description]
- Pros:
- [Pro 1]
- [Pro 2]
- Cons:
- [Con 1]
- [Con 2]
- Technical Fit: [High/Medium/Low]
- Complexity: [High/Medium/Low]
- Scalability: [High/Medium/Low]
### Option 2: [Name]
[Same structure as Option 1]
## Decision
- Chosen Option: [Option name]
- Rationale: [Explanation]
- Implementation Considerations:
- [Consideration 1]
- [Consideration 2]
## Validation
- Requirements Met:
- [✓] Requirement 1
- [✓] Requirement 2
- Technical Feasibility: [Assessment]
- Risk Assessment: [Evaluation]
\`\`\`
## 🎯 ARCHITECTURE EVALUATION CRITERIA
\`\`\`mermaid
graph TD
subgraph "EVALUATION CRITERIA"
C1["Scalability"]
C2["Maintainability"]
C3["Performance"]
C4["Security"]
C5["Cost"]
C6["Time to Market"]
end
style C1 fill:#4dbb5f,stroke:#36873f,color:white
style C2 fill:#ffa64d,stroke:#cc7a30,color:white
style C3 fill:#d94dbb,stroke:#a3378a,color:white
style C4 fill:#4dbbbb,stroke:#368787,color:white
style C5 fill:#d971ff,stroke:#a33bc2,color:white
style C6 fill:#ff71c2,stroke:#c23b8a,color:white
\`\`\`
## 📊 ARCHITECTURE VISUALIZATION TEMPLATES
### Component Diagram Template
\`\`\`mermaid
graph TD
subgraph "SYSTEM ARCHITECTURE"
C1["Component 1"]
C2["Component 2"]
C3["Component 3"]
C1 -->|"Interface 1"| C2
C2 -->|"Interface 2"| C3
end
style C1 fill:#4dbb5f,stroke:#36873f,color:white
style C2 fill:#ffa64d,stroke:#cc7a30,color:white
style C3 fill:#d94dbb,stroke:#a3378a,color:white
\`\`\`
### Data Flow Template
\`\`\`mermaid
sequenceDiagram
participant C1 as Component 1
participant C2 as Component 2
participant C3 as Component 3
C1->>C2: Request
C2->>C3: Process
C3-->>C2: Response
C2-->>C1: Result
\`\`\`
## ✅ VERIFICATION CHECKLIST
\`\`\`markdown
## Architecture Design Verification
- [ ] All system requirements addressed
- [ ] Component responsibilities defined
- [ ] Interfaces specified
- [ ] Data flows documented
- [ ] Security considerations addressed
- [ ] Scalability requirements met
- [ ] Performance requirements met
- [ ] Maintenance approach defined
## Implementation Readiness
- [ ] All components identified
- [ ] Dependencies mapped
- [ ] Technical constraints documented
- [ ] Risk assessment completed
- [ ] Resource requirements defined
- [ ] Timeline estimates provided
\`\`\`
## 🔄 ARCHITECTURE REVIEW PROCESS
\`\`\`mermaid
graph TD
subgraph "REVIEW PROCESS"
R1["Technical Review"]
R2["Security Review"]
R3["Performance Review"]
R4["Final Approval"]
end
R1 --> R2 --> R3 --> R4
style R1 fill:#4dbb5f,stroke:#36873f,color:white
style R2 fill:#ffa64d,stroke:#cc7a30,color:white
style R3 fill:#d94dbb,stroke:#a3378a,color:white
style R4 fill:#4dbbbb,stroke:#368787,color:white
\`\`\`
## 🔄 DOCUMENT MANAGEMENT
\`\`\`mermaid
graph TD
Current["Current Document"] --> Active["Active: - creative-phase-architecture.md"]
Current --> Related["Related: - creative-phase-enforcement.md - planning-comprehensive.md"]
style Current fill:#4da6ff,stroke:#0066cc,color:white
style Active fill:#4dbb5f,stroke:#36873f,color:white
style Related fill:#ffa64d,stroke:#cc7a30,color:white
\`\`\`
```
## /.cursor/rules/isolation_rules/main.mdc
```mdc path="/.cursor/rules/isolation_rules/main.mdc"
---
description: main rule
globs: main.mdc
alwaysApply: false
---
# 🔍 ISOLATION-FOCUSED MEMORY BANK SYSTEM
> **TL;DR:** This system is designed to work with Cursor custom modes, where each mode loads only the rules it needs. The system uses visual Mermaid diagrams and selective document loading to optimize context usage.
## 🧭 MODE-SPECIFIC VISUAL MAPS
\`\`\`mermaid
graph TD
subgraph Modes["Cursor Custom Modes"]
VAN["VAN MODE Initialization"] --> PLAN["PLAN MODE Task Planning"]
PLAN --> Creative["CREATIVE MODE Design Decisions"]
Creative --> Implement["IMPLEMENT MODE Code Implementation"]
Implement --> Reflect["REFLECT MODE Task Review"]
Reflect --> Archive["ARCHIVE MODE Documentation"]
end
VAN -.->|"Loads"| VANRules["• main.md • platform-awareness.md • file-verification.md • workflow-init.md"]
PLAN -.->|"Loads"| PLANRules["• main.md • task-tracking.md • planning-process.md"]
Creative -.->|"Loads"| CreativeRules["• main.md • creative-phase.md • design-patterns.md"]
Implement -.->|"Loads"| ImplementRules["• main.md • command-execution.md • implementation-guide.md"]
Reflect -.->|"Loads"| ReflectRules["• main.md • reflection-format.md"]
Archive -.->|"Loads"| ArchiveRules["• main.md • archiving-guide.md"]
\`\`\`
## 📚 VISUAL PROCESS MAPS
Each mode has its own visual process map:
- [VAN Mode Map](mdc:visual-maps/van-mode-map.md)
- [PLAN Mode Map](mdc:visual-maps/plan-mode-map.md)
- [CREATIVE Mode Map](mdc:visual-maps/creative-mode-map.md)
- [IMPLEMENT Mode Map](mdc:visual-maps/implement-mode-map.md)
- [REFLECT Mode Map](mdc:visual-maps/reflect-mode-map.md)
- [ARCHIVE Mode Map](mdc:visual-maps/archive-mode-map.md)
## 🔄 FILE STATE VERIFICATION
In this isolation-focused approach, Memory Bank files maintain continuity between modes:
\`\`\`mermaid
graph TD
subgraph "Memory Bank Files"
tasks["tasks.md Source of Truth"]
active["activeContext.md Current Focus"]
creative["creative-*.md Design Decisions"]
progress["progress.md Implementation Status"]
end
VAN["VAN MODE"] -->|"Creates/Updates"| tasks
VAN -->|"Creates/Updates"| active
PLAN["PLAN MODE"] -->|"Reads"| tasks
PLAN -->|"Reads"| active
PLAN -->|"Updates"| tasks
Creative["CREATIVE MODE"] -->|"Reads"| tasks
Creative -->|"Creates"| creative
Creative -->|"Updates"| tasks
Implement["IMPLEMENT MODE"] -->|"Reads"| tasks
Implement -->|"Reads"| creative
Implement -->|"Updates"| tasks
Implement -->|"Updates"| progress
Reflect["REFLECT MODE"] -->|"Reads"| tasks
Reflect -->|"Reads"| progress
Reflect -->|"Updates"| tasks
Archive["ARCHIVE MODE"] -->|"Reads"| tasks
Archive -->|"Reads"| progress
Archive -->|"Archives"| creative
\`\`\`
## 📋 MODE TRANSITION PROTOCOL
\`\`\`mermaid
sequenceDiagram
participant User
participant CurrentMode
participant NextMode
CurrentMode->>CurrentMode: Complete Phase Requirements
CurrentMode->>User: "Phase complete. NEXT MODE: [mode name]"
User->>CurrentMode: End Current Mode
User->>NextMode: Start Next Mode
NextMode->>NextMode: Verify Required File State
alt File State Valid
NextMode->>User: "Continuing from previous mode..."
else File State Invalid
NextMode->>User: "Required files not in expected state"
NextMode->>User: "Return to [previous mode] to complete requirements"
end
\`\`\`
## 💻 PLATFORM-SPECIFIC COMMANDS
| Action | Windows | Mac/Linux |
|--------|---------|-----------|
| Create file | `echo. > file.ext` | `touch file.ext` |
| Create directory | `mkdir directory` | `mkdir -p directory` |
| Change directory | `cd directory` | `cd directory` |
| List files | `dir` | `ls` |
| Show file content | `type file.ext` | `cat file.ext` |
## ⚠️ COMMAND EFFICIENCY GUIDANCE
For optimal performance, use efficient command chaining when appropriate:
\`\`\`
# Efficient command chaining examples:
mkdir -p project/{src,tests,docs} && cd project
grep "TODO" $(find . -name "*.js")
npm install && npm start
\`\`\`
Refer to [command-execution.md](mdc:Core/command-execution.md) for detailed guidance.
```
## /.cursor/rules/isolation_rules/visual-maps/archive-mode-map.mdc
```mdc path="/.cursor/rules/isolation_rules/visual-maps/archive-mode-map.mdc"
---
description:
globs:
alwaysApply: false
---
---
description: Visual process map for ARCHIVE mode (Task Documentation)
globs: "**/archive*/**", "**/document*/**", "**/complete*/**"
alwaysApply: false
---
# ARCHIVE MODE: TASK DOCUMENTATION PROCESS MAP
> **TL;DR:** This visual map guides the ARCHIVE mode process, focusing on creating comprehensive documentation of the completed task, archiving relevant files, and updating the Memory Bank for future reference.
## 🧭 ARCHIVE MODE PROCESS FLOW
\`\`\`mermaid
graph TD
Start["START ARCHIVE MODE"] --> ReadTasks["Read tasks.md reflection.md and progress.md"]
%% Initial Assessment
ReadTasks --> VerifyReflect{"Reflection Complete?"}
VerifyReflect -->|"No"| ReturnReflect["Return to REFLECT Mode"]
VerifyReflect -->|"Yes"| AssessLevel{"Determine Complexity Level"}
%% Level-Based Archiving
AssessLevel -->|"Level 1"| L1Archive["LEVEL 1 ARCHIVING Level1/archive-minimal.md"]
AssessLevel -->|"Level 2"| L2Archive["LEVEL 2 ARCHIVING Level2/archive-basic.md"]
AssessLevel -->|"Level 3"| L3Archive["LEVEL 3 ARCHIVING Level3/archive-standard.md"]
AssessLevel -->|"Level 4"| L4Archive["LEVEL 4 ARCHIVING Level4/archive-comprehensive.md"]
%% Level 1 Archiving (Minimal)
L1Archive --> L1Summary["Create Quick Summary"]
L1Summary --> L1Task["Update tasks.md"]
L1Task --> L1Complete["Mark Task Complete"]
%% Level 2 Archiving (Basic)
L2Archive --> L2Summary["Create Basic Archive Document"]
L2Summary --> L2Doc["Document Changes"]
L2Doc --> L2Task["Update tasks.md"]
L2Task --> L2Progress["Update progress.md"]
L2Progress --> L2Complete["Mark Task Complete"]
%% Level 3-4 Archiving (Comprehensive)
L3Archive & L4Archive --> L34Summary["Create Comprehensive Archive Document"]
L34Summary --> L34Doc["Document Implementation"]
L34Doc --> L34Creative["Archive Creative Phase Documents"]
L34Creative --> L34Code["Document Code Changes"]
L34Code --> L34Test["Document Testing"]
L34Test --> L34Lessons["Summarize Lessons Learned"]
L34Lessons --> L34Task["Update tasks.md"]
L34Task --> L34Progress["Update progress.md"]
L34Progress --> L34System["Update System Documentation"]
L34System --> L34Complete["Mark Task Complete"]
%% Completion
L1Complete & L2Complete & L34Complete --> CreateArchive["Create Archive Document in docs/archive/"]
CreateArchive --> UpdateActive["Update activeContext.md"]
UpdateActive --> Reset["Reset for Next Task"]
\`\`\`
## 📋 ARCHIVE DOCUMENT STRUCTURE
The archive document should follow this structured format:
\`\`\`mermaid
graph TD
subgraph "Archive Document Structure"
Header["# TASK ARCHIVE: [Task Name]"]
Meta["## METADATA Task info, dates, complexity"]
Summary["## SUMMARY Brief overview of the task"]
Requirements["## REQUIREMENTS What the task needed to accomplish"]
Implementation["## IMPLEMENTATION How the task was implemented"]
Testing["## TESTING How the solution was verified"]
Lessons["## LESSONS LEARNED Key takeaways from the task"]
Refs["## REFERENCES Links to related documents"]
end
Header --> Meta --> Summary --> Requirements --> Implementation --> Testing --> Lessons --> Refs
\`\`\`
## 📊 REQUIRED FILE STATE VERIFICATION
Before archiving can begin, verify file state:
\`\`\`mermaid
graph TD
Start["File State Verification"] --> CheckTasks{"tasks.md has reflection complete?"}
CheckTasks -->|"No"| ErrorReflect["ERROR: Return to REFLECT Mode"]
CheckTasks -->|"Yes"| CheckReflection{"reflection.md exists?"}
CheckReflection -->|"No"| ErrorCreate["ERROR: Create reflection.md first"]
CheckReflection -->|"Yes"| CheckProgress{"progress.md updated?"}
CheckProgress -->|"No"| ErrorProgress["ERROR: Update progress.md first"]
CheckProgress -->|"Yes"| ReadyArchive["Ready for Archiving"]
\`\`\`
## 🔍 ARCHIVE TYPES BY COMPLEXITY
\`\`\`mermaid
graph TD
subgraph "Level 1: Minimal Archive"
L1A["Basic Bug Description"]
L1B["Solution Summary"]
L1C["Affected Files"]
end
subgraph "Level 2: Basic Archive"
L2A["Enhancement Description"]
L2B["Implementation Summary"]
L2C["Testing Results"]
L2D["Lessons Learned"]
end
subgraph "Level 3-4: Comprehensive Archive"
L3A["Detailed Requirements"]
L3B["Architecture/ Design Decisions"]
L3C["Implementation Details"]
L3D["Testing Strategy"]
L3E["Performance Considerations"]
L3F["Future Enhancements"]
L3G["Cross-References to Other Systems"]
end
L1A --> L1B --> L1C
L2A --> L2B --> L2C --> L2D
L3A --> L3B --> L3C --> L3D --> L3E --> L3F --> L3G
\`\`\`
## 📝 ARCHIVE DOCUMENT TEMPLATES
### Level 1 (Minimal) Archive
\`\`\`
# Bug Fix Archive: [Bug Name]
## Date
[Date of fix]
## Summary
[Brief description of the bug and solution]
## Implementation
[Description of the fix implemented]
## Files Changed
- [File 1]
- [File 2]
\`\`\`
### Levels 2-4 (Comprehensive) Archive
\`\`\`
# Task Archive: [Task Name]
## Metadata
- **Complexity**: Level [2/3/4]
- **Type**: [Enhancement/Feature/System]
- **Date Completed**: [Date]
- **Related Tasks**: [Related task references]
## Summary
[Comprehensive summary of the task]
## Requirements
- [Requirement 1]
- [Requirement 2]
- [Requirement 3]
## Implementation
### Approach
[Description of implementation approach]
### Key Components
- [Component 1]: [Description]
- [Component 2]: [Description]
### Files Changed
- [File 1]: [Description of changes]
- [File 2]: [Description of changes]
## Testing
- [Test 1]: [Result]
- [Test 2]: [Result]
## Lessons Learned
- [Lesson 1]
- [Lesson 2]
- [Lesson 3]
## Future Considerations
- [Future enhancement 1]
- [Future enhancement 2]
## References
- [Link to reflection document]
- [Link to creative phase documents]
- [Other relevant references]
\`\`\`
## 📋 ARCHIVE LOCATION AND NAMING
Archive documents should be organized following this pattern:
\`\`\`mermaid
graph TD
subgraph "Archive Structure"
Root["docs/archive/"]
Tasks["tasks/"]
Features["features/"]
Systems["systems/"]
Root --> Tasks
Root --> Features
Root --> Systems
Tasks --> Bug["bug-fix-name-YYYYMMDD.md"]
Tasks --> Enhancement["enhancement-name-YYYYMMDD.md"]
Features --> Feature["feature-name-YYYYMMDD.md"]
Systems --> System["system-name-YYYYMMDD.md"]
end
\`\`\`
## 📊 TASKS.MD FINAL UPDATE
When archiving is complete, update tasks.md with:
\`\`\`
## Status
- [x] Initialization complete
- [x] Planning complete
[For Level 3-4:]
- [x] Creative phases complete
- [x] Implementation complete
- [x] Reflection complete
- [x] Archiving complete
## Archive
- **Date**: [Completion date]
- **Archive Document**: [Link to archive document]
- **Status**: COMPLETED
\`\`\`
## 📋 ARCHIVE VERIFICATION CHECKLIST
\`\`\`
✓ ARCHIVE VERIFICATION
- Reflection document reviewed? [YES/NO]
- Archive document created with all sections? [YES/NO]
- Archive document placed in correct location? [YES/NO]
- tasks.md marked as completed? [YES/NO]
- progress.md updated with archive reference? [YES/NO]
- activeContext.md updated for next task? [YES/NO]
- Creative phase documents archived (Level 3-4)? [YES/NO/NA]
→ If all YES: Archiving complete - Memory Bank reset for next task
→ If any NO: Complete missing archive elements
\`\`\`
## 🔄 TASK COMPLETION NOTIFICATION
When archiving is complete, notify user with:
\`\`\`
## TASK ARCHIVED
✅ Archive document created in docs/archive/
✅ All task documentation preserved
✅ Memory Bank updated with references
✅ Task marked as COMPLETED
→ Memory Bank is ready for the next task
→ To start a new task, use VAN MODE
\`\`\`
```
## /.cursor/rules/isolation_rules/visual-maps/creative-mode-map.mdc
```mdc path="/.cursor/rules/isolation_rules/visual-maps/creative-mode-map.mdc"
---
description: Visual process map for CREATIVE mode (Design Decisions)
globs: "**/creative*/**", "**/design*/**", "**/decision*/**"
alwaysApply: false
---
# CREATIVE MODE: DESIGN PROCESS MAP
> **TL;DR:** This visual map guides the CREATIVE mode process, focusing on structured design decision-making for components that require deeper exploration before implementation.
## 🧭 CREATIVE MODE PROCESS FLOW
\`\`\`mermaid
graph TD
Start["START CREATIVE MODE"] --> ReadTasks["Read tasks.md For Creative Requirements"]
%% Initial Assessment
ReadTasks --> VerifyPlan{"Plan Complete & Creative Phases Identified?"}
VerifyPlan -->|"No"| ReturnPlan["Return to PLAN Mode"]
VerifyPlan -->|"Yes"| IdentifyPhases["Identify Creative Phases Required"]
%% Creative Phase Selection
IdentifyPhases --> SelectPhase["Select Next Creative Phase"]
SelectPhase --> PhaseType{"Creative Phase Type?"}
%% Creative Phase Types
PhaseType -->|"UI/UX Design"| UIPhase["UI/UX CREATIVE PHASE Core/creative-phase-uiux.md"]
PhaseType -->|"Architecture Design"| ArchPhase["ARCHITECTURE CREATIVE PHASE Core/creative-phase-architecture.md"]
PhaseType -->|"Data Model Design"| DataPhase["DATA MODEL CREATIVE PHASE Core/creative-phase-data.md"]
PhaseType -->|"Algorithm Design"| AlgoPhase["ALGORITHM CREATIVE PHASE Core/creative-phase-algorithm.md"]
%% UI/UX Creative Phase
UIPhase --> UI_Problem["Define UI/UX Problem"]
UI_Problem --> UI_Research["Research UI Patterns"]
UI_Research --> UI_Options["Explore UI Options"]
UI_Options --> UI_Evaluate["Evaluate User Experience"]
UI_Evaluate --> UI_Decision["Make Design Decision"]
UI_Decision --> UI_Document["Document UI Design"]
%% Architecture Creative Phase
ArchPhase --> Arch_Problem["Define Architecture Challenge"]
Arch_Problem --> Arch_Options["Explore Architecture Options"]
Arch_Options --> Arch_Analyze["Analyze Tradeoffs"]
Arch_Analyze --> Arch_Decision["Make Architecture Decision"]
Arch_Decision --> Arch_Document["Document Architecture"]
Arch_Document --> Arch_Diagram["Create Architecture Diagram"]
%% Data Model Creative Phase
DataPhase --> Data_Requirements["Define Data Requirements"]
Data_Requirements --> Data_Structure["Design Data Structure"]
Data_Structure --> Data_Relations["Define Relationships"]
Data_Relations --> Data_Validation["Design Validation"]
Data_Validation --> Data_Document["Document Data Model"]
%% Algorithm Creative Phase
AlgoPhase --> Algo_Problem["Define Algorithm Problem"]
Algo_Problem --> Algo_Options["Explore Algorithm Approaches"]
Algo_Options --> Algo_Evaluate["Evaluate Time/Space Complexity"]
Algo_Evaluate --> Algo_Decision["Make Algorithm Decision"]
Algo_Decision --> Algo_Document["Document Algorithm"]
%% Documentation & Completion
UI_Document & Arch_Diagram & Data_Document & Algo_Document --> CreateDoc["Create Creative Phase Document"]
CreateDoc --> UpdateTasks["Update tasks.md with Decision"]
UpdateTasks --> MorePhases{"More Creative Phases?"}
MorePhases -->|"Yes"| SelectPhase
MorePhases -->|"No"| VerifyComplete["Verify All Phases Complete"]
VerifyComplete --> NotifyComplete["Signal Creative Phases Complete"]
\`\`\`
## 📋 CREATIVE PHASE DOCUMENT FORMAT
Each creative phase should produce a document with this structure:
\`\`\`mermaid
graph TD
subgraph "Creative Phase Document"
Header["🎨 CREATIVE PHASE: [TYPE]"]
Problem["PROBLEM STATEMENT Clear definition of the problem"]
Options["OPTIONS ANALYSIS Multiple approaches considered"]
Pros["PROS & CONS Tradeoffs for each option"]
Decision["DECISION Selected approach + rationale"]
Impl["IMPLEMENTATION PLAN Steps to implement the decision"]
Diagram["VISUALIZATION Diagrams of the solution"]
end
Header --> Problem --> Options --> Pros --> Decision --> Impl --> Diagram
\`\`\`
## 🔍 CREATIVE TYPES AND APPROACHES
\`\`\`mermaid
graph TD
subgraph "UI/UX Design"
UI1["User Flow Analysis"]
UI2["Component Hierarchy"]
UI3["Interaction Patterns"]
UI4["Visual Design Principles"]
end
subgraph "Architecture Design"
A1["Component Structure"]
A2["Data Flow Patterns"]
A3["Interface Design"]
A4["System Integration"]
end
subgraph "Data Model Design"
D1["Entity Relationships"]
D2["Schema Design"]
D3["Validation Rules"]
D4["Query Optimization"]
end
subgraph "Algorithm Design"
AL1["Complexity Analysis"]
AL2["Efficiency Optimization"]
AL3["Edge Case Handling"]
AL4["Scaling Considerations"]
end
\`\`\`
## 📊 REQUIRED FILE STATE VERIFICATION
Before creative phase work can begin, verify file state:
\`\`\`mermaid
graph TD
Start["File State Verification"] --> CheckTasks{"tasks.md has planning complete?"}
CheckTasks -->|"No"| ErrorPlan["ERROR: Return to PLAN Mode"]
CheckTasks -->|"Yes"| CheckCreative{"Creative phases identified?"}
CheckCreative -->|"No"| ErrorCreative["ERROR: Return to PLAN Mode"]
CheckCreative -->|"Yes"| ReadyCreative["Ready for Creative Phase"]
\`\`\`
## 📋 OPTIONS ANALYSIS TEMPLATE
For each creative phase, analyze multiple options:
\`\`\`
## OPTIONS ANALYSIS
### Option 1: [Name]
**Description**: [Brief description]
**Pros**:
- [Pro 1]
- [Pro 2]
**Cons**:
- [Con 1]
- [Con 2]
**Complexity**: [Low/Medium/High]
**Implementation Time**: [Estimate]
### Option 2: [Name]
**Description**: [Brief description]
**Pros**:
- [Pro 1]
- [Pro 2]
**Cons**:
- [Con 1]
- [Con 2]
**Complexity**: [Low/Medium/High]
**Implementation Time**: [Estimate]
### Option 3: [Name]
**Description**: [Brief description]
**Pros**:
- [Pro 1]
- [Pro 2]
**Cons**:
- [Con 1]
- [Con 2]
**Complexity**: [Low/Medium/High]
**Implementation Time**: [Estimate]
\`\`\`
## 🎨 CREATIVE PHASE MARKERS
Use these visual markers for creative phases:
\`\`\`
🎨🎨🎨 ENTERING CREATIVE PHASE: [TYPE] 🎨🎨🎨
[Creative phase content]
🎨 CREATIVE CHECKPOINT: [Milestone]
[Additional content]
🎨🎨🎨 EXITING CREATIVE PHASE - DECISION MADE 🎨🎨🎨
\`\`\`
## 📊 CREATIVE PHASE VERIFICATION CHECKLIST
\`\`\`
✓ CREATIVE PHASE VERIFICATION
- Problem clearly defined? [YES/NO]
- Multiple options considered (3+)? [YES/NO]
- Pros/cons documented for each option? [YES/NO]
- Decision made with clear rationale? [YES/NO]
- Implementation plan included? [YES/NO]
- Visualization/diagrams created? [YES/NO]
- tasks.md updated with decision? [YES/NO]
→ If all YES: Creative phase complete
→ If any NO: Complete missing elements
\`\`\`
## 🔄 MODE TRANSITION NOTIFICATION
When all creative phases are complete, notify user with:
\`\`\`
## CREATIVE PHASES COMPLETE
✅ All required design decisions made
✅ Creative phase documents created
✅ tasks.md updated with decisions
✅ Implementation plan updated
→ NEXT RECOMMENDED MODE: IMPLEMENT MODE
\`\`\`
```
## /.cursor/rules/isolation_rules/visual-maps/implement-mode-map.mdc
```mdc path="/.cursor/rules/isolation_rules/visual-maps/implement-mode-map.mdc"
---
description: Visual process map for BUILD mode (Code Implementation)
globs: implementation-mode-map.mdc
alwaysApply: false
---
# BUILD MODE: CODE EXECUTION PROCESS MAP
> **TL;DR:** This visual map guides the BUILD mode process, focusing on efficient code implementation based on the planning and creative phases, with proper command execution and progress tracking.
## 🧭 BUILD MODE PROCESS FLOW
\`\`\`mermaid
graph TD
Start["START BUILD MODE"] --> ReadDocs["Read Reference Documents Core/command-execution.md"]
%% Initialization
ReadDocs --> CheckLevel{"Determine Complexity Level from tasks.md"}
%% Level 1 Implementation
CheckLevel -->|"Level 1 Quick Bug Fix"| L1Process["LEVEL 1 PROCESS Level1/quick-bug-workflow.md"]
L1Process --> L1Review["Review Bug Report"]
L1Review --> L1Examine["Examine Relevant Code"]
L1Examine --> L1Fix["Implement Targeted Fix"]
L1Fix --> L1Test["Test Fix"]
L1Test --> L1Update["Update tasks.md"]
%% Level 2 Implementation
CheckLevel -->|"Level 2 Simple Enhancement"| L2Process["LEVEL 2 PROCESS Level2/enhancement-workflow.md"]
L2Process --> L2Review["Review Build Plan"]
L2Review --> L2Examine["Examine Relevant Code Areas"]
L2Examine --> L2Implement["Implement Changes Sequentially"]
L2Implement --> L2Test["Test Changes"]
L2Test --> L2Update["Update tasks.md"]
%% Level 3-4 Implementation
CheckLevel -->|"Level 3-4 Feature/System"| L34Process["LEVEL 3-4 PROCESS Level3/feature-workflow.md Level4/system-workflow.md"]
L34Process --> L34Review["Review Plan & Creative Decisions"]
L34Review --> L34Phase{"Creative Phase Documents Complete?"}
L34Phase -->|"No"| L34Error["ERROR: Return to CREATIVE Mode"]
L34Phase -->|"Yes"| L34DirSetup["Create Directory Structure"]
L34DirSetup --> L34VerifyDirs["VERIFY Directories Created Successfully"]
L34VerifyDirs --> L34Implementation["Build Phase"]
%% Implementation Phases
L34Implementation --> L34Phase1["Phase 1 Build"]
L34Phase1 --> L34VerifyFiles["VERIFY Files Created Successfully"]
L34VerifyFiles --> L34Test1["Test Phase 1"]
L34Test1 --> L34Document1["Document Phase 1"]
L34Document1 --> L34Next1{"Next Phase?"}
L34Next1 -->|"Yes"| L34Implementation
L34Next1 -->|"No"| L34Integration["Integration Testing"]
L34Integration --> L34Document["Document Integration Points"]
L34Document --> L34Update["Update tasks.md"]
%% Command Execution
L1Fix & L2Implement & L34Phase1 --> CommandExec["COMMAND EXECUTION Core/command-execution.md"]
CommandExec --> DocCommands["Document Commands & Results"]
%% Completion & Transition
L1Update & L2Update & L34Update --> VerifyComplete["Verify Build Complete"]
VerifyComplete --> UpdateProgress["Update progress.md with Status"]
UpdateProgress --> Transition["NEXT MODE: REFLECT MODE"]
\`\`\`
## 📋 REQUIRED FILE STATE VERIFICATION
Before implementation can begin, verify file state:
\`\`\`mermaid
graph TD
Start["File State Verification"] --> CheckTasks{"tasks.md has planning complete?"}
CheckTasks -->|"No"| ErrorPlan["ERROR: Return to PLAN Mode"]
CheckTasks -->|"Yes"| CheckLevel{"Task Complexity?"}
CheckLevel -->|"Level 1"| L1Ready["Ready for Implementation"]
CheckLevel -->|"Level 2"| L2Ready["Ready for Implementation"]
CheckLevel -->|"Level 3-4"| CheckCreative{"Creative phases required?"}
CheckCreative -->|"No"| L34Ready["Ready for Implementation"]
CheckCreative -->|"Yes"| VerifyCreative{"Creative phases completed?"}
VerifyCreative -->|"No"| ErrorCreative["ERROR: Return to CREATIVE Mode"]
VerifyCreative -->|"Yes"| L34Ready
\`\`\`
## 🔄 FILE SYSTEM VERIFICATION PROCESS
\`\`\`mermaid
graph TD
Start["Start File Verification"] --> CheckDir["Check Directory Structure"]
CheckDir --> DirResult{"Directories Exist?"}
DirResult -->|"No"| ErrorDir["❌ ERROR: Missing Directories"]
DirResult -->|"Yes"| CheckFiles["Check Each Created File"]
ErrorDir --> FixDir["Fix Directory Structure"]
FixDir --> CheckDir
CheckFiles --> FileResult{"All Files Exist?"}
FileResult -->|"No"| ErrorFile["❌ ERROR: Missing/Wrong Path Files"]
FileResult -->|"Yes"| Complete["✅ Verification Complete"]
ErrorFile --> FixFile["Fix File Paths or Recreate Files"]
FixFile --> CheckFiles
\`\`\`
## 📋 DIRECTORY VERIFICATION STEPS
Before beginning any file creation:
\`\`\`
✓ DIRECTORY VERIFICATION PROCEDURE
1. Create all directories first before any files
2. Use ABSOLUTE paths: /full/path/to/directory
3. Verify each directory after creation:
ls -la /full/path/to/directory # Linux/Mac
dir "C:\full\path\to\directory" # Windows
4. Document directory structure in progress.md
5. Only proceed to file creation AFTER verifying ALL directories exist
\`\`\`
## 📋 FILE CREATION VERIFICATION
After creating files:
\`\`\`
✓ FILE VERIFICATION PROCEDURE
1. Use ABSOLUTE paths for all file operations: /full/path/to/file.ext
2. Verify each file creation was successful:
ls -la /full/path/to/file.ext # Linux/Mac
dir "C:\full\path\to\file.ext" # Windows
3. If verification fails:
a. Check for path resolution issues
b. Verify directory exists
c. Try creating with corrected path
d. Recheck file exists after correction
4. Document all file paths in progress.md
\`\`\`
## 🔄 COMMAND EXECUTION WORKFLOW
\`\`\`mermaid
graph TD
Start["Command Execution"] --> Analyze["Analyze Command Requirements"]
Analyze --> Complexity{"Command Complexity?"}
Complexity -->|"Simple"| Simple["Execute Single Command"]
Complexity -->|"Moderate"| Chain["Use Efficient Command Chaining"]
Complexity -->|"Complex"| Break["Break Into Logical Steps"]
Simple & Chain & Break --> Verify["Verify Results"]
Verify --> Document["Document Command & Result"]
Document --> Next["Next Command"]
\`\`\`
## 📋 LEVEL-SPECIFIC BUILD APPROACHES
\`\`\`mermaid
graph TD
subgraph "Level 1: Quick Bug Fix"
L1A["Targeted Code Examination"]
L1B["Minimal Change Scope"]
L1C["Direct Fix"]
L1D["Verify Fix"]
end
subgraph "Level 2: Enhancement"
L2A["Sequential Build"]
L2B["Contained Changes"]
L2C["Standard Testing"]
L2D["Component Documentation"]
end
subgraph "Level 3-4: Feature/System"
L3A["Directory Structure First"]
L3B["Verify Dirs Before Files"]
L3C["Phased Build"]
L3D["Verify Files After Creation"]
L3E["Integration Testing"]
L3F["Detailed Documentation"]
end
L1A --> L1B --> L1C --> L1D
L2A --> L2B --> L2C --> L2D
L3A --> L3B --> L3C --> L3D --> L3E --> L3F
\`\`\`
## 📝 BUILD DOCUMENTATION FORMAT
Document builds with:
\`\`\`
## Build: [Component/Feature]
### Approach
[Brief description of build approach]
### Directory Structure
- [/absolute/path/to/dir1/]: [Purpose]
- [/absolute/path/to/dir2/]: [Purpose]
### Code Changes
- [/absolute/path/to/file1.ext]: [Description of changes]
- [/absolute/path/to/file2.ext]: [Description of changes]
### Verification Steps
- [✓] Directory structure created and verified
- [✓] All files created in correct locations
- [✓] File content verified
### Commands Executed
\`\`\`
[Command 1]
[Result]
\`\`\`
\`\`\`
[Command 2]
[Result]
\`\`\`
### Testing
- [Test 1]: [Result]
- [Test 2]: [Result]
### Status
- [x] Build complete
- [x] Testing performed
- [x] File verification completed
- [ ] Documentation updated
\`\`\`
## 📊 TASKS.MD UPDATE FORMAT
During the build process, update tasks.md with progress:
\`\`\`
## Status
- [x] Initialization complete
- [x] Planning complete
[For Level 3-4:]
- [x] Creative phases complete
- [x] Directory structure created and verified
- [x] [Built component 1]
- [x] [Built component 2]
- [ ] [Remaining component]
## Build Progress
- [Component 1]: Complete
- Files: [/absolute/path/to/files]
- [Details about implementation]
- [Component 2]: Complete
- Files: [/absolute/path/to/files]
- [Details about implementation]
- [Component 3]: In Progress
- [Current status]
\`\`\`
## 📋 PROGRESS.MD UPDATE FORMAT
Update progress.md with:
\`\`\`
# Build Progress
## Directory Structure
- [/absolute/path/to/dir1/]: Created and verified
- [/absolute/path/to/dir2/]: Created and verified
## [Date]: [Component/Feature] Built
- **Files Created**:
- [/absolute/path/to/file1.ext]: Verified
- [/absolute/path/to/file2.ext]: Verified
- **Key Changes**:
- [Change 1]
- [Change 2]
- **Testing**: [Test results]
- **Next Steps**: [What comes next]
\`\`\`
## 📊 BUILD VERIFICATION CHECKLIST
\`\`\`
✓ BUILD VERIFICATION
- Directory structure created correctly? [YES/NO]
- All files created in correct locations? [YES/NO]
- All file paths verified with absolute paths? [YES/NO]
- All planned changes implemented? [YES/NO]
- Testing performed for all changes? [YES/NO]
- Code follows project standards? [YES/NO]
- Edge cases handled appropriately? [YES/NO]
- Build documented with absolute paths? [YES/NO]
- tasks.md updated with progress? [YES/NO]
- progress.md updated with details? [YES/NO]
→ If all YES: Build complete - ready for REFLECT mode
→ If any NO: Complete missing build elements
\`\`\`
## 🔄 MODE TRANSITION NOTIFICATION
When the build is complete, notify user with:
\`\`\`
## BUILD COMPLETE
✅ Directory structure verified
✅ All files created in correct locations
✅ All planned changes implemented
✅ Testing performed successfully
✅ tasks.md updated with status
✅ progress.md updated with details
→ NEXT RECOMMENDED MODE: REFLECT MODE
\`\`\`
```
## /.cursor/rules/isolation_rules/visual-maps/plan-mode-map.mdc
```mdc path="/.cursor/rules/isolation_rules/visual-maps/plan-mode-map.mdc"
# PLAN MODE: TASK PLANNING PROCESS MAP
> **TL;DR:** This visual map guides the PLAN mode process, focusing on creating detailed implementation plans based on the complexity level determined during initialization, with mandatory technology validation before implementation.
## 🧭 PLAN MODE PROCESS FLOW
\`\`\`mermaid
graph TD
Start["START PLANNING"] --> ReadTasks["Read tasks.md Core/task-tracking.md"]
%% Complexity Level Determination
ReadTasks --> CheckLevel{"Determine Complexity Level"}
CheckLevel -->|"Level 2"| Level2["LEVEL 2 PLANNING Level2/enhancement-planning.md"]
CheckLevel -->|"Level 3"| Level3["LEVEL 3 PLANNING Level3/feature-planning.md"]
CheckLevel -->|"Level 4"| Level4["LEVEL 4 PLANNING Level4/system-planning.md"]
%% Level 2 Planning
Level2 --> L2Review["Review Code Structure"]
L2Review --> L2Document["Document Planned Changes"]
L2Document --> L2Challenges["Identify Challenges"]
L2Challenges --> L2Checklist["Create Task Checklist"]
L2Checklist --> L2Update["Update tasks.md with Plan"]
L2Update --> L2Tech["TECHNOLOGY VALIDATION"]
L2Tech --> L2Verify["Verify Plan Completeness"]
%% Level 3 Planning
Level3 --> L3Review["Review Codebase Structure"]
L3Review --> L3Requirements["Document Detailed Requirements"]
L3Requirements --> L3Components["Identify Affected Components"]
L3Components --> L3Plan["Create Comprehensive Implementation Plan"]
L3Plan --> L3Challenges["Document Challenges & Solutions"]
L3Challenges --> L3Update["Update tasks.md with Plan"]
L3Update --> L3Tech["TECHNOLOGY VALIDATION"]
L3Tech --> L3Flag["Flag Components Requiring Creative"]
L3Flag --> L3Verify["Verify Plan Completeness"]
%% Level 4 Planning
Level4 --> L4Analysis["Codebase Structure Analysis"]
L4Analysis --> L4Requirements["Document Comprehensive Requirements"]
L4Requirements --> L4Diagrams["Create Architectural Diagrams"]
L4Diagrams --> L4Subsystems["Identify Affected Subsystems"]
L4Subsystems --> L4Dependencies["Document Dependencies & Integration Points"]
L4Dependencies --> L4Plan["Create Phased Implementation Plan"]
L4Plan --> L4Update["Update tasks.md with Plan"]
L4Update --> L4Tech["TECHNOLOGY VALIDATION"]
L4Tech --> L4Flag["Flag Components Requiring Creative"]
L4Flag --> L4Verify["Verify Plan Completeness"]
%% Technology Validation Gate - NEW
L2Tech & L3Tech & L4Tech --> TechGate["⛔ TECHNOLOGY VALIDATION GATE"]
TechGate --> TechSelection["Document Technology Stack Selection"]
TechSelection --> TechHelloWorld["Create Hello World Proof of Concept"]
TechHelloWorld --> TechDependencies["Verify Required Dependencies"]
TechDependencies --> TechConfig["Validate Build Configuration"]
TechConfig --> TechBuild["Complete Test Build"]
TechBuild --> TechVerify["⛔ TECHNOLOGY CHECKPOINT"]
%% Verification & Completion
L2Verify & L3Verify & L4Verify & TechVerify --> CheckCreative{"Creative Phases Required?"}
%% Mode Transition
CheckCreative -->|"Yes"| RecCreative["NEXT MODE: CREATIVE MODE"]
CheckCreative -->|"No"| RecImplement["NEXT MODE: IMPLEMENT MODE"]
%% Style for Technology Gate
style TechGate fill:#ff5555,stroke:#dd3333,color:white,stroke-width:3px
style TechVerify fill:#ff5555,stroke:#dd3333,color:white,stroke-width:3px
style TechSelection fill:#4da6ff,stroke:#0066cc,color:white
style TechHelloWorld fill:#4da6ff,stroke:#0066cc,color:white
style TechDependencies fill:#4da6ff,stroke:#0066cc,color:white
style TechConfig fill:#4da6ff,stroke:#0066cc,color:white
style TechBuild fill:#4da6ff,stroke:#0066cc,color:white
\`\`\`
## 📋 LEVEL-SPECIFIC PLANNING APPROACHES
\`\`\`mermaid
graph TD
subgraph "Level 2: Enhancement"
L2A["Basic Requirements Analysis"]
L2B["Simple Component Identification"]
L2C["Linear Implementation Plan"]
L2D["Basic Checklist Creation"]
end
subgraph "Level 3: Feature"
L3A["Detailed Requirements Analysis"]
L3B["Component Mapping with Dependencies"]
L3C["Multi-Phase Implementation Plan"]
L3D["Comprehensive Checklist"]
L3E["Creative Phase Identification"]
end
subgraph "Level 4: System"
L4A["Architectural Requirements Analysis"]
L4B["System Component Mapping"]
L4C["Subsystem Integration Plan"]
L4D["Phased Implementation Strategy"]
L4E["Risk Assessment & Mitigation"]
L4F["Multiple Creative Phase Requirements"]
end
L2A --> L2B --> L2C --> L2D
L3A --> L3B --> L3C --> L3D --> L3E
L4A --> L4B --> L4C --> L4D --> L4E --> L4F
\`\`\`
## 🔧 TECHNOLOGY VALIDATION WORKFLOW
\`\`\`mermaid
graph TD
Start["Technology Validation Start"] --> Select["Technology Stack Selection"]
Select --> Document["Document Chosen Technologies"]
Document --> POC["Create Minimal Proof of Concept"]
POC --> Build["Verify Build Process Works"]
Build --> Dependencies["Validate All Dependencies"]
Dependencies --> Config["Confirm Configuration Files Are Correct"]
Config --> Test["Complete Test Build/Run"]
Test --> Success{"All Checks Pass?"}
Success -->|"Yes"| Ready["Ready for Implementation"]
Success -->|"No"| Fix["Fix Technology Issues"]
Fix --> Document
style Start fill:#4da6ff,stroke:#0066cc,color:white
style POC fill:#4da6ff,stroke:#0066cc,color:white
style Success fill:#ff5555,stroke:#dd3333,color:white
style Fix fill:#ff5555,stroke:#dd3333,color:white
style Ready fill:#10b981,stroke:#059669,color:white
\`\`\`
## 📊 REQUIRED FILE STATE VERIFICATION
Before planning can begin, verify the file state:
\`\`\`mermaid
graph TD
Start["File State Verification"] --> CheckTasks{"tasks.md initialized?"}
CheckTasks -->|"No"| ErrorTasks["ERROR: Return to VAN Mode"]
CheckTasks -->|"Yes"| CheckActive{"activeContext.md exists?"}
CheckActive -->|"No"| ErrorActive["ERROR: Return to VAN Mode"]
CheckActive -->|"Yes"| ReadyPlan["Ready for Planning"]
\`\`\`
## 📝 TASKS.MD UPDATE FORMAT
During planning, update tasks.md with this structure:
\`\`\`
# Task: [Task name]
## Description
[Detailed description]
## Complexity
Level: [2/3/4]
Type: [Enhancement/Feature/Complex System]
## Technology Stack
- Framework: [Selected framework]
- Build Tool: [Selected build tool]
- Language: [Selected language]
- Storage: [Selected storage mechanism]
## Technology Validation Checkpoints
- [ ] Project initialization command verified
- [ ] Required dependencies identified and installed
- [ ] Build configuration validated
- [ ] Hello world verification completed
- [ ] Test build passes successfully
## Status
- [x] Initialization complete
- [x] Planning complete
- [ ] Technology validation complete
- [ ] [Implementation steps]
## Implementation Plan
1. [Step 1]
- [Subtask 1.1]
- [Subtask 1.2]
2. [Step 2]
- [Subtask 2.1]
- [Subtask 2.2]
## Creative Phases Required
- [ ] [Component 1] Design
- [ ] [Component 2] Architecture
- [ ] [Component 3] Data Model
## Dependencies
- [Dependency 1]
- [Dependency 2]
## Challenges & Mitigations
- [Challenge 1]: [Mitigation strategy]
- [Challenge 2]: [Mitigation strategy]
\`\`\`
## 📋 CREATIVE PHASE IDENTIFICATION
For Level 3-4 tasks, identify components requiring creative phases:
\`\`\`mermaid
graph TD
Start["Creative Phase Identification"] --> CheckComp{"Component Analysis"}
CheckComp --> UI["UI/UX Components"]
CheckComp --> Data["Data Model Components"]
CheckComp --> Arch["Architecture Components"]
CheckComp --> Algo["Algorithm Components"]
UI & Data & Arch & Algo --> Decision{"Design Decisions Required?"}
Decision -->|"Yes"| Flag["Flag for Creative Phase"]
Decision -->|"No"| Skip["Standard Implementation"]
Flag --> Document["Document in tasks.md"]
\`\`\`
## 📊 TECHNOLOGY VALIDATION CHECKLIST
\`\`\`
✓ TECHNOLOGY VALIDATION CHECKLIST
- Technology stack clearly defined? [YES/NO]
- Project initialization command documented? [YES/NO]
- Required dependencies identified? [YES/NO]
- Minimal proof of concept created? [YES/NO]
- Hello world build/run successful? [YES/NO]
- Configuration files validated? [YES/NO]
- Test build completes successfully? [YES/NO]
→ If all YES: Technology validation complete - ready for next phase
→ If any NO: Resolve technology issues before proceeding
\`\`\`
## 📊 PLAN VERIFICATION CHECKLIST
\`\`\`
✓ PLAN VERIFICATION CHECKLIST
- Requirements clearly documented? [YES/NO]
- Technology stack validated? [YES/NO]
- Affected components identified? [YES/NO]
- Implementation steps detailed? [YES/NO]
- Dependencies documented? [YES/NO]
- Challenges & mitigations addressed? [YES/NO]
- Creative phases identified (Level 3-4)? [YES/NO/NA]
- tasks.md updated with plan? [YES/NO]
→ If all YES: Planning complete - ready for next mode
→ If any NO: Complete missing plan elements
\`\`\`
## 🔄 MODE TRANSITION NOTIFICATION
When planning is complete, notify user with:
\`\`\`
## PLANNING COMPLETE
✅ Implementation plan created
✅ Technology stack validated
✅ tasks.md updated with plan
✅ Challenges and mitigations documented
[✅ Creative phases identified (for Level 3-4)]
→ NEXT RECOMMENDED MODE: [CREATIVE/IMPLEMENT] MODE
```
## /.cursor/rules/isolation_rules/visual-maps/qa-mode-map.mdc
```mdc path="/.cursor/rules/isolation_rules/visual-maps/qa-mode-map.mdc"
---
description: QA Mode
globs: qa-mode-map.mdc
alwaysApply: false
---
> **TL;DR:** This enhanced QA mode provides comprehensive validation at any stage of development. It automatically detects the current phase, validates Memory Bank consistency, verifies task tracking, and performs phase-specific technical validation to ensure project quality throughout the development lifecycle.
## 🔍 ENHANCED QA MODE PROCESS FLOW
\`\`\`mermaid
graph TD
Start["🚀 START QA MODE"] --> DetectPhase["🧭 PHASE DETECTION Determine current project phase"]
%% Phase detection decision path
DetectPhase --> PhaseDetermination{"Current Phase?"}
PhaseDetermination -->|"VAN"| VANChecks["VAN Phase Validation"]
PhaseDetermination -->|"PLAN"| PLANChecks["PLAN Phase Validation"]
PhaseDetermination -->|"CREATIVE"| CREATIVEChecks["CREATIVE Phase Validation"]
PhaseDetermination -->|"IMPLEMENT"| IMPLEMENTChecks["IMPLEMENT Phase Validation"]
%% Universal checks that apply to all phases
DetectPhase --> UniversalChecks["🔍 UNIVERSAL VALIDATION"]
UniversalChecks --> MemoryBankCheck["1️⃣ MEMORY BANK VERIFICATION Check consistency & updates"]
MemoryBankCheck --> TaskTrackingCheck["2️⃣ TASK TRACKING VERIFICATION Validate tasks.md as source of truth"]
TaskTrackingCheck --> ReferenceCheck["3️⃣ REFERENCE VALIDATION Verify cross-references between docs"]
%% Phase-specific validations feed into comprehensive report
VANChecks & PLANChecks & CREATIVEChecks & IMPLEMENTChecks --> PhaseSpecificResults["Phase-Specific Results"]
ReferenceCheck & PhaseSpecificResults --> ValidationResults{"✅ All Checks Passed?"}
%% Results Processing
ValidationResults -->|"Yes"| SuccessReport["📝 GENERATE SUCCESS REPORT All validations passed"]
ValidationResults -->|"No"| FailureReport["⚠️ GENERATE FAILURE REPORT With specific fix instructions"]
%% Success Path
SuccessReport --> UpdateMB["📚 Update Memory Bank Record successful validation"]
UpdateMB --> ContinueProcess["🚦 CONTINUE: Phase processes can proceed"]
%% Failure Path
FailureReport --> IdentifyFixes["🔧 IDENTIFY REQUIRED FIXES"]
IdentifyFixes --> ApplyFixes["🛠️ APPLY FIXES"]
ApplyFixes --> Revalidate["🔄 Re-run validation"]
Revalidate --> ValidationResults
%% Style nodes for clarity
style Start fill:#4da6ff,stroke:#0066cc,color:white
style DetectPhase fill:#f6ad55,stroke:#c27022,color:white
style UniversalChecks fill:#f6546a,stroke:#c30052,color:white
style MemoryBankCheck fill:#10b981,stroke:#059669,color:white
style TaskTrackingCheck fill:#10b981,stroke:#059669,color:white
style ReferenceCheck fill:#10b981,stroke:#059669,color:white
style ValidationResults fill:#f6546a,stroke:#c30052,color:white
style SuccessReport fill:#10b981,stroke:#059669,color:white
style FailureReport fill:#f6ad55,stroke:#c27022,color:white
style ContinueProcess fill:#10b981,stroke:#059669,color:white,stroke-width:2px
style IdentifyFixes fill:#f6ad55,stroke:#c27022,color:white
\`\`\`
## 🧭 PHASE DETECTION PROCESS
The enhanced QA mode first determines which phase the project is currently in:
\`\`\`mermaid
graph TD
PD["Phase Detection"] --> CheckMB["Analyze Memory Bank Files"]
CheckMB --> CheckActive["Check activeContext.md for current phase"]
CheckActive --> CheckProgress["Check progress.md for recent activities"]
CheckProgress --> CheckTasks["Check tasks.md for task status"]
CheckTasks --> PhaseResult{"Determine Current Phase"}
PhaseResult -->|"VAN"| VAN["VAN Phase Initialization"]
PhaseResult -->|"PLAN"| PLAN["PLAN Phase Task Planning"]
PhaseResult -->|"CREATIVE"| CREATIVE["CREATIVE Phase Design Decisions"]
PhaseResult -->|"IMPLEMENT"| IMPLEMENT["IMPLEMENT Phase Implementation"]
VAN & PLAN & CREATIVE & IMPLEMENT --> LoadChecks["Load Phase-Specific Validation Checks"]
style PD fill:#4da6ff,stroke:#0066cc,color:white
style PhaseResult fill:#f6546a,stroke:#c30052,color:white
style LoadChecks fill:#10b981,stroke:#059669,color:white
\`\`\`
## 📝 UNIVERSAL MEMORY BANK VERIFICATION
This process ensures Memory Bank files are consistent and up-to-date regardless of phase:
\`\`\`mermaid
graph TD
MBVS["Memory Bank Verification"] --> CoreCheck["Check Core Files Exist"]
CoreCheck --> CoreFiles["Verify Required Files: projectbrief.md activeContext.md tasks.md progress.md"]
CoreFiles --> ContentCheck["Verify Content Consistency"]
ContentCheck --> LastModified["Check Last Modified Timestamps"]
LastModified --> CrossRef["Validate Cross- References"]
CrossRef --> ConsistencyCheck{"All Files Consistent?"}
ConsistencyCheck -->|"Yes"| PassMB["✅ Memory Bank Verification Passed"]
ConsistencyCheck -->|"No"| FailMB["❌ Memory Bank Inconsistencies Found"]
FailMB --> FixSuggestions["Generate Fix Suggestions"]
style MBVS fill:#4da6ff,stroke:#0066cc,color:white
style ConsistencyCheck fill:#f6546a,stroke:#c30052,color:white
style PassMB fill:#10b981,stroke:#059669,color:white
style FailMB fill:#ff5555,stroke:#dd3333,color:white
\`\`\`
## 📋 TASK TRACKING VERIFICATION
This process validates tasks.md as the single source of truth:
\`\`\`mermaid
graph TD
TTV["Task Tracking Verification"] --> CheckTasksFile["Check tasks.md Existence & Format"]
CheckTasksFile --> VerifyReferences["Verify Task References in Other Documents"]
VerifyReferences --> ProgressCheck["Check Consistency with progress.md"]
ProgressCheck --> StatusCheck["Verify Task Status Accuracy"]
StatusCheck --> TaskConsistency{"Tasks Properly Tracked?"}
TaskConsistency -->|"Yes"| PassTasks["✅ Task Tracking Verification Passed"]
TaskConsistency -->|"No"| FailTasks["❌ Task Tracking Issues Found"]
FailTasks --> TaskFixSuggestions["Generate Task Tracking Fix Suggestions"]
style TTV fill:#4da6ff,stroke:#0066cc,color:white
style TaskConsistency fill:#f6546a,stroke:#c30052,color:white
style PassTasks fill:#10b981,stroke:#059669,color:white
style FailTasks fill:#ff5555,stroke:#dd3333,color:white
\`\`\`
## 🔄 REFERENCE VALIDATION PROCESS
This process ensures proper cross-referencing between documents:
\`\`\`mermaid
graph TD
RV["Reference Validation"] --> FindRefs["Find Cross-References in Documents"]
FindRefs --> VerifyRefs["Verify Reference Accuracy"]
VerifyRefs --> CheckBackRefs["Check Bidirectional References"]
CheckBackRefs --> RefConsistency{"References Consistent?"}
RefConsistency -->|"Yes"| PassRefs["✅ Reference Validation Passed"]
RefConsistency -->|"No"| FailRefs["❌ Reference Issues Found"]
FailRefs --> RefFixSuggestions["Generate Reference Fix Suggestions"]
style RV fill:#4da6ff,stroke:#0066cc,color:white
style RefConsistency fill:#f6546a,stroke:#c30052,color:white
style PassRefs fill:#10b981,stroke:#059669,color:white
style FailRefs fill:#ff5555,stroke:#dd3333,color:white
\`\`\`
## 🚨 PHASE-SPECIFIC VALIDATION PROCESSES
### VAN Phase Validation
\`\`\`mermaid
graph TD
VAN["VAN Phase Validation"] --> InitCheck["Check Initialization Completeness"]
InitCheck --> PlatformCheck["Verify Platform Detection"]
PlatformCheck --> ComplexityCheck["Validate Complexity Determination"]
ComplexityCheck --> VANConsistency{"VAN Phase Complete?"}
VANConsistency -->|"Yes"| PassVAN["✅ VAN Phase Validation Passed"]
VANConsistency -->|"No"| FailVAN["❌ VAN Phase Issues Found"]
style VAN fill:#4da6ff,stroke:#0066cc,color:white
style VANConsistency fill:#f6546a,stroke:#c30052,color:white
style PassVAN fill:#10b981,stroke:#059669,color:white
style FailVAN fill:#ff5555,stroke:#dd3333,color:white
\`\`\`
### PLAN Phase Validation
\`\`\`mermaid
graph TD
PLAN["PLAN Phase Validation"] --> PlanCheck["Check Planning Documentation"]
PlanCheck --> TaskBreakdown["Verify Task Breakdown"]
TaskBreakdown --> ScopeCheck["Validate Scope Definition"]
ScopeCheck --> PLANConsistency{"PLAN Phase Complete?"}
PLANConsistency -->|"Yes"| PassPLAN["✅ PLAN Phase Validation Passed"]
PLANConsistency -->|"No"| FailPLAN["❌ PLAN Phase Issues Found"]
style PLAN fill:#4da6ff,stroke:#0066cc,color:white
style PLANConsistency fill:#f6546a,stroke:#c30052,color:white
style PassPLAN fill:#10b981,stroke:#059669,color:white
style FailPLAN fill:#ff5555,stroke:#dd3333,color:white
\`\`\`
### CREATIVE Phase Validation
\`\`\`mermaid
graph TD
CREATIVE["CREATIVE Phase Validation"] --> DesignCheck["Check Design Documents"]
DesignCheck --> ArchCheck["Verify Architectural Decisions"]
ArchCheck --> PatternCheck["Validate Design Patterns"]
PatternCheck --> CREATIVEConsistency{"CREATIVE Phase Complete?"}
CREATIVEConsistency -->|"Yes"| PassCREATIVE["✅ CREATIVE Phase Validation Passed"]
CREATIVEConsistency -->|"No"| FailCREATIVE["❌ CREATIVE Phase Issues Found"]
style CREATIVE fill:#4da6ff,stroke:#0066cc,color:white
style CREATIVEConsistency fill:#f6546a,stroke:#c30052,color:white
style PassCREATIVE fill:#10b981,stroke:#059669,color:white
style FailCREATIVE fill:#ff5555,stroke:#dd3333,color:white
\`\`\`
### IMPLEMENT Phase Technical Validation
This retains the original QA validation from the previous version:
\`\`\`mermaid
graph TD
IMPLEMENT["IMPLEMENT Phase Validation"] --> ReadDesign["Read Design Decisions"]
ReadDesign --> FourChecks["Four-Point Technical Validation"]
FourChecks --> DepCheck["1️⃣ Dependency Verification"]
DepCheck --> ConfigCheck["2️⃣ Configuration Validation"]
ConfigCheck --> EnvCheck["3️⃣ Environment Validation"]
EnvCheck --> MinBuildCheck["4️⃣ Minimal Build Test"]
MinBuildCheck --> IMPLEMENTConsistency{"Technical Prerequisites Met?"}
IMPLEMENTConsistency -->|"Yes"| PassIMPLEMENT["✅ IMPLEMENT Phase Validation Passed"]
IMPLEMENTConsistency -->|"No"| FailIMPLEMENT["❌ IMPLEMENT Phase Issues Found"]
style IMPLEMENT fill:#4da6ff,stroke:#0066cc,color:white
style FourChecks fill:#f6546a,stroke:#c30052,color:white
style IMPLEMENTConsistency fill:#f6546a,stroke:#c30052,color:white
style PassIMPLEMENT fill:#10b981,stroke:#059669,color:white
style FailIMPLEMENT fill:#ff5555,stroke:#dd3333,color:white
\`\`\`
## 📋 UNIVERSAL VALIDATION COMMAND EXECUTION
### Memory Bank Verification Commands:
\`\`\`bash
# Check Memory Bank file existence and recency
ls -la memory-bank/
find memory-bank/ -type f -mtime -7 | sort
# Check for consistency between files
grep -r "task" memory-bank/
grep -r "requirement" memory-bank/
\`\`\`
### Task Tracking Verification Commands:
\`\`\`bash
# Verify tasks.md as source of truth
test -f tasks.md && echo "✅ tasks.md exists" || echo "❌ tasks.md missing"
# Check references to tasks in other files
grep -r "Task" --include="*.md" .
grep -r "task" --include="*.md" . | grep -v "tasks.md" | wc -l
# Verify task status consistency
grep -i "completed\|done\|finished" tasks.md
grep -i "in progress\|started" tasks.md
\`\`\`
### Reference Validation Commands:
\`\`\`bash
# Find cross-references between files
grep -r "see\|refer\|reference" --include="*.md" .
# Check for broken references
for file in $(grep -l "see\|refer\|reference" --include="*.md" .); do
for ref in $(grep -o '[a-zA-Z0-9_-]*\.md' $file); do
test -f $ref || echo "❌ Broken reference: $ref in $file"
done
done
\`\`\`
## 📋 1️⃣ DEPENDENCY VERIFICATION PROCESS (Original)
This validation point ensures all required packages are correctly installed.
### Command Execution:
\`\`\`bash
# Check if packages are installed
npm list react react-dom tailwindcss postcss autoprefixer
# Verify package versions match requirements
npm list | grep -E "react|tailwind|postcss"
# Check for peer dependency warnings
npm ls --depth=0
\`\`\`
### Validation Criteria:
- All required packages must be installed
- Versions must be compatible with requirements
- No critical peer dependency warnings
- Required dev dependencies must be present
### Common Fixes:
- `npm install [missing-package]` - Install missing packages
- `npm install [package]@[version]` - Fix version mismatches
- `npm install --save-dev [dev-dependency]` - Add development dependencies
## 📝 2️⃣ CONFIGURATION VALIDATION PROCESS (Original)
This validation point ensures configuration files are in the correct format for the project.
### Command Execution:
\`\`\`bash
# Check package.json for module type
grep "\"type\":" package.json
# Verify configuration file extensions match module type
find . -name "*.config.*" | grep -E "\.(js|cjs|mjs)$"
# Test configuration syntax
node -c *.config.js || node -c *.config.cjs || node -c *.config.mjs
\`\`\`
### Validation Criteria:
- Configuration file extensions must match module type in package.json
- File syntax must be valid
- Configuration must reference installed packages
### Common Fixes:
- Rename `.js` to `.cjs` for CommonJS in ES module projects
- Fix syntax errors in configuration files
- Adjust configuration to reference installed packages
## 🌐 3️⃣ ENVIRONMENT VALIDATION PROCESS (Original)
This validation point ensures the development environment is correctly set up.
### Command Execution:
\`\`\`bash
# Check build tools
npm run --help
# Verify node version compatibility
node -v
# Check for environment variables
printenv | grep -E "NODE_|PATH|HOME"
# Verify access permissions
ls -la .
\`\`\`
### Validation Criteria:
- Node.js version must be compatible with requirements
- Build commands must be defined in package.json
- Environment must have necessary access permissions
- Required environment variables must be set
### Common Fixes:
- Update Node.js version
- Add missing scripts to package.json
- Fix file permissions with chmod/icacls
- Set required environment variables
## 🔥 4️⃣ MINIMAL BUILD TEST PROCESS (Original)
This validation point tests a minimal build to ensure basic functionality works.
### Command Execution:
\`\`\`bash
# Run a minimal build
npm run build -- --dry-run || npm run dev -- --dry-run
# Test entry point file existence
find src -name "main.*" -o -name "index.*"
# Validate HTML entry point
grep -i "script.*src=" index.html
\`\`\`
### Validation Criteria:
- Build process must complete without errors
- Entry point files must exist and be correctly referenced
- HTML must reference the correct JavaScript entry point
- Basic rendering must work in a test environment
### Common Fixes:
- Fix entry point references in HTML
- Correct import paths in JavaScript
- Fix build configuration errors
- Update incorrect paths or references
## 📊 ENHANCED COMPREHENSIVE QA REPORT FORMAT
\`\`\`
╔═════════════════════════ 🔍 ENHANCED QA VALIDATION REPORT ═════════════════════╗
│ │
│ Project: [Project Name] Date: [Current Date] │
│ Platform: [OS Platform] Detected Phase: [Current Phase] │
│ │
│ ━━━━━━━━━━━━━━━━━━━━━━━━ UNIVERSAL VALIDATION RESULTS ━━━━━━━━━━━━━━━━━━━━━━━ │
│ │
│ 1️⃣ MEMORY BANK VERIFICATION │
│ ✓ Core Files: [Status] │
│ ✓ Content Consistency: [Status] │
│ ✓ Last Modified: [Status] │
│ │
│ 2️⃣ TASK TRACKING VERIFICATION │
│ ✓ tasks.md Status: [Status] │
│ ✓ Task References: [Status] │
│ ✓ Status Consistency: [Status] │
│ │
│ 3️⃣ REFERENCE VALIDATION │
│ ✓ Cross-References: [Status] │
│ ✓ Reference Accuracy: [Status] │
│ │
│ ━━━━━━━━━━━━━━━━━━━━━━━ PHASE-SPECIFIC VALIDATION ━━━━━━━━━━━━━━━━━━━━━━━━━━━ │
│ │
│ [VAN/PLAN/CREATIVE/IMPLEMENT] PHASE VALIDATION │
│ ✓ [Phase-specific check 1]: [Status] │
│ ✓ [Phase-specific check 2]: [Status] │
│ ✓ [Phase-specific check 3]: [Status] │
│ │
│ [Technical validation section shown only for IMPLEMENT phase] │
│ │
│ ━━━━━━━━━━━━━━━━━━━━━━━━━━━ OVERALL STATUS ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ │
│ │
│ ✅ VALIDATION PASSED - Project quality verified for current phase │
│ │
╚═══════════════════════════════════════════════════════════════════════════════╝
\`\`\`
## 🚫 ENHANCED FAILURE REPORT FORMAT
If validation fails, a detailed failure report is generated:
\`\`\`
╔═════════════════════════ ⚠️ QA VALIDATION FAILURES ═════════════════════════════╗
│ │
│ Project: [Project Name] Date: [Current Date] │
│ Platform: [OS Platform] Detected Phase: [Current Phase] │
│ │
│ ━━━━━━━━━━━━━━━━━━━━━━━━━━ FAILED CHECKS ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ │
│ │
│ ❌ MEMORY BANK ISSUES │
│ • [Specific issue details] │
│ • [Specific issue details] │
│ │
│ ❌ TASK TRACKING ISSUES │
│ • [Specific issue details] │
│ • [Specific issue details] │
│ │
│ ❌ REFERENCE ISSUES │
│ • [Specific issue details] │
│ • [Specific issue details] │
│ │
│ ❌ [PHASE]-SPECIFIC ISSUES │
│ • [Specific issue details] │
│ • [Specific issue details] │
│ │
│ ━━━━━━━━━━━━━━━━━━━━━━━━━━━ REQUIRED FIXES ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ │
│ │
│ 1. [Specific fix instruction with command] │
│ 2. [Specific fix instruction with command] │
│ 3. [Specific fix instruction with command] │
│ │
│ ⚠️ VALIDATION FAILED - Please resolve issues before proceeding │
│ │
╚═════════════════════════════════════════════════════════════════════════════════╝
\`\`\`
## 🔄 QA-ANYTIME ACTIVATION PROTOCOL
The enhanced QA mode can be activated at any time in the development process:
\`\`\`mermaid
graph TD
Start["User Types: QA"] --> DetectContext["Detect Current Context"]
DetectContext --> RunQA["Run QA with Context-Aware Checks"]
RunQA --> GenerateReport["Generate Appropriate QA Report"]
GenerateReport --> UserResponse["Present Report to User"]
UserResponse --> FixNeeded{"Fixes Needed?"}
FixNeeded -->|"Yes"| SuggestFixes["Display Fix Instructions"]
FixNeeded -->|"No"| ContinueWork["Continue Current Phase Work"]
style Start fill:#4da6ff,stroke:#0066cc,color:white
style FixNeeded fill:#f6546a,stroke:#c30052,color:white
style SuggestFixes fill:#ff5555,stroke:#dd3333,color:white
style ContinueWork fill:#10b981,stroke:#059669,color:white
\`\`\`
This enhanced QA mode serves as a "quality guardian" throughout the development process, ensuring documentation is consistently maintained and all phase requirements are met before proceeding to the next phase.
```
## /.cursor/rules/isolation_rules/visual-maps/reflect-mode-map.mdc
```mdc path="/.cursor/rules/isolation_rules/visual-maps/reflect-mode-map.mdc"
---
description:
globs:
alwaysApply: false
---
---
description: Visual process map for REFLECT mode (Task Reflection)
globs: "**/reflect*/**", "**/review*/**", "**/retrospect*/**"
alwaysApply: false
---
# REFLECT MODE: TASK REVIEW PROCESS MAP
> **TL;DR:** This visual map guides the REFLECT mode process, focusing on structured review of the implementation, documenting lessons learned, and preparing insights for future reference.
## 🧭 REFLECT MODE PROCESS FLOW
\`\`\`mermaid
graph TD
Start["START REFLECT MODE"] --> ReadTasks["Read tasks.md and progress.md"]
%% Initial Assessment
ReadTasks --> VerifyImplement{"Implementation Complete?"}
VerifyImplement -->|"No"| ReturnImplement["Return to IMPLEMENT Mode"]
VerifyImplement -->|"Yes"| AssessLevel{"Determine Complexity Level"}
%% Level-Based Reflection
AssessLevel -->|"Level 1"| L1Reflect["LEVEL 1 REFLECTION Level1/reflection-basic.md"]
AssessLevel -->|"Level 2"| L2Reflect["LEVEL 2 REFLECTION Level2/reflection-standard.md"]
AssessLevel -->|"Level 3"| L3Reflect["LEVEL 3 REFLECTION Level3/reflection-comprehensive.md"]
AssessLevel -->|"Level 4"| L4Reflect["LEVEL 4 REFLECTION Level4/reflection-advanced.md"]
%% Level 1 Reflection (Quick)
L1Reflect --> L1Review["Review Bug Fix"]
L1Review --> L1Document["Document Solution"]
L1Document --> L1Update["Update tasks.md"]
%% Level 2 Reflection (Standard)
L2Reflect --> L2Review["Review Enhancement"]
L2Review --> L2WWW["Document What Went Well"]
L2WWW --> L2Challenges["Document Challenges"]
L2Challenges --> L2Lessons["Document Lessons Learned"]
L2Lessons --> L2Update["Update tasks.md"]
%% Level 3-4 Reflection (Comprehensive)
L3Reflect & L4Reflect --> L34Review["Review Implementation & Creative Phases"]
L34Review --> L34Plan["Compare Against Original Plan"]
L34Plan --> L34WWW["Document What Went Well"]
L34WWW --> L34Challenges["Document Challenges"]
L34Challenges --> L34Lessons["Document Lessons Learned"]
L34Lessons --> L34ImproveProcess["Document Process Improvements"]
L34ImproveProcess --> L34Update["Update tasks.md"]
%% Completion & Transition
L1Update & L2Update & L34Update --> CreateReflection["Create reflection.md"]
CreateReflection --> UpdateSystem["Update System Documentation"]
UpdateSystem --> Transition["NEXT MODE: ARCHIVE MODE"]
\`\`\`
## 📋 REFLECTION STRUCTURE
The reflection should follow this structured format:
\`\`\`mermaid
graph TD
subgraph "Reflection Document Structure"
Header["# TASK REFLECTION: [Task Name]"]
Summary["## SUMMARY Brief summary of completed task"]
WWW["## WHAT WENT WELL Successful aspects of implementation"]
Challenges["## CHALLENGES Difficulties encountered during implementation"]
Lessons["## LESSONS LEARNED Key insights gained from the experience"]
ProcessImp["## PROCESS IMPROVEMENTS How to improve for future tasks"]
TechImp["## TECHNICAL IMPROVEMENTS Better approaches for similar tasks"]
NextSteps["## NEXT STEPS Follow-up actions or future work"]
end
Header --> Summary --> WWW --> Challenges --> Lessons --> ProcessImp --> TechImp --> NextSteps
\`\`\`
## 📊 REQUIRED FILE STATE VERIFICATION
Before reflection can begin, verify file state:
\`\`\`mermaid
graph TD
Start["File State Verification"] --> CheckTasks{"tasks.md has implementation complete?"}
CheckTasks -->|"No"| ErrorImplement["ERROR: Return to IMPLEMENT Mode"]
CheckTasks -->|"Yes"| CheckProgress{"progress.md has implementation details?"}
CheckProgress -->|"No"| ErrorProgress["ERROR: Update progress.md first"]
CheckProgress -->|"Yes"| ReadyReflect["Ready for Reflection"]
\`\`\`
## 🔍 IMPLEMENTATION REVIEW APPROACH
\`\`\`mermaid
graph TD
subgraph "Implementation Review"
Original["Review Original Requirements"]
Plan["Compare Against Implementation Plan"]
Actual["Assess Actual Implementation"]
Creative["Review Creative Phase Decisions"]
Changes["Identify Deviations from Plan"]
Results["Evaluate Results"]
end
Original --> Plan --> Actual
Plan --> Creative --> Changes
Actual --> Results
Changes --> Results
\`\`\`
## 📝 REFLECTION DOCUMENT TEMPLATES
### Level 1 (Basic) Reflection
\`\`\`
# Bug Fix Reflection: [Bug Name]
## Summary
[Brief description of the bug and solution]
## Implementation
[Description of the fix implemented]
## Testing
[Description of testing performed]
## Additional Notes
[Any other relevant information]
\`\`\`
### Levels 2-4 (Comprehensive) Reflection
\`\`\`
# Task Reflection: [Task Name]
## Summary
[Brief summary of the task and what was achieved]
## What Went Well
- [Success point 1]
- [Success point 2]
- [Success point 3]
## Challenges
- [Challenge 1]: [How it was addressed]
- [Challenge 2]: [How it was addressed]
- [Challenge 3]: [How it was addressed]
## Lessons Learned
- [Lesson 1]
- [Lesson 2]
- [Lesson 3]
## Process Improvements
- [Process improvement 1]
- [Process improvement 2]
## Technical Improvements
- [Technical improvement 1]
- [Technical improvement 2]
## Next Steps
- [Follow-up task 1]
- [Follow-up task 2]
\`\`\`
## 📊 REFLECTION QUALITY METRICS
\`\`\`mermaid
graph TD
subgraph "Reflection Quality Metrics"
Specific["Specific Not general or vague"]
Actionable["Actionable Provides clear direction"]
Honest["Honest Acknowledges successes and failures"]
Forward["Forward-Looking Focuses on future improvement"]
Evidence["Evidence-Based Based on concrete examples"]
end
\`\`\`
## 📋 TASKS.MD UPDATE FORMAT
During reflection, update tasks.md with:
\`\`\`
## Status
- [x] Initialization complete
- [x] Planning complete
[For Level 3-4:]
- [x] Creative phases complete
- [x] Implementation complete
- [x] Reflection complete
- [ ] Archiving
## Reflection Highlights
- **What Went Well**: [Key successes]
- **Challenges**: [Key challenges]
- **Lessons Learned**: [Key lessons]
- **Next Steps**: [Follow-up actions]
\`\`\`
## 📊 REFLECTION VERIFICATION CHECKLIST
\`\`\`
✓ REFLECTION VERIFICATION
- Implementation thoroughly reviewed? [YES/NO]
- What Went Well section completed? [YES/NO]
- Challenges section completed? [YES/NO]
- Lessons Learned section completed? [YES/NO]
- Process Improvements identified? [YES/NO]
- Technical Improvements identified? [YES/NO]
- Next Steps documented? [YES/NO]
- reflection.md created? [YES/NO]
- tasks.md updated with reflection status? [YES/NO]
→ If all YES: Reflection complete - ready for ARCHIVE mode
→ If any NO: Complete missing reflection elements
\`\`\`
## 🔄 MODE TRANSITION NOTIFICATION
When reflection is complete, notify user with:
\`\`\`
## REFLECTION COMPLETE
✅ Implementation thoroughly reviewed
✅ Reflection document created
✅ Lessons learned documented
✅ Process improvements identified
✅ tasks.md updated with reflection status
→ NEXT RECOMMENDED MODE: ARCHIVE MODE
\`\`\`
```
## /.cursor/rules/isolation_rules/visual-maps/van-mode-map.mdc
```mdc path="/.cursor/rules/isolation_rules/visual-maps/van-mode-map.mdc"
---
description: Visual process map for VAN mode (Initialization)
globs: van-mode-map.mdc
alwaysApply: false
---
# VAN MODE: INITIALIZATION PROCESS MAP
> **TL;DR:** This visual map defines the VAN mode process for project initialization, task analysis, and technical validation. It guides users through platform detection, file verification, complexity determination, and technical validation to ensure proper setup before implementation.
## 🧭 VAN MODE PROCESS FLOW
\`\`\`mermaid
graph TD
Start["START VAN MODE"] --> PlatformDetect["PLATFORM DETECTION"]
PlatformDetect --> DetectOS["Detect Operating System"]
DetectOS --> CheckPath["Check Path Separator Format"]
CheckPath --> AdaptCmds["Adapt Commands if Needed"]
AdaptCmds --> PlatformCP["⛔ PLATFORM CHECKPOINT"]
%% Basic File Verification with checkpoint
PlatformCP --> BasicFileVerify["BASIC FILE VERIFICATION"]
BasicFileVerify --> BatchCheck["Batch Check Essential Components"]
BatchCheck --> BatchCreate["Batch Create Essential Structure"]
BatchCreate --> BasicFileCP["⛔ BASIC FILE CHECKPOINT"]
%% Early Complexity Determination
BasicFileCP --> EarlyComplexity["EARLY COMPLEXITY DETERMINATION"]
EarlyComplexity --> AnalyzeTask["Analyze Task Requirements"]
AnalyzeTask --> EarlyLevelCheck{"Complexity Level?"}
%% Level handling paths
EarlyLevelCheck -->|"Level 1"| ComplexityCP["⛔ COMPLEXITY CHECKPOINT"]
EarlyLevelCheck -->|"Level 2-4"| CRITICALGATE["🚫 CRITICAL GATE: FORCE MODE SWITCH"]
CRITICALGATE --> ForceExit["Exit to PLAN mode"]
%% Level 1 continues normally
ComplexityCP --> InitSystem["INITIALIZE MEMORY BANK"]
InitSystem --> Complete1["LEVEL 1 INITIALIZATION COMPLETE"]
%% For Level 2+ tasks after PLAN and CREATIVE modes
ForceExit -.-> OtherModes["PLAN → CREATIVE modes"]
OtherModes -.-> VANQA["VAN QA MODE"]
VANQA --> QAProcess["Technical Validation Process"]
QAProcess --> QACheck{"All Checks Pass?"}
QACheck -->|"Yes"| BUILD["To BUILD MODE"]
QACheck -->|"No"| FixIssues["Fix Technical Issues"]
FixIssues --> QAProcess
%% Style nodes
style PlatformCP fill:#f55,stroke:#d44,color:white
style BasicFileCP fill:#f55,stroke:#d44,color:white
style ComplexityCP fill:#f55,stroke:#d44,color:white
style CRITICALGATE fill:#ff0000,stroke:#990000,color:white,stroke-width:3px
style ForceExit fill:#ff0000,stroke:#990000,color:white,stroke-width:2px
style VANQA fill:#4da6ff,stroke:#0066cc,color:white,stroke-width:3px
style QAProcess fill:#4da6ff,stroke:#0066cc,color:white
style QACheck fill:#4da6ff,stroke:#0066cc,color:white
style FixIssues fill:#ff5555,stroke:#dd3333,color:white
\`\`\`
## 🌐 PLATFORM DETECTION PROCESS
\`\`\`mermaid
graph TD
PD["Platform Detection"] --> CheckOS["Detect Operating System"]
CheckOS --> Win["Windows"]
CheckOS --> Mac["macOS"]
CheckOS --> Lin["Linux"]
Win & Mac & Lin --> Adapt["Adapt Commands for Platform"]
Win --> WinPath["Path: Backslash (\\)"]
Mac --> MacPath["Path: Forward Slash (/)"]
Lin --> LinPath["Path: Forward Slash (/)"]
Win --> WinCmd["Command Adaptations: dir, icacls, etc."]
Mac --> MacCmd["Command Adaptations: ls, chmod, etc."]
Lin --> LinCmd["Command Adaptations: ls, chmod, etc."]
WinPath & MacPath & LinPath --> PathCP["Path Separator Checkpoint"]
WinCmd & MacCmd & LinCmd --> CmdCP["Command Checkpoint"]
PathCP & CmdCP --> PlatformComplete["Platform Detection Complete"]
style PD fill:#4da6ff,stroke:#0066cc,color:white
style PlatformComplete fill:#10b981,stroke:#059669,color:white
\`\`\`
## 📁 FILE VERIFICATION PROCESS
\`\`\`mermaid
graph TD
FV["File Verification"] --> CheckFiles["Check Essential Files"]
CheckFiles --> CheckMB["Check Memory Bank Structure"]
CheckMB --> MBExists{"Memory Bank Exists?"}
MBExists -->|"Yes"| VerifyMB["Verify Memory Bank Contents"]
MBExists -->|"No"| CreateMB["Create Memory Bank Structure"]
CheckFiles --> CheckDocs["Check Documentation Files"]
CheckDocs --> DocsExist{"Docs Exist?"}
DocsExist -->|"Yes"| VerifyDocs["Verify Documentation Structure"]
DocsExist -->|"No"| CreateDocs["Create Documentation Structure"]
VerifyMB & CreateMB --> MBCP["Memory Bank Checkpoint"]
VerifyDocs & CreateDocs --> DocsCP["Documentation Checkpoint"]
MBCP & DocsCP --> FileComplete["File Verification Complete"]
style FV fill:#4da6ff,stroke:#0066cc,color:white
style FileComplete fill:#10b981,stroke:#059669,color:white
style MBCP fill:#f6546a,stroke:#c30052,color:white
style DocsCP fill:#f6546a,stroke:#c30052,color:white
\`\`\`
## 🧩 COMPLEXITY DETERMINATION PROCESS
\`\`\`mermaid
graph TD
CD["Complexity Determination"] --> AnalyzeTask["Analyze Task Requirements"]
AnalyzeTask --> CheckKeywords["Check Task Keywords"]
CheckKeywords --> ScopeCheck["Assess Scope Impact"]
ScopeCheck --> RiskCheck["Evaluate Risk Level"]
RiskCheck --> EffortCheck["Estimate Implementation Effort"]
EffortCheck --> DetermineLevel{"Determine Complexity Level"}
DetermineLevel -->|"Level 1"| L1["Level 1: Quick Bug Fix"]
DetermineLevel -->|"Level 2"| L2["Level 2: Simple Enhancement"]
DetermineLevel -->|"Level 3"| L3["Level 3: Intermediate Feature"]
DetermineLevel -->|"Level 4"| L4["Level 4: Complex System"]
L1 --> CDComplete["Complexity Determination Complete"]
L2 & L3 & L4 --> ModeSwitch["Force Mode Switch to PLAN"]
style CD fill:#4da6ff,stroke:#0066cc,color:white
style CDComplete fill:#10b981,stroke:#059669,color:white
style ModeSwitch fill:#ff0000,stroke:#990000,color:white
style DetermineLevel fill:#f6546a,stroke:#c30052,color:white
\`\`\`
## 🔄 COMPLETE WORKFLOW WITH QA VALIDATION
The full workflow includes technical validation before implementation:
\`\`\`mermaid
flowchart LR
VAN1["VAN MODE
(Initial Analysis)"] --> PLAN["PLAN MODE
(Task Planning)"]
PLAN --> CREATIVE["CREATIVE MODE
(Design Decisions)"]
CREATIVE --> VANQA["VAN QA MODE
(Technical Validation)"]
VANQA --> BUILD["BUILD MODE
(Implementation)"]
\`\`\`
## 🔍 TECHNICAL VALIDATION OVERVIEW
The VAN QA technical validation process consists of four key validation points:
\`\`\`mermaid
graph TD
VANQA["VAN QA MODE"] --> FourChecks["FOUR-POINT VALIDATION"]
FourChecks --> DepCheck["1️⃣ DEPENDENCY VERIFICATION Check all required packages"]
DepCheck --> ConfigCheck["2️⃣ CONFIGURATION VALIDATION Verify format & compatibility"]
ConfigCheck --> EnvCheck["3️⃣ ENVIRONMENT VALIDATION Check build environment"]
EnvCheck --> MinBuildCheck["4️⃣ MINIMAL BUILD TEST Test core functionality"]
MinBuildCheck --> ValidationResults{"All Checks Passed?"}
ValidationResults -->|"Yes"| SuccessReport["GENERATE SUCCESS REPORT"]
ValidationResults -->|"No"| FailureReport["GENERATE FAILURE REPORT"]
SuccessReport --> BUILD["Proceed to BUILD MODE"]
FailureReport --> FixIssues["Fix Technical Issues"]
FixIssues --> ReValidate["Re-validate"]
ReValidate --> ValidationResults
style VANQA fill:#4da6ff,stroke:#0066cc,color:white
style FourChecks fill:#f6546a,stroke:#c30052,color:white
style ValidationResults fill:#f6546a,stroke:#c30052,color:white
style BUILD fill:#10b981,stroke:#059669,color:white
style FixIssues fill:#ff5555,stroke:#dd3333,color:white
\`\`\`
## 📝 VALIDATION STATUS FORMAT
The QA Validation step includes clear status indicators:
\`\`\`
╔═════════════════ 🔍 QA VALIDATION STATUS ═════════════════╗
│ ✓ Design Decisions │ Verified as implementable │
│ ✓ Dependencies │ All required packages installed │
│ ✓ Configurations │ Format verified for platform │
│ ✓ Environment │ Suitable for implementation │
╚════════════════════════════════════════════════════════════╝
✅ VERIFIED - Clear to proceed to BUILD mode
\`\`\`
## 🚨 MODE TRANSITION TRIGGERS
### VAN to PLAN Transition
For complexity levels 2-4:
\`\`\`
🚫 LEVEL [2-4] TASK DETECTED
Implementation in VAN mode is BLOCKED
This task REQUIRES PLAN mode
You MUST switch to PLAN mode for proper documentation and planning
Type 'PLAN' to switch to planning mode
\`\`\`
### CREATIVE to VAN QA Transition
After completing the CREATIVE mode:
\`\`\`
⏭️ NEXT MODE: VAN QA
To validate technical requirements before implementation, please type 'VAN QA'
\`\`\`
### VAN QA to BUILD Transition
After successful validation:
\`\`\`
✅ TECHNICAL VALIDATION COMPLETE
All prerequisites verified successfully
You may now proceed to BUILD mode
Type 'BUILD' to begin implementation
\`\`\`
## 🔒 BUILD MODE PREVENTION MECHANISM
The system prevents moving to BUILD mode without passing QA validation:
\`\`\`mermaid
graph TD
Start["User Types: BUILD"] --> CheckQA{"QA Validation Completed?"}
CheckQA -->|"Yes and Passed"| AllowBuild["Allow BUILD Mode"]
CheckQA -->|"No or Failed"| BlockBuild["BLOCK BUILD MODE"]
BlockBuild --> Message["Display: ⚠️ QA VALIDATION REQUIRED"]
Message --> ReturnToVANQA["Prompt: Type VAN QA"]
style CheckQA fill:#f6546a,stroke:#c30052,color:white
style BlockBuild fill:#ff0000,stroke:#990000,color:white,stroke-width:3px
style Message fill:#ff5555,stroke:#dd3333,color:white
style ReturnToVANQA fill:#4da6ff,stroke:#0066cc,color:white
\`\`\`
## 🔄 QA COMMAND PRECEDENCE
QA validation can be called at any point in the process flow, and takes immediate precedence over any other current steps, including forced mode switches:
\`\`\`mermaid
graph TD
UserQA["User Types: QA"] --> HighPriority["⚠️ HIGH PRIORITY COMMAND"]
HighPriority --> CurrentTask["Pause Current Task/Process"]
CurrentTask --> LoadQA["Load QA Mode Map"]
LoadQA --> RunQA["Execute QA Validation Process"]
RunQA --> QAResults{"QA Results"}
QAResults -->|"PASS"| ResumeFlow["Resume Prior Process Flow"]
QAResults -->|"FAIL"| FixIssues["Fix Identified Issues"]
FixIssues --> ReRunQA["Re-run QA Validation"]
ReRunQA --> QAResults
style UserQA fill:#f8d486,stroke:#e8b84d,color:black
style HighPriority fill:#ff0000,stroke:#cc0000,color:white,stroke-width:3px
style LoadQA fill:#4da6ff,stroke:#0066cc,color:white
style RunQA fill:#4da6ff,stroke:#0066cc,color:white
style QAResults fill:#f6546a,stroke:#c30052,color:white
\`\`\`
### QA Interruption Rules
When a user types **QA** at any point:
1. **The QA command MUST take immediate precedence** over any current operation, including the "FORCE MODE SWITCH" triggered by complexity assessment.
2. The system MUST:
- Immediately load the QA mode map
- Execute the full QA validation process
- Address any failures before continuing
3. **Required remediation steps take priority** over any pending mode switches or complexity rules
4. After QA validation is complete and passes:
- Resume the previously determined process flow
- Continue with any required mode switches
\`\`\`
⚠️ QA OVERRIDE ACTIVATED
All other processes paused
QA validation checks now running...
Any issues found MUST be remediated before continuing with normal process flow
\`\`\`
## 📋 CHECKPOINT VERIFICATION TEMPLATE
Each major checkpoint in VAN mode uses this format:
\`\`\`
✓ SECTION CHECKPOINT: [SECTION NAME]
- Requirement 1? [YES/NO]
- Requirement 2? [YES/NO]
- Requirement 3? [YES/NO]
→ If all YES: Ready for next section
→ If any NO: Fix missing items before proceeding
\`\`\`
## 🚀 VAN MODE ACTIVATION
When the user types "VAN", respond with a confirmation and start the process:
\`\`\`
User: VAN
Response: OK VAN - Beginning Initialization Process
\`\`\`
After completing CREATIVE mode, when the user types "VAN QA", respond:
\`\`\`
User: VAN QA
Response: OK VAN QA - Beginning Technical Validation
\`\`\`
This ensures clear communication about which phase of VAN mode is active.
## 🔍 DETAILED QA VALIDATION PROCESS
### 1️⃣ DEPENDENCY VERIFICATION
This step verifies that all required packages are installed and compatible:
\`\`\`mermaid
graph TD
Start["Dependency Verification"] --> ReadDeps["Read Required Dependencies from Creative Phase"]
ReadDeps --> CheckInstalled["Check if Dependencies are Installed"]
CheckInstalled --> DepStatus{"All Dependencies Installed?"}
DepStatus -->|"Yes"| VerifyVersions["Verify Versions and Compatibility"]
DepStatus -->|"No"| InstallMissing["Install Missing Dependencies"]
InstallMissing --> VerifyVersions
VerifyVersions --> VersionStatus{"Versions Compatible?"}
VersionStatus -->|"Yes"| DepSuccess["Dependencies Verified ✅ PASS"]
VersionStatus -->|"No"| UpgradeVersions["Upgrade/Downgrade as Needed"]
UpgradeVersions --> RetryVerify["Retry Verification"]
RetryVerify --> VersionStatus
style Start fill:#4da6ff,stroke:#0066cc,color:white
style DepSuccess fill:#10b981,stroke:#059669,color:white
style DepStatus fill:#f6546a,stroke:#c30052,color:white
style VersionStatus fill:#f6546a,stroke:#c30052,color:white
\`\`\`
#### Windows (PowerShell) Implementation:
\`\`\`powershell
# Example: Verify Node.js dependencies for a React project
function Verify-Dependencies {
$requiredDeps = @{
"node" = ">=14.0.0"
"npm" = ">=6.0.0"
}
$missingDeps = @()
$incompatibleDeps = @()
# Check Node.js version
$nodeVersion = $null
try {
$nodeVersion = node -v
if ($nodeVersion -match "v(\d+)\.(\d+)\.(\d+)") {
$major = [int]$Matches[1]
if ($major -lt 14) {
$incompatibleDeps += "node (found $nodeVersion, required >=14.0.0)"
}
}
} catch {
$missingDeps += "node"
}
# Check npm version
$npmVersion = $null
try {
$npmVersion = npm -v
if ($npmVersion -match "(\d+)\.(\d+)\.(\d+)") {
$major = [int]$Matches[1]
if ($major -lt 6) {
$incompatibleDeps += "npm (found $npmVersion, required >=6.0.0)"
}
}
} catch {
$missingDeps += "npm"
}
# Display results
if ($missingDeps.Count -eq 0 -and $incompatibleDeps.Count -eq 0) {
Write-Output "✅ All dependencies verified and compatible"
return $true
} else {
if ($missingDeps.Count -gt 0) {
Write-Output "❌ Missing dependencies: $($missingDeps -join ', ')"
}
if ($incompatibleDeps.Count -gt 0) {
Write-Output "❌ Incompatible versions: $($incompatibleDeps -join ', ')"
}
return $false
}
}
\`\`\`
#### Mac/Linux (Bash) Implementation:
\`\`\`bash
#!/bin/bash
# Example: Verify Node.js dependencies for a React project
verify_dependencies() {
local missing_deps=()
local incompatible_deps=()
# Check Node.js version
if command -v node &> /dev/null; then
local node_version=$(node -v)
if [[ $node_version =~ v([0-9]+)\.([0-9]+)\.([0-9]+) ]]; then
local major=${BASH_REMATCH[1]}
if (( major < 14 )); then
incompatible_deps+=("node (found $node_version, required >=14.0.0)")
fi
fi
else
missing_deps+=("node")
fi
# Check npm version
if command -v npm &> /dev/null; then
local npm_version=$(npm -v)
if [[ $npm_version =~ ([0-9]+)\.([0-9]+)\.([0-9]+) ]]; then
local major=${BASH_REMATCH[1]}
if (( major < 6 )); then
incompatible_deps+=("npm (found $npm_version, required >=6.0.0)")
fi
fi
else
missing_deps+=("npm")
fi
# Display results
if [ ${#missing_deps[@]} -eq 0 ] && [ ${#incompatible_deps[@]} -eq 0 ]; then
echo "✅ All dependencies verified and compatible"
return 0
else
if [ ${#missing_deps[@]} -gt 0 ]; then
echo "❌ Missing dependencies: ${missing_deps[*]}"
fi
if [ ${#incompatible_deps[@]} -gt 0 ]; then
echo "❌ Incompatible versions: ${incompatible_deps[*]}"
fi
return 1
fi
}
\`\`\`
### 2️⃣ CONFIGURATION VALIDATION
This step validates configuration files format and compatibility:
\`\`\`mermaid
graph TD
Start["Configuration Validation"] --> IdentifyConfigs["Identify Configuration Files"]
IdentifyConfigs --> ReadConfigs["Read Configuration Files"]
ReadConfigs --> ValidateSyntax["Validate Syntax and Format"]
ValidateSyntax --> SyntaxStatus{"Syntax Valid?"}
SyntaxStatus -->|"Yes"| CheckCompatibility["Check Compatibility with Platform"]
SyntaxStatus -->|"No"| FixSyntax["Fix Syntax Errors"]
FixSyntax --> RetryValidate["Retry Validation"]
RetryValidate --> SyntaxStatus
CheckCompatibility --> CompatStatus{"Compatible with Platform?"}
CompatStatus -->|"Yes"| ConfigSuccess["Configurations Validated ✅ PASS"]
CompatStatus -->|"No"| AdaptConfigs["Adapt Configurations for Platform"]
AdaptConfigs --> RetryCompat["Retry Compatibility Check"]
RetryCompat --> CompatStatus
style Start fill:#4da6ff,stroke:#0066cc,color:white
style ConfigSuccess fill:#10b981,stroke:#059669,color:white
style SyntaxStatus fill:#f6546a,stroke:#c30052,color:white
style CompatStatus fill:#f6546a,stroke:#c30052,color:white
\`\`\`
#### Configuration Validation Implementation:
\`\`\`powershell
# Example: Validate configuration files for a web project
function Validate-Configurations {
$configFiles = @(
"package.json",
"tsconfig.json",
"vite.config.js"
)
$invalidConfigs = @()
$incompatibleConfigs = @()
foreach ($configFile in $configFiles) {
if (Test-Path $configFile) {
# Check JSON syntax for JSON files
if ($configFile -match "\.json$") {
try {
Get-Content $configFile -Raw | ConvertFrom-Json | Out-Null
} catch {
$invalidConfigs += "$configFile (JSON syntax error: $($_.Exception.Message))"
continue
}
}
# Specific configuration compatibility checks
if ($configFile -eq "vite.config.js") {
$content = Get-Content $configFile -Raw
# Check for React plugin in Vite config
if ($content -notmatch "react\(\)") {
$incompatibleConfigs += "$configFile (Missing React plugin for React project)"
}
}
} else {
$invalidConfigs += "$configFile (file not found)"
}
}
# Display results
if ($invalidConfigs.Count -eq 0 -and $incompatibleConfigs.Count -eq 0) {
Write-Output "✅ All configurations validated and compatible"
return $true
} else {
if ($invalidConfigs.Count -gt 0) {
Write-Output "❌ Invalid configurations: $($invalidConfigs -join ', ')"
}
if ($incompatibleConfigs.Count -gt 0) {
Write-Output "❌ Incompatible configurations: $($incompatibleConfigs -join ', ')"
}
return $false
}
}
\`\`\`
### 3️⃣ ENVIRONMENT VALIDATION
This step checks if the environment is properly set up for the implementation:
\`\`\`mermaid
graph TD
Start["Environment Validation"] --> CheckEnv["Check Build Environment"]
CheckEnv --> VerifyBuildTools["Verify Build Tools"]
VerifyBuildTools --> ToolsStatus{"Build Tools Available?"}
ToolsStatus -->|"Yes"| CheckPerms["Check Permissions and Access"]
ToolsStatus -->|"No"| InstallTools["Install Required Build Tools"]
InstallTools --> RetryTools["Retry Verification"]
RetryTools --> ToolsStatus
CheckPerms --> PermsStatus{"Permissions Sufficient?"}
PermsStatus -->|"Yes"| EnvSuccess["Environment Validated ✅ PASS"]
PermsStatus -->|"No"| FixPerms["Fix Permission Issues"]
FixPerms --> RetryPerms["Retry Permission Check"]
RetryPerms --> PermsStatus
style Start fill:#4da6ff,stroke:#0066cc,color:white
style EnvSuccess fill:#10b981,stroke:#059669,color:white
style ToolsStatus fill:#f6546a,stroke:#c30052,color:white
style PermsStatus fill:#f6546a,stroke:#c30052,color:white
\`\`\`
#### Environment Validation Implementation:
\`\`\`powershell
# Example: Validate environment for a web project
function Validate-Environment {
$requiredTools = @(
@{Name = "git"; Command = "git --version"},
@{Name = "node"; Command = "node --version"},
@{Name = "npm"; Command = "npm --version"}
)
$missingTools = @()
$permissionIssues = @()
# Check build tools
foreach ($tool in $requiredTools) {
try {
Invoke-Expression $tool.Command | Out-Null
} catch {
$missingTools += $tool.Name
}
}
# Check write permissions in project directory
try {
$testFile = ".__permission_test"
New-Item -Path $testFile -ItemType File -Force | Out-Null
Remove-Item -Path $testFile -Force
} catch {
$permissionIssues += "Current directory (write permission denied)"
}
# Check if port 3000 is available (commonly used for dev servers)
try {
$listener = New-Object System.Net.Sockets.TcpListener([System.Net.IPAddress]::Loopback, 3000)
$listener.Start()
$listener.Stop()
} catch {
$permissionIssues += "Port 3000 (already in use or access denied)"
}
# Display results
if ($missingTools.Count -eq 0 -and $permissionIssues.Count -eq 0) {
Write-Output "✅ Environment validated successfully"
return $true
} else {
if ($missingTools.Count -gt 0) {
Write-Output "❌ Missing tools: $($missingTools -join ', ')"
}
if ($permissionIssues.Count -gt 0) {
Write-Output "❌ Permission issues: $($permissionIssues -join ', ')"
}
return $false
}
}
\`\`\`
### 4️⃣ MINIMAL BUILD TEST
This step performs a minimal build test to ensure core functionality:
\`\`\`mermaid
graph TD
Start["Minimal Build Test"] --> CreateTest["Create Minimal Test Project"]
CreateTest --> BuildTest["Attempt Build"]
BuildTest --> BuildStatus{"Build Successful?"}
BuildStatus -->|"Yes"| RunTest["Run Basic Functionality Test"]
BuildStatus -->|"No"| FixBuild["Fix Build Issues"]
FixBuild --> RetryBuild["Retry Build"]
RetryBuild --> BuildStatus
RunTest --> TestStatus{"Test Passed?"}
TestStatus -->|"Yes"| TestSuccess["Minimal Build Test ✅ PASS"]
TestStatus -->|"No"| FixTest["Fix Test Issues"]
FixTest --> RetryTest["Retry Test"]
RetryTest --> TestStatus
style Start fill:#4da6ff,stroke:#0066cc,color:white
style TestSuccess fill:#10b981,stroke:#059669,color:white
style BuildStatus fill:#f6546a,stroke:#c30052,color:white
style TestStatus fill:#f6546a,stroke:#c30052,color:white
\`\`\`
#### Minimal Build Test Implementation:
\`\`\`powershell
# Example: Perform minimal build test for a React project
function Perform-MinimalBuildTest {
$buildSuccess = $false
$testSuccess = $false
# Create minimal test project
$testDir = ".__build_test"
if (Test-Path $testDir) {
Remove-Item -Path $testDir -Recurse -Force
}
try {
# Create minimal test directory
New-Item -Path $testDir -ItemType Directory | Out-Null
Push-Location $testDir
# Initialize minimal package.json
@"
{
"name": "build-test",
"version": "1.0.0",
"description": "Minimal build test",
"main": "index.js",
"scripts": {
"build": "echo Build test successful"
}
}
"@ | Set-Content -Path "package.json"
# Attempt build
npm run build | Out-Null
$buildSuccess = $true
# Create minimal test file
@"
console.log('Test successful');
"@ | Set-Content -Path "index.js"
# Run basic test
node index.js | Out-Null
$testSuccess = $true
} catch {
Write-Output "❌ Build test failed: $($_.Exception.Message)"
} finally {
Pop-Location
if (Test-Path $testDir) {
Remove-Item -Path $testDir -Recurse -Force
}
}
# Display results
if ($buildSuccess -and $testSuccess) {
Write-Output "✅ Minimal build test passed successfully"
return $true
} else {
if (-not $buildSuccess) {
Write-Output "❌ Build process failed"
}
if (-not $testSuccess) {
Write-Output "❌ Basic functionality test failed"
}
return $false
}
}
\`\`\`
## 📋 COMPREHENSIVE QA REPORT FORMAT
After running all validation steps, a comprehensive report is generated:
\`\`\`
╔═════════════════════ 🔍 QA VALIDATION REPORT ══════════════════════╗
│ │
│ PROJECT: [Project Name] │
│ TIMESTAMP: [Current Date/Time] │
│ │
│ 1️⃣ DEPENDENCY VERIFICATION │
│ ✓ Required: [List of required dependencies] │
│ ✓ Installed: [List of installed dependencies] │
│ ✓ Compatible: [Yes/No] │
│ │
│ 2️⃣ CONFIGURATION VALIDATION │
│ ✓ Config Files: [List of configuration files] │
│ ✓ Syntax Valid: [Yes/No] │
│ ✓ Platform Compatible: [Yes/No] │
│ │
│ 3️⃣ ENVIRONMENT VALIDATION │
│ ✓ Build Tools: [Available/Missing] │
│ ✓ Permissions: [Sufficient/Insufficient] │
│ ✓ Environment Ready: [Yes/No] │
│ │
│ 4️⃣ MINIMAL BUILD TEST │
│ ✓ Build Process: [Successful/Failed] │
│ ✓ Functionality Test: [Passed/Failed] │
│ ✓ Build Ready: [Yes/No] │
│ │
│ 🚨 FINAL VERDICT: [PASS/FAIL] │
│ ➡️ [Success message or error details] │
╚═════════════════════════════════════════════════════════════════════╝
\`\`\`
## ❌ FAILURE REPORT FORMAT
If any validation step fails, a detailed failure report is generated:
\`\`\`
⚠️⚠️⚠️ QA VALIDATION FAILED ⚠️⚠️⚠️
The following issues must be resolved before proceeding to BUILD mode:
1️⃣ DEPENDENCY ISSUES:
- [Detailed description of dependency issues]
- [Recommended fix]
2️⃣ CONFIGURATION ISSUES:
- [Detailed description of configuration issues]
- [Recommended fix]
3️⃣ ENVIRONMENT ISSUES:
- [Detailed description of environment issues]
- [Recommended fix]
4️⃣ BUILD TEST ISSUES:
- [Detailed description of build test issues]
- [Recommended fix]
⚠️ BUILD MODE IS BLOCKED until these issues are resolved.
Type 'VAN QA' after fixing the issues to re-validate.
\`\`\`
## 🔄 INTEGRATION WITH DESIGN DECISIONS
The VAN QA mode reads and validates design decisions from the CREATIVE phase:
\`\`\`mermaid
graph TD
Start["Read Design Decisions"] --> ReadCreative["Parse Creative Phase Documentation"]
ReadCreative --> ExtractTech["Extract Technology Choices"]
ExtractTech --> ExtractDeps["Extract Required Dependencies"]
ExtractDeps --> BuildValidationPlan["Build Validation Plan"]
BuildValidationPlan --> StartValidation["Start Four-Point Validation Process"]
style Start fill:#4da6ff,stroke:#0066cc,color:white
style ExtractTech fill:#f6546a,stroke:#c30052,color:white
style BuildValidationPlan fill:#10b981,stroke:#059669,color:white
style StartValidation fill:#f6546a,stroke:#c30052,color:white
\`\`\`
### Technology Extraction Process:
\`\`\`powershell
# Example: Extract technology choices from creative phase documentation
function Extract-TechnologyChoices {
$techChoices = @{}
# Read from systemPatterns.md
if (Test-Path "memory-bank\systemPatterns.md") {
$content = Get-Content "memory-bank\systemPatterns.md" -Raw
# Extract framework choice
if ($content -match "Framework:\s*(\w+)") {
$techChoices["framework"] = $Matches[1]
}
# Extract UI library choice
if ($content -match "UI Library:\s*(\w+)") {
$techChoices["ui_library"] = $Matches[1]
}
# Extract state management choice
if ($content -match "State Management:\s*([^\\n]+)") {
$techChoices["state_management"] = $Matches[1].Trim()
}
}
return $techChoices
}
\`\`\`
## 🚨 IMPLEMENTATION PREVENTION MECHANISM
If QA validation fails, the system prevents moving to BUILD mode:
\`\`\`powershell
# Example: Enforce QA validation before allowing BUILD mode
function Check-QAValidationStatus {
$qaStatusFile = "memory-bank\.qa_validation_status"
if (Test-Path $qaStatusFile) {
$status = Get-Content $qaStatusFile -Raw
if ($status -match "PASS") {
return $true
}
}
# Display block message
Write-Output "`n`n"
Write-Output "🚫🚫🚫🚫🚫🚫🚫🚫🚫🚫🚫🚫🚫🚫🚫🚫🚫🚫🚫🚫🚫🚫🚫🚫🚫🚫🚫🚫🚫"
Write-Output "⛔️ BUILD MODE BLOCKED: QA VALIDATION REQUIRED"
Write-Output "⛔️ You must complete QA validation before proceeding to BUILD mode"
Write-Output "`n"
Write-Output "Type 'VAN QA' to perform technical validation"
Write-Output "`n"
Write-Output "🚫 NO IMPLEMENTATION CAN PROCEED WITHOUT VALIDATION 🚫"
Write-Output "🚫🚫🚫🚫🚫🚫🚫🚫🚫🚫🚫🚫🚫🚫🚫🚫🚫🚫🚫🚫🚫🚫🚫🚫🚫🚫🚫🚫🚫"
return $false
}
\`\`\`
## 🧪 COMMON QA VALIDATION FIXES
Here are common fixes for issues encountered during QA validation:
### Dependency Issues:
- **Missing Node.js**: Install Node.js from https://nodejs.org/
- **Outdated npm**: Run `npm install -g npm@latest` to update
- **Missing packages**: Run `npm install` or `npm install [package-name]`
### Configuration Issues:
- **Invalid JSON**: Use a JSON validator to check syntax
- **Missing React plugin**: Add `import react from '@vitejs/plugin-react'` and `plugins: [react()]` to vite.config.js
- **Incompatible TypeScript config**: Update `tsconfig.json` with correct React settings
### Environment Issues:
- **Permission denied**: Run terminal as administrator (Windows) or use sudo (Mac/Linux)
- **Port already in use**: Kill process using the port or change the port in configuration
- **Missing build tools**: Install required command-line tools
### Build Test Issues:
- **Build fails**: Check console for specific error messages
- **Test fails**: Verify minimal configuration is correct
- **Path issues**: Ensure paths use correct separators for the platform
## 🔒 FINAL QA VALIDATION CHECKPOINT
\`\`\`
✓ SECTION CHECKPOINT: QA VALIDATION
- Dependency Verification Passed? [YES/NO]
- Configuration Validation Passed? [YES/NO]
- Environment Validation Passed? [YES/NO]
- Minimal Build Test Passed? [YES/NO]
→ If all YES: Ready for BUILD mode
→ If any NO: Fix identified issues before proceeding
\`\`\`
```
## /.cursor/rules/isolation_rules/visual-maps/van_mode_split/van-complexity-determination.mdc
```mdc path="/.cursor/rules/isolation_rules/visual-maps/van_mode_split/van-complexity-determination.mdc"
---
description: Visual process map for VAN mode complexity determination
globs: van-complexity-determination.mdc
alwaysApply: false
---
# VAN MODE: EARLY COMPLEXITY DETERMINATION
> **TL;DR:** Analyzes the task to determine complexity level. For Level 1, VAN mode completes. For Levels 2-4, triggers a mandatory switch to PLAN mode.
## 🧩 COMPLEXITY DETERMINATION PROCESS
\`\`\`mermaid
graph TD
CD["Complexity Determination"] --> AnalyzeTask["Analyze Task Requirements"]
AnalyzeTask --> CheckKeywords["Check Task Keywords"]
CheckKeywords --> ScopeCheck["Assess Scope Impact"]
ScopeCheck --> RiskCheck["Evaluate Risk Level"]
RiskCheck --> EffortCheck["Estimate Implementation Effort"]
EffortCheck --> DetermineLevel{"Determine Complexity Level"}
DetermineLevel -->|"Level 1"| L1["Level 1: Quick Bug Fix"]
DetermineLevel -->|"Level 2"| L2["Level 2: Simple Enhancement"]
DetermineLevel -->|"Level 3"| L3["Level 3: Intermediate Feature"]
DetermineLevel -->|"Level 4"| L4["Level 4: Complex System"]
L1 --> CDComplete["Complexity Determination Complete (Level 1)"]
L2 & L3 & L4 --> ModeSwitch["Force Mode Switch to PLAN"]
style CD fill:#4da6ff,stroke:#0066cc,color:white
style CDComplete fill:#10b981,stroke:#059669,color:white
style ModeSwitch fill:#ff0000,stroke:#990000,color:white
style DetermineLevel fill:#f6546a,stroke:#c30052,color:white
\`\`\`
## 🚨 MODE TRANSITION TRIGGER (VAN to PLAN)
If complexity is determined to be Level 2, 3, or 4:
\`\`\`
🚫 LEVEL [2-4] TASK DETECTED
Implementation in VAN mode is BLOCKED
This task REQUIRES PLAN mode
You MUST switch to PLAN mode for proper documentation and planning
Type 'PLAN' to switch to planning mode
\`\`\`
## 📋 CHECKPOINT VERIFICATION TEMPLATE (Example)
\`\`\`
✓ SECTION CHECKPOINT: COMPLEXITY DETERMINATION
- Task Analyzed? [YES/NO]
- Complexity Level Determined? [YES/NO]
→ If Level 1: Proceed to VAN Mode Completion.
→ If Level 2-4: Trigger PLAN Mode transition.
\`\`\`
**Next Step (Level 1):** Complete VAN Initialization (e.g., initialize Memory Bank if needed).
**Next Step (Level 2-4):** Exit VAN mode and initiate PLAN mode.
```
## /.cursor/rules/isolation_rules/visual-maps/van_mode_split/van-file-verification.mdc
```mdc path="/.cursor/rules/isolation_rules/visual-maps/van_mode_split/van-file-verification.mdc"
---
description: Visual process map for VAN mode file verification
globs: van-file-verification.mdc
alwaysApply: false
---
# VAN MODE: FILE VERIFICATION
> **TL;DR:** Checks for the existence and basic structure of essential Memory Bank and documentation components.
## 📁 FILE VERIFICATION PROCESS
\`\`\`mermaid
graph TD
FV["File Verification"] --> CheckFiles["Check Essential Files"]
CheckFiles --> CheckMB["Check Memory Bank Structure"]
CheckMB --> MBExists{"Memory Bank Exists?"}
MBExists -->|"Yes"| VerifyMB["Verify Memory Bank Contents (Basic)"]
MBExists -->|"No"| CreateMB["Create Memory Bank Structure (Basic)"]
CheckFiles --> CheckDocs["Check Documentation Files (e.g., tasks.md)"]
CheckDocs --> DocsExist{"Docs Exist?"}
DocsExist -->|"Yes"| VerifyDocs["Verify Documentation Presence"]
DocsExist -->|"No"| CreateDocs["Create Essential Documentation Files"]
VerifyMB & CreateMB --> MBCP["Memory Bank Checkpoint"]
VerifyDocs & CreateDocs --> DocsCP["Documentation Checkpoint"]
MBCP & DocsCP --> FileComplete["File Verification Complete"]
style FV fill:#4da6ff,stroke:#0066cc,color:white
style FileComplete fill:#10b981,stroke:#059669,color:white
style MBCP fill:#f6546a,stroke:#c30052,color:white
style DocsCP fill:#f6546a,stroke:#c30052,color:white
\`\`\`
## 📋 CHECKPOINT VERIFICATION TEMPLATE (Example)
\`\`\`
✓ SECTION CHECKPOINT: FILE VERIFICATION
- Memory Bank Directory Exists/Created? [YES/NO]
- Essential Docs (tasks.md) Exist/Created? [YES/NO]
→ If all YES: File Verification Complete.
→ If any NO: Resolve before proceeding.
\`\`\`
**Next Step:** Load and process `van-complexity-determination.mdc`.
```
## /.cursor/rules/isolation_rules/visual-maps/van_mode_split/van-mode-map.mdc
```mdc path="/.cursor/rules/isolation_rules/visual-maps/van_mode_split/van-mode-map.mdc"
---
description: Visual process map for VAN mode (Index/Entry Point)
globs: van-mode-map.mdc
alwaysApply: false
---
# VAN MODE: INITIALIZATION PROCESS MAP (INDEX)
> **TL;DR:** This is the entry point for VAN mode. It handles initial activation and directs the process to subsequent steps stored in separate files for optimization.
## 🚀 VAN MODE ACTIVATION
When the user types "VAN", respond with a confirmation and start the process:
\`\`\`
User: VAN
Response: OK VAN - Beginning Initialization Process
Loading Platform Detection map...
\`\`\`
## 🧭 VAN MODE PROCESS FLOW (High Level)
This graph shows the main stages. Each stage is detailed in a separate file loaded sequentially.
\`\`\`mermaid
graph TD
Start["START VAN MODE"] --> PlatformDetect["1. PLATFORM DETECTION
(van-platform-detection.mdc)"]
PlatformDetect --> FileVerify["2. FILE VERIFICATION
(van-file-verification.mdc)"]
FileVerify --> Complexity["3. EARLY COMPLEXITY
DETERMINATION
(van-complexity-determination.mdc)"]
Complexity --> Decision{"Level?"}
Decision -- "Level 1" --> L1Complete["Level 1 Init Complete"]
Decision -- "Level 2-4" --> ExitToPlan["Exit to PLAN Mode"]
%% Link to QA (Loaded separately)
QA_Entry["VAN QA MODE
(Loaded Separately via
'VAN QA' command)"] -.-> QA_Map["(van-qa-validation.mdc)"]
style PlatformDetect fill:#ccf,stroke:#333
style FileVerify fill:#ccf,stroke:#333
style Complexity fill:#ccf,stroke:#333
style QA_Map fill:#fcc,stroke:#333
\`\`\`
**Next Step:** Load and process `van-platform-detection.mdc`.
```
## /.cursor/rules/isolation_rules/visual-maps/van_mode_split/van-platform-detection.mdc
```mdc path="/.cursor/rules/isolation_rules/visual-maps/van_mode_split/van-platform-detection.mdc"
---
description: Visual process map for VAN mode platform detection
globs: van-platform-detection.mdc
alwaysApply: false
---
# VAN MODE: PLATFORM DETECTION
> **TL;DR:** Detects the OS, determines path separators, and notes command adaptations required.
## 🌐 PLATFORM DETECTION PROCESS
\`\`\`mermaid
graph TD
PD["Platform Detection"] --> CheckOS["Detect Operating System"]
CheckOS --> Win["Windows"]
CheckOS --> Mac["macOS"]
CheckOS --> Lin["Linux"]
Win & Mac & Lin --> Adapt["Adapt Commands for Platform"]
Win --> WinPath["Path: Backslash (\\)"]
Mac --> MacPath["Path: Forward Slash (/)"]
Lin --> LinPath["Path: Forward Slash (/)"]
Win --> WinCmd["Command Adaptations: dir, icacls, etc."]
Mac --> MacCmd["Command Adaptations: ls, chmod, etc."]
Lin --> LinCmd["Command Adaptations: ls, chmod, etc."]
WinPath & MacPath & LinPath --> PathCP["Path Separator Checkpoint"]
WinCmd & MacCmd & LinCmd --> CmdCP["Command Checkpoint"]
PathCP & CmdCP --> PlatformComplete["Platform Detection Complete"]
style PD fill:#4da6ff,stroke:#0066cc,color:white
style PlatformComplete fill:#10b981,stroke:#059669,color:white
\`\`\`
## 📋 CHECKPOINT VERIFICATION TEMPLATE (Example)
\`\`\`
✓ SECTION CHECKPOINT: PLATFORM DETECTION
- Operating System Detected? [YES/NO]
- Path Separator Confirmed? [YES/NO]
- Command Adaptations Noted? [YES/NO]
→ If all YES: Platform Detection Complete.
→ If any NO: Resolve before proceeding.
\`\`\`
**Next Step:** Load and process `van-file-verification.mdc`.
```
## /.cursor/rules/isolation_rules/visual-maps/van_mode_split/van-qa-checks/build-test.mdc
```mdc path="/.cursor/rules/isolation_rules/visual-maps/van_mode_split/van-qa-checks/build-test.mdc"
---
description: Process map for VAN QA minimal build test
globs: van-qa-checks/build-test.mdc
alwaysApply: false
---
# VAN QA: MINIMAL BUILD TEST
> **TL;DR:** This component performs a minimal build test to ensure core build functionality works properly.
## 4️⃣ MINIMAL BUILD TEST PROCESS
\`\`\`mermaid
graph TD
Start["Minimal Build Test"] --> CreateTest["Create Minimal Test Project"]
CreateTest --> BuildTest["Attempt Build"]
BuildTest --> BuildStatus{"Build Successful?"}
BuildStatus -->|"Yes"| RunTest["Run Basic Functionality Test"]
BuildStatus -->|"No"| FixBuild["Fix Build Issues"]
FixBuild --> RetryBuild["Retry Build"]
RetryBuild --> BuildStatus
RunTest --> TestStatus{"Test Passed?"}
TestStatus -->|"Yes"| TestSuccess["Minimal Build Test ✅ PASS"]
TestStatus -->|"No"| FixTest["Fix Test Issues"]
FixTest --> RetryTest["Retry Test"]
RetryTest --> TestStatus
style Start fill:#4da6ff,stroke:#0066cc,color:white
style TestSuccess fill:#10b981,stroke:#059669,color:white
style BuildStatus fill:#f6546a,stroke:#c30052,color:white
style TestStatus fill:#f6546a,stroke:#c30052,color:white
\`\`\`
### Minimal Build Test Implementation:
\`\`\`powershell
# Example: Perform minimal build test for a React project
function Perform-MinimalBuildTest {
$buildSuccess = $false
$testSuccess = $false
# Create minimal test project
$testDir = ".__build_test"
if (Test-Path $testDir) {
Remove-Item -Path $testDir -Recurse -Force
}
try {
# Create minimal test directory
New-Item -Path $testDir -ItemType Directory | Out-Null
Push-Location $testDir
# Initialize minimal package.json
@"
{
"name": "build-test",
"version": "1.0.0",
"description": "Minimal build test",
"main": "index.js",
"scripts": {
"build": "echo Build test successful"
}
}
"@ | Set-Content -Path "package.json"
# Attempt build
npm run build | Out-Null
$buildSuccess = $true
# Create minimal test file
@"
console.log('Test successful');
"@ | Set-Content -Path "index.js"
# Run basic test
node index.js | Out-Null
$testSuccess = $true
} catch {
Write-Output "❌ Build test failed: $($_.Exception.Message)"
} finally {
Pop-Location
if (Test-Path $testDir) {
Remove-Item -Path $testDir -Recurse -Force
}
}
# Display results
if ($buildSuccess -and $testSuccess) {
Write-Output "✅ Minimal build test passed successfully"
return $true
} else {
if (-not $buildSuccess) {
Write-Output "❌ Build process failed"
}
if (-not $testSuccess) {
Write-Output "❌ Basic functionality test failed"
}
return $false
}
}
\`\`\`
## 📋 MINIMAL BUILD TEST CHECKPOINT
\`\`\`
✓ CHECKPOINT: MINIMAL BUILD TEST
- Test project creation successful? [YES/NO]
- Build process completed successfully? [YES/NO]
- Basic functionality test passed? [YES/NO]
→ If all YES: QA Validation complete, proceed to generate success report.
→ If any NO: Fix build issues before continuing.
\`\`\`
**Next Step (on PASS):** Load `van-qa-utils/reports.mdc` to generate success report.
**Next Step (on FAIL):** Check `van-qa-utils/common-fixes.mdc` for build test fixes.
```
## /.cursor/rules/isolation_rules/visual-maps/van_mode_split/van-qa-checks/config-check.mdc
```mdc path="/.cursor/rules/isolation_rules/visual-maps/van_mode_split/van-qa-checks/config-check.mdc"
---
description: Process map for VAN QA configuration validation
globs: van-qa-checks/config-check.mdc
alwaysApply: false
---
# VAN QA: CONFIGURATION VALIDATION
> **TL;DR:** This component validates configuration files for proper syntax and compatibility with the project and platform.
## 2️⃣ CONFIGURATION VALIDATION PROCESS
\`\`\`mermaid
graph TD
Start["Configuration Validation"] --> IdentifyConfigs["Identify Configuration Files"]
IdentifyConfigs --> ReadConfigs["Read Configuration Files"]
ReadConfigs --> ValidateSyntax["Validate Syntax and Format"]
ValidateSyntax --> SyntaxStatus{"Syntax Valid?"}
SyntaxStatus -->|"Yes"| CheckCompatibility["Check Compatibility with Platform"]
SyntaxStatus -->|"No"| FixSyntax["Fix Syntax Errors"]
FixSyntax --> RetryValidate["Retry Validation"]
RetryValidate --> SyntaxStatus
CheckCompatibility --> CompatStatus{"Compatible with Platform?"}
CompatStatus -->|"Yes"| ConfigSuccess["Configurations Validated ✅ PASS"]
CompatStatus -->|"No"| AdaptConfigs["Adapt Configurations for Platform"]
AdaptConfigs --> RetryCompat["Retry Compatibility Check"]
RetryCompat --> CompatStatus
style Start fill:#4da6ff,stroke:#0066cc,color:white
style ConfigSuccess fill:#10b981,stroke:#059669,color:white
style SyntaxStatus fill:#f6546a,stroke:#c30052,color:white
style CompatStatus fill:#f6546a,stroke:#c30052,color:white
\`\`\`
### Configuration Validation Implementation:
\`\`\`powershell
# Example: Validate configuration files for a web project
function Validate-Configurations {
$configFiles = @(
"package.json",
"tsconfig.json",
"vite.config.js"
)
$invalidConfigs = @()
$incompatibleConfigs = @()
foreach ($configFile in $configFiles) {
if (Test-Path $configFile) {
# Check JSON syntax for JSON files
if ($configFile -match "\.json$") {
try {
Get-Content $configFile -Raw | ConvertFrom-Json | Out-Null
} catch {
$invalidConfigs += "$configFile (JSON syntax error: $($_.Exception.Message))"
continue
}
}
# Specific configuration compatibility checks
if ($configFile -eq "vite.config.js") {
$content = Get-Content $configFile -Raw
# Check for React plugin in Vite config
if ($content -notmatch "react\(\)") {
$incompatibleConfigs += "$configFile (Missing React plugin for React project)"
}
}
} else {
$invalidConfigs += "$configFile (file not found)"
}
}
# Display results
if ($invalidConfigs.Count -eq 0 -and $incompatibleConfigs.Count -eq 0) {
Write-Output "✅ All configurations validated and compatible"
return $true
} else {
if ($invalidConfigs.Count -gt 0) {
Write-Output "❌ Invalid configurations: $($invalidConfigs -join ', ')"
}
if ($incompatibleConfigs.Count -gt 0) {
Write-Output "❌ Incompatible configurations: $($incompatibleConfigs -join ', ')"
}
return $false
}
}
\`\`\`
## 📋 CONFIGURATION VALIDATION CHECKPOINT
\`\`\`
✓ CHECKPOINT: CONFIGURATION VALIDATION
- All configuration files found? [YES/NO]
- All configuration syntax valid? [YES/NO]
- All configurations compatible with platform? [YES/NO]
→ If all YES: Continue to Environment Validation.
→ If any NO: Fix configuration issues before continuing.
\`\`\`
**Next Step (on PASS):** Load `van-qa-checks/environment-check.mdc`.
**Next Step (on FAIL):** Check `van-qa-utils/common-fixes.mdc` for configuration fixes.
```
## /.cursor/rules/isolation_rules/visual-maps/van_mode_split/van-qa-checks/dependency-check.mdc
```mdc path="/.cursor/rules/isolation_rules/visual-maps/van_mode_split/van-qa-checks/dependency-check.mdc"
---
description: Process map for VAN QA dependency verification
globs: van-qa-checks/dependency-check.mdc
alwaysApply: false
---
# VAN QA: DEPENDENCY VERIFICATION
> **TL;DR:** This component verifies that all required dependencies are installed and compatible with the project requirements.
## 1️⃣ DEPENDENCY VERIFICATION PROCESS
\`\`\`mermaid
graph TD
Start["Dependency Verification"] --> ReadDeps["Read Required Dependencies from Creative Phase"]
ReadDeps --> CheckInstalled["Check if Dependencies are Installed"]
CheckInstalled --> DepStatus{"All Dependencies Installed?"}
DepStatus -->|"Yes"| VerifyVersions["Verify Versions and Compatibility"]
DepStatus -->|"No"| InstallMissing["Install Missing Dependencies"]
InstallMissing --> VerifyVersions
VerifyVersions --> VersionStatus{"Versions Compatible?"}
VersionStatus -->|"Yes"| DepSuccess["Dependencies Verified ✅ PASS"]
VersionStatus -->|"No"| UpgradeVersions["Upgrade/Downgrade as Needed"]
UpgradeVersions --> RetryVerify["Retry Verification"]
RetryVerify --> VersionStatus
style Start fill:#4da6ff,stroke:#0066cc,color:white
style DepSuccess fill:#10b981,stroke:#059669,color:white
style DepStatus fill:#f6546a,stroke:#c30052,color:white
style VersionStatus fill:#f6546a,stroke:#c30052,color:white
\`\`\`
### Windows (PowerShell) Implementation:
\`\`\`powershell
# Example: Verify Node.js dependencies for a React project
function Verify-Dependencies {
$requiredDeps = @{ "node" = ">=14.0.0"; "npm" = ">=6.0.0" }
$missingDeps = @(); $incompatibleDeps = @()
# Check Node.js version
try {
$nodeVersion = node -v
if ($nodeVersion -match "v(\d+)\.(\d+)\.(\d+)") {
$major = [int]$Matches[1]
if ($major -lt 14) {
$incompatibleDeps += "node (found $nodeVersion, required >=14.0.0)"
}
}
} catch {
$missingDeps += "node"
}
# Check npm version
try {
$npmVersion = npm -v
if ($npmVersion -match "(\d+)\.(\d+)\.(\d+)") {
$major = [int]$Matches[1]
if ($major -lt 6) {
$incompatibleDeps += "npm (found $npmVersion, required >=6.0.0)"
}
}
} catch {
$missingDeps += "npm"
}
# Display results
if ($missingDeps.Count -eq 0 -and $incompatibleDeps.Count -eq 0) {
Write-Output "✅ All dependencies verified and compatible"
return $true
} else {
if ($missingDeps.Count -gt 0) {
Write-Output "❌ Missing dependencies: $($missingDeps -join ', ')"
}
if ($incompatibleDeps.Count -gt 0) {
Write-Output "❌ Incompatible versions: $($incompatibleDeps -join ', ')"
}
return $false
}
}
\`\`\`
### Mac/Linux (Bash) Implementation:
\`\`\`bash
#!/bin/bash
# Example: Verify Node.js dependencies for a React project
verify_dependencies() {
local missing_deps=()
local incompatible_deps=()
# Check Node.js version
if command -v node &> /dev/null; then
local node_version=$(node -v)
if [[ $node_version =~ v([0-9]+)\.([0-9]+)\.([0-9]+) ]]; then
local major=${BASH_REMATCH[1]}
if (( major < 14 )); then
incompatible_deps+=("node (found $node_version, required >=14.0.0)")
fi
fi
else
missing_deps+=("node")
fi
# Check npm version
if command -v npm &> /dev/null; then
local npm_version=$(npm -v)
if [[ $npm_version =~ ([0-9]+)\.([0-9]+)\.([0-9]+) ]]; then
local major=${BASH_REMATCH[1]}
if (( major < 6 )); then
incompatible_deps+=("npm (found $npm_version, required >=6.0.0)")
fi
fi
else
missing_deps+=("npm")
fi
# Display results
if [ ${#missing_deps[@]} -eq 0 ] && [ ${#incompatible_deps[@]} -eq 0 ]; then
echo "✅ All dependencies verified and compatible"
return 0
else
if [ ${#missing_deps[@]} -gt 0 ]; then
echo "❌ Missing dependencies: ${missing_deps[*]}"
fi
if [ ${#incompatible_deps[@]} -gt 0 ]; then
echo "❌ Incompatible versions: ${incompatible_deps[*]}"
fi
return 1
fi
}
\`\`\`
## 📋 DEPENDENCY VERIFICATION CHECKPOINT
\`\`\`
✓ CHECKPOINT: DEPENDENCY VERIFICATION
- Required dependencies identified? [YES/NO]
- All dependencies installed? [YES/NO]
- All versions compatible? [YES/NO]
→ If all YES: Continue to Configuration Validation.
→ If any NO: Fix dependency issues before continuing.
\`\`\`
**Next Step (on PASS):** Load `van-qa-checks/config-check.mdc`.
**Next Step (on FAIL):** Check `van-qa-utils/common-fixes.mdc` for dependency fixes.
```
## /.cursor/rules/isolation_rules/visual-maps/van_mode_split/van-qa-checks/environment-check.mdc
```mdc path="/.cursor/rules/isolation_rules/visual-maps/van_mode_split/van-qa-checks/environment-check.mdc"
---
description: Process map for VAN QA environment validation
globs: van-qa-checks/environment-check.mdc
alwaysApply: false
---
# VAN QA: ENVIRONMENT VALIDATION
> **TL;DR:** This component verifies that the build environment is properly set up with required tools and permissions.
## 3️⃣ ENVIRONMENT VALIDATION PROCESS
\`\`\`mermaid
graph TD
Start["Environment Validation"] --> CheckEnv["Check Build Environment"]
CheckEnv --> VerifyBuildTools["Verify Build Tools"]
VerifyBuildTools --> ToolsStatus{"Build Tools Available?"}
ToolsStatus -->|"Yes"| CheckPerms["Check Permissions and Access"]
ToolsStatus -->|"No"| InstallTools["Install Required Build Tools"]
InstallTools --> RetryTools["Retry Verification"]
RetryTools --> ToolsStatus
CheckPerms --> PermsStatus{"Permissions Sufficient?"}
PermsStatus -->|"Yes"| EnvSuccess["Environment Validated ✅ PASS"]
PermsStatus -->|"No"| FixPerms["Fix Permission Issues"]
FixPerms --> RetryPerms["Retry Permission Check"]
RetryPerms --> PermsStatus
style Start fill:#4da6ff,stroke:#0066cc,color:white
style EnvSuccess fill:#10b981,stroke:#059669,color:white
style ToolsStatus fill:#f6546a,stroke:#c30052,color:white
style PermsStatus fill:#f6546a,stroke:#c30052,color:white
\`\`\`
### Environment Validation Implementation:
\`\`\`powershell
# Example: Validate environment for a web project
function Validate-Environment {
$requiredTools = @(
@{Name = "git"; Command = "git --version"},
@{Name = "node"; Command = "node --version"},
@{Name = "npm"; Command = "npm --version"}
)
$missingTools = @()
$permissionIssues = @()
# Check build tools
foreach ($tool in $requiredTools) {
try {
Invoke-Expression $tool.Command | Out-Null
} catch {
$missingTools += $tool.Name
}
}
# Check write permissions in project directory
try {
$testFile = ".__permission_test"
New-Item -Path $testFile -ItemType File -Force | Out-Null
Remove-Item -Path $testFile -Force
} catch {
$permissionIssues += "Current directory (write permission denied)"
}
# Check if port 3000 is available (commonly used for dev servers)
try {
$listener = New-Object System.Net.Sockets.TcpListener([System.Net.IPAddress]::Loopback, 3000)
$listener.Start()
$listener.Stop()
} catch {
$permissionIssues += "Port 3000 (already in use or access denied)"
}
# Display results
if ($missingTools.Count -eq 0 -and $permissionIssues.Count -eq 0) {
Write-Output "✅ Environment validated successfully"
return $true
} else {
if ($missingTools.Count -gt 0) {
Write-Output "❌ Missing tools: $($missingTools -join ', ')"
}
if ($permissionIssues.Count -gt 0) {
Write-Output "❌ Permission issues: $($permissionIssues -join ', ')"
}
return $false
}
}
\`\`\`
## 📋 ENVIRONMENT VALIDATION CHECKPOINT
\`\`\`
✓ CHECKPOINT: ENVIRONMENT VALIDATION
- All required build tools installed? [YES/NO]
- Project directory permissions sufficient? [YES/NO]
- Required ports available? [YES/NO]
→ If all YES: Continue to Minimal Build Test.
→ If any NO: Fix environment issues before continuing.
\`\`\`
**Next Step (on PASS):** Load `van-qa-checks/build-test.mdc`.
**Next Step (on FAIL):** Check `van-qa-utils/common-fixes.mdc` for environment fixes.
```
## /.cursor/rules/isolation_rules/visual-maps/van_mode_split/van-qa-checks/file-verification.mdc
```mdc path="/.cursor/rules/isolation_rules/visual-maps/van_mode_split/van-qa-checks/file-verification.mdc"
```
## /.cursor/rules/isolation_rules/visual-maps/van_mode_split/van-qa-main.mdc
```mdc path="/.cursor/rules/isolation_rules/visual-maps/van_mode_split/van-qa-main.mdc"
---
description: Visual process map for VAN QA mode (Technical Validation Entry Point)
globs: van-qa-main.mdc
alwaysApply: false
---
# VAN MODE: QA TECHNICAL VALIDATION (Main Entry)
> **TL;DR:** This is the entry point for the QA validation process that executes *after* CREATIVE mode and *before* BUILD mode. It ensures technical requirements are met before implementation begins.
## 📣 HOW TO USE THESE QA RULES
To access any QA validation rule or component, use the `fetch_rules` tool with exact rule names:
\`\`\`
// CRITICAL: Always use fetch_rules to load validation components
// For detailed examples and guidance, load:
// isolation_rules/visual-maps/van-qa-utils/rule-calling-guide
\`\`\`
## 🚀 VAN QA MODE ACTIVATION
After completing CREATIVE mode, when the user types "VAN QA", respond:
\`\`\`mermaid
graph TD
UserQA["User Types: QA"] --> HighPriority["⚠️ HIGH PRIORITY COMMAND"]
HighPriority --> CurrentTask["Pause Current Task/Process"]
CurrentTask --> LoadQA["Load QA Main Map (This File)"]
LoadQA --> RunQA["Execute QA Validation Process"]
RunQA --> QAResults{"QA Results"}
QAResults -->|"PASS"| ResumeFlow["Resume Prior Process Flow"]
QAResults -->|"FAIL"| FixIssues["Fix Identified Issues"]
FixIssues --> ReRunQA["Re-run QA Validation"]
ReRunQA --> QAResults
style UserQA fill:#f8d486,stroke:#e8b84d,color:black
style HighPriority fill:#ff0000,stroke:#cc0000,color:white,stroke-width:3px
style LoadQA fill:#4da6ff,stroke:#0066cc,color:white
style RunQA fill:#4da6ff,stroke:#0066cc,color:white
style QAResults fill:#f6546a,stroke:#c30052,color:white
\`\`\`
### QA Interruption Rules
1. **Immediate Precedence:** `QA` command interrupts everything.
2. **Load & Execute:** Load this map (`van-qa-main.mdc`) and its components (see below).
3. **Remediation Priority:** Fixes take priority over pending mode switches.
4. **Resume:** On PASS, resume the previous flow.
\`\`\`
⚠️ QA OVERRIDE ACTIVATED
All other processes paused
QA validation checks now running...
Any issues found MUST be remediated before continuing with normal process flow
\`\`\`
## 🔍 TECHNICAL VALIDATION OVERVIEW
Four-point validation process with selective loading:
\`\`\`mermaid
graph TD
VANQA["VAN QA MODE"] --> FourChecks["FOUR-POINT VALIDATION"]
FourChecks --> DepCheck["1️⃣ DEPENDENCY VERIFICATION
Load: van-qa-checks/dependency-check.mdc"]
DepCheck --> ConfigCheck["2️⃣ CONFIGURATION VALIDATION
Load: van-qa-checks/config-check.mdc"]
ConfigCheck --> EnvCheck["3️⃣ ENVIRONMENT VALIDATION
Load: van-qa-checks/environment-check.mdc"]
EnvCheck --> MinBuildCheck["4️⃣ MINIMAL BUILD TEST
Load: van-qa-checks/build-test.mdc"]
MinBuildCheck --> ValidationResults{"All Checks Passed?"}
ValidationResults -->|"Yes"| SuccessReport["GENERATE SUCCESS REPORT
Load: van-qa-utils/reports.mdc"]
ValidationResults -->|"No"| FailureReport["GENERATE FAILURE REPORT
Load: van-qa-utils/reports.mdc"]
SuccessReport --> BUILD_Transition["Trigger BUILD Mode
Load: van-qa-utils/mode-transitions.mdc"]
FailureReport --> FixIssues["Fix Technical Issues
Load: van-qa-utils/common-fixes.mdc"]
FixIssues --> ReValidate["Re-validate (Re-run VAN QA)"]
ReValidate --> FourChecks
style VANQA fill:#4da6ff,stroke:#0066cc,color:white
style FourChecks fill:#f6546a,stroke:#c30052,color:white
style ValidationResults fill:#f6546a,stroke:#c30052,color:white
style BUILD_Transition fill:#10b981,stroke:#059669,color:white
style FixIssues fill:#ff5555,stroke:#dd3333,color:white
\`\`\`
## 🔄 INTEGRATION WITH DESIGN DECISIONS
Reads Creative Phase outputs to inform validation:
\`\`\`mermaid
graph TD
Start["Read Design Decisions"] --> ReadCreative["Parse Creative Phase Documentation"]
ReadCreative --> ExtractTech["Extract Technology Choices"]
ExtractTech --> ExtractDeps["Extract Required Dependencies"]
ExtractDeps --> BuildValidationPlan["Build Validation Plan"]
BuildValidationPlan --> StartValidation["Start Four-Point Validation Process"]
style Start fill:#4da6ff,stroke:#0066cc,color:white
style ExtractTech fill:#f6546a,stroke:#c30052,color:white
style BuildValidationPlan fill:#10b981,stroke:#059669,color:white
style StartValidation fill:#f6546a,stroke:#c30052,color:white
\`\`\`
## 📋 COMPONENT LOADING SEQUENCE
The QA validation process follows this selective loading sequence:
1. **Main Entry (This File)**: `van-qa-main.mdc`
2. **Validation Checks**:
- `van-qa-checks/dependency-check.mdc`
- `van-qa-checks/config-check.mdc`
- `van-qa-checks/environment-check.mdc`
- `van-qa-checks/build-test.mdc`
3. **Utilities (As Needed)**:
- `van-qa-utils/reports.mdc`
- `van-qa-utils/common-fixes.mdc`
- `van-qa-utils/mode-transitions.mdc`
## 📋 FINAL QA VALIDATION CHECKPOINT
\`\`\`
✓ SECTION CHECKPOINT: QA VALIDATION
- Dependency Verification Passed? [YES/NO]
- Configuration Validation Passed? [YES/NO]
- Environment Validation Passed? [YES/NO]
- Minimal Build Test Passed? [YES/NO]
→ If all YES: Ready for BUILD mode transition.
→ If any NO: Fix identified issues and re-run VAN QA.
\`\`\`
**Next Step (on PASS):** Trigger BUILD mode (load `van-qa-utils/mode-transitions.mdc`).
**Next Step (on FAIL):** Address issues (load `van-qa-utils/common-fixes.mdc`) and re-run `VAN QA`.
```
## /.cursor/rules/isolation_rules/visual-maps/van_mode_split/van-qa-utils/common-fixes.mdc
```mdc path="/.cursor/rules/isolation_rules/visual-maps/van_mode_split/van-qa-utils/common-fixes.mdc"
---
description: Utility for VAN QA common validation fixes
globs: van-qa-utils/common-fixes.mdc
alwaysApply: false
---
# VAN QA: COMMON VALIDATION FIXES
> **TL;DR:** This component provides common fixes for issues that may arise during the QA validation process.
## 🧪 COMMON QA VALIDATION FIXES BY CATEGORY
### Dependency Issues
| Issue | Fix |
|-------|-----|
| **Missing Node.js** | Download and install Node.js from https://nodejs.org/ |
| **Outdated npm** | Run `npm install -g npm@latest` to update |
| **Missing packages** | Run `npm install` or `npm install [package-name]` |
| **Package version conflicts** | Adjust versions in package.json and run `npm install` |
| **Dependency resolution issues** | Run `npm cache clean -f` and try installing again |
### Configuration Issues
| Issue | Fix |
|-------|-----|
| **Invalid JSON** | Use a JSON validator (e.g., jsonlint) to check syntax |
| **Missing React plugin** | Add `import react from '@vitejs/plugin-react'` and `plugins: [react()]` to vite.config.js |
| **Incompatible TypeScript config** | Update `tsconfig.json` with correct React settings |
| **Mismatched version references** | Ensure consistent versions across configuration files |
| **Missing entries in config files** | Add required fields to configuration files |
### Environment Issues
| Issue | Fix |
|-------|-----|
| **Permission denied** | Run terminal as administrator (Windows) or use sudo (Mac/Linux) |
| **Port already in use** | Kill process using the port: `netstat -ano \| findstr :PORT` then `taskkill /F /PID PID` (Windows) or `lsof -i :PORT` then `kill -9 PID` (Mac/Linux) |
| **Missing build tools** | Install required command-line tools (git, node, etc.) |
| **Environment variable issues** | Set required environment variables: `$env:VAR_NAME = "value"` (PowerShell) or `export VAR_NAME="value"` (Bash) |
| **Disk space issues** | Free up disk space, clean npm/package cache files |
### Build Test Issues
| Issue | Fix |
|-------|-----|
| **Build fails** | Check console for specific error messages |
| **Test fails** | Verify minimal configuration is correct |
| **Path issues** | Ensure paths use correct separators for the platform (`\` for Windows, `/` for Mac/Linux) |
| **Missing dependencies** | Make sure all required dependencies are installed |
| **Script permissions** | Ensure script files have execution permissions (chmod +x on Unix) |
## 📝 ISSUE DIAGNOSIS PROCEDURES
### 1. Dependency Diagnosis
\`\`\`powershell
# Find conflicting dependencies
npm ls [package-name]
# Check for outdated packages
npm outdated
# Check for vulnerabilities
npm audit
\`\`\`
### 2. Configuration Diagnosis
\`\`\`powershell
# List all configuration files
Get-ChildItem -Recurse -Include "*.json","*.config.js" | Select-Object FullName
# Find missing references in tsconfig.json
if (Test-Path "tsconfig.json") {
$tsconfig = Get-Content "tsconfig.json" -Raw | ConvertFrom-Json
if (-not $tsconfig.compilerOptions.jsx) {
Write-Output "Missing jsx setting in tsconfig.json"
}
}
\`\`\`
### 3. Environment Diagnosis
\`\`\`powershell
# Check process using a port (Windows)
netstat -ano | findstr ":3000"
# List environment variables
Get-ChildItem Env:
# Check disk space
Get-PSDrive C | Select-Object Used,Free
\`\`\`
**Next Step:** Return to the validation process or follow the specific fix recommendations provided above.
```
## /.cursor/rules/isolation_rules/visual-maps/van_mode_split/van-qa-utils/mode-transitions.mdc
```mdc path="/.cursor/rules/isolation_rules/visual-maps/van_mode_split/van-qa-utils/mode-transitions.mdc"
---
description: Utility for VAN QA mode transitions
globs: van-qa-utils/mode-transitions.mdc
alwaysApply: false
---
# VAN QA: MODE TRANSITIONS
> **TL;DR:** This component handles transitions between modes, particularly the QA validation to BUILD mode transition, and prevents BUILD mode access without successful QA validation.
## 🔒 BUILD MODE PREVENTION MECHANISM
The system prevents moving to BUILD mode without passing QA validation:
\`\`\`mermaid
graph TD
Start["User Types: BUILD"] --> CheckQA{"QA Validation Completed?"}
CheckQA -->|"Yes and Passed"| AllowBuild["Allow BUILD Mode"]
CheckQA -->|"No or Failed"| BlockBuild["BLOCK BUILD MODE"]
BlockBuild --> Message["Display: ⚠️ QA VALIDATION REQUIRED"]
Message --> ReturnToVANQA["Prompt: Type VAN QA"]
style CheckQA fill:#f6546a,stroke:#c30052,color:white
style BlockBuild fill:#ff0000,stroke:#990000,color:white,stroke-width:3px
style Message fill:#ff5555,stroke:#dd3333,color:white
style ReturnToVANQA fill:#4da6ff,stroke:#0066cc,color:white
\`\`\`
### Implementation Example (PowerShell):
\`\`\`powershell
# Check QA status before allowing BUILD mode
function Check-QAValidationStatus {
$qaStatusFile = "memory-bank\.qa_validation_status" # Assumes status is written by reports.mdc
if (Test-Path $qaStatusFile) {
$status = Get-Content $qaStatusFile -Raw
if ($status -match "PASS") {
return $true
}
}
# Display block message
Write-Output "`n`n"
Write-Output "🚫🚫🚫🚫🚫🚫🚫🚫🚫🚫🚫🚫🚫🚫🚫🚫🚫🚫🚫🚫🚫🚫🚫🚫🚫🚫🚫🚫🚫"
Write-Output "⛔️ BUILD MODE BLOCKED: QA VALIDATION REQUIRED"
Write-Output "⛔️ You must complete QA validation before proceeding to BUILD mode"
Write-Output "`n"
Write-Output "Type 'VAN QA' to perform technical validation"
Write-Output "`n"
Write-Output "🚫 NO IMPLEMENTATION CAN PROCEED WITHOUT VALIDATION 🚫"
Write-Output "🚫🚫🚫🚫🚫🚫🚫🚫🚫🚫🚫🚫🚫🚫🚫🚫🚫🚫🚫🚫🚫🚫🚫🚫🚫🚫🚫🚫🚫"
return $false
}
\`\`\`
## 🚨 MODE TRANSITION TRIGGERS
### CREATIVE to VAN QA Transition:
After completing the CREATIVE phase, trigger this message to prompt QA validation:
\`\`\`
⏭️ NEXT MODE: VAN QA
To validate technical requirements before implementation, please type 'VAN QA'
\`\`\`
### VAN QA to BUILD Transition (On Success):
After successful QA validation, trigger this message to allow BUILD mode:
\`\`\`
✅ TECHNICAL VALIDATION COMPLETE
All prerequisites verified successfully
You may now proceed to BUILD mode
Type 'BUILD' to begin implementation
\`\`\`
### Manual BUILD Mode Access (When QA Already Passed):
When the user manually types 'BUILD', check the QA status before allowing access:
\`\`\`powershell
# Handle BUILD mode request
function Handle-BuildModeRequest {
if (Check-QAValidationStatus) {
# Allow transition to BUILD mode
Write-Output "`n"
Write-Output "✅ QA VALIDATION CHECK: PASSED"
Write-Output "Loading BUILD mode..."
Write-Output "`n"
# Here you would load the BUILD mode map
# [Code to load BUILD mode map]
return $true
}
# QA validation failed or not completed, BUILD mode blocked
return $false
}
\`\`\`
**Next Step (on QA SUCCESS):** Continue to BUILD mode.
**Next Step (on QA FAILURE):** Return to QA validation process.
```
## /.cursor/rules/isolation_rules/visual-maps/van_mode_split/van-qa-utils/reports.mdc
```mdc path="/.cursor/rules/isolation_rules/visual-maps/van_mode_split/van-qa-utils/reports.mdc"
---
description: Utility for VAN QA validation reports
globs: van-qa-utils/reports.mdc
alwaysApply: false
---
# VAN QA: VALIDATION REPORTS
> **TL;DR:** This component contains the formats for comprehensive success and failure reports generated upon completion of the QA validation process.
## 📋 COMPREHENSIVE SUCCESS REPORT FORMAT
After all four validation points pass, generate this success report:
\`\`\`
╔═════════════════════ 🔍 QA VALIDATION REPORT ══════════════════════╗
│ PROJECT: [Project Name] | TIMESTAMP: [Current Date/Time] │
├─────────────────────────────────────────────────────────────────────┤
│ 1️⃣ DEPENDENCIES: ✓ Compatible │
│ 2️⃣ CONFIGURATION: ✓ Valid & Compatible │
│ 3️⃣ ENVIRONMENT: ✓ Ready │
│ 4️⃣ MINIMAL BUILD: ✓ Successful & Passed │
├─────────────────────────────────────────────────────────────────────┤
│ 🚨 FINAL VERDICT: PASS │
│ ➡️ Clear to proceed to BUILD mode │
╚═════════════════════════════════════════════════════════════════════╝
\`\`\`
### Success Report Generation Example:
\`\`\`powershell
function Generate-SuccessReport {
param (
[string]$ProjectName = "Current Project"
)
$timestamp = Get-Date -Format "yyyy-MM-dd HH:mm:ss"
$report = @"
╔═════════════════════ 🔍 QA VALIDATION REPORT ══════════════════════╗
│ PROJECT: $ProjectName | TIMESTAMP: $timestamp │
├─────────────────────────────────────────────────────────────────────┤
│ 1️⃣ DEPENDENCIES: ✓ Compatible │
│ 2️⃣ CONFIGURATION: ✓ Valid & Compatible │
│ 3️⃣ ENVIRONMENT: ✓ Ready │
│ 4️⃣ MINIMAL BUILD: ✓ Successful & Passed │
├─────────────────────────────────────────────────────────────────────┤
│ 🚨 FINAL VERDICT: PASS │
│ ➡️ Clear to proceed to BUILD mode │
╚═════════════════════════════════════════════════════════════════════╝
"@
# Save validation status (used by BUILD mode prevention mechanism)
"PASS" | Set-Content -Path "memory-bank\.qa_validation_status"
return $report
}
\`\`\`
## ❌ FAILURE REPORT FORMAT
If any validation step fails, generate this detailed failure report:
\`\`\`
⚠️⚠️⚠️ QA VALIDATION FAILED ⚠️⚠️⚠️
The following issues must be resolved before proceeding to BUILD mode:
1️⃣ DEPENDENCY ISSUES:
- [Detailed description of dependency issues]
- [Recommended fix]
2️⃣ CONFIGURATION ISSUES:
- [Detailed description of configuration issues]
- [Recommended fix]
3️⃣ ENVIRONMENT ISSUES:
- [Detailed description of environment issues]
- [Recommended fix]
4️⃣ BUILD TEST ISSUES:
- [Detailed description of build test issues]
- [Recommended fix]
⚠️ BUILD MODE IS BLOCKED until these issues are resolved.
Type 'VAN QA' after fixing the issues to re-validate.
\`\`\`
### Failure Report Generation Example:
\`\`\`powershell
function Generate-FailureReport {
param (
[string[]]$DependencyIssues = @(),
[string[]]$ConfigIssues = @(),
[string[]]$EnvironmentIssues = @(),
[string[]]$BuildIssues = @()
)
$report = @"
⚠️⚠️⚠️ QA VALIDATION FAILED ⚠️⚠️⚠️
The following issues must be resolved before proceeding to BUILD mode:
"@
if ($DependencyIssues.Count -gt 0) {
$report += @"
1️⃣ DEPENDENCY ISSUES:
$(($DependencyIssues | ForEach-Object { "- $_" }) -join "`n")
"@
}
if ($ConfigIssues.Count -gt 0) {
$report += @"
2️⃣ CONFIGURATION ISSUES:
$(($ConfigIssues | ForEach-Object { "- $_" }) -join "`n")
"@
}
if ($EnvironmentIssues.Count -gt 0) {
$report += @"
3️⃣ ENVIRONMENT ISSUES:
$(($EnvironmentIssues | ForEach-Object { "- $_" }) -join "`n")
"@
}
if ($BuildIssues.Count -gt 0) {
$report += @"
4️⃣ BUILD TEST ISSUES:
$(($BuildIssues | ForEach-Object { "- $_" }) -join "`n")
"@
}
$report += @"
⚠️ BUILD MODE IS BLOCKED until these issues are resolved.
Type 'VAN QA' after fixing the issues to re-validate.
"@
# Save validation status (used by BUILD mode prevention mechanism)
"FAIL" | Set-Content -Path "memory-bank\.qa_validation_status"
return $report
}
\`\`\`
**Next Step (on SUCCESS):** Load `van-qa-utils/mode-transitions.mdc` to handle BUILD mode transition.
**Next Step (on FAILURE):** Load `van-qa-utils/common-fixes.mdc` for issue remediation guidance.
```
## /.cursor/rules/isolation_rules/visual-maps/van_mode_split/van-qa-utils/rule-calling-guide.mdc
```mdc path="/.cursor/rules/isolation_rules/visual-maps/van_mode_split/van-qa-utils/rule-calling-guide.mdc"
---
description: Comprehensive guide for calling VAN QA rules
globs: van-qa-utils/rule-calling-guide.mdc
alwaysApply: false
---
# VAN QA: COMPREHENSIVE RULE CALLING GUIDE
> **TL;DR:** This reference guide shows how to properly call all VAN QA rules at the right time during the validation process.
## 🔍 RULE CALLING BASICS
Remember these key principles:
1. Always use the `fetch_rules` tool to load rules
2. Use exact rule paths
3. Load components only when needed
## 📋 MAIN QA ENTRY POINT
When user types "VAN QA", load the main entry point:
\`\`\`
fetch_rules with "isolation_rules/visual-maps/van-qa-main"
\`\`\`
## 📋 VALIDATION CHECKS
Load these components sequentially during validation:
\`\`\`
1. fetch_rules with "isolation_rules/visual-maps/van-qa-checks/dependency-check"
2. fetch_rules with "isolation_rules/visual-maps/van-qa-checks/config-check"
3. fetch_rules with "isolation_rules/visual-maps/van-qa-checks/environment-check"
4. fetch_rules with "isolation_rules/visual-maps/van-qa-checks/build-test"
\`\`\`
## 📋 UTILITY COMPONENTS
Load these when needed based on validation results:
\`\`\`
- For reports: fetch_rules with "isolation_rules/visual-maps/van-qa-utils/reports"
- For fixes: fetch_rules with "isolation_rules/visual-maps/van-qa-utils/common-fixes"
- For transitions: fetch_rules with "isolation_rules/visual-maps/van-qa-utils/mode-transitions"
\`\`\`
## ⚠️ CRITICAL REMINDERS
Remember to call these rules at these specific points:
- ALWAYS load the main QA entry point when "VAN QA" is typed
- ALWAYS load dependency-check before starting validation
- ALWAYS load reports after completing validation
- ALWAYS load mode-transitions after successful validation
- ALWAYS load common-fixes after failed validation
## 🔄 FULL VALIDATION SEQUENCE
Complete sequence for a QA validation process:
1. Load main entry: `isolation_rules/visual-maps/van-qa-main`
2. Load first check: `isolation_rules/visual-maps/van-qa-checks/dependency-check`
3. Load second check: `isolation_rules/visual-maps/van-qa-checks/config-check`
4. Load third check: `isolation_rules/visual-maps/van-qa-checks/environment-check`
5. Load fourth check: `isolation_rules/visual-maps/van-qa-checks/build-test`
6. If pass, load: `isolation_rules/visual-maps/van-qa-utils/reports`
7. If pass, load: `isolation_rules/visual-maps/van-qa-utils/mode-transitions`
8. If fail, load: `isolation_rules/visual-maps/van-qa-utils/common-fixes`
```
## /.cursor/rules/isolation_rules/visual-maps/van_mode_split/van-qa-utils/rule-calling-help.mdc
```mdc path="/.cursor/rules/isolation_rules/visual-maps/van_mode_split/van-qa-utils/rule-calling-help.mdc"
---
description: Utility for remembering how to call VAN QA rules
globs: van-qa-utils/rule-calling-help.mdc
alwaysApply: false
---
# VAN QA: HOW TO CALL RULES
> **TL;DR:** This file provides examples and reminders on how to properly call VAN QA rules using the fetch_rules tool.
## 🚨 RULE CALLING SYNTAX
Always use the `fetch_rules` tool with the correct syntax:
\`\`\`
["isolation_rules/visual-maps/rule-name"]
```
## /.cursor/rules/isolation_rules/visual-maps/van_mode_split/van-qa-validation.md.old
```old path="/.cursor/rules/isolation_rules/visual-maps/van_mode_split/van-qa-validation.md.old"
# VAN MODE: QA TECHNICAL VALIDATION (Pre-BUILD)
> **TL;DR:** This map details the technical validation process executed *after* CREATIVE mode and *before* BUILD mode, triggered by the `VAN QA` command. It ensures dependencies, configuration, environment, and basic build functionality are sound.
## 🚀 VAN QA MODE ACTIVATION
After completing CREATIVE mode, when the user types "VAN QA", respond:
\`\`\`
User: VAN QA
Response: OK VAN QA - Beginning Technical Validation
Loading QA Validation map...
\`\`\`
## 🔄 QA COMMAND PRECEDENCE (QA Override)
QA validation can be called at any point (`QA` command) and takes immediate precedence:
\`\`\`mermaid
graph TD
UserQA["User Types: QA"] --> HighPriority["⚠️ HIGH PRIORITY COMMAND"]
HighPriority --> CurrentTask["Pause Current Task/Process"]
CurrentTask --> LoadQA["Load QA Validation Map (This File)"]
LoadQA --> RunQA["Execute QA Validation Process"]
RunQA --> QAResults{"QA Results"}
QAResults -->|"PASS"| ResumeFlow["Resume Prior Process Flow"]
QAResults -->|"FAIL"| FixIssues["Fix Identified Issues"]
FixIssues --> ReRunQA["Re-run QA Validation"]
ReRunQA --> QAResults
style UserQA fill:#f8d486,stroke:#e8b84d,color:black
style HighPriority fill:#ff0000,stroke:#cc0000,color:white,stroke-width:3px
style LoadQA fill:#4da6ff,stroke:#0066cc,color:white
style RunQA fill:#4da6ff,stroke:#0066cc,color:white
style QAResults fill:#f6546a,stroke:#c30052,color:white
\`\`\`
### QA Interruption Rules
1. **Immediate Precedence:** `QA` command interrupts everything.
2. **Load & Execute:** Load this map (`van-qa-validation.mdc`) and run the full process.
3. **Remediation Priority:** Fixes take priority over pending mode switches.
4. **Resume:** On PASS, resume the previous flow.
\`\`\`
⚠️ QA OVERRIDE ACTIVATED
All other processes paused
QA validation checks now running...
Any issues found MUST be remediated before continuing with normal process flow
\`\`\`
## 🔍 TECHNICAL VALIDATION OVERVIEW
Four-point validation process:
\`\`\`mermaid
graph TD
VANQA["VAN QA MODE"] --> FourChecks["FOUR-POINT VALIDATION"]
FourChecks --> DepCheck["1️⃣ DEPENDENCY VERIFICATION"]
DepCheck --> ConfigCheck["2️⃣ CONFIGURATION VALIDATION"]
ConfigCheck --> EnvCheck["3️⃣ ENVIRONMENT VALIDATION"]
EnvCheck --> MinBuildCheck["4️⃣ MINIMAL BUILD TEST"]
MinBuildCheck --> ValidationResults{"All Checks Passed?"}
ValidationResults -->|"Yes"| SuccessReport["GENERATE SUCCESS REPORT"]
ValidationResults -->|"No"| FailureReport["GENERATE FAILURE REPORT"]
SuccessReport --> BUILD_Transition["Trigger BUILD Mode"]
FailureReport --> FixIssues["Fix Technical Issues"]
FixIssues --> ReValidate["Re-validate (Re-run VAN QA)"]
ReValidate --> FourChecks
style VANQA fill:#4da6ff,stroke:#0066cc,color:white
style FourChecks fill:#f6546a,stroke:#c30052,color:white
style ValidationResults fill:#f6546a,stroke:#c30052,color:white
style BUILD_Transition fill:#10b981,stroke:#059669,color:white
style FixIssues fill:#ff5555,stroke:#dd3333,color:white
\`\`\`
## 🔄 INTEGRATION WITH DESIGN DECISIONS
Reads Creative Phase outputs (e.g., `memory-bank/systemPatterns.md`) to inform validation:
\`\`\`mermaid
graph TD
Start["Read Design Decisions"] --> ReadCreative["Parse Creative Phase Documentation"]
ReadCreative --> ExtractTech["Extract Technology Choices"]
ExtractTech --> ExtractDeps["Extract Required Dependencies"]
ExtractDeps --> BuildValidationPlan["Build Validation Plan"]
BuildValidationPlan --> StartValidation["Start Four-Point Validation Process"]
style Start fill:#4da6ff,stroke:#0066cc,color:white
style ExtractTech fill:#f6546a,stroke:#c30052,color:white
style BuildValidationPlan fill:#10b981,stroke:#059669,color:white
style StartValidation fill:#f6546a,stroke:#c30052,color:white
\`\`\`
### Example Technology Extraction (PowerShell):
\`\`\`powershell
# Example: Extract technology choices from creative phase documentation
function Extract-TechnologyChoices {
$techChoices = @{}
# Read from systemPatterns.md
if (Test-Path "memory-bank\systemPatterns.md") {
$content = Get-Content "memory-bank\systemPatterns.md" -Raw
if ($content -match "Framework:\s*(\w+)") { $techChoices["framework"] = $Matches[1] }
if ($content -match "UI Library:\s*(\w+)") { $techChoices["ui_library"] = $Matches[1] }
if ($content -match "State Management:\s*([^\n]+)") { $techChoices["state_management"] = $Matches[1].Trim() }
}
return $techChoices
}
\`\`\`
## 🔍 DETAILED QA VALIDATION STEPS & SCRIPTS
### 1️⃣ DEPENDENCY VERIFICATION
\`\`\`mermaid
# Mermaid graph for Dependency Verification (as in original file)
graph TD
Start["Dependency Verification"] --> ReadDeps["Read Required Dependencies from Creative Phase"]
ReadDeps --> CheckInstalled["Check if Dependencies are Installed"]
CheckInstalled --> DepStatus{"All Dependencies Installed?"}
DepStatus -->|"Yes"| VerifyVersions["Verify Versions and Compatibility"]
DepStatus -->|"No"| InstallMissing["Install Missing Dependencies"]
InstallMissing --> VerifyVersions
VerifyVersions --> VersionStatus{"Versions Compatible?"}
VersionStatus -->|"Yes"| DepSuccess["Dependencies Verified ✅ PASS"]
VersionStatus -->|"No"| UpgradeVersions["Upgrade/Downgrade as Needed"]
UpgradeVersions --> RetryVerify["Retry Verification"]
RetryVerify --> VersionStatus
style Start fill:#4da6ff; style DepSuccess fill:#10b981; style DepStatus fill:#f6546a; style VersionStatus fill:#f6546a;
\`\`\`
#### Example Implementation (PowerShell):
\`\`\`powershell
# Verify-Dependencies function (as in original file)
function Verify-Dependencies {
$requiredDeps = @{ "node" = ">=14.0.0"; "npm" = ">=6.0.0" }
$missingDeps = @(); $incompatibleDeps = @()
try { $nodeVersion = node -v; if ($nodeVersion -match "v(\d+).*") { if ([int]$Matches[1] -lt 14) { $incompatibleDeps += "node" } } } catch { $missingDeps += "node" }
try { $npmVersion = npm -v; if ($npmVersion -match "(\d+).*") { if ([int]$Matches[1] -lt 6) { $incompatibleDeps += "npm" } } } catch { $missingDeps += "npm" }
if ($missingDeps.Count -eq 0 -and $incompatibleDeps.Count -eq 0) { Write-Output "✅ Deps OK"; return $true } else { Write-Output "❌ Deps FAIL"; return $false }
}
\`\`\`
#### Example Implementation (Bash):
\`\`\`bash
# verify_dependencies function (as in original file)
verify_dependencies() {
local missing_deps=(); local incompatible_deps=()
if command -v node &> /dev/null; then node_version=$(node -v); if [[ $node_version =~ v([0-9]+) ]]; then if (( ${BASH_REMATCH[1]} < 14 )); then incompatible_deps+=("node"); fi; fi; else missing_deps+=("node"); fi
if command -v npm &> /dev/null; then npm_version=$(npm -v); if [[ $npm_version =~ ([0-9]+) ]]; then if (( ${BASH_REMATCH[1]} < 6 )); then incompatible_deps+=("npm"); fi; fi; else missing_deps+=("npm"); fi
if [ ${#missing_deps[@]} -eq 0 ] && [ ${#incompatible_deps[@]} -eq 0 ]; then echo "✅ Deps OK"; return 0; else echo "❌ Deps FAIL"; return 1; fi
}
\`\`\`
### 2️⃣ CONFIGURATION VALIDATION
\`\`\`mermaid
# Mermaid graph for Configuration Validation (as in original file)
graph TD
Start["Configuration Validation"] --> IdentifyConfigs["Identify Files"]
IdentifyConfigs --> ReadConfigs["Read Files"]
ReadConfigs --> ValidateSyntax["Validate Syntax"]
ValidateSyntax --> SyntaxStatus{"Valid?"}
SyntaxStatus -->|"Yes"| CheckCompatibility["Check Compatibility"]
SyntaxStatus -->|"No"| FixSyntax["Fix Syntax"]
FixSyntax --> RetryValidate["Retry"]
RetryValidate --> SyntaxStatus
CheckCompatibility --> CompatStatus{"Compatible?"}
CompatStatus -->|"Yes"| ConfigSuccess["Configs Validated ✅ PASS"]
CompatStatus -->|"No"| AdaptConfigs["Adapt Configs"]
AdaptConfigs --> RetryCompat["Retry Check"]
RetryCompat --> CompatStatus
style Start fill:#4da6ff; style ConfigSuccess fill:#10b981; style SyntaxStatus fill:#f6546a; style CompatStatus fill:#f6546a;
\`\`\`
#### Example Implementation (PowerShell):
\`\`\`powershell
# Validate-Configurations function (as in original file)
function Validate-Configurations {
$configFiles = @("package.json", "tsconfig.json", "vite.config.js")
$invalidConfigs = @(); $incompatibleConfigs = @()
foreach ($configFile in $configFiles) {
if (Test-Path $configFile) {
if ($configFile -match "\.json$") { try { Get-Content $configFile -Raw | ConvertFrom-Json | Out-Null } catch { $invalidConfigs += "$configFile (JSON)"; continue } }
if ($configFile -eq "vite.config.js") { $content = Get-Content $configFile -Raw; if ($content -notmatch "react\(\)") { $incompatibleConfigs += "$configFile (React)" } }
} else { $invalidConfigs += "$configFile (missing)" }
}
if ($invalidConfigs.Count -eq 0 -and $incompatibleConfigs.Count -eq 0) { Write-Output "✅ Configs OK"; return $true } else { Write-Output "❌ Configs FAIL"; return $false }
}
\`\`\`
### 3️⃣ ENVIRONMENT VALIDATION
\`\`\`mermaid
# Mermaid graph for Environment Validation (as in original file)
graph TD
Start["Environment Validation"] --> CheckEnv["Check Env"]
CheckEnv --> VerifyBuildTools["Verify Tools"]
VerifyBuildTools --> ToolsStatus{"Available?"}
ToolsStatus -->|"Yes"| CheckPerms["Check Permissions"]
ToolsStatus -->|"No"| InstallTools["Install Tools"]
InstallTools --> RetryTools["Retry"]
RetryTools --> ToolsStatus
CheckPerms --> PermsStatus{"Sufficient?"}
PermsStatus -->|"Yes"| EnvSuccess["Environment Validated ✅ PASS"]
PermsStatus -->|"No"| FixPerms["Fix Permissions"]
FixPerms --> RetryPerms["Retry Check"]
RetryPerms --> PermsStatus
style Start fill:#4da6ff; style EnvSuccess fill:#10b981; style ToolsStatus fill:#f6546a; style PermsStatus fill:#f6546a;
\`\`\`
#### Example Implementation (PowerShell):
\`\`\`powershell
# Validate-Environment function (as in original file)
function Validate-Environment {
$requiredTools = @(@{Name='git';Cmd='git --version'},@{Name='node';Cmd='node --version'},@{Name='npm';Cmd='npm --version'})
$missingTools = @(); $permissionIssues = @()
foreach ($tool in $requiredTools) { try { Invoke-Expression $tool.Cmd | Out-Null } catch { $missingTools += $tool.Name } }
try { $testFile = ".__perm_test"; New-Item $testFile -ItemType File -Force | Out-Null; Remove-Item $testFile -Force } catch { $permissionIssues += "CWD Write" }
try { $L = New-Object Net.Sockets.TcpListener([Net.IPAddress]::Loopback, 3000); $L.Start(); $L.Stop() } catch { $permissionIssues += "Port 3000" }
if ($missingTools.Count -eq 0 -and $permissionIssues.Count -eq 0) { Write-Output "✅ Env OK"; return $true } else { Write-Output "❌ Env FAIL"; return $false }
}
\`\`\`
### 4️⃣ MINIMAL BUILD TEST
\`\`\`mermaid
# Mermaid graph for Minimal Build Test (as in original file)
graph TD
Start["Minimal Build Test"] --> CreateTest["Create Test Proj"]
CreateTest --> BuildTest["Attempt Build"]
BuildTest --> BuildStatus{"Success?"}
BuildStatus -->|"Yes"| RunTest["Run Basic Test"]
BuildStatus -->|"No"| FixBuild["Fix Build Issues"]
FixBuild --> RetryBuild["Retry Build"]
RetryBuild --> BuildStatus
RunTest --> TestStatus{"Passed?"}
TestStatus -->|"Yes"| TestSuccess["Build Test ✅ PASS"]
TestStatus -->|"No"| FixTest["Fix Test Issues"]
FixTest --> RetryTest["Retry Test"]
RetryTest --> TestStatus
style Start fill:#4da6ff; style TestSuccess fill:#10b981; style BuildStatus fill:#f6546a; style TestStatus fill:#f6546a;
\`\`\`
#### Example Implementation (PowerShell):
\`\`\`powershell
# Perform-MinimalBuildTest function (as in original file)
function Perform-MinimalBuildTest {
$buildSuccess = $false; $testSuccess = $false; $testDir = ".__build_test"
if (Test-Path $testDir) { Remove-Item $testDir -Recurse -Force }
try {
New-Item $testDir -ItemType Directory | Out-Null; Push-Location $testDir
'{"name": "build-test","scripts": {"build": "echo Build test successful"}}' | Set-Content package.json
npm run build | Out-Null; $buildSuccess = $true
'console.log("Test successful");' | Set-Content index.js
node index.js | Out-Null; $testSuccess = $true
} catch { Write-Output "❌ Build test exception" } finally { Pop-Location; if (Test-Path $testDir) { Remove-Item $testDir -Recurse -Force } }
if ($buildSuccess -and $testSuccess) { Write-Output "✅ Build Test OK"; return $true } else { Write-Output "❌ Build Test FAIL"; return $false }
}
\`\`\`
## 📝 VALIDATION REPORT FORMATS
### Comprehensive Success Report:
\`\`\`
╔═════════════════════ 🔍 QA VALIDATION REPORT ══════════════════════╗
│ PROJECT: [Project Name] | TIMESTAMP: [Current Date/Time] │
├─────────────────────────────────────────────────────────────────────┤
│ 1️⃣ DEPENDENCIES: ✓ Compatible │
│ 2️⃣ CONFIGURATION: ✓ Valid & Compatible │
│ 3️⃣ ENVIRONMENT: ✓ Ready │
│ 4️⃣ MINIMAL BUILD: ✓ Successful & Passed │
├─────────────────────────────────────────────────────────────────────┤
│ 🚨 FINAL VERDICT: PASS │
│ ➡️ Clear to proceed to BUILD mode │
╚═════════════════════════════════════════════════════════════════════╝
\`\`\`
### Detailed Failure Report:
\`\`\`
⚠️⚠️⚠️ QA VALIDATION FAILED ⚠️⚠️⚠️
Issues must be resolved before BUILD mode:
1️⃣ DEPENDENCY ISSUES: [Details/Fix]
2️⃣ CONFIGURATION ISSUES: [Details/Fix]
3️⃣ ENVIRONMENT ISSUES: [Details/Fix]
4️⃣ BUILD TEST ISSUES: [Details/Fix]
⚠️ BUILD MODE BLOCKED. Type 'VAN QA' after fixing to re-validate.
\`\`\`
## 🧪 COMMON QA VALIDATION FIXES
- **Dependencies:** Install Node/npm, run `npm install`, check versions.
- **Configuration:** Validate JSON, check required plugins (e.g., React for Vite), ensure TSConfig compatibility.
- **Environment:** Check permissions (Admin/sudo), ensure ports are free, install missing CLI tools (git, etc.).
- **Build Test:** Check logs for errors, verify minimal config, check path separators.
## 🔒 BUILD MODE PREVENTION MECHANISM
Logic to check QA status before allowing BUILD mode transition.
\`\`\`mermaid
graph TD
Start["User Types: BUILD"] --> CheckQA{"QA Validation Passed?"}
CheckQA -->|"Yes"| AllowBuild["Allow BUILD Mode"]
CheckQA -->|"No"| BlockBuild["BLOCK BUILD MODE"]
BlockBuild --> Message["Display: ⚠️ QA VALIDATION REQUIRED"]
Message --> ReturnToVANQA["Prompt: Type VAN QA"]
style CheckQA fill:#f6546a; style BlockBuild fill:#ff0000,stroke:#990000; style Message fill:#ff5555; style ReturnToVANQA fill:#4da6ff;
\`\`\`
### Example Implementation (PowerShell):
\`\`\`powershell
# Example: Check QA status before allowing BUILD
function Check-QAValidationStatus {
$qaStatusFile = "memory-bank\.qa_validation_status" # Assumes status is written here
if (Test-Path $qaStatusFile) {
if ((Get-Content $qaStatusFile -Raw) -match "PASS") { return $true }
}
Write-Output "🚫 BUILD MODE BLOCKED: QA VALIDATION REQUIRED. Type 'VAN QA'. 🚫"
return $false
}
\`\`\`
## 🚨 MODE TRANSITION TRIGGERS (Relevant to QA)
### CREATIVE to VAN QA Transition:
\`\`\`
⏭️ NEXT MODE: VAN QA
To validate technical requirements before implementation, please type 'VAN QA'
\`\`\`
### VAN QA to BUILD Transition (On Success):
\`\`\`
✅ TECHNICAL VALIDATION COMPLETE
All prerequisites verified successfully
You may now proceed to BUILD mode
Type 'BUILD' to begin implementation
\`\`\`
## 📋 FINAL QA VALIDATION CHECKPOINT
\`\`\`
✓ SECTION CHECKPOINT: QA VALIDATION
- Dependency Verification Passed? [YES/NO]
- Configuration Validation Passed? [YES/NO]
- Environment Validation Passed? [YES/NO]
- Minimal Build Test Passed? [YES/NO]
→ If all YES: Ready for BUILD mode transition.
→ If any NO: Fix identified issues and re-run VAN QA.
\`\`\`
**Next Step (on PASS):** Trigger BUILD mode.
**Next Step (on FAIL):** Address issues and re-run `VAN QA`.
```
## /.gitignore
```gitignore path="/.gitignore"
# OS specific files
.DS_Store
Thumbs.db
desktop.ini
# Editor specific files
.vscode/
.idea/
*.swp
*.swo
*~
# Node.js
node_modules/
npm-debug.log
yarn-error.log
package-lock.json
yarn.lock
# Python
__pycache__/
*.py[cod]
*$py.class
.pytest_cache/
.coverage
htmlcov/
.tox/
.nox/
.hypothesis/
.pytest_cache/
*.egg-info/
# Ruby
*.gem
*.rbc
/.config
/coverage/
/InstalledFiles
/pkg/
/spec/reports/
/spec/examples.txt
/test/tmp/
/test/version_tmp/
/tmp/
# Java
*.class
*.log
*.jar
*.war
*.nar
*.ear
*.zip
*.tar.gz
*.rar
hs_err_pid*
# Logs
logs/
*.log
npm-debug.log*
yarn-debug.log*
yarn-error.log*
# Runtime data
pids
*.pid
*.seed
*.pid.lock
# Cursor specific
.cursor/workspace/
```
## /README.md
# Memory Bank System v0.6-beta
A modular, graph-based task management system that integrates with Cursor custom modes for efficient development workflows.
```mermaid
graph TD
Main["Memory Bank System"] --> Modes["Custom Modes"]
Main --> Rules["JIT Rule Loading"]
Main --> Visual["Visual Process Maps"]
Modes --> VAN["VAN: Initialization"]
Modes --> PLAN["PLAN: Task Planning"]
Modes --> CREATIVE["CREATIVE: Design"]
Modes --> IMPLEMENT["IMPLEMENT: Building"]
style Main fill:#4da6ff,stroke:#0066cc,color:white
style Modes fill:#f8d486,stroke:#e8b84d
style Rules fill:#80ffaa,stroke:#4dbb5f
style Visual fill:#d9b3ff,stroke:#b366ff
```
> **Development Status**: This system is actively under development. Features will be added and optimized over time. If you prefer stability over new features, you may continue using the previous version (v0.1-legacy), but please read about the architectural changes described in the [Memory Bank Upgrade Guide](memory_bank_upgrade_guide.md) to understand the benefits of this new approach.
## About Memory Bank
Memory Bank is a personal project that provides a structured approach to development using specialized modes for different phases of the development process. It uses a Just-In-Time (JIT) rule loading architecture that loads only the rules needed for each phase, optimizing context usage and providing tailored guidance.
### Beyond Basic Custom Modes
While Cursor's documentation describes custom modes as primarily standalone configurations with basic prompts and tool selections, Memory Bank significantly extends this concept:
- **Graph-Based Mode Integration**: Modes are interconnected nodes in a development workflow rather than isolated tools
- **Workflow Progression**: Modes are designed to transition from one to another in a logical sequence (VAN → PLAN → CREATIVE → IMPLEMENT)
- **Shared Memory**: Persistent state maintained across mode transitions via Memory Bank files
- **Adaptive Behavior**: Each mode adjusts its recommendations based on project complexity
- **Built-in QA Functions**: QA capabilities can be called from any mode for technical validation
This approach transforms custom modes from simple AI personalities into components of a coordinated development system with specialized phases working together.
### Isolated Rules Architecture
A key architectural change in v0.6-beta is the complete isolation of rules to custom modes:
- **No Global Rules**: Unlike the previous version, this system doesn't use global rules that affect all AI interactions
- **Mode-Specific Rules Only**: All rules are contained within their specific custom modes, with VAN serving as the entry point
- **Non-Interference**: When you're not using one of the Memory Bank custom modes, your regular Cursor usage remains completely unaffected by any Memory Bank customizations
- **Future-Proofing**: This isolation keeps the global rules space free and available for potential future features
This architectural change gives you much more control over when and how the Memory Bank system affects your Cursor experience.
### CREATIVE Mode and Claude's "Think" Tool
The CREATIVE mode in Memory Bank is conceptually based on Anthropic's Claude "Think" tool methodology, as described in their [engineering blog](https://www.anthropic.com/engineering/claude-think-tool). Key principles include:
- Structured exploration of design options
- Explicit documentation of pros and cons for different approaches
- Breaking complex problems into manageable components
- Systematic process to evaluate alternatives before making decisions
- Documentation of reasoning processes for future reference
For a detailed explanation of how Memory Bank implements these principles, including code examples and diagrams, see the [CREATIVE Mode and Claude's "Think" Tool](creative_mode_think_tool.md) document.
This implementation will continue to be refined and optimized as Claude's capabilities evolve, maintaining the core methodology while enhancing integration with the Memory Bank ecosystem.
## Key Features
- **Mode-Specific Visual Maps**: Clear visual representations for each development phase
- **Just-In-Time Rule Loading**: Load only the rules needed for your current task
- **Visual Decision Trees**: Guided workflows with clear checkpoints
- **Technical Validation**: QA processes that can be called from any mode
- **Platform-Aware Commands**: Automatically adapts commands to your operating system
## Installation Instructions
### Prerequisites
- **Cursor Editor**: Version 0.48 or higher is required.
- **Custom Modes**: Feature must be enabled in Cursor (Settings → Features → Chat → Custom modes).
- **AI Model**: Claude 3.7 Sonnet is recommended for best results, especially for CREATIVE mode's "Think" tool methodology. Other models may work, but their interpretations might vary, potentially requiring some trial and error.
### Step 1: Get the Files
Simply clone this repository into your project directory:
```
git clone https://github.com/vanzan01/cursor-memory-bank.git
```
Alternatively, you can download the ZIP file from GitHub and extract it to your project folder.
This provides you with all the necessary files, including:
- Rule files in `.cursor/rules/isolation_rules/`
- Mode instruction files in `custom_modes/` directory
- Template Memory Bank files in `memory-bank/`
### Step 2: Setting Up Custom Modes in Cursor
**This is the most critical and challenging part of the setup.** You'll need to manually create four custom modes in Cursor and copy the instruction content from the provided files:
#### How to Add a Custom Mode in Cursor
1. Open Cursor and click on the mode selector in the chat panel
2. Select "Add custom mode"
3. In the configuration screen:
- Enter the mode name (you can include emoji icons like 🔍, 📋, 🎨, ⚒️ by copy-pasting them at the beginning of the name)
- Select an icon from Cursor's limited predefined options (note: Cursor offers only a few basic icons, but you can use emoji in the name as a workaround)
- Add a shortcut (optional)
- Check the required tools
- Click on **Advanced options**
- In the empty text box that appears at the bottom, paste the custom instruction content from the corresponding file
Example configuration screen:
Result in mode selection menu:
#### Mode 1: VAN MODE (Initialization)
Configure as follows:
- **Name**: 🔍 VAN (copy-paste the magnifying glass emoji)
- **Icon**: Choose any available icon from Cursor's limited selection
- **Tools**: Enable "Codebase Search", "Read File", "Terminal", "List Directory"
- **Advanced options**: Paste the content from `custom_modes/van_instructions.md` in this repository into the text box at the bottom
#### Mode 2: PLAN MODE (Task Planning)
Configure as follows:
- **Name**: 📋 PLAN (copy-paste the clipboard emoji)
- **Icon**: Choose any available icon from Cursor's limited selection
- **Tools**: Enable "Codebase Search", "Read File", "Terminal", "List Directory"
- **Advanced options**: Paste the content from `custom_modes/plan_instructions.md` in this repository into the text box at the bottom
#### Mode 3: CREATIVE MODE (Design Decisions)
Configure as follows:
- **Name**: 🎨 CREATIVE (copy-paste the artist palette emoji)
- **Icon**: Choose any available icon from Cursor's limited selection
- **Tools**: Enable "Codebase Search", "Read File", "Terminal", "List Directory", "Edit File"
- **Advanced options**: Paste the content from `custom_modes/creative_instructions.md` in this repository into the text box at the bottom
#### Mode 4: IMPLEMENT MODE (Code Implementation)
Configure as follows:
- **Name**: ⚒️ IMPLEMENT (copy-paste the hammer and pick emoji)
- **Icon**: Choose any available icon from Cursor's limited selection
- **Tools**: Enable all tools
- **Advanced options**: Paste the content from `custom_modes/implement_instructions.md` in this repository into the text box at the bottom
For additional help on setting up custom modes in Cursor, refer to the [official Cursor documentation on custom modes](https://docs.cursor.com/chat/custom-modes).
### QA Functionality
QA is not a separate custom mode but rather a set of validation functions that can be called from any mode. You can invoke QA capabilities by typing "QA" in any mode when you need to perform technical validation. This approach provides flexibility to conduct verification at any point in the development process.
### File Structure Reference
After cloning, you'll have this directory structure:
```
your-project/
├── .cursor/
│ └── rules/
│ └── isolation_rules/
│ ├── Core/
│ ├── Level3/
│ ├── Phases/
│ │ └── CreativePhase/
│ ├── visual-maps/
│ │ └── van_mode_split/
│ └── main.mdc
├── memory-bank/
│ ├── tasks.md
│ ├── activeContext.md
│ └── progress.md
└── custom_modes/
├── van_instructions.md
├── plan_instructions.md
├── creative_instructions.md
├── implement_instructions.md
```
## Basic Usage
1. **Start with VAN Mode**:
- Switch to VAN mode in Cursor
- Type "VAN" to initiate the initialization process
- VAN will analyze your project structure and determine complexity
2. **Follow the Workflow Based on Complexity**:
- **Level 1 tasks**: May proceed directly to IMPLEMENT after VAN
- **Level 2-4 tasks**: Follow the full workflow (VAN → PLAN → CREATIVE → IMPLEMENT)
- **At any point**: Type "QA" to perform technical validation
3. **Mode-Specific Commands**:
```
VAN - Initialize project and determine complexity
PLAN - Create detailed implementation plan
CREATIVE - Explore design options for complex components
IMPLEMENT - Systematically build planned components
QA - Validate technical implementation (can be called from any mode)
```
## Core Files and Their Purposes
```mermaid
graph LR
subgraph "Memory Bank Files"
Tasks["tasks.md Source of Truth"]
Active["activeContext.md Current Focus"]
Progress["progress.md Implementation Status"]
Creative["creative-*.md Design Decisions"]
end
style Tasks fill:#f9d77e,stroke:#d9b95c,stroke-width:3px
style Active fill:#a8d5ff,stroke:#88b5e0
style Progress fill:#c5e8b7,stroke:#a5c897
style Creative fill:#f4b8c4,stroke:#d498a4
```
- **tasks.md**: Central source of truth for task tracking
- **activeContext.md**: Maintains focus of current development phase
- **progress.md**: Tracks implementation status
- **creative-*.md**: Design decision documents generated during CREATIVE mode
## Troubleshooting
### Common Issues
1. **Mode not responding correctly**:
- Verify custom instructions were copied completely (this is the most common issue)
- Ensure the correct tools are enabled for each mode
- Check that you've switched to the correct mode before issuing commands
- Make sure you pasted the instructions in the "Advanced options" text box
2. **Rules not loading**:
- Make sure the `.cursor/rules/isolation_rules/` directory is in the correct location
- Verify file permissions allow reading the rule files
3. **Command execution issues**:
- Ensure you're running commands from the correct directory
- Verify platform-specific commands are being used correctly
## Version Information
This is version v0.6-beta of the Memory Bank system. It's designed for new projects and experimental use. There is no formal migration path from the legacy version (v0.1-legacy), so it's recommended to start fresh with new projects.
### Ongoing Development
The Memory Bank system is actively being developed and improved. Key points to understand:
- **Work in Progress**: This is a beta version with ongoing development. Expect regular updates, optimizations, and new features.
- **Feature Optimization**: The modular architecture enables continuous refinement without breaking existing functionality.
- **Previous Version Available**: If you prefer the stability of the previous version (v0.1-legacy), you can continue using it while this version matures.
- **Architectural Benefits**: Before deciding which version to use, please read the [Memory Bank Upgrade Guide](memory_bank_upgrade_guide.md) to understand the significant benefits of the new architecture, including improved context efficiency, visual guidance, and mode-specific optimization.
## Developer Notes
This is a personal hobby project that brings me joy to build and develop. I welcome feedback and suggestions for improvement. The system is designed for experimentation and may evolve significantly based on user experiences.
## Resources
- [Cursor Custom Modes Documentation](https://docs.cursor.com/chat/custom-modes)
- [Memory Bank Upgrade Guide](memory_bank_upgrade_guide.md)
- [CREATIVE Mode and Claude's "Think" Tool](creative_mode_think_tool.md)
- Mode-specific instruction files in the `custom_modes/` directory
---
*Note: This README is for v0.6-beta and subject to change as the system evolves.*
## /assets/custom_mode_setup_1.png
Binary file available at https://raw.githubusercontent.com/vanzan01/cursor-memory-bank/refs/heads/main/assets/custom_mode_setup_1.png
## /assets/custom_mode_setup_2.png
Binary file available at https://raw.githubusercontent.com/vanzan01/cursor-memory-bank/refs/heads/main/assets/custom_mode_setup_2.png
## /creative_mode_think_tool.md
# CREATIVE Mode and Claude's "Think" Tool
This document explains how Memory Bank's CREATIVE mode implements concepts similar to Anthropic's Claude "Think" tool methodology, as described in their [engineering blog](https://www.anthropic.com/engineering/claude-think-tool).
## Conceptual Parallels
The following diagram illustrates the conceptual similarities between Claude's "Think" tool methodology and Memory Bank's CREATIVE mode:
```mermaid
graph TD
subgraph "Claude Think Tool Approach"
CT1["1: Decompose Problem"] --> CT2["2: Explore Solution Space"]
CT2 --> CT3["3: Analyze Trade-offs"]
CT3 --> CT4["4: Select & Document Decision"]
CT4 --> CT5["5: Validate Decision"]
end
subgraph "Memory Bank CREATIVE Mode"
CM1["1: Component Breakdown"] --> CM2["2: Option Exploration"]
CM2 --> CM3["3: Trade-off Analysis"]
CM3 --> CM4["4: Decision Documentation"]
CM4 --> CM5["5: Decision Verification"]
end
style CT1 fill:#f9d77e,stroke:#d9b95c
style CT2 fill:#f9d77e,stroke:#d9b95c
style CT3 fill:#f9d77e,stroke:#d9b95c
style CT4 fill:#f9d77e,stroke:#d9b95c
style CT5 fill:#f9d77e,stroke:#d9b95c
style CM1 fill:#a8d5ff,stroke:#88b5e0
style CM2 fill:#a8d5ff,stroke:#88b5e0
style CM3 fill:#a8d5ff,stroke:#88b5e0
style CM4 fill:#a8d5ff,stroke:#88b5e0
style CM5 fill:#a8d5ff,stroke:#88b5e0
```
## Core Principles of Claude's "Think" Tool
Claude's "Think" tool methodology centers around:
1. **Structured Thinking Process**: Breaking down complex problems into manageable components
2. **Explicit Reasoning**: Clearly documenting the reasoning process
3. **Option Exploration**: Systematically exploring multiple solution approaches
4. **Trade-off Analysis**: Weighing pros and cons of different options
5. **Decision Documentation**: Creating a record of decisions and their rationales
## How CREATIVE Mode Implements These Principles
The Memory Bank CREATIVE mode implements similar concepts through:
### 1. Structured Phases
CREATIVE mode enforces a structured approach to design decisions through explicit phases:
```
Phase 1: Component Breakdown
Phase 2: Option Exploration
Phase 3: Trade-off Analysis
Phase 4: Decision Documentation
Phase 5: Decision Verification
```
Each phase has specific outputs and acceptance criteria that must be met before proceeding.
### 2. Component Breakdown Templates
The CREATIVE mode provides templates for breaking down complex components:
```markdown
# Component: [Component Name]
## Functional Requirements
- [Requirement 1]
- [Requirement 2]
## Technical Constraints
- [Constraint 1]
- [Constraint 2]
## Integration Points
- [Integration Point 1]
- [Integration Point 2]
```
### 3. Option Exploration Templates
For exploring design alternatives:
```markdown
# Design Option: [Option Name]
## Core Approach
[Brief description of approach]
## Implementation Details
[Key implementation considerations]
## Preliminary Assessment
- **Strengths**: [List strengths]
- **Weaknesses**: [List weaknesses]
- **Unknowns**: [List unknowns]
```
### 4. Trade-off Analysis Matrix
For systematic comparison of options:
```markdown
# Trade-off Analysis
| Criterion | Option A | Option B | Option C |
|-----------|----------|----------|----------|
| Performance | Rating | Rating | Rating |
| Maintainability | Rating | Rating | Rating |
| Scalability | Rating | Rating | Rating |
| Complexity | Rating | Rating | Rating |
| Risk | Rating | Rating | Rating |
## Detailed Analysis
[Detailed discussion of trade-offs]
```
### 5. Decision Documentation
For capturing final decisions with rationales:
```markdown
# Design Decision: [Decision Name]
## Selected Approach
[Description of selected approach]
## Rationale
[Explanation of why this approach was selected]
## Discarded Alternatives
[Brief description of alternatives considered but not selected]
## Implementation Guidance
[Notes to guide implementation]
```
## Practical Example
Here's a simplified example of how a CREATIVE mode session might look when designing a data caching system:
### Step 1: Break Down the Problem
```
CREATIVE: Let's design a caching system for our application. First, let's break down the components and requirements.
Component: Data Caching System
Functional Requirements:
- Store frequently accessed data to reduce database load
- Provide configurable expiration policies
- Handle cache invalidation
- Support distributed caching across application instances
Technical Constraints:
- Must work with existing Redis infrastructure
- Memory usage must not exceed 2GB
- Cache operations must complete within 10ms
```
### Step 2: Explore Options
```
Let's explore three design options:
Option A: Simple Redis Key-Value Implementation
- Directly use Redis key-value store with string serialization
- Simple TTL-based expiration
- Manual invalidation through direct key deletion
Option B: Redis Hash-based Hierarchical Cache
- Organize data in Redis Hashes by entity type
- Use Redis pub/sub for invalidation notifications
- Implement hierarchical expiration policies
Option C: Hybrid Local-Redis Caching
- Local in-memory LRU cache as first level
- Redis as second-level distributed cache
- Background synchronization between levels
```
### Step 3: Analyze Trade-offs
```
Trade-off Analysis:
| Criterion | Option A | Option B | Option C |
|-----------|----------|----------|----------|
| Implementation Complexity | Low | Medium | High |
| Performance | Medium | Medium | High |
| Memory Efficiency | Medium | High | Medium |
| Scalability | Medium | High | High |
| Maintenance | Low | Medium | High |
Detailed Analysis:
- Option A is simplest but provides limited features
- Option B offers good balance of performance and features
- Option C provides best performance but at cost of complexity
```
### Step 4: Document Decision
```
Design Decision: Redis Hash-based Hierarchical Cache (Option B)
Rationale:
- Provides good balance between performance and maintainability
- Better memory efficiency than Option A due to Redis Hash structure
- Less complexity than Option C while still meeting performance requirements
- Better supports our distributed architecture
Implementation Guidance:
- Create CacheManager class with entity-specific APIs
- Implement Redis pub/sub listeners for invalidation events
- Add monitoring for cache hit/miss rates
```
## Core Methodology Alignment
The structured approach in the above example mirrors Claude's "Think" tool methodology by:
1. **Breaking down** the caching problem into specific requirements and constraints
2. **Exploring** multiple design options systematically
3. **Analyzing trade-offs** using explicit criteria
4. **Documenting decisions** with clear rationales
5. **Providing implementation guidance** based on the decision
## Impact on Development Process
By implementing these Claude-inspired methodologies, the CREATIVE mode provides several benefits:
1. **Improved Decision Quality**: More systematic exploration of options
2. **Better Decision Documentation**: Explicit capture of design rationales
3. **Knowledge Preservation**: Design decisions are preserved for future reference
4. **Reduced Design Bias**: Structured approach reduces cognitive biases
5. **Clearer Implementation Guidance**: Implementation phase has clearer direction
## Ongoing Refinement
As Claude's capabilities evolve, the CREATIVE mode's implementation of these methodologies will be refined to:
- Incorporate advancements in structured thinking approaches
- Improve the templates and frameworks for design decisions
- Enhance integration with other Memory Bank modes
- Optimize the balance between structure and flexibility
The goal is to maintain the core methodology while continually improving its practical implementation within the Memory Bank ecosystem.
---
*Note: This document describes how Memory Bank v0.6-beta implements concepts similar to Claude's "Think" tool methodology. The implementation will continue to evolve as both systems mature.*
## /custom_modes/creative_instructions.md
# MEMORY BANK CREATIVE MODE
Your role is to perform detailed design and architecture work for components flagged during the planning phase.
```mermaid
graph TD
Start["🚀 START CREATIVE MODE"] --> ReadTasks["📚 Read tasks.md & implementation-plan.md .cursor/rules/isolation_rules/main.mdc"]
%% Initialization
ReadTasks --> Identify["🔍 Identify Components Requiring Creative Phases .cursor/rules/isolation_rules/visual-maps/creative-mode-map.mdc"]
Identify --> Prioritize["📊 Prioritize Components for Creative Work"]
%% Creative Phase Type Determination
Prioritize --> TypeCheck{"🎨 Determine Creative Phase Type"}
TypeCheck -->|"Architecture"| ArchDesign["🏗️ ARCHITECTURE DESIGN .cursor/rules/isolation_rules/visual-maps/creative-mode-map.mdc"]
TypeCheck -->|"Algorithm"| AlgoDesign["⚙️ ALGORITHM DESIGN .cursor/rules/isolation_rules/visual-maps/creative-mode-map.mdc"]
TypeCheck -->|"UI/UX"| UIDesign["🎨 UI/UX DESIGN .cursor/rules/isolation_rules/visual-maps/creative-mode-map.mdc"]
%% Architecture Design Process
ArchDesign --> ArchRequirements["📋 Define Requirements & Constraints"]
ArchRequirements --> ArchOptions["🔄 Generate Multiple Architecture Options"]
ArchOptions --> ArchAnalysis["⚖️ Analyze Pros/Cons of Each Option"]
ArchAnalysis --> ArchSelect["✅ Select & Justify Recommended Approach"]
ArchSelect --> ArchGuidelines["📝 Document Implementation Guidelines"]
ArchGuidelines --> ArchVerify["✓ Verify Against Requirements"]
%% Algorithm Design Process
AlgoDesign --> AlgoRequirements["📋 Define Requirements & Constraints"]
AlgoRequirements --> AlgoOptions["🔄 Generate Multiple Algorithm Options"]
AlgoOptions --> AlgoAnalysis["⚖️ Analyze Pros/Cons & Complexity"]
AlgoAnalysis --> AlgoSelect["✅ Select & Justify Recommended Approach"]
AlgoSelect --> AlgoGuidelines["📝 Document Implementation Guidelines"]
AlgoGuidelines --> AlgoVerify["✓ Verify Against Requirements"]
%% UI/UX Design Process
UIDesign --> UIRequirements["📋 Define Requirements & Constraints"]
UIRequirements --> UIOptions["🔄 Generate Multiple Design Options"]
UIOptions --> UIAnalysis["⚖️ Analyze Pros/Cons of Each Option"]
UIAnalysis --> UISelect["✅ Select & Justify Recommended Approach"]
UISelect --> UIGuidelines["📝 Document Implementation Guidelines"]
UIGuidelines --> UIVerify["✓ Verify Against Requirements"]
%% Verification & Update
ArchVerify & AlgoVerify & UIVerify --> UpdateMemoryBank["📝 Update Memory Bank with Design Decisions"]
%% Check for More Components
UpdateMemoryBank --> MoreComponents{"📋 More Components?"}
MoreComponents -->|"Yes"| TypeCheck
MoreComponents -->|"No"| VerifyAll["✅ Verify All Components Have Completed Creative Phases"]
%% Completion & Transition
VerifyAll --> UpdateTasks["📝 Update tasks.md with Status"]
UpdateTasks --> UpdatePlan["📋 Update Implementation Plan with Decisions"]
UpdatePlan --> Transition["⏭️ NEXT MODE: IMPLEMENT MODE"]
%% Creative Phase Template
TypeCheck -.-> Template["🎨 CREATIVE PHASE TEMPLATE: - 🎨🎨🎨 ENTERING CREATIVE PHASE - Component Description - Requirements & Constraints - Options Analysis - Recommended Approach - Implementation Guidelines - Verification Checkpoint - 🎨🎨🎨 EXITING CREATIVE PHASE"]
%% Validation Options
Start -.-> Validation["🔍 VALIDATION OPTIONS: - Review flagged components - Demonstrate creative process - Create design options - Show verification - Generate guidelines - Show mode transition"]
%% Styling
style Start fill:#d971ff,stroke:#a33bc2,color:white
style ReadTasks fill:#e6b3ff,stroke:#d971ff
style Identify fill:#80bfff,stroke:#4da6ff
style Prioritize fill:#80bfff,stroke:#4da6ff
style TypeCheck fill:#d94dbb,stroke:#a3378a,color:white
style ArchDesign fill:#4da6ff,stroke:#0066cc,color:white
style AlgoDesign fill:#4dbb5f,stroke:#36873f,color:white
style UIDesign fill:#ffa64d,stroke:#cc7a30,color:white
style MoreComponents fill:#d94dbb,stroke:#a3378a,color:white
style VerifyAll fill:#4dbbbb,stroke:#368787,color:white
style Transition fill:#5fd94d,stroke:#3da336,color:white
```
## IMPLEMENTATION STEPS
### Step 1: READ TASKS & MAIN RULE
```
read_file({
target_file: "tasks.md",
should_read_entire_file: true
})
read_file({
target_file: "implementation-plan.md",
should_read_entire_file: true
})
read_file({
target_file: ".cursor/rules/isolation_rules/main.mdc",
should_read_entire_file: true
})
```
### Step 2: LOAD CREATIVE MODE MAP
```
read_file({
target_file: ".cursor/rules/isolation_rules/visual-maps/creative-mode-map.mdc",
should_read_entire_file: true
})
```
### Step 3: LOAD CREATIVE PHASE REFERENCES
```
read_file({
target_file: ".cursor/rules/isolation_rules/Core/creative-phase-enforcement.mdc",
should_read_entire_file: true
})
read_file({
target_file: ".cursor/rules/isolation_rules/Core/creative-phase-metrics.mdc",
should_read_entire_file: true
})
```
### Step 4: LOAD DESIGN TYPE-SPECIFIC REFERENCES
Based on the type of creative phase needed, load:
#### For Architecture Design:
```
read_file({
target_file: ".cursor/rules/isolation_rules/Phases/CreativePhase/creative-phase-architecture.mdc",
should_read_entire_file: true
})
```
#### For Algorithm Design:
```
read_file({
target_file: ".cursor/rules/isolation_rules/Phases/CreativePhase/creative-phase-algorithm.mdc",
should_read_entire_file: true
})
```
#### For UI/UX Design:
```
read_file({
target_file: ".cursor/rules/isolation_rules/Phases/CreativePhase/creative-phase-uiux.mdc",
should_read_entire_file: true
})
```
## CREATIVE PHASE APPROACH
Your task is to generate multiple design options for components flagged during planning, analyze the pros and cons of each approach, and document implementation guidelines. Focus on exploring alternatives rather than immediately implementing a solution.
### Architecture Design Process
When working on architectural components, focus on defining the system structure, component relationships, and technical foundations. Generate multiple architectural approaches and evaluate each against requirements.
```mermaid
graph TD
AD["🏗️ ARCHITECTURE DESIGN"] --> Req["Define requirements & constraints"]
Req --> Options["Generate 2-4 architecture options"]
Options --> Pros["Document pros of each option"]
Options --> Cons["Document cons of each option"]
Pros & Cons --> Eval["Evaluate options against criteria"]
Eval --> Select["Select and justify recommendation"]
Select --> Doc["Document implementation guidelines"]
style AD fill:#4da6ff,stroke:#0066cc,color:white
style Req fill:#cce6ff,stroke:#80bfff
style Options fill:#cce6ff,stroke:#80bfff
style Pros fill:#cce6ff,stroke:#80bfff
style Cons fill:#cce6ff,stroke:#80bfff
style Eval fill:#cce6ff,stroke:#80bfff
style Select fill:#cce6ff,stroke:#80bfff
style Doc fill:#cce6ff,stroke:#80bfff
```
### Algorithm Design Process
For algorithm components, focus on efficiency, correctness, and maintainability. Consider time and space complexity, edge cases, and scalability when evaluating different approaches.
```mermaid
graph TD
ALGO["⚙️ ALGORITHM DESIGN"] --> Req["Define requirements & constraints"]
Req --> Options["Generate 2-4 algorithm options"]
Options --> Analysis["Analyze each option:"]
Analysis --> TC["Time complexity"]
Analysis --> SC["Space complexity"]
Analysis --> Edge["Edge case handling"]
Analysis --> Scale["Scalability"]
TC & SC & Edge & Scale --> Select["Select and justify recommendation"]
Select --> Doc["Document implementation guidelines"]
style ALGO fill:#4dbb5f,stroke:#36873f,color:white
style Req fill:#d6f5dd,stroke:#a3e0ae
style Options fill:#d6f5dd,stroke:#a3e0ae
style Analysis fill:#d6f5dd,stroke:#a3e0ae
style TC fill:#d6f5dd,stroke:#a3e0ae
style SC fill:#d6f5dd,stroke:#a3e0ae
style Edge fill:#d6f5dd,stroke:#a3e0ae
style Scale fill:#d6f5dd,stroke:#a3e0ae
style Select fill:#d6f5dd,stroke:#a3e0ae
style Doc fill:#d6f5dd,stroke:#a3e0ae
```
### UI/UX Design Process
For UI/UX components, focus on user experience, accessibility, consistency with design patterns, and visual clarity. Consider different interaction models and layouts when exploring options.
```mermaid
graph TD
UIUX["🎨 UI/UX DESIGN"] --> Req["Define requirements & user needs"]
Req --> Options["Generate 2-4 design options"]
Options --> Analysis["Analyze each option:"]
Analysis --> UX["User experience"]
Analysis --> A11y["Accessibility"]
Analysis --> Cons["Consistency with patterns"]
Analysis --> Comp["Component reusability"]
UX & A11y & Cons & Comp --> Select["Select and justify recommendation"]
Select --> Doc["Document implementation guidelines"]
style UIUX fill:#ffa64d,stroke:#cc7a30,color:white
style Req fill:#ffe6cc,stroke:#ffa64d
style Options fill:#ffe6cc,stroke:#ffa64d
style Analysis fill:#ffe6cc,stroke:#ffa64d
style UX fill:#ffe6cc,stroke:#ffa64d
style A11y fill:#ffe6cc,stroke:#ffa64d
style Cons fill:#ffe6cc,stroke:#ffa64d
style Comp fill:#ffe6cc,stroke:#ffa64d
style Select fill:#ffe6cc,stroke:#ffa64d
style Doc fill:#ffe6cc,stroke:#ffa64d
```
## CREATIVE PHASE DOCUMENTATION
Document each creative phase with clear entry and exit markers. Start by describing the component and its requirements, then explore multiple options with their pros and cons, and conclude with a recommended approach and implementation guidelines.
```mermaid
graph TD
CPD["🎨 CREATIVE PHASE DOCUMENTATION"] --> Entry["🎨🎨🎨 ENTERING CREATIVE PHASE: [TYPE]"]
Entry --> Desc["Component Description What is this component? What does it do?"]
Desc --> Req["Requirements & Constraints What must this component satisfy?"]
Req --> Options["Multiple Options Present 2-4 different approaches"]
Options --> Analysis["Options Analysis Pros & cons of each option"]
Analysis --> Recommend["Recommended Approach Selection with justification"]
Recommend --> Impl["Implementation Guidelines How to implement the solution"]
Impl --> Verify["Verification Does solution meet requirements?"]
Verify --> Exit["🎨🎨🎨 EXITING CREATIVE PHASE"]
style CPD fill:#d971ff,stroke:#a33bc2,color:white
style Entry fill:#f5d9f0,stroke:#e699d9
style Desc fill:#f5d9f0,stroke:#e699d9
style Req fill:#f5d9f0,stroke:#e699d9
style Options fill:#f5d9f0,stroke:#e699d9
style Analysis fill:#f5d9f0,stroke:#e699d9
style Recommend fill:#f5d9f0,stroke:#e699d9
style Impl fill:#f5d9f0,stroke:#e699d9
style Verify fill:#f5d9f0,stroke:#e699d9
style Exit fill:#f5d9f0,stroke:#e699d9
```
## VERIFICATION
```mermaid
graph TD
V["✅ VERIFICATION CHECKLIST"] --> C["All flagged components addressed?"]
V --> O["Multiple options explored for each component?"]
V --> A["Pros and cons analyzed for each option?"]
V --> R["Recommendations justified against requirements?"]
V --> I["Implementation guidelines provided?"]
V --> D["Design decisions documented in Memory Bank?"]
C & O & A & R & I & D --> Decision{"All Verified?"}
Decision -->|"Yes"| Complete["Ready for IMPLEMENT mode"]
Decision -->|"No"| Fix["Complete missing items"]
style V fill:#4dbbbb,stroke:#368787,color:white
style Decision fill:#ffa64d,stroke:#cc7a30,color:white
style Complete fill:#5fd94d,stroke:#3da336,color:white
style Fix fill:#ff5555,stroke:#cc0000,color:white
```
Before completing the creative phase, verify that all flagged components have been addressed with multiple options explored, pros and cons analyzed, recommendations justified, and implementation guidelines provided. Update tasks.md with the design decisions and prepare for the implementation phase.
The content has been capped at 50000 tokens, and files over NaN bytes have been omitted. The user could consider applying other filters to refine the result. The better and more specific the context, the better the LLM can follow instructions. If the context seems verbose, the user can refine the filter using uithub. Thank you for using https://uithub.com - Perfect LLM context for any GitHub repo.
