Faturrachman dev

.cursor/rules/isolation_rules/Core/command-execution.mdc

@@ -0,0 +1,81 @@
+---
+description: Core guidelines for AI command execution, emphasizing tool priority (edit_file, fetch_rules, run_terminal_cmd), platform awareness, and result documentation within the Memory Bank system.
+globs: **/Core/command-execution.mdc
+alwaysApply: false
+---
+# COMMAND EXECUTION SYSTEM
+
+> **TL;DR:** This system provides guidelines for efficient and reliable command and tool usage. Prioritize `edit_file` for file content, `fetch_rules` for loading `.mdc` rules, and `run_terminal_cmd` for execution tasks. Always document actions and results in `memory-bank/activeContext.md`.
+
+## 🛠️ TOOL PRIORITY & USAGE
+
+1.  **`edit_file` (Primary for Content):**
+    *   Use for ALL creation and modification of `.md` files in `memory-bank/` and `documentation/`.
+    *   Use for ALL source code modifications.
+    *   `edit_file` can create a new file if it doesn't exist and populate it.
+    *   Provide clear instructions or full content blocks for `edit_file`.
+2.  **`fetch_rules` (Primary for `.mdc` Rules):**
+    *   Use to load and follow instructions from other `.mdc` rule files within `.cursor/rules/isolation_rules/`.
+    *   Specify the full path to the target `.mdc` file.
+3.  **`read_file` (Primary for Context Gathering):**
+    *   Use to read existing project files (source code, `README.md`), `memory-bank/*.md` files for context, or `.mdc` files if `fetch_rules` is not appropriate for the specific need (e.g., just extracting a template).
+4.  **`run_terminal_cmd` (Primary for Execution):**
+    *   Use for tasks like `mkdir`, running tests, build scripts, or starting servers.
+    *   **CRITICAL:** Be platform-aware (see "Platform-Specific Considerations" below). If unsure of the OS, state your default command (e.g., for Linux) and ask for the Windows PowerShell equivalent if needed.
+5.  **`list_dir`, `search_files`, `codebase_search`:**
+    *   Use for file system exploration and code/text searching as appropriate.
+
+## 🔍 COMMAND EFFICIENCY & PLANNING WORKFLOW (Conceptual for AI)
+```mermaid
+graph TD
+    Start["Command Planning"] --> Analyze["Analyze Requirements"]
+    Analyze --> ToolSelect["Select Correct Tool<br>(edit_file, fetch_rules, run_terminal_cmd, etc.)"]
+    ToolSelect --> Complexity{"Action Complexity?"}
+    Complexity -->|"Simple File Edit"| SingleEdit["Use `edit_file` directly"]
+    Complexity -->|"Simple Terminal Cmd"| SingleCmd["Use `run_terminal_cmd`"]
+    Complexity -->|"Complex Sequence"| GroupedSteps["Break into Logical Textual Steps<br>using appropriate tools for each step"]
+    SingleEdit & SingleCmd & GroupedSteps --> Verify["Verify Results<br>(e.g., `read_file` back, check terminal output)"]
+    Verify --> Document["Document Action & Result<br>in `activeContext.md` using `edit_file`"]
+    Document --> Next["Next Action"]
+```
+**Textual Guide for AI:**
+1.  **Analyze Requirements:** Understand what needs to be achieved.
+2.  **Select Correct Tool:** Choose `edit_file` for content, `fetch_rules` for rules, `run_terminal_cmd` for execution, etc.
+3.  **Execute:** Perform the action. For complex sequences, break it down into clear, tool-specific steps.
+4.  **Verify Results:** If you used `edit_file`, consider using `read_file` to confirm the content. If `run_terminal_cmd`, examine the output.
+5.  **Document Action & Result:** Use `edit_file` to append a summary of the command/tool call and its outcome to the "Build Log" or relevant section in `memory-bank/activeContext.md`.
+
+## 🚦 DIRECTORY VERIFICATION (for `run_terminal_cmd`)
+**Textual Guide for AI:**
+1.  Before running build scripts or package manager commands (npm, pip) via `run_terminal_cmd`, verify you are in the correct project root directory.
+2.  Use `list_dir` to check for key files like `package.json` or `requirements.txt`.
+3.  If not in the correct directory, use `run_terminal_cmd` with `cd [path_to_project_root]` to navigate.
+
+## 📋 COMMAND DOCUMENTATION TEMPLATE (for `activeContext.md` "Build Log")
+When documenting your actions, use `edit_file` to append entries like this to `memory-bank/activeContext.md`:
+```markdown
+### Action: [Purpose of the action]
+- **Tool Used:** `[edit_file | fetch_rules | run_terminal_cmd | etc.]`
+- **Target/Command:** `[file_path | rule_path | actual_terminal_command]`
+- **Parameters (if applicable):** `[e.g., content for edit_file, search query]`
+- **Expected Outcome:** `[Briefly what you expected]`
+- **Actual Result:**
+  \`\`\`
+  [Output from run_terminal_cmd, or confirmation of file edit/read]
+  \`\`\`
+- **Effect:** `[Brief description of what changed in the system or Memory Bank]`
+- **Next Steps:** `[What you plan to do next]`
+```
+
+## 🔍 PLATFORM-SPECIFIC CONSIDERATIONS (for `run_terminal_cmd`)
+**Textual Guide for AI:**
+*   **Windows (PowerShell):** Path separator: `\`, Dir creation: `mkdir my_dir` or `New-Item -ItemType Directory -Path my_dir`.
+*   **Unix/Linux/Mac (Bash/Zsh):** Path separator: `/`, Dir creation: `mkdir -p my_dir`.
+*   **Action:** If unsure of OS, state default (Linux) and ask for Windows PowerShell equivalent or user OS specification.
+
+## 📝 COMMAND EXECUTION CHECKLIST (AI Self-Correction)
+- Purpose clear? Correct tool chosen? Platform considerations for `run_terminal_cmd`? Action/result documented in `activeContext.md` via `edit_file`? Outcome verified?
+
+## 🚨 WARNINGS
+*   Avoid `run_terminal_cmd` with `echo > file` or `Add-Content` for multi-line content. **Always use `edit_file`**.
+*   For destructive `run_terminal_cmd` (e.g., `rm`), seek user confirmation.

.cursor/rules/isolation_rules/Core/complexity-decision-tree.mdc

@@ -0,0 +1,37 @@
+---
+description: Core rule for AI to determine task complexity (Level 1-4) and initiate appropriate workflow using Memory Bank principles.
+globs: **/Core/complexity-decision-tree.mdc
+alwaysApply: false
+---
+# TASK COMPLEXITY DETERMINATION
+
+> **TL;DR:** This rule guides you to determine task complexity (Level 1-4). Based on the level, you will then be instructed to `fetch_rules` for the corresponding primary mode map.
+
+## 🌳 COMPLEXITY DECISION TREE (Conceptual for AI)
+**Textual Guide for AI:**
+Based on user's request and initial analysis (e.g., from `read_file` on `README.md`):
+
+1.  **Bug fix/error correction?**
+    *   **Yes:** Single, isolated component? -> **Level 1 (Quick Bug Fix)**
+    *   **Yes:** Multiple components, straightforward fix? -> **Level 2 (Simple Enhancement/Refactor)**
+    *   **Yes:** Complex interactions, architectural impact? -> **Level 3 (Intermediate Feature/Bug)**
+    *   **No (new feature/enhancement):**
+        *   Small, self-contained addition? -> **Level 2 (Simple Enhancement)**
+        *   Complete new feature, multiple components, needs design? -> **Level 3 (Intermediate Feature)**
+        *   System-wide, major subsystem, deep architectural design? -> **Level 4 (Complex System)**
+
+## 📝 ACTION: DOCUMENT & ANNOUNCE COMPLEXITY
+
+1.  **Determine Level:** Decide Level 1, 2, 3, or 4.
+2.  **Document in `activeContext.md`:** Use `edit_file` to update `memory-bank/activeContext.md`:
+    ```markdown
+    ## Task Complexity Assessment
+    - Task: [User's request]
+    - Determined Complexity: Level [1/2/3/4] - [Name]
+    - Rationale: [Justification]
+    ```
+3.  **Update `tasks.md`:** Use `edit_file` to update `memory-bank/tasks.md` with the level, e.g., `Level 3: Implement user auth`.
+4.  **Announce & Next Step:**
+    *   State: "Assessed as Level [N]: [Name]."
+    *   **Level 1:** "Proceeding with Level 1 workflow. Will `fetch_rules` for `.cursor/rules/isolation_rules/Level1/workflow-level1.mdc` (or directly to IMPLEMENT map if simple enough, e.g., `visual-maps/implement-mode-map.mdc` which might then fetch a Level 1 implement rule)."
+    *   **Level 2-4:** "Requires detailed planning. Transitioning to PLAN mode. Will `fetch_rules` for `.cursor/rules/isolation_rules/visual-maps/plan-mode-map.mdc`."

.cursor/rules/isolation_rules/Core/creative-phase-enforcement.mdc

@@ -0,0 +1,21 @@
+---
+description: Core rule for enforcing Creative Phase completion for Level 3-4 tasks before allowing IMPLEMENT mode.
+globs: **/Core/creative-phase-enforcement.mdc
+alwaysApply: false
+---
+# CREATIVE PHASE ENFORCEMENT
+
+> **TL;DR:** For L3/L4 tasks, if `tasks.md` flags items for "CREATIVE Phase", they MUST be completed before IMPLEMENT.
+
+## 🔍 ENFORCEMENT WORKFLOW (AI Actions)
+(Typically invoked by IMPLEMENT mode orchestrator for L3/L4 tasks, or by PLAN mode before suggesting IMPLEMENT)
+
+1.  **Check Task Level & Creative Flags:**
+    a.  `read_file` `memory-bank/activeContext.md` (for task level).
+    b.  `read_file` `memory-bank/tasks.md`. Scan current feature's sub-tasks for incomplete "CREATIVE: Design..." entries.
+2.  **Decision:**
+    *   **If uncompleted CREATIVE tasks for L3/L4 feature:**
+        a.  State: "🚨 IMPLEMENTATION BLOCKED for [feature]. Creative designs needed for: [list uncompleted creative tasks]."
+        b.  Suggest: "Initiate CREATIVE mode (e.g., 'CREATIVE design [component]')." Await user.
+    *   **Else (No uncompleted creative tasks or not L3/L4):**
+        a.  State: "Creative phase requirements met/not applicable. Proceeding."

.cursor/rules/isolation_rules/Core/creative-phase-metrics.mdc

@@ -0,0 +1,22 @@
+---
+description: Core reference on metrics and quality assessment for Creative Phase outputs. For AI understanding of quality expectations.
+globs: **/Core/creative-phase-metrics.mdc
+alwaysApply: false
+---
+# CREATIVE PHASE METRICS & QUALITY ASSESSMENT (AI Guidance)
+
+> **TL;DR:** This outlines quality expectations for `creative-*.md` documents. Use this as a guide when generating or reviewing creative outputs.
+
+## 📊 QUALITY EXPECTATIONS FOR `memory-bank/creative/creative-[feature_name].md` (AI Self-Guide)
+A good creative document (created/updated via `edit_file`) should cover:
+1.  **Problem & Objectives:** Clearly defined. What problem is this design solving? What are the goals?
+2.  **Requirements & Constraints:** List functional and non-functional requirements. Note any technical or business constraints.
+3.  **Options Explored:** At least 2-3 viable design options should be considered and briefly described.
+4.  **Analysis of Options:** For each option:
+    *   Pros (advantages).
+    *   Cons (disadvantages).
+    *   Feasibility (technical, time, resources).
+    *   Impact (on other system parts, user experience).
+5.  **Recommended Design & Justification:** Clearly state the chosen design option and provide a strong rationale for why it was selected over others, referencing the analysis.
+6.  **Implementation Guidelines:** High-level steps or considerations for implementing the chosen design. This is not a full plan, but key pointers for the IMPLEMENT phase.
+7.  **Visualizations (if applicable):** Reference or describe any diagrams (e.g., flowcharts, component diagrams) that clarify the design. (Actual diagram creation might be a separate step or user-provided).

.cursor/rules/isolation_rules/Core/file-verification.mdc

@@ -0,0 +1,56 @@
+---
+description: Core rule for AI to verify and create Memory Bank file structures, prioritizing `edit_file` for content and `run_terminal_cmd` for `mkdir`.
+globs: **/Core/file-verification.mdc
+alwaysApply: false
+---
+# OPTIMIZED FILE VERIFICATION & CREATION SYSTEM (Memory Bank Setup)
+
+> **TL;DR:** Verify/create essential Memory Bank directories and files. Use `edit_file` to create/populate files, `run_terminal_cmd` (platform-aware) for `mkdir`. Log actions.
+
+## ⚙️ AI ACTIONS FOR MEMORY BANK SETUP (Typically during early VAN)
+
+1.  **Acknowledge:** State: "Performing Memory Bank file verification and setup."
+2.  **Reference Paths:** Mentally (or by `read_file` if necessary) refer to `.cursor/rules/isolation_rules/Core/memory-bank-paths.mdc` for canonical paths.
+3.  **Verify/Create `memory-bank/` Root Directory:**
+    a.  Use `list_dir .` (project root) to check if `memory-bank/` exists.
+    b.  If missing:
+        i.  `run_terminal_cmd` (platform-aware, e.g., `mkdir memory-bank` or `New-Item -ItemType Directory -Path memory-bank`).
+        ii. Verify creation (e.g., `list_dir .` again).
+4.  **Verify/Create Core Subdirectories in `memory-bank/`:**
+    a.  The subdirectories are: `creative/`, `reflection/`, `archive/`.
+    b.  For each (e.g., `creative`):
+        i.  `list_dir memory-bank/` to check if `memory-bank/creative/` exists.
+        ii. If missing: `run_terminal_cmd` (e.g., `mkdir memory-bank/creative`). Verify.
+5.  **Verify/Create Core `.md` Files in `memory-bank/` (Using `edit_file`):**
+    a.  The core files are: `tasks.md`, `activeContext.md`, `progress.md`, `projectbrief.md`, `productContext.md`, `systemPatterns.md`, `techContext.md`, `style-guide.md`.
+    b.  For each file (e.g., `tasks.md`):
+        i.  Attempt to `read_file memory-bank/tasks.md`.
+        ii. If it fails (file doesn't exist) or content is empty/default placeholder:
+            Use `edit_file memory-bank/tasks.md` to write an initial template. Example for `tasks.md`:
+            ```markdown
+            # Memory Bank: Tasks
+
+            ## Current Task
+            - Task ID: T000
+            - Name: [Task not yet defined]
+            - Status: PENDING_INITIALIZATION
+            - Complexity: Not yet assessed
+            - Assigned To: AI
+
+            ## Backlog
+            (Empty)
+            ```
+            *(Provide similar minimal templates for other core files if creating them anew. `activeContext.md` could start with `# Active Context - Initialized [Timestamp]`).*
+        iii. Optionally, `read_file memory-bank/tasks.md` again to confirm content.
+6.  **Log Verification Actions:**
+    a.  Use `edit_file` to append a summary to `memory-bank/activeContext.md` under a "File Verification Log" heading. List directories/files checked, created, or found existing. Note any errors.
+    b.  Example log entry:
+        ```markdown
+        ### File Verification Log - [Timestamp]
+        - Checked/Created `memory-bank/` directory.
+        - Checked/Created `memory-bank/creative/` directory.
+        - Checked/Created `memory-bank/tasks.md` (initial template written).
+        - ... (other files/dirs) ...
+        - Status: All essential Memory Bank structures verified/created.
+        ```
+7.  **Completion:** State: "Memory Bank file structure verification and setup complete."

.cursor/rules/isolation_rules/Core/hierarchical-rule-loading.mdc

@@ -0,0 +1,14 @@
+---
+description: Core design principle for Memory Bank: hierarchical/lazy loading of `.mdc` rules via `fetch_rules`.
+globs: **/Core/hierarchical-rule-loading.mdc
+alwaysApply: false
+---
+# HIERARCHICAL RULE LOADING SYSTEM (Design Principle for AI)
+
+> **TL;DR:** You achieve hierarchical/lazy rule loading by following instructions in main mode prompts or other `.mdc` rules that direct you to use `fetch_rules` to load specific `.mdc` rule files only when needed.
+
+## 🧠 HOW YOU EXECUTE HIERARCHICAL LOADING:
+1.  **Mode Activation:** Your main custom prompt for a mode (e.g., VAN) tells you to `fetch_rules` for its primary orchestrating `.mdc` (e.g., `visual-maps/van_mode_split/van-mode-map.mdc`).
+2.  **Following Instructions:** That `.mdc` guides you. Some steps might instruct: "If [condition], then `fetch_rules` to load and follow `[specific_sub_rule.mdc]`." For example, `van-mode-map.mdc` might tell you to `fetch_rules` for `Core/complexity-decision-tree.mdc`.
+3.  **Current Rule Focus:** Always operate based on the instructions from the most recently fetched and relevant rule. Once a fetched rule's instructions are complete, you "return" to the context of the rule that fetched it, or if it was a top-level fetch, you await further user instruction or mode transition.
+4.  **Acknowledge Fetches:** When you `fetch_rules` for an `.mdc`, briefly state: "Fetched `.cursor/rules/isolation_rules/[rule_path]`. Now proceeding with its instructions."

.cursor/rules/isolation_rules/Core/memory-bank-paths.mdc

@@ -0,0 +1,35 @@
+---
+description: Defines canonical paths for core Memory Bank files and directories. CRITICAL reference for all file operations.
+globs: **/Core/memory-bank-paths.mdc
+alwaysApply: true
+---
+# CORE MEMORY BANK FILE & DIRECTORY LOCATIONS
+
+**CRITICAL REFERENCE:** Adhere strictly to these paths for all file operations (`edit_file`, `read_file`, `list_dir`, `run_terminal_cmd` for `mkdir`).
+
+## Root Memory Bank Directory:
+*   `memory-bank/` (at project root)
+
+## Core `.md` Files (in `memory-bank/`):
+*   Tasks: `memory-bank/tasks.md`
+*   Active Context: `memory-bank/activeContext.md`
+*   Progress: `memory-bank/progress.md`
+*   Project Brief: `memory-bank/projectbrief.md`
+*   Product Context: `memory-bank/productContext.md`
+*   System Patterns: `memory-bank/systemPatterns.md`
+*   Tech Context: `memory-bank/techContext.md`
+*   Style Guide: `memory-bank/style-guide.md`
+
+## Subdirectories in `memory-bank/`:
+*   Creative: `memory-bank/creative/` (Files: `creative-[feature_or_component_name]-[YYYYMMDD].md`)
+*   Reflection: `memory-bank/reflection/` (Files: `reflect-[task_id_or_feature_name]-[YYYYMMDD].md`)
+*   Archive: `memory-bank/archive/` (Files: `archive-[task_id_or_feature_name]-[YYYYMMDD].md`)
+
+## Project Documentation Directory (Separate from Memory Bank, but related):
+*   `documentation/` (at project root, for final, polished, user-facing docs)
+
+## AI Verification Mandate:
+*   Before using `edit_file` on Memory Bank artifacts, confirm the path starts with `memory-bank/` or one of its specified subdirectories.
+*   When creating new core files (e.g., `tasks.md`), use `edit_file` with the exact path (e.g., `memory-bank/tasks.md`).
+*   For `run_terminal_cmd mkdir`, ensure correct target paths (e.g., `mkdir memory-bank/creative`).
+*   Filenames for creative, reflection, and archive documents should include a descriptive name and a date (YYYYMMDD format is good practice).

.cursor/rules/isolation_rules/Core/mode-transition-optimization.mdc

@@ -0,0 +1,29 @@
+---
+description: Core design principles for optimized mode transitions using `activeContext.md` as the handover document.
+globs: **/Core/mode-transition-optimization.mdc
+alwaysApply: false
+---
+# MODE TRANSITION OPTIMIZATION (AI Actions)
+
+> **TL;DR:** Efficient mode transitions are achieved by updating `memory-bank/activeContext.md` (via `edit_file`) before a transition. The next mode's orchestrator rule then reads this file for context.
+
+## 🔄 CONTEXT TRANSFER PROCESS (AI Actions):
+
+1.  **Before Current Mode Exits (or suggests exiting):**
+    a.  Your current instructions (from main prompt or an `.mdc` via `fetch_rules`) will guide you to use `edit_file` to update `memory-bank/activeContext.md`.
+    b.  This update should include a section like:
+        ```markdown
+        ## Mode Transition Prepared - [Timestamp]
+        - **From Mode:** [Current Mode, e.g., PLAN]
+        - **To Mode Recommended:** [Target Mode, e.g., CREATIVE or IMPLEMENT]
+        - **Current Task Focus:** [Specific task name or ID from tasks.md]
+        - **Key Outputs/Decisions from [Current Mode]:**
+            - [Summary of what was achieved, e.g., "Plan for user authentication feature is complete."]
+            - [Reference to key artifacts created/updated, e.g., "See `memory-bank/tasks.md` for detailed sub-tasks. Creative design needed for UI components."]
+        - **Primary Goal for [Target Mode]:** [What the next mode should focus on, e.g., "Design UI mockups for login and registration pages."]
+        ```
+2.  **When New Mode Starts:**
+    a.  The new mode's main custom prompt (in Cursor's Advanced Settings) will instruct you to `fetch_rules` for its primary orchestrating `.mdc` file (e.g., `visual-maps/creative-mode-map.mdc`).
+    b.  That orchestrating `.mdc` will (as an early step) instruct you to `read_file memory-bank/activeContext.md` to understand the incoming context, task focus, and goals.
+
+**Key Principle:** `memory-bank/activeContext.md` is the primary "handover document" between modes, managed by `edit_file`. Keep its "Mode Transition Prepared" section concise and actionable for the next mode.