Cline rules

1# **Cline Recursive Chain-of-Thought System (CRCT) - Execution Plugin**
2 
3**This Plugin provides detailed instructions and procedures for the Execution phase of the CRCT system. It should be used in conjunction with the Core System Prompt.**
4 
5---
6 
7## I. Entering and Exiting Execution Phase
8 
9**Entering Execution Phase:**
101.  **`.clinerules` Check**: Always read `.clinerules` first. If `[LAST_ACTION_STATE]` shows `current_phase: "Execution"` or `next_phase: "Execution"`, proceed with these instructions, resuming from `next_action` if specified.
112.  **Transition from Strategy**: The `project_roadmap.md` file, updated by the Strategy phase, now contains the definitive, sequenced list of `Execution_*` tasks for the current cycle. This list is the primary input for this phase.
123.  **User Trigger**: Start a new session post-Strategy or to resume execution if paused.
13 
14**Exiting Execution Phase:**
151. **Completion Criteria:**
16   - **All `Execution_*` tasks listed in the current cycle's "Unified Execution Sequence" within `project_roadmap.md` have been marked as complete (`[x]`).**
17   - Expected outputs for all tasks are generated and verified.
18   - Results and observations are documented.
19   - MUP is followed for all actions.
202. **`.clinerules` Update (MUP):**
21   - To proceed to cleanup and consolidation:
22```
23     [LAST_ACTION_STATE]
24     last_action: "Completed Execution Phase - Tasks Executed"
25     current_phase: "Execution"
26     next_action: "Phase Complete - User Action Required"
27     next_phase: "Cleanup/Consolidation"
28```
29   - *Alternative: If transitioning back to Set-up/Maintenance for re-verification (less common after standard execution)*:
30```
31     [LAST_ACTION_STATE]
32     last_action: "Completed Execution Phase - Tasks Executed, Needs Verification"
33     current_phase: "Execution"
34     next_action: "Phase Complete - User Action Required"
35     next_phase: "Set-up/Maintenance"
36```
37   - For project completion:
38```
39     [LAST_ACTION_STATE]
40     last_action: "Completed Execution Phase - Project Objectives Achieved"
41     current_phase: "Execution"
42     next_action: "Project Completion - User Review"
43     next_phase: "Project Complete"
44```
45   *Note: "Project Complete" pauses the system; define further actions if needed.*
463. **User Action**: After updating `.clinerules`, pause for user to trigger the next phase. See Core System Prompt, Section III for a phase transition checklist.
47 
48---
49 
50## II. Loading Context for Execution
51 
52**Action**: Load necessary context for the selected Task Instruction, respecting the planning hierarchy and dependencies.
53 
54**Procedure:**
55**Load the Master Plan (MANDATORY FIRST STEP)**:
56    *   `read_file` the `project_roadmap.md`.
57    *   State: "Reading `project_roadmap.md` to identify the execution sequence for the current cycle."
58 
591.  **Identify Next Task from Unified Sequence**:
60    *   Locate the "Unified Execution Sequence" checklist for the current cycle within the roadmap.
61    *   Scan the list for the **first task that is not marked as complete** (i.e., the first `[ ]`). This is the `[Current_Task_File_Path]`.
62    *   **If no incomplete tasks are found**: The execution for this cycle is complete. State: "All tasks in the project roadmap's execution sequence are complete. Proceeding to exit phase." **Go to Section I, Exiting Execution Phase.**
63    *   **If a task is found**: State: "Next task identified from roadmap: `[Current_Task_File_Path]`."
64 
652.  **Load Parent Plan (Context)**: Read the parent `implementation_plan_*.md` file (or relevant section of `*_module.md`) that contains the task. This provides higher-level objectives and context. State: "Reading parent plan `{plan_name}.md` for task context."
663.  **Load Task Instruction**: Read the specific `Execution_{task_name}.md` file.
674.  **Load Dependencies (MANDATORY PRE-EXECUTION STEP)**:
68    *   **Identify Dependencies**: Review the `Context/Dependencies` section of the Task Instruction file *and* run `show-dependencies --key <key>` for the primary file(s) being modified by this task. (Find the key using `analyze-project` output or by convention if unsure). State: "Checking dependencies for task target(s) using `show-dependencies`."
69    *   **In-Code Verification**: When modifying source files, look for `[AUTO] STATION_HEADER` (to verify the file's primary key) and `[AUTO] CONNECTION_MAP` comments near class/function definitions. These provide immediate, localized context of the file's established dependencies.
70    *   **Read Dependent Files**: **Crucially, use `read_file` to load the content of files identified as direct dependencies** ('<', '>', 'x', 'd' relationships relevant to the task) from `show-dependencies` output, the task's explicit context list, and any in-code `CONNECTION_MAP`. **Failure to gather context from dependent files before coding/modification is a HIGH RISK for introducing errors and logical inconsistencies.** State: "Reading content of dependent files: `{file_path_1}`, `{file_path_2}`..."
71    *   **Load Other Explicit Context**: Use `read_file` to load any other specific Task Instructions, documentation files, or code snippets explicitly listed as required context in the current task file.
72 
73---
74 
75## III. Executing Tasks from Instruction Files
76 
77**Action**: Execute the step-by-step plan detailed in the loaded Task Instruction file, maintaining awareness of its place in the hierarchy and its dependencies.
78 
79**Procedure:**
801.  **Iterate Through Steps:** For each numbered step in the Task Instruction file:
81    *   **A. Understand the Step**: Read the step's description. Clarify the specific action required, considering the overall task objective and the context from the parent Implementation Plan (loaded in Section II).
82    *   **B. Review Dependencies & Context (MANDATORY REINFORCEMENT)**: **Before generating or modifying *any* code or significant file content for this specific step:**
83        *   Re-check dependencies using `show-dependencies --key <target_file_key>` if the step involves complex interactions or if context might be stale.
84        *   **CRITICAL**: Ensure you have **read and understood the relevant content (`read_file`) of the directly dependent files** identified in Section II.4. How does this step interact with those dependencies (e.g., calling functions, using data structures, implementing interfaces)? State: "Confirming understanding of interaction with dependencies `{key_1}`, `{key_2}` based on previously read files before proceeding with step."
85    *   **C. Pre-Action Verification (MANDATORY for File Modifications)**: Before using tools that modify files (`replace_in_file`, `write_to_file` on existing files, `execute_command` that changes files):
86        *   Re-read the specific target file(s) for this step using `read_file`.
87        *   Generate a "Pre-Action Verification" Chain-of-Thought:
88            1.  **Intended Change**: Clearly state the modification planned for this step (e.g., "Insert function X at line Y in file Z").
89            2.  **Dependency Context Summary**: Briefly summarize how the intended change relates to the critical dependencies reviewed in III.1.B (e.g., "Function X implements interface defined in dependent file A", "Change adheres to data format expected by dependent function B").
90            3.  **Expected Current State**: Describe the specific part of the file you expect to see before the change (e.g., "Expect line Y to be empty", "Expect function signature Z to be present").
91            4.  **Actual Current State**: Note the actual state observed from the `read_file` output.
92            5.  **Validation**: Compare expected and actual state. Proceed **only if** they match reasonably AND the intended change is consistent with the dependency context summary. If validation fails, **STOP**, state the discrepancy, and re-evaluate the step, plan, or dependencies. Ask for clarification if needed.
93        *   Example:
94```
95            Pre-Action Verification:
96            1. Intended Change: Replace line 55 in `game_logic.py` (Key: 2Ca1) with `new_score = calculate_score(data, multipliers)`.
97            2. Dependency Context Summary: `calculate_score` is imported from `scoring_utils.py` (Key: 2Cb3, dependency confirmed via show-dependencies & read_file). It expects `data` (dict) and `multipliers` (list). `game_logic.py` has access to these variables in scope.
98            3. Expected Current State: Line 55 contains the old calculation `new_score = data['base'] * 1.1`.
99            4. Actual Current State: Line 55 is `new_score = data['base'] * 1.1`.
100            5. Validation: Match confirmed. Change is consistent with dependency context. Proceeding with `replace_in_file`.
101```
102    *   **D. Perform Action**: Execute the action described in the step using the appropriate tool (`write_to_file`, `execute_command`, `replace_in_file`, etc.).
103    *   **E. Document Results (Mini-CoT)**: Immediately after the action, record the outcome:
104        *   **Action Taken**: Briefly restate the action performed.
105        *   **Result**: Success, failure, command output, generated content snippet.
106        *   **Observations**: Any unexpected behavior, potential issues, or insights gained.
107        *   **Next**: Confirm moving to the next step or handling an error.
108    *   **F. MUP**: Follow Core MUP (Section VI of Core Prompt) and Section IV additions below. **Perform MUP after each step.**
109 
1102.  **Error Handling:** If an action fails or produces unexpected results:
111    *   Document the error message and the Mini-CoT leading up to it.
112    *   Diagnose the cause: Check command syntax, file paths, permissions, dependency conflicts (referencing context from III.1.B), or logical errors in generated code/instructions. Consult Core Prompt Section VIII for dependency command error details if applicable.
113    *   Propose a resolution: Correct the command, revise the code logic based on dependency understanding, adjust the task instructions, or query the user if the plan seems flawed.
114    *   Execute the fix.
115    *   Document the resolution process.
116    *   Apply MUP post-resolution before continuing.
117 
1183.  **Code Generation and Modification Guidelines:**
119    *(Reminder: Before generating/modifying code, ensure Step III.1.B 'Review Dependencies & Context' including reading dependent files was performed)*
120    When performing actions that involve writing or changing code, adhere strictly to the following:
121    1.  **Context-Driven**:
122     - Code **must** align with the interactions, interfaces, data formats, and requirements identified during dependency review (III.1.B) and pre-action verification (III.1.C).
123    2.  **Modularity**:
124     - Write small, focused functions/methods/classes. Aim for high cohesion and low coupling.
125     - Design reusable components to enhance maintainability.
126    3.  **Clarity and Readability**:
127     - Use meaningful names for variables, functions, and classes.
128     - Follow language-specific formatting conventions (e.g., PEP 8 for Python).
129     - Add comments only for complex logic or intent, avoiding redundant explanations of *what* the code does.
130     - Provide complete, runnable code blocks or snippets as appropriate for the task step.
131    4.  **Error Handling**:
132     - Anticipate errors (e.g., invalid inputs, file not found) and implement robust handling (e.g., try-except, return value checks).
133     - Validate inputs and assumptions to prevent errors early.
134    5.  **Efficiency**:
135     - Prioritize clarity and correctness but be mindful of algorithmic complexity for performance-critical tasks.
136    6.  **Documentation**:
137     - Add docstrings or comments for public APIs or complex functions, detailing purpose, parameters, and return values.
138     - Keep documentation concise and synchronized with code changes.
139    7.  **Testing**:
140     - Write testable code and, where applicable, suggest or include unit tests for new functionality or fixes.
141    8.  **Dependency Management**:
142     - Use existing dependencies where possible. Avoid adding new external libraries unless explicitly planned.
143     - If code changes introduce *new functional dependencies* between project files, prepare to update the relevant mini-tracker (see MUP Additions, Section IV).
144    9.  **Security**:
145     - Follow secure coding practices to mitigate vulnerabilities (e.g., avoid injection risks, secure credential handling).
146    10. **WIP Markings (CRITICAL)**:
147     - Note that any areas or code blocks that require additional steps, deferred logic, or future modifications **require** a clear, descriptive `# WIP` tag (or language-appropriate comment syntax like `// WIP` or `<!-- WIP -->`) directing to the additional work needed. The system is blind without these markers to direct it during subsequent sweeps or handoffs. Reference the `comment-skill` package path defined under `[SKILLS_WORKFLOWS]` in `.clinerules/default-rules.md` for proper in-file comment-based navigation and standards.
148 
1494.  **Execution Flowchart**
150 
151```mermaid
152flowchart TD
153    subgraph Task Selection
154        Start_Exec[Start Execution Phase] --> Load_Roadmap[Load project_roadmap.md]
155        Load_Roadmap --> Find_Next_Task{Find Next Incomplete Task in Sequence}
156        Find_Next_Task -- Task Found --> Load_Task_File[Load Task Instruction File]
157        Find_Next_Task -- No Tasks Left --> End_Phase[Exit Execution Phase]
158    end
159 
160    subgraph Task Execution
161        Load_Task_File --> Load_Context[Load Parent Plan & Dependencies]
162        Load_Context --> A[Start Step] --> B[Understand Step]
163        B --> C[Review Dependencies & Read Context Files<br>MANDATORY]
164        C --> D{File Modification?}
165        D -- Yes --> E[Pre-Action Verification<br> with Context]
166        D -- No --> G[Perform Action]
167        E -- Match & Valid --> G
168        E -- No Match or Invalid --> F[Re-evaluate Plan/Context]
169        F --> B
170        G --> H[Document Results]
171        H --> I{Error?}
172        I -- Yes --> J[Handle Error]
173        I -- No --> K[MUP]
174        J --> K
175        K --> L{Next Step in Task?}
176        L -- Yes --> A
177        L -- No --> M[End Task - Update Roadmap]
178    end
179    
180    M --> Find_Next_Task
181```
182 
183---
184 
185## IV. Execution Plugin - MUP Additions
186 
187After Core MUP steps (Section VI of Core Prompt), performed *after each step* of the Task Instruction:
1881.  **Update Task Instruction File**:
189    *   Mark the just-completed step (e.g., add `[DONE]` or similar marker).
190    *   Save any significant observations or results from the Mini-CoT directly into the task file as notes for the relevant step, if useful for context later. Avoid changing the core instructions unless correcting an error found during execution.
191    *   If the task is now fully complete, update its overall status section.
192    *   Use `write_to_file` to save changes.
1932.  **Update Mini-Trackers (If New Functional Dependency Created)**:
194    *   **Condition**: If the executed step modified code in file A (key `key_A`) such that it *now* directly imports, calls, or functionally relies on code/data in file B (key `key_B`) *within the same module*, and this dependency didn't exist before or wasn't accurately reflected.
195    *   **Action**: Use `add-dependency` on the relevant `{module_name}_module.md` mini-tracker.
196    *   **Reasoning (Mandatory)**: Clearly state why the dependency is being added/updated based *specifically* on the code change made in this step.
197    *   Example (adding dependency from function/file 2Ca1 to 2Ca3 within module 'C' after adding an import):
198```bash
199        # MUP Trigger: Step X added 'from .file3 import specific_func' to file associated with key 2Ca1.
200        # Reasoning: This creates a new functional dependency where 2Ca1 now requires 2Ca3 for specific_func.
201        python -m cline_utils.dependency_system.dependency_processor add-dependency --tracker path/to/module_C/module_C_module.md --source-key 2Ca1 --target-key 2Ca3 --dep-type &quot;&lt;&quot;
202```
203        *(Use correct dep-type: '<' if A calls B, '>' if B calls A, 'x' if mutual, 'd' if essential doc link)*
2043.  **Update Domain Module / Implementation Plan Documents (If Significant)**: If the task execution led to a significant design change or outcome not captured in the original plan, briefly note this in the relevant Domain Module (`*_module.md`) or Implementation Plan (`implementation_plan_*.md`).
2054.  **Update `.clinerules` [LAST_ACTION_STATE]:** Update `last_action`, `current_phase`, `next_action`, `next_phase`.
206    *   After a step:
207```
208        [LAST_ACTION_STATE]
209        last_action: "Completed Step {N} in Execution_{task_name}.md"
210        current_phase: "Execution"
211        next_action: "Execute Step {N+1} in Execution_{task_name}.md"
212        next_phase: "Execution"
213```
214    *   After completing the last step in a task:
215```
216        [LAST_ACTION_STATE]
217        last_action: "Completed all steps in Execution_{task_name}.md"
218        current_phase: "Execution"
219        next_action: "Select next Execution task or transition phase"
220        next_phase: "Execution" # Default, change only when *all* planned tasks are done.
221```
222    *   Upon exiting the phase (as defined in Section I): Use the appropriate state from Section I.
223 
224---
225 
226## V. Quick Reference
227- **Objective**: Execute planned `Execution_*` tasks step-by-step, modifying files/code according to instructions, dependencies, and quality guidelines.
228- **Key Actions**:
229    - Load context: Parent Plan -> Task Instruction -> Dependencies (`show-dependencies` + `read_file`).
230    - Execute steps sequentially.
231    - **MANDATORY**: Review dependencies & **read context files** before coding/modification.
232    - **MANDATORY**: Perform pre-action verification for file modifications.
233    - Follow code quality guidelines.
234    - Document results (Mini-CoT) after each action.
235    - Perform MUP after each action.
236    - Update mini-trackers (`add-dependency`) if new functional dependencies are created.
237- **Key Inputs**: Prioritized Task list (from Strategy), `implementation_plan_*.md`, `Execution_*.md`, dependency tracker info (`show-dependencies`), content of dependent files (`read_file`).
238- **Key Outputs**: Modified project files (code, docs), updated `activeContext.md`, updated task instruction files, potentially updated mini-trackers, updated `.clinerules`.
239- **MUP Additions**: Update instruction files (step completion, notes), mini-trackers (if needed), potentially Plans/Modules, and `.clinerules`.
240