Cline rules

1# **Cline Recursive Chain-of-Thought System (CRCT) - Cleanup/Consolidation Plugin**
2 
3**This Plugin provides detailed instructions and procedures for the Cleanup/Consolidation phase of the CRCT system. It should be used in conjunction with the Core System Prompt.**
4 
5---
6 
7## I. Entering and Exiting Cleanup/Consolidation Phase
8 
9**Entering Cleanup/Consolidation Phase:**
101. **`.clinerules` Check**: Always read `.clinerules/default-rules.md` first. If `[LAST_ACTION_STATE]` shows `next_phase: "Cleanup/Consolidation"`, proceed with these instructions. This phase typically follows the Execution phase.
112. **User Trigger**: Start a new session if the system is paused after Execution, awaiting this phase.
12 
13**Exiting Cleanup/Consolidation Phase:**
141. **Completion Criteria:**
15   - Consolidation steps (Section III) are complete: relevant information integrated into persistent docs, changelog reorganized.
16   - Cleanup steps (Section IV) are complete: obsolete files identified and archived/removed.
17   - `activeContext.md` reflects the clean, consolidated state.
18   - MUP is followed for all actions.
192. **`default-rules.md` Update (MUP):**
20   - Typically transition back to Set-up/Maintenance for verification or Strategy for next planning cycle:
21```
22     [LAST_ACTION_STATE]
23     last_action: "Completed Cleanup/Consolidation Phase"
24     current_phase: "Cleanup/Consolidation"
25     next_action: "Phase Complete - User Action Required"
26     next_phase: "Set-up/Maintenance" # Or "Strategy" if planning next cycle immediately
27```
28   - *Alternative: If the project is now considered fully complete:*
29```
30     [LAST_ACTION_STATE]
31     last_action: "Completed Cleanup/Consolidation Phase - Project Finalized"
32     current_phase: "Cleanup/Consolidation"
33     next_action: "Project Completion - User Review"
34     next_phase: "Project Complete"
35```
363. **User Action**: After updating `default-rules.md`, pause for user to trigger the next phase.
37 
38---
39 
40## II. Phase Objective
41 
42**Objective**: To systematically review the project state after a cycle of execution, consolidate essential information and learnings into persistent documentation (HDTA, core files), **reorganize the changelog for better readability**, and clean up temporary or obsolete files (like completed Task Instructions, session trackers, and temporary consolidation notes) to maintain a focused and relevant project context.
43 
44**Workflow Order**: Consolidation MUST happen *before* Cleanup.
45 
46---
47 
48## III. Consolidation Workflow
49 
50**Goal**: Synthesize key information, decisions, and learnings from the recent execution cycle into the core project documentation, and reorganize the changelog by component/module.
51 
52<<<***CRITICAL WARNING***>>>
53*You **must** verify the base file's state by manually reading it to determine completion status. For code files read the actual code. For documentation, read the associated documents.*
54 
55**Procedure:**
56 
571.  **Review and Verify All Relevant Project Documentation and Task States (CRITICAL)**:
58    *   **a. Identify HDTA Document Structure and Other Strategic Trackers**:
59        *   **Action**: Review files in `cline_docs/templates/` to understand the standard structure and expected content for all HDTA document tiers (`system_manifest.md`, `*_module.md`, `implementation_plan_*.md`, `task_instruction.md`).
60        *   **Action**: Use `list_files` to search within `cline_docs/` (and potentially other relevant project documentation directories if custom locations are used) for any files matching patterns like `*roadmap*.md`, `*checklist*.md`, `*review_progress*.md`, or other strategic tracking documents.
61        *   **Purpose**: To ensure a complete understanding of the project's intended documentation structure and to identify all high-level tracking documents that need review and consolidation.
62    *   **b. List All Task Instruction Files**:
63        *   **Action**: Use `list_files` recursively to identify all `*.md` files within the primary `tasks/` directory (and its subdirectories).
64        *   **Action**: Use `list_files` recursively to identify all `*.md` files within the *entire* `cline_docs/archive/` directory (and its subdirectories) to locate any previously archived task files.
65        *   **Purpose**: Create a comprehensive list of all available task instruction files, regardless of their current location (active or archived), for subsequent review in batches.
66    *   **c. List All Implementation Plan Files**:
67        *   **Action**: For each directory listed in `[CODE_ROOT_DIRECTORIES]` (from `default-rules.md`), use `list_files` recursively to identify all files matching the pattern `implementation_plan_*.md`. These are typically located within module directories (e.g., `src/module_name/implementation_plan_*.md`).
68        *   **Purpose**: Create a comprehensive list of all implementation plan files for subsequent review in batches.
69    *   **d. Read Core Project State Files**:
70        *   **Action**: Read `activeContext.md`: Identify key decisions, unresolved issues, and summaries of work done.
71        *   **Action**: Read `changelog.md`: Review all significant changes. **(Note: Will be reorganized in Step 3)**.
72        *   **Action**: Read `progress.md`: Check for all high-level milestones.
73        *   **Purpose**: To gather current project state information that will inform the consolidation process.
74    *   **e. Review All Identified Task Instruction Files in Batches (CRITICAL)**:
75        *   **Purpose**: To identify significant implementation details, design choices, "gotchas," learnings, and to **CRITICALLY verify the actual completion status of tasks.** This review covers all task instruction files identified in step 1b, processed in batches to prevent context overload.
76        *   **Procedure**:
77            i. **Batch Creation**:
78                - **Action**: Divide the comprehensive list of Task Instruction files (from step 1b) into batches, with each batch containing **no more than 10 files**. If the total number of files is not evenly divisible by 10, the final batch may contain fewer than 10 files.
79                - **Action**: Maintain a record of which files have been processed to ensure no files are missed or processed twice. This can be done internally or by updating a temporary tracking mechanism (e.g., a note in `activeContext.md` for the duration of this phase).
80            ii. **Process Each Batch (Standalone Processing)**:
81                - **Action**: For each batch of up to 10 Task Instruction files, **fully process the batch as a standalone task** before proceeding to the next batch. This means completing all verification, extraction, and updating actions for all files in the batch with no inter-batch dependencies for these actions.
82                - **Sub-Procedure (for each file in the batch)**:
83                    1. **Read the Task File**:
84                        - **Action**: Use `read_file` to read the content of the task file.
85                    2. **Verify Completion (Manual & CRITICAL)**:
86                        - **Verification Approach**:
87                            - For **Execution Tasks**: If the task file indicates a tangible action was taken on a project artifact (e.g., "applied x to y," "created file z," "modified function f in file w," "updated documentation q"), you **MUST** manually verify this outcome by examining the target artifact.
88                            - For **Strategy Tasks**: Verification involves confirming that the planned output of the strategy task (e.g., a design document, a research summary, a set of defined requirements, a completed exploration) has been produced, is complete, and meets the task's objectives. This may involve reading the output document(s) or assessing the completeness of the strategic analysis presented in the task file itself.
89                        - **Action**: Use `read_file` to examine target artifacts or output documents, or use `list_files` to confirm existence/modification as appropriate. Consult `changelog.md` entries if they provide specific file modification details related to the task.
90                        - **If the outcome is NOT verified** (e.g., 'x' was not applied to 'y', file 'z' does not contain expected content, function 'f' was not modified as described):
91                            - Clearly note this discrepancy for this task file.
92                            - **Action (CRITICAL)**: If the task file has a "Status: Completed" marker (or all its internal steps are checked off implying completion), this status is now considered **invalid**. You **MUST** update the task file itself to remove or clearly mark the "Completed" status as incorrect/unverified (e.g., change to "Status: Pending Verification" or "Status: Incomplete - Outcome Not Verified").
93                            - **Action (CRITICAL)**: Identify ALL documents that reference this task as completed. This includes (but is not limited to) parent Implementation Plan(s), any `*checklist*.md` files, `*roadmap*.md` files, `progress.md`, and potentially `activeContext.md`. Update these referencing documents to reflect the task's true (unverified/incomplete) status.
94                            - **Note**: This task file **MUST NOT** be archived as "complete" in Section IV. It may require a new task to be created in a subsequent phase to address the incompletion.
95                    3. **Extract Consolidatable Information (CRITICAL)**:
96                        - Regardless of verified completion status, identify any design decisions, new information, important learnings, "gotchas," or deviations from original plans noted *within* the task file.
97                        - **Action**: Record this information in a temporary file, `consolidation_notes.md`, located in `cline_docs/`. Append each piece of information with a reference to the source file and batch number (e.g., "Batch 1, task_abc.md: Learned that algorithm X is suboptimal for large datasets"). Use `write_to_file` or `apply_diff` to update `consolidation_notes.md`.
98                - **Action**: After fully processing all files in the current batch (i.e., all files have been read, verified, updated if necessary, and their consolidatable information recorded in `consolidation_notes.md`), document the completion of the batch in `activeContext.md` (e.g., "Completed verification and extraction for batch X containing files [file1, file2, ...]. Information recorded in `consolidation_notes.md`."). Only then proceed to the next batch.
99                - **Purpose**: Processing each batch as a standalone task ensures that all critical actions are completed without relying on future batches, reducing context overload while maintaining comprehensive verification and extraction.
100    *   **f. Review All Identified Implementation Plan Files in Batches (CRITICAL)**:
101        *   **Purpose**: To consolidate strategic decisions, outcomes, and ensure alignment with completed (and verified) tasks. This review covers all files identified in step 1c, processed in batches to prevent context overload.
102        *   **Procedure**:
103            i. **Batch Creation**:
104                - **Action**: Divide the comprehensive list of Implementation Plan files (from step 1c) into batches, with each batch containing **no more than 10 files**. If the total number of files is not evenly divisible by 10, the final batch may contain fewer than 10 files.
105                - **Action**: Maintain a record of which files have been processed to ensure no files are missed or processed twice.
106            ii. **Process Each Batch (Standalone Processing)**:
107                - **Action**: For each batch of up to 10 Implementation Plan files, **fully process the batch as a standalone task** before proceeding to the next batch. This means completing all reading, analysis, updating, and extraction actions for all files in the batch with no inter-batch dependencies for these actions.
108                - **Sub-Procedure (for each file in the batch)**:
109                    1. **Read the Implementation Plan**:
110                        - **Action**: Use `read_file` to read the content of the implementation plan.
111                    2. Identify any high-level strategic decisions, architectural changes, or overall outcomes described in the plan.
112                    3. Cross-reference the tasks listed within the plan against the verification status determined in step 1e. Update the Implementation Plan to accurately reflect the true completion status of its child tasks.
113                    4. **Extract Consolidatable Information**:
114                        - Earmark any significant strategic information not yet captured in higher-level HDTA documents (like `system_manifest.md` or `*_module.md` files).
115                        - **Action**: Record this information in `consolidation_notes.md` in `cline_docs/`, appending each piece with a reference to the source file and batch number (e.g., "Batch 2, implementation_plan_feature_y.md: Decision to use microservices for scalability").
116                - **Action**: After fully processing all files in the current batch (i.e., all files have been read, updated, and their consolidatable information recorded in `consolidation_notes.md`), document the completion of the batch in `activeContext.md` (e.g., "Completed verification and extraction for batch Y containing implementation plans [plan1, plan2, ...]. Information recorded in `consolidation_notes.md`."). Only then proceed to the next batch.
117                - **Purpose**: Processing each batch as a standalone task ensures manageable processing of Implementation Plans, maintaining alignment with verified task statuses.
118    *   **g. Review Other Strategic Tracking Documents (Roadmaps, Checklists, etc.) in Batches (CRITICAL)**:
119        *   **Purpose**: To ensure all high-level tracking documents are up-to-date, and that incomplete items from older versions are not lost. This review covers all files identified in step 1a (excluding HDTA templates), processed in batches to prevent context overload.
120        *   **Procedure**:
121            i. **Batch Creation**:
122                - **Action**: Divide the comprehensive list of Strategic Tracking documents (from step 1a, e.g., `*roadmap*.md`, `*checklist*.md`, `*review_progress*.md`, and explicitly `final_review_checklist.md`) into batches, with each batch containing **no more than 10 files**. If the total number of files is not evenly divisible by 10, the final batch may contain fewer than 10 files.
123                - **Action**: Maintain a record of which files have been processed to ensure no files are missed or processed twice.
124            ii. **Process Each Batch (Standalone Processing)**:
125                - **Action**: For each batch of up to 10 Strategic Tracking documents, **fully process the batch as a standalone task** before proceeding to the next batch. This means completing all reading, consolidation, updating, and extraction actions for all files in the batch with no inter-batch dependencies for these actions.
126                - **Sub-Procedure (for each file in the batch)**:
127                    1. If multiple versions of the same conceptual tracker exist (e.g., `project_checklist_v1.md`, `project_checklist_v2.md`):
128                        - **Action**: Read all versions within the batch.
129                        - **Action (CRITICAL)**: Identify the *newest* version. Consolidate all incomplete or pending items from *older* versions into this newest version.
130                        - **Action (CRITICAL)**: Ensure all significant completed items and learnings noted in older versions are appropriately reflected in persistent project documentation (HDTA, changelog, etc.) or carried over to the newest tracker version if still relevant for context.
131                        - Once an older version is fully consolidated (all its unique, still-relevant information is transferred), it can be considered for archival in Section IV. The newest version becomes the active tracker.
132                    2. For the active/newest version of each tracker, review its items against the verified task statuses (from step 1e) and Implementation Plan reviews (step 1f). Update the tracker to accurately reflect project progress.
133                    3. **Extract Consolidatable Information**:
134                        - Earmark any strategic insights or status updates for broader consolidation (e.g., into `activeContext.md` or `progress.md`).
135                        - **Action**: Record this information in `consolidation_notes.md` in `cline_docs/`, appending each piece with a reference to the source file and batch number (e.g., "Batch 3, roadmap_v3.md: Updated milestone priorities based on task delays").
136                - **Action**: After fully processing all files in the current batch (i.e., all files have been read, consolidated, updated, and their consolidatable information recorded in `consolidation_notes.md`), document the completion of the batch in `activeContext.md` (e.g., "Completed verification and extraction for batch Z containing trackers [tracker1, tracker2, ...]. Information recorded in `consolidation_notes.md`."). Only then proceed to the next batch.
137                - **Purpose**: Processing each batch as a standalone task ensures manageable processing of Strategic Trackers, maintaining comprehensive consolidation.
138 
1392.  **Identify All Information for Consolidation (CRITICAL)**:
140    *   Based on the comprehensive review performed in Step 1 (covering all task instructions, implementation plans, strategic trackers, and core state files), **CRITICALLY** list all specific pieces of information that represent lasting design decisions, architectural changes, significant outcomes, refined requirements, important operational learnings, "gotchas," or any other vital knowledge that **MUST** be integrated into persistent project documentation. This list is not limited to findings from only the most recent operational cycle but encompasses the entire project history as reviewed. (Excluding changelog structural reorganization for this step, which is handled in Step 3b).
141 
1423.  **Update Persistent Documentation & Reorganize Changelog**:
143 
144    *   **a. Update Standard Documentation (HDTA, Core Files) (CRITICAL)**:
145        *   **Purpose**: To ensure all persistent project documentation accurately reflects the consolidated knowledge gathered from `consolidation_notes.md` in Step 2. This is a **CRITICAL** step for maintaining an up-to-date and reliable knowledge base for the project.
146        *   **HDTA Documents**:
147            *   **Action (CRITICAL)**: Update `system_manifest.md` if the overall architecture, core components, or project goals have evolved or been clarified at any point.
148            *   **Action (CRITICAL)**: Update relevant Domain Modules (`*_module.md`) to incorporate refined descriptions, interface changes, key implementation notes, or any other significant learnings discovered.
149            *   **Action (CRITICAL)**: Update relevant Implementation Plans (`implementation_plan_*.md`) with notes on final outcomes, deviations from original plans, or significant decisions made during any implementation effort. Ensure they accurately reflect the verified completion status of their child tasks.
150            *   **Procedure**: For each HDTA document requiring updates: Use `read_file` to load the target document, integrate the consolidated information logically and clearly, and use `write_to_file` to save changes. **State reasoning for each update, referencing the source of the consolidated information (e.g., specific task file, `activeContext.md` insight).** Example: "Consolidating final algorithm choice for module Y (from archived task `cline_docs/archive/tasks/task_abc.md`) into `src/module_y/module_y_module.md`."
151        *   **Core Files**:
152            *   **Action (CRITICAL)**: Update `progress.md` to accurately mark all completed high-level checklist items based on verified outcomes.
153            *   **Action (CRITICAL)**: Update `userProfile.md` with any newly observed or reinforced user preferences or interaction patterns.
154            *   **Action (CRITICAL)**: Review and Consolidate `default-rules.md` `[LEARNING_JOURNAL]`:
155                i.  **Action**: Read the current `[LEARNING_JOURNAL]` section from `default-rules.md`.
156                ii. **Purpose**: To refine the journal by grouping similar learnings, combining related entries for conciseness, removing entries that are not strategic or system-level learnings (e.g., very minor tactical notes better suited for `activeContext.md` during a specific task, or temporary observations that are no longer relevant), and ensuring entries are clearly articulated.
157                iii. **Procedure**:
158                    - Identify entries that are redundant or cover very similar points. Combine them into a single, more comprehensive entry.
159                    - Identify entries that are too granular or represent temporary states rather than lasting learnings. Consider removing these if their value is not persistent.
160                    - Identify entries that are not appropriate for the Learning Journal's purpose (e.g., simple reminders, task-specific notes that don't represent broader learning). Remove these.
161                    - Ensure remaining entries are clear, concise, and genuinely reflect significant learnings about the CRCT process, project management, technical approaches, or user interactions.
162                iv. **Action**: Add any *new* significant system-level learnings identified during the comprehensive review (from Step 1e, 1f, 1g) to the refined journal. Example: "Adding to Learning Journal: Comprehensive review during Cleanup/Consolidation revealed a recurring pattern of task underestimation when initial data definitions are incomplete, highlighting the need for more rigorous data strategy upfront."
163                v.  **Action**: Use `write_to_file` (or `apply_diff` if more appropriate for `default-rules.md` format) to update the `[LEARNING_JOURNAL]` section in `default-rules.md` with the consolidated and newly added entries.
164 
165    *   **b. Consolidate and Reorganize Changelog (CRITICAL)**:
166        *   **Purpose**: To transform the `changelog.md` into a more readable and maintainable format by structuring all historical entries by their primary component/module and then chronologically within each component. This provides a clear, organized history of changes for the entire project lifecycle. This is a **CRITICAL** step for long-term project understanding and maintainability.
167        *   **Goal**: Reformat `changelog.md` by grouping entries under component/module headings, sorted chronologically (newest first) within each group.
168        *   **Action: Read**: Use `read_file` to load the current content of `changelog.md`.
169        *   **Action: Process Internally**:
170            1.  **Parse Entries**: Mentally (or by outlining the steps) parse the loaded text into individual changelog entries (likely delimited by `---` or `### Heading - Date`). Extract the Date, Summary, Files Modified list, and the full text block for each entry.
171            2.  **Determine Component**: For each entry, determine its primary component/module based on the `Files Modified` paths. Use heuristics:
172                *   If most/all files are in `src/module_name/`, component is `Module: module_name`.
173                *   If most/all files are in `docs/category/`, component is `Documentation: category`.
174                *   If files are in `cline_utils/` or `cline_docs/`, component is `CRCT System`.
175                *   If files span multiple major areas, choose the most representative one or create a `Cross-Cutting` category.
176                *   Use a default `General` category if no clear component is identifiable.
177            3.  **Group Entries**: Create internal lists, grouping the parsed entries by their determined component.
178            4.  **Sort Groups**: Within each component group, sort the entries strictly by Date (most recent date first).
179            5.  **Format Output**: Construct the *entire new text content* for `changelog.md`.
180                *   Start with the main `# Changelog` heading.
181                *   For each component group:
182                    *   Add a component heading (e.g., `## Component: Game Loop` or `## Documentation: Worldbuilding`).
183                    *   List the sorted entries for that component, preserving their original `### Summary - Date`, `Description`, `Impact`, `Files Modified` structure.
184                    *   Use `---` between individual entries within the component group.
185                *   *(Optional: Add a more distinct separator like `***` between different component groups if helpful for readability)*.
186        *   **Action: Write**: Use `write_to_file` to overwrite `changelog.md` with the *complete, reformatted content* generated in the previous step.
187        *   **State**: "Reorganized `changelog.md`. Read existing content, parsed entries, grouped by component (e.g., Game Loop, Documentation, CRCT System), sorted entries by date within each group, and overwrote the file with the new structure."
188 
189    *   **c. `activeContext.md` (Final Pass & CRITICAL Update)**:
190        *   **Action (CRITICAL)**: After all other information has been consolidated into persistent documents (HDTA, core files) and the changelog has been reorganized, update `activeContext.md` one last time.
191        *   **Goal**: To ensure `activeContext.md` accurately reflects the *current, fully consolidated baseline state of the entire project*. This involves removing any transient details specific to *any previously completed work cycles or outdated project states* (e.g., step-by-step execution logs from past tasks, outdated considerations, resolved issues that are now documented elsewhere). The file should retain only the current high-level project status, truly outstanding issues that require immediate or near-term attention, and clear pointers to where detailed, persistent information now resides (e.g., "Final design details for feature Y documented in `implementation_plan_feature_y.md`. Changelog comprehensively reorganized. Next focus: Phase X based on `roadmap_v3.md`.").
192 
1934.  **MUP**: Perform Core MUP and Section V additions after completing the consolidation steps (including changelog). Update `last_action` in `default-rules.md` to indicate consolidation is finished and cleanup is next.
194 
195---
196 
197## IV. Cleanup Workflow
198 
199**Goal**: Remove or archive obsolete files and data to reduce clutter and keep the project context focused on active work. **Proceed only after Consolidation (Section III) is complete.**
200 
201**Procedure:**
202 
2031.  **Identify Cleanup Targets (CRITICAL)**:
204    *   **CRITICAL Pre-condition**: This step relies entirely on the comprehensive review and verification performed in Section III. Only files confirmed as fully completed, verified, and whose essential information has been consolidated into persistent documentation are eligible for cleanup.
205    *   **a. Identify Completed and Consolidated Task Instruction Files**:
206        *   Refer to the outcomes of Section III, Step 1e. Task Instruction files that were:
207            i.  Verified as genuinely completed.
208            ii. Had all their critical information (learnings, design choices, "gotchas") successfully consolidated into persistent HDTA documents or the Learning Journal.
209        *   These files are primary candidates for archival. **Task files that were found to be unverified or incomplete in Section III, Step 1e, MUST NOT be targeted for cleanup as "complete" items.**
210    *   **b. Identify Fulfilled Strategy Task Files**:
211        *   Refer to the outcomes of Section III, Step 1f and 1g. Strategy task files whose objectives have been fully met by downstream Execution tasks (which themselves are verified complete and consolidated) and whose own content has been fully consolidated are candidates for archival.
212    *   **c. Identify Obsolete Temporary Session Files and Trackers**:
213        *   Refer to the outcomes of Section III, Step 1g. Older versions of strategic tracking documents (roadmaps, checklists, review progress files) that have had all their pending items and unique valuable information consolidated into a newer active version (or into persistent HDTA documents) are candidates for archival.
214        *   Identify any other temporary session-specific files (e.g., ad-hoc notes from a past phase that are now fully processed and consolidated) that are no longer relevant to the current project state.
215    *   **d. Identify Temporary Consolidation Notes File**:
216        *   **Action**: Identify `consolidation_notes.md` in `cline_docs/` as a temporary file created during the Consolidation Workflow (Section III). Since its contents have been fully processed and integrated into persistent documentation in Section III, Step 3, it is now obsolete and a candidate for archival.
217    *   **e. Identify Other Obsolete Files**:
218        *   Consider other temporary files or logs if any were created during any project phase and are confirmed to be no longer relevant and their information (if any) has been consolidated.
219 
2202.  **Determine Cleanup Strategy (Archive vs. Delete)**:
221    *   **Recommendation**: Archiving is generally safer than permanent deletion.
222    *   **Determine Project Root**: Identify the absolute path to the project's root workspace directory from your current environment context. Let's refer to this as `{WORKSPACE_ROOT}`. **Do not hardcode paths.**
223    *   **Proposal**: Propose creating an archive structure if it doesn't exist, using **absolute paths**.
224        *   Example absolute paths for archive dirs: `{WORKSPACE_ROOT}/cline_docs/archive/tasks/`, `{WORKSPACE_ROOT}/cline_docs/archive/session_trackers/`.
225    *   **Action**: First, use `list_files` to check if the proposed archive directories (e.g., `{WORKSPACE_ROOT}/cline_docs/archive/tasks/`, `{WORKSPACE_ROOT}/cline_docs/archive/session_trackers/`) already exist if you have not already done so in a previous step. If they do not, then propose creating them using `execute_command`. Propose the appropriate OS-specific command (e.g., `mkdir -p` for Unix-like, `New-Item -ItemType Directory -Force` for PowerShell, `mkdir` for CMD which might require checking for existence first or handling an error if it already exists) using the absolute path. **Use `ask_followup_question` to confirm this specific command** or allow the user to provide an alternative. Prioritize using the environment details to determine the user's shell for more accurate initial suggestions. If the directories already exist, this creation step can be skipped.
226```xml
227        <!-- Determine Workspace Root as {WORKSPACE_ROOT} -->
228        <!-- Proposing command to create archive directories. -->
229        <ask_followup_question>
230          <question>Create archive directories? Proposed command (uses absolute paths, tailored to detected OS/shell):
231          `[Proposed Command Here]`
232          Is this command correct for your OS/shell?</question>
233          <follow_up>
234            <suggest>Yes, execute this command</suggest>
235            <suggest>No, I will provide the correct command</suggest>
236          </follow_up>
237        </ask_followup_question>
238```
239        *   If user selects "Yes", proceed with `execute_command` using the proposed command.
240        *   If user selects "No", wait for their input and use that in `execute_command`.
241        *(Note: Quoting paths is good practice, especially if the root path might contain spaces. Be mindful of shell-specific syntax for multiple directories or force options.)*
242 
2433.  **Execute Cleanup (Using `execute_command` with User Confirmation via `ask_followup_question`) (CRITICAL)**:
244    *   **Input**: This step processes the list of files deemed eligible for cleanup (archival or deletion) as determined by the rigorous verification and consolidation checks in Section IV, Step 1, including `consolidation_notes.md`.
245    *   **List Files**: Use `list_files` (which uses relative paths based on workspace) to confirm the current existence and *relative paths* of files targeted for cleanup *from the eligible list*.
246    *   **Construct Absolute Paths**: For each relative path identified for cleanup (e.g., `tasks/some_task.md`), construct its corresponding **absolute path** by prepending the determined `{WORKSPACE_ROOT}` (e.g., `{WORKSPACE_ROOT}/tasks/some_task.md`). Do the same for target archive locations.
247    *   **Propose Actions and Get Command Confirmation (MANDATORY `ask_followup_question` Step)**:
248        *   For each file or group of files to be cleaned up:
249            1.  Clearly formulate the **question** stating the intended action (archive/delete) and the full absolute path(s) involved.
250            2.  Generate **suggested commands** (as `<suggest>` options) for common OS/shell combinations (Linux/macOS/Git Bash, Windows CMD, Windows PowerShell), using the determined `{WORKSPACE_ROOT}` and appropriate path separators (`/` or `\`) for each suggestion. **Prioritize the suggestion matching the detected OS/shell.**
251            3.  Include a final `<suggest>` option like: `Provide alternative command`.
252            4.  Use the `ask_followup_question` tool with the question and these suggestions.
253    *   **Note on Shell Accuracy**: Be aware that the detected shell might not always be the active one. If command execution fails, re-verify the user's active shell or ask for explicit confirmation.
254    *   **Example Interaction Flow**: (Examples remain relevant, but suggestions should be tailored and prioritize detected shell)
255        *   **LLM**: *(Constructs absolute paths internally based on `{WORKSPACE_ROOT}`)*
256```xml
257          <ask_followup_question>
258            <question>Archive completed task file "{WORKSPACE_ROOT}/tasks/Execution_integrate_input_handler_game_loop_task.md" to "{WORKSPACE_ROOT}/cline_docs/archive/tasks/"? Select the correct command for your system:</question>
259            <follow_up>
260              <suggest>mv "{WORKSPACE_ROOT}/tasks/Execution_integrate_input_handler_game_loop_task.md" "{WORKSPACE_ROOT}/cline_docs/archive/tasks/"</suggest> <!-- Prioritize if Linux/macOS detected -->
261              <suggest>move "{WORKSPACE_ROOT}\tasks\Execution_integrate_input_handler_game_loop_task.md" "{WORKSPACE_ROOT}\cline_docs\archive\tasks\"</suggest> <!-- Prioritize if Windows detected -->
262              <suggest>Provide alternative command</suggest>
263            </follow_up>
264          </ask_followup_question>
265```
266        *   **User**: *(Selects a command or provides alternative)*
267        *   **LLM**: "Okay, executing the selected command:"
268```xml
269          <execute_command>
270          <command>[User Confirmed or Provided Command]</command>
271          </execute_command>
272```
273        *   *(Wait for tool result, document action, then proceed to next file)*
274    *   **Document Actions**: After successful execution (based on tool output), clearly log which files were archived or deleted using the confirmed commands and absolute paths.
275 
2764.  **Final Verification (CRITICAL)**:
277    *   **Action (CRITICAL)**: If any archive or delete operations were performed in Step 3, use `list_files` again with the original *relative* locations of the processed files to verify they are no longer present in those locations.
278    *   **Action (CRITICAL)**: Ensure `activeContext.md` is clean and does not reference the removed/archived files unless it is explicitly pointing to their new archive location for historical reference. All other pointers should be to active, persistent documentation.
279 
2805.  **MUP**: Perform Core MUP and Section V additions after completing cleanup. Update `last_action` and `next_phase` in `default-rules.md` to signify the end of this phase.
281 
282**Cleanup Flowchart**
283```mermaid
284flowchart TD
285    A[Start Cleanup (Post-Consolidation)] --> B[Identify Cleanup Targets]
286    B --> B1[Determine Absolute Workspace Root `{WORKSPACE_ROOT}`]
287    B1 --> C{Archive Structure Exists?}
288    C -- No --> D[Use `ask_followup_question` to Confirm `mkdir` command w/ Absolute Paths]
289    D -- Confirmed --> D1[Execute Confirmed `mkdir` command]
290    C -- Yes --> E
291    D1 --> E
292    E --> F[List Target Files]
293    F --> G[For each file/group:]
294    G --> G1[Construct Absolute Paths for Source & Target]
295    G1 --> H[1. State Intent<br>Archive/Delete]
296    H --> I[2. Generate OS-specific command suggestions w/ Absolute Paths]
297    I --> J[3. Use `ask_followup_question` w/ suggestions + "Provide Alternative"]
298    J -- User Selects Suggested Command --> K[Execute Selected Command via `execute_command`]
299    J -- User Selects "Provide Alternative" --> J1[Wait for User Command Input]
300    J1 --> K2[Execute User-Provided Command via `execute_command`]
301    K --> L[Document Action]
302    K2 --> L
303    L --> M{More files?}
304    M -- Yes --> G
305    M -- No --> N[Verify Files Moved/Removed]
306    N --> O[MUP & Update default-rules.md to Exit Phase]
307    O --> P[End Cleanup]
308 
309    style J fill:#f9f,stroke:#f6f,stroke-width:2px,color:#000
310    style B1 fill:#e6f7ff,stroke:#91d5ff
311    style G1 fill:#fffbe6,stroke:#ffe58f
312```
313 
314---
315 
316## V. Cleanup/Consolidation Plugin - MUP Additions (CRITICAL)
317 
318**CRITICAL**: These steps **MUST** be performed in addition to Core MUP steps at the appropriate junctures.
319 
3201.  **Verify `activeContext.md` State (CRITICAL)**: After any significant consolidation or cleanup action, and especially at the MUP points defined in Section III.4 and IV.5, **CRITICALLY** verify that `activeContext.md` accurately reflects the current, clean, and consolidated state. Ensure it points to persistent documents for details and that all transient information from now-completed cycles or outdated states has been removed.
3212.  **Verify `changelog.md` Structure (CRITICAL)**: After the changelog reorganization (Section III.3b), and at the MUP point in Section III.4, **CRITICALLY** verify that the `changelog.md` structure correctly reflects the component grouping and chronological sorting as intended.
3223.  **Update `default-rules.md` [LAST_ACTION_STATE] (CRITICAL)**:
323    *   **After Consolidation step is fully completed (including changelog reorganization - as per Section III.4)**:
324```
325      [LAST_ACTION_STATE]
326      last_action: "Completed ALL Consolidation Steps (incl. Changelog Reorg)"
327      current_phase: "Cleanup/Consolidation"
328      next_action: "Begin Cleanup Workflow"
329      next_phase: "Cleanup/Consolidation"
330```
331    *   **After Cleanup step is fully completed (exiting phase - as per Section IV.5)**:
332```
333      [LAST_ACTION_STATE]
334      last_action: "Completed Cleanup/Consolidation Phase (All Steps)"
335      current_phase: "Cleanup/Consolidation"
336      next_action: "Phase Complete - User Action Required to transition to next phase"
337      next_phase: "Set-up/Maintenance" # Or "Strategy" or "Project Complete"
338```
339 
340---
341 
342## VI. Quick Reference (All Steps are CRITICAL)
343 
344- **Objective**: **CRITICALLY** and comprehensively review the **entire project state**. Consolidate all verified learnings, outcomes, and essential information into persistent documentation. **Reorganize `changelog.md` by component/date for the entire project history.** Archive or remove obsolete files based on rigorous verification and consolidation.
345- **Order**: Consolidation (Section III) MUST be fully completed BEFORE Cleanup (Section IV).
346- **Consolidation (Section III)**:
347    - **Inputs (Comprehensive Review)**:
348        - HDTA Templates (`cline_docs/templates/`)
349        - All Task Instruction files (from `tasks/` and `cline_docs/archive/`)
350        - All Implementation Plan files (from Code Root directories)
351        - All Strategic Tracking documents (roadmaps, checklists from `cline_docs/`, etc.)
352        - Core state files: `activeContext.md`, `changelog.md` (entire history), `progress.md`
353    - **Actions (All Mandatory & CRITICAL)**:
354        1.  Review HDTA templates; List all Task Instructions, Impl. Plans, Strategic Trackers. Process in batches of ≤10 files; **Fully process each batch as a standalone task**.
355        2.  For ALL Task Instructions: Read, **MANUALLY VERIFY OUTCOMES** (if outcome unverified, update task file & all references to show NOT complete; unverified tasks are NOT archived as complete). Extract ALL learnings/design choices.
356        3.  For ALL Impl. Plans: Read, cross-reference task verification, update plan status, extract strategic info.
357        4.  For ALL Strategic Trackers: Review, consolidate older versions into newest, update status based on verified tasks.
358        5.  Identify ALL information for consolidation from the above reviews.
359        6.  Update HDTA docs (`system_manifest.md`, `*_module.md`, `implementation_plan_*.md`).
360        7.  Update Core Files: `progress.md`, `userProfile.md`.
361        8.  Review, Refine, & Update `default-rules.md` `[LEARNING_JOURNAL]` (group, combine, remove inappropriate, add new).
362        9.  Reorganize ENTIRE `changelog.md` (Parse->Group by Component->Sort by Date->Format->Write).
363        10. Update `activeContext.md` to reflect fully consolidated project baseline.
364    - **Tools**: `list_files`, `read_file`, `write_to_file`, `apply_diff`.
365- **Cleanup (Section IV)**:
366    - **Inputs (Derived from Section III)**: Verified list of fully completed & consolidated Task Instructions; Fulfilled Strategy Tasks; Obsolete (fully consolidated) session files/trackers; Other confirmed obsolete files.
367    - **Actions (All Mandatory & CRITICAL)**:
368        1.  Identify cleanup targets **based on Section III's verified outputs.**
369        2.  Determine archive strategy (archive preferred); Check/Create archive dirs (confirm command with `ask_followup_question`).
370        3.  For each eligible file: Construct absolute paths, confirm archive/delete command with `ask_followup_question`, execute, document.
371        4.  Verify files moved/removed (use `list_files`); Ensure `activeContext.md` is clean.
372    - **Tools**: `list_files`, `execute_command`, `ask_followup_question`.
373- **MUP Additions (Section V) (CRITICAL)**:
374    - After Consolidation: Verify `activeContext.md`, `changelog.md`; Update `default-rules.md` (last_action: "Completed ALL Consolidation...", next_action: "Begin Cleanup...").
375    - After Cleanup (Exiting Phase): Verify `activeContext.md`; Update `default-rules.md` (last_action: "Completed Cleanup/Consolidation Phase (All Steps)...", next_action: "Phase Complete...").
376