Cline rules

1# **Cline Recursive Chain-of-Thought System (CRCT) - Set-up/Maintenance Plugin**
2 
3**This Plugin provides detailed instructions and procedures for the Set-up/Maintenance phase of the CRCT system. It should be used in conjunction with the Core System Prompt.**
4 
5## I. Entering and Exiting Set-up/Maintenance Phase
6 
7**Entering Set-up/Maintenance Phase:**
8 
91. **Initial State**: Start here for new projects or if `.clinerules` shows `next_phase: "Set-up/Maintenance"`.
102. **`.clinerules` Check**: Always read `.clinerules` first. If `[LAST_ACTION_STATE]` indicates `current_phase: "Set-up/Maintenance"` or `next_phase: "Set-up/Maintenance"`, proceed with these instructions, resuming from the `next_action` if specified.
113. **New Project**: If `.clinerules` is missing/empty, assume this phase, create `.clinerules` (see Section II), and initialize other core files.
12 
13**Exiting Set-up/Maintenance Phase:**
14 
151. **Completion Criteria:**
16    * All core files exist and are initialized (Section II).
17    * `[CODE_ROOT_DIRECTORIES]` and `[DOC_DIRECTORIES]` are populated in `.clinerules` (Core Prompt Sections X & XI).
18    * `doc_tracker.md` exists and has no 'p', 's', or 'S' placeholders remaining (verified via `show-keys` in Section III, Stage 1).
19    * All mini-trackers (`*_module.md`) exist and have no 'p', 's', or 'S' placeholders remaining (verified via `show-keys` in Section III, Stage 2).
20    * `module_relationship_tracker.md` exists and has no 'p', 's', or 'S' placeholders remaining (verified via `show-keys` in Section III, Stage 3).
21    * **Code-Documentation Cross-Reference completed (Section III, Stage 4), ensuring essential 'd' links are added.**
22    * `system_manifest.md` is created and populated (at least minimally from template).
23    * Mini-trackers are created/populated as needed via `analyze-project`.
242. **`.clinerules` Update (MUP):** Once all criteria are met, update `[LAST_ACTION_STATE]` as follows:
25 
26```markdown
27    last_action: "Completed Set-up/Maintenance Phase"
28    current_phase: "Set-up/Maintenance"
29    next_action: "Phase Complete - User Action Required"
30    next_phase: "Strategy"
31```
32 
333. **User Action**: After updating `.clinerules`, pause for user to trigger the next session/phase. Refer to Core System Prompt, Section III for the phase transition checklist.
34 
35## II. Initializing Core Required Files & Project Structure
36 
37**Action**: Ensure all core files exist, triggering their creation if missing according to the specifications in the Core System Prompt (Section II).
38 
39**Procedure:**
40 
411. **Check for Existence**: Check if each required file listed in Core Prompt Section II (`.clinerules`, `system_manifest.md`, `activeContext.md`, `module_relationship_tracker.md`, `changelog.md`, `doc_tracker.md`, `userProfile.md`, `progress.md`) exists in its specified location.
422. **Identify Code and Documentation Directories**: If `[CODE_ROOT_DIRECTORIES]` or `[DOC_DIRECTORIES]` in `.clinerules` are empty or missing, **stop** other initialization and follow the procedures in Core Prompt Sections X and XI to identify and populate these sections first. Update `.clinerules` and perform MUP. Resume initialization checks afterwards.
433. **Trigger Creation of Missing Files:**
44    * **Manual Creation Files** (`.clinerules`, `activeContext.md`, `changelog.md`, `userProfile.md`, `progress.md`): If missing, use `write_to_file` to create them with minimal placeholder content as described in Core Prompt Section II table. State: "File `{file_path}` missing. Creating with placeholder content."
45        * Example Initial `.clinerules` (if creating):
46 
47```markdown
48            [LAST_ACTION_STATE]
49            last_action: "System Initialized"
50            current_phase: "Set-up/Maintenance"
51            next_action: "Initialize Core Files" # Or Identify Code/Doc Roots if needed first
52            next_phase: "Set-up/Maintenance"
53 
54            [CODE_ROOT_DIRECTORIES]
55            # To be identified
56 
57            [DOC_DIRECTORIES]
58            # To be identified
59 
60            [LEARNING_JOURNAL]
61            -
62```
63 
64    * **Template-Based File** (`system_manifest.md`): If missing, first use `write_to_file` to create an empty file named `system_manifest.md` in `{memory_dir}/`. State: "File `system_manifest.md` missing. Creating empty file." Then, read the template content from `cline_docs/templates/system_manifest_template.md` and use `write_to_file` again to *overwrite* the empty `system_manifest.md` with the template content. State: "Populating `system_manifest.md` with template content."
65    * **Tracker Files** (`module_relationship_tracker.md`, `doc_tracker.md`, and mini-trackers `*_module.md`):
66        * **DO NOT CREATE MANUALLY.**
67        * If any of these are missing, or if significant project changes have occurred, or if you are starting verification, run `analyze-project`. This command will create or update all necessary trackers based on the current project structure and identified code/doc roots.
68 
69```bash
70        # Ensure code/doc roots are set in .clinerules first!
71        python -m cline_utils.dependency_system.dependency_processor analyze-project
72```
73 
74        * State: "Tracker file(s) missing or update needed. Running `analyze-project` to create/update trackers."
75        * *(Running `analyze-project` is also the first step in the verification workflow in Section III)*.
76        * *(Optional: Add `--force-analysis` or `--force-embeddings` if needed)*.
77        * *(Mini-trackers in module directories are also created/updated by `analyze-project`)*.
784. **MUP**: Follow Core Prompt MUP (Section VI) and Section V additions below after creating files or running `analyze-project`. Update `[LAST_ACTION_STATE]` to reflect progress (e.g., `next_action: "Verify Tracker Dependencies"`).
79 
80## III. Analyzing and Verifying Tracker Dependencies (Ordered Workflow)
81 
82**DO NOT ASSUME A DEPENDENCY BEFORE THE RELATED FILES HAVE BEEN READ!!**
83 
84**Objective**: Ensure trackers accurately reflect project dependencies by systematically resolving placeholders ('p') and verifying suggestions ('s', 'S'), followed by an explicit code-to-documentation cross-referencing step. **This process MUST follow a specific order:**
85 
860. **Project-Wide Dependency Overview** (Aggregate check)
871. `doc_tracker.md` (Placeholder/Suggestion Resolution)
882. All Mini-Trackers (`*_module.md`) (Placeholder/Suggestion Resolution)
893. `module_relationship_tracker.md` (Placeholder/Suggestion Resolution)
904. **Code-Documentation Cross-Reference** (Adding explicit dependencies)
91 
92This order is crucial because Mini-Trackers capture detailed cross-directory dependencies within modules, which are essential for accurately determining the higher-level module-to-module relationships in `module_relationship_tracker.md`.
93 
94**IMPORTANT**:
95 
96* **All tracker modifications MUST use `dependency_processor.py` commands.** See Core Prompt Section VIII for command details.
97* **Do NOT read tracker files directly** for dependency information; use `show-keys` and `show-dependencies`.
98* Run `analyze-project` *before* starting this verification process if significant code/doc changes have occurred since the last run, or upon entering this phase (as done in Section II).
99 
100<<<**CRITICAL ORCHESTRATION RULE**>>>
101*The primary Set-up/Maintenance instance is an **orchestrator/dispatcher** for dependency verification. It is responsible for:*
102* *Running `dependency_processor.py` commands, preparing worker/subagent task instructions, reviewing returned results, and applying accepted relationships with `add-dependency`.*
103*The primary instance is **not** the default verifier of file-to-file relationships. Verification must be outsourced using this priority:*
1041. **`use_subagents`** (if available in the current interface)
1052. **`new_task`**
1063. **`resolve-placeholders`** (fallback when delegation tools are unavailable or failing)
1074. **Manual verification by the primary instance** (last resort only if all above options fail)
108*All delegated verification tasks must instruct the worker/subagent that its first action is to load and follow `.clinerules/setup_worker.md`.*
109*Neutrality requirement for delegated instructions is mandatory: delegated prompts must not suggest, bias, or imply an expected dependency type or expected existence/non-existence of a dependency.*
110 
111***CRITICAL EMPHASIS***: *It is critical that the documentation is **Exhaustively** cross-referenced against the code. The code cannot be completed properly if the docs that define it are not listed as a dependency. The following verification stages, especially Stage 4, are designed to achieve this.*
112 
113**This phase isn't about efficiency, it's about *accuracy*. This is a foundational job. If the accuracy in this phase is low, the entire project will suffer.**
114 
115**Procedure:**
116 
1171. **Run Project Analysis (Initial & Updates)**:
118    * Use `analyze-project` to automatically generate/update keys, analyze files, suggest dependencies ('p', 's', 'S'), and update *all* trackers (`module_relationship_tracker.md`, `doc_tracker.md`, and mini-trackers). This command creates trackers if they don't exist and populates/updates the grid based on current code/docs and configuration.
119    * **Verification of `system_manifest.md`**: After analysis, ensure `system_manifest.md` accurately lists all modules found. If `analyze-project` created new mini-trackers in directories not listed in the manifest, add them to the manifest. You will find a complete tracker list at `cline_utils/dependency_system/core/tracker_map.json` after running `analyze-project`. 
120 
121```bash
122    python -m cline_utils.dependency_system.dependency_processor analyze-project
123```
124 
125    * *(Optional: Add `--force-analysis` or `--force-embeddings` if needed, e.g., if configuration changed or cache seems stale)*.
126    * **Review logs (`debug.txt`, `suggestions.log`)** for analysis details and suggested changes, but prioritize the verification workflow below. State: "Ran analyze-project. Reviewing logs and proceeding with ordered verification."
127 
1282. **Stage 0: Project-Wide Dependency Overview**:
129    * Run the bare `show-placeholders` command to query `tracker_map.json` and gauge the total verification debt across the project before processing individual trackers.
130    
131```bash
132    python -m cline_utils.dependency_system.dependency_processor show-placeholders
133```
134    * State: "Performed project-wide dependency overview. Proceeding to individual tracker verification."
135 
1363. **Stage 1: Verify `doc_tracker.md`**:
137    * **A. Identify Keys Needing Verification**:
138        * Run `show-keys` for `doc_tracker.md`:
139 
140```bash
141          python -m cline_utils.dependency_system.dependency_processor show-keys --tracker &lt;path_to_doc_tracker.md&gt;
142```
143 
144          *(Use actual path, likely `{memory_dir}/doc_tracker.md` based on config)*
145        * Examine the output. Keys listed might be base keys (e.g., "1A1") or globally instanced keys (e.g., "2B1#1") if their base key string is used for multiple different paths in the project. Identify all lines ending with `(checks needed: ...)`. This indicates unresolved 'p', 's', or 'S' characters in that key's row *within this tracker*.
146        * Create a list of these keys needing verification for `doc_tracker.md`. If none, state this and proceed to Stage 2.
147    * **B. Verify Placeholders/Suggestions for Identified Keys**:
148        * **Automated Resolution (Optional)**:
149            * You may use the local LLM to resolve 'p' placeholders in batches before delegated verification or as part of fallback handling.
150            * Command: `python -m cline_utils.dependency_system.dependency_processor resolve-placeholders --tracker <path_to_doc_tracker.md>` (defaults to processing all 'p' placeholders).
151            * *(Optional args: `--limit 50`, `--key <key_string>`, `--dep-char p`)*.
152            * **Review**: Review the changes. The LLM will update 'p' to '<', '>', 'x', 'd', or 'n'.
153        * **Targeted Verification Orchestration**:
154            * Iterate through the list of keys from Step 2.A (or remaining keys after automation).
155            * For each `key_string` (row key):
156            * **Get Context**: Run `show-placeholders` targeting the current tracker and key. This command specifically lists the 'p', 's', and 'S' relationships for the given key *within this tracker*, providing a targeted list for verification.
157 
158```bash
159            python -m cline_utils.dependency_system.dependency_processor show-placeholders --tracker &lt;path_to_doc_tracker.md&gt; --key &lt;key_string&gt; --dep-char &lt;char&gt;
160```
161 
162            * **Determine Verification Approach**: Assess the number of target files to verify for this key.
163            * **Delegated Verification (Default - `use_subagents` preferred, `new_task` fallback)**:
164                * **Group Target Files**: Divide the target files into chunks of 5-10 files each. Group by dependency type ('p', 's', 'S') or by logical similarity to improve efficiency.
165                * **Select Delegation Tool (Strict Priority)**:
166                    * Use **`use_subagents`** if available in the current interface.
167                    * Otherwise use **`new_task`**.
168                    * If neither delegation tool is available/working, run `resolve-placeholders` for the tracker/key as fallback.
169                    * If all delegation/automation options fail, manual verification by the primary instance is allowed as a last resort.
170                **IMPORTANT**:
171                    * Instruction wording must remain neutral and evidence-first.
172                    * Do not suggest or imply a preferred dependency character before analysis.
173                    * Do not imply that any dependency does or does not exist before analysis.
174                * **Create Verification Task**: For each chunk, use the delegation payload structure below:
175 
176```markdown
177                    Dependency Verification Task for Key {key_string}
178 
179                    Source File
180                    Key: {key_string}
181                    Path: {source_file_path}
182 
183                    Task Objective
184                    Determine the dependency relationship between the source file and each target file listed below using the criteria from .clinerules/setup_worker.md.
185 
186                    Dependency Criteria (from setup_maintenance_plugin.md)
187                    < (Row Requires Column): Row relies on Column for context, logic, or operation
188                    > (Column Requires Row): Column relies on Row for context, logic, or operation
189                    x (Mutual Requirement): Mutual reliance or deep conceptual link requiring co-consideration
190                    d (Documentation/Conceptual): Row is documentation or defines the "Why/How" essential for Column (or vice-versa)
191                    n (Verified No Dependency): Confirmed NO relational, functional, or conceptual link exists
192 
193                    Target Files to Verify (Group {group_number})
194                    [List target keys and paths for this chunk]
195 
196                    Instructions
197                    0. MANDATORY FIRST ACTION: Load and follow .clinerules/setup_worker.md before doing any dependency analysis.
198                    1. Read the source file: {source_file_path}
199                    2. For each target file above:
200                       a. Read the target file
201                       b. Analyze the relationship (Functional, Logical, or Conceptual) between source and target
202                       c. Determine the appropriate dependency character (<, >, x, d, or n)
203                       d. State your reasoning for the chosen dependency type
204                    3. Provide a summary of your findings in the format:
205                       Key {key_string} Dependency Verification Results:
206 
207                       [Target Key] [Target Path] -> [Dependency Character]
208                       Reasoning: [Your reasoning]
209 
210                       [Repeat for each target file]
211 
212                    Important Notes
213                    - Apply the full relationship criteria from .clinerules/setup_worker.md.
214                    - Do not skip the required checks for relational and contextual necessity.
215                    
216                    Expected Output
217                    A clear summary of dependency determinations for all target files in this group with reasoning for each.
218```
219 
220                * **Wait for Task Completion**: Allow the delegated task to complete and return results.
221                * **Review Results**: Examine the returned dependency determinations and reasoning.
222                * **Apply Dependencies**: Use `add-dependency` to apply accepted verified relationships from the delegated task results.
223            * **Correct/Confirm Dependencies**: Use `add-dependency`. Omitting `--tracker` operates in **broadcast mode** (recommended default for standard dependencies), automatically updating all trackers containing both keys. Specify `--tracker <path_to_tracker.md>` if targeting a specific file or adding foreign keys to mini-trackers. The `--source-key` is always the `key_string` you are iterating on. The `--target-key` is the column key whose relationship you determined. Set the `--dep-type` based on your reasoned analysis. Batch multiple targets *for the same source key* if they share the *same new dependency type*.
224 
225```bash
226              # Example (Broadcast Mode - Recommended): Set '>' from 1A2 (source) to 2B1#3 (target) across all trackers containing both keys
227              # Reasoning: docs/setup.md (1A2) details steps required BEFORE using API described in docs/api/users.md (2B1). Thus, 2B1 depends on 1A2.
228              python -m cline_utils.dependency_system.dependency_processor add-dependency --source-key 1A2 --target-key 2B1#3 --dep-type ">"
229 
230              # Example (Targeted Mode): Set 'd' from 1A2 (source) to 3C1 (target) in specific tracker
231              # Reasoning: While not a code call, 3C1 contains the user stories that 1A2 implements. 1A2 requires 3C1 for conceptual alignment.
232              python -m cline_utils.dependency_system.dependency_processor add-dependency --tracker &lt;path_to_doc_tracker.md&gt; --source-key 1A2 --target-key 3C1 --dep-type &quot;d&quot;
233```
234 
235        * Repeat Step 2.B for all keys identified in Step 2.A.
236    * **C. Final Check**: Run `show-keys --tracker <path_to_doc_tracker.md>` again to confirm no `(checks needed: ...)` remain.
237    * **MUP**: Perform MUP. Update `last_action`. State: "Completed verification for doc_tracker.md. Proceeding to find and verify mini-trackers."
238 
2393. **Stage 2: Find and Verify Mini-Trackers (`*_module.md`)**:
240    * **A. Find Mini-Tracker Files**:
241        * **Goal**: Locate all `*_module.md` files within the project's code directories.
242        * **Get Code Roots**: Read the `[CODE_ROOT_DIRECTORIES]` list from `.clinerules`. If empty, state this and this stage cannot proceed.
243        * **Scan Directories**: For each code root directory, recursively scan its contents using `list_files` or similar directory traversal logic.
244        * **Identify & Verify**: Identify files matching the pattern `{dirname}_module.md` where `{dirname}` exactly matches the name of the directory containing the file (e.g., `src/user_auth/user_auth_module.md`).
245        * **Create List**: Compile a list of the full, normalized paths to all valid mini-tracker files found.
246        * **Report**: State the list of found mini-tracker paths. If none are found but code roots exist, state this and confirm that `analyze-project` ran successfully (as it should create them if modules exist). If none are found, proceed to Stage 3.
247    * **B. Iterate Through Mini-Trackers**: If mini-trackers were found:
248        * Select the next mini-tracker path from the list. State which one you are processing.
249        * **Repeat Verification Steps**: Follow the same sub-procedure as in Stage 1 (Steps 2.A and 2.B), but substitute the current mini-tracker path for `<path_to_doc_tracker.md>` in all commands (`show-keys`, `add-dependency`).
250            * **Identify Keys**: Use `show-keys --tracker <mini_tracker_path>`. List keys needing checks.
251            * **Verify Keys**: Iterate through keys needing checks. Use `show-placeholders` to get a targeted list of unverified dependencies *within this mini-tracker*.
252 
253```bash
254            python -m cline_utils.dependency_system.dependency_processor show-placeholders --tracker &lt;mini_tracker_path&gt; --key &lt;key_string&gt; --dep-char &lt;char&gt;
255```
256 
257            * **Determine Verification Approach**: Use the delegation-first workflow defined in Stage 1, Step 2.B (including tool priority, fallback chain, and neutrality constraints).
258            * **Delegated Verification**: As defined in Stage 1, Step 2.B.
259            * **Foreign Keys**: Remember, when using `add-dependency` on a mini-tracker, the `--target-key` can be an external (foreign) key if it exists globally (Core Prompt Section VIII). Use this to link internal code to external docs or code in other modules if identified during analysis. State reasoning clearly.
260 
261```bash
262              # Example: Set 'd' from internal code file 1Ba2 to external doc 1Aa6 in agents_module.md
263              # Reasoning: combat_agent.py (1Ba2) implements concepts defined in Multi-Agent_Collaboration.md (1Aa6), making doc essential.
264              python -m cline_utils.dependency_system.dependency_processor add-dependency --tracker src/agents/agents_module.md --source-key 1Ba2 --target-key 1Aa6 --dep-type &quot;d&quot;
265```
266 
267            * **Proactive External Links**: While analyzing file content, actively look for explicit references or clear conceptual reliance on *external* files (docs or other modules) missed by automation. Add these using `add-dependency` with the foreign key capability if a true dependency exists. State reasoning.
268        * **C. Final Check (Mini-Tracker)**: Run `show-keys --tracker <mini_tracker_path>` again to confirm no `(checks needed: ...)` remain for *this* mini-tracker.
269        * Repeat Step 3.B and 3.C for all mini-trackers in the list found in Step 3.A.
270    * **MUP**: Perform MUP after verifying all mini-trackers found. Update `last_action`. State: "Completed verification for all identified mini-trackers. Proceeding to module_relationship_tracker.md."
271 
2724. **Stage 3: Verify `module_relationship_tracker.md`**:
273    * Follow the same verification sub-procedure as in Stage 1 (Steps 2.A, 2.B, 2.C), targeting `<path_to_module_relationship_tracker.md>` (likely `{memory_dir}/module_relationship_tracker.md`).
274        * **Identify Keys**: Use `show-keys --tracker <path_to_module_relationship_tracker.md>`. List keys needing checks. If none, state this and verification is complete.
275        * **Verify Keys**: Iterate through keys needing checks.
276            * **Context**: Use `show-placeholders` to get the list of unverified module-level dependencies. When determining relationships here, rely heavily on the verified dependencies established *within* the mini-trackers during Stage 2, as well as the overall system architecture (`system_manifest.md`). A module-level dependency often arises because *some file within* module A depends on *some file within* module B. Read key module files/docs (`read_file`) only if mini-tracker context is insufficient.
277 
278```bash
279            python -m cline_utils.dependency_system.dependency_processor show-placeholders --tracker &lt;path_to_module_relationship_tracker.md&gt; --key &lt;key_string&gt;
280```
281 
282            * **Determine Verification Approach**: Use the delegation-first workflow defined in Stage 1, Step 2.B (including tool priority, fallback chain, and neutrality constraints).
283            * **Delegated Verification**:
284                * Provide module-level context from Stage 2 mini-tracker relationships and `system_manifest.md`.
285                * Require evidence-based reasoning for each proposed relationship in returned results.
286                * Keep instructions neutral and avoid any implied expected dependency outcome.
287            * **Correct/Confirm**: Use `add-dependency --tracker <path_to_module_relationship_tracker.md>` with appropriate arguments.
288        * **Final Check**: Run `show-keys --tracker <path_to_module_relationship_tracker.md>` again to confirm no checks needed remain.
289    * **MUP**: Perform MUP after verifying `module_relationship_tracker.md`. Update `last_action`. State: "Completed verification for module_relationship_tracker.md. Proceeding to Code-Documentation Cross-Reference."
290 
291*Keys must be set from each perspective, as each *row* has its own dependency list.*
292 
2931. **Stage 4: Code-Documentation Cross-Reference (Adding 'd' links)**:
294    * **Objective**: Systematically review code components and ensure they have explicit dependencies pointing to all essential documentation required for their understanding or implementation. This happens *after* initial placeholders/suggestions ('p', 's', 'S') are resolved in Stages 1-3.
295    * **A. Identify Code and Doc Keys**:
296        * Use `show-keys` on relevant trackers (mini-trackers, main tracker) to get lists of code keys.
297        * Use `show-keys --tracker <path_to_doc_tracker.md>` to get a list of documentation keys.
298        *The output keys might be `KEY` or `KEY#GI`. You need to resolve these to their specific global `KeyInfo` objects (paths and base keys) to perform the conceptual matching.*
299        * *(Alternatively, use internal logic based on `ConfigManager` and the global key map if more efficient)*.
300    * **B. Iterate Through Code Keys**:
301        * Select a code key (e.g., `code_key_string` representing a specific code file).
302        * **Identify Potential Docs**: Determine which documentation keys (`doc_key_string`) are potentially relevant to `code_key_string`. Consider:
303            * The module the code belongs to.
304            * Functionality described in the code file (`read_file <code_file_path>`).
305            * Existing dependencies shown by `show-dependencies --key <code_key_string>`.
306            * Look for comments in the code referencing specific documentation.
307            * Ask questions like, "Does this documentation provide valuable or useful information for understanding how the code is intended to operate?", and "Does the code need to be aware of this information to perform its intended function?".
308            * Conceptual links and future planned directions should be considered as well. The more information available to inform how the code operates in relation to the systems, the higher quality the end result will be.
309        * **Determine Verification Approach**: Use the delegation-first workflow defined in Stage 1, Step 2.B.
310        * **Delegated Verification**:
311            * Delegate determination of essential documentation links using neutral, evidence-first instructions.
312            * Review returned reasoning and apply accepted links bi-directionally with `add-dependency`.
313            * Add Code -> Doc and Doc -> Code links using the appropriate tracker targets. **Note**: Adding these `d` links automatically updates tracking in `final_review_checklist.md` and triggers `populate_comments.py` to inject `[AUTO] CONNECTION_MAP` comments near class/function definitions in the source files.
314        * Repeat for all relevant documentation keys for the current `code_key_string`.
315    * **C. Repeat for All Code Keys**: Continue Step 5.B until all relevant code keys have been reviewed against the documentation corpus.
316    * **MUP**: Perform MUP. Update `last_action`. State: "Completed Code-Documentation Cross-Reference."
317 
3182. **Completion**: Once all four stages are complete and `show-keys` reports no `(checks needed: ...)` for `doc_tracker.md`, all mini-trackers, and `module_relationship_tracker.md`, the tracker verification part of Set-up/Maintenance is done. Check if all other phase exit criteria (Section I) are met (e.g., core files exist, code/doc roots identified, system manifest populated). If so, prepare to exit the phase by updating `.clinerules` as per Section I.
319 
320*If a dependency is detected in **either** direction 'n' should not be used. Choose the best character to represent the directional dependency or 'd' if it is a more general documentation dependency.*
321 
322## IV. Set-up/Maintenance Dependency Workflow Diagram
323 
324```mermaid
325graph TD
326    A[Start Set-up/Maintenance Verification] --> B(Run analyze-project);
327    B --> C[Stage 1: Verify doc_tracker.md];
328 
329    subgraph Verify_doc_tracker [Stage 1: doc_tracker.md]
330        C1[Use show-keys --tracker doc_tracker.md] --> C2{Checks Needed?};
331        C2 -- Yes --> C3[Identify Key(s)];
332        C3 --> C3a[Optional: Run resolve-placeholders --auto];
333        C3a --> C4[For Each (remaining) Key needing check:];
334        C4 --> C5(Run show-placeholders --tracker doc_tracker.md --key [key]);
335        C5 --> C6[Group Targets 5-10 per chunk];
336        C6 --> C6a{Delegation Tool Available?};
337        C6a -- use_subagents --> C6b[Dispatch via use_subagents];
338        C6a -- new_task --> C6c[Dispatch via new_task];
339        C6a -- Neither --> C6d[Run resolve-placeholders fallback];
340        C6d --> C6e{Fallback Successful?};
341        C6e -- Yes --> C6f[Review fallback output & apply dependencies];
342        C6e -- No --> C6g[Manual verification (last resort)];
343        C6b --> C6h[Wait for completion];
344        C6c --> C6h[Wait for completion];
345        C6h --> C6i[Review results & apply dependencies];
346        C6f --> C4;
347        C6g --> C4;
348        C6i --> C4;
349        C4 -- All Keys Done --> C10[Final Check: show-keys];
350        C2 -- No --> C10[doc_tracker Verified];
351    end
352 
353    C --> Verify_doc_tracker;
354    C10 --> D[MUP after Stage 1];
355 
356    D --> E[Stage 2: Find & Verify Mini-Trackers];
357    subgraph Find_Verify_Minis [Stage 2: Mini-Trackers (`*_module.md`)]
358        E1[Identify Code Roots from .clinerules] --> E2[Scan Code Roots Recursively];
359        E2 --> E3[Find & Verify *_module.md Files];
360        E3 --> E4[Compile List of Mini-Tracker Paths];
361        E4 --> E5{Any Mini-Trackers Found?};
362        E5 -- Yes --> E6[Select Next Mini-Tracker];
363        E6 --> E7[Use show-keys --tracker <mini_tracker>];
364        E7 --> E8{Checks Needed?};
365        E8 -- Yes --> E9[Identify Key(s)];
366        E9 --> E10[For Each Key needing check:];
367        E10 --> E11(Run show-placeholders --tracker [mini_tracker] --key [key]);
368        E11 --> E12[Group Targets 5-10 per chunk];
369        E12 --> E12a{Delegation Tool Available?};
370        E12a -- use_subagents --> E12b[Dispatch via use_subagents];
371        E12a -- new_task --> E12c[Dispatch via new_task];
372        E12a -- Neither --> E12d[Run resolve-placeholders fallback];
373        E12d --> E12e{Fallback Successful?};
374        E12e -- Yes --> E12f[Review fallback output & apply dependencies];
375        E12e -- No --> E12g[Manual verification (last resort)];
376        E12b --> E12h[Wait for completion];
377        E12c --> E12h[Wait for completion];
378        E12h --> E12i[Review results & apply dependencies];
379        E12f --> E10;
380        E12g --> E10;
381        E12i --> E10;
382        E10 -- All Keys Done --> E16[Final Check: show-keys];
383        E8 -- No --> E16[Mini-Tracker Verified];
384        E16 --> E17{All Mini-Trackers Checked?};
385        E17 -- No --> E6;
386        E17 -- Yes --> E18[All Mini-Trackers Verified];
387        E5 -- No --> E18; // Skip if no minis found
388    end
389 
390    E --> Find_Verify_Minis;
391    E18 --> F[MUP after Stage 2];
392 
393    F --> G[Stage 3: Verify module_relationship_tracker.md];
394    subgraph Verify_main_tracker [Stage 3: module_relationship_tracker.md]
395        G1[Use show-keys --tracker module_relationship_tracker.md] --> G2{Checks Needed?};
396        G2 -- Yes --> G3[Identify Key(s)];
397        G3 --> G4[For Each Key needing check:];
398        G4 --> G5(Run show-placeholders --tracker module_relationship_tracker.md --key [key]);
399        G5 --> G6[Group Targets 5-10 per chunk];
400        G6 --> G6a{Delegation Tool Available?};
401        G6a -- use_subagents --> G6b[Dispatch via use_subagents];
402        G6a -- new_task --> G6c[Dispatch via new_task];
403        G6a -- Neither --> G6d[Run resolve-placeholders fallback];
404        G6d --> G6e{Fallback Successful?};
405        G6e -- Yes --> G6f[Review fallback output & apply dependencies];
406        G6e -- No --> G6g[Manual verification (last resort)];
407        G6b --> G6h[Wait for completion];
408        G6c --> G6h[Wait for completion];
409        G6h --> G6i[Review results & apply dependencies];
410        G6f --> G4;
411        G6g --> G4;
412        G6i --> G4;
413        G4 -- All Keys Done --> G10[Final Check: show-keys];
414        G2 -- No --> G10[Main Tracker Verified];
415    end
416 
417    G --> Verify_main_tracker;
418    G10 --> H[MUP after Stage 3];
419 
420    H --> J[Stage 4: Code-Documentation Cross-Ref];
421    subgraph CodeDocRef [Stage 4: Code-Doc Cross-Ref]
422        J1[Identify Code & Doc Keys] --> J2[For Each Code Key:];
423        J2 --> J3(Identify Potential Docs);
424        J3 --> J4[Group Docs 5-10 per chunk];
425        J4 --> J4a{Delegation Tool Available?};
426        J4a -- use_subagents --> J4b[Dispatch via use_subagents];
427        J4a -- new_task --> J4c[Dispatch via new_task];
428        J4a -- Neither --> J4d[Run resolve-placeholders fallback];
429        J4d --> J4e{Fallback Successful?};
430        J4e -- Yes --> J4f[Review fallback output & apply bi-directional links];
431        J4e -- No --> J4g[Manual verification (last resort)];
432        J4b --> J4h[Wait for completion];
433        J4c --> J4h[Wait for completion];
434        J4h --> J4i[Review results & apply bi-directional links];
435        J4f --> J2;
436        J4g --> J2;
437        J4i --> J2;
438        J2 -- All Code Keys Done --> J8[Stage 4 Complete];
439    end
440 
441    J --> CodeDocRef;
442    J8 --> K[MUP after Stage 4];
443    K --> L[End Verification Process - Check All Exit Criteria (Section I)];
444 
445    style Verify_doc_tracker fill:#e6f7ff,stroke:#91d5ff
446    style Find_Verify_Minis fill:#f6ffed,stroke:#b7eb8f
447    style Verify_main_tracker fill:#fffbe6,stroke:#ffe58f
448```
449 
450## V. Using Delegation Tools for Dependency Verification
451 
452**Purpose**: Dependency verification in Set-up/Maintenance is orchestrator-led and worker-executed. The primary instance delegates verification and then applies accepted results using `dependency_processor.py` commands.
453 
454**Delegation Priority (Mandatory)**:
455 
4561. Use **`use_subagents`** when available in the current interface.
4572. If unavailable, use **`new_task`**.
4583. If both delegation tools are unavailable or failing, use `resolve-placeholders` as fallback.
4594. If delegation and `resolve-placeholders` fail, manual verification by the primary instance is allowed as a last resort.
460 
461**Guidelines for Delegation**:
462 
4631. **Grouping Strategy**:
464   * Group targets into chunks of 5-10 items.
465   * Group by dependency type ('p', 's', 'S') when practical.
466   * Group by logical similarity (same directory, related functionality).
467   * Keep each chunk independently verifiable.
468 
4692. **Task Structure**:
470   * **Source File Information**: Include source key and source path.
471   * **Task Objective**: State the verification objective without bias.
472   * **Worker Bootstrap**: Require that the first action is loading `.clinerules/setup_worker.md`.
473   * **Dependency Criteria**: Include the full dependency definitions from this plugin.
474   * **Target List**: Provide the complete list of target keys and paths for the chunk
475   * **Instructions**: Provide step-by-step instructions for the task
476   * **Expected Output**: Specify the exact format for results
477 
4783. **Neutral Instruction Template Rules (Mandatory)**:
479   * Use evidence-first wording only.
480   * Do not include recommendation language such as "likely" or "probably".
481   * Do not suggest a preferred dependency character before analysis.
482   * Do not imply that a dependency exists or does not exist before analysis.
483   * Require the worker/subagent to return: selected dependency character + explicit reasoning/evidence.
484 
4854. **Delegation Template Payload**:
486 
487```markdown
488   Dependency Verification Task for Key {key_string}
489   
490   **MANDATORY FIRST ACTION**: Load and follow `.clinerules/setup_worker.md`.
491 
492   Source File
493   Key: {key_string}
494   Path: {source_file_path}
495 
496   Task Objective
497   Determine the dependency relationship between the source file and each target file listed below using the criteria from  `.clinerules/setup_worker.md`.
498 
499   Target Files to Verify (Group {group_number})
500   [List target keys and paths for this chunk]
501 
502   Instructions
503   1. Read the source file: {source_file_path}
504   2. For each target file above:
505      a. Read the target file
506      b. Analyze the functional relationship between source and target
507      c. Determine the appropriate dependency character (<, >, x, d, or n)
508      d. State your reasoning for the chosen dependency type
509   3. Provide a summary of your findings in the format:
510      Key {key_string} Dependency Verification Results:
511 
512      [Target Key] [Target Path] -> [Dependency Character]
513      Reasoning: [Your reasoning]
514 
515      [Repeat for each target file]
516 
517   Important Notes
518   - Focus on functional reliance and necessary knowledge, not just semantic similarity
519   - A file mentioning another file's topic does not automatically create a dependency
520   - Consider whether the source file would break or be incomplete without the target file
521 
522   Expected Output
523   A clear summary of dependency determinations for all target files in this group with reasoning for each.
524```
525 
5265. **Tool Invocation Guidance**:
527   * **`use_subagents` path**: Use the interface-defined command/schema exactly as provided by the current environment.
528   * **`new_task` path**: Use the interface-defined `new_task` schema exactly as provided by the current environment.
529   * For both paths, pass the same neutral payload structure above.
530 
5316. **Post-Task Processing**:
532   * **Wait for Completion**: Allow each delegated task to complete before proceeding
533   * **Review Results**: Examine the returned dependency determinations and reasoning
534   * **Apply Dependencies**: Use `add-dependency` commands to apply the verified relationships
535   * **Batch Applications**: Group multiple `add-dependency` commands for the same source key and dependency type
536 
5377. **Best Practices**:
538    * **Clear Context**: Provide relevant context about the source file in the task instructions
539    * **Consistent Format**: Use the same output format across all tasks for easier processing
540    * **Reasoning Quality**: Emphasize the importance of clear, detailed reasoning in task instructions
541    * **Independent Chunks**: Ensure each chunk can be verified without dependencies on other chunks
542 
5438. **Example Workflow**:
544 
545```markdown
546   1. Run show-placeholders for key 1A3.
547   2. Identify 196 targets to verify.
548   3. Group into 20 chunks of ~10 files each.
549   4. For each chunk, use use_subagents if available; otherwise new_task.
550   5. If both delegation tools fail, run resolve-placeholders fallback.
551   6. If fallback fails, perform manual verification as last resort.
552   7. Review outputs and apply add-dependency updates.
553   8. Run show-keys to confirm verification complete.
554```
555 
556**Important Notes**:
557 
558* Delegation is required by default for verification work in this phase.
559* The primary instance should focus on orchestration, review, and dependency application.
560* Always review task results before applying dependencies to ensure accuracy
561* The task instructions must be clear and comprehensive to ensure quality results
562* Delegated instructions must remain neutral and unbiased.
563 
564## VI. Locating and Understanding Mini-Trackers
565 
566**Purpose**: Mini-trackers (`{dirname}_module.md`) serve a dual role:
567 
5681. **HDTA Domain Module**: They contain the descriptive text for the module (purpose, components, etc.), managed manually during Strategy.
5692. **Dependency Tracker**: They track file/function-level dependencies *within* that module and potentially *to external* files/docs. The dependency grid is managed via `dependency_processor.py` commands.
570 
571**Locating Mini-Trackers:**
572 
5731. **Get Code Roots**: Read the `[CODE_ROOT_DIRECTORIES]` list from `.clinerules`. These are the top-level directories containing project source code.
5742. **Scan Code Roots**: For each directory listed in `[CODE_ROOT_DIRECTORIES]`:
575    * Recursively scan its contents.
576    * Look for files matching the pattern `{dirname}_module.md`, where `{dirname}` is the exact name of the directory containing the file.
577    * Example: In `src/auth/`, look for `auth_module.md`. In `src/game/state/`, look for `state_module.md`.
5783. **Compile List**: Create a list of the full, normalized paths to all valid mini-tracker files found. This list will be used in Section III when it's time to verify mini-trackers.
579 
580**Creation and Verification**:
581 
582* **Creation/Update**: The `analyze-project` command (run in Section II.4 and potentially before Section III) automatically creates `{dirname}_module.md` files for detected modules if they don't exist, or updates the dependency grid within them if they do. It populates the grid with keys and initial placeholders/suggestions.
583* **Verification**: The detailed verification process in **Section III** is used to resolve placeholders ('p', 's', 'S') within these mini-trackers *after* `doc_tracker.md` is verified and *before* `module_relationship_tracker.md` is verified. Use the list compiled above to iterate through the mini-trackers during that stage.
584 
585## VII. Set-up/Maintenance Plugin - MUP Additions
586 
587After performing the Core MUP steps (Core Prompt Section VI):
588 
5891. **Update `system_manifest.md` (If Changed)**: If Set-up actions modified the project structure significantly (e.g., adding a major module requiring a mini-tracker), ensure `system_manifest.md` reflects this, potentially adding the new module.
5902. **Update `.clinerules` [LAST_ACTION_STATE]:** Update `last_action`, `current_phase`, `next_action`, `next_phase` to reflect the specific step completed within this phase. Examples:
591    * After identifying roots:
592 
593```markdown
594        last_action: "Identified Code and Doc Roots"
595        current_phase: "Set-up/Maintenance"
596        next_action: "Initialize Core Files / Run analyze-project"
597        next_phase: "Set-up/Maintenance"
598```
599 
600    * After initial `analyze-project`:
601 
602```markdown
603        last_action: "Ran analyze-project, Initialized Trackers"
604        current_phase: "Set-up/Maintenance"
605        next_action: "Verify doc_tracker.md Dependencies"
606        next_phase: "Set-up/Maintenance"
607```
608 
609    * After verifying `doc_tracker.md`:
610 
611```markdown
612        last_action: "Verified doc_tracker.md"
613        current_phase: "Set-up/Maintenance"
614        next_action: "Verify Mini-Trackers"
615        next_phase: "Set-up/Maintenance"
616```
617 
618    * After verifying the last tracker:
619 
620```markdown
621        last_action: "Completed All Tracker Verification"
622        current_phase: "Set-up/Maintenance"
623        next_action: "Perform Code-Documentation Cross-Reference"
624        next_phase: "Set-up/Maintenance"
625```
626 
627    * After completing Code-Documentation Cross-Reference:
628 
629```markdown
630        last_action: "Completed Code-Documentation Cross-Reference ('d' links added)"
631        current_phase: "Set-up/Maintenance"
632        next_action: "Phase Complete - User Action Required"
633        next_phase: "Strategy"
634```
635