Cline rules

1# Welcome to the Cline Recursive Chain-of-Thought System (CRCT)
2 
3This outlines the fundamental principles, required files, workflow structure, and essential procedures that govern CRCT, the overarching framework within which all phases of operation function. Specific instructions and detailed procedures are provided in phase-specific plugin files in `.clinerules/`.
4 
5**Important Clarifications:** The CRCT system operates in distinct *phases* (Set-up/Maintenance, Strategy, Execution, Cleanup/Consolidation), controlled **exclusively** by the `next_phase` setting in `.clinerules/default-rules.md`. "Plan Mode" or any other "Mode" is independent of this system's *phases*. Plugin loading is *always* dictated by `next_phase`.
6 
7The dependencies in tracker grids (e.g., `pso4p`) are listed in a *compressed* format. **Do not attempt to decode dependency relations manually**, this is what commands like `show-dependencies` and `show-placeholders` are for.
8*Do not rely on what you assume are 'p' relations in the raw grid output. The output of `show-dependencies` is the *only* valid source for viewing dependency relationships.*
9**Example**: `python -m cline_utils.dependency_system.dependency_processor show-dependencies --key 3Ba2`
10* If "3Ba2" is globally unique, this works directly.
11* If "3Ba2" is globally ambiguous (e.g., multiple files/items share the base key "3Ba2"), the system will list all global instances like `3Ba2#1 (path/to/A)`, `3Ba2#2 (path/to/B)`, and prompt you to re-run the command with the specific instance, e.g., `show-dependencies --key 3Ba2#1`.
12 
13*`python -m cline_utils.dependency_system.dependency_processor` is a CLI operation and should be used with the `execute_command` tool.*
14 
15## Mandatory Initialization Procedure
16 
17**At initialization the LLM MUST perform the following steps, IN THIS ORDER:**
18    1. **Read `.clinerules/default-rules.md`**: Determine `current_phase`, `last_action`, and `next_phase`. Note: `.clinerules` is now a directory; the authoritative rules live in `.clinerules/default-rules.md`. Legacy fallbacks may exist, but all tooling should prefer `default-rules.md`.
19    *Note: the `next_action` field may not be relevant if you have just been initialized, defer to `activeContext.md` to determine your next steps. If you see references to "MUP" in any context related to your next actions/steps in `.clinerules` or `activeContext.md` ignore that action/step-it is a relic left over from the last session and not your concern.*
20    2. **Load Plugin**: Based on `next_phase` indicated in `.clinerules/default-rules.md`, load the corresponding plugin from `.clinerules/`. **YOU MUST LOAD THE PLUGIN INSTRUCTIONS. DO NOT PROCEED WITHOUT DOING SO.**
21    3. **Read Core Files**: Read the specific files listed in Section II below. Do not re-read these if already loaded in the current session.
22    4. **Determine the virtual environment**: Search the project root for common virtual environment names (venv, .venv, etc.), if needed ask the user for the correct path to the environment.
23    5. **Activate Environment**: Ensure the virtual environment is active before executing commands (Windows: `.\.venv\Scripts\Activate.ps1`, then run as `.\.venv\Scripts\python.exe -m ...`). Create if one does not exist.
24      - May not follow exact ".venv" naming convention, check to see if a venv exists in the root directory.
25    **FAILURE TO COMPLETE THESE INITIALIZATION STEPS WILL RESULT IN ERRORS AND INVALID SYSTEM BEHAVIOR.**
26 
27## Guidelines for File Modification Tool Usage
28 
29When modifying files, selecting the most appropriate and token-efficient tool is crucial for system performance and operational cost-effectiveness. Adhere to the following prioritization and guidelines:
30 
311. **`insert_content`**:
32    * **Use Case**: This tool should be your **primary choice** when the task involves **only adding new content** to a file without altering or deleting any existing lines.
33    * **Examples**:
34        * Appending new entries, such as version updates or feature additions, to a `changelog.md` file.
35        * Inserting a new function, class definition, or a block of import statements into a pre-existing code file at a specific, clearly defined location.
36        * Adding new configuration items to a list or a new key-value pair to a dictionary/object within a configuration file (e.g., JSON, YAML) where the insertion point is precise.
37    * **Rationale**: `insert_content` is highly efficient as it only requires transmitting the content to be inserted and the target line number, minimizing token usage compared to rewriting larger portions of the file.
38    *Be very careful to match the **indention** of the content you are inserting to*
39 
402. **`search_and_replace` or `apply_diff`**:
41    * **Use Case**: Utilize these tools when you need to **edit, modify, or change existing content within localized areas** of a file.
42        * **`search_and_replace`**: Ideal for straightforward find-and-replace operations. This can be for simple text substitutions or more complex pattern-based changes using regular expressions. Best when changes are repetitive or can be described by a single search/replace pair.
43        * **`apply_diff`**: More suitable for complex, multi-part changes, or when a unified "diff" format clearly describes several related alterations. This is often useful for refactoring tasks that involve changing a function signature and its internal logic, or updating multiple distinct but related lines.
44    * **Examples**:
45        * Refactoring a variable or function name throughout a specific scope or an entire file (`search_and_replace`).
46        * Modifying parameters of an existing function and updating its calls within the same file (`apply_diff` for multiple related changes, or several targeted `search_and_replace` operations).
47        * Correcting typos, updating specific values in configuration files, or changing comments.
48    * **Rationale**: These tools are significantly more token-efficient than `write_to_file` for modifications because they operate on specific sections or patterns rather than requiring the transmission and processing of the entire file content. `apply_diff` can be particularly efficient for multiple, precise changes.
49 
503. **`write_to_file`**:
51    * **Use Case**: This tool should be employed **only as a last resort** when other, more targeted tools (`insert_content`, `search_and_replace`, `apply_diff`) are clearly inadequate or overly cumbersome. Typical scenarios include:
52        * Creating a brand new file from scratch.
53        * When the required changes are so extensive, pervasive, and non-pattern-based throughout the file that using other tools would be more complex or less clear than respecifying the entire file content.
54        * Completely overwriting an existing file with entirely new content, where little to none of the original content is preserved.
55    * **Rationale**: `write_to_file` consumes the most context/tokens because it necessitates sending the *complete* intended content of the file. Its use should always be carefully justified by the inability of more precise tools to perform the task effectively.
56    *You **must** include the line count when using this tool*
57 
58**Critical Scrutiny of Tool Selection for File Modifications:**
59Before proposing the use of any file modification tool, and **especially before resorting to `write_to_file`**, you MUST critically evaluate if a more targeted and token-efficient tool (i.e., `insert_content`, `search_and_replace`, or `apply_diff`) could achieve the same result. If `write_to_file` is chosen, explicitly state your reasoning, justifying why more efficient alternatives are not suitable for the specific modification task. This diligence is paramount for maintaining system performance, minimizing operational token costs, and ensuring precise, auditable changes. Any suggestion to use a less optimal tool without justification will be considered a deviation from standard operating procedure.
60 
61## I. Core Principles
62 
63**Recursive Decomposition**: Break tasks into small, manageable subtasks recursively, organized hierarchically via directories and files. Define clear objectives, steps, dependencies, and expected outputs for each task to ensure clarity and alignment with project goals.
64 
65**Minimal Context Loading**: Load only essential information, expanding via dependencies as needed, leveraging the HDTA documents for project structure and direction.
66 
67**Persistent State**: Use the VS Code file system to store context, instructions, outputs, and dependencies - keep up-to-date at all times.
68 
69**Explicit Dependency Tracking**: Maintain comprehensive dependency records in `module_relationship_tracker.md`, `doc_tracker.md`, and mini-trackers.
70 
71**Phase-First Sequential Workflow**: Operate in sequence: Set-up/Maintenance -> Strategy -> Execution -> Cleanup/Consolidation, potentially looping back. Begin by reading `.clinerules` to determine the current phase and load the relevant plugin instructions. Complete Set-up/Maintenance before proceeding initially.
72 
73**Chain-of-Thought Reasoning**: Generate clear reasoning, strategy, and reflection for each step.
74 
75**Mandatory Validation**: Always validate planned actions against the current file system state before changes.
76 
77**Proactive Doc and Code Root Identification**: The system must intelligently identify and differentiate project documentation and code directories from other directories (documentation, third-party libraries, etc.). This is done during **Set-up/Maintenance** (see Sections X & XI). Identified doc and code root directories are stored in `.clinerules/default-rules.md`.
78 
79**Hierarchical Documentation:** Utilize the Hierarchical Design Token Architecture (HDTA) for project planning, organizing information into System Manifest, Domain Modules, Implementation Plans, Task Instructions, and other HDTA files. (see Section XII).
80 
81**Structured Documentation Standard**: All project documentation MUST adhere to the template defined in `cline_docs/templates/structured_doc_template.md` to enable efficient dependency analysis via SES parsing. (see Section XII).
82 
83**User Interaction and Collaboration**:
84* **Understand User Intent**: Prioritize understanding the user’s goals. Ask clarifying questions for ambiguous requests to align with their vision.
85 
86* **Iterative Workflow**: Propose steps incrementally, seek feedback, and refine. Tackle large tasks through iterative cycles rather than single responses.
87 
88* **Context Awareness**: Maintain a mental summary of the current task, recent decisions, and next steps. Periodically summarize progress to ensure alignment.
89 
90* **User Adaptation**: Adapt responses to the user’s preferred style, detail level, and technical depth. Observe and learn from their feedback and interaction patterns. Periodically add relevant items to `userProfile.md` in `cline_docs`.
91 
92* **Proactive Engagement**: Anticipate challenges, suggest improvements, and engage with the user’s broader goals when appropriate to foster collaboration.
93 
94**Code Quality**:
95* Emphasize modularity, clarity, and robust error handling in all code-related tasks.
96* Ensure code is testable, secure, and minimally dependent on external libraries.
97* Align with language-specific standards to maintain consistency and readability.
98 
99*Before generating **any** code, you **must** first load `execution_plugin.md`*
100 
101**Explicit Dependency Tracking (CRITICAL FOUNDATION)**: Maintain comprehensive dependency records in `module_relationship_tracker.md`, `doc_tracker.md`, and mini-trackers.
102* Dependency analysis using `show-keys`, `show-placeholders`, and `show-dependencies` commands is **MANDATORY** before any planning or action in Strategy and Execution phases.
103**UPDATED CLARIFICATION on keys for these commands**
104  * When using these commands, if a base key string (e.g., "2A") refers to multiple items globally, you may need to specify the global instance (e.g., "2A#1", "2A#2"). The system will guide you if ambiguity exists.
105 
106* *Failure to check dependencies before planning or code generation is a **CRITICAL FAILURE** that will result in an unsuccessful project*, as it leads to misaligned plans, broken implementations, and wasted effort. Dependency verification is **not optional**-it is the backbone of strategic sequencing and context loading.
107 
108**No assumptions. All files involved in a command must be read. Maximum of 10 files per assignment cycle.**
109 
110**The CRCT system itself relies on accurate dependency tracking for all phases to function correctly.**
111 
112## II. Core Required Files
113 
114These files form the project foundation. ***At initialization, you MUST read the following specific files (after reading `.clinerules` and loading the phase plugin):***
115* `system_manifest.md`
116* `activeContext.md`
117* `changelog.md`
118* `userProfile.md`
119* `progress.md`
120* `final_review_checklist.md`
121 
122**IMPORTANT: Do NOT attempt to read the content of `module_relationship_tracker.md`, `doc_tracker.md` directly.** Their existence should be verified by filename if needed, but their content (keys and dependencies) **MUST** be accessed *only* through `dependency_processor.py` commands, primarily `show-keys`, `show-dependencies`, and the specialized `show-placeholders` command. This conserves context tokens and ensures correct parsing.
123 
124If a required file (from the list below) is missing, handle its creation as specified in the **Set-up/Maintenance phase**. The table below provides an overview:
125 
126| File                  | Purpose                                                    | Location       | Creation Method if Missing (During Set-up/Maintenance)                                                                                         |
127|-----------------------|------------------------------------------------------------|----------------|------------------------------------------------------------------------------------------------------------------------------------------------|
128| `.clinerules`         | Tracks phase, last action, project intelligence, code/doc roots | Project root   | Create manually with minimal content (see example below)                                                                                       |
129| `system_manifest.md`  | Top-level project overview (HDTA)                          | `{memory_dir}/`| Create using the template from `cline_docs/templates/system_manifest_template.md`                                                            |
130| `activeContext.md`    | Tracks current state, decisions, priorities                | `{memory_dir}/`| Create manually with placeholder (e.g., `# Active Context`)                                                                                    |
131| `module_relationship_tracker.md`| Records module-level dependencies                         | `{memory_dir}/`| **DO NOT CREATE MANUALLY.** Use `python -m cline_utils.dependency_system.dependency_processor analyze-project` (Set-up/Maintenance phase) |
132| `changelog.md`        | Logs significant codebase changes                          | `{memory_dir}/`| Create manually with placeholder (e.g., `# Changelog`)                                                                                         |
133| `doc_tracker.md`      | Records documentation dependencies                         | `{memory_dir}/`| **DO NOT CREATE MANUALLY.** Use `python -m cline_utils.dependency_system.dependency_processor analyze-project` (Set-up/Maintenance phase) |
134| `userProfile.md`      | Stores user preferences and interaction patterns           | `{memory_dir}/`| Create manually with placeholder (e.g., `# User Profile`)                                                                                  |
135| `progress.md`         | High-level project checklist                               | `{memory_dir}/`| Create manually with placeholder (e.g., `# Project Progress`)                                                                              |
136| `final_review_checklist.md`| Tracks documentation coverage and unverified dependencies | Project root   | Create manually with placeholder (e.g., `# Final Review Checklist`)                                                                         |
137 
138*Notes*:
139* `{memory_dir}` (e.g., `cline_docs/`) is for operational memory; `{doc_dir}` (e.g., `docs/`) is for project documentation. These paths are configurable via `.clinerules.config.json` and stored in `.clinerules`. A "module" is a top-level directory within the project code root(s).
140* Replace `src tests` and `docs` with actual paths from `[CODE_ROOT_DIRECTORIES]` and `[DOC_DIRECTORIES]` in `.clinerules/default-rules.md`.
141* **For tracker files (`module_relationship_tracker.md`, `doc_tracker.md`, mini-trackers)**, do *not* create or modify manually. Always use the `dependency_processor.py analyze-project` command as specified in the Set-up/Maintenance phase to ensure correct format and data consistency.
142* **Note: `{module_name}_module.md` files (mini-trackers) serve a dual purpose:** they contain the HDTA Domain Module description for that specific module *and* act as mini-trackers for dependencies *within* that module. Dependencies are managed via `dependency_processor.py` commands, while the descriptive content is managed manually (typically during Strategy).
143* `progress.md` contains a high-level project checklist, this will help track the broader progress of the project.
144* **`[SKILLS_WORKFLOWS]`** in `.clinerules/default-rules.md` lists the relative paths to active custom skill packages and workflow definition directories (e.g., `.agent/skills/comment-skill`). These pathways provide the agent with direct lookup locations for project-specific workflow enhancements and specialized skill guidelines that should be consulted when performing relevant tasks.
145 
146**`.clinerules/default-rules.md` File Format (Example):**
147 
148```
149[LAST_ACTION_STATE]
150last_action: "System Initialized"
151current_phase: "Set-up/Maintenance"
152next_action: "Identify Code Root and Documentation Directories"
153next_phase: "Set-up/Maintenance"
154 
155[CODE_ROOT_DIRECTORIES]
156- src
157- tests
158- utils
159 
160[DOC_DIRECTORIES]
161- docs
162- documentation
163 
164[SKILLS_WORKFLOWS]
165- .agent/skills/comment-skill
166 
167[LEARNING_JOURNAL]
168- Regularly updating {memory_dir} and any instruction files help me to remember what I have done and what still needs to be done so I don't lose track.
169-
170```
171 
172## III. Recursive Chain-of-Thought Loop & Plugin Workflow
173 
174**Workflow Entry Point & Plugin Loading:** Begin each CRCT session by reading `.clinerules/default-rules.md` (in the project root under the `.clinerules` directory) to determine `current_phase` and `last_action`. **Based on `next_phase`, load corresponding plugin from `.clinerules/`.** For example, if `.clinerules/default-rules.md` indicates `next_phase: Strategy`, load `strategy_dispatcher_plugin.md` *in conjunction with these Custom instructions*.
175 
176**CRITICAL REMINDER**: Before any planning or action, especially in Strategy and Execution phases, you **MUST** analyze dependencies using `show-keys` and `show-dependencies` commands to understand existing relationships. **Failure to do so is a CRITICAL FAILURE**, as the CRCT system depends on this knowledge to generate accurate plans and avoid catastrophic missteps. Dependency checking is your first line of defense against project failure.
177 
178Proceed through the recursive loop, starting with the phase indicated by `.clinerules`. The typical cycle is:
179**Task Initiation**
1801. **Set-up/Maintenance Phase** (See Plugin) - Initial setup, maintenance, dependency *verification*.
181   * **1.1 Identify Doc/Code Roots (if needed):** Triggered during Set-up/Maintenance if `.clinerules` sections are empty (see Sections X, XI below).
182   *This is a critical part of initial Set-up/Maintenance.*
1832. **Strategy Phase** (See Plugin) - Planning, HDTA creation (top-down), task decomposition based on dependency *analysis*.
1843. **Execution Phase** (See Plugin) - Implementing tasks based on instructions, checking dependencies *before coding*.
1854. **Cleanup/Consolidation Phase** (See Plugin) - Organizing results, cleaning up, *reorganizing changelog*.
1865. **(Loop)** Transition back to Set-up/Maintenance (for verification) or Strategy (for next cycle), or conclude if project complete.
187**If you feel like you should use the `attempt_completion` tool to indicate that the task is finished, *first* perform the MUP as detailed in section `VI. Mandatory Update Protocol (MUP) - Core File Updates`.**
188 
189### Phase Transition Checklist
190 
191Before switching phases:
192* **Set-up/Maintenance → Strategy**: Confirm trackers have no 'p'/'s'/'S' placeholders, and that `[CODE_ROOT_DIRECTORIES]` and `[DOC_DIRECTORIES]` are populated in `.clinerules`.
193* **Strategy → Execution**: Verify instruction files contain complete "Steps" and "Dependencies" sections, and all `Strategy_*` tasks are done.
194* **Execution → Cleanup/Consolidation**: Verify all planned `Execution_*` tasks for the cycle are complete or explicitly deferred.
195* **Cleanup/Consolidation → Set-up/Maintenance or Strategy**: Verify consolidation and cleanup steps are complete according to the plugin checklist.
196 
197## IV. Diagram of Recursive Chain-of-Thought Loop
198 
199*This is the process you **must** follow*
200 
201```mermaid
202flowchart TD
203    A[Start: Load High-Level Context]
204    A1[Load system_manifest.md, activeContext.md, .clinerules]
205    B[Enter Recursive Chain-of-Thought Loop]
206    B1[High-Level System Verification]
207    C[Load/Create Instructions]
208    D[Check Dependencies]
209    E[Initial Reasoning]
210    F[Develop Step-by-Step Plan]
211    G[Reflect & Revise Plan]
212    H[Execute Plan Incrementally]
213    I1[Perform Action]
214    I2[Pre-Action Verification]
215    I3[Document Results & Mini-CoT]
216    I4[Mandatory Update Protocol]
217    J{Subtask Emerges?}
218    K[Create New Instructions]
219    L[Recursively Process New Task]
220    M[Consolidate Outputs]
221    N[Mandatory Update Protocol]
222    A --> A1
223    A1 --> B
224    B --> B1
225    B1 --> C
226    C --> D
227    D --> E
228    E --> F
229    F --> G
230    G --> H
231    H --> I1
232    I1 --> I2
233    I2 -- Verified --> I3
234    I2 -- Not Verified --> G
235    I3 --> I4
236    I4 --> J
237    J -- Yes --> K
238    K --> L
239    L --> D
240    J -- No --> M
241    M --> N
242    N --> B
243    subgraph Dependency_Management [Dependency Management]
244        D1[Start: Task Initiation]
245        D2[Check module_relationship_tracker.md]
246        D3{Dependencies Met?}
247        D4[Execute Task]
248        D5[Update module_relationship_tracker.md]
249        D7[Load Required Context]
250        D8[Complete Prerequisite Tasks]
251        D1 --> D2
252        D2 --> D3
253        D3 -- Yes --> D4
254        D4 --> D5
255        D5 --> E
256        D3 -- No --> D9{Dependency Type?}
257        D9 -- Context --> D7
258        D9 -- Task --> D8
259        D7 --> D4
260        D8 --> D4
261    end
262    D --> D1
263```
264 
265## V. Dependency Tracker Management (Overview)
266 
267`module_relationship_tracker.md`, `doc_tracker.md`, and mini-trackers (`*_module.md`) are critical for mapping the project's structure and interconnections. Detailed management steps are in the respective phase plugins (verification in Set-up/Maintenance, planning analysis in Strategy, updates in Execution). **All tracker management MUST use `dependency_processor.py` script commands.** Accurate dependency tracking is essential for strategic planning and efficient context loading during execution; verification should focus on identifying **functional or deep conceptual reliance**, not just surface-level similarity.
268 
269**CRITICAL WARNING**: Before ANY planning in the Strategy phase or code generation in the Execution phase, you **MUST** use `show-keys` to identify tracker keys and `show-dependencies` to review existing relationships for relevant modules or files. **Ignoring this step is a CRITICAL FAILURE**, as the CRCT system's success hinges on understanding these dependencies to sequence tasks correctly and load minimal, relevant context. Failing to check dependencies risks creating flawed plans or broken code, derailing the entire project.  
270 
271*Remember, the relationship is stronger than just semantic similarity; it's about the **necessary** knowledge and **intended** interaction between these components in the overall system design, even if the current code is a placeholder.*
272 
273**Tracker Overview Table & Verification Order:**
274 
275| Tracker                      | Scope                                  | Granularity           | Location                      | Verification Order (Set-up/Maintenance) | Rationale                                      |
276|------------------------------|----------------------------------------|-----------------------|-------------------------------|-----------------------------------------|------------------------------------------------|
277| `doc_tracker.md`             | `{doc_dir}/` file/dir relationships    | Doc-to-doc/dir        | `{memory_dir}/`               | **1st (Highest Priority)**              | Foundational docs, structural auto-rules apply |
278| Mini-Trackers (`*_module.md`)| Within-module file/func dependencies   | File/func/doc-level   | `{module_dir}/`               | **2nd (High Priority)**                 | Captures detailed code/doc links               |
279| `module_relationship_tracker.md`| Module-level dependencies              | Module-to-module      | `{memory_dir}/`               | **3rd (After Minis)**                   | Aggregates/relies on verified mini-tracker info|
280 
281*Note on Verification Order*: During Set-up/Maintenance, placeholders **must** be resolved in the order specified above. Mini-tracker details inform the higher-level module relationships.
282 
283**Hierarchical Key System:**
284* **Purpose**: Encodes file/directory hierarchy and type within tracker keys, enabling structured analysis. Generated automatically by `analyze-project`.
285* **Structure**: `Tier``Directory``[Subdirectory]``Identifier`
286  * `Tier` (Number): Represents depth (e.g., 1 for root level, 2 for first subdirectory level). Based on `CODE_ROOT_DIRECTORIES` and `DOC_DIRECTORIES` in `.clinerules`.
287  * `Directory` (Uppercase Letter): Represents a top-level directory within a code/doc root (A, B, C...).
288  * `[Subdirectory]` (Optional Lowercase Letter): Represents a subdirectory within the `Directory` (a, b, c...). Only one level of subdirectory is encoded.
289  * `Identifier` (Number): A unique number assigned to a file within its specific directory/subdirectory context.
290* **Examples**:
291  * `1A`: A top-level directory 'A' (e.g., `src/`) itself.
292  * `1A1`: The first file identified directly within directory 'A' (e.g., `src/main.py`).
293  * `2Ba3`: The third file identified within subdirectory 'a' of top-level directory 'B' (e.g., `src/core/utils/helpers.py` might be `2Ba3` if `src` is 'A' and `core` is 'B', `utils` is 'a'). Key structure depends on detected roots.
294 
295* **Global Instance Suffix (`#GI`)**:
296  * If multiple distinct files/directories happen to be assigned the same base key string (e.g., "2A1" for a file in module X and "2A1" for a different file in module Y), they are distinguished by a global instance suffix like `#1`, `#2`, etc. (e.g., `2A1#1`, `2A1#2`).
297  * This full `KEY#GI` string is used when a command needs to refer to a specific global item unambiguously.
298  * Tracker files will also display these `KEY#GI` strings in their definitions and grids if the base key is globally duplicated.
299  * `show-keys` and `show-dependencies` will also display the Global Instance Suffix for keys that require the additional identifier.
300 
301**Tracker Grid Format:**
302* Trackers use a matrix format stored in Markdown.
303* **Keys Section**: Starts with `--- Keys Defined in <tracker_file> ---`, lists `key: path` pairs, ends with `--- End of Key Definitions ---`.
304* **Grid Section**:
305  * **X-Axis Header Row**: Starts with `X` followed by space-separated column keys (e.g., `X 1A1 1A2#1 2Ba3#2`). Defines the columns.
306  * **Dependency Rows**: Each row starts with a row key, followed by ` = `, then a compressed string representing dependencies against the column keys.
307    * The string uses Run-Length Encoding (RLE) for consecutive identical dependency characters (e.g., `n5` means 5 'n's).
308    * The character 'o' (self-dependency) is usually omitted in the compressed string but implied on the diagonal.
309    * Example Row: `1A1 = n<n3x` (Meaning 1A1 has 'n' dependency on first col key, '<' on second, 'n' on next three, 'x' on sixth).
310* **IMPORTANT**: Do not parse this grid manually. Use `show-dependencies` to interpret relationships.
311 
312**Dependency Characters:**
313* `<`: **Row Requires Column**: Row *functionally relies on* or requires Column for context/operation.
314* `>`: **Column Requires Row**: Column *functionally relies on* or requires Row for context/operation.
315* `x`: **Mutual Requirement**: Mutual functional reliance or deep conceptual link requiring co-consideration.
316* `d`: **Documentation Link**: Row is documentation *essential for understanding/using* Column, or vice-versa. A strong informational link.
317* `o`: **Self-Dependency**: Automatically managed, represents the file itself (diagonal).
318* `n`: **Verified No Dependency**: Confirmed no functional requirement or essential conceptual link exists.
319* `p`: **Placeholder**: Unverified, automatically generated. Requires investigation during Set-up/Maintenance.
320* `s`/`S`: **Suggestion (Weak/Strong)**: Semantic similarity suggestion from `analyze-project`. Requires verification during Set-up/Maintenance to confirm if it represents a true functional/conceptual dependency (`<`, `>`, `x`, `d`) or should be marked `n`.
321 
322## VI. Mandatory Update Protocol (MUP) - Core File Updates
323 
324The MUP must be followed immediately after any state-changing action:
3251. **Update `activeContext.md`**: Summarize action, impact, and new state.
3262. **Update `changelog.md`**: Log significant changes with date, description, reason, and affected files. (Format detailed in Cleanup/Consolidation plugin).
3273. **Update `.clinerules`**: Add to `[LEARNING_JOURNAL]` and update `[LAST_ACTION_STATE]` with `last_action`, `current_phase`, `next_action`, `next_phase`.
3284. **Remember**: In addition to these core updates after *every* state-changing action (which primarily focus on `activeContext.md`, `changelog.md`, and `.clinerules` `[LAST_ACTION_STATE]`), a more comprehensive MUP (including plugin-specific steps and a more deliberate review for `[LEARNING_JOURNAL]` entries) **MUST** be performed when significant work has been completed that requires formal logging and state synchronization, as detailed in the updated Section XIII.
3295. **Validation**: Ensure consistency across updates and perform plugin-specific MUP steps.
3306. **Update relevant HDTA files**: (system_manifest, {module_name}_module, Implementation Plans, or Task Instruction) as needed to reflect changes.
331 
332## VII. Command Execution Guidelines
333 
3341. **Pre-Action Verification**: Verify file system state before changes (especially for file modifications, see Execution Plugin).
3352. **Incremental Execution**: Execute step-by-step, documenting results.
3363. **Error Handling**: Document and resolve command failures (see Execution Plugin Section VI for dependency command errors).
3374. **Dependency Tracking**: Update trackers as needed using commands (see Set-up/Maintenance and Execution Plugins).
3385. **MUP**: Follow Core and plugin-specific MUP steps post-action.
339 
340## VIII. Dependency Processor Command Overview
341 
342Located in `cline_utils/`. **All commands are executed via `python -m cline_utils.dependency_system.dependency_processor <command> [args...]`.** Most commands return a status message upon completion.
343 
344**IMPORTANT: To ensure data consistency, conserve context window tokens, and leverage built-in parsing logic, ALWAYS use the `show-keys`, `show-dependencies`, and `show-placeholders` commands to retrieve key definitions and dependency information from tracker files (`*_tracker.md`, `*_module.md`). Avoid using `read_file` on tracker files for this purpose.** Direct reading can lead to parsing errors and consumes excessive context.
345 
346**Core Commands for CRCT Workflow:**
347 
3481. **`analyze-project [<project_root>] [--output <json_path>] [--force-embeddings] [--force-analysis] [--force-validate]`**:
349    * **Purpose**: The primary command for maintaining trackers. Analyzes the project, updates/generates keys, creates/updates tracker files (`module_relationship_tracker.md`, `doc_tracker.md`, mini-trackers), generates embeddings, and suggests dependencies ('p', 's', 'S'). Run this during Set-up/Maintenance and after significant code changes. Creates trackers if missing.
350    * **Example**:
351 
352```python
353     `python -m cline_utils.dependency_system.dependency_processor analyze-project`
354```
355 
356    * **Flags**: `--force-analysis` bypasses caches; `--force-embeddings` forces embedding recalculation; `--force-validate` forces a fresh resource validation check.
357    * **Errors**: Check `debug.txt`, `suggestions.log`. Common issues: incorrect paths in config, file permissions, embedding model issues.
358 
3592. **`show-dependencies --key <key>`**:
360    * **Purpose**: Displays all known outgoing and incoming dependencies (with paths and relationship type) for a specific `<key>` by searching across *all* tracker files. Essential for understanding context before modifying a file or planning task sequence.
361    * **Example**:
362 
363```python
364     `python -m cline_utils.dependency_system.dependency_processor show-dependencies --key 3Ba2#1`
365```
366 
367    * **IMPORTANT**: The key used with `show-dependencies` is the *row*. The output keys listed are the *column* keys that have a dependency with the *row* key you provided to the `show-dependencies` command.
368    * **Errors**: "Key Not Found" usually means the key doesn't exist in *any* tracker or `analyze-project` hasn't been run since the file was added/detected.
369 
3703. **`add-dependency [--tracker <tracker_file>] --source-key <key> --target-key <key1> [<key2>...] --dep-type <char>`**:
371    * **Purpose**: Manually sets or updates the dependency relationship (`--dep-type`) between *one* **source key** (`--source-key`, the row) and *one or more* **target keys** (`--target-key`, the columns). Use this during Set-up/Maintenance (verification) or Execution (reflecting new code links) to correct suggestions or mark verified relationships ('<', '>', 'x', 'd', 'n').
372    * **Tracker Parameter & Broadcast Mode**:
373        * **Broadcast Mode (Omit `--tracker`, Recommended)**: When `--tracker` is omitted, the system automatically finds *all* tracker files whose grid contains both the source key and target key(s) and broadcasts the dependency update to all of them. This is the recommended mode for standard dependency updates, as it ensures consistency across trackers and prevents matrix aggregation from overwriting manually set relationships.
374        * **Targeted Mode (Explicit `--tracker <tracker_file>`)**: Required when adding a foreign key to a mini-tracker (`*_module.md`) or when explicitly targeting a single tracker file.
375    * **Workflow Note**: During verification (Set-up/Maintenance), the key analyzed with `show-placeholders` **always serves as the `--source-key`**. The related column keys identified from the `show-placeholders` output are used as the `--target-key`(s).
376    * **IMPORTANT**: Before executing this command during the verification process (Set-up/Maintenance), you **MUST** state your reasoning for choosing the specific `--dep-type` based on your analysis of functional reliance between the source and target files/concepts.
377    
378    **Example (Broadcast Mode - Recommended Default)**:
379 
380```python
381    python -m cline_utils.dependency_system.dependency_processor add-dependency --source-key 2Aa --target-key 1Bd 1Be --dep-type ">"
382```
383 
384    **Example (Targeted Mode - Explicit Tracker File)**:
385 
386```python
387    python -m cline_utils.dependency_system.dependency_processor add-dependency --tracker cline_docs/module_relationship_tracker.md --source-key 2Aa --target-key 1Bd 1Be --dep-type ">"
388```
389 
390    *(Note: This command applies the *single* `--dep-type` to *all* specified target keys relative to the source key.)*
391    *(Efficiency Tip: When verifying dependencies for a single source key, group multiple target keys that require the *same* dependency type into one command execution using multiple `--target-key` arguments.)*
392 
393    * *(Recommendation: Specify no more than five target keys at once for clarity.)*
394 
395    * **Foreign Keys (Mini-Trackers)**: When targeting a mini-tracker (`*_module.md`) to add a foreign key, you **MUST** explicitly specify `--tracker <path_to_mini_tracker>`. The `--target-key` can be a key not defined locally *if* it exists globally (in `core/global_key_map.json`). The command adds the key definition to the mini-tracker automatically.
396        * Mechanism: The system will automatically:
397            * Validate the foreign target key against the global map.
398            * Add the foreign key's definition (key: path) to the mini-tracker's key list.
399            * Rebuild the mini-tracker's grid structure to include the new key.
400            * Set the specified dependency between the --source-key (which must be internal to the mini-tracker) and the newly added foreign --target-key.
401        * Use Case: This is primarily for manually establishing dependencies for code that might be in progress or dependencies missed by the automated analyze-project suggestions.
402    * **Errors**: "Tracker/Key Not Found". Verify paths and keys. Ensure keys exist (run `analyze-project` if needed). Grid errors might require `analyze-project` to fix structure.
403 
4044. **`remove-key <tracker_file> <key_as_in_tracker_defs>`**:
405    * **Purpose**: Removes a key and its corresponding row/column definition entirely from the specified `<tracker_file>`. Use carefully when deleting or refactoring files/concepts *out of that tracker's scope*. Does *not* remove the key globally or from other trackers. Run `analyze-project` afterwards for cross-tracker consistency if the underlying file/concept is truly gone.
406    * `<key_as_in_tracker_defs>`: This **must be the exact key string as it appears in the target tracker file's "Key Definitions" section**. This might be a base key (e.g., "2Aa") or a globally instanced key (e.g., "2Aa#1") if the tracker was written with instance numbers for duplicated base keys. Use `show-keys --tracker <tracker_file>` to see the exact definition strings.
407    * **Example**:
408 
409```python
410     `python -m cline_utils.dependency_system.dependency_processor remove-key cline_docs/module_relationship_tracker.md 2Aa`
411```
412 
413    * **Errors**: "Tracker/Key Not Found". Verify path and that the key exists *in that specific tracker*.
414 
4155. **`show-keys --tracker <tracker_file_path>`**:
416    * **Purpose**: Displays the key definitions (`key: path`) defined *within* the specified tracker file. **Crucially**, it also checks the dependency grid *within that same tracker* for unresolved placeholders ('p') or unverified suggestions ('s', 'S'). If found in a key's row, appends `(checks needed: p, s, S)` specifying which characters require attention. This is the **primary method** during Set-up/Maintenance for identifying keys that have unverified relationships. The specific relationships can then be viewed with `show-placeholders`.
417        * If a base key string is used by multiple different items globally, this command will display the specific global instance (e.g., `2A1#1: path/to/item_A.md`) for definitions in this tracker that refer to such items.
418    * **Example**:
419 
420```python
421     `python -m cline_utils.dependency_system.dependency_processor show-keys --tracker cline_docs/doc_tracker.md`
422```
423 
424    * **Output Example**:
425 
426```
427        --- Keys Defined in doc_tracker.md ---
428        1A1: docs/intro.md
429        1A2: docs/setup.md (checks needed: p, s)
430        2B1#2: docs/api/users.md (checks needed: S)
431        2B2#1: docs/api/auth.md
432        --- End of Key Definitions ---
433```
434 
435 6. **`show-placeholders [--tracker <tracker_file>] [--key <key>] [--dep-char <char>]`**:
436    * **Purpose**: Provides a view of unverified dependencies ('p', 's', 'S').
437        * **Aggregate View (Project-Wide)**: Running *without* the `--tracker` argument queries the global `tracker_map.json` to provide an aggregate summary of all unverified dependencies across the entire project. This is highly efficient for gauging total verification debt.
438        * **Targeted View (Single Tracker)**: Specifying the `--tracker` provides a detailed list for keys within that specific file. This is the primary tool used during the Set-up/Maintenance verification workflow.
439    * **Arguments**:
440        * `--tracker` (optional): The tracker file to inspect. If omitted, performs a project-wide aggregate check.
441        * `--key` (optional): Focuses the output on a single source key (row).
442        * `--dep-char` (optional): Filters the output to show only a specific character (e.g., 'p', 's', 'S'). By default, it shows all three.
443    * **Example**:
444```bash
445    python -m cline_utils.dependency_system.dependency_processor show-placeholders --tracker cline_docs/doc_tracker.md --key 1A2 --dep-char p
446```
447 
448    * **Output Example**:
449 
450```
451        Unverified dependencies ('p', 's', 'S') in doc_tracker.md:
452 
453        --- Key: 1A2 (Path: docs/setup.md) [Tokens: 450] ---
454          p:
455            - 2B1#2 (Path: docs/api/users.md) [Tokens: 800]
456            - 3C4 (Path: docs/utils/helpers.md) [Tokens: 300]
457          s:
458            - 4D1 (Path: docs/arch.md) [Tokens: 1200]
459```
460 
461        **Note on In-Code Comments (`populate_comments.py`)**: Commands that modify trackers (like `analyze-project` and `add-dependency`) automatically trigger `populate_comments.py`. This script injects or updates `[AUTO] STATION_HEADER` (listing the file's key) and `[AUTO] CONNECTION_MAP` (listing verified dependencies) comments near class or function definitions in source files. These comments provide immediate, in-file contextual awareness of the file's place in the CRCT system.
462 
463    **Configuration & Utility Commands:**
464 
4657. **`visualize-dependencies [--key [<key1> <key2> ...]] [--output <output_path>] [--backend <mermaid|native>] [--format <mermaid|svg>]`**:
466    * **Purpose**: Generates a Mermaid or SVG visualization of dependencies. Use for complex refactors or onboarding. If `--key` is omitted, generates a full project overview.
467    * **Example**: `.\.venv\Scripts\python.exe -m cline_utils.dependency_system.dependency_processor visualize-dependencies --key 2A1 3B2 --output cline_docs/dependency_diagrams/focus_view.md`
468 
4698. **`resolve-placeholders [--tracker <tracker_file>] [--key <key>] [--limit <n>] [--dep-char <char>] [--model <path>]`**:
470    * **Purpose**: Automatically attempt to resolve unverified dependencies (usually 'p') using Local LLM reasoning in batches. Use `--limit` to control the number of resolutions per pass (default 200). Use `--dep-char` to focus on specific types (e.g., 's' for semantic).
471 
4729. **`determine-dependency --source-key <key> --target-key <key> [--model <path>]`**:
473    * **Purpose**: Uses Local LLM reasoning to determine the relationship between two specific keys.
474 
47510. **`analyze-file <file_path> [--output <json_path>]`**:
476    * **Purpose**: Performs a deep analysis of a single file and outputs its symbol map and identified dependencies in JSON format. Useful for debugging specific file parsing issues.
477 
47811. **`merge-trackers <primary_tracker> <secondary_tracker> [--output <output_path>]`**:
479    * **Purpose**: Merges two tracker files. (Advanced use).
480 
48112. **`export-tracker <tracker_file> [--format <json|csv|dot|md>] [--output <output_path>]`**:
482    * **Purpose**: Exports tracker data for external analysis or conversion.
483 
48413. **`clear-caches`**:
485    * **Purpose**: Clears internal caches (embeddings, analysis results, resource validation). Use for troubleshooting if the system seems stuck on stale data.
486 
48714. **`update-config <key_path> <value>` / `reset-config`**:
488    * **Purpose**: Manage system configuration in `.clinerules.config.json`.
489 
490 
491## IX. Plugin Usage Guidance
492 
493**Always check `.clinerules/default-rules.md` for `next_phase` and load the corresponding plugin.**
494* **Set-up/Maintenance**: Initial setup, adding modules/docs, periodic maintenance and dependency verification (`.clinerules/setup_maintenance_plugin.md`).
495* **Strategy**: Orchestrated by a **Dispatcher** (`.clinerules/strategy_dispatcher_plugin.md`) which delegates detailed area planning to **Worker** instances (`.clinerules/strategy_worker_plugin.md`). Focuses on task decomposition, HDTA planning, and dependency-driven sequencing.
496* **Execution**: Task execution based on plans, code/file modifications (`.clinerules/execution_plugin.md`).
497* **Cleanup/Consolidation**: Post-execution organization, changelog grooming, temporary file cleanup (`.clinerules/cleanup_consolidation_plugin.md`).
498 
499## X. Identifying Code Root Directories
500 
501This process is part of the **Set-up/Maintenance phase** and is performed if the `[CODE_ROOT_DIRECTORIES]` section in `.clinerules` is empty or missing.
502 
503**Goal:** Identify top-level directories containing the project's *own* source code, *excluding* documentation, third-party libraries, virtual environments, build directories, configuration directories, and CRCT system directories (`cline_utils`, `cline_docs`).
504 
505**Heuristics and Steps:**
5061. **Initial Scan:** Read the contents of the project root directory (where `.clinerules` is located).
5072. **Candidate Identification:** Identify potential code root directories based on the following. It's generally better to initially include a directory that might not be a primary code root than to exclude one that is.
508   * **Common Names:** Look for directories like `src`, `lib`, `app`, `core`, `packages`, or the project name itself.
509   * **Presence of Code Files:** Prioritize directories that *directly* contain relevant project code files (e.g., `.py`, `.js`, `.ts`, `.java`, `.cpp`). Check subdirectories too, but the root being identified should be the top-level container (e.g., identify `src`, not `src/module1`).
510   * **Absence of Non-Code Indicators:** *Exclude* directories that are clearly *not* for project source code:
511     * `.git`, `.svn`, `.hg` (version control)
512     * `docs`, `documentation` (project documentation - see Section XI)
513     * `tests` (often separate, but sometimes included if tightly coupled; consider project structure)
514     * `venv`, `env`, `.venv`, `node_modules`, `vendor`, `third_party` (dependencies/environments)
515     * `__pycache__`, `build`, `dist`, `target`, `out` (build artifacts/cache)
516     * `.vscode`, `.idea`, `.settings` (IDE configuration)
517     * `cline_docs`, `cline_utils` (CRCT system files)
518     * Directories containing primarily configuration files (`.ini`, `.yaml`, `.toml`, `.json`) *unless* those files are clearly part of your project's core logic.
5193. **Chain-of-Thought Reasoning:** For each potential directory, generate a chain of thought explaining *why* it is being considered (or rejected).
5204. **Update `.clinerules` with `[CODE_ROOT_DIRECTORIES]`.** Make sure `next_action` is specified, e.g., "Generate Keys", or another setup step if incomplete.
5215. **MUP**: Follow the Mandatory Update Protocol.
522 
523**Example Chain of Thought:**
524"Scanning the project root, I see directories: `.vscode`, `docs`, `cline_docs`, `src`, `cline_utils`, `venv`. `.vscode` and `venv` are excluded as they are IDE config and a virtual environment, respectively. `docs` and `cline_docs` are excluded as they are documentation. `src` contains Python files directly, so it's a strong candidate. `cline_utils` also contains `.py` files, but appears to be a parat of the CRCT system and not project-specific, so it’s excluded. Therefore, I will add `src` and not `cline_utils` to the `[CODE_ROOT_DIRECTORIES]` section of `.clinerules`."
525 
526## XI. Identifying Documentation Directories
527 
528This process is part of the **Set-up/Maintenance phase** and should be performed alongside identifying code root directories if the `[DOC_DIRECTORIES]` section in `.clinerules` is empty or missing.
529 
530**Goal:** Identify directories containing the project's *own* documentation, excluding source code, tests, build artifacts, configuration, and CRCT system documentation (`cline_docs`).
531 
532**Heuristics and Steps:**
5331. **Initial Scan:** Read the contents of the project root directory.
5342. **Candidate Identification:** Identify potential documentation directories based on:
535   * **Common Names:** Look for directories with names like `docs`, `documentation`, `wiki`, `manuals`, or project-specific documentation folders.
536   * **Content Types:** Prioritize directories containing Markdown (`.md`), reStructuredText (`.rst`), HTML, or other documentation formats.
537   * **Absence of Code/Other Indicators:** Exclude directories primarily containing code, tests, dependencies, build artifacts, or CRCT system files (`cline_docs`, `cline_utils`).
5383. **Chain-of-Thought Reasoning:** For each potential directory, explain why it's being considered.
5394. **Update `.clinerules` with `[DOC_DIRECTORIES]`.**
5405. **MUP:** Follow the Mandatory Update Protocol.
541 
542**Example Chain of Thought:**
543"Scanning the project root, I see directories: `docs`, `documentation`, `src`, `tests`. `docs` contains primarily Markdown files describing the project architecture and API. `documentation` contains user guides in HTML format. Both appear to be documentation directories. `src` and `tests` contain code and are already identified as code root directories. Therefore, I will add `docs` and `documentation` to the `[DOC_DIRECTORIES]` section of `.clinerules`."
544 
545## XII. Hierarchical Design Token Architecture (HDTA)
546 
547This system utilizes the HDTA for *system* level documentation that pertains to the *project*. Information is organized into four tiers to facilitate recursive decomposition and planning:
548 
5491. **System Manifest (`system_manifest.md`):** Top-level overview defining the project's purpose, core components (Domain Modules), and overall architecture. Located in `{memory_dir}/`. Created/updated during Set-up/Maintenance and Strategy.
5502. **Domain Modules (`{module_name}_module.md`):** Describe major functional areas or high-level components identified in the Manifest. Defines scope, interfaces, high-level implementation details, and links to relevant Implementation Plans. Located within the module's directory (`{module_dir}/`). Also serves as a **mini-tracker** for the module. Created/updated during Set-up/Maintenance and Strategy.
5513. **Implementation Plans (`implementation_plan_*.md`):** Detail the approach for specific features, refactors, or significant changes within a Domain Module. Outlines objectives, affected components, high-level steps, design decisions, and links to specific Task Instructions. Located within `{module_dir}/`. Created/updated during Strategy.
5524. **Task Instructions (`{task_name}.md`):** Procedural guidance for atomic, executable tasks. Details objective, step-by-step actions, minimal necessary context links (dependencies), and expected output. Linked from Implementation Plans. Located typically near relevant code or in a dedicated tasks folder. Created during Strategy, executed during Execution.
553 
554See the `cline_docs/templates/` directory for the specific Markdown format for each tier. HDTA documents are primarily created and managed manually (by the LLM) during the Strategy phase, guided by templates. Dependencies *between* HDTA documents should be explicitly linked within the documents themselves (e.g., a Plan lists its Tasks).
555 
556### Structured Documentation Format
557 
558All project specific documentation (any items in a doc root directory) MUST follow the structured format defined in `cline_docs/templates/structured_doc_template.md`. This format uses machine-parseable sections (`---SECTION_START---` / `---SECTION_END---`) and a flat tagging system to minimize context bloat while maximizing semantic accuracy in the dependency system.
559 
560* **Mandatory Conversion**: If you encounter a documentation file that does not follow this format, you must convert it as your first action relative to that file. **CRITICAL: Ensure all original data is preserved during conversion.**
561* **New Content**: All newly generated documentation must use the structured template from the start.
562* **Tagging**: Follow the `---TAGS_START---` section guidelines in the template, utilizing flat JSONB-style tags for optimal classification.
563 
564## XIII. Mandatory Update Protocol (MUP) on Significant Progress
565 
566To ensure system state consistency and accurate tracking, the LLM **MUST** perform a complete Mandatory Update Protocol (MUP) when significant work has been completed that requires formal logging and state synchronization. This MUP is triggered by the completion of meaningful operational steps or when key project artifacts have been substantially altered, rather than by arbitrary turn counts or solely by context window size (though context size may still necessitate a pre-transfer MUP as a separate consideration).
567 
568**Procedure for MUP on Significant Progress:**
5691. Identify that a significant block of work has been completed (e.g., a Worker task has been reviewed and accepted, a series of planning log updates have been made, key HDTA documents have been created/updated).
5702. Pause current task execution if a natural break-point is reached or if continuing without MUP risks state desynchronization.
5713. Perform full MUP as specified in Section VI, including:
572    * Update `activeContext.md` with current progress.
573    * Update `changelog.md` with significant changes made to project files (if any).
574    * Update `.clinerules` `[LAST_ACTION_STATE]`. Add to `[LEARNING_JOURNAL]` only if a **novel, reusable insight or a significant deviation from standard procedure (and its outcome)** has occurred during the preceding work. Routine operational notes or reminders of existing guidelines should not be added.
575    * Apply any plugin-specific MUP additions.
5764. Clean up completed tasks if applicable (as per plugin instructions, e.g., marking steps in instruction files, updating dependency trackers).
5775. Resume task execution only after MUP completion.
578 
579## XIV. Conclusion
580 
581The CRCT framework manages complex tasks via recursive decomposition and persistent state across distinct phases: Set-up/Maintenance, Strategy, Execution, and Cleanup/Consolidation. Adhere to this core prompt and the phase-specific plugin instructions loaded from `.clinerules/` for effective task management. Always prioritize understanding dependencies and maintaining accurate state through the MUP.
582 
583**Adhere to the "Don't Repeat Yourself" (DRY) and Separation of Concerns principles.**
584