Cline rules

1# **CRCT Set-up/Maintenance - Dependency Verification Worker Instructions**
2 
3This file defines the required verification behavior for delegated Set-up/Maintenance dependency tasks.
4 
5## I. Mandatory Bootstrap
6 
71. Apply these rules for every source->target relationship in the assigned task.
82. If task instructions conflict with this file, follow this file and report the conflict.
9 
10## II. Worker Scope
11 
121. Analyze assigned source/target files and determine dependency characters.
132. Return determinations with explicit reasoning tied to file evidence.
143. Do not assume outcomes before reading evidence.
154. Do not modify trackers; return determinations for the orchestrator to apply.
16 
17## III. Determine Relationship (CRITICAL STEP)
18 
19```text
20**Dependency Criteria**
21   < (Row Requires Column): Row functionally relies on or requires Column for context/operation
22   > (Column Requires Row): Column functionally relies on or requires Row for context/operation
23   x (Mutual Requirement): Mutual functional reliance or deep conceptual link requiring co-consideration
24   d (Documentation Link): Row is documentation essential for understanding/using Column, or vice-versa
25   n (Verified No Dependency): Confirmed no functional requirement or essential conceptual link exists
26```
27 
28* **Determine Relationship (CRITICAL STEP)**: Based on file contents, determine the **true relational necessity or essential conceptual link** between the source (`key_string`) and each target key being verified.
29* **Go Beyond Semantic Similarity**: Suggestions ('s', 'S') might only indicate related topics. However, if the source file defines the "Why," the rules, or the architecture for the target, it is an essential dependency.
30* **Focus on Relational and Contextual Necessity**: Ask:
31  * **Logic & Purpose**: Does the *row file* provide the business logic, requirements, or purpose that the *column file* implements? (Leads to 'd' or '<').
32  * **Technical Reliance**: Does the code in the *row file* directly **import, call, or inherit from** code in the *column file*? (Leads to '<' or 'x').
33  * **Knowledge Requirement**: Does a developer/LLM need to read the *column file* to safely or correctly modify the *row file*? (Leads to '<' or 'd').
34  * **Implementation Link**: Is the *row file* essential documentation for understanding or implementing the concepts/code in the *column file*? (Leads to 'd' or '>').
35  * **Architectural Fit**: Are these files part of the same specific feature or architectural pattern where changing one without the other would cause conceptual drift or technical debt? (Leads to 'x' or 'd').
36* **Purpose of Dependencies**: Remember, these verified dependencies guide the **Strategy phase** (determining task order) and the **Execution phase** (loading minimal necessary context). A dependency should mean "This file is part of the necessary context required to work effectively on the other."
37* **Assign 'n' ONLY for Unrelated Content**: If the relationship is purely coincidental, uses similar common terms in a different context, or is an unrelated file, assign 'n' (verified no dependency). **If there is any doubt regarding conceptual relevance, err on the side of 'd' (Documentation/Conceptual link) rather than 'n'.**
38* **State Reasoning (MANDATORY)**: **clearly state your reasoning** for the chosen dependency character (`<`, `>`, `x`, `d`, or `n`) for *each specific relationship* you intend to set, based on your direct file analysis and the relational necessity criteria.
39 
40## IV. Stage-Specific Guidance
41 
421. **Doc tracker and mini-tracker verification**:
43   * Verify by reading source and target files, not by similarity alone.
44   * Include conceptual/documentation relationships.
45   * If either the source or target file *should* reference the other, but does not, a positive dependency **must** be established so the system can add the missing information.
46   * When determining documentation dependency relations, think beyond direct connectivity. Does the described system or functionality interact with the other in *any* way? For proper planning we must be able to see relations beyond the obvious first tier connections. We must ask if a change in either system would have downstream effects on the other.
47 
482. **Module relationship tracker verification**:
49   * **Determine Relationship & State Reasoning**: Base decision on aggregated dependencies from mini-trackers and high-level design intent.
50   * **Focus on Module-Level Reliance**: Ask:
51   * **Logic Flow**: Does Module A provide the data or the trigger that Module B processes? (Leads to '<' or 'x').
52   * **Architectural Dependence**: Is Module A the "Controller" or "Core" that Module B (as a "Plugin" or "Utility") requires to have purpose? (Leads to '<' or 'd').
53   * **Direct Code Interaction**: Does *any file within* module A directly **import, call, or inherit from** code in *any file within* module B? (Leads to '<' or 'x').
54                    *   **Knowledge/Conceptual Link**: Is there a **deep, direct conceptual link** where understanding or modifying one module *necessitates* understanding the other? (Consider '<', '>', 'x', or 'd' based on the nature of the link).
55   * **State Reasoning (MANDATORY)**: **Clearly state your reasoning** for the chosen dependency character (`<`, `>`, `x`, `d`, or `n`) for *each specific relationship* you intend to set, based on your analysis of module-level dependencies.
56 
573. **Code-Documentation cross-reference**:
58   * Determine whether documentation is essential context for understanding, implementing, or safely modifying code.
59   * Explicitly note when doc->code and code->doc links should both exist.
60 
61## V. Output Contract
62 
63Use this output format unless the parent task specifies a stricter format:
64 
65```markdown
66Key {source_key} Dependency Verification Results:
67 
68[Target Key] [Target Path] -> [Dependency Character]
69Reasoning: [Evidence-backed reasoning]
70 
71[Repeat for each target]
72```
73 
74If evidence is insufficient, state exactly what is missing and why.
75 
76## File Paths
77 
78If you do not have the paths to the files or the correct keys, you can look them up in the global_key_map.json file located at `cline_utils\dependency_system\core\global_key_map.json`.
79