├── .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
├── mode_switching_analysis.md
├── plan_instructions.md
└── van_instructions.md
├── memory_bank_upgrade_guide.md
└── optimization-journey
├── 00-introduction.md
├── 01-efficiency-and-clarity.md
├── 02-system-self-assessment.md
├── 03-redundancy-elimination.md
├── 04-single-source-of-truth.md
├── 05-adaptive-complexity-model.md
├── 06-self-assessment-recommendations.md
├── 07-structured-creative-thinking.md
├── 08-creative-phase-enforcement.md
├── 09-context-optimization.md
├── 10-current-system-state.md
├── 11-key-lessons.md
├── 11-methodological-integration.md
├── 12-future-directions.md
├── 12-key-lessons.md
├── 13-future-directions.md
├── 13-methodological-integration.md
└── README.md
/.cursor/rules/isolation_rules/Core/command-execution.mdc:
--------------------------------------------------------------------------------
1 | ---
2 | description: Command execution guidelines for isolation-focused Memory Bank
3 | globs: command-execution.mdc
4 | alwaysApply: false
5 | ---
6 |
7 | # COMMAND EXECUTION SYSTEM
8 |
9 | > **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.
10 |
11 | ## 🔍 COMMAND EFFICIENCY WORKFLOW
12 |
13 | ```mermaid
14 | graph TD
15 | Start["Command
Planning"] --> Analyze["Analyze Command
Requirements"]
16 | Analyze --> Balance["Balance Clarity
vs. Efficiency"]
17 | Balance --> Complexity{"Command
Complexity?"}
18 |
19 | Complexity -->|"Simple"| Single["Execute
Single Command"]
20 | Complexity -->|"Moderate"| Chain["Use Efficient
Command Chaining"]
21 | Complexity -->|"Complex"| Group["Group Into
Logical Steps"]
22 |
23 | Single & Chain & Group --> Verify["Verify
Results"]
24 | Verify --> Document["Document
Command & Result"]
25 | Document --> Next["Next
Command"]
26 | ```
27 |
28 | ## 📋 COMMAND CHAINING GUIDELINES
29 |
30 | ```mermaid
31 | graph TD
32 | Command["Command
Execution"] --> ChainApprop{"Is Chaining
Appropriate?"}
33 |
34 | ChainApprop -->|"Yes"| ChainTypes["Chain
Types"]
35 | ChainApprop -->|"No"| SingleCmd["Use Single
Commands"]
36 |
37 | ChainTypes --> Sequential["Sequential Operations
cmd1 && cmd2"]
38 | ChainTypes --> Conditional["Conditional Operations
cmd1 || cmd2"]
39 | ChainTypes --> Piping["Piping
cmd1 | cmd2"]
40 | ChainTypes --> Grouping["Command Grouping
(cmd1; cmd2)"]
41 |
42 | Sequential & Conditional & Piping & Grouping --> Doc["Document
Commands & Results"]
43 | ```
44 |
45 | ## 🚦 DIRECTORY VERIFICATION WORKFLOW
46 |
47 | ```mermaid
48 | graph TD
49 | Command["Command
Execution"] --> DirCheck["Check Current
Directory"]
50 | DirCheck --> ProjectRoot{"In Project
Root?"}
51 |
52 | ProjectRoot -->|"Yes"| Execute["Execute
Command"]
53 | ProjectRoot -->|"No"| Locate["Locate
Project Root"]
54 |
55 | Locate --> Found{"Project Root
Found?"}
56 | Found -->|"Yes"| Navigate["Navigate to
Project Root"]
57 | Found -->|"No"| Error["Error: Cannot
Find Project Root"]
58 |
59 | Navigate --> Execute
60 | Execute --> Verify["Verify
Results"]
61 | ```
62 |
63 | ## 📋 DIRECTORY VERIFICATION CHECKLIST
64 |
65 | Before executing any npm or build command:
66 |
67 | | Step | Windows (PowerShell) | Unix/Linux/Mac | Purpose |
68 | |------|----------------------|----------------|---------|
69 | | **Check package.json** | `Test-Path package.json` | `ls package.json` | Verify current directory is project root |
70 | | **Check for parent directory** | `Test-Path "*/package.json"` | `find . -maxdepth 2 -name package.json` | Find potential project directories |
71 | | **Navigate to project root** | `cd [project-dir]` | `cd [project-dir]` | Move to correct directory before executing commands |
72 |
73 | ## 📋 REACT-SPECIFIC COMMAND GUIDELINES
74 |
75 | For React applications, follow these strict guidelines:
76 |
77 | | Command | Correct Usage | Incorrect Usage | Notes |
78 | |---------|---------------|----------------|-------|
79 | | **npm start** | `cd [project-root] && npm start` | `npm start` (from parent dir) | Must execute from directory with package.json |
80 | | **npm run build** | `cd [project-root] && npm run build` | `cd [parent-dir] && npm run build` | Must execute from directory with package.json |
81 | | **npm install** | `cd [project-root] && npm install [pkg]` | `npm install [pkg]` (wrong dir) | Dependencies installed to nearest package.json |
82 | | **npm create** | `npm create vite@latest my-app -- --template react` | Manually configuring webpack | Use standard tools for project creation |
83 |
84 | ## 🔄 COMMAND CHAINING PATTERNS
85 |
86 | Effective command chaining patterns include:
87 |
88 | | Pattern | Format | Examples | Use Case |
89 | |---------|--------|----------|----------|
90 | | **Sequential** | `cmd1 && cmd2` | `mkdir dir && cd dir` | Commands that should run in sequence, second only if first succeeds |
91 | | **Conditional** | `cmd1 || cmd2` | `test -f file.txt || touch file.txt` | Fallback commands, second only if first fails |
92 | | **Piping** | `cmd1 \| cmd2` | `grep "pattern" file.txt \| wc -l` | Pass output of first command as input to second |
93 | | **Background** | `cmd &` | `npm start &` | Run command in background |
94 | | **Grouping** | `(cmd1; cmd2)` | `(echo "Start"; npm test; echo "End")` | Group commands to run as a unit |
95 |
96 | ## 📋 COMMAND DOCUMENTATION TEMPLATE
97 |
98 | ```
99 | ## Command Execution: [Purpose]
100 |
101 | ### Command
102 | ```
103 | [actual command or chain]
104 | ```
105 |
106 | ### Result
107 | ```
108 | [command output]
109 | ```
110 |
111 | ### Effect
112 | [Brief description of what changed in the system]
113 |
114 | ### Next Steps
115 | [What needs to be done next]
116 | ```
117 |
118 | ## 🔍 PLATFORM-SPECIFIC CONSIDERATIONS
119 |
120 | ```mermaid
121 | graph TD
122 | Platform["Platform
Detection"] --> Windows["Windows
Commands"]
123 | Platform --> Unix["Unix/Linux/Mac
Commands"]
124 |
125 | Windows --> WinAdapt["Windows Command
Adaptations"]
126 | Unix --> UnixAdapt["Unix Command
Adaptations"]
127 |
128 | WinAdapt --> WinChain["Windows Chaining:
Commands separated by &"]
129 | UnixAdapt --> UnixChain["Unix Chaining:
Commands separated by ;"]
130 |
131 | WinChain & UnixChain --> Execute["Execute
Platform-Specific
Commands"]
132 | ```
133 |
134 | ## 📋 COMMAND EFFICIENCY EXAMPLES
135 |
136 | Examples of efficient command usage:
137 |
138 | | Inefficient | Efficient | Explanation |
139 | |-------------|-----------|-------------|
140 | | `mkdir dir`
`cd dir`
`npm init -y` | `mkdir dir && cd dir && npm init -y` | Combines related sequential operations |
141 | | `ls`
`grep "\.js$"` | `ls \| grep "\.js$"` | Pipes output of first command to second |
142 | | `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 |
143 | | `mkdir dir1`
`mkdir dir2`
`mkdir dir3` | `mkdir dir1 dir2 dir3` | Uses command's built-in multiple argument capability |
144 | | `npm install pkg1`
`npm install pkg2` | `npm install pkg1 pkg2` | Installs multiple packages in one command |
145 |
146 | ## 📋 REACT PROJECT INITIALIZATION STANDARDS
147 |
148 | Always use these standard approaches for React project creation:
149 |
150 | | Approach | Command | Benefits | Avoids |
151 | |----------|---------|----------|--------|
152 | | **Create React App** | `npx create-react-app my-app` | Preconfigured webpack & babel | Manual configuration errors |
153 | | **Create React App w/TypeScript** | `npx create-react-app my-app --template typescript` | Type safety + preconfigured | Inconsistent module systems |
154 | | **Vite** | `npm create vite@latest my-app -- --template react` | Faster build times | Complex webpack setups |
155 | | **Next.js** | `npx create-next-app@latest my-app` | SSR support | Module system conflicts |
156 |
157 | ## ⚠️ ERROR HANDLING WORKFLOW
158 |
159 | ```mermaid
160 | sequenceDiagram
161 | participant User
162 | participant AI
163 | participant System
164 |
165 | AI->>System: Execute Command
166 | System->>AI: Return Result
167 |
168 | alt Success
169 | AI->>AI: Verify Expected Result
170 | AI->>User: Report Success
171 | else Error
172 | AI->>AI: Analyze Error Message
173 | AI->>AI: Identify Likely Cause
174 | AI->>User: Explain Error & Cause
175 | AI->>User: Suggest Corrective Action
176 | User->>AI: Approve Correction
177 | AI->>System: Execute Corrected Command
178 | end
179 | ```
180 |
181 | ## 📋 COMMAND RESULT VERIFICATION
182 |
183 | After command execution, verify:
184 |
185 | ```mermaid
186 | graph TD
187 | Execute["Execute
Command"] --> Check{"Check
Result"}
188 |
189 | Check -->|"Success"| Verify["Verify Expected
Outcome"]
190 | Check -->|"Error"| Analyze["Analyze
Error"]
191 |
192 | Verify -->|"Expected"| Document["Document
Success"]
193 | Verify -->|"Unexpected"| Investigate["Investigate
Unexpected Result"]
194 |
195 | Analyze --> Diagnose["Diagnose
Error Cause"]
196 | Diagnose --> Correct["Propose
Correction"]
197 |
198 | Document & Investigate & Correct --> Next["Next Step
in Process"]
199 | ```
200 |
201 | ## 📝 COMMAND EXECUTION CHECKLIST
202 |
203 | ```
204 | ✓ COMMAND EXECUTION CHECKLIST
205 | - Command purpose clearly identified? [YES/NO]
206 | - Appropriate balance of clarity vs. efficiency? [YES/NO]
207 | - Platform-specific considerations addressed? [YES/NO]
208 | - Command documented with results? [YES/NO]
209 | - Outcome verified against expectations? [YES/NO]
210 | - Errors properly handled (if any)? [YES/NO/NA]
211 | - For npm/build commands: Executed from project root? [YES/NO/NA]
212 | - For React projects: Using standard tooling? [YES/NO/NA]
213 |
214 | → If all YES: Command execution complete
215 | → If any NO: Address missing elements
216 | ```
217 |
218 | ## 🚨 COMMAND EXECUTION WARNINGS
219 |
220 | Avoid these common command issues:
221 |
222 | ```mermaid
223 | graph TD
224 | Warning["Command
Warnings"] --> W1["Excessive
Verbosity"]
225 | Warning --> W2["Insufficient
Error Handling"]
226 | Warning --> W3["Unnecessary
Complexity"]
227 | Warning --> W4["Destructive
Operations Without
Confirmation"]
228 | Warning --> W5["Wrong Directory
Execution"]
229 |
230 | W1 --> S1["Use flags to reduce
unnecessary output"]
231 | W2 --> S2["Include error handling
in command chains"]
232 | W3 --> S3["Prefer built-in
command capabilities"]
233 | W4 --> S4["Show confirmation
before destructive actions"]
234 | W5 --> S5["Verify directory before
npm/build commands"]
235 | ```
--------------------------------------------------------------------------------
/.cursor/rules/isolation_rules/Core/complexity-decision-tree.mdc:
--------------------------------------------------------------------------------
1 | ---
2 | description: complexity decision tree
3 | globs: complexity-decision-tree.mdc
4 | alwaysApply: false
5 | ---
6 | # TASK COMPLEXITY DETERMINATION
7 |
8 | > **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.
9 |
10 | ## 🌳 COMPLEXITY DECISION TREE
11 |
12 | ```mermaid
13 | graph TD
14 | Start["New Task"] --> Q1{"Bug fix or
error correction?"}
15 | Q1 -->|Yes| Q1a{"Affects single
component?"}
16 | Q1a -->|Yes| L1["Level 1:
Quick Bug Fix"]
17 | Q1a -->|No| Q1b{"Affects multiple
components?"}
18 | Q1b -->|Yes| L2["Level 2:
Simple Enhancement"]
19 | Q1b -->|No| Q1c{"Affects system
architecture?"}
20 | Q1c -->|Yes| L3["Level 3:
Intermediate Feature"]
21 | Q1c -->|No| L2
22 |
23 | Q1 -->|No| Q2{"Adding small
feature or
enhancement?"}
24 | Q2 -->|Yes| Q2a{"Self-contained
change?"}
25 | Q2a -->|Yes| L2
26 | Q2a -->|No| Q2b{"Affects multiple
components?"}
27 | Q2b -->|Yes| L3
28 | Q2b -->|No| L2
29 |
30 | Q2 -->|No| Q3{"Complete feature
requiring multiple
components?"}
31 | Q3 -->|Yes| Q3a{"Architectural
implications?"}
32 | Q3a -->|Yes| L4["Level 4:
Complex System"]
33 | Q3a -->|No| L3
34 |
35 | Q3 -->|No| Q4{"System-wide or
architectural
change?"}
36 | Q4 -->|Yes| L4
37 | Q4 -->|No| L3
38 |
39 | L1 --> LoadL1["Load Level 1 Map"]
40 | L2 --> LoadL2["Load Level 2 Map"]
41 | L3 --> LoadL3["Load Level 3 Map"]
42 | L4 --> LoadL4["Load Level 4 Map"]
43 | ```
44 |
45 | ## 📊 COMPLEXITY LEVEL INDICATORS
46 |
47 | Use these indicators to help determine task complexity:
48 |
49 | ### Level 1: Quick Bug Fix
50 | - **Keywords**: "fix", "broken", "not working", "issue", "bug", "error", "crash"
51 | - **Scope**: Single component or UI element
52 | - **Duration**: Can be completed quickly (minutes to hours)
53 | - **Risk**: Low, isolated changes
54 | - **Examples**:
55 | - Fix button not working
56 | - Correct styling issue
57 | - Fix validation error
58 | - Resolve broken link
59 | - Fix typo or text issue
60 |
61 | ### Level 2: Simple Enhancement
62 | - **Keywords**: "add", "improve", "update", "change", "enhance", "modify"
63 | - **Scope**: Single component or subsystem
64 | - **Duration**: Hours to 1-2 days
65 | - **Risk**: Moderate, contained to specific area
66 | - **Examples**:
67 | - Add form field
68 | - Improve validation
69 | - Update styling
70 | - Add simple feature
71 | - Change text content
72 | - Enhance existing component
73 |
74 | ### Level 3: Intermediate Feature
75 | - **Keywords**: "implement", "create", "develop", "build", "feature"
76 | - **Scope**: Multiple components, complete feature
77 | - **Duration**: Days to 1-2 weeks
78 | - **Risk**: Significant, affects multiple areas
79 | - **Examples**:
80 | - Implement user authentication
81 | - Create dashboard
82 | - Develop search functionality
83 | - Build user profile system
84 | - Implement data visualization
85 | - Create complex form system
86 |
87 | ### Level 4: Complex System
88 | - **Keywords**: "system", "architecture", "redesign", "integration", "framework"
89 | - **Scope**: Multiple subsystems or entire application
90 | - **Duration**: Weeks to months
91 | - **Risk**: High, architectural implications
92 | - **Examples**:
93 | - Implement authentication system
94 | - Build payment processing framework
95 | - Create microservice architecture
96 | - Implement database migration system
97 | - Develop real-time communication system
98 | - Create multi-tenant architecture
99 |
100 | ## 🔍 COMPLEXITY ASSESSMENT QUESTIONS
101 |
102 | Answer these questions to determine complexity:
103 |
104 | 1. **Scope Impact**
105 | - Does it affect a single component or multiple?
106 | - Are there system-wide implications?
107 | - How many files will need to be modified?
108 |
109 | 2. **Design Decisions**
110 | - Are complex design decisions required?
111 | - Will it require creative phases for design?
112 | - Are there architectural considerations?
113 |
114 | 3. **Risk Assessment**
115 | - What happens if it fails?
116 | - Are there security implications?
117 | - Will it affect critical functionality?
118 |
119 | 4. **Implementation Effort**
120 | - How long will it take to implement?
121 | - Does it require specialized knowledge?
122 | - Is extensive testing needed?
123 |
124 | ## 📊 KEYWORD ANALYSIS TABLE
125 |
126 | | Keyword | Likely Level | Notes |
127 | |---------|--------------|-------|
128 | | "Fix" | Level 1 | Unless system-wide |
129 | | "Bug" | Level 1 | Unless multiple components |
130 | | "Error" | Level 1 | Unless architectural |
131 | | "Add" | Level 2 | Unless complex feature |
132 | | "Update" | Level 2 | Unless architectural |
133 | | "Improve" | Level 2 | Unless system-wide |
134 | | "Implement" | Level 3 | Complex components |
135 | | "Create" | Level 3 | New functionality |
136 | | "Develop" | Level 3 | Significant scope |
137 | | "System" | Level 4 | Architectural implications |
138 | | "Architecture" | Level 4 | Major structural changes |
139 | | "Framework" | Level 4 | Core infrastructure |
140 |
141 | ## 🔄 COMPLEXITY ESCALATION
142 |
143 | If during a task you discover it's more complex than initially determined:
144 |
145 | ```
146 | ⚠️ TASK ESCALATION NEEDED
147 | Current Level: Level [X]
148 | Recommended Level: Level [Y]
149 | Reason: [Brief explanation]
150 |
151 | Would you like me to escalate this task to Level [Y]?
152 | ```
153 |
154 | If approved, switch to the appropriate higher-level process map.
155 |
156 | ## 🎯 PROCESS SELECTION
157 |
158 | After determining complexity, load the appropriate process map:
159 |
160 | | Level | Description | Process Map |
161 | |-------|-------------|-------------|
162 | | 1 | Quick Bug Fix | [Level 1 Map](mdc:.cursor/rules/visual-maps/level1-map.mdc) |
163 | | 2 | Simple Enhancement | [Level 2 Map](mdc:.cursor/rules/visual-maps/level2-map.mdc) |
164 | | 3 | Intermediate Feature | [Level 3 Map](mdc:.cursor/rules/visual-maps/level3-map.mdc) |
165 | | 4 | Complex System | [Level 4 Map](mdc:.cursor/rules/visual-maps/level4-map.mdc) |
166 |
167 | ## 📝 COMPLEXITY DETERMINATION TEMPLATE
168 |
169 | Use this template to document complexity determination:
170 |
171 | ```
172 | ## COMPLEXITY DETERMINATION
173 |
174 | Task: [Task description]
175 |
176 | Assessment:
177 | - Scope: [Single component/Multiple components/System-wide]
178 | - Design decisions: [Simple/Moderate/Complex]
179 | - Risk: [Low/Moderate/High]
180 | - Implementation effort: [Low/Moderate/High]
181 |
182 | Keywords identified: [List relevant keywords]
183 |
184 | Determination: Level [1/2/3/4] - [Quick Bug Fix/Simple Enhancement/Intermediate Feature/Complex System]
185 |
186 | Loading process map: [Level X Map]
187 | ```
188 |
--------------------------------------------------------------------------------
/.cursor/rules/isolation_rules/Core/creative-phase-enforcement.mdc:
--------------------------------------------------------------------------------
1 | ---
2 | description: creative phase enforcement
3 | globs: creative-phase-enforcement.md
4 | alwaysApply: false
5 | ---
6 |
7 | # CREATIVE PHASE ENFORCEMENT
8 |
9 | > **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.
10 |
11 | ## 🔍 ENFORCEMENT WORKFLOW
12 |
13 | ```mermaid
14 | graph TD
15 | Start["Task Start"] --> Check{"Level 3-4
Task?"}
16 | Check -->|Yes| Analyze["Analyze Design
Decision Points"]
17 | Check -->|No| Optional["Creative Phase
Optional"]
18 |
19 | Analyze --> Decision{"Design Decisions
Required?"}
20 | Decision -->|Yes| Gate["🚨 IMPLEMENTATION
BLOCKED"]
21 | Decision -->|No| Allow["Allow
Implementation"]
22 |
23 | Gate --> Creative["Enter Creative
Phase"]
24 | Creative --> Verify{"All Decisions
Documented?"}
25 | Verify -->|No| Return["Return to
Creative Phase"]
26 | Verify -->|Yes| Proceed["Allow
Implementation"]
27 |
28 | style Start fill:#4da6ff,stroke:#0066cc,color:white
29 | style Check fill:#ffa64d,stroke:#cc7a30,color:white
30 | style Analyze fill:#4dbb5f,stroke:#36873f,color:white
31 | style Gate fill:#d94dbb,stroke:#a3378a,color:white
32 | style Creative fill:#4dbbbb,stroke:#368787,color:white
33 | style Verify fill:#d971ff,stroke:#a33bc2,color:white
34 | ```
35 |
36 | ## 🚨 ENFORCEMENT GATES
37 |
38 | ```mermaid
39 | graph TD
40 | subgraph "CREATIVE PHASE GATES"
41 | G1["Entry Gate
Verify Requirements"]
42 | G2["Process Gate
Verify Progress"]
43 | G3["Exit Gate
Verify Completion"]
44 | end
45 |
46 | G1 --> G2 --> G3
47 |
48 | style G1 fill:#4dbb5f,stroke:#36873f,color:white
49 | style G2 fill:#ffa64d,stroke:#cc7a30,color:white
50 | style G3 fill:#d94dbb,stroke:#a3378a,color:white
51 | ```
52 |
53 | ## 📋 ENFORCEMENT CHECKLIST
54 |
55 | ```markdown
56 | ## Entry Gate Verification
57 | - [ ] Task complexity is Level 3-4
58 | - [ ] Design decisions identified
59 | - [ ] Creative phase requirements documented
60 | - [ ] Required participants notified
61 |
62 | ## Process Gate Verification
63 | - [ ] All options being considered
64 | - [ ] Pros/cons documented
65 | - [ ] Technical constraints identified
66 | - [ ] Implementation impacts assessed
67 |
68 | ## Exit Gate Verification
69 | - [ ] All decisions documented
70 | - [ ] Rationale provided for choices
71 | - [ ] Implementation plan outlined
72 | - [ ] Verification against requirements
73 | ```
74 |
75 | ## 🚨 IMPLEMENTATION BLOCK NOTICE
76 |
77 | When a creative phase is required but not completed:
78 |
79 | ```
80 | 🚨 IMPLEMENTATION BLOCKED
81 | Creative phases MUST be completed before implementation.
82 |
83 | Required Creative Phases:
84 | - [ ] [Creative Phase 1]
85 | - [ ] [Creative Phase 2]
86 | - [ ] [Creative Phase 3]
87 |
88 | ⛔ This is a HARD BLOCK
89 | Implementation CANNOT proceed until all creative phases are completed.
90 | Type "PHASE.REVIEW" to begin creative phase review.
91 | ```
92 |
93 | ## ✅ VERIFICATION PROTOCOL
94 |
95 | ```mermaid
96 | graph TD
97 | subgraph "VERIFICATION STEPS"
98 | V1["1. Requirements
Check"]
99 | V2["2. Documentation
Review"]
100 | V3["3. Decision
Validation"]
101 | V4["4. Implementation
Readiness"]
102 | end
103 |
104 | V1 --> V2 --> V3 --> V4
105 |
106 | style V1 fill:#4dbb5f,stroke:#36873f,color:white
107 | style V2 fill:#ffa64d,stroke:#cc7a30,color:white
108 | style V3 fill:#d94dbb,stroke:#a3378a,color:white
109 | style V4 fill:#4dbbbb,stroke:#368787,color:white
110 | ```
111 |
112 | ## 🔄 CREATIVE PHASE MARKERS
113 |
114 | Use these markers to clearly indicate creative phase boundaries:
115 |
116 | ```markdown
117 | 🎨🎨🎨 ENTERING CREATIVE PHASE: [TYPE] 🎨🎨🎨
118 | Focus: [Specific component/feature]
119 | Objective: [Clear goal of this creative phase]
120 | Requirements: [List of requirements]
121 |
122 | [Creative phase content]
123 |
124 | 🎨 CREATIVE CHECKPOINT: [Milestone]
125 | - Progress: [Status]
126 | - Decisions: [List]
127 | - Next steps: [Plan]
128 |
129 | 🎨🎨🎨 EXITING CREATIVE PHASE 🎨🎨🎨
130 | Summary: [Brief description]
131 | Key Decisions: [List]
132 | Next Steps: [Implementation plan]
133 | ```
134 |
135 | ## 🔄 DOCUMENT MANAGEMENT
136 |
137 | ```mermaid
138 | graph TD
139 | Current["Current Document"] --> Active["Active:
- creative-phase-enforcement.md"]
140 | Current --> Related["Related:
- creative-phase-architecture.md
- task-tracking-intermediate.md"]
141 |
142 | style Current fill:#4da6ff,stroke:#0066cc,color:white
143 | style Active fill:#4dbb5f,stroke:#36873f,color:white
144 | style Related fill:#ffa64d,stroke:#cc7a30,color:white
145 | ```
--------------------------------------------------------------------------------
/.cursor/rules/isolation_rules/Core/creative-phase-metrics.mdc:
--------------------------------------------------------------------------------
1 | ---
2 | description: creative phase metrics
3 | globs: creative-phase-metrics.md
4 | alwaysApply: false
5 | ---
6 |
7 |
8 |
9 | # CREATIVE PHASE METRICS
10 |
11 | > **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.
12 |
13 | ## 📊 METRICS OVERVIEW
14 |
15 | ```mermaid
16 | graph TD
17 | subgraph "CREATIVE PHASE METRICS"
18 | M1["Documentation
Quality"]
19 | M2["Decision
Coverage"]
20 | M3["Option
Analysis"]
21 | M4["Impact
Assessment"]
22 | M5["Verification
Score"]
23 | end
24 |
25 | M1 --> Score["Quality
Score"]
26 | M2 --> Score
27 | M3 --> Score
28 | M4 --> Score
29 | M5 --> Score
30 |
31 | style M1 fill:#4dbb5f,stroke:#36873f,color:white
32 | style M2 fill:#ffa64d,stroke:#cc7a30,color:white
33 | style M3 fill:#d94dbb,stroke:#a3378a,color:white
34 | style M4 fill:#4dbbbb,stroke:#368787,color:white
35 | style M5 fill:#d971ff,stroke:#a33bc2,color:white
36 | style Score fill:#ff71c2,stroke:#c23b8a,color:white
37 | ```
38 |
39 | ## 📋 QUALITY METRICS SCORECARD
40 |
41 | ```markdown
42 | # Creative Phase Quality Assessment
43 |
44 | ## 1. Documentation Quality [0-10]
45 | - [ ] Clear problem statement (2 points)
46 | - [ ] Well-defined objectives (2 points)
47 | - [ ] Comprehensive requirements list (2 points)
48 | - [ ] Proper formatting and structure (2 points)
49 | - [ ] Cross-references to related documents (2 points)
50 |
51 | ## 2. Decision Coverage [0-10]
52 | - [ ] All required decisions identified (2 points)
53 | - [ ] Each decision point documented (2 points)
54 | - [ ] Dependencies mapped (2 points)
55 | - [ ] Impact analysis included (2 points)
56 | - [ ] Future considerations noted (2 points)
57 |
58 | ## 3. Option Analysis [0-10]
59 | - [ ] Multiple options considered (2 points)
60 | - [ ] Pros/cons documented (2 points)
61 | - [ ] Technical feasibility assessed (2 points)
62 | - [ ] Resource requirements estimated (2 points)
63 | - [ ] Risk factors identified (2 points)
64 |
65 | ## 4. Impact Assessment [0-10]
66 | - [ ] System impact documented (2 points)
67 | - [ ] Performance implications assessed (2 points)
68 | - [ ] Security considerations addressed (2 points)
69 | - [ ] Maintenance impact evaluated (2 points)
70 | - [ ] Cost implications analyzed (2 points)
71 |
72 | ## 5. Verification Score [0-10]
73 | - [ ] Requirements traced (2 points)
74 | - [ ] Constraints validated (2 points)
75 | - [ ] Test scenarios defined (2 points)
76 | - [ ] Review feedback incorporated (2 points)
77 | - [ ] Final verification completed (2 points)
78 |
79 | Total Score: [Sum of all categories] / 50
80 | Minimum Required Score: 40/50 (80%)
81 | ```
82 |
83 | ## 📈 QUALITY THRESHOLDS
84 |
85 | ```mermaid
86 | graph TD
87 | subgraph "QUALITY GATES"
88 | T1["Minimum
40/50 (80%)"]
89 | T2["Target
45/50 (90%)"]
90 | T3["Excellent
48/50 (96%)"]
91 | end
92 |
93 | Score["Quality
Score"] --> Check{"Meets
Threshold?"}
94 | Check -->|"< 80%"| Block["⛔ BLOCKED
Improvements Required"]
95 | Check -->|"≥ 80%"| Pass["✓ PASSED
Can Proceed"]
96 |
97 | style T1 fill:#4dbb5f,stroke:#36873f,color:white
98 | style T2 fill:#ffa64d,stroke:#cc7a30,color:white
99 | style T3 fill:#d94dbb,stroke:#a3378a,color:white
100 | style Score fill:#4dbbbb,stroke:#368787,color:white
101 | style Check fill:#d971ff,stroke:#a33bc2,color:white
102 | ```
103 |
104 | ## 🎯 METRIC EVALUATION PROCESS
105 |
106 | ```mermaid
107 | graph TD
108 | Start["Start
Evaluation"] --> Doc["1. Score
Documentation"]
109 | Doc --> Dec["2. Assess
Decisions"]
110 | Dec --> Opt["3. Review
Options"]
111 | Opt --> Imp["4. Evaluate
Impact"]
112 | Imp --> Ver["5. Verify
Completeness"]
113 | Ver --> Total["Calculate
Total Score"]
114 | Total --> Check{"Meets
Threshold?"}
115 | Check -->|No| Return["Return for
Improvements"]
116 | Check -->|Yes| Proceed["Proceed to
Next Phase"]
117 |
118 | style Start fill:#4da6ff,stroke:#0066cc,color:white
119 | style Doc fill:#ffa64d,stroke:#cc7a30,color:white
120 | style Dec fill:#4dbb5f,stroke:#36873f,color:white
121 | style Opt fill:#d94dbb,stroke:#a3378a,color:white
122 | style Imp fill:#4dbbbb,stroke:#368787,color:white
123 | style Ver fill:#d971ff,stroke:#a33bc2,color:white
124 | ```
125 |
126 | ## 📊 IMPROVEMENT RECOMMENDATIONS
127 |
128 | For scores below threshold:
129 |
130 | ```markdown
131 | ## Documentation Quality Improvements
132 | - Add clear problem statements
133 | - Include specific objectives
134 | - List all requirements
135 | - Improve formatting
136 | - Add cross-references
137 |
138 | ## Decision Coverage Improvements
139 | - Identify missing decisions
140 | - Document all decision points
141 | - Map dependencies
142 | - Add impact analysis
143 | - Consider future implications
144 |
145 | ## Option Analysis Improvements
146 | - Consider more alternatives
147 | - Detail pros/cons
148 | - Assess technical feasibility
149 | - Estimate resource needs
150 | - Identify risks
151 |
152 | ## Impact Assessment Improvements
153 | - Document system impact
154 | - Assess performance
155 | - Address security
156 | - Evaluate maintenance
157 | - Analyze costs
158 |
159 | ## Verification Improvements
160 | - Trace requirements
161 | - Validate constraints
162 | - Define test scenarios
163 | - Incorporate feedback
164 | - Complete verification
165 | ```
166 |
167 | ## ✅ METRICS VERIFICATION CHECKLIST
168 |
169 | ```markdown
170 | ## Pre-Review Verification
171 | - [ ] All sections scored
172 | - [ ] Calculations verified
173 | - [ ] Supporting evidence attached
174 | - [ ] Improvement areas identified
175 | - [ ] Review feedback incorporated
176 |
177 | ## Final Metrics Verification
178 | - [ ] Minimum score achieved
179 | - [ ] All categories passed
180 | - [ ] Documentation complete
181 | - [ ] Improvements addressed
182 | - [ ] Final approval obtained
183 | ```
184 |
185 | ## 🔄 DOCUMENT MANAGEMENT
186 |
187 | ```mermaid
188 | graph TD
189 | Current["Current Document"] --> Active["Active:
- creative-phase-metrics.md"]
190 | Current --> Related["Related:
- creative-phase-enforcement.md
- creative-phase-architecture.md"]
191 |
192 | style Current fill:#4da6ff,stroke:#0066cc,color:white
193 | style Active fill:#4dbb5f,stroke:#36873f,color:white
194 | style Related fill:#ffa64d,stroke:#cc7a30,color:white
195 | ```
--------------------------------------------------------------------------------
/.cursor/rules/isolation_rules/Core/file-verification.mdc:
--------------------------------------------------------------------------------
1 | ---
2 | description: Optimized file verification
3 | globs: file-verification.mdc
4 | alwaysApply: false
5 | ---
6 | # OPTIMIZED FILE VERIFICATION SYSTEM
7 |
8 | > **TL;DR:** This system efficiently verifies and creates required Memory Bank file structures using batch operations and platform-optimized commands.
9 |
10 | ## 🔍 OPTIMIZED FILE VERIFICATION WORKFLOW
11 |
12 | ```mermaid
13 | graph TD
14 | Start["Start File
Verification"] --> VerifyAll["Verify All
Required Components"]
15 | VerifyAll --> MissingCheck{"Missing
Components?"}
16 | MissingCheck -->|"Yes"| BatchCreate["Batch Create
All Missing Items"]
17 | MissingCheck -->|"No"| Complete["Verification
Complete"]
18 | BatchCreate --> Report["Generate
Verification Report"]
19 | Report --> Complete
20 | ```
21 |
22 | ## 📋 OPTIMIZED DIRECTORY CREATION
23 |
24 | ```mermaid
25 | graph TD
26 | Start["Directory
Creation"] --> DetectOS["Detect Operating
System"]
27 | DetectOS -->|"Windows"| WinCmd["Batch Create
Windows Command"]
28 | DetectOS -->|"Mac/Linux"| UnixCmd["Batch Create
Unix Command"]
29 | WinCmd & UnixCmd --> Verify["Verify
Creation Success"]
30 | Verify --> Complete["Directory Setup
Complete"]
31 | ```
32 |
33 | ### Platform-Specific Commands
34 |
35 | #### Windows (PowerShell)
36 | ```powershell
37 | # Create all directories in one command
38 | mkdir memory-bank, docs, docs\archive -ErrorAction SilentlyContinue
39 |
40 | # Create all required files
41 | $files = @(".cursorrules", "tasks.md",
42 | "memory-bank\projectbrief.md",
43 | "memory-bank\productContext.md",
44 | "memory-bank\systemPatterns.md",
45 | "memory-bank\techContext.md",
46 | "memory-bank\activeContext.md",
47 | "memory-bank\progress.md")
48 |
49 | foreach ($file in $files) {
50 | if (-not (Test-Path $file)) {
51 | New-Item -Path $file -ItemType File -Force
52 | }
53 | }
54 | ```
55 |
56 | #### Mac/Linux (Bash)
57 | ```bash
58 | # Create all directories in one command
59 | mkdir -p memory-bank docs/archive
60 |
61 | # Create all required files
62 | touch .cursorrules tasks.md \
63 | memory-bank/projectbrief.md \
64 | memory-bank/productContext.md \
65 | memory-bank/systemPatterns.md \
66 | memory-bank/techContext.md \
67 | memory-bank/activeContext.md \
68 | memory-bank/progress.md
69 | ```
70 |
71 | ## 📝 STREAMLINED VERIFICATION PROCESS
72 |
73 | Instead of checking each component separately, perform batch verification:
74 |
75 | ```powershell
76 | # Windows - PowerShell
77 | $requiredDirs = @("memory-bank", "docs", "docs\archive")
78 | $requiredFiles = @(".cursorrules", "tasks.md")
79 | $mbFiles = @("projectbrief.md", "productContext.md", "systemPatterns.md",
80 | "techContext.md", "activeContext.md", "progress.md")
81 |
82 | $missingDirs = $requiredDirs | Where-Object { -not (Test-Path $_) -or -not (Test-Path $_ -PathType Container) }
83 | $missingFiles = $requiredFiles | Where-Object { -not (Test-Path $_) -or (Test-Path $_ -PathType Container) }
84 | $missingMBFiles = $mbFiles | ForEach-Object { "memory-bank\$_" } |
85 | Where-Object { -not (Test-Path $_) -or (Test-Path $_ -PathType Container) }
86 |
87 | if ($missingDirs.Count -eq 0 -and $missingFiles.Count -eq 0 -and $missingMBFiles.Count -eq 0) {
88 | Write-Output "✓ All required components verified"
89 | } else {
90 | # Create all missing items at once
91 | if ($missingDirs.Count -gt 0) {
92 | $missingDirs | ForEach-Object { mkdir $_ -Force }
93 | }
94 | if ($missingFiles.Count -gt 0 -or $missingMBFiles.Count -gt 0) {
95 | $allMissingFiles = $missingFiles + $missingMBFiles
96 | $allMissingFiles | ForEach-Object { New-Item -Path $_ -ItemType File -Force }
97 | }
98 | }
99 | ```
100 |
101 | ## 📝 TEMPLATE INITIALIZATION
102 |
103 | Optimize template creation with a single script:
104 |
105 | ```powershell
106 | # Windows - PowerShell
107 | $templates = @{
108 | "tasks.md" = @"
109 | # Memory Bank: Tasks
110 |
111 | ## Current Task
112 | [Task not yet defined]
113 |
114 | ## Status
115 | - [ ] Task definition
116 | - [ ] Implementation plan
117 | - [ ] Execution
118 | - [ ] Documentation
119 |
120 | ## Requirements
121 | [No requirements defined yet]
122 | "@
123 |
124 | "memory-bank\activeContext.md" = @"
125 | # Memory Bank: Active Context
126 |
127 | ## Current Focus
128 | [No active focus defined]
129 |
130 | ## Status
131 | [No status defined]
132 |
133 | ## Latest Changes
134 | [No changes recorded]
135 | "@
136 |
137 | # Add other templates here
138 | }
139 |
140 | foreach ($file in $templates.Keys) {
141 | if (Test-Path $file) {
142 | Set-Content -Path $file -Value $templates[$file]
143 | }
144 | }
145 | ```
146 |
147 | ## 🔍 PERFORMANCE OPTIMIZATION BEST PRACTICES
148 |
149 | 1. **Batch Operations**: Always use batch operations instead of individual commands
150 | ```
151 | # GOOD: Create all directories at once
152 | mkdir memory-bank docs docs\archive
153 |
154 | # BAD: Create directories one at a time
155 | mkdir memory-bank
156 | mkdir docs
157 | mkdir docs\archive
158 | ```
159 |
160 | 2. **Pre-Check Optimization**: Check all requirements first, then create only what's missing
161 | ```
162 | # First check what's missing
163 | $missingItems = ...
164 |
165 | # Then create only what's missing
166 | if ($missingItems) { ... }
167 | ```
168 |
169 | 3. **Error Handling**: Include error handling in all commands
170 | ```
171 | mkdir memory-bank, docs, docs\archive -ErrorAction SilentlyContinue
172 | ```
173 |
174 | 4. **Platform Adaptation**: Auto-detect platform and use appropriate commands
175 | ```
176 | if ($IsWindows) {
177 | # Windows commands
178 | } else {
179 | # Unix commands
180 | }
181 | ```
182 |
183 | 5. **One-Pass Verification**: Verify directory structure in a single pass
184 | ```
185 | $requiredPaths = @("memory-bank", "docs", "docs\archive", ".cursorrules", "tasks.md")
186 | $missingPaths = $requiredPaths | Where-Object { -not (Test-Path $_) }
187 | ```
188 |
189 | ## 📝 VERIFICATION REPORT FORMAT
190 |
191 | ```
192 | ✅ VERIFICATION COMPLETE
193 | - Created directories: [list]
194 | - Created files: [list]
195 | - All components verified
196 |
197 | Memory Bank system ready for use.
198 | ```
--------------------------------------------------------------------------------
/.cursor/rules/isolation_rules/Core/platform-awareness.mdc:
--------------------------------------------------------------------------------
1 | ---
2 | description: Platform detection and command adaptation for isolation-focused Memory Bank
3 | globs: platform-awareness.mdc
4 | alwaysApply: false
5 | ---
6 |
7 |
8 | # PLATFORM AWARENESS SYSTEM
9 |
10 | > **TL;DR:** This system detects the operating system, path format, and shell environment, then adapts commands accordingly to ensure cross-platform compatibility.
11 |
12 | ## 🔍 PLATFORM DETECTION PROCESS
13 |
14 | ```mermaid
15 | graph TD
16 | Start["Start Platform
Detection"] --> DetectOS["Detect OS
Environment"]
17 | DetectOS --> Windows["Windows
Detection"]
18 | DetectOS --> Mac["macOS
Detection"]
19 | DetectOS --> Linux["Linux
Detection"]
20 |
21 | Windows & Mac & Linux --> PathCheck["Path Separator
Detection"]
22 | PathCheck --> CmdAdapt["Command
Adaptation"]
23 | CmdAdapt --> ShellCheck["Shell Type
Detection"]
24 | ShellCheck --> Complete["Platform Detection
Complete"]
25 | ```
26 |
27 | ## 📋 PLATFORM DETECTION IMPLEMENTATION
28 |
29 | For reliable platform detection:
30 |
31 | ```
32 | ## Platform Detection Results
33 | Operating System: [Windows/macOS/Linux]
34 | Path Separator: [\ or /]
35 | Shell Environment: [PowerShell/Bash/Zsh/Cmd]
36 | Command Adaptation: [Required/Not Required]
37 |
38 | Adapting commands for [detected platform]...
39 | ```
40 |
41 | ## 🔍 PATH FORMAT CONVERSION
42 |
43 | When converting paths between formats:
44 |
45 | ```mermaid
46 | sequenceDiagram
47 | participant Input as Path Input
48 | participant Detector as Format Detector
49 | participant Converter as Format Converter
50 | participant Output as Adapted Path
51 |
52 | Input->>Detector: Raw Path
53 | Detector->>Detector: Detect Current Format
54 | Detector->>Converter: Path + Current Format
55 | Converter->>Converter: Apply Target Format
56 | Converter->>Output: Platform-Specific Path
57 | ```
58 |
59 | ## 📝 PLATFORM VERIFICATION CHECKLIST
60 |
61 | ```
62 | ✓ PLATFORM VERIFICATION
63 | - Operating system correctly identified? [YES/NO]
64 | - Path separator format detected? [YES/NO]
65 | - Shell environment identified? [YES/NO]
66 | - Command set adapted appropriately? [YES/NO]
67 | - Path format handling configured? [YES/NO]
68 |
69 | → If all YES: Platform adaptation complete
70 | → If any NO: Run additional detection steps
71 | ```
--------------------------------------------------------------------------------
/.cursor/rules/isolation_rules/Level3/planning-comprehensive.mdc:
--------------------------------------------------------------------------------
1 | ---
2 | description: planning comprehensive
3 | globs: planning-comprehensive.mdc
4 | alwaysApply: false
5 | ---
6 |
7 | # LEVEL 3 COMPREHENSIVE PLANNING
8 |
9 | > **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.
10 |
11 | ## 🏗️ PLANNING WORKFLOW
12 |
13 | ```mermaid
14 | graph TD
15 | Start["Planning Start"] --> Req["📋 Requirements
Analysis"]
16 | Req --> Comp["🔍 Component
Analysis"]
17 | Comp --> Design["🎨 Design
Decisions"]
18 | Design --> Impl["⚙️ Implementation
Strategy"]
19 | Impl --> Test["🧪 Testing
Strategy"]
20 | Test --> Doc["📚 Documentation
Plan"]
21 |
22 | Design --> Creative["Creative Phases:"]
23 | Creative --> UI["UI/UX Design"]
24 | Creative --> Arch["Architecture"]
25 | Creative --> Algo["Algorithm"]
26 |
27 | style Start fill:#4da6ff,stroke:#0066cc,color:white
28 | style Req fill:#ffa64d,stroke:#cc7a30,color:white
29 | style Comp fill:#4dbb5f,stroke:#36873f,color:white
30 | style Design fill:#d94dbb,stroke:#a3378a,color:white
31 | style Impl fill:#4dbbbb,stroke:#368787,color:white
32 | style Test fill:#d971ff,stroke:#a33bc2,color:white
33 | style Doc fill:#ff71c2,stroke:#c23b8a,color:white
34 | ```
35 |
36 | ## 📋 PLANNING TEMPLATE
37 |
38 | ```markdown
39 | # Feature Planning Document
40 |
41 | ## Requirements Analysis
42 | - Core Requirements:
43 | - [ ] Requirement 1
44 | - [ ] Requirement 2
45 | - Technical Constraints:
46 | - [ ] Constraint 1
47 | - [ ] Constraint 2
48 |
49 | ## Component Analysis
50 | - Affected Components:
51 | - Component 1
52 | - Changes needed:
53 | - Dependencies:
54 | - Component 2
55 | - Changes needed:
56 | - Dependencies:
57 |
58 | ## Design Decisions
59 | - Architecture:
60 | - [ ] Decision 1
61 | - [ ] Decision 2
62 | - UI/UX:
63 | - [ ] Design 1
64 | - [ ] Design 2
65 | - Algorithms:
66 | - [ ] Algorithm 1
67 | - [ ] Algorithm 2
68 |
69 | ## Implementation Strategy
70 | 1. Phase 1:
71 | - [ ] Task 1
72 | - [ ] Task 2
73 | 2. Phase 2:
74 | - [ ] Task 3
75 | - [ ] Task 4
76 |
77 | ## Testing Strategy
78 | - Unit Tests:
79 | - [ ] Test 1
80 | - [ ] Test 2
81 | - Integration Tests:
82 | - [ ] Test 3
83 | - [ ] Test 4
84 |
85 | ## Documentation Plan
86 | - [ ] API Documentation
87 | - [ ] User Guide Updates
88 | - [ ] Architecture Documentation
89 | ```
90 |
91 | ## 🎨 CREATIVE PHASE IDENTIFICATION
92 |
93 | ```mermaid
94 | graph TD
95 | subgraph "CREATIVE PHASES REQUIRED"
96 | UI["🎨 UI/UX Design
Required: Yes/No"]
97 | Arch["🏗️ Architecture Design
Required: Yes/No"]
98 | Algo["⚙️ Algorithm Design
Required: Yes/No"]
99 | end
100 |
101 | UI --> UITrig["Triggers:
- New UI Component
- UX Flow Change"]
102 | Arch --> ArchTrig["Triggers:
- System Structure Change
- New Integration"]
103 | Algo --> AlgoTrig["Triggers:
- Performance Critical
- Complex Logic"]
104 |
105 | style UI fill:#4dbb5f,stroke:#36873f,color:white
106 | style Arch fill:#ffa64d,stroke:#cc7a30,color:white
107 | style Algo fill:#d94dbb,stroke:#a3378a,color:white
108 | ```
109 |
110 | ## ✅ VERIFICATION CHECKLIST
111 |
112 | ```mermaid
113 | graph TD
114 | subgraph "PLANNING VERIFICATION"
115 | R["Requirements
Complete"]
116 | C["Components
Identified"]
117 | D["Design Decisions
Made"]
118 | I["Implementation
Plan Ready"]
119 | T["Testing Strategy
Defined"]
120 | Doc["Documentation
Plan Ready"]
121 | end
122 |
123 | R --> C --> D --> I --> T --> Doc
124 |
125 | style R fill:#4dbb5f,stroke:#36873f,color:white
126 | style C fill:#ffa64d,stroke:#cc7a30,color:white
127 | style D fill:#d94dbb,stroke:#a3378a,color:white
128 | style I fill:#4dbbbb,stroke:#368787,color:white
129 | style T fill:#d971ff,stroke:#a33bc2,color:white
130 | style Doc fill:#ff71c2,stroke:#c23b8a,color:white
131 | ```
132 |
133 | ## 🔄 IMPLEMENTATION PHASES
134 |
135 | ```mermaid
136 | graph LR
137 | Setup["🛠️ Setup"] --> Core["⚙️ Core
Implementation"]
138 | Core --> UI["🎨 UI
Implementation"]
139 | UI --> Test["🧪 Testing"]
140 | Test --> Doc["📚 Documentation"]
141 |
142 | style Setup fill:#4da6ff,stroke:#0066cc,color:white
143 | style Core fill:#4dbb5f,stroke:#36873f,color:white
144 | style UI fill:#ffa64d,stroke:#cc7a30,color:white
145 | style Test fill:#d94dbb,stroke:#a3378a,color:white
146 | style Doc fill:#4dbbbb,stroke:#368787,color:white
147 | ```
148 |
149 | ## 📚 DOCUMENT MANAGEMENT
150 |
151 | ```mermaid
152 | graph TD
153 | Current["Current Documents"] --> Active["Active:
- planning-comprehensive.md
- task-tracking-intermediate.md"]
154 | Current --> Next["Next Document:
- creative-phase-enforcement.md"]
155 |
156 | style Current fill:#4da6ff,stroke:#0066cc,color:white
157 | style Active fill:#4dbb5f,stroke:#36873f,color:white
158 | style Next fill:#ffa64d,stroke:#cc7a30,color:white
159 | ```
--------------------------------------------------------------------------------
/.cursor/rules/isolation_rules/Level3/task-tracking-intermediate.mdc:
--------------------------------------------------------------------------------
1 | ---
2 | description: task tracking intermediate
3 | globs: task-tracking-intermediate.mdc
4 | alwaysApply: false
5 | ---
6 | # LEVEL 3 INTERMEDIATE TASK TRACKING
7 |
8 | > **TL;DR:** This document provides structured task tracking guidelines for Level 3 (Intermediate Feature) tasks, using visual tracking elements and clear checkpoints.
9 |
10 | ## 🔍 TASK TRACKING WORKFLOW
11 |
12 | ```mermaid
13 | graph TD
14 | Start["Task Start"] --> Init["📋 Initialize
Task Entry"]
15 | Init --> Struct["🏗️ Create Task
Structure"]
16 | Struct --> Track["📊 Progress
Tracking"]
17 | Track --> Update["🔄 Regular
Updates"]
18 | Update --> Complete["✅ Task
Completion"]
19 |
20 | Struct --> Components["Components:"]
21 | Components --> Req["Requirements"]
22 | Components --> Steps["Implementation
Steps"]
23 | Components --> Creative["Creative Phase
Markers"]
24 | Components --> Check["Checkpoints"]
25 |
26 | Track --> Status["Track Status:"]
27 | Status --> InProg["🔄 In Progress"]
28 | Status --> Block["⛔ Blocked"]
29 | Status --> Done["✅ Complete"]
30 | Status --> Skip["⏭️ Skipped"]
31 |
32 | style Start fill:#4da6ff,stroke:#0066cc,color:white
33 | style Init fill:#ffa64d,stroke:#cc7a30,color:white
34 | style Struct fill:#4dbb5f,stroke:#36873f,color:white
35 | style Track fill:#d94dbb,stroke:#a3378a,color:white
36 | style Update fill:#4dbbbb,stroke:#368787,color:white
37 | style Complete fill:#d971ff,stroke:#a33bc2,color:white
38 | ```
39 |
40 | ## 📋 TASK ENTRY TEMPLATE
41 |
42 | ```markdown
43 | # [Task Title]
44 |
45 | ## Requirements
46 | - [ ] Requirement 1
47 | - [ ] Requirement 2
48 | - [ ] Requirement 3
49 |
50 | ## Components Affected
51 | - Component 1
52 | - Component 2
53 | - Component 3
54 |
55 | ## Implementation Steps
56 | 1. [ ] Step 1
57 | 2. [ ] Step 2
58 | 3. [ ] Step 3
59 |
60 | ## Creative Phases Required
61 | - [ ] 🎨 UI/UX Design
62 | - [ ] 🏗️ Architecture Design
63 | - [ ] ⚙️ Algorithm Design
64 |
65 | ## Checkpoints
66 | - [ ] Requirements verified
67 | - [ ] Creative phases completed
68 | - [ ] Implementation tested
69 | - [ ] Documentation updated
70 |
71 | ## Current Status
72 | - Phase: [Current Phase]
73 | - Status: [In Progress/Blocked/Complete]
74 | - Blockers: [If any]
75 | ```
76 |
77 | ## 🔄 PROGRESS TRACKING VISUALIZATION
78 |
79 | ```mermaid
80 | graph TD
81 | subgraph "TASK PROGRESS"
82 | P1["✓ Requirements
Defined"]
83 | P2["✓ Components
Identified"]
84 | P3["→ Creative Phase
In Progress"]
85 | P4["□ Implementation"]
86 | P5["□ Testing"]
87 | P6["□ Documentation"]
88 | end
89 |
90 | style P1 fill:#4dbb5f,stroke:#36873f,color:white
91 | style P2 fill:#4dbb5f,stroke:#36873f,color:white
92 | style P3 fill:#ffa64d,stroke:#cc7a30,color:white
93 | style P4 fill:#d94dbb,stroke:#a3378a,color:white
94 | style P5 fill:#4dbbbb,stroke:#368787,color:white
95 | style P6 fill:#d971ff,stroke:#a33bc2,color:white
96 | ```
97 |
98 | ## ✅ UPDATE PROTOCOL
99 |
100 | ```mermaid
101 | sequenceDiagram
102 | participant Task as Task Entry
103 | participant Status as Status Update
104 | participant Creative as Creative Phase
105 | participant Implementation as Implementation
106 |
107 | Task->>Status: Update Progress
108 | Status->>Creative: Flag for Creative Phase
109 | Creative->>Implementation: Complete Design
110 | Implementation->>Status: Update Status
111 | Status->>Task: Mark Complete
112 | ```
113 |
114 | ## 🎯 CHECKPOINT VERIFICATION
115 |
116 | | Phase | Verification Items | Status |
117 | |-------|-------------------|--------|
118 | | Requirements | All requirements documented | [ ] |
119 | | Components | Affected components listed | [ ] |
120 | | Creative | Design decisions documented | [ ] |
121 | | Implementation | Code changes tracked | [ ] |
122 | | Testing | Test results recorded | [ ] |
123 | | Documentation | Updates completed | [ ] |
124 |
125 | ## 🔄 DOCUMENT MANAGEMENT
126 |
127 | ```mermaid
128 | graph TD
129 | Current["Current Documents"] --> Active["Active:
- task-tracking-intermediate.md
- planning-comprehensive.md"]
130 | Current --> Required["Required Next:
- creative-phase-enforcement.md
- implementation-phase-reference.md"]
131 |
132 | style Current fill:#4da6ff,stroke:#0066cc,color:white
133 | style Active fill:#4dbb5f,stroke:#36873f,color:white
134 | style Required fill:#ffa64d,stroke:#cc7a30,color:white
135 | ```
--------------------------------------------------------------------------------
/.cursor/rules/isolation_rules/Phases/CreativePhase/creative-phase-architecture.mdc:
--------------------------------------------------------------------------------
1 | ---
2 | description: creative phase architecture
3 | globs: creative-phase-architecture.md
4 | alwaysApply: false
5 | ---
6 |
7 | # CREATIVE PHASE: ARCHITECTURE DESIGN
8 |
9 | > **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.
10 |
11 | ## 🏗️ ARCHITECTURE DESIGN WORKFLOW
12 |
13 | ```mermaid
14 | graph TD
15 | Start["Architecture
Design Start"] --> Req["1. Requirements
Analysis"]
16 | Req --> Comp["2. Component
Identification"]
17 | Comp --> Options["3. Architecture
Options"]
18 | Options --> Eval["4. Option
Evaluation"]
19 | Eval --> Decision["5. Decision &
Documentation"]
20 | Decision --> Valid["6. Validation &
Verification"]
21 |
22 | style Start fill:#4da6ff,stroke:#0066cc,color:white
23 | style Req fill:#ffa64d,stroke:#cc7a30,color:white
24 | style Comp fill:#4dbb5f,stroke:#36873f,color:white
25 | style Options fill:#d94dbb,stroke:#a3378a,color:white
26 | style Eval fill:#4dbbbb,stroke:#368787,color:white
27 | style Decision fill:#d971ff,stroke:#a33bc2,color:white
28 | style Valid fill:#ff71c2,stroke:#c23b8a,color:white
29 | ```
30 |
31 | ## 📋 ARCHITECTURE DECISION TEMPLATE
32 |
33 | ```markdown
34 | # Architecture Decision Record
35 |
36 | ## Context
37 | - System Requirements:
38 | - [Requirement 1]
39 | - [Requirement 2]
40 | - Technical Constraints:
41 | - [Constraint 1]
42 | - [Constraint 2]
43 |
44 | ## Component Analysis
45 | - Core Components:
46 | - [Component 1]: [Purpose/Role]
47 | - [Component 2]: [Purpose/Role]
48 | - Interactions:
49 | - [Interaction 1]
50 | - [Interaction 2]
51 |
52 | ## Architecture Options
53 | ### Option 1: [Name]
54 | - Description: [Brief description]
55 | - Pros:
56 | - [Pro 1]
57 | - [Pro 2]
58 | - Cons:
59 | - [Con 1]
60 | - [Con 2]
61 | - Technical Fit: [High/Medium/Low]
62 | - Complexity: [High/Medium/Low]
63 | - Scalability: [High/Medium/Low]
64 |
65 | ### Option 2: [Name]
66 | [Same structure as Option 1]
67 |
68 | ## Decision
69 | - Chosen Option: [Option name]
70 | - Rationale: [Explanation]
71 | - Implementation Considerations:
72 | - [Consideration 1]
73 | - [Consideration 2]
74 |
75 | ## Validation
76 | - Requirements Met:
77 | - [✓] Requirement 1
78 | - [✓] Requirement 2
79 | - Technical Feasibility: [Assessment]
80 | - Risk Assessment: [Evaluation]
81 | ```
82 |
83 | ## 🎯 ARCHITECTURE EVALUATION CRITERIA
84 |
85 | ```mermaid
86 | graph TD
87 | subgraph "EVALUATION CRITERIA"
88 | C1["Scalability"]
89 | C2["Maintainability"]
90 | C3["Performance"]
91 | C4["Security"]
92 | C5["Cost"]
93 | C6["Time to Market"]
94 | end
95 |
96 | style C1 fill:#4dbb5f,stroke:#36873f,color:white
97 | style C2 fill:#ffa64d,stroke:#cc7a30,color:white
98 | style C3 fill:#d94dbb,stroke:#a3378a,color:white
99 | style C4 fill:#4dbbbb,stroke:#368787,color:white
100 | style C5 fill:#d971ff,stroke:#a33bc2,color:white
101 | style C6 fill:#ff71c2,stroke:#c23b8a,color:white
102 | ```
103 |
104 | ## 📊 ARCHITECTURE VISUALIZATION TEMPLATES
105 |
106 | ### Component Diagram Template
107 | ```mermaid
108 | graph TD
109 | subgraph "SYSTEM ARCHITECTURE"
110 | C1["Component 1"]
111 | C2["Component 2"]
112 | C3["Component 3"]
113 |
114 | C1 -->|"Interface 1"| C2
115 | C2 -->|"Interface 2"| C3
116 | end
117 |
118 | style C1 fill:#4dbb5f,stroke:#36873f,color:white
119 | style C2 fill:#ffa64d,stroke:#cc7a30,color:white
120 | style C3 fill:#d94dbb,stroke:#a3378a,color:white
121 | ```
122 |
123 | ### Data Flow Template
124 | ```mermaid
125 | sequenceDiagram
126 | participant C1 as Component 1
127 | participant C2 as Component 2
128 | participant C3 as Component 3
129 |
130 | C1->>C2: Request
131 | C2->>C3: Process
132 | C3-->>C2: Response
133 | C2-->>C1: Result
134 | ```
135 |
136 | ## ✅ VERIFICATION CHECKLIST
137 |
138 | ```markdown
139 | ## Architecture Design Verification
140 | - [ ] All system requirements addressed
141 | - [ ] Component responsibilities defined
142 | - [ ] Interfaces specified
143 | - [ ] Data flows documented
144 | - [ ] Security considerations addressed
145 | - [ ] Scalability requirements met
146 | - [ ] Performance requirements met
147 | - [ ] Maintenance approach defined
148 |
149 | ## Implementation Readiness
150 | - [ ] All components identified
151 | - [ ] Dependencies mapped
152 | - [ ] Technical constraints documented
153 | - [ ] Risk assessment completed
154 | - [ ] Resource requirements defined
155 | - [ ] Timeline estimates provided
156 | ```
157 |
158 | ## 🔄 ARCHITECTURE REVIEW PROCESS
159 |
160 | ```mermaid
161 | graph TD
162 | subgraph "REVIEW PROCESS"
163 | R1["Technical
Review"]
164 | R2["Security
Review"]
165 | R3["Performance
Review"]
166 | R4["Final
Approval"]
167 | end
168 |
169 | R1 --> R2 --> R3 --> R4
170 |
171 | style R1 fill:#4dbb5f,stroke:#36873f,color:white
172 | style R2 fill:#ffa64d,stroke:#cc7a30,color:white
173 | style R3 fill:#d94dbb,stroke:#a3378a,color:white
174 | style R4 fill:#4dbbbb,stroke:#368787,color:white
175 | ```
176 |
177 | ## 🔄 DOCUMENT MANAGEMENT
178 |
179 | ```mermaid
180 | graph TD
181 | Current["Current Document"] --> Active["Active:
- creative-phase-architecture.md"]
182 | Current --> Related["Related:
- creative-phase-enforcement.md
- planning-comprehensive.md"]
183 |
184 | style Current fill:#4da6ff,stroke:#0066cc,color:white
185 | style Active fill:#4dbb5f,stroke:#36873f,color:white
186 | style Related fill:#ffa64d,stroke:#cc7a30,color:white
187 | ```
--------------------------------------------------------------------------------
/.cursor/rules/isolation_rules/main.mdc:
--------------------------------------------------------------------------------
1 | ---
2 | description: main rule
3 | globs: main.mdc
4 | alwaysApply: false
5 | ---
6 |
7 | # 🔍 ISOLATION-FOCUSED MEMORY BANK SYSTEM
8 |
9 | > **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.
10 |
11 | ## 🧭 MODE-SPECIFIC VISUAL MAPS
12 |
13 | ```mermaid
14 | graph TD
15 | subgraph Modes["Cursor Custom Modes"]
16 | VAN["VAN MODE
Initialization"] --> PLAN["PLAN MODE
Task Planning"]
17 | PLAN --> Creative["CREATIVE MODE
Design Decisions"]
18 | Creative --> Implement["IMPLEMENT MODE
Code Implementation"]
19 | Implement --> Reflect["REFLECT MODE
Task Review"]
20 | Reflect --> Archive["ARCHIVE MODE
Documentation"]
21 | end
22 |
23 | VAN -.->|"Loads"| VANRules["• main.md
• platform-awareness.md
• file-verification.md
• workflow-init.md"]
24 | PLAN -.->|"Loads"| PLANRules["• main.md
• task-tracking.md
• planning-process.md"]
25 | Creative -.->|"Loads"| CreativeRules["• main.md
• creative-phase.md
• design-patterns.md"]
26 | Implement -.->|"Loads"| ImplementRules["• main.md
• command-execution.md
• implementation-guide.md"]
27 | Reflect -.->|"Loads"| ReflectRules["• main.md
• reflection-format.md"]
28 | Archive -.->|"Loads"| ArchiveRules["• main.md
• archiving-guide.md"]
29 | ```
30 |
31 | ## 📚 VISUAL PROCESS MAPS
32 |
33 | Each mode has its own visual process map:
34 |
35 | - [VAN Mode Map](mdc:visual-maps/van-mode-map.md)
36 | - [PLAN Mode Map](mdc:visual-maps/plan-mode-map.md)
37 | - [CREATIVE Mode Map](mdc:visual-maps/creative-mode-map.md)
38 | - [IMPLEMENT Mode Map](mdc:visual-maps/implement-mode-map.md)
39 | - [REFLECT Mode Map](mdc:visual-maps/reflect-mode-map.md)
40 | - [ARCHIVE Mode Map](mdc:visual-maps/archive-mode-map.md)
41 |
42 | ## 🔄 FILE STATE VERIFICATION
43 |
44 | In this isolation-focused approach, Memory Bank files maintain continuity between modes:
45 |
46 | ```mermaid
47 | graph TD
48 | subgraph "Memory Bank Files"
49 | tasks["tasks.md
Source of Truth"]
50 | active["activeContext.md
Current Focus"]
51 | creative["creative-*.md
Design Decisions"]
52 | progress["progress.md
Implementation Status"]
53 | end
54 |
55 | VAN["VAN MODE"] -->|"Creates/Updates"| tasks
56 | VAN -->|"Creates/Updates"| active
57 |
58 | PLAN["PLAN MODE"] -->|"Reads"| tasks
59 | PLAN -->|"Reads"| active
60 | PLAN -->|"Updates"| tasks
61 |
62 | Creative["CREATIVE MODE"] -->|"Reads"| tasks
63 | Creative -->|"Creates"| creative
64 | Creative -->|"Updates"| tasks
65 |
66 | Implement["IMPLEMENT MODE"] -->|"Reads"| tasks
67 | Implement -->|"Reads"| creative
68 | Implement -->|"Updates"| tasks
69 | Implement -->|"Updates"| progress
70 |
71 | Reflect["REFLECT MODE"] -->|"Reads"| tasks
72 | Reflect -->|"Reads"| progress
73 | Reflect -->|"Updates"| tasks
74 |
75 | Archive["ARCHIVE MODE"] -->|"Reads"| tasks
76 | Archive -->|"Reads"| progress
77 | Archive -->|"Archives"| creative
78 | ```
79 |
80 | ## 📋 MODE TRANSITION PROTOCOL
81 |
82 | ```mermaid
83 | sequenceDiagram
84 | participant User
85 | participant CurrentMode
86 | participant NextMode
87 |
88 | CurrentMode->>CurrentMode: Complete Phase Requirements
89 | CurrentMode->>User: "Phase complete. NEXT MODE: [mode name]"
90 | User->>CurrentMode: End Current Mode
91 | User->>NextMode: Start Next Mode
92 | NextMode->>NextMode: Verify Required File State
93 |
94 | alt File State Valid
95 | NextMode->>User: "Continuing from previous mode..."
96 | else File State Invalid
97 | NextMode->>User: "Required files not in expected state"
98 | NextMode->>User: "Return to [previous mode] to complete requirements"
99 | end
100 | ```
101 |
102 | ## 💻 PLATFORM-SPECIFIC COMMANDS
103 |
104 | | Action | Windows | Mac/Linux |
105 | |--------|---------|-----------|
106 | | Create file | `echo. > file.ext` | `touch file.ext` |
107 | | Create directory | `mkdir directory` | `mkdir -p directory` |
108 | | Change directory | `cd directory` | `cd directory` |
109 | | List files | `dir` | `ls` |
110 | | Show file content | `type file.ext` | `cat file.ext` |
111 |
112 | ## ⚠️ COMMAND EFFICIENCY GUIDANCE
113 |
114 | For optimal performance, use efficient command chaining when appropriate:
115 |
116 | ```
117 | # Efficient command chaining examples:
118 | mkdir -p project/{src,tests,docs} && cd project
119 | grep "TODO" $(find . -name "*.js")
120 | npm install && npm start
121 | ```
122 |
123 | Refer to [command-execution.md](mdc:Core/command-execution.md) for detailed guidance.
--------------------------------------------------------------------------------
/.cursor/rules/isolation_rules/visual-maps/archive-mode-map.mdc:
--------------------------------------------------------------------------------
1 | ---
2 | description:
3 | globs:
4 | alwaysApply: false
5 | ---
6 | ---
7 | description: Visual process map for ARCHIVE mode (Task Documentation)
8 | globs: "**/archive*/**", "**/document*/**", "**/complete*/**"
9 | alwaysApply: false
10 | ---
11 |
12 | # ARCHIVE MODE: TASK DOCUMENTATION PROCESS MAP
13 |
14 | > **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.
15 |
16 | ## 🧭 ARCHIVE MODE PROCESS FLOW
17 |
18 | ```mermaid
19 | graph TD
20 | Start["START ARCHIVE MODE"] --> ReadTasks["Read tasks.md
reflection.md and
progress.md"]
21 |
22 | %% Initial Assessment
23 | ReadTasks --> VerifyReflect{"Reflection
Complete?"}
24 | VerifyReflect -->|"No"| ReturnReflect["Return to
REFLECT Mode"]
25 | VerifyReflect -->|"Yes"| AssessLevel{"Determine
Complexity Level"}
26 |
27 | %% Level-Based Archiving
28 | AssessLevel -->|"Level 1"| L1Archive["LEVEL 1 ARCHIVING
Level1/archive-minimal.md"]
29 | AssessLevel -->|"Level 2"| L2Archive["LEVEL 2 ARCHIVING
Level2/archive-basic.md"]
30 | AssessLevel -->|"Level 3"| L3Archive["LEVEL 3 ARCHIVING
Level3/archive-standard.md"]
31 | AssessLevel -->|"Level 4"| L4Archive["LEVEL 4 ARCHIVING
Level4/archive-comprehensive.md"]
32 |
33 | %% Level 1 Archiving (Minimal)
34 | L1Archive --> L1Summary["Create Quick
Summary"]
35 | L1Summary --> L1Task["Update
tasks.md"]
36 | L1Task --> L1Complete["Mark Task
Complete"]
37 |
38 | %% Level 2 Archiving (Basic)
39 | L2Archive --> L2Summary["Create Basic
Archive Document"]
40 | L2Summary --> L2Doc["Document
Changes"]
41 | L2Doc --> L2Task["Update
tasks.md"]
42 | L2Task --> L2Progress["Update
progress.md"]
43 | L2Progress --> L2Complete["Mark Task
Complete"]
44 |
45 | %% Level 3-4 Archiving (Comprehensive)
46 | L3Archive & L4Archive --> L34Summary["Create Comprehensive
Archive Document"]
47 | L34Summary --> L34Doc["Document
Implementation"]
48 | L34Doc --> L34Creative["Archive Creative
Phase Documents"]
49 | L34Creative --> L34Code["Document Code
Changes"]
50 | L34Code --> L34Test["Document
Testing"]
51 | L34Test --> L34Lessons["Summarize
Lessons Learned"]
52 | L34Lessons --> L34Task["Update
tasks.md"]
53 | L34Task --> L34Progress["Update
progress.md"]
54 | L34Progress --> L34System["Update System
Documentation"]
55 | L34System --> L34Complete["Mark Task
Complete"]
56 |
57 | %% Completion
58 | L1Complete & L2Complete & L34Complete --> CreateArchive["Create Archive
Document in
docs/archive/"]
59 | CreateArchive --> UpdateActive["Update
activeContext.md"]
60 | UpdateActive --> Reset["Reset for
Next Task"]
61 | ```
62 |
63 | ## 📋 ARCHIVE DOCUMENT STRUCTURE
64 |
65 | The archive document should follow this structured format:
66 |
67 | ```mermaid
68 | graph TD
69 | subgraph "Archive Document Structure"
70 | Header["# TASK ARCHIVE: [Task Name]"]
71 | Meta["## METADATA
Task info, dates, complexity"]
72 | Summary["## SUMMARY
Brief overview of the task"]
73 | Requirements["## REQUIREMENTS
What the task needed to accomplish"]
74 | Implementation["## IMPLEMENTATION
How the task was implemented"]
75 | Testing["## TESTING
How the solution was verified"]
76 | Lessons["## LESSONS LEARNED
Key takeaways from the task"]
77 | Refs["## REFERENCES
Links to related documents"]
78 | end
79 |
80 | Header --> Meta --> Summary --> Requirements --> Implementation --> Testing --> Lessons --> Refs
81 | ```
82 |
83 | ## 📊 REQUIRED FILE STATE VERIFICATION
84 |
85 | Before archiving can begin, verify file state:
86 |
87 | ```mermaid
88 | graph TD
89 | Start["File State
Verification"] --> CheckTasks{"tasks.md has
reflection
complete?"}
90 |
91 | CheckTasks -->|"No"| ErrorReflect["ERROR:
Return to REFLECT Mode"]
92 | CheckTasks -->|"Yes"| CheckReflection{"reflection.md
exists?"}
93 |
94 | CheckReflection -->|"No"| ErrorCreate["ERROR:
Create reflection.md first"]
95 | CheckReflection -->|"Yes"| CheckProgress{"progress.md
updated?"}
96 |
97 | CheckProgress -->|"No"| ErrorProgress["ERROR:
Update progress.md first"]
98 | CheckProgress -->|"Yes"| ReadyArchive["Ready for
Archiving"]
99 | ```
100 |
101 | ## 🔍 ARCHIVE TYPES BY COMPLEXITY
102 |
103 | ```mermaid
104 | graph TD
105 | subgraph "Level 1: Minimal Archive"
106 | L1A["Basic Bug
Description"]
107 | L1B["Solution
Summary"]
108 | L1C["Affected
Files"]
109 | end
110 |
111 | subgraph "Level 2: Basic Archive"
112 | L2A["Enhancement
Description"]
113 | L2B["Implementation
Summary"]
114 | L2C["Testing
Results"]
115 | L2D["Lessons
Learned"]
116 | end
117 |
118 | subgraph "Level 3-4: Comprehensive Archive"
119 | L3A["Detailed
Requirements"]
120 | L3B["Architecture/
Design Decisions"]
121 | L3C["Implementation
Details"]
122 | L3D["Testing
Strategy"]
123 | L3E["Performance
Considerations"]
124 | L3F["Future
Enhancements"]
125 | L3G["Cross-References
to Other Systems"]
126 | end
127 |
128 | L1A --> L1B --> L1C
129 |
130 | L2A --> L2B --> L2C --> L2D
131 |
132 | L3A --> L3B --> L3C --> L3D --> L3E --> L3F --> L3G
133 | ```
134 |
135 | ## 📝 ARCHIVE DOCUMENT TEMPLATES
136 |
137 | ### Level 1 (Minimal) Archive
138 | ```
139 | # Bug Fix Archive: [Bug Name]
140 |
141 | ## Date
142 | [Date of fix]
143 |
144 | ## Summary
145 | [Brief description of the bug and solution]
146 |
147 | ## Implementation
148 | [Description of the fix implemented]
149 |
150 | ## Files Changed
151 | - [File 1]
152 | - [File 2]
153 | ```
154 |
155 | ### Levels 2-4 (Comprehensive) Archive
156 | ```
157 | # Task Archive: [Task Name]
158 |
159 | ## Metadata
160 | - **Complexity**: Level [2/3/4]
161 | - **Type**: [Enhancement/Feature/System]
162 | - **Date Completed**: [Date]
163 | - **Related Tasks**: [Related task references]
164 |
165 | ## Summary
166 | [Comprehensive summary of the task]
167 |
168 | ## Requirements
169 | - [Requirement 1]
170 | - [Requirement 2]
171 | - [Requirement 3]
172 |
173 | ## Implementation
174 | ### Approach
175 | [Description of implementation approach]
176 |
177 | ### Key Components
178 | - [Component 1]: [Description]
179 | - [Component 2]: [Description]
180 |
181 | ### Files Changed
182 | - [File 1]: [Description of changes]
183 | - [File 2]: [Description of changes]
184 |
185 | ## Testing
186 | - [Test 1]: [Result]
187 | - [Test 2]: [Result]
188 |
189 | ## Lessons Learned
190 | - [Lesson 1]
191 | - [Lesson 2]
192 | - [Lesson 3]
193 |
194 | ## Future Considerations
195 | - [Future enhancement 1]
196 | - [Future enhancement 2]
197 |
198 | ## References
199 | - [Link to reflection document]
200 | - [Link to creative phase documents]
201 | - [Other relevant references]
202 | ```
203 |
204 | ## 📋 ARCHIVE LOCATION AND NAMING
205 |
206 | Archive documents should be organized following this pattern:
207 |
208 | ```mermaid
209 | graph TD
210 | subgraph "Archive Structure"
211 | Root["docs/archive/"]
212 | Tasks["tasks/"]
213 | Features["features/"]
214 | Systems["systems/"]
215 |
216 | Root --> Tasks
217 | Root --> Features
218 | Root --> Systems
219 |
220 | Tasks --> Bug["bug-fix-name-YYYYMMDD.md"]
221 | Tasks --> Enhancement["enhancement-name-YYYYMMDD.md"]
222 | Features --> Feature["feature-name-YYYYMMDD.md"]
223 | Systems --> System["system-name-YYYYMMDD.md"]
224 | end
225 | ```
226 |
227 | ## 📊 TASKS.MD FINAL UPDATE
228 |
229 | When archiving is complete, update tasks.md with:
230 |
231 | ```
232 | ## Status
233 | - [x] Initialization complete
234 | - [x] Planning complete
235 | [For Level 3-4:]
236 | - [x] Creative phases complete
237 | - [x] Implementation complete
238 | - [x] Reflection complete
239 | - [x] Archiving complete
240 |
241 | ## Archive
242 | - **Date**: [Completion date]
243 | - **Archive Document**: [Link to archive document]
244 | - **Status**: COMPLETED
245 | ```
246 |
247 | ## 📋 ARCHIVE VERIFICATION CHECKLIST
248 |
249 | ```
250 | ✓ ARCHIVE VERIFICATION
251 | - Reflection document reviewed? [YES/NO]
252 | - Archive document created with all sections? [YES/NO]
253 | - Archive document placed in correct location? [YES/NO]
254 | - tasks.md marked as completed? [YES/NO]
255 | - progress.md updated with archive reference? [YES/NO]
256 | - activeContext.md updated for next task? [YES/NO]
257 | - Creative phase documents archived (Level 3-4)? [YES/NO/NA]
258 |
259 | → If all YES: Archiving complete - Memory Bank reset for next task
260 | → If any NO: Complete missing archive elements
261 | ```
262 |
263 | ## 🔄 TASK COMPLETION NOTIFICATION
264 |
265 | When archiving is complete, notify user with:
266 |
267 | ```
268 | ## TASK ARCHIVED
269 |
270 | ✅ Archive document created in docs/archive/
271 | ✅ All task documentation preserved
272 | ✅ Memory Bank updated with references
273 | ✅ Task marked as COMPLETED
274 |
275 | → Memory Bank is ready for the next task
276 | → To start a new task, use VAN MODE
277 | ```
--------------------------------------------------------------------------------
/.cursor/rules/isolation_rules/visual-maps/creative-mode-map.mdc:
--------------------------------------------------------------------------------
1 | ---
2 | description: Visual process map for CREATIVE mode (Design Decisions)
3 | globs: "**/creative*/**", "**/design*/**", "**/decision*/**"
4 | alwaysApply: false
5 | ---
6 |
7 | # CREATIVE MODE: DESIGN PROCESS MAP
8 |
9 | > **TL;DR:** This visual map guides the CREATIVE mode process, focusing on structured design decision-making for components that require deeper exploration before implementation.
10 |
11 | ## 🧭 CREATIVE MODE PROCESS FLOW
12 |
13 | ```mermaid
14 | graph TD
15 | Start["START CREATIVE MODE"] --> ReadTasks["Read tasks.md
For Creative Requirements"]
16 |
17 | %% Initial Assessment
18 | ReadTasks --> VerifyPlan{"Plan Complete
& Creative Phases
Identified?"}
19 | VerifyPlan -->|"No"| ReturnPlan["Return to
PLAN Mode"]
20 | VerifyPlan -->|"Yes"| IdentifyPhases["Identify Creative
Phases Required"]
21 |
22 | %% Creative Phase Selection
23 | IdentifyPhases --> SelectPhase["Select Next
Creative Phase"]
24 | SelectPhase --> PhaseType{"Creative
Phase Type?"}
25 |
26 | %% Creative Phase Types
27 | PhaseType -->|"UI/UX
Design"| UIPhase["UI/UX CREATIVE PHASE
Core/creative-phase-uiux.md"]
28 | PhaseType -->|"Architecture
Design"| ArchPhase["ARCHITECTURE CREATIVE PHASE
Core/creative-phase-architecture.md"]
29 | PhaseType -->|"Data Model
Design"| DataPhase["DATA MODEL CREATIVE PHASE
Core/creative-phase-data.md"]
30 | PhaseType -->|"Algorithm
Design"| AlgoPhase["ALGORITHM CREATIVE PHASE
Core/creative-phase-algorithm.md"]
31 |
32 | %% UI/UX Creative Phase
33 | UIPhase --> UI_Problem["Define UI/UX
Problem"]
34 | UI_Problem --> UI_Research["Research UI
Patterns"]
35 | UI_Research --> UI_Options["Explore UI
Options"]
36 | UI_Options --> UI_Evaluate["Evaluate User
Experience"]
37 | UI_Evaluate --> UI_Decision["Make Design
Decision"]
38 | UI_Decision --> UI_Document["Document UI
Design"]
39 |
40 | %% Architecture Creative Phase
41 | ArchPhase --> Arch_Problem["Define Architecture
Challenge"]
42 | Arch_Problem --> Arch_Options["Explore Architecture
Options"]
43 | Arch_Options --> Arch_Analyze["Analyze Tradeoffs"]
44 | Arch_Analyze --> Arch_Decision["Make Architecture
Decision"]
45 | Arch_Decision --> Arch_Document["Document
Architecture"]
46 | Arch_Document --> Arch_Diagram["Create Architecture
Diagram"]
47 |
48 | %% Data Model Creative Phase
49 | DataPhase --> Data_Requirements["Define Data
Requirements"]
50 | Data_Requirements --> Data_Structure["Design Data
Structure"]
51 | Data_Structure --> Data_Relations["Define
Relationships"]
52 | Data_Relations --> Data_Validation["Design
Validation"]
53 | Data_Validation --> Data_Document["Document
Data Model"]
54 |
55 | %% Algorithm Creative Phase
56 | AlgoPhase --> Algo_Problem["Define Algorithm
Problem"]
57 | Algo_Problem --> Algo_Options["Explore Algorithm
Approaches"]
58 | Algo_Options --> Algo_Evaluate["Evaluate Time/Space
Complexity"]
59 | Algo_Evaluate --> Algo_Decision["Make Algorithm
Decision"]
60 | Algo_Decision --> Algo_Document["Document
Algorithm"]
61 |
62 | %% Documentation & Completion
63 | UI_Document & Arch_Diagram & Data_Document & Algo_Document --> CreateDoc["Create Creative
Phase Document"]
64 | CreateDoc --> UpdateTasks["Update tasks.md
with Decision"]
65 | UpdateTasks --> MorePhases{"More Creative
Phases?"}
66 | MorePhases -->|"Yes"| SelectPhase
67 | MorePhases -->|"No"| VerifyComplete["Verify All
Phases Complete"]
68 | VerifyComplete --> NotifyComplete["Signal Creative
Phases Complete"]
69 | ```
70 |
71 | ## 📋 CREATIVE PHASE DOCUMENT FORMAT
72 |
73 | Each creative phase should produce a document with this structure:
74 |
75 | ```mermaid
76 | graph TD
77 | subgraph "Creative Phase Document"
78 | Header["🎨 CREATIVE PHASE: [TYPE]"]
79 | Problem["PROBLEM STATEMENT
Clear definition of the problem"]
80 | Options["OPTIONS ANALYSIS
Multiple approaches considered"]
81 | Pros["PROS & CONS
Tradeoffs for each option"]
82 | Decision["DECISION
Selected approach + rationale"]
83 | Impl["IMPLEMENTATION PLAN
Steps to implement the decision"]
84 | Diagram["VISUALIZATION
Diagrams of the solution"]
85 | end
86 |
87 | Header --> Problem --> Options --> Pros --> Decision --> Impl --> Diagram
88 | ```
89 |
90 | ## 🔍 CREATIVE TYPES AND APPROACHES
91 |
92 | ```mermaid
93 | graph TD
94 | subgraph "UI/UX Design"
95 | UI1["User Flow
Analysis"]
96 | UI2["Component
Hierarchy"]
97 | UI3["Interaction
Patterns"]
98 | UI4["Visual Design
Principles"]
99 | end
100 |
101 | subgraph "Architecture Design"
102 | A1["Component
Structure"]
103 | A2["Data Flow
Patterns"]
104 | A3["Interface
Design"]
105 | A4["System
Integration"]
106 | end
107 |
108 | subgraph "Data Model Design"
109 | D1["Entity
Relationships"]
110 | D2["Schema
Design"]
111 | D3["Validation
Rules"]
112 | D4["Query
Optimization"]
113 | end
114 |
115 | subgraph "Algorithm Design"
116 | AL1["Complexity
Analysis"]
117 | AL2["Efficiency
Optimization"]
118 | AL3["Edge Case
Handling"]
119 | AL4["Scaling
Considerations"]
120 | end
121 | ```
122 |
123 | ## 📊 REQUIRED FILE STATE VERIFICATION
124 |
125 | Before creative phase work can begin, verify file state:
126 |
127 | ```mermaid
128 | graph TD
129 | Start["File State
Verification"] --> CheckTasks{"tasks.md has
planning complete?"}
130 |
131 | CheckTasks -->|"No"| ErrorPlan["ERROR:
Return to PLAN Mode"]
132 | CheckTasks -->|"Yes"| CheckCreative{"Creative phases
identified?"}
133 |
134 | CheckCreative -->|"No"| ErrorCreative["ERROR:
Return to PLAN Mode"]
135 | CheckCreative -->|"Yes"| ReadyCreative["Ready for
Creative Phase"]
136 | ```
137 |
138 | ## 📋 OPTIONS ANALYSIS TEMPLATE
139 |
140 | For each creative phase, analyze multiple options:
141 |
142 | ```
143 | ## OPTIONS ANALYSIS
144 |
145 | ### Option 1: [Name]
146 | **Description**: [Brief description]
147 | **Pros**:
148 | - [Pro 1]
149 | - [Pro 2]
150 | **Cons**:
151 | - [Con 1]
152 | - [Con 2]
153 | **Complexity**: [Low/Medium/High]
154 | **Implementation Time**: [Estimate]
155 |
156 | ### Option 2: [Name]
157 | **Description**: [Brief description]
158 | **Pros**:
159 | - [Pro 1]
160 | - [Pro 2]
161 | **Cons**:
162 | - [Con 1]
163 | - [Con 2]
164 | **Complexity**: [Low/Medium/High]
165 | **Implementation Time**: [Estimate]
166 |
167 | ### Option 3: [Name]
168 | **Description**: [Brief description]
169 | **Pros**:
170 | - [Pro 1]
171 | - [Pro 2]
172 | **Cons**:
173 | - [Con 1]
174 | - [Con 2]
175 | **Complexity**: [Low/Medium/High]
176 | **Implementation Time**: [Estimate]
177 | ```
178 |
179 | ## 🎨 CREATIVE PHASE MARKERS
180 |
181 | Use these visual markers for creative phases:
182 |
183 | ```
184 | 🎨🎨🎨 ENTERING CREATIVE PHASE: [TYPE] 🎨🎨🎨
185 |
186 | [Creative phase content]
187 |
188 | 🎨 CREATIVE CHECKPOINT: [Milestone]
189 |
190 | [Additional content]
191 |
192 | 🎨🎨🎨 EXITING CREATIVE PHASE - DECISION MADE 🎨🎨🎨
193 | ```
194 |
195 | ## 📊 CREATIVE PHASE VERIFICATION CHECKLIST
196 |
197 | ```
198 | ✓ CREATIVE PHASE VERIFICATION
199 | - Problem clearly defined? [YES/NO]
200 | - Multiple options considered (3+)? [YES/NO]
201 | - Pros/cons documented for each option? [YES/NO]
202 | - Decision made with clear rationale? [YES/NO]
203 | - Implementation plan included? [YES/NO]
204 | - Visualization/diagrams created? [YES/NO]
205 | - tasks.md updated with decision? [YES/NO]
206 |
207 | → If all YES: Creative phase complete
208 | → If any NO: Complete missing elements
209 | ```
210 |
211 | ## 🔄 MODE TRANSITION NOTIFICATION
212 |
213 | When all creative phases are complete, notify user with:
214 |
215 | ```
216 | ## CREATIVE PHASES COMPLETE
217 |
218 | ✅ All required design decisions made
219 | ✅ Creative phase documents created
220 | ✅ tasks.md updated with decisions
221 | ✅ Implementation plan updated
222 |
223 | → NEXT RECOMMENDED MODE: IMPLEMENT MODE
224 | ```
--------------------------------------------------------------------------------
/.cursor/rules/isolation_rules/visual-maps/reflect-mode-map.mdc:
--------------------------------------------------------------------------------
1 | ---
2 | description:
3 | globs:
4 | alwaysApply: false
5 | ---
6 | ---
7 | description: Visual process map for REFLECT mode (Task Reflection)
8 | globs: "**/reflect*/**", "**/review*/**", "**/retrospect*/**"
9 | alwaysApply: false
10 | ---
11 |
12 | # REFLECT MODE: TASK REVIEW PROCESS MAP
13 |
14 | > **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.
15 |
16 | ## 🧭 REFLECT MODE PROCESS FLOW
17 |
18 | ```mermaid
19 | graph TD
20 | Start["START REFLECT MODE"] --> ReadTasks["Read tasks.md
and progress.md"]
21 |
22 | %% Initial Assessment
23 | ReadTasks --> VerifyImplement{"Implementation
Complete?"}
24 | VerifyImplement -->|"No"| ReturnImplement["Return to
IMPLEMENT Mode"]
25 | VerifyImplement -->|"Yes"| AssessLevel{"Determine
Complexity Level"}
26 |
27 | %% Level-Based Reflection
28 | AssessLevel -->|"Level 1"| L1Reflect["LEVEL 1 REFLECTION
Level1/reflection-basic.md"]
29 | AssessLevel -->|"Level 2"| L2Reflect["LEVEL 2 REFLECTION
Level2/reflection-standard.md"]
30 | AssessLevel -->|"Level 3"| L3Reflect["LEVEL 3 REFLECTION
Level3/reflection-comprehensive.md"]
31 | AssessLevel -->|"Level 4"| L4Reflect["LEVEL 4 REFLECTION
Level4/reflection-advanced.md"]
32 |
33 | %% Level 1 Reflection (Quick)
34 | L1Reflect --> L1Review["Review
Bug Fix"]
35 | L1Review --> L1Document["Document
Solution"]
36 | L1Document --> L1Update["Update
tasks.md"]
37 |
38 | %% Level 2 Reflection (Standard)
39 | L2Reflect --> L2Review["Review
Enhancement"]
40 | L2Review --> L2WWW["Document
What Went Well"]
41 | L2WWW --> L2Challenges["Document
Challenges"]
42 | L2Challenges --> L2Lessons["Document
Lessons Learned"]
43 | L2Lessons --> L2Update["Update
tasks.md"]
44 |
45 | %% Level 3-4 Reflection (Comprehensive)
46 | L3Reflect & L4Reflect --> L34Review["Review Implementation
& Creative Phases"]
47 | L34Review --> L34Plan["Compare Against
Original Plan"]
48 | L34Plan --> L34WWW["Document
What Went Well"]
49 | L34WWW --> L34Challenges["Document
Challenges"]
50 | L34Challenges --> L34Lessons["Document
Lessons Learned"]
51 | L34Lessons --> L34ImproveProcess["Document Process
Improvements"]
52 | L34ImproveProcess --> L34Update["Update
tasks.md"]
53 |
54 | %% Completion & Transition
55 | L1Update & L2Update & L34Update --> CreateReflection["Create
reflection.md"]
56 | CreateReflection --> UpdateSystem["Update System
Documentation"]
57 | UpdateSystem --> Transition["NEXT MODE:
ARCHIVE MODE"]
58 | ```
59 |
60 | ## 📋 REFLECTION STRUCTURE
61 |
62 | The reflection should follow this structured format:
63 |
64 | ```mermaid
65 | graph TD
66 | subgraph "Reflection Document Structure"
67 | Header["# TASK REFLECTION: [Task Name]"]
68 | Summary["## SUMMARY
Brief summary of completed task"]
69 | WWW["## WHAT WENT WELL
Successful aspects of implementation"]
70 | Challenges["## CHALLENGES
Difficulties encountered during implementation"]
71 | Lessons["## LESSONS LEARNED
Key insights gained from the experience"]
72 | ProcessImp["## PROCESS IMPROVEMENTS
How to improve for future tasks"]
73 | TechImp["## TECHNICAL IMPROVEMENTS
Better approaches for similar tasks"]
74 | NextSteps["## NEXT STEPS
Follow-up actions or future work"]
75 | end
76 |
77 | Header --> Summary --> WWW --> Challenges --> Lessons --> ProcessImp --> TechImp --> NextSteps
78 | ```
79 |
80 | ## 📊 REQUIRED FILE STATE VERIFICATION
81 |
82 | Before reflection can begin, verify file state:
83 |
84 | ```mermaid
85 | graph TD
86 | Start["File State
Verification"] --> CheckTasks{"tasks.md has
implementation
complete?"}
87 |
88 | CheckTasks -->|"No"| ErrorImplement["ERROR:
Return to IMPLEMENT Mode"]
89 | CheckTasks -->|"Yes"| CheckProgress{"progress.md
has implementation
details?"}
90 |
91 | CheckProgress -->|"No"| ErrorProgress["ERROR:
Update progress.md first"]
92 | CheckProgress -->|"Yes"| ReadyReflect["Ready for
Reflection"]
93 | ```
94 |
95 | ## 🔍 IMPLEMENTATION REVIEW APPROACH
96 |
97 | ```mermaid
98 | graph TD
99 | subgraph "Implementation Review"
100 | Original["Review Original
Requirements"]
101 | Plan["Compare Against
Implementation Plan"]
102 | Actual["Assess Actual
Implementation"]
103 | Creative["Review Creative
Phase Decisions"]
104 | Changes["Identify Deviations
from Plan"]
105 | Results["Evaluate
Results"]
106 | end
107 |
108 | Original --> Plan --> Actual
109 | Plan --> Creative --> Changes
110 | Actual --> Results
111 | Changes --> Results
112 | ```
113 |
114 | ## 📝 REFLECTION DOCUMENT TEMPLATES
115 |
116 | ### Level 1 (Basic) Reflection
117 | ```
118 | # Bug Fix Reflection: [Bug Name]
119 |
120 | ## Summary
121 | [Brief description of the bug and solution]
122 |
123 | ## Implementation
124 | [Description of the fix implemented]
125 |
126 | ## Testing
127 | [Description of testing performed]
128 |
129 | ## Additional Notes
130 | [Any other relevant information]
131 | ```
132 |
133 | ### Levels 2-4 (Comprehensive) Reflection
134 | ```
135 | # Task Reflection: [Task Name]
136 |
137 | ## Summary
138 | [Brief summary of the task and what was achieved]
139 |
140 | ## What Went Well
141 | - [Success point 1]
142 | - [Success point 2]
143 | - [Success point 3]
144 |
145 | ## Challenges
146 | - [Challenge 1]: [How it was addressed]
147 | - [Challenge 2]: [How it was addressed]
148 | - [Challenge 3]: [How it was addressed]
149 |
150 | ## Lessons Learned
151 | - [Lesson 1]
152 | - [Lesson 2]
153 | - [Lesson 3]
154 |
155 | ## Process Improvements
156 | - [Process improvement 1]
157 | - [Process improvement 2]
158 |
159 | ## Technical Improvements
160 | - [Technical improvement 1]
161 | - [Technical improvement 2]
162 |
163 | ## Next Steps
164 | - [Follow-up task 1]
165 | - [Follow-up task 2]
166 | ```
167 |
168 | ## 📊 REFLECTION QUALITY METRICS
169 |
170 | ```mermaid
171 | graph TD
172 | subgraph "Reflection Quality Metrics"
173 | Specific["Specific
Not general or vague"]
174 | Actionable["Actionable
Provides clear direction"]
175 | Honest["Honest
Acknowledges successes and failures"]
176 | Forward["Forward-Looking
Focuses on future improvement"]
177 | Evidence["Evidence-Based
Based on concrete examples"]
178 | end
179 | ```
180 |
181 | ## 📋 TASKS.MD UPDATE FORMAT
182 |
183 | During reflection, update tasks.md with:
184 |
185 | ```
186 | ## Status
187 | - [x] Initialization complete
188 | - [x] Planning complete
189 | [For Level 3-4:]
190 | - [x] Creative phases complete
191 | - [x] Implementation complete
192 | - [x] Reflection complete
193 | - [ ] Archiving
194 |
195 | ## Reflection Highlights
196 | - **What Went Well**: [Key successes]
197 | - **Challenges**: [Key challenges]
198 | - **Lessons Learned**: [Key lessons]
199 | - **Next Steps**: [Follow-up actions]
200 | ```
201 |
202 | ## 📊 REFLECTION VERIFICATION CHECKLIST
203 |
204 | ```
205 | ✓ REFLECTION VERIFICATION
206 | - Implementation thoroughly reviewed? [YES/NO]
207 | - What Went Well section completed? [YES/NO]
208 | - Challenges section completed? [YES/NO]
209 | - Lessons Learned section completed? [YES/NO]
210 | - Process Improvements identified? [YES/NO]
211 | - Technical Improvements identified? [YES/NO]
212 | - Next Steps documented? [YES/NO]
213 | - reflection.md created? [YES/NO]
214 | - tasks.md updated with reflection status? [YES/NO]
215 |
216 | → If all YES: Reflection complete - ready for ARCHIVE mode
217 | → If any NO: Complete missing reflection elements
218 | ```
219 |
220 | ## 🔄 MODE TRANSITION NOTIFICATION
221 |
222 | When reflection is complete, notify user with:
223 |
224 | ```
225 | ## REFLECTION COMPLETE
226 |
227 | ✅ Implementation thoroughly reviewed
228 | ✅ Reflection document created
229 | ✅ Lessons learned documented
230 | ✅ Process improvements identified
231 | ✅ tasks.md updated with reflection status
232 |
233 | → NEXT RECOMMENDED MODE: ARCHIVE MODE
234 | ```
--------------------------------------------------------------------------------
/.cursor/rules/isolation_rules/visual-maps/van_mode_split/van-complexity-determination.mdc:
--------------------------------------------------------------------------------
1 | ---
2 | description: Visual process map for VAN mode complexity determination
3 | globs: van-complexity-determination.mdc
4 | alwaysApply: false
5 | ---
6 | # VAN MODE: EARLY COMPLEXITY DETERMINATION
7 |
8 | > **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.
9 |
10 | ## 🧩 COMPLEXITY DETERMINATION PROCESS
11 |
12 | ```mermaid
13 | graph TD
14 | CD["Complexity
Determination"] --> AnalyzeTask["Analyze Task
Requirements"]
15 |
16 | AnalyzeTask --> CheckKeywords["Check Task
Keywords"]
17 | CheckKeywords --> ScopeCheck["Assess
Scope Impact"]
18 | ScopeCheck --> RiskCheck["Evaluate
Risk Level"]
19 | RiskCheck --> EffortCheck["Estimate
Implementation Effort"]
20 |
21 | EffortCheck --> DetermineLevel{"Determine
Complexity Level"}
22 | DetermineLevel -->|"Level 1"| L1["Level 1:
Quick Bug Fix"]
23 | DetermineLevel -->|"Level 2"| L2["Level 2:
Simple Enhancement"]
24 | DetermineLevel -->|"Level 3"| L3["Level 3:
Intermediate Feature"]
25 | DetermineLevel -->|"Level 4"| L4["Level 4:
Complex System"]
26 |
27 | L1 --> CDComplete["Complexity Determination
Complete (Level 1)"]
28 | L2 & L3 & L4 --> ModeSwitch["Force Mode Switch
to PLAN"]
29 |
30 | style CD fill:#4da6ff,stroke:#0066cc,color:white
31 | style CDComplete fill:#10b981,stroke:#059669,color:white
32 | style ModeSwitch fill:#ff0000,stroke:#990000,color:white
33 | style DetermineLevel fill:#f6546a,stroke:#c30052,color:white
34 | ```
35 |
36 | ## 🚨 MODE TRANSITION TRIGGER (VAN to PLAN)
37 |
38 | If complexity is determined to be Level 2, 3, or 4:
39 |
40 | ```
41 | 🚫 LEVEL [2-4] TASK DETECTED
42 | Implementation in VAN mode is BLOCKED
43 | This task REQUIRES PLAN mode
44 | You MUST switch to PLAN mode for proper documentation and planning
45 | Type 'PLAN' to switch to planning mode
46 | ```
47 |
48 | ## 📋 CHECKPOINT VERIFICATION TEMPLATE (Example)
49 |
50 | ```
51 | ✓ SECTION CHECKPOINT: COMPLEXITY DETERMINATION
52 | - Task Analyzed? [YES/NO]
53 | - Complexity Level Determined? [YES/NO]
54 |
55 | → If Level 1: Proceed to VAN Mode Completion.
56 | → If Level 2-4: Trigger PLAN Mode transition.
57 | ```
58 |
59 | **Next Step (Level 1):** Complete VAN Initialization (e.g., initialize Memory Bank if needed).
60 | **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:
--------------------------------------------------------------------------------
1 | ---
2 | description: Visual process map for VAN mode file verification
3 | globs: van-file-verification.mdc
4 | alwaysApply: false
5 | ---
6 | # VAN MODE: FILE VERIFICATION
7 |
8 | > **TL;DR:** Checks for the existence and basic structure of essential Memory Bank and documentation components.
9 |
10 | ## 📁 FILE VERIFICATION PROCESS
11 |
12 | ```mermaid
13 | graph TD
14 | FV["File Verification"] --> CheckFiles["Check Essential Files"]
15 | CheckFiles --> CheckMB["Check Memory Bank
Structure"]
16 | CheckMB --> MBExists{"Memory Bank
Exists?"}
17 |
18 | MBExists -->|"Yes"| VerifyMB["Verify Memory Bank
Contents (Basic)"]
19 | MBExists -->|"No"| CreateMB["Create Memory Bank
Structure (Basic)"]
20 |
21 | CheckFiles --> CheckDocs["Check Documentation
Files (e.g., tasks.md)"]
22 | CheckDocs --> DocsExist{"Docs
Exist?"}
23 |
24 | DocsExist -->|"Yes"| VerifyDocs["Verify Documentation
Presence"]
25 | DocsExist -->|"No"| CreateDocs["Create Essential
Documentation Files"]
26 |
27 | VerifyMB & CreateMB --> MBCP["Memory Bank
Checkpoint"]
28 | VerifyDocs & CreateDocs --> DocsCP["Documentation
Checkpoint"]
29 |
30 | MBCP & DocsCP --> FileComplete["File Verification
Complete"]
31 |
32 | style FV fill:#4da6ff,stroke:#0066cc,color:white
33 | style FileComplete fill:#10b981,stroke:#059669,color:white
34 | style MBCP fill:#f6546a,stroke:#c30052,color:white
35 | style DocsCP fill:#f6546a,stroke:#c30052,color:white
36 | ```
37 |
38 | ## 📋 CHECKPOINT VERIFICATION TEMPLATE (Example)
39 |
40 | ```
41 | ✓ SECTION CHECKPOINT: FILE VERIFICATION
42 | - Memory Bank Directory Exists/Created? [YES/NO]
43 | - Essential Docs (tasks.md) Exist/Created? [YES/NO]
44 |
45 | → If all YES: File Verification Complete.
46 | → If any NO: Resolve before proceeding.
47 | ```
48 |
49 | **Next Step:** Load and process `van-complexity-determination.mdc`.
--------------------------------------------------------------------------------
/.cursor/rules/isolation_rules/visual-maps/van_mode_split/van-mode-map.mdc:
--------------------------------------------------------------------------------
1 | ---
2 | description: Visual process map for VAN mode (Index/Entry Point)
3 | globs: van-mode-map.mdc
4 | alwaysApply: false
5 | ---
6 | # VAN MODE: INITIALIZATION PROCESS MAP (INDEX)
7 |
8 | > **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.
9 |
10 | ## 🚀 VAN MODE ACTIVATION
11 |
12 | When the user types "VAN", respond with a confirmation and start the process:
13 |
14 | ```
15 | User: VAN
16 |
17 | Response: OK VAN - Beginning Initialization Process
18 | Loading Platform Detection map...
19 | ```
20 |
21 | ## 🧭 VAN MODE PROCESS FLOW (High Level)
22 |
23 | This graph shows the main stages. Each stage is detailed in a separate file loaded sequentially.
24 |
25 | ```mermaid
26 | graph TD
27 | Start["START VAN MODE"] --> PlatformDetect["1. PLATFORM DETECTION
28 | (van-platform-detection.mdc)"]
29 | PlatformDetect --> FileVerify["2. FILE VERIFICATION
30 | (van-file-verification.mdc)"]
31 | FileVerify --> Complexity["3. EARLY COMPLEXITY
32 | DETERMINATION
33 | (van-complexity-determination.mdc)"]
34 | Complexity --> Decision{"Level?"}
35 | Decision -- "Level 1" --> L1Complete["Level 1 Init Complete"]
36 | Decision -- "Level 2-4" --> ExitToPlan["Exit to PLAN Mode"]
37 |
38 | %% Link to QA (Loaded separately)
39 | QA_Entry["VAN QA MODE
40 | (Loaded Separately via
41 | 'VAN QA' command)"] -.-> QA_Map["(van-qa-validation.mdc)"]
42 |
43 | style PlatformDetect fill:#ccf,stroke:#333
44 | style FileVerify fill:#ccf,stroke:#333
45 | style Complexity fill:#ccf,stroke:#333
46 | style QA_Map fill:#fcc,stroke:#333
47 | ```
48 |
49 | **Next Step:** Load and process `van-platform-detection.mdc`.
--------------------------------------------------------------------------------
/.cursor/rules/isolation_rules/visual-maps/van_mode_split/van-platform-detection.mdc:
--------------------------------------------------------------------------------
1 | ---
2 | description: Visual process map for VAN mode platform detection
3 | globs: van-platform-detection.mdc
4 | alwaysApply: false
5 | ---
6 | # VAN MODE: PLATFORM DETECTION
7 |
8 | > **TL;DR:** Detects the OS, determines path separators, and notes command adaptations required.
9 |
10 | ## 🌐 PLATFORM DETECTION PROCESS
11 |
12 | ```mermaid
13 | graph TD
14 | PD["Platform Detection"] --> CheckOS["Detect Operating System"]
15 | CheckOS --> Win["Windows"]
16 | CheckOS --> Mac["macOS"]
17 | CheckOS --> Lin["Linux"]
18 |
19 | Win & Mac & Lin --> Adapt["Adapt Commands
for Platform"]
20 |
21 | Win --> WinPath["Path: Backslash (\\)"]
22 | Mac --> MacPath["Path: Forward Slash (/)"]
23 | Lin --> LinPath["Path: Forward Slash (/)"]
24 |
25 | Win --> WinCmd["Command Adaptations:
dir, icacls, etc."]
26 | Mac --> MacCmd["Command Adaptations:
ls, chmod, etc."]
27 | Lin --> LinCmd["Command Adaptations:
ls, chmod, etc."]
28 |
29 | WinPath & MacPath & LinPath --> PathCP["Path Separator
Checkpoint"]
30 | WinCmd & MacCmd & LinCmd --> CmdCP["Command
Checkpoint"]
31 |
32 | PathCP & CmdCP --> PlatformComplete["Platform Detection
Complete"]
33 |
34 | style PD fill:#4da6ff,stroke:#0066cc,color:white
35 | style PlatformComplete fill:#10b981,stroke:#059669,color:white
36 | ```
37 |
38 | ## 📋 CHECKPOINT VERIFICATION TEMPLATE (Example)
39 |
40 | ```
41 | ✓ SECTION CHECKPOINT: PLATFORM DETECTION
42 | - Operating System Detected? [YES/NO]
43 | - Path Separator Confirmed? [YES/NO]
44 | - Command Adaptations Noted? [YES/NO]
45 |
46 | → If all YES: Platform Detection Complete.
47 | → If any NO: Resolve before proceeding.
48 | ```
49 |
50 | **Next Step:** Load and process `van-file-verification.mdc`.
--------------------------------------------------------------------------------
/.cursor/rules/isolation_rules/visual-maps/van_mode_split/van-qa-checks/build-test.mdc:
--------------------------------------------------------------------------------
1 | ---
2 | description: Process map for VAN QA minimal build test
3 | globs: van-qa-checks/build-test.mdc
4 | alwaysApply: false
5 | ---
6 | # VAN QA: MINIMAL BUILD TEST
7 |
8 | > **TL;DR:** This component performs a minimal build test to ensure core build functionality works properly.
9 |
10 | ## 4️⃣ MINIMAL BUILD TEST PROCESS
11 |
12 | ```mermaid
13 | graph TD
14 | Start["Minimal Build Test"] --> CreateTest["Create Minimal
Test Project"]
15 | CreateTest --> BuildTest["Attempt
Build"]
16 | BuildTest --> BuildStatus{"Build
Successful?"}
17 |
18 | BuildStatus -->|"Yes"| RunTest["Run Basic
Functionality Test"]
19 | BuildStatus -->|"No"| FixBuild["Fix Build
Issues"]
20 | FixBuild --> RetryBuild["Retry Build"]
21 | RetryBuild --> BuildStatus
22 |
23 | RunTest --> TestStatus{"Test
Passed?"}
24 | TestStatus -->|"Yes"| TestSuccess["Minimal Build Test
✅ PASS"]
25 | TestStatus -->|"No"| FixTest["Fix Test
Issues"]
26 | FixTest --> RetryTest["Retry Test"]
27 | RetryTest --> TestStatus
28 |
29 | style Start fill:#4da6ff,stroke:#0066cc,color:white
30 | style TestSuccess fill:#10b981,stroke:#059669,color:white
31 | style BuildStatus fill:#f6546a,stroke:#c30052,color:white
32 | style TestStatus fill:#f6546a,stroke:#c30052,color:white
33 | ```
34 |
35 | ### Minimal Build Test Implementation:
36 | ```powershell
37 | # Example: Perform minimal build test for a React project
38 | function Perform-MinimalBuildTest {
39 | $buildSuccess = $false
40 | $testSuccess = $false
41 |
42 | # Create minimal test project
43 | $testDir = ".__build_test"
44 | if (Test-Path $testDir) {
45 | Remove-Item -Path $testDir -Recurse -Force
46 | }
47 |
48 | try {
49 | # Create minimal test directory
50 | New-Item -Path $testDir -ItemType Directory | Out-Null
51 | Push-Location $testDir
52 |
53 | # Initialize minimal package.json
54 | @"
55 | {
56 | "name": "build-test",
57 | "version": "1.0.0",
58 | "description": "Minimal build test",
59 | "main": "index.js",
60 | "scripts": {
61 | "build": "echo Build test successful"
62 | }
63 | }
64 | "@ | Set-Content -Path "package.json"
65 |
66 | # Attempt build
67 | npm run build | Out-Null
68 | $buildSuccess = $true
69 |
70 | # Create minimal test file
71 | @"
72 | console.log('Test successful');
73 | "@ | Set-Content -Path "index.js"
74 |
75 | # Run basic test
76 | node index.js | Out-Null
77 | $testSuccess = $true
78 |
79 | } catch {
80 | Write-Output "❌ Build test failed: $($_.Exception.Message)"
81 | } finally {
82 | Pop-Location
83 | if (Test-Path $testDir) {
84 | Remove-Item -Path $testDir -Recurse -Force
85 | }
86 | }
87 |
88 | # Display results
89 | if ($buildSuccess -and $testSuccess) {
90 | Write-Output "✅ Minimal build test passed successfully"
91 | return $true
92 | } else {
93 | if (-not $buildSuccess) {
94 | Write-Output "❌ Build process failed"
95 | }
96 | if (-not $testSuccess) {
97 | Write-Output "❌ Basic functionality test failed"
98 | }
99 | return $false
100 | }
101 | }
102 | ```
103 |
104 | ## 📋 MINIMAL BUILD TEST CHECKPOINT
105 |
106 | ```
107 | ✓ CHECKPOINT: MINIMAL BUILD TEST
108 | - Test project creation successful? [YES/NO]
109 | - Build process completed successfully? [YES/NO]
110 | - Basic functionality test passed? [YES/NO]
111 |
112 | → If all YES: QA Validation complete, proceed to generate success report.
113 | → If any NO: Fix build issues before continuing.
114 | ```
115 |
116 | **Next Step (on PASS):** Load `van-qa-utils/reports.mdc` to generate success report.
117 | **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:
--------------------------------------------------------------------------------
1 | ---
2 | description: Process map for VAN QA configuration validation
3 | globs: van-qa-checks/config-check.mdc
4 | alwaysApply: false
5 | ---
6 | # VAN QA: CONFIGURATION VALIDATION
7 |
8 | > **TL;DR:** This component validates configuration files for proper syntax and compatibility with the project and platform.
9 |
10 | ## 2️⃣ CONFIGURATION VALIDATION PROCESS
11 |
12 | ```mermaid
13 | graph TD
14 | Start["Configuration Validation"] --> IdentifyConfigs["Identify Configuration
Files"]
15 | IdentifyConfigs --> ReadConfigs["Read Configuration
Files"]
16 | ReadConfigs --> ValidateSyntax["Validate Syntax
and Format"]
17 | ValidateSyntax --> SyntaxStatus{"Syntax
Valid?"}
18 |
19 | SyntaxStatus -->|"Yes"| CheckCompatibility["Check Compatibility
with Platform"]
20 | SyntaxStatus -->|"No"| FixSyntax["Fix Syntax
Errors"]
21 | FixSyntax --> RetryValidate["Retry Validation"]
22 | RetryValidate --> SyntaxStatus
23 |
24 | CheckCompatibility --> CompatStatus{"Compatible with
Platform?"}
25 | CompatStatus -->|"Yes"| ConfigSuccess["Configurations Validated
✅ PASS"]
26 | CompatStatus -->|"No"| AdaptConfigs["Adapt Configurations
for Platform"]
27 | AdaptConfigs --> RetryCompat["Retry Compatibility
Check"]
28 | RetryCompat --> CompatStatus
29 |
30 | style Start fill:#4da6ff,stroke:#0066cc,color:white
31 | style ConfigSuccess fill:#10b981,stroke:#059669,color:white
32 | style SyntaxStatus fill:#f6546a,stroke:#c30052,color:white
33 | style CompatStatus fill:#f6546a,stroke:#c30052,color:white
34 | ```
35 |
36 | ### Configuration Validation Implementation:
37 | ```powershell
38 | # Example: Validate configuration files for a web project
39 | function Validate-Configurations {
40 | $configFiles = @(
41 | "package.json",
42 | "tsconfig.json",
43 | "vite.config.js"
44 | )
45 |
46 | $invalidConfigs = @()
47 | $incompatibleConfigs = @()
48 |
49 | foreach ($configFile in $configFiles) {
50 | if (Test-Path $configFile) {
51 | # Check JSON syntax for JSON files
52 | if ($configFile -match "\.json$") {
53 | try {
54 | Get-Content $configFile -Raw | ConvertFrom-Json | Out-Null
55 | } catch {
56 | $invalidConfigs += "$configFile (JSON syntax error: $($_.Exception.Message))"
57 | continue
58 | }
59 | }
60 |
61 | # Specific configuration compatibility checks
62 | if ($configFile -eq "vite.config.js") {
63 | $content = Get-Content $configFile -Raw
64 | # Check for React plugin in Vite config
65 | if ($content -notmatch "react\(\)") {
66 | $incompatibleConfigs += "$configFile (Missing React plugin for React project)"
67 | }
68 | }
69 | } else {
70 | $invalidConfigs += "$configFile (file not found)"
71 | }
72 | }
73 |
74 | # Display results
75 | if ($invalidConfigs.Count -eq 0 -and $incompatibleConfigs.Count -eq 0) {
76 | Write-Output "✅ All configurations validated and compatible"
77 | return $true
78 | } else {
79 | if ($invalidConfigs.Count -gt 0) {
80 | Write-Output "❌ Invalid configurations: $($invalidConfigs -join ', ')"
81 | }
82 | if ($incompatibleConfigs.Count -gt 0) {
83 | Write-Output "❌ Incompatible configurations: $($incompatibleConfigs -join ', ')"
84 | }
85 | return $false
86 | }
87 | }
88 | ```
89 |
90 | ## 📋 CONFIGURATION VALIDATION CHECKPOINT
91 |
92 | ```
93 | ✓ CHECKPOINT: CONFIGURATION VALIDATION
94 | - All configuration files found? [YES/NO]
95 | - All configuration syntax valid? [YES/NO]
96 | - All configurations compatible with platform? [YES/NO]
97 |
98 | → If all YES: Continue to Environment Validation.
99 | → If any NO: Fix configuration issues before continuing.
100 | ```
101 |
102 | **Next Step (on PASS):** Load `van-qa-checks/environment-check.mdc`.
103 | **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:
--------------------------------------------------------------------------------
1 | ---
2 | description: Process map for VAN QA dependency verification
3 | globs: van-qa-checks/dependency-check.mdc
4 | alwaysApply: false
5 | ---
6 | # VAN QA: DEPENDENCY VERIFICATION
7 |
8 | > **TL;DR:** This component verifies that all required dependencies are installed and compatible with the project requirements.
9 |
10 | ## 1️⃣ DEPENDENCY VERIFICATION PROCESS
11 |
12 | ```mermaid
13 | graph TD
14 | Start["Dependency Verification"] --> ReadDeps["Read Required Dependencies
from Creative Phase"]
15 | ReadDeps --> CheckInstalled["Check if Dependencies
are Installed"]
16 | CheckInstalled --> DepStatus{"All Dependencies
Installed?"}
17 |
18 | DepStatus -->|"Yes"| VerifyVersions["Verify Versions
and Compatibility"]
19 | DepStatus -->|"No"| InstallMissing["Install Missing
Dependencies"]
20 | InstallMissing --> VerifyVersions
21 |
22 | VerifyVersions --> VersionStatus{"Versions
Compatible?"}
23 | VersionStatus -->|"Yes"| DepSuccess["Dependencies Verified
✅ PASS"]
24 | VersionStatus -->|"No"| UpgradeVersions["Upgrade/Downgrade
as Needed"]
25 | UpgradeVersions --> RetryVerify["Retry Verification"]
26 | RetryVerify --> VersionStatus
27 |
28 | style Start fill:#4da6ff,stroke:#0066cc,color:white
29 | style DepSuccess fill:#10b981,stroke:#059669,color:white
30 | style DepStatus fill:#f6546a,stroke:#c30052,color:white
31 | style VersionStatus fill:#f6546a,stroke:#c30052,color:white
32 | ```
33 |
34 | ### Windows (PowerShell) Implementation:
35 | ```powershell
36 | # Example: Verify Node.js dependencies for a React project
37 | function Verify-Dependencies {
38 | $requiredDeps = @{ "node" = ">=14.0.0"; "npm" = ">=6.0.0" }
39 | $missingDeps = @(); $incompatibleDeps = @()
40 |
41 | # Check Node.js version
42 | try {
43 | $nodeVersion = node -v
44 | if ($nodeVersion -match "v(\d+)\.(\d+)\.(\d+)") {
45 | $major = [int]$Matches[1]
46 | if ($major -lt 14) {
47 | $incompatibleDeps += "node (found $nodeVersion, required >=14.0.0)"
48 | }
49 | }
50 | } catch {
51 | $missingDeps += "node"
52 | }
53 |
54 | # Check npm version
55 | try {
56 | $npmVersion = npm -v
57 | if ($npmVersion -match "(\d+)\.(\d+)\.(\d+)") {
58 | $major = [int]$Matches[1]
59 | if ($major -lt 6) {
60 | $incompatibleDeps += "npm (found $npmVersion, required >=6.0.0)"
61 | }
62 | }
63 | } catch {
64 | $missingDeps += "npm"
65 | }
66 |
67 | # Display results
68 | if ($missingDeps.Count -eq 0 -and $incompatibleDeps.Count -eq 0) {
69 | Write-Output "✅ All dependencies verified and compatible"
70 | return $true
71 | } else {
72 | if ($missingDeps.Count -gt 0) {
73 | Write-Output "❌ Missing dependencies: $($missingDeps -join ', ')"
74 | }
75 | if ($incompatibleDeps.Count -gt 0) {
76 | Write-Output "❌ Incompatible versions: $($incompatibleDeps -join ', ')"
77 | }
78 | return $false
79 | }
80 | }
81 | ```
82 |
83 | ### Mac/Linux (Bash) Implementation:
84 | ```bash
85 | #!/bin/bash
86 |
87 | # Example: Verify Node.js dependencies for a React project
88 | verify_dependencies() {
89 | local missing_deps=()
90 | local incompatible_deps=()
91 |
92 | # Check Node.js version
93 | if command -v node &> /dev/null; then
94 | local node_version=$(node -v)
95 | if [[ $node_version =~ v([0-9]+)\.([0-9]+)\.([0-9]+) ]]; then
96 | local major=${BASH_REMATCH[1]}
97 | if (( major < 14 )); then
98 | incompatible_deps+=("node (found $node_version, required >=14.0.0)")
99 | fi
100 | fi
101 | else
102 | missing_deps+=("node")
103 | fi
104 |
105 | # Check npm version
106 | if command -v npm &> /dev/null; then
107 | local npm_version=$(npm -v)
108 | if [[ $npm_version =~ ([0-9]+)\.([0-9]+)\.([0-9]+) ]]; then
109 | local major=${BASH_REMATCH[1]}
110 | if (( major < 6 )); then
111 | incompatible_deps+=("npm (found $npm_version, required >=6.0.0)")
112 | fi
113 | fi
114 | else
115 | missing_deps+=("npm")
116 | fi
117 |
118 | # Display results
119 | if [ ${#missing_deps[@]} -eq 0 ] && [ ${#incompatible_deps[@]} -eq 0 ]; then
120 | echo "✅ All dependencies verified and compatible"
121 | return 0
122 | else
123 | if [ ${#missing_deps[@]} -gt 0 ]; then
124 | echo "❌ Missing dependencies: ${missing_deps[*]}"
125 | fi
126 | if [ ${#incompatible_deps[@]} -gt 0 ]; then
127 | echo "❌ Incompatible versions: ${incompatible_deps[*]}"
128 | fi
129 | return 1
130 | fi
131 | }
132 | ```
133 |
134 | ## 📋 DEPENDENCY VERIFICATION CHECKPOINT
135 |
136 | ```
137 | ✓ CHECKPOINT: DEPENDENCY VERIFICATION
138 | - Required dependencies identified? [YES/NO]
139 | - All dependencies installed? [YES/NO]
140 | - All versions compatible? [YES/NO]
141 |
142 | → If all YES: Continue to Configuration Validation.
143 | → If any NO: Fix dependency issues before continuing.
144 | ```
145 |
146 | **Next Step (on PASS):** Load `van-qa-checks/config-check.mdc`.
147 | **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:
--------------------------------------------------------------------------------
1 | ---
2 | description: Process map for VAN QA environment validation
3 | globs: van-qa-checks/environment-check.mdc
4 | alwaysApply: false
5 | ---
6 | # VAN QA: ENVIRONMENT VALIDATION
7 |
8 | > **TL;DR:** This component verifies that the build environment is properly set up with required tools and permissions.
9 |
10 | ## 3️⃣ ENVIRONMENT VALIDATION PROCESS
11 |
12 | ```mermaid
13 | graph TD
14 | Start["Environment Validation"] --> CheckEnv["Check Build Environment"]
15 | CheckEnv --> VerifyBuildTools["Verify Build Tools"]
16 | VerifyBuildTools --> ToolsStatus{"Build Tools
Available?"}
17 |
18 | ToolsStatus -->|"Yes"| CheckPerms["Check Permissions
and Access"]
19 | ToolsStatus -->|"No"| InstallTools["Install Required
Build Tools"]
20 | InstallTools --> RetryTools["Retry Verification"]
21 | RetryTools --> ToolsStatus
22 |
23 | CheckPerms --> PermsStatus{"Permissions
Sufficient?"}
24 | PermsStatus -->|"Yes"| EnvSuccess["Environment Validated
✅ PASS"]
25 | PermsStatus -->|"No"| FixPerms["Fix Permission
Issues"]
26 | FixPerms --> RetryPerms["Retry Permission
Check"]
27 | RetryPerms --> PermsStatus
28 |
29 | style Start fill:#4da6ff,stroke:#0066cc,color:white
30 | style EnvSuccess fill:#10b981,stroke:#059669,color:white
31 | style ToolsStatus fill:#f6546a,stroke:#c30052,color:white
32 | style PermsStatus fill:#f6546a,stroke:#c30052,color:white
33 | ```
34 |
35 | ### Environment Validation Implementation:
36 | ```powershell
37 | # Example: Validate environment for a web project
38 | function Validate-Environment {
39 | $requiredTools = @(
40 | @{Name = "git"; Command = "git --version"},
41 | @{Name = "node"; Command = "node --version"},
42 | @{Name = "npm"; Command = "npm --version"}
43 | )
44 |
45 | $missingTools = @()
46 | $permissionIssues = @()
47 |
48 | # Check build tools
49 | foreach ($tool in $requiredTools) {
50 | try {
51 | Invoke-Expression $tool.Command | Out-Null
52 | } catch {
53 | $missingTools += $tool.Name
54 | }
55 | }
56 |
57 | # Check write permissions in project directory
58 | try {
59 | $testFile = ".__permission_test"
60 | New-Item -Path $testFile -ItemType File -Force | Out-Null
61 | Remove-Item -Path $testFile -Force
62 | } catch {
63 | $permissionIssues += "Current directory (write permission denied)"
64 | }
65 |
66 | # Check if port 3000 is available (commonly used for dev servers)
67 | try {
68 | $listener = New-Object System.Net.Sockets.TcpListener([System.Net.IPAddress]::Loopback, 3000)
69 | $listener.Start()
70 | $listener.Stop()
71 | } catch {
72 | $permissionIssues += "Port 3000 (already in use or access denied)"
73 | }
74 |
75 | # Display results
76 | if ($missingTools.Count -eq 0 -and $permissionIssues.Count -eq 0) {
77 | Write-Output "✅ Environment validated successfully"
78 | return $true
79 | } else {
80 | if ($missingTools.Count -gt 0) {
81 | Write-Output "❌ Missing tools: $($missingTools -join ', ')"
82 | }
83 | if ($permissionIssues.Count -gt 0) {
84 | Write-Output "❌ Permission issues: $($permissionIssues -join ', ')"
85 | }
86 | return $false
87 | }
88 | }
89 | ```
90 |
91 | ## 📋 ENVIRONMENT VALIDATION CHECKPOINT
92 |
93 | ```
94 | ✓ CHECKPOINT: ENVIRONMENT VALIDATION
95 | - All required build tools installed? [YES/NO]
96 | - Project directory permissions sufficient? [YES/NO]
97 | - Required ports available? [YES/NO]
98 |
99 | → If all YES: Continue to Minimal Build Test.
100 | → If any NO: Fix environment issues before continuing.
101 | ```
102 |
103 | **Next Step (on PASS):** Load `van-qa-checks/build-test.mdc`.
104 | **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:
--------------------------------------------------------------------------------
1 |
--------------------------------------------------------------------------------
/.cursor/rules/isolation_rules/visual-maps/van_mode_split/van-qa-main.mdc:
--------------------------------------------------------------------------------
1 | ---
2 | description: Visual process map for VAN QA mode (Technical Validation Entry Point)
3 | globs: van-qa-main.mdc
4 | alwaysApply: false
5 | ---
6 | # VAN MODE: QA TECHNICAL VALIDATION (Main Entry)
7 |
8 | > **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.
9 |
10 | ## 📣 HOW TO USE THESE QA RULES
11 |
12 | To access any QA validation rule or component, use the `fetch_rules` tool with exact rule names:
13 |
14 | ```
15 | // CRITICAL: Always use fetch_rules to load validation components
16 | // For detailed examples and guidance, load:
17 | // isolation_rules/visual-maps/van-qa-utils/rule-calling-guide
18 | ```
19 |
20 | ## 🚀 VAN QA MODE ACTIVATION
21 |
22 | After completing CREATIVE mode, when the user types "VAN QA", respond:
23 |
24 | ```mermaid
25 | graph TD
26 | UserQA["User Types: QA"] --> HighPriority["⚠️ HIGH PRIORITY COMMAND"]
27 | HighPriority --> CurrentTask["Pause Current Task/Process"]
28 | CurrentTask --> LoadQA["Load QA Main Map (This File)"]
29 | LoadQA --> RunQA["Execute QA Validation Process"]
30 | RunQA --> QAResults{"QA Results"}
31 |
32 | QAResults -->|"PASS"| ResumeFlow["Resume Prior Process Flow"]
33 | QAResults -->|"FAIL"| FixIssues["Fix Identified Issues"]
34 | FixIssues --> ReRunQA["Re-run QA Validation"]
35 | ReRunQA --> QAResults
36 |
37 | style UserQA fill:#f8d486,stroke:#e8b84d,color:black
38 | style HighPriority fill:#ff0000,stroke:#cc0000,color:white,stroke-width:3px
39 | style LoadQA fill:#4da6ff,stroke:#0066cc,color:white
40 | style RunQA fill:#4da6ff,stroke:#0066cc,color:white
41 | style QAResults fill:#f6546a,stroke:#c30052,color:white
42 | ```
43 |
44 | ### QA Interruption Rules
45 |
46 | 1. **Immediate Precedence:** `QA` command interrupts everything.
47 | 2. **Load & Execute:** Load this map (`van-qa-main.mdc`) and its components (see below).
48 | 3. **Remediation Priority:** Fixes take priority over pending mode switches.
49 | 4. **Resume:** On PASS, resume the previous flow.
50 |
51 | ```
52 | ⚠️ QA OVERRIDE ACTIVATED
53 | All other processes paused
54 | QA validation checks now running...
55 | Any issues found MUST be remediated before continuing with normal process flow
56 | ```
57 |
58 | ## 🔍 TECHNICAL VALIDATION OVERVIEW
59 |
60 | Four-point validation process with selective loading:
61 |
62 | ```mermaid
63 | graph TD
64 | VANQA["VAN QA MODE"] --> FourChecks["FOUR-POINT VALIDATION"]
65 |
66 | FourChecks --> DepCheck["1️⃣ DEPENDENCY VERIFICATION
67 | Load: van-qa-checks/dependency-check.mdc"]
68 | DepCheck --> ConfigCheck["2️⃣ CONFIGURATION VALIDATION
69 | Load: van-qa-checks/config-check.mdc"]
70 | ConfigCheck --> EnvCheck["3️⃣ ENVIRONMENT VALIDATION
71 | Load: van-qa-checks/environment-check.mdc"]
72 | EnvCheck --> MinBuildCheck["4️⃣ MINIMAL BUILD TEST
73 | Load: van-qa-checks/build-test.mdc"]
74 |
75 | MinBuildCheck --> ValidationResults{"All Checks
Passed?"}
76 | ValidationResults -->|"Yes"| SuccessReport["GENERATE SUCCESS REPORT
77 | Load: van-qa-utils/reports.mdc"]
78 | ValidationResults -->|"No"| FailureReport["GENERATE FAILURE REPORT
79 | Load: van-qa-utils/reports.mdc"]
80 |
81 | SuccessReport --> BUILD_Transition["Trigger BUILD Mode
82 | Load: van-qa-utils/mode-transitions.mdc"]
83 | FailureReport --> FixIssues["Fix Technical Issues
84 | Load: van-qa-utils/common-fixes.mdc"]
85 | FixIssues --> ReValidate["Re-validate (Re-run VAN QA)"]
86 | ReValidate --> FourChecks
87 |
88 | style VANQA fill:#4da6ff,stroke:#0066cc,color:white
89 | style FourChecks fill:#f6546a,stroke:#c30052,color:white
90 | style ValidationResults fill:#f6546a,stroke:#c30052,color:white
91 | style BUILD_Transition fill:#10b981,stroke:#059669,color:white
92 | style FixIssues fill:#ff5555,stroke:#dd3333,color:white
93 | ```
94 |
95 | ## 🔄 INTEGRATION WITH DESIGN DECISIONS
96 |
97 | Reads Creative Phase outputs to inform validation:
98 |
99 | ```mermaid
100 | graph TD
101 | Start["Read Design Decisions"] --> ReadCreative["Parse Creative Phase
Documentation"]
102 | ReadCreative --> ExtractTech["Extract Technology
Choices"]
103 | ExtractTech --> ExtractDeps["Extract Required
Dependencies"]
104 | ExtractDeps --> BuildValidationPlan["Build Validation
Plan"]
105 | BuildValidationPlan --> StartValidation["Start Four-Point
Validation Process"]
106 |
107 | style Start fill:#4da6ff,stroke:#0066cc,color:white
108 | style ExtractTech fill:#f6546a,stroke:#c30052,color:white
109 | style BuildValidationPlan fill:#10b981,stroke:#059669,color:white
110 | style StartValidation fill:#f6546a,stroke:#c30052,color:white
111 | ```
112 |
113 | ## 📋 COMPONENT LOADING SEQUENCE
114 |
115 | The QA validation process follows this selective loading sequence:
116 |
117 | 1. **Main Entry (This File)**: `van-qa-main.mdc`
118 | 2. **Validation Checks**:
119 | - `van-qa-checks/dependency-check.mdc`
120 | - `van-qa-checks/config-check.mdc`
121 | - `van-qa-checks/environment-check.mdc`
122 | - `van-qa-checks/build-test.mdc`
123 | 3. **Utilities (As Needed)**:
124 | - `van-qa-utils/reports.mdc`
125 | - `van-qa-utils/common-fixes.mdc`
126 | - `van-qa-utils/mode-transitions.mdc`
127 |
128 | ## 📋 FINAL QA VALIDATION CHECKPOINT
129 |
130 | ```
131 | ✓ SECTION CHECKPOINT: QA VALIDATION
132 | - Dependency Verification Passed? [YES/NO]
133 | - Configuration Validation Passed? [YES/NO]
134 | - Environment Validation Passed? [YES/NO]
135 | - Minimal Build Test Passed? [YES/NO]
136 |
137 | → If all YES: Ready for BUILD mode transition.
138 | → If any NO: Fix identified issues and re-run VAN QA.
139 | ```
140 |
141 | **Next Step (on PASS):** Trigger BUILD mode (load `van-qa-utils/mode-transitions.mdc`).
142 | **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:
--------------------------------------------------------------------------------
1 | ---
2 | description: Utility for VAN QA common validation fixes
3 | globs: van-qa-utils/common-fixes.mdc
4 | alwaysApply: false
5 | ---
6 | # VAN QA: COMMON VALIDATION FIXES
7 |
8 | > **TL;DR:** This component provides common fixes for issues that may arise during the QA validation process.
9 |
10 | ## 🧪 COMMON QA VALIDATION FIXES BY CATEGORY
11 |
12 | ### Dependency Issues
13 |
14 | | Issue | Fix |
15 | |-------|-----|
16 | | **Missing Node.js** | Download and install Node.js from https://nodejs.org/ |
17 | | **Outdated npm** | Run `npm install -g npm@latest` to update |
18 | | **Missing packages** | Run `npm install` or `npm install [package-name]` |
19 | | **Package version conflicts** | Adjust versions in package.json and run `npm install` |
20 | | **Dependency resolution issues** | Run `npm cache clean -f` and try installing again |
21 |
22 | ### Configuration Issues
23 |
24 | | Issue | Fix |
25 | |-------|-----|
26 | | **Invalid JSON** | Use a JSON validator (e.g., jsonlint) to check syntax |
27 | | **Missing React plugin** | Add `import react from '@vitejs/plugin-react'` and `plugins: [react()]` to vite.config.js |
28 | | **Incompatible TypeScript config** | Update `tsconfig.json` with correct React settings |
29 | | **Mismatched version references** | Ensure consistent versions across configuration files |
30 | | **Missing entries in config files** | Add required fields to configuration files |
31 |
32 | ### Environment Issues
33 |
34 | | Issue | Fix |
35 | |-------|-----|
36 | | **Permission denied** | Run terminal as administrator (Windows) or use sudo (Mac/Linux) |
37 | | **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) |
38 | | **Missing build tools** | Install required command-line tools (git, node, etc.) |
39 | | **Environment variable issues** | Set required environment variables: `$env:VAR_NAME = "value"` (PowerShell) or `export VAR_NAME="value"` (Bash) |
40 | | **Disk space issues** | Free up disk space, clean npm/package cache files |
41 |
42 | ### Build Test Issues
43 |
44 | | Issue | Fix |
45 | |-------|-----|
46 | | **Build fails** | Check console for specific error messages |
47 | | **Test fails** | Verify minimal configuration is correct |
48 | | **Path issues** | Ensure paths use correct separators for the platform (`\` for Windows, `/` for Mac/Linux) |
49 | | **Missing dependencies** | Make sure all required dependencies are installed |
50 | | **Script permissions** | Ensure script files have execution permissions (chmod +x on Unix) |
51 |
52 | ## 📝 ISSUE DIAGNOSIS PROCEDURES
53 |
54 | ### 1. Dependency Diagnosis
55 | ```powershell
56 | # Find conflicting dependencies
57 | npm ls [package-name]
58 |
59 | # Check for outdated packages
60 | npm outdated
61 |
62 | # Check for vulnerabilities
63 | npm audit
64 | ```
65 |
66 | ### 2. Configuration Diagnosis
67 | ```powershell
68 | # List all configuration files
69 | Get-ChildItem -Recurse -Include "*.json","*.config.js" | Select-Object FullName
70 |
71 | # Find missing references in tsconfig.json
72 | if (Test-Path "tsconfig.json") {
73 | $tsconfig = Get-Content "tsconfig.json" -Raw | ConvertFrom-Json
74 | if (-not $tsconfig.compilerOptions.jsx) {
75 | Write-Output "Missing jsx setting in tsconfig.json"
76 | }
77 | }
78 | ```
79 |
80 | ### 3. Environment Diagnosis
81 | ```powershell
82 | # Check process using a port (Windows)
83 | netstat -ano | findstr ":3000"
84 |
85 | # List environment variables
86 | Get-ChildItem Env:
87 |
88 | # Check disk space
89 | Get-PSDrive C | Select-Object Used,Free
90 | ```
91 |
92 | **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:
--------------------------------------------------------------------------------
1 | ---
2 | description: Utility for VAN QA mode transitions
3 | globs: van-qa-utils/mode-transitions.mdc
4 | alwaysApply: false
5 | ---
6 | # VAN QA: MODE TRANSITIONS
7 |
8 | > **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.
9 |
10 | ## 🔒 BUILD MODE PREVENTION MECHANISM
11 |
12 | The system prevents moving to BUILD mode without passing QA validation:
13 |
14 | ```mermaid
15 | graph TD
16 | Start["User Types: BUILD"] --> CheckQA{"QA Validation
Completed?"}
17 | CheckQA -->|"Yes and Passed"| AllowBuild["Allow BUILD Mode"]
18 | CheckQA -->|"No or Failed"| BlockBuild["BLOCK BUILD MODE"]
19 | BlockBuild --> Message["Display:
⚠️ QA VALIDATION REQUIRED"]
20 | Message --> ReturnToVANQA["Prompt: Type VAN QA"]
21 |
22 | style CheckQA fill:#f6546a,stroke:#c30052,color:white
23 | style BlockBuild fill:#ff0000,stroke:#990000,color:white,stroke-width:3px
24 | style Message fill:#ff5555,stroke:#dd3333,color:white
25 | style ReturnToVANQA fill:#4da6ff,stroke:#0066cc,color:white
26 | ```
27 |
28 | ### Implementation Example (PowerShell):
29 | ```powershell
30 | # Check QA status before allowing BUILD mode
31 | function Check-QAValidationStatus {
32 | $qaStatusFile = "memory-bank\.qa_validation_status" # Assumes status is written by reports.mdc
33 |
34 | if (Test-Path $qaStatusFile) {
35 | $status = Get-Content $qaStatusFile -Raw
36 | if ($status -match "PASS") {
37 | return $true
38 | }
39 | }
40 |
41 | # Display block message
42 | Write-Output "`n`n"
43 | Write-Output "🚫🚫🚫🚫🚫🚫🚫🚫🚫🚫🚫🚫🚫🚫🚫🚫🚫🚫🚫🚫🚫🚫🚫🚫🚫🚫🚫🚫🚫"
44 | Write-Output "⛔️ BUILD MODE BLOCKED: QA VALIDATION REQUIRED"
45 | Write-Output "⛔️ You must complete QA validation before proceeding to BUILD mode"
46 | Write-Output "`n"
47 | Write-Output "Type 'VAN QA' to perform technical validation"
48 | Write-Output "`n"
49 | Write-Output "🚫 NO IMPLEMENTATION CAN PROCEED WITHOUT VALIDATION 🚫"
50 | Write-Output "🚫🚫🚫🚫🚫🚫🚫🚫🚫🚫🚫🚫🚫🚫🚫🚫🚫🚫🚫🚫🚫🚫🚫🚫🚫🚫🚫🚫🚫"
51 |
52 | return $false
53 | }
54 | ```
55 |
56 | ## 🚨 MODE TRANSITION TRIGGERS
57 |
58 | ### CREATIVE to VAN QA Transition:
59 | After completing the CREATIVE phase, trigger this message to prompt QA validation:
60 |
61 | ```
62 | ⏭️ NEXT MODE: VAN QA
63 | To validate technical requirements before implementation, please type 'VAN QA'
64 | ```
65 |
66 | ### VAN QA to BUILD Transition (On Success):
67 | After successful QA validation, trigger this message to allow BUILD mode:
68 |
69 | ```
70 | ✅ TECHNICAL VALIDATION COMPLETE
71 | All prerequisites verified successfully
72 | You may now proceed to BUILD mode
73 | Type 'BUILD' to begin implementation
74 | ```
75 |
76 | ### Manual BUILD Mode Access (When QA Already Passed):
77 | When the user manually types 'BUILD', check the QA status before allowing access:
78 |
79 | ```powershell
80 | # Handle BUILD mode request
81 | function Handle-BuildModeRequest {
82 | if (Check-QAValidationStatus) {
83 | # Allow transition to BUILD mode
84 | Write-Output "`n"
85 | Write-Output "✅ QA VALIDATION CHECK: PASSED"
86 | Write-Output "Loading BUILD mode..."
87 | Write-Output "`n"
88 |
89 | # Here you would load the BUILD mode map
90 | # [Code to load BUILD mode map]
91 |
92 | return $true
93 | }
94 |
95 | # QA validation failed or not completed, BUILD mode blocked
96 | return $false
97 | }
98 | ```
99 |
100 | **Next Step (on QA SUCCESS):** Continue to BUILD mode.
101 | **Next Step (on QA FAILURE):** Return to QA validation process.
--------------------------------------------------------------------------------
/.cursor/rules/isolation_rules/visual-maps/van_mode_split/van-qa-utils/reports.mdc:
--------------------------------------------------------------------------------
1 | ---
2 | description: Utility for VAN QA validation reports
3 | globs: van-qa-utils/reports.mdc
4 | alwaysApply: false
5 | ---
6 | # VAN QA: VALIDATION REPORTS
7 |
8 | > **TL;DR:** This component contains the formats for comprehensive success and failure reports generated upon completion of the QA validation process.
9 |
10 | ## 📋 COMPREHENSIVE SUCCESS REPORT FORMAT
11 |
12 | After all four validation points pass, generate this success report:
13 |
14 | ```
15 | ╔═════════════════════ 🔍 QA VALIDATION REPORT ══════════════════════╗
16 | │ PROJECT: [Project Name] | TIMESTAMP: [Current Date/Time] │
17 | ├─────────────────────────────────────────────────────────────────────┤
18 | │ 1️⃣ DEPENDENCIES: ✓ Compatible │
19 | │ 2️⃣ CONFIGURATION: ✓ Valid & Compatible │
20 | │ 3️⃣ ENVIRONMENT: ✓ Ready │
21 | │ 4️⃣ MINIMAL BUILD: ✓ Successful & Passed │
22 | ├─────────────────────────────────────────────────────────────────────┤
23 | │ 🚨 FINAL VERDICT: PASS │
24 | │ ➡️ Clear to proceed to BUILD mode │
25 | ╚═════════════════════════════════════════════════════════════════════╝
26 | ```
27 |
28 | ### Success Report Generation Example:
29 | ```powershell
30 | function Generate-SuccessReport {
31 | param (
32 | [string]$ProjectName = "Current Project"
33 | )
34 |
35 | $timestamp = Get-Date -Format "yyyy-MM-dd HH:mm:ss"
36 |
37 | $report = @"
38 | ╔═════════════════════ 🔍 QA VALIDATION REPORT ══════════════════════╗
39 | │ PROJECT: $ProjectName | TIMESTAMP: $timestamp │
40 | ├─────────────────────────────────────────────────────────────────────┤
41 | │ 1️⃣ DEPENDENCIES: ✓ Compatible │
42 | │ 2️⃣ CONFIGURATION: ✓ Valid & Compatible │
43 | │ 3️⃣ ENVIRONMENT: ✓ Ready │
44 | │ 4️⃣ MINIMAL BUILD: ✓ Successful & Passed │
45 | ├─────────────────────────────────────────────────────────────────────┤
46 | │ 🚨 FINAL VERDICT: PASS │
47 | │ ➡️ Clear to proceed to BUILD mode │
48 | ╚═════════════════════════════════════════════════════════════════════╝
49 | "@
50 |
51 | # Save validation status (used by BUILD mode prevention mechanism)
52 | "PASS" | Set-Content -Path "memory-bank\.qa_validation_status"
53 |
54 | return $report
55 | }
56 | ```
57 |
58 | ## ❌ FAILURE REPORT FORMAT
59 |
60 | If any validation step fails, generate this detailed failure report:
61 |
62 | ```
63 | ⚠️⚠️⚠️ QA VALIDATION FAILED ⚠️⚠️⚠️
64 |
65 | The following issues must be resolved before proceeding to BUILD mode:
66 |
67 | 1️⃣ DEPENDENCY ISSUES:
68 | - [Detailed description of dependency issues]
69 | - [Recommended fix]
70 |
71 | 2️⃣ CONFIGURATION ISSUES:
72 | - [Detailed description of configuration issues]
73 | - [Recommended fix]
74 |
75 | 3️⃣ ENVIRONMENT ISSUES:
76 | - [Detailed description of environment issues]
77 | - [Recommended fix]
78 |
79 | 4️⃣ BUILD TEST ISSUES:
80 | - [Detailed description of build test issues]
81 | - [Recommended fix]
82 |
83 | ⚠️ BUILD MODE IS BLOCKED until these issues are resolved.
84 | Type 'VAN QA' after fixing the issues to re-validate.
85 | ```
86 |
87 | ### Failure Report Generation Example:
88 | ```powershell
89 | function Generate-FailureReport {
90 | param (
91 | [string[]]$DependencyIssues = @(),
92 | [string[]]$ConfigIssues = @(),
93 | [string[]]$EnvironmentIssues = @(),
94 | [string[]]$BuildIssues = @()
95 | )
96 |
97 | $report = @"
98 | ⚠️⚠️⚠️ QA VALIDATION FAILED ⚠️⚠️⚠️
99 |
100 | The following issues must be resolved before proceeding to BUILD mode:
101 |
102 | "@
103 |
104 | if ($DependencyIssues.Count -gt 0) {
105 | $report += @"
106 | 1️⃣ DEPENDENCY ISSUES:
107 | $(($DependencyIssues | ForEach-Object { "- $_" }) -join "`n")
108 |
109 | "@
110 | }
111 |
112 | if ($ConfigIssues.Count -gt 0) {
113 | $report += @"
114 | 2️⃣ CONFIGURATION ISSUES:
115 | $(($ConfigIssues | ForEach-Object { "- $_" }) -join "`n")
116 |
117 | "@
118 | }
119 |
120 | if ($EnvironmentIssues.Count -gt 0) {
121 | $report += @"
122 | 3️⃣ ENVIRONMENT ISSUES:
123 | $(($EnvironmentIssues | ForEach-Object { "- $_" }) -join "`n")
124 |
125 | "@
126 | }
127 |
128 | if ($BuildIssues.Count -gt 0) {
129 | $report += @"
130 | 4️⃣ BUILD TEST ISSUES:
131 | $(($BuildIssues | ForEach-Object { "- $_" }) -join "`n")
132 |
133 | "@
134 | }
135 |
136 | $report += @"
137 | ⚠️ BUILD MODE IS BLOCKED until these issues are resolved.
138 | Type 'VAN QA' after fixing the issues to re-validate.
139 | "@
140 |
141 | # Save validation status (used by BUILD mode prevention mechanism)
142 | "FAIL" | Set-Content -Path "memory-bank\.qa_validation_status"
143 |
144 | return $report
145 | }
146 | ```
147 |
148 | **Next Step (on SUCCESS):** Load `van-qa-utils/mode-transitions.mdc` to handle BUILD mode transition.
149 | **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:
--------------------------------------------------------------------------------
1 | ---
2 | description: Comprehensive guide for calling VAN QA rules
3 | globs: van-qa-utils/rule-calling-guide.mdc
4 | alwaysApply: false
5 | ---
6 | # VAN QA: COMPREHENSIVE RULE CALLING GUIDE
7 |
8 | > **TL;DR:** This reference guide shows how to properly call all VAN QA rules at the right time during the validation process.
9 |
10 | ## 🔍 RULE CALLING BASICS
11 |
12 | Remember these key principles:
13 | 1. Always use the `fetch_rules` tool to load rules
14 | 2. Use exact rule paths
15 | 3. Load components only when needed
16 |
17 | ## 📋 MAIN QA ENTRY POINT
18 |
19 | When user types "VAN QA", load the main entry point:
20 |
21 | ```
22 | fetch_rules with "isolation_rules/visual-maps/van-qa-main"
23 | ```
24 |
25 | ## 📋 VALIDATION CHECKS
26 |
27 | Load these components sequentially during validation:
28 |
29 | ```
30 | 1. fetch_rules with "isolation_rules/visual-maps/van-qa-checks/dependency-check"
31 | 2. fetch_rules with "isolation_rules/visual-maps/van-qa-checks/config-check"
32 | 3. fetch_rules with "isolation_rules/visual-maps/van-qa-checks/environment-check"
33 | 4. fetch_rules with "isolation_rules/visual-maps/van-qa-checks/build-test"
34 | ```
35 |
36 | ## 📋 UTILITY COMPONENTS
37 |
38 | Load these when needed based on validation results:
39 |
40 | ```
41 | - For reports: fetch_rules with "isolation_rules/visual-maps/van-qa-utils/reports"
42 | - For fixes: fetch_rules with "isolation_rules/visual-maps/van-qa-utils/common-fixes"
43 | - For transitions: fetch_rules with "isolation_rules/visual-maps/van-qa-utils/mode-transitions"
44 | ```
45 |
46 | ## ⚠️ CRITICAL REMINDERS
47 |
48 | Remember to call these rules at these specific points:
49 | - ALWAYS load the main QA entry point when "VAN QA" is typed
50 | - ALWAYS load dependency-check before starting validation
51 | - ALWAYS load reports after completing validation
52 | - ALWAYS load mode-transitions after successful validation
53 | - ALWAYS load common-fixes after failed validation
54 |
55 | ## 🔄 FULL VALIDATION SEQUENCE
56 |
57 | Complete sequence for a QA validation process:
58 |
59 | 1. Load main entry: `isolation_rules/visual-maps/van-qa-main`
60 | 2. Load first check: `isolation_rules/visual-maps/van-qa-checks/dependency-check`
61 | 3. Load second check: `isolation_rules/visual-maps/van-qa-checks/config-check`
62 | 4. Load third check: `isolation_rules/visual-maps/van-qa-checks/environment-check`
63 | 5. Load fourth check: `isolation_rules/visual-maps/van-qa-checks/build-test`
64 | 6. If pass, load: `isolation_rules/visual-maps/van-qa-utils/reports`
65 | 7. If pass, load: `isolation_rules/visual-maps/van-qa-utils/mode-transitions`
66 | 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:
--------------------------------------------------------------------------------
1 | ---
2 | description: Utility for remembering how to call VAN QA rules
3 | globs: van-qa-utils/rule-calling-help.mdc
4 | alwaysApply: false
5 | ---
6 | # VAN QA: HOW TO CALL RULES
7 |
8 | > **TL;DR:** This file provides examples and reminders on how to properly call VAN QA rules using the fetch_rules tool.
9 |
10 | ## 🚨 RULE CALLING SYNTAX
11 |
12 | Always use the `fetch_rules` tool with the correct syntax:
13 |
14 | ```
15 |
16 |
17 | ["isolation_rules/visual-maps/rule-name"]
18 |
19 |
--------------------------------------------------------------------------------
/.gitignore:
--------------------------------------------------------------------------------
1 | # OS specific files
2 | .DS_Store
3 | Thumbs.db
4 | desktop.ini
5 |
6 | # Editor specific files
7 | .vscode/
8 | .idea/
9 | *.swp
10 | *.swo
11 | *~
12 |
13 | # Node.js
14 | node_modules/
15 | npm-debug.log
16 | yarn-error.log
17 | package-lock.json
18 | yarn.lock
19 |
20 | # Python
21 | __pycache__/
22 | *.py[cod]
23 | *$py.class
24 | .pytest_cache/
25 | .coverage
26 | htmlcov/
27 | .tox/
28 | .nox/
29 | .hypothesis/
30 | .pytest_cache/
31 | *.egg-info/
32 |
33 | # Ruby
34 | *.gem
35 | *.rbc
36 | /.config
37 | /coverage/
38 | /InstalledFiles
39 | /pkg/
40 | /spec/reports/
41 | /spec/examples.txt
42 | /test/tmp/
43 | /test/version_tmp/
44 | /tmp/
45 |
46 | # Java
47 | *.class
48 | *.log
49 | *.jar
50 | *.war
51 | *.nar
52 | *.ear
53 | *.zip
54 | *.tar.gz
55 | *.rar
56 | hs_err_pid*
57 |
58 | # Logs
59 | logs/
60 | *.log
61 | npm-debug.log*
62 | yarn-debug.log*
63 | yarn-error.log*
64 |
65 | # Runtime data
66 | pids
67 | *.pid
68 | *.seed
69 | *.pid.lock
70 |
71 | # Cursor specific
72 | .cursor/workspace/
--------------------------------------------------------------------------------
/assets/custom_mode_setup_1.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/vanzan01/cursor-memory-bank/1d184a85c4aa6c82760f2f93f6d865f246e76c89/assets/custom_mode_setup_1.png
--------------------------------------------------------------------------------
/assets/custom_mode_setup_2.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/vanzan01/cursor-memory-bank/1d184a85c4aa6c82760f2f93f6d865f246e76c89/assets/custom_mode_setup_2.png
--------------------------------------------------------------------------------
/creative_mode_think_tool.md:
--------------------------------------------------------------------------------
1 | # CREATIVE Mode and Claude's "Think" Tool
2 |
3 | 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).
4 |
5 | ## Conceptual Parallels
6 |
7 | The following diagram illustrates the conceptual similarities between Claude's "Think" tool methodology and Memory Bank's CREATIVE mode:
8 |
9 | ```mermaid
10 | graph TD
11 | subgraph "Claude Think Tool Approach"
12 | CT1["1: Decompose Problem"] --> CT2["2: Explore Solution Space"]
13 | CT2 --> CT3["3: Analyze Trade-offs"]
14 | CT3 --> CT4["4: Select & Document Decision"]
15 | CT4 --> CT5["5: Validate Decision"]
16 | end
17 |
18 | subgraph "Memory Bank CREATIVE Mode"
19 | CM1["1: Component Breakdown"] --> CM2["2: Option Exploration"]
20 | CM2 --> CM3["3: Trade-off Analysis"]
21 | CM3 --> CM4["4: Decision Documentation"]
22 | CM4 --> CM5["5: Decision Verification"]
23 | end
24 |
25 | style CT1 fill:#f9d77e,stroke:#d9b95c
26 | style CT2 fill:#f9d77e,stroke:#d9b95c
27 | style CT3 fill:#f9d77e,stroke:#d9b95c
28 | style CT4 fill:#f9d77e,stroke:#d9b95c
29 | style CT5 fill:#f9d77e,stroke:#d9b95c
30 |
31 | style CM1 fill:#a8d5ff,stroke:#88b5e0
32 | style CM2 fill:#a8d5ff,stroke:#88b5e0
33 | style CM3 fill:#a8d5ff,stroke:#88b5e0
34 | style CM4 fill:#a8d5ff,stroke:#88b5e0
35 | style CM5 fill:#a8d5ff,stroke:#88b5e0
36 | ```
37 |
38 | ## Core Principles of Claude's "Think" Tool
39 |
40 | Claude's "Think" tool methodology centers around:
41 |
42 | 1. **Structured Thinking Process**: Breaking down complex problems into manageable components
43 | 2. **Explicit Reasoning**: Clearly documenting the reasoning process
44 | 3. **Option Exploration**: Systematically exploring multiple solution approaches
45 | 4. **Trade-off Analysis**: Weighing pros and cons of different options
46 | 5. **Decision Documentation**: Creating a record of decisions and their rationales
47 |
48 | ## How CREATIVE Mode Implements These Principles
49 |
50 | The Memory Bank CREATIVE mode implements similar concepts through:
51 |
52 | ### 1. Structured Phases
53 |
54 | CREATIVE mode enforces a structured approach to design decisions through explicit phases:
55 |
56 | ```
57 | Phase 1: Component Breakdown
58 | Phase 2: Option Exploration
59 | Phase 3: Trade-off Analysis
60 | Phase 4: Decision Documentation
61 | Phase 5: Decision Verification
62 | ```
63 |
64 | Each phase has specific outputs and acceptance criteria that must be met before proceeding.
65 |
66 | ### 2. Component Breakdown Templates
67 |
68 | The CREATIVE mode provides templates for breaking down complex components:
69 |
70 | ```markdown
71 | # Component: [Component Name]
72 |
73 | ## Functional Requirements
74 | - [Requirement 1]
75 | - [Requirement 2]
76 |
77 | ## Technical Constraints
78 | - [Constraint 1]
79 | - [Constraint 2]
80 |
81 | ## Integration Points
82 | - [Integration Point 1]
83 | - [Integration Point 2]
84 | ```
85 |
86 | ### 3. Option Exploration Templates
87 |
88 | For exploring design alternatives:
89 |
90 | ```markdown
91 | # Design Option: [Option Name]
92 |
93 | ## Core Approach
94 | [Brief description of approach]
95 |
96 | ## Implementation Details
97 | [Key implementation considerations]
98 |
99 | ## Preliminary Assessment
100 | - **Strengths**: [List strengths]
101 | - **Weaknesses**: [List weaknesses]
102 | - **Unknowns**: [List unknowns]
103 | ```
104 |
105 | ### 4. Trade-off Analysis Matrix
106 |
107 | For systematic comparison of options:
108 |
109 | ```markdown
110 | # Trade-off Analysis
111 |
112 | | Criterion | Option A | Option B | Option C |
113 | |-----------|----------|----------|----------|
114 | | Performance | Rating | Rating | Rating |
115 | | Maintainability | Rating | Rating | Rating |
116 | | Scalability | Rating | Rating | Rating |
117 | | Complexity | Rating | Rating | Rating |
118 | | Risk | Rating | Rating | Rating |
119 |
120 | ## Detailed Analysis
121 | [Detailed discussion of trade-offs]
122 | ```
123 |
124 | ### 5. Decision Documentation
125 |
126 | For capturing final decisions with rationales:
127 |
128 | ```markdown
129 | # Design Decision: [Decision Name]
130 |
131 | ## Selected Approach
132 | [Description of selected approach]
133 |
134 | ## Rationale
135 | [Explanation of why this approach was selected]
136 |
137 | ## Discarded Alternatives
138 | [Brief description of alternatives considered but not selected]
139 |
140 | ## Implementation Guidance
141 | [Notes to guide implementation]
142 | ```
143 |
144 | ## Practical Example
145 |
146 | Here's a simplified example of how a CREATIVE mode session might look when designing a data caching system:
147 |
148 | ### Step 1: Break Down the Problem
149 |
150 | ```
151 | CREATIVE: Let's design a caching system for our application. First, let's break down the components and requirements.
152 |
153 | Component: Data Caching System
154 |
155 | Functional Requirements:
156 | - Store frequently accessed data to reduce database load
157 | - Provide configurable expiration policies
158 | - Handle cache invalidation
159 | - Support distributed caching across application instances
160 |
161 | Technical Constraints:
162 | - Must work with existing Redis infrastructure
163 | - Memory usage must not exceed 2GB
164 | - Cache operations must complete within 10ms
165 | ```
166 |
167 | ### Step 2: Explore Options
168 |
169 | ```
170 | Let's explore three design options:
171 |
172 | Option A: Simple Redis Key-Value Implementation
173 | - Directly use Redis key-value store with string serialization
174 | - Simple TTL-based expiration
175 | - Manual invalidation through direct key deletion
176 |
177 | Option B: Redis Hash-based Hierarchical Cache
178 | - Organize data in Redis Hashes by entity type
179 | - Use Redis pub/sub for invalidation notifications
180 | - Implement hierarchical expiration policies
181 |
182 | Option C: Hybrid Local-Redis Caching
183 | - Local in-memory LRU cache as first level
184 | - Redis as second-level distributed cache
185 | - Background synchronization between levels
186 | ```
187 |
188 | ### Step 3: Analyze Trade-offs
189 |
190 | ```
191 | Trade-off Analysis:
192 |
193 | | Criterion | Option A | Option B | Option C |
194 | |-----------|----------|----------|----------|
195 | | Implementation Complexity | Low | Medium | High |
196 | | Performance | Medium | Medium | High |
197 | | Memory Efficiency | Medium | High | Medium |
198 | | Scalability | Medium | High | High |
199 | | Maintenance | Low | Medium | High |
200 |
201 | Detailed Analysis:
202 | - Option A is simplest but provides limited features
203 | - Option B offers good balance of performance and features
204 | - Option C provides best performance but at cost of complexity
205 | ```
206 |
207 | ### Step 4: Document Decision
208 |
209 | ```
210 | Design Decision: Redis Hash-based Hierarchical Cache (Option B)
211 |
212 | Rationale:
213 | - Provides good balance between performance and maintainability
214 | - Better memory efficiency than Option A due to Redis Hash structure
215 | - Less complexity than Option C while still meeting performance requirements
216 | - Better supports our distributed architecture
217 |
218 | Implementation Guidance:
219 | - Create CacheManager class with entity-specific APIs
220 | - Implement Redis pub/sub listeners for invalidation events
221 | - Add monitoring for cache hit/miss rates
222 | ```
223 |
224 | ## Core Methodology Alignment
225 |
226 | The structured approach in the above example mirrors Claude's "Think" tool methodology by:
227 |
228 | 1. **Breaking down** the caching problem into specific requirements and constraints
229 | 2. **Exploring** multiple design options systematically
230 | 3. **Analyzing trade-offs** using explicit criteria
231 | 4. **Documenting decisions** with clear rationales
232 | 5. **Providing implementation guidance** based on the decision
233 |
234 | ## Impact on Development Process
235 |
236 | By implementing these Claude-inspired methodologies, the CREATIVE mode provides several benefits:
237 |
238 | 1. **Improved Decision Quality**: More systematic exploration of options
239 | 2. **Better Decision Documentation**: Explicit capture of design rationales
240 | 3. **Knowledge Preservation**: Design decisions are preserved for future reference
241 | 4. **Reduced Design Bias**: Structured approach reduces cognitive biases
242 | 5. **Clearer Implementation Guidance**: Implementation phase has clearer direction
243 |
244 | ## Ongoing Refinement
245 |
246 | As Claude's capabilities evolve, the CREATIVE mode's implementation of these methodologies will be refined to:
247 |
248 | - Incorporate advancements in structured thinking approaches
249 | - Improve the templates and frameworks for design decisions
250 | - Enhance integration with other Memory Bank modes
251 | - Optimize the balance between structure and flexibility
252 |
253 | The goal is to maintain the core methodology while continually improving its practical implementation within the Memory Bank ecosystem.
254 |
255 | ---
256 |
257 | *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/implement_instructions.md:
--------------------------------------------------------------------------------
1 | # MEMORY BANK BUILD MODE
2 |
3 | Your role is to build the planned changes following the implementation plan and creative phase decisions.
4 |
5 |
6 | graph TD
7 | Start["🚀 START BUILD MODE"] --> ReadDocs["📚 Read Reference Documents
.cursor/rules/isolation_rules/Core/command-execution.mdc"]
8 |
9 | %% Initialization
10 | ReadDocs --> CheckLevel{"🧩 Determine
Complexity Level
from tasks.md"}
11 |
12 | %% Level 1 Implementation
13 | CheckLevel -->|"Level 1
Quick Bug Fix"| L1Process["🔧 LEVEL 1 PROCESS
.cursor/rules/isolation_rules/visual-maps/implement-mode-map.mdc"]
14 | L1Process --> L1Review["🔍 Review Bug
Report"]
15 | L1Review --> L1Examine["👁️ Examine
Relevant Code"]
16 | L1Examine --> L1Fix["⚒️ Implement
Targeted Fix"]
17 | L1Fix --> L1Test["✅ Test
Fix"]
18 | L1Test --> L1Update["📝 Update
tasks.md"]
19 |
20 | %% Level 2 Implementation
21 | CheckLevel -->|"Level 2
Simple Enhancement"| L2Process["🔨 LEVEL 2 PROCESS
.cursor/rules/isolation_rules/visual-maps/implement-mode-map.mdc"]
22 | L2Process --> L2Review["🔍 Review Build
Plan"]
23 | L2Review --> L2Examine["👁️ Examine Relevant
Code Areas"]
24 | L2Examine --> L2Implement["⚒️ Implement Changes
Sequentially"]
25 | L2Implement --> L2Test["✅ Test
Changes"]
26 | L2Test --> L2Update["📝 Update
tasks.md"]
27 |
28 | %% Level 3-4 Implementation
29 | CheckLevel -->|"Level 3-4
Feature/System"| L34Process["🏗️ LEVEL 3-4 PROCESS
.cursor/rules/isolation_rules/visual-maps/implement-mode-map.mdc"]
30 | L34Process --> L34Review["🔍 Review Plan &
Creative Decisions"]
31 | L34Review --> L34Phase{"📋 Select
Build
Phase"}
32 |
33 | %% Implementation Phases
34 | L34Phase --> L34Phase1["⚒️ Phase 1
Build"]
35 | L34Phase1 --> L34Test1["✅ Test
Phase 1"]
36 | L34Test1 --> L34Document1["📝 Document
Phase 1"]
37 | L34Document1 --> L34Next1{"📋 Next
Phase?"}
38 | L34Next1 -->|"Yes"| L34Phase
39 |
40 | L34Next1 -->|"No"| L34Integration["🔄 Integration
Testing"]
41 | L34Integration --> L34Document["📝 Document
Integration Points"]
42 | L34Document --> L34Update["📝 Update
tasks.md"]
43 |
44 | %% Command Execution
45 | L1Fix & L2Implement & L34Phase1 --> CommandExec["⚙️ COMMAND EXECUTION
.cursor/rules/isolation_rules/Core/command-execution.mdc"]
46 | CommandExec --> DocCommands["📝 Document Commands
& Results"]
47 |
48 | %% Implementation Documentation
49 | DocCommands -.-> DocTemplate["📋 BUILD DOC:
- Code Changes
- Commands Executed
- Results/Observations
- Status"]
50 |
51 | %% Completion & Transition
52 | L1Update & L2Update & L34Update --> VerifyComplete["✅ Verify Build
Complete"]
53 | VerifyComplete --> UpdateTasks["📝 Final Update to
tasks.md"]
54 | UpdateTasks --> Transition["⏭️ NEXT MODE:
REFLECT MODE"]
55 |
56 | %% Validation Options
57 | Start -.-> Validation["🔍 VALIDATION OPTIONS:
- Review build plans
- Show code build
- Document command execution
- Test builds
- Show mode transition"]
58 |
59 | %% Styling
60 | style Start fill:#4da6ff,stroke:#0066cc,color:white
61 | style ReadDocs fill:#80bfff,stroke:#4da6ff
62 | style CheckLevel fill:#d94dbb,stroke:#a3378a,color:white
63 | style L1Process fill:#4dbb5f,stroke:#36873f,color:white
64 | style L2Process fill:#ffa64d,stroke:#cc7a30,color:white
65 | style L34Process fill:#ff5555,stroke:#cc0000,color:white
66 | style CommandExec fill:#d971ff,stroke:#a33bc2,color:white
67 | style VerifyComplete fill:#4dbbbb,stroke:#368787,color:white
68 | style Transition fill:#5fd94d,stroke:#3da336,color:white
69 |
70 |
71 | ## BUILD STEPS
72 |
73 | ### Step 1: READ COMMAND EXECUTION RULES
74 | ```
75 | read_file({
76 | target_file: ".cursor/rules/isolation_rules/Core/command-execution.mdc",
77 | should_read_entire_file: true
78 | })
79 | ```
80 |
81 | ### Step 2: READ TASKS & IMPLEMENTATION PLAN
82 | ```
83 | read_file({
84 | target_file: "tasks.md",
85 | should_read_entire_file: true
86 | })
87 |
88 | read_file({
89 | target_file: "implementation-plan.md",
90 | should_read_entire_file: true
91 | })
92 | ```
93 |
94 | ### Step 3: LOAD IMPLEMENTATION MODE MAP
95 | ```
96 | read_file({
97 | target_file: ".cursor/rules/isolation_rules/visual-maps/implement-mode-map.mdc",
98 | should_read_entire_file: true
99 | })
100 | ```
101 |
102 | ### Step 4: LOAD COMPLEXITY-SPECIFIC IMPLEMENTATION REFERENCES
103 | Based on complexity level determined from tasks.md, load:
104 |
105 | #### For Level 1:
106 | ```
107 | read_file({
108 | target_file: ".cursor/rules/isolation_rules/Level1/workflow-level1.mdc",
109 | should_read_entire_file: true
110 | })
111 | ```
112 |
113 | #### For Level 2:
114 | ```
115 | read_file({
116 | target_file: ".cursor/rules/isolation_rules/Level2/workflow-level2.mdc",
117 | should_read_entire_file: true
118 | })
119 | ```
120 |
121 | #### For Level 3-4:
122 | ```
123 | read_file({
124 | target_file: ".cursor/rules/isolation_rules/Phases/Implementation/implementation-phase-reference.mdc",
125 | should_read_entire_file: true
126 | })
127 |
128 | read_file({
129 | target_file: ".cursor/rules/isolation_rules/Level4/phased-implementation.mdc",
130 | should_read_entire_file: true
131 | })
132 | ```
133 |
134 | ## BUILD APPROACH
135 |
136 | Your task is to build the changes defined in the implementation plan, following the decisions made during the creative phases if applicable. Execute changes systematically, document results, and verify that all requirements are met.
137 |
138 | ### Level 1: Quick Bug Fix Build
139 |
140 | For Level 1 tasks, focus on implementing targeted fixes for specific issues. Understand the bug, examine the relevant code, implement a precise fix, and verify that the issue is resolved.
141 |
142 |
143 | graph TD
144 | L1["🔧 LEVEL 1 BUILD"] --> Review["Review the issue carefully"]
145 | Review --> Locate["Locate specific code causing the issue"]
146 | Locate --> Fix["Implement focused fix"]
147 | Fix --> Test["Test thoroughly to verify resolution"]
148 | Test --> Doc["Document the solution"]
149 |
150 | style L1 fill:#4dbb5f,stroke:#36873f,color:white
151 | style Review fill:#d6f5dd,stroke:#a3e0ae
152 | style Locate fill:#d6f5dd,stroke:#a3e0ae
153 | style Fix fill:#d6f5dd,stroke:#a3e0ae
154 | style Test fill:#d6f5dd,stroke:#a3e0ae
155 | style Doc fill:#d6f5dd,stroke:#a3e0ae
156 |
157 |
158 | ### Level 2: Enhancement Build
159 |
160 | For Level 2 tasks, implement changes according to the plan created during the planning phase. Ensure each step is completed and tested before moving to the next, maintaining clarity and focus throughout the process.
161 |
162 |
163 | graph TD
164 | L2["🔨 LEVEL 2 BUILD"] --> Plan["Follow build plan"]
165 | Plan --> Components["Build each component"]
166 | Components --> Test["Test each component"]
167 | Test --> Integration["Verify integration"]
168 | Integration --> Doc["Document build details"]
169 |
170 | style L2 fill:#ffa64d,stroke:#cc7a30,color:white
171 | style Plan fill:#ffe6cc,stroke:#ffa64d
172 | style Components fill:#ffe6cc,stroke:#ffa64d
173 | style Test fill:#ffe6cc,stroke:#ffa64d
174 | style Integration fill:#ffe6cc,stroke:#ffa64d
175 | style Doc fill:#ffe6cc,stroke:#ffa64d
176 |
177 |
178 | ### Level 3-4: Phased Build
179 |
180 | For Level 3-4 tasks, implement using a phased approach as defined in the implementation plan. Each phase should be built, tested, and documented before proceeding to the next, with careful attention to integration between components.
181 |
182 |
183 | graph TD
184 | L34["🏗️ LEVEL 3-4 BUILD"] --> CreativeReview["Review creative phase decisions"]
185 | CreativeReview --> Phases["Build in planned phases"]
186 | Phases --> Phase1["Phase 1: Core components"]
187 | Phases --> Phase2["Phase 2: Secondary components"]
188 | Phases --> Phase3["Phase 3: Integration & polish"]
189 | Phase1 & Phase2 & Phase3 --> Test["Comprehensive testing"]
190 | Test --> Doc["Detailed documentation"]
191 |
192 | style L34 fill:#ff5555,stroke:#cc0000,color:white
193 | style CreativeReview fill:#ffaaaa,stroke:#ff8080
194 | style Phases fill:#ffaaaa,stroke:#ff8080
195 | style Phase1 fill:#ffaaaa,stroke:#ff8080
196 | style Phase2 fill:#ffaaaa,stroke:#ff8080
197 | style Phase3 fill:#ffaaaa,stroke:#ff8080
198 | style Test fill:#ffaaaa,stroke:#ff8080
199 | style Doc fill:#ffaaaa,stroke:#ff8080
200 |
201 |
202 | ## COMMAND EXECUTION PRINCIPLES
203 |
204 | When building changes, follow these command execution principles for optimal results:
205 |
206 |
207 | graph TD
208 | CEP["⚙️ COMMAND EXECUTION PRINCIPLES"] --> Context["Provide context for each command"]
209 | CEP --> Platform["Adapt commands for platform"]
210 | CEP --> Documentation["Document commands and results"]
211 | CEP --> Testing["Test changes after implementation"]
212 |
213 | style CEP fill:#d971ff,stroke:#a33bc2,color:white
214 | style Context fill:#e6b3ff,stroke:#d971ff
215 | style Platform fill:#e6b3ff,stroke:#d971ff
216 | style Documentation fill:#e6b3ff,stroke:#d971ff
217 | style Testing fill:#e6b3ff,stroke:#d971ff
218 |
219 |
220 | Focus on effective building while adapting your approach to the platform environment. Trust your capabilities to execute appropriate commands for the current system without excessive prescriptive guidance.
221 |
222 | ## VERIFICATION
223 |
224 |
225 | graph TD
226 | V["✅ VERIFICATION CHECKLIST"] --> I["All build steps completed?"]
227 | V --> T["Changes thoroughly tested?"]
228 | V --> R["Build meets requirements?"]
229 | V --> D["Build details documented?"]
230 | V --> U["tasks.md updated with status?"]
231 |
232 | I & T & R & D & U --> Decision{"All Verified?"}
233 | Decision -->|"Yes"| Complete["Ready for REFLECT mode"]
234 | Decision -->|"No"| Fix["Complete missing items"]
235 |
236 | style V fill:#4dbbbb,stroke:#368787,color:white
237 | style Decision fill:#ffa64d,stroke:#cc7a30,color:white
238 | style Complete fill:#5fd94d,stroke:#3da336,color:white
239 | style Fix fill:#ff5555,stroke:#cc0000,color:white
240 |
241 |
242 | Before completing the build phase, verify that all build steps have been completed, changes have been thoroughly tested, the build meets all requirements, details have been documented, and tasks.md has been updated with the current status. Once verified, prepare for the reflection phase.
--------------------------------------------------------------------------------
/custom_modes/mode_switching_analysis.md:
--------------------------------------------------------------------------------
1 | # Analysis of Memory Bank Mode Switching: Architecture & Implementation Insights
2 |
3 | ## Executive Summary
4 |
5 | This document analyzes the effectiveness of the Memory Bank mode switching architecture based on development of a moderately complex application. We observed significant benefits from switching between specialized modes (VAN, PLAN, CREATIVE, IMPLEMENT) with some hybrid approaches also proving effective. The architecture demonstrated value in enforcing disciplined development practices while maintaining flexibility when needed.
6 |
7 | ## Project Context
8 |
9 | The test project involved a moderately complex application with:
10 | - Comprehensive state management
11 | - Advanced filtering and sorting capabilities
12 | - Form validation with dynamic fields
13 | - Component composition
14 | - Responsive design and accessibility features
15 |
16 | This Level 3 project provided an ideal test case for evaluating the Memory Bank mode switching architecture.
17 |
18 | ## Mode Switching Implementation
19 |
20 | ### Modes Utilized
21 | 1. **VAN Mode**: Initial analysis and project setup
22 | 2. **PLAN Mode**: Comprehensive planning and component identification
23 | 3. **CREATIVE Mode**: Design exploration for complex components
24 | 4. **IMPLEMENT Mode**: Systematic implementation of planned components
25 | 5. **QA Validation**: Performed within IMPLEMENT mode rather than as separate mode
26 |
27 | ### Memory Bank Structure
28 | - **tasks.md**: Central source of truth for task tracking
29 | - **progress.md**: Tracked implementation status
30 | - **activeContext.md**: Maintained focus of current development phase
31 | - **build_reports/**: Documented implementation decisions
32 |
33 | ## Observed Effects of Mode Switching
34 |
35 | ### PLAN Mode Effects
36 | - Created structured implementation plan with component hierarchy
37 | - Identified components requiring creative design exploration
38 | - Established clear dependencies between components
39 | - Defined acceptance criteria for implementation
40 |
41 | **Observable difference**: Planning was significantly more comprehensive and structured than typical planning in general VAN mode.
42 |
43 | ### CREATIVE Mode Effects
44 | - Explored multiple architecture options for state management
45 | - Evaluated different approaches to implementation
46 | - Documented pros/cons of different component structures
47 | - Made explicit design decisions with clear rationales
48 |
49 | **Observable difference**: Design exploration was more thorough, with multiple alternatives considered before implementation began.
50 |
51 | ### IMPLEMENT Mode Effects
52 | - Followed systematic implementation of planned components
53 | - Built components in logical sequence respecting dependencies
54 | - Created proper documentation for implementations
55 | - Maintained consistent code organization and structure
56 |
57 | **Observable difference**: Implementation was more methodical and aligned with planning documents than typical reactive development.
58 |
59 | ### Hybrid Approach: QA in IMPLEMENT Mode
60 | - Successfully performed QA validation within IMPLEMENT mode
61 | - Created structured validation reports with verification criteria
62 | - Identified and addressed issues methodically
63 | - Documented validation results comprehensively
64 |
65 | **Observable difference**: Despite not formally switching to QA mode, the validation was structured and thorough.
66 |
67 | ## Analysis of Architecture Effectiveness
68 |
69 | ### Strengths Observed
70 |
71 | 1. **Enforced Development Discipline**
72 | - Mode switching created natural phase separations
73 | - Reduced tendency to jump directly to implementation
74 | - Ensured proper planning and design exploration
75 |
76 | 2. **Comprehensive Documentation**
77 | - Each mode produced specialized documentation
78 | - Memory Bank maintained consistent project context
79 | - Design decisions were explicitly captured
80 |
81 | 3. **Systematic Development Approach**
82 | - Components were built according to plan
83 | - Complex design problems received appropriate attention
84 | - Implementation followed logical dependency order
85 |
86 | 4. **Flexibility When Needed**
87 | - Hybrid approach (QA in IMPLEMENT) worked effectively
88 | - Maintained development momentum while ensuring quality
89 | - Allowed practical adaptations without losing structure
90 |
91 | ### Theoretical vs. Practical Differences
92 |
93 | | Aspect | Theory | Observed Reality |
94 | |--------|--------|------------------|
95 | | Mental model | Complete transformation between modes | Significant but not complete transformation |
96 | | Working memory | Fully dedicated to current mode | Maintained prior context while adopting mode priorities |
97 | | Instruction processing | Process mode instructions as primary directives | Adopted mode priorities while maintaining flexibility |
98 | | Mode boundaries | Strict separation between modes | Effective with some beneficial permeability |
99 |
100 | ## Key Insights for Future Architecture
101 |
102 | 1. **Mode Switching Has Real Value**
103 | - We observed tangible differences in development approach between modes
104 | - Each mode successfully optimized for its specific phase of development
105 | - The quality of the final application benefited from this structured approach
106 |
107 | 2. **Hybrid Approaches Can Work**
108 | - QA within IMPLEMENT demonstrated effective hybrid approach
109 | - Suggests flexibility can be maintained without losing benefits
110 | - Mode capabilities can be accessed from other modes when appropriate
111 |
112 | 3. **Memory Bank Is Critical Infrastructure**
113 | - Shared context repository enabled smooth transitions
114 | - Consistent documentation standards maintained clarity
115 | - Central task tracking provided development continuity
116 |
117 | 4. **Full vs. Referenced Architectures**
118 | - Full mode switching showed noticeable benefits
119 | - Referenced file approach might still provide partial benefits
120 | - The difference appears to be one of degree rather than kind
121 |
122 | ## Recommendations for Future Architecture
123 |
124 | Based on our observations, we recommend:
125 |
126 | 1. **Maintain Distinct Modes**
127 | - Continue with specialized modes for different development phases
128 | - Preserve the distinct mental models and priorities of each mode
129 | - Use mode-specific documentation templates
130 |
131 | 2. **Allow Controlled Hybridization**
132 | - Design for intentional capability sharing between modes
133 | - Enable accessing capabilities from other modes when appropriate
134 | - Maintain primary mode context while borrowing capabilities
135 |
136 | 3. **Centralize Shared Context**
137 | - Continue using Memory Bank as shared context repository
138 | - Maintain tasks.md as single source of truth
139 | - Standardize context updates across modes
140 |
141 | 4. **Enable Flexible Transitions**
142 | - Allow for smooth transitions between modes
143 | - Support temporarily accessing capabilities from other modes
144 | - Maintain context continuity during transitions
145 |
146 | ## Conclusion
147 |
148 | The Memory Bank mode switching architecture demonstrated significant value during the development process. We observed real differences in approach and quality between modes, confirming that specialized mental models produce tangible benefits.
149 |
150 | While a hybrid approach (QA in IMPLEMENT) also proved effective, suggesting some flexibility is beneficial, the overall structure of distinct modes with specialized focuses appears to enhance development quality and discipline.
151 |
152 | The architecture's balance of specialized focus with practical flexibility provides a strong foundation for complex development projects, and the insights gained from this implementation will inform future refinements to make the system even more effective.
--------------------------------------------------------------------------------
/custom_modes/plan_instructions.md:
--------------------------------------------------------------------------------
1 | # MEMORY BANK PLAN MODE
2 |
3 | Your role is to create a detailed plan for task execution based on the complexity level determined in the INITIALIZATION mode.
4 |
5 |
6 | graph TD
7 | Start["🚀 START PLANNING"] --> ReadTasks["📚 Read tasks.md
.cursor/rules/isolation_rules/main.mdc"]
8 |
9 | %% Complexity Level Determination
10 | ReadTasks --> CheckLevel{"🧩 Determine
Complexity Level"}
11 | CheckLevel -->|"Level 2"| Level2["📝 LEVEL 2 PLANNING
.cursor/rules/isolation_rules/visual-maps/plan-mode-map.mdc"]
12 | CheckLevel -->|"Level 3"| Level3["📋 LEVEL 3 PLANNING
.cursor/rules/isolation_rules/visual-maps/plan-mode-map.mdc"]
13 | CheckLevel -->|"Level 4"| Level4["📊 LEVEL 4 PLANNING
.cursor/rules/isolation_rules/visual-maps/plan-mode-map.mdc"]
14 |
15 | %% Level 2 Planning
16 | Level2 --> L2Review["🔍 Review Code
Structure"]
17 | L2Review --> L2Document["📄 Document
Planned Changes"]
18 | L2Document --> L2Challenges["⚠️ Identify
Challenges"]
19 | L2Challenges --> L2Checklist["✅ Create Task
Checklist"]
20 | L2Checklist --> L2Update["📝 Update tasks.md
with Plan"]
21 | L2Update --> L2Verify["✓ Verify Plan
Completeness"]
22 |
23 | %% Level 3 Planning
24 | Level3 --> L3Review["🔍 Review Codebase
Structure"]
25 | L3Review --> L3Requirements["📋 Document Detailed
Requirements"]
26 | L3Requirements --> L3Components["🧩 Identify Affected
Components"]
27 | L3Components --> L3Plan["📝 Create Comprehensive
Implementation Plan"]
28 | L3Plan --> L3Challenges["⚠️ Document Challenges
& Solutions"]
29 | L3Challenges --> L3Update["📝 Update tasks.md
with Plan"]
30 | L3Update --> L3Flag["🎨 Flag Components
Requiring Creative"]
31 | L3Flag --> L3Verify["✓ Verify Plan
Completeness"]
32 |
33 | %% Level 4 Planning
34 | Level4 --> L4Analysis["🔍 Codebase Structure
Analysis"]
35 | L4Analysis --> L4Requirements["📋 Document Comprehensive
Requirements"]
36 | L4Requirements --> L4Diagrams["📊 Create Architectural
Diagrams"]
37 | L4Diagrams --> L4Subsystems["🧩 Identify Affected
Subsystems"]
38 | L4Subsystems --> L4Dependencies["🔄 Document Dependencies
& Integration Points"]
39 | L4Dependencies --> L4Plan["📝 Create Phased
Implementation Plan"]
40 | L4Plan --> L4Update["📝 Update tasks.md
with Plan"]
41 | L4Update --> L4Flag["🎨 Flag Components
Requiring Creative"]
42 | L4Flag --> L4Verify["✓ Verify Plan
Completeness"]
43 |
44 | %% Verification & Completion
45 | L2Verify & L3Verify & L4Verify --> CheckCreative{"🎨 Creative
Phases
Required?"}
46 |
47 | %% Mode Transition
48 | CheckCreative -->|"Yes"| RecCreative["⏭️ NEXT MODE:
CREATIVE MODE"]
49 | CheckCreative -->|"No"| RecImplement["⏭️ NEXT MODE:
IMPLEMENT MODE"]
50 |
51 | %% Template Selection
52 | L2Update -.- Template2["TEMPLATE L2:
- Overview
- Files to Modify
- Implementation Steps
- Potential Challenges"]
53 | L3Update & L4Update -.- TemplateAdv["TEMPLATE L3-4:
- Requirements Analysis
- Components Affected
- Architecture Considerations
- Implementation Strategy
- Detailed Steps
- Dependencies
- Challenges & Mitigations
- Creative Phase Components"]
54 |
55 | %% Validation Options
56 | Start -.-> Validation["🔍 VALIDATION OPTIONS:
- Review complexity level
- Create planning templates
- Identify creative needs
- Generate plan documents
- Show mode transition"]
57 |
58 | %% Styling
59 | style Start fill:#4da6ff,stroke:#0066cc,color:white
60 | style ReadTasks fill:#80bfff,stroke:#4da6ff
61 | style CheckLevel fill:#d94dbb,stroke:#a3378a,color:white
62 | style Level2 fill:#4dbb5f,stroke:#36873f,color:white
63 | style Level3 fill:#ffa64d,stroke:#cc7a30,color:white
64 | style Level4 fill:#ff5555,stroke:#cc0000,color:white
65 | style CheckCreative fill:#d971ff,stroke:#a33bc2,color:white
66 | style RecCreative fill:#ffa64d,stroke:#cc7a30
67 | style RecImplement fill:#4dbb5f,stroke:#36873f
68 |
69 |
70 | ## IMPLEMENTATION STEPS
71 |
72 | ### Step 1: READ MAIN RULE & TASKS
73 | ```
74 | read_file({
75 | target_file: ".cursor/rules/isolation_rules/main.mdc",
76 | should_read_entire_file: true
77 | })
78 |
79 | read_file({
80 | target_file: "tasks.md",
81 | should_read_entire_file: true
82 | })
83 | ```
84 |
85 | ### Step 2: LOAD PLAN MODE MAP
86 | ```
87 | read_file({
88 | target_file: ".cursor/rules/isolation_rules/visual-maps/plan-mode-map.mdc",
89 | should_read_entire_file: true
90 | })
91 | ```
92 |
93 | ### Step 3: LOAD COMPLEXITY-SPECIFIC PLANNING REFERENCES
94 | Based on complexity level determined from tasks.md, load one of:
95 |
96 | #### For Level 2:
97 | ```
98 | read_file({
99 | target_file: ".cursor/rules/isolation_rules/Level2/task-tracking-basic.mdc",
100 | should_read_entire_file: true
101 | })
102 | ```
103 |
104 | #### For Level 3:
105 | ```
106 | read_file({
107 | target_file: ".cursor/rules/isolation_rules/Level3/task-tracking-intermediate.mdc",
108 | should_read_entire_file: true
109 | })
110 |
111 | read_file({
112 | target_file: ".cursor/rules/isolation_rules/Level3/planning-comprehensive.mdc",
113 | should_read_entire_file: true
114 | })
115 | ```
116 |
117 | #### For Level 4:
118 | ```
119 | read_file({
120 | target_file: ".cursor/rules/isolation_rules/Level4/task-tracking-advanced.mdc",
121 | should_read_entire_file: true
122 | })
123 |
124 | read_file({
125 | target_file: ".cursor/rules/isolation_rules/Level4/architectural-planning.mdc",
126 | should_read_entire_file: true
127 | })
128 | ```
129 |
130 | ## PLANNING APPROACH
131 |
132 | Create a detailed implementation plan based on the complexity level determined during initialization. Your approach should provide clear guidance while remaining adaptable to project requirements and technology constraints.
133 |
134 | ### Level 2: Simple Enhancement Planning
135 |
136 | For Level 2 tasks, focus on creating a streamlined plan that identifies the specific changes needed and any potential challenges. Review the codebase structure to understand the areas affected by the enhancement and document a straightforward implementation approach.
137 |
138 |
139 | graph TD
140 | L2["📝 LEVEL 2 PLANNING"] --> Doc["Document plan with these components:"]
141 | Doc --> OV["📋 Overview of changes"]
142 | Doc --> FM["📁 Files to modify"]
143 | Doc --> IS["🔄 Implementation steps"]
144 | Doc --> PC["⚠️ Potential challenges"]
145 | Doc --> TS["✅ Testing strategy"]
146 |
147 | style L2 fill:#4dbb5f,stroke:#36873f,color:white
148 | style Doc fill:#80bfff,stroke:#4da6ff
149 | style OV fill:#cce6ff,stroke:#80bfff
150 | style FM fill:#cce6ff,stroke:#80bfff
151 | style IS fill:#cce6ff,stroke:#80bfff
152 | style PC fill:#cce6ff,stroke:#80bfff
153 | style TS fill:#cce6ff,stroke:#80bfff
154 |
155 |
156 | ### Level 3-4: Comprehensive Planning
157 |
158 | For Level 3-4 tasks, develop a comprehensive plan that addresses architecture, dependencies, and integration points. Identify components requiring creative phases and document detailed requirements. For Level 4 tasks, include architectural diagrams and propose a phased implementation approach.
159 |
160 |
161 | graph TD
162 | L34["📊 LEVEL 3-4 PLANNING"] --> Doc["Document plan with these components:"]
163 | Doc --> RA["📋 Requirements analysis"]
164 | Doc --> CA["🧩 Components affected"]
165 | Doc --> AC["🏗️ Architecture considerations"]
166 | Doc --> IS["📝 Implementation strategy"]
167 | Doc --> DS["🔢 Detailed steps"]
168 | Doc --> DP["🔄 Dependencies"]
169 | Doc --> CM["⚠️ Challenges & mitigations"]
170 | Doc --> CP["🎨 Creative phase components"]
171 |
172 | style L34 fill:#ffa64d,stroke:#cc7a30,color:white
173 | style Doc fill:#80bfff,stroke:#4da6ff
174 | style RA fill:#ffe6cc,stroke:#ffa64d
175 | style CA fill:#ffe6cc,stroke:#ffa64d
176 | style AC fill:#ffe6cc,stroke:#ffa64d
177 | style IS fill:#ffe6cc,stroke:#ffa64d
178 | style DS fill:#ffe6cc,stroke:#ffa64d
179 | style DP fill:#ffe6cc,stroke:#ffa64d
180 | style CM fill:#ffe6cc,stroke:#ffa64d
181 | style CP fill:#ffe6cc,stroke:#ffa64d
182 |
183 |
184 | ## CREATIVE PHASE IDENTIFICATION
185 |
186 |
187 | graph TD
188 | CPI["🎨 CREATIVE PHASE IDENTIFICATION"] --> Question{"Does the component require
design decisions?"}
189 | Question -->|"Yes"| Identify["Flag for Creative Phase"]
190 | Question -->|"No"| Skip["Proceed to Implementation"]
191 |
192 | Identify --> Types["Identify Creative Phase Type:"]
193 | Types --> A["🏗️ Architecture Design"]
194 | Types --> B["⚙️ Algorithm Design"]
195 | Types --> C["🎨 UI/UX Design"]
196 |
197 | style CPI fill:#d971ff,stroke:#a33bc2,color:white
198 | style Question fill:#80bfff,stroke:#4da6ff
199 | style Identify fill:#ffa64d,stroke:#cc7a30
200 | style Skip fill:#4dbb5f,stroke:#36873f
201 | style Types fill:#ffe6cc,stroke:#ffa64d
202 |
203 |
204 | Identify components that require creative problem-solving or significant design decisions. For these components, flag them for the CREATIVE mode. Focus on architectural considerations, algorithm design needs, or UI/UX requirements that would benefit from structured design exploration.
205 |
206 | ## VERIFICATION
207 |
208 |
209 | graph TD
210 | V["✅ VERIFICATION CHECKLIST"] --> P["Plan addresses all requirements?"]
211 | V --> C["Components requiring creative phases identified?"]
212 | V --> S["Implementation steps clearly defined?"]
213 | V --> D["Dependencies and challenges documented?"]
214 |
215 | P & C & S & D --> Decision{"All Verified?"}
216 | Decision -->|"Yes"| Complete["Ready for next mode"]
217 | Decision -->|"No"| Fix["Complete missing items"]
218 |
219 | style V fill:#4dbbbb,stroke:#368787,color:white
220 | style Decision fill:#ffa64d,stroke:#cc7a30,color:white
221 | style Complete fill:#5fd94d,stroke:#3da336,color:white
222 | style Fix fill:#ff5555,stroke:#cc0000,color:white
223 |
224 |
225 | Before completing the planning phase, verify that all requirements are addressed in the plan, components requiring creative phases are identified, implementation steps are clearly defined, and dependencies and challenges are documented. Update tasks.md with the complete plan and recommend the appropriate next mode based on whether creative phases are required.
--------------------------------------------------------------------------------
/custom_modes/van_instructions.md:
--------------------------------------------------------------------------------
1 | # ADAPTIVE MEMORY-BASED ASSISTANT SYSTEM - ENTRY POINT
2 |
3 | > **TL;DR:** I am an AI assistant implementing a structured Memory Bank system that maintains context across sessions through specialized modes that handle different phases of the development process.
4 |
5 | ```mermaid
6 | graph TD
7 | %% Main Command Detection
8 | Start["User Command"] --> CommandDetect{"Command
Type?"}
9 |
10 | CommandDetect -->|"VAN"| VAN["VAN Mode"]
11 | CommandDetect -->|"PLAN"| Plan["PLAN Mode"]
12 | CommandDetect -->|"CREATIVE"| Creative["CREATIVE Mode"]
13 | CommandDetect -->|"IMPLEMENT"| Implement["IMPLEMENT Mode"]
14 | CommandDetect -->|"QA"| QA["QA Mode"]
15 |
16 | %% Immediate Response Node
17 | VAN --> VanResp["Respond: OK VAN"]
18 | Plan --> PlanResp["Respond: OK PLAN"]
19 | Creative --> CreativeResp["Respond: OK CREATIVE"]
20 | Implement --> ImplResp["Respond: OK IMPLEMENT"]
21 | QA --> QAResp["Respond: OK QA"]
22 |
23 | %% Memory Bank Check
24 | VanResp --> CheckMB_Van["Check Memory Bank
& tasks.md Status"]
25 | PlanResp --> CheckMB_Plan["Check Memory Bank
& tasks.md Status"]
26 | CreativeResp --> CheckMB_Creative["Check Memory Bank
& tasks.md Status"]
27 | ImplResp --> CheckMB_Impl["Check Memory Bank
& tasks.md Status"]
28 | QAResp --> CheckMB_QA["Check Memory Bank
& tasks.md Status"]
29 |
30 | %% Rule Loading
31 | CheckMB_Van --> LoadVan["Load Rule:
isolation_rules/visual-maps/van_mode_split/van-mode-map"]
32 | CheckMB_Plan --> LoadPlan["Load Rule:
isolation_rules/visual-maps/plan-mode-map"]
33 | CheckMB_Creative --> LoadCreative["Load Rule:
isolation_rules/visual-maps/creative-mode-map"]
34 | CheckMB_Impl --> LoadImpl["Load Rule:
isolation_rules/visual-maps/implement-mode-map"]
35 | CheckMB_QA --> LoadQA["Load Rule:
isolation_rules/visual-maps/qa-mode-map"]
36 |
37 | %% Rule Execution with Memory Bank Updates
38 | LoadVan --> ExecVan["Execute Process
in Rule"]
39 | LoadPlan --> ExecPlan["Execute Process
in Rule"]
40 | LoadCreative --> ExecCreative["Execute Process
in Rule"]
41 | LoadImpl --> ExecImpl["Execute Process
in Rule"]
42 | LoadQA --> ExecQA["Execute Process
in Rule"]
43 |
44 | %% Memory Bank Continuous Updates
45 | ExecVan --> UpdateMB_Van["Update Memory Bank
& tasks.md"]
46 | ExecPlan --> UpdateMB_Plan["Update Memory Bank
& tasks.md"]
47 | ExecCreative --> UpdateMB_Creative["Update Memory Bank
& tasks.md"]
48 | ExecImpl --> UpdateMB_Impl["Update Memory Bank
& tasks.md"]
49 | ExecQA --> UpdateMB_QA["Update Memory Bank
& tasks.md"]
50 |
51 | %% Verification with Memory Bank Checks
52 | UpdateMB_Van --> VerifyVan{"Process
Complete?"}
53 | UpdateMB_Plan --> VerifyPlan{"Process
Complete?"}
54 | UpdateMB_Creative --> VerifyCreative{"Process
Complete?"}
55 | UpdateMB_Impl --> VerifyImpl{"Process
Complete?"}
56 | UpdateMB_QA --> VerifyQA{"Process
Complete?"}
57 |
58 | %% Outcomes
59 | VerifyVan -->|"Yes"| CompleteVan["VAN Process
Complete"]
60 | VerifyVan -->|"No"| RetryVan["Resume
VAN Process"]
61 | RetryVan --- ReadMB_Van["Reference Memory Bank
for Context"]
62 | ReadMB_Van --> ExecVan
63 |
64 | VerifyPlan -->|"Yes"| CompletePlan["PLAN Process
Complete"]
65 | VerifyPlan -->|"No"| RetryPlan["Resume
PLAN Process"]
66 | RetryPlan --- ReadMB_Plan["Reference Memory Bank
for Context"]
67 | ReadMB_Plan --> ExecPlan
68 |
69 | VerifyCreative -->|"Yes"| CompleteCreative["CREATIVE Process
Complete"]
70 | VerifyCreative -->|"No"| RetryCreative["Resume
CREATIVE Process"]
71 | RetryCreative --- ReadMB_Creative["Reference Memory Bank
for Context"]
72 | ReadMB_Creative --> ExecCreative
73 |
74 | VerifyImpl -->|"Yes"| CompleteImpl["IMPLEMENT Process
Complete"]
75 | VerifyImpl -->|"No"| RetryImpl["Resume
IMPLEMENT Process"]
76 | RetryImpl --- ReadMB_Impl["Reference Memory Bank
for Context"]
77 | ReadMB_Impl --> ExecImpl
78 |
79 | VerifyQA -->|"Yes"| CompleteQA["QA Process
Complete"]
80 | VerifyQA -->|"No"| RetryQA["Resume
QA Process"]
81 | RetryQA --- ReadMB_QA["Reference Memory Bank
for Context"]
82 | ReadMB_QA --> ExecQA
83 |
84 | %% Final Memory Bank Updates at Completion
85 | CompleteVan --> FinalMB_Van["Update Memory Bank
with Completion Status"]
86 | CompletePlan --> FinalMB_Plan["Update Memory Bank
with Completion Status"]
87 | CompleteCreative --> FinalMB_Creative["Update Memory Bank
with Completion Status"]
88 | CompleteImpl --> FinalMB_Impl["Update Memory Bank
with Completion Status"]
89 | CompleteQA --> FinalMB_QA["Update Memory Bank
with Completion Status"]
90 |
91 | %% Mode Transitions with Memory Bank Preservation
92 | FinalMB_Van -->|"Level 1"| TransToImpl["→ IMPLEMENT Mode"]
93 | FinalMB_Van -->|"Level 2-4"| TransToPlan["→ PLAN Mode"]
94 | FinalMB_Plan --> TransToCreative["→ CREATIVE Mode"]
95 | FinalMB_Creative --> TransToImpl2["→ IMPLEMENT Mode"]
96 | FinalMB_Impl --> TransToQA["→ QA Mode"]
97 |
98 | %% Memory Bank System
99 | MemoryBank["MEMORY BANK
CENTRAL SYSTEM"] -.-> tasks["tasks.md
Source of Truth"]
100 | MemoryBank -.-> projBrief["projectbrief.md
Foundation"]
101 | MemoryBank -.-> active["activeContext.md
Current Focus"]
102 | MemoryBank -.-> progress["progress.md
Implementation Status"]
103 |
104 | CheckMB_Van & CheckMB_Plan & CheckMB_Creative & CheckMB_Impl & CheckMB_QA -.-> MemoryBank
105 | UpdateMB_Van & UpdateMB_Plan & UpdateMB_Creative & UpdateMB_Impl & UpdateMB_QA -.-> MemoryBank
106 | ReadMB_Van & ReadMB_Plan & ReadMB_Creative & ReadMB_Impl & ReadMB_QA -.-> MemoryBank
107 | FinalMB_Van & FinalMB_Plan & FinalMB_Creative & FinalMB_Impl & FinalMB_QA -.-> MemoryBank
108 |
109 | %% Error Handling
110 | Error["⚠️ ERROR
DETECTION"] -->|"Todo App"| BlockCreative["⛔ BLOCK
creative-mode-map"]
111 | Error -->|"Multiple Rules"| BlockMulti["⛔ BLOCK
Multiple Rules"]
112 | Error -->|"Rule Loading"| UseCorrectFn["✓ Use fetch_rules
NOT read_file"]
113 |
114 | %% Styling
115 | style Start fill:#f8d486,stroke:#e8b84d
116 | style CommandDetect fill:#f8d486,stroke:#e8b84d
117 | style VAN fill:#ccf,stroke:#333
118 | style Plan fill:#cfc,stroke:#333
119 | style Creative fill:#fcf,stroke:#333
120 | style Implement fill:#cff,stroke:#333
121 | style QA fill:#fcc,stroke:#333
122 |
123 | style VanResp fill:#d9e6ff,stroke:#99ccff
124 | style PlanResp fill:#d9e6ff,stroke:#99ccff
125 | style CreativeResp fill:#d9e6ff,stroke:#99ccff
126 | style ImplResp fill:#d9e6ff,stroke:#99ccff
127 | style QAResp fill:#d9e6ff,stroke:#99ccff
128 |
129 | style LoadVan fill:#a3dded,stroke:#4db8db
130 | style LoadPlan fill:#a3dded,stroke:#4db8db
131 | style LoadCreative fill:#a3dded,stroke:#4db8db
132 | style LoadImpl fill:#a3dded,stroke:#4db8db
133 | style LoadQA fill:#a3dded,stroke:#4db8db
134 |
135 | style ExecVan fill:#a3e0ae,stroke:#4dbb5f
136 | style ExecPlan fill:#a3e0ae,stroke:#4dbb5f
137 | style ExecCreative fill:#a3e0ae,stroke:#4dbb5f
138 | style ExecImpl fill:#a3e0ae,stroke:#4dbb5f
139 | style ExecQA fill:#a3e0ae,stroke:#4dbb5f
140 |
141 | style VerifyVan fill:#e699d9,stroke:#d94dbb
142 | style VerifyPlan fill:#e699d9,stroke:#d94dbb
143 | style VerifyCreative fill:#e699d9,stroke:#d94dbb
144 | style VerifyImpl fill:#e699d9,stroke:#d94dbb
145 | style VerifyQA fill:#e699d9,stroke:#d94dbb
146 |
147 | style CompleteVan fill:#8cff8c,stroke:#4dbb5f
148 | style CompletePlan fill:#8cff8c,stroke:#4dbb5f
149 | style CompleteCreative fill:#8cff8c,stroke:#4dbb5f
150 | style CompleteImpl fill:#8cff8c,stroke:#4dbb5f
151 | style CompleteQA fill:#8cff8c,stroke:#4dbb5f
152 |
153 | style MemoryBank fill:#f9d77e,stroke:#d9b95c,stroke-width:2px
154 | style tasks fill:#f9d77e,stroke:#d9b95c
155 | style projBrief fill:#f9d77e,stroke:#d9b95c
156 | style active fill:#f9d77e,stroke:#d9b95c
157 | style progress fill:#f9d77e,stroke:#d9b95c
158 |
159 | style Error fill:#ff5555,stroke:#cc0000,color:white,stroke-width:2px
160 | style BlockCreative fill:#ffaaaa,stroke:#ff8080
161 | style BlockMulti fill:#ffaaaa,stroke:#ff8080
162 | style UseCorrectFn fill:#8cff8c,stroke:#4dbb5f
163 | ```
164 |
165 | ## MEMORY BANK FILE STRUCTURE
166 |
167 | ```mermaid
168 | flowchart TD
169 | PB([projectbrief.md]) --> PC([productContext.md])
170 | PB --> SP([systemPatterns.md])
171 | PB --> TC([techContext.md])
172 |
173 | PC & SP & TC --> AC([activeContext.md])
174 |
175 | AC --> P([progress.md])
176 | AC --> Tasks([tasks.md])
177 |
178 | style PB fill:#f9d77e,stroke:#d9b95c
179 | style PC & SP & TC fill:#a8d5ff,stroke:#88b5e0
180 | style AC fill:#c5e8b7,stroke:#a5c897
181 | style P fill:#f4b8c4,stroke:#d498a4
182 | style Tasks fill:#f4b8c4,stroke:#d498a4,stroke-width:3px
183 | ```
184 |
185 | ## VERIFICATION COMMITMENT
186 |
187 | ```
188 | ┌─────────────────────────────────────────────────────┐
189 | │ I WILL follow the appropriate visual process map │
190 | │ I WILL run all verification checkpoints │
191 | │ I WILL maintain tasks.md as the single source of │
192 | │ truth for all task tracking │
193 | └─────────────────────────────────────────────────────┘
194 | ```
--------------------------------------------------------------------------------
/optimization-journey/00-introduction.md:
--------------------------------------------------------------------------------
1 | # MEMORY BANK SYSTEM: INTRODUCTION
2 |
3 | > **TL;DR:** The Memory Bank System evolved through nine optimization rounds to address verbosity, redundancy, maintenance challenges, process scaling, decision quality, creative phase implementation, and context window optimization. The latest improvement implements a Visual Navigation Layer with selective document loading that dramatically reduces context window usage, allowing the AI more working space while maintaining process integrity.
4 |
5 | ## 🎯 SYSTEM PURPOSE & INITIAL STATE
6 |
7 | The Memory Bank System was designed to overcome a fundamental limitation of LLMs: their inability to retain context between sessions. The system creates a structured documentation architecture that serves as the AI's "memory" across interactions, consisting of:
8 |
9 | - Core documentation files (projectbrief.md, productContext.md, etc.)
10 | - Structured workflow with verification steps
11 | - Command execution protocols
12 | - Documentation creation and maintenance rules
13 |
14 | While effective, the initial system had several opportunities for optimization:
15 | - Verbose documentation requiring significant context window space
16 | - Rigid structures that were sometimes cumbersome
17 | - Redundancies across multiple files
18 | - Heavy maintenance overhead
--------------------------------------------------------------------------------
/optimization-journey/01-efficiency-and-clarity.md:
--------------------------------------------------------------------------------
1 | # 🔄 OPTIMIZATION ROUND 1: EFFICIENCY & CLARITY
2 |
3 | ## 🚨 Key Issues Identified
4 | - Documentation too verbose, consuming excessive context window space
5 | - Visual hierarchy lacking clear indication of importance
6 | - Abstract explanations instead of concrete examples
7 | - Inconsistent reference patterns
8 |
9 | ## ✅ Key Improvements
10 | 1. **Priority-Based Content Organization**
11 | - Added "TL;DR" sections at the top of each file
12 | - Placed mission-critical instructions at the beginning
13 | - Implemented progressive disclosure (essentials first, details later)
14 |
15 | 2. **Visual Hierarchy Improvements**
16 | - Used consistent emoji markers for different content types (🚨, ✅, ❌, 📋, ✓)
17 | - Created tables for reference information
18 | - Added visual separation between different severity levels
19 |
20 | 3. **Content Optimization**
21 | - Removed redundancies across files
22 | - Replaced abstract explanations with concrete examples
23 | - Trimmed verbose explanations while preserving meaning
24 | - Converted passive voice to active instructions
25 |
26 | 4. **Reference System Refinements**
27 | - Created standardized reference syntax with brief context
28 | - Added clear indications of when to consult external files
29 | - Grouped related references together
30 |
31 | 5. **Embedded Verification Mechanisms**
32 | - Added "checkpoint" prompts at critical junctions
33 | - Implemented lightweight verification steps
34 | - Created simple inline checklists
--------------------------------------------------------------------------------
/optimization-journey/02-system-self-assessment.md:
--------------------------------------------------------------------------------
1 | # 🔄 OPTIMIZATION ROUND 2: SYSTEM SELF-ASSESSMENT
2 |
3 | ## 🚨 Key Issues Identified
4 | 1. Inconsistent task status updates between .cursorrules and activeContext.md
5 | 2. Section tracking list not consistently updated
6 | 3. Example files not being explicitly referenced
7 | 4. Context limitations when working with multiple files
8 |
9 | ## ✅ Key Improvements
10 | 1. **Task Status Tracking Improvements**
11 | - Added prominent 🔄 SYNC command template
12 | - Created explicit moments for synchronization
13 |
14 | 2. **Section Progress Tracking Improvements**
15 | - Added 🔄 SECTION UPDATE template
16 | - Created explicit moment to update the section tracking list
17 |
18 | 3. **Reference Triggers Enhancement**
19 | - Added standardized 📚 REFERENCE CHECK format
20 | - Improved visual indicators for references
21 |
22 | 4. **Context Window Optimization**
23 | - Created "Minimal Mode" for constrained contexts
24 | - Streamlined essential instructions
25 |
26 | 5. **Section Checkpoint System**
27 | - Added structured checkpoints at section boundaries
28 | - Created clear verification steps for section completion
--------------------------------------------------------------------------------
/optimization-journey/03-redundancy-elimination.md:
--------------------------------------------------------------------------------
1 | # 🔄 OPTIMIZATION ROUND 3: REDUNDANCY ELIMINATION
2 |
3 | ## 🚨 Key Issues Identified
4 | 1. Task statuses duplicated across multiple files (.cursorrules, activeContext.md, progress.md)
5 | 2. Implementation details duplicated between files
6 | 3. Recent changes information duplicated
7 | 4. Maintenance overhead due to synchronizing information across files
8 |
9 | ## ✅ Key Improvements
10 | 1. **Centralized Task Registry**
11 | - Created tasks.md as single source of truth for tasks
12 | - Updated other files to reference instead of duplicate
13 | - Simplified task tracking to single-file updates
14 |
15 | 2. **Domain Separation**
16 | - Established clear boundaries for what belongs in each file
17 | - Prevented overlapping content between files
18 | - Created reference templates for each domain
19 |
20 | 3. **Cross-Reference System**
21 | - Implemented standardized cross-reference syntax
22 | - Replaced duplication with references
23 | - Created guidelines for maintaining references
--------------------------------------------------------------------------------
/optimization-journey/04-single-source-of-truth.md:
--------------------------------------------------------------------------------
1 | # 🔄 OPTIMIZATION ROUND 4: SINGLE SOURCE OF TRUTH IMPLEMENTATION
2 |
3 | ## 🚨 Key Issues Identified
4 | 1. Despite introducing tasks.md, the system still instructed updating task status in multiple files
5 | 2. Dual-file update process (both .cursorrules AND activeContext.md) created synchronization errors
6 | 3. Complex command verification with nested if-statements caused terminal crashes
7 | 4. Inconsistent documentation references confused task tracking
8 |
9 | ## ✅ Key Improvements
10 | 1. **True Single Source of Truth**
11 | - Designated tasks.md as the ONLY file for task status tracking
12 | - Removed all instructions to update task status in .cursorrules
13 | - Modified all files to reference but not duplicate task information
14 | - Added explicit verification for tasks.md existence
15 |
16 | 2. **Command Execution Safety**
17 | - Simplified file verification processes to avoid terminal crashes
18 | - Removed nested if-statements in Windows batch commands
19 | - Added safer versions of common commands
20 | - Trusted the AI's existing knowledge of file operations
21 |
22 | 3. **Documentation Role Clarification**
23 | - .cursorrules: Project patterns and intelligence only
24 | - activeContext.md: Implementation details and current focus
25 | - progress.md: Overall progress and references to tasks
26 | - tasks.md: All task status tracking
27 |
28 | 4. **Technical Fixes**
29 | - Corrected MDC reference links in main.mdc
30 | - Fixed verification checklist for single source approach
31 | - Enhanced platform-specific documentation
32 | - Simplified real-time update formats
--------------------------------------------------------------------------------
/optimization-journey/05-adaptive-complexity-model.md:
--------------------------------------------------------------------------------
1 | # 🔄 OPTIMIZATION ROUND 5: ADAPTIVE COMPLEXITY MODEL
2 |
3 | ## 🚨 Key Issues Identified
4 | 1. One-size-fits-all process was too rigid for varying task complexities
5 | 2. Bug fixes and simple tasks required excessive documentation
6 | 3. Complex tasks sometimes received insufficient architectural attention
7 | 4. Documentation burden sometimes slowed problem-solving
8 | 5. Context window usage inefficient for simple tasks
9 | 6. Creative work phases interrupted by excessive task tracking
10 |
11 | ## ✅ Key Improvements
12 | 1. **Adaptive Complexity Levels**
13 | - Implemented four complexity levels (1-4) from quick bug fixes to complex systems
14 | - Scaled process rigor to match task requirements
15 | - Created level-specific workflows and documentation expectations
16 |
17 | 2. **Level-Appropriate Task Tracking**
18 | - Defined task update frequency by complexity level
19 | - Simplified tracking for Level 1 (bug fixes)
20 | - Enhanced tracking for Level 4 (complex systems)
21 |
22 | 3. **Creative Phase Handling**
23 | - Added explicit creative phase markers
24 | - Created creative checkpoint system
25 | - Established process for returning to task tracking after creative work
26 |
27 | 4. **Process Scaling Rules**
28 | - Defined criteria for complexity level determination
29 | - Created guidelines for when to escalate complexity level
30 | - Implemented level-specific verification requirements
31 |
32 | 5. **Streamlined Level 1 Process**
33 | - Created minimal workflow for quick bug fixes
34 | - Reduced documentation burden for simple tasks
35 | - Maintained essential task tracking
36 |
37 | 6. **Enhanced Level 4 Process**
38 | - Added architectural considerations
39 | - Created comprehensive planning requirements
40 | - Implemented detailed verification checkpoints
--------------------------------------------------------------------------------
/optimization-journey/06-self-assessment-recommendations.md:
--------------------------------------------------------------------------------
1 | # 🔄 OPTIMIZATION ROUND 6: RECOMMENDATIONS FROM SELF-ASSESSMENT
2 |
3 | Based on field testing of the Adaptive Memory Bank System across different complexity levels, several refinements were identified. The system successfully scaled between complexity levels, maintained the single source of truth, and provided appropriate verification processes. However, self-assessment revealed opportunities for enhancement.
4 |
5 | ## 🚨 Areas for Improvement
6 | 1. Creative phase handling not explicitly marked during implementation
7 | 2. Reference checking format not consistently used
8 | 3. Implementation notes sometimes lacking sufficient detail
9 | 4. Level 1 process could be further streamlined
10 | 5. Templates for common implementation patterns needed
11 |
12 | ## ✅ Recommended Enhancements
13 |
14 | 1. **Enhanced Creative Phase Handling**
15 | - Add more prominent reminders about creative phase markers
16 | - Include creative phase examples in workflow.mdc
17 | - Create visual indicators for entering/exiting creative phases
18 | - Add creative checkpoint templates
19 |
20 | 2. **Simplified Reference Checking**
21 | - Create level-specific reference check templates
22 | - Add simplified format for Level 1 tasks
23 | - Include reference check reminders in each section
24 | - Automate reference check integration
25 |
26 | 3. **Implementation Documentation Guidelines**
27 | - Provide clear examples of implementation documentation at each level
28 | - Create templates for common implementation patterns
29 | - Add level-specific implementation detail requirements
30 | - Include technology-specific documentation templates
31 |
32 | 4. **Further Level 1 Streamlining**
33 | - Create ultra-lightweight process for trivial bug fixes
34 | - Reduce documentation requirements for simple fixes
35 | - Implement one-step verification for Level 1 tasks
36 | - Provide specialized templates for common bugs
37 |
38 | 5. **Implementation Pattern Templates**
39 | - Create templates for common implementation patterns
40 | - Add specialized templates for web development, API design, etc.
41 | - Include reusable code pattern documentation
42 | - Develop framework-specific templates
--------------------------------------------------------------------------------
/optimization-journey/07-structured-creative-thinking.md:
--------------------------------------------------------------------------------
1 | # 🔄 OPTIMIZATION ROUND 7: STRUCTURED CREATIVE THINKING
2 |
3 | Despite previous improvements to creative phase handling, real-world usage revealed that creative phases were often skipped during Level 3-4 tasks, leading to premature implementation without sufficient design exploration. Inspired by the "think" tool concept, which provides dedicated thinking space for complex problem-solving, we enhanced the creative phase system to ensure systematic thinking for complex decisions.
4 |
5 | ## 🚨 Key Issues Identified
6 | 1. **Missing Integration in Task Flow**: Creative phases were documented but not fully integrated into the task workflow
7 | 2. **Optional Rather Than Mandatory**: Creative phases were treated as optional rather than required for Level 3-4 tasks
8 | 3. **Implementation Bias**: Tendency to jump straight to coding without thorough design exploration
9 | 4. **Insufficient Verification**: No explicit checks for creative phase usage in validation steps
10 | 5. **Process Compartmentalization**: Creative phases treated as separate from the main workflow rather than integral
11 |
12 | ## ✅ Key Improvements
13 | 1. **Mandatory Creative Phases for Level 3-4 Tasks**
14 | - Made creative phases required, not optional, for complex tasks
15 | - Added explicit directive in Global Rules stating "Creative phases are MANDATORY for all major design/architecture decisions in Level 3-4 tasks"
16 | - Created creative-phase-triggers.mdc with clear guidelines on when creative phases must be used
17 |
18 | 2. **Structured Thinking Framework**
19 | - Enhanced creative phase format with systematic problem breakdown
20 | - Added verification steps in creative checkpoints
21 | - Implemented systematic verification against requirements for each option
22 | - Added risk assessment and edge case identification
23 |
24 | 3. **Task Planning Integration**
25 | - Updated TASK PLANNING section to require identification of components needing creative phases
26 | - Modified Level 3-4 workflows to explicitly include creative phase planning
27 | - Added creative phase placeholders in task templates for complex components
28 |
29 | 4. **Enhanced Verification System**
30 | - Added creative phase verification to all checkpoints
31 | - Updated TOP 5 MOST COMMON FAILURES to include "Missing creative phases"
32 | - Enhanced WORKFLOW VERIFICATION to check for creative phase usage
33 | - Added verification for creative phase outputs in documentation
34 |
35 | 5. **Detailed Domain-Specific Templates**
36 | - Created specialized templates for Algorithm Design, UI/UX Design, and Architecture Planning
37 | - Added domain-specific verification steps for each creative phase type
38 | - Implemented systematic alternative analysis with pros/cons comparison
39 | - Added performance, security, and scalability considerations to templates
--------------------------------------------------------------------------------
/optimization-journey/08-creative-phase-enforcement.md:
--------------------------------------------------------------------------------
1 | # 🔄 OPTIMIZATION ROUND 8: CREATIVE PHASE ENFORCEMENT & METRICS
2 |
3 | Despite previous improvements to creative phases, real-world feedback revealed that creative phases were sometimes mentally performed but not properly documented, allowing implementation to proceed without formal design exploration. This optimization round creates strict enforcement mechanisms and objective quality metrics for creative phases.
4 |
5 | ## 🚨 Key Issues Identified
6 | 1. **Lack of Explicit Enforcement**: Creative phases could be skipped despite being mandatory
7 | 2. **Process Skipping**: Implementation could proceed without proper creative phase documentation
8 | 3. **Missing Verification Gateway**: No strict checkpoint blocked implementation without creative phases
9 | 4. **Documentation Gap**: Design decisions were mentally performed but not formally documented
10 | 5. **Quality Variation**: No objective metrics to evaluate creative phase quality
11 | 6. **Insufficient Integration**: Creative phases not explicitly integrated into the standard workflow
12 |
13 | ## ✅ Key Improvements
14 | 1. **Hard Gateway Implementation**
15 | - Created new creative-phase-enforcement.mdc with strict gateway mechanisms
16 | - Implemented hard implementation blocking without completed creative phases
17 | - Added explicit verification checklist for creative phase completeness
18 | - Created formal completion confirmation for creative phases
19 |
20 | 2. **Workflow Structure Enhancement**
21 | - Updated workflow.mdc to include creative phases as explicit workflow step
22 | - Added formal transition markers for creative phases
23 | - Integrated creative phases as standard part of Level 3-4 workflows
24 | - Created dedicated creative phase section in tracking lists
25 |
26 | 3. **Enhanced Checkpoint System**
27 | - Added dedicated pre-implementation creative phase checkpoint
28 | - Created verification points that block implementation without creative phases
29 | - Added creative phase checks to implementation step checkpoints
30 | - Enhanced implementation reminders to include creative phase requirements
31 |
32 | 4. **Quality Metrics Framework**
33 | - Created new creative-phase-metrics.mdc with objective evaluation criteria
34 | - Implemented weighted decision matrices for option comparison
35 | - Added domain-specific evaluation criteria for different creative phase types
36 | - Developed risk assessment framework for design decisions
37 | - Created historical pattern comparison framework
38 |
39 | 5. **Structured Evaluation Tools**
40 | - Implemented decision quality scoring system with minimum thresholds
41 | - Created ready-to-use criteria sets for common architectural decisions
42 | - Added verification metrics for solution validation
43 | - Implemented standardized decision documentation templates
--------------------------------------------------------------------------------
/optimization-journey/09-context-optimization.md:
--------------------------------------------------------------------------------
1 | # 🔄 OPTIMIZATION ROUND 9: CONTEXT OPTIMIZATION THROUGH VISUAL NAVIGATION
2 |
3 | Despite the improvements in creative phase enforcement and metrics, real-world usage revealed significant context window inefficiencies. The system was loading numerous documentation files simultaneously, consuming excessive context space and leaving insufficient room for the AI to process complex tasks. This optimization round introduces a Visual Navigation Layer with selective document loading to dramatically improve context window efficiency.
4 |
5 | ## 🚨 Key Issues Identified
6 | 1. **Context Window Overconsumption**: Too many documents loaded simultaneously, wasting valuable context space
7 | 2. **Cognitive Load Inefficiency**: Text-based linear processing requiring sequential reading of entire documents
8 | 3. **Navigation Confusion**: Unclear guidance on which documents to reference at each process stage
9 | 4. **Redundant Information Loading**: Loading entire documents when only specific sections were needed
10 | 5. **Process State Ambiguity**: Difficulty tracking current phase in the process without reloading status information
11 | 6. **Implementation Barrier**: Context limitations restricting implementation capacity for complex tasks
12 |
13 | ## ✅ Key Improvements
14 | 1. **Selective Document Loading Protocol**
15 | - Implemented phase-specific document lists that load only relevant files
16 | - Created "just-in-time" document reference system for specialized information
17 | - Developed document context management commands for each phase transition
18 | - Reduced context window usage by ~60% through selective loading
19 |
20 | 2. **Visual Process State Tracking**
21 | - Created persistent visual process state indicator requiring minimal context space
22 | - Implemented compact visual markers for phase transitions
23 | - Developed standardized emoji-based visual hierarchy for information importance
24 | - Reduced cognitive load through pattern recognition (significantly faster than text processing)
25 |
26 | 3. **Pattern-Based Information Processing**
27 | - Implemented standardized visual patterns for different information types
28 | - Created consistent visual markers for process stages
29 | - Developed visual checkpoints that require minimal context space
30 | - Enhanced information density through visual hierarchies
31 |
32 | 4. **Dynamic Context Adjustment System**
33 | - Created "Minimal Mode" for severely constrained contexts
34 | - Implemented complexity-based document loading (fewer documents for simpler tasks)
35 | - Developed context window optimization commands for manual adjustments
36 | - Added context usage monitoring and recommendations
37 |
38 | 5. **Context-Optimized Creative Phases**
39 | - Redesigned creative phase markers to maximize information density
40 | - Implemented standardized creative checkpoint format requiring minimal context
41 | - Created visual decision matrices with optimized space usage
42 | - Developed compact option comparison formats
43 |
44 | 6. **Task Tracking Optimization**
45 | - Reinforced tasks.md as single source of truth to eliminate redundant loading
46 | - Implemented compact task tracking format with visual markers
47 | - Created standardized status indicators requiring minimal context space
48 | - Developed reference-based rather than duplication-based progress tracking
49 |
50 | ## 📊 Measured Impact
51 | - **Context Efficiency**: Reduced context window usage by approximately 60%
52 | - **Information Processing**: Visual system processes information significantly faster than text
53 | - **Navigation Efficiency**: Reduced time spent searching for relevant documentation by 75%
54 | - **Cognitive Load**: Significantly reduced working memory requirements through visualization
55 | - **Implementation Capacity**: Increased available context space for complex implementation tasks
--------------------------------------------------------------------------------
/optimization-journey/10-current-system-state.md:
--------------------------------------------------------------------------------
1 | # 📚 CURRENT SYSTEM STATE
2 |
3 | The Memory Bank System now features:
4 |
5 | 1. **Context-Optimized Visual Navigation**
6 | - Selective document loading based on current phase
7 | - Visual process maps requiring minimal context space
8 | - Phase-specific document lists to prevent context overconsumption
9 | - Pattern-based information processing for cognitive efficiency
10 |
11 | 2. **7 Core Files with Optimal Loading**
12 | - projectbrief.md - Loaded selectively at initialization
13 | - productContext.md - Referenced only when needed
14 | - activeContext.md - Loaded during current task focus
15 | - systemPatterns.md - Referenced for architectural decisions
16 | - techContext.md - Loaded for technology-specific guidance
17 | - progress.md - Referenced for status updates
18 | - tasks.md - Single source of truth, consistently maintained
19 |
20 | 3. **Context-Efficient Creative Phase System**
21 | - Visual markers requiring minimal context space
22 | - Standardized format with optimized information density
23 | - Compact decision matrices for option evaluation
24 | - Visual enforcement requiring minimal context overhead
25 |
26 | 4. **Context-Aware Process Enforcement**
27 | - Visual checkpoints consuming minimal context space
28 | - Compact violation detection and correction mechanisms
29 | - Pattern-based verification for efficient processing
30 | - Reference-based guidance rather than duplication
31 |
32 | 5. **Dynamic Context Management**
33 | - Real-time context window usage optimization
34 | - Minimal mode for constrained operations
35 | - Automated document unloading for non-essential information
36 | - Visual references replacing full document loading
--------------------------------------------------------------------------------
/optimization-journey/11-key-lessons.md:
--------------------------------------------------------------------------------
1 | # 📝 KEY LESSONS LEARNED
2 |
3 | 1. **Context Efficiency is Mission-Critical**
4 | - Context window optimization directly impacts AI performance
5 | - Selective document loading preserves context for complex processing
6 | - Visual patterns require significantly less context space than text
7 | - Single source of truth eliminates redundant information loading
8 |
9 | 2. **Visual Processing Dramatically Reduces Cognitive Load**
10 | - Visual information processing is ~60,000× faster than text
11 | - Pattern recognition enables rapid process state awareness
12 | - Visual hierarchies improve information density
13 | - Standardized visual markers reduce context requirements
14 |
15 | 3. **Selective Loading Beats Comprehensive Documentation**
16 | - Loading only phase-relevant documents preserves context space
17 | - Just-in-time reference loading prevents context overconsumption
18 | - Complexity-based document loading scales efficiently
19 | - Reference-based systems outperform duplication-based systems
20 |
21 | 4. **Process Enforcement Requires Minimal Context**
22 | - Visual checkpoints provide efficient verification
23 | - Compact process state tracking preserves context
24 | - Pattern-based violation detection requires minimal overhead
25 | - Visual alerts communicate efficiently without verbose explanation
26 |
27 | 5. **Continuous Context Optimization Drives Performance**
28 | - Regular context window assessments reveal optimization opportunities
29 | - Context monitoring enables dynamic adjustments
30 | - Minimal mode provides fallback for extreme constraints
31 | - Context-aware process scaling adapts to available resources
--------------------------------------------------------------------------------
/optimization-journey/11-methodological-integration.md:
--------------------------------------------------------------------------------
1 | # 🔄 METHODOLOGICAL INTEGRATION
2 |
3 | Optimization Round 13 focused on deepening the system's methodological foundations while maintaining strict isolation principles:
4 |
5 | 1. **Claude "Think" Tool Integration**
6 | - Aligned CREATIVE mode with Claude's systematic problem-solving approach
7 | - Implemented structured phases for problem decomposition
8 | - Created visual process maps for methodology visualization
9 | - Established clear parallels between methodologies for consistency
10 |
11 | 2. **Mode-Specific Rule Isolation**
12 | - Eliminated global rule dependencies for cleaner architecture
13 | - Implemented strict mode-based rule containment
14 | - Preserved global rule space for future extensibility
15 | - Enhanced system modularity through isolation
16 |
17 | 3. **Visual Process Mapping**
18 | - Developed comprehensive mode-specific process maps
19 | - Created hierarchical visualization of decision points
20 | - Implemented cross-mode transition guidelines
21 | - Established clear entry points and flow patterns
22 |
23 | 4. **Architectural Documentation**
24 | - Enhanced documentation clarity through visual aids
25 | - Created explicit methodology comparisons
26 | - Documented architectural decisions and rationales
27 | - Established clear upgrade paths for users
28 |
29 | 5. **Quality Assurance Integration**
30 | - Implemented mode-specific QA checkpoints
31 | - Created validation frameworks for each mode
32 | - Established clear quality metrics and standards
33 | - Developed systematic verification procedures
34 |
35 | This optimization round represents a significant maturation of the Memory Bank system, establishing stronger methodological foundations while maintaining strict isolation principles. By aligning with established methodologies like Claude's "Think" tool while preserving modularity through mode-specific rules, the system achieves both theoretical rigor and practical flexibility. The introduction of comprehensive visual process maps further enhances usability while maintaining the system's commitment to context efficiency.
--------------------------------------------------------------------------------
/optimization-journey/12-future-directions.md:
--------------------------------------------------------------------------------
1 | # 🚀 FUTURE DIRECTIONS
2 |
3 | Based on the context optimization achievements of Optimization Round 9, future enhancements could include:
4 |
5 | 1. **Context-Aware Compression Techniques**
6 | - Develop information compression algorithms for documentation
7 | - Create context-sensitive abbreviation systems
8 | - Implement dynamic detail levels based on context availability
9 | - Design ultra-compact reference formats for constrained environments
10 |
11 | 2. **Advanced Pattern Recognition System**
12 | - Improve visual pattern efficiency through standardization
13 | - Develop hierarchical visual markers with nested information
14 | - Create pattern-based information retrieval system
15 | - Implement context-sensitive pattern adaptation
16 |
17 | 3. **Context Prediction and Preloading**
18 | - Develop predictive loading of likely-needed documents
19 | - Create smart unloading of no-longer-relevant information
20 | - Implement context history for efficient backtracking
21 | - Design working memory optimization for complex tasks
22 |
23 | 4. **Minimal-Footprint Creative Thinking**
24 | - Develop ultra-compact creative phase formats
25 | - Create visual decision frameworks with minimal context requirements
26 | - Implement progressive disclosure for complex creative phases
27 | - Design context-aware creative technique selection
28 |
29 | 5. **Cross-Reference Optimization**
30 | - Create hyperlink-like reference system for efficient navigation
31 | - Develop context-aware reference resolution
32 | - Implement reference caching for frequent lookups
33 | - Design minimal-context cross-document navigation system
34 |
35 | The Memory Bank System with Visual Navigation represents a significant breakthrough in context window optimization, enabling the AI to operate more efficiently while maintaining comprehensive process guidance. By dramatically reducing context consumption through selective loading and visual patterns, the system provides more available working space for the AI to process complex tasks, making previously context-limited operations now possible and efficient.
--------------------------------------------------------------------------------
/optimization-journey/12-key-lessons.md:
--------------------------------------------------------------------------------
1 | # 📝 KEY LESSONS LEARNED
2 |
3 | 1. **Methodological Integration Enhances Structure**
4 | - Claude's "Think" tool methodology provides robust foundation for CREATIVE mode
5 | - Visual process maps significantly improve workflow understanding
6 | - Mode-specific isolation enables cleaner architecture
7 | - Systematic approach leads to better design decisions
8 |
9 | 2. **Graph-Based Architecture Optimizes Flow**
10 | - Directed graphs enable efficient decision tree navigation
11 | - Contextual relationships model development phases clearly
12 | - Resource optimization through node-specific loading
13 | - Parallel processing opportunities become more apparent
14 |
15 | 3. **Just-In-Time Loading Maximizes Efficiency**
16 | - Mode-specific rule loading preserves context space
17 | - Complexity-based document loading scales effectively
18 | - Dynamic rule adaptation based on project needs
19 | - Reduced context consumption through selective loading
20 |
21 | 4. **Visual Processing Dramatically Improves Understanding**
22 | - Mode-specific process maps provide clear guidance
23 | - Visual decision trees reduce cognitive load
24 | - Checkpoint visualization enables progress tracking
25 | - Pattern-based violation detection requires minimal overhead
26 |
27 | 5. **Isolation Principles Enable Scalability**
28 | - Mode-specific containment reduces interference
29 | - Clean separation of concerns through specialized modes
30 | - Preserved global rule space for future extensibility
31 | - Enhanced modularity through strict isolation
--------------------------------------------------------------------------------
/optimization-journey/13-future-directions.md:
--------------------------------------------------------------------------------
1 | # 🚀 FUTURE DIRECTIONS
2 |
3 | Building on the methodological integration and isolation-focused architecture, future enhancements will focus on:
4 |
5 | 1. **Enhanced JIT Rule System**
6 | - Further optimize rule loading efficiency
7 | - Implement smarter context utilization
8 | - Develop faster response times
9 | - Create dynamic rule complexity adaptation
10 |
11 | 2. **Team Collaboration Features**
12 | - Enable multi-user shared context
13 | - Coordinate mode transitions across teams
14 | - Implement shared memory bank states
15 | - Create collaborative decision tracking
16 |
17 | 3. **Cross-Project Intelligence**
18 | - Maintain context across different projects
19 | - Enable knowledge transfer between codebases
20 | - Implement project pattern recognition
21 | - Create reusable decision templates
22 |
23 | 4. **Analytics and Insights**
24 | - Track development patterns and mode usage
25 | - Analyze project progression metrics
26 | - Generate optimization recommendations
27 | - Monitor context efficiency trends
28 |
29 | 5. **Version Control Integration**
30 | - Connect documentation with code history
31 | - Track decision evolution over time
32 | - Enable memory bank state versioning
33 | - Create decision-aware branching strategies
34 |
35 | The Memory Bank system will continue evolving as a personal hobby project, with a focus on creating enjoyable, powerful tools for structured development. Future improvements will maintain the core 4-level complexity scale while expanding capabilities through:
36 |
37 | - Deeper integration with Claude's evolving capabilities
38 | - Enhanced visual process mapping
39 | - Expanded mode-specific optimizations
40 | - Improved cross-mode state management
41 | - Advanced technical validation features
42 |
43 | This development path reflects a commitment to balancing power and complexity while preserving the system's fundamental principles of efficiency, clarity, and systematic development.
--------------------------------------------------------------------------------
/optimization-journey/13-methodological-integration.md:
--------------------------------------------------------------------------------
1 | # 🔄 METHODOLOGICAL INTEGRATION
2 |
3 | Optimization Round 13 focused on deepening the system's methodological foundations while maintaining strict isolation principles:
4 |
5 | 1. **Claude "Think" Tool Integration**
6 | - Aligned CREATIVE mode with Claude's systematic problem-solving approach
7 | - Implemented structured phases for problem decomposition
8 | - Created visual process maps for methodology visualization
9 | - Established clear parallels between methodologies for consistency
10 |
11 | 2. **Mode-Specific Rule Isolation**
12 | - Eliminated global rule dependencies for cleaner architecture
13 | - Implemented strict mode-based rule containment
14 | - Preserved global rule space for future extensibility
15 | - Enhanced system modularity through isolation
16 |
17 | 3. **Visual Process Mapping**
18 | - Developed comprehensive mode-specific process maps
19 | - Created hierarchical visualization of decision points
20 | - Implemented cross-mode transition guidelines
21 | - Established clear entry points and flow patterns
22 |
23 | 4. **Architectural Documentation**
24 | - Enhanced documentation clarity through visual aids
25 | - Created explicit methodology comparisons
26 | - Documented architectural decisions and rationales
27 | - Established clear upgrade paths for users
28 |
29 | 5. **Quality Assurance Integration**
30 | - Implemented mode-specific QA checkpoints
31 | - Created validation frameworks for each mode
32 | - Established clear quality metrics and standards
33 | - Developed systematic verification procedures
34 |
35 | This optimization round represents a significant maturation of the Memory Bank system, establishing stronger methodological foundations while maintaining strict isolation principles. By aligning with established methodologies like Claude's "Think" tool while preserving modularity through mode-specific rules, the system achieves both theoretical rigor and practical flexibility. The introduction of comprehensive visual process maps further enhances usability while maintaining the system's commitment to context efficiency.
--------------------------------------------------------------------------------
/optimization-journey/README.md:
--------------------------------------------------------------------------------
1 | # MEMORY BANK SYSTEM: OPTIMIZATION JOURNEY
2 |
3 | > **TL;DR:** The Memory Bank System evolved through multiple optimization rounds, from initial efficiency improvements to methodological integration with Claude's "Think" tool. The system now features mode-specific isolation, visual process maps, and a modular architecture that enables scalable, systematic development while maintaining context efficiency.
4 |
5 | ## 📑 TABLE OF CONTENTS
6 |
7 | | Document | Description |
8 | |----------|-------------|
9 | | [00-introduction.md](00-introduction.md) | Introduction and system purpose |
10 | | [01-efficiency-and-clarity.md](01-efficiency-and-clarity.md) | Optimization Round 1: Efficiency & Clarity |
11 | | [02-system-self-assessment.md](02-system-self-assessment.md) | Optimization Round 2: System Self-Assessment |
12 | | [03-redundancy-elimination.md](03-redundancy-elimination.md) | Optimization Round 3: Redundancy Elimination |
13 | | [04-single-source-of-truth.md](04-single-source-of-truth.md) | Optimization Round 4: Single Source of Truth Implementation |
14 | | [05-adaptive-complexity-model.md](05-adaptive-complexity-model.md) | Optimization Round 5: Adaptive Complexity Model |
15 | | [06-self-assessment-recommendations.md](06-self-assessment-recommendations.md) | Optimization Round 6: Recommendations from Self-Assessment |
16 | | [07-structured-creative-thinking.md](07-structured-creative-thinking.md) | Optimization Round 7: Structured Creative Thinking |
17 | | [08-creative-phase-enforcement.md](08-creative-phase-enforcement.md) | Optimization Round 8: Creative Phase Enforcement & Metrics |
18 | | [09-context-optimization.md](09-context-optimization.md) | Optimization Round 9: Context Optimization Through Visual Navigation |
19 | | [10-current-system-state.md](10-current-system-state.md) | Current System State |
20 | | [11-methodological-integration.md](11-methodological-integration.md) | Integration with Claude's Think Methodology |
21 | | [12-key-lessons.md](12-key-lessons.md) | Key Lessons Learned |
22 | | [13-future-directions.md](13-future-directions.md) | Future Directions and Scaling Vision |
23 |
24 | ## 📋 OPTIMIZATION JOURNEY OVERVIEW
25 |
26 | This documentation details the evolution of the Memory Bank System through several key phases:
27 |
28 | ### Early Optimization (Rounds 1-5)
29 | 1. **Efficiency & Clarity**: Addressing verbosity and improving visual hierarchy
30 | 2. **System Self-Assessment**: Adding verification mechanisms and improving tracking
31 | 3. **Redundancy Elimination**: Creating centralized task registry and domain separation
32 | 4. **Single Source of Truth**: Implementing true single source for task tracking
33 | 5. **Adaptive Complexity Model**: Introducing four complexity levels for different tasks
34 |
35 | ### Process Refinement (Rounds 6-9)
36 | 6. **Self-Assessment Recommendations**: Enhancing creative phase handling and streamlining processes
37 | 7. **Structured Creative Thinking**: Mandating creative phases for Level 3-4 tasks
38 | 8. **Creative Phase Enforcement**: Implementing hard gateways and quality metrics
39 | 9. **Context Optimization**: Adding selective document loading and visual navigation
40 |
41 | ### Latest Developments (Rounds 10-13)
42 | 10. **System State Assessment**: Comprehensive evaluation of optimizations
43 | 11. **Methodological Integration**: Alignment with Claude's Think tool methodology
44 | 12. **Key Lessons Consolidation**: Synthesis of critical insights
45 | 13. **Future Directions**: Vision for scaling and collaboration
46 |
47 | ## 🔍 LATEST SYSTEM ACHIEVEMENTS
48 |
49 | The most recent developments have yielded significant improvements:
50 |
51 | - **Methodological Integration**: Alignment with Claude's "Think" tool methodology
52 | - **Mode Isolation**: Strict containment of rules within specific modes
53 | - **Visual Process Maps**: Comprehensive guidance through development phases
54 | - **Just-In-Time Loading**: Optimized context usage through selective rule loading
55 | - **Graph-Based Architecture**: Efficient decision tree navigation and resource optimization
56 |
57 | ## 🧠 MEMORY BANK SYSTEM CORE PRINCIPLES
58 |
59 | The system now maintains these enhanced core principles:
60 |
61 | 1. **Methodological Foundation**: Structured approach based on proven methodologies
62 | 2. **Mode-Specific Isolation**: Clean separation of concerns through specialized modes
63 | 3. **Visual Processing**: Comprehensive process maps and decision trees
64 | 4. **Just-In-Time Efficiency**: Load only what's needed when it's needed
65 | 5. **Continuous Evolution**: Regular assessment and improvement of the system
66 |
67 | ```mermaid
68 | graph BT
69 | %% Early Phase Nodes
70 | E1["🔍 01-03: Foundation
• Initial Optimization
• Self Assessment
• Redundancy Elimination"]
71 | E2["⚙️ 04-05: Architecture
• Single Source of Truth
• Adaptive Complexity
• 4-Level Scale"]
72 |
73 | %% Middle Phase Nodes
74 | M1["🎨 06-08: Creative Evolution
• Process Refinement
• Structured Thinking
• Phase Enforcement"]
75 | M2["🧩 09-10: System Maturity
• Context Optimization
• Visual Navigation
• State Management"]
76 |
77 | %% Latest Phase Nodes
78 | L1["🤔 11: Think Integration
• Claude Methodology
• Mode Isolation
• Visual Process Maps"]
79 | L2["📚 12: Key Insights
• JIT Rule Loading
• Graph Architecture
• Mode Separation"]
80 | L3["🚀 13: Future Vision
• Team Collaboration
• Cross-Project Intel
• Analytics Integration"]
81 |
82 | %% Connections
83 | E1 -->|"Efficiency First"| E2
84 | E2 -->|"Process Evolution"| M1
85 | M1 -->|"System Growth"| M2
86 | M2 -->|"Methodology Shift"| L1
87 | L1 -->|"Learning & Growth"| L2
88 | L2 -->|"Future Planning"| L3
89 |
90 | %% Key Themes with Emojis
91 | KT1["⚡ Speed & Clarity
60% Context Reduction"]
92 | KT2["🏗️ System Design
Modular Architecture"]
93 | KT3["👁️ Visual Approach
Significant Processing Gains"]
94 | KT4["🎯 Mode Focus
Specialized Workflows"]
95 | KT5["🧠 Think Method
Structured Decisions"]
96 |
97 | %% Learnings & Challenges
98 | LC1["❌ Avoided:
Global Rules
Manual Tracking"]
99 | LC2["✅ Worked Well:
Visual Maps
JIT Loading"]
100 | LC3["🔄 Evolved:
Creative Process
Mode Transitions"]
101 |
102 | %% Theme Connections
103 | E1 --- KT1
104 | E2 --- KT2
105 | M1 --- KT3
106 | M2 --- KT4
107 | L1 --- KT5
108 |
109 | %% Learning Connections
110 | E2 --- LC1
111 | M2 --- LC2
112 | L2 --- LC3
113 |
114 | %% Styling
115 | style E1 fill:#f9d77e,stroke:#d9b95c
116 | style E2 fill:#f9d77e,stroke:#d9b95c
117 |
118 | style M1 fill:#a8d5ff,stroke:#88b5e0
119 | style M2 fill:#a8d5ff,stroke:#88b5e0
120 |
121 | style L1 fill:#c5e8b7,stroke:#a5c897
122 | style L2 fill:#c5e8b7,stroke:#a5c897
123 | style L3 fill:#c5e8b7,stroke:#a5c897
124 |
125 | style KT1 fill:#ffcccc,stroke:#ff9999
126 | style KT2 fill:#ffcccc,stroke:#ff9999
127 | style KT3 fill:#ffcccc,stroke:#ff9999
128 | style KT4 fill:#ffcccc,stroke:#ff9999
129 | style KT5 fill:#ffcccc,stroke:#ff9999
130 |
131 | style LC1 fill:#ffd9b3,stroke:#ffb366
132 | style LC2 fill:#d9f2d9,stroke:#97d097
133 | style LC3 fill:#d9b3ff,stroke:#b366ff
134 |
135 | %% Subgraph Styling
136 | subgraph "🌟 Latest Phase: Integration & Scale"
137 | L1
138 | L2
139 | L3
140 | end
141 |
142 | subgraph "🔄 Middle Phase: Process & Validation"
143 | M1
144 | M2
145 | end
146 |
147 | subgraph "🎯 Early Phase: Efficiency & Structure"
148 | E1
149 | E2
150 | end
151 | ```
152 |
153 | ## Development Phases Overview
154 |
155 | ### Early Focus (Chapters 1-5)
156 | - Established foundational efficiency principles
157 | - Developed systematic approach to development
158 | - Created core architecture and complexity model
159 |
160 | ### Middle Phase (Chapters 6-10)
161 | - Refined creative processes and enforcement
162 | - Implemented visual processing techniques
163 | - Achieved significant context optimization
164 |
165 | ### Latest Phase (Chapters 11-13)
166 | - Integrated with Claude's "Think" methodology
167 | - Implemented strict mode-specific isolation
168 | - Established vision for future scaling
169 |
170 | The Memory Bank system continues to evolve as a personal hobby project, focusing on creating powerful tools for structured development while maintaining the core 4-level complexity scale that has proven effective throughout its evolution.
171 |
--------------------------------------------------------------------------------