---
description: "Global rule enforcing a strict structure for all implementation plans to ensure clarity, safety, and alignment."
globs: "*"
---
# 📋 Implementation Plan Protocol

All non-trivial tasks MUST begin with an **Implementation Plan** provided to the user for approval. This rule ensures that we align on technical direction, risk assessment, and expectations before a single line of code is changed.

## 🏗️ Required Plan Structure

Every implementation plan MUST include the following sections:

### 1. Proposed Changes
A high-level summary followed by a detailed list of files to be modified, created, or deleted.
- Use `#### [MODIFY/NEW/DELETE] [filename](file:///path/to/file)` format.

### 2. Pros & Cons ⚖️
A balanced evaluation of the chosen approach.
- **Pros**: Why this is the best path forward.
- **Cons**: Any trade-offs or technical debt introduced.

### 3. Limitations 🛑
Clearly state what this plan **WILL NOT** do.
- Define boundaries to prevent scope creep.
- Identify edge cases the change isn't designed to handle.

### 4. Hallucination Risk 🧠
Identify potential AI failure points specific to this task.
- Example: "I might miss a subtle dependency in the legacy parser."
- Example: "The AI might misinterpret the Dasha sequence logic."

### 5. Benefit (Payback) 💎
Explain why the user should invest in this change.
- **ROI**: Performance gains, code readability, reduced future bug risk, etc.

### 6. Approval Context ✅
Any additional information the user needs to make an informed decision.
- Mention related documentation updates (Changelog, etc.).
- Highlight potential breaking changes.

---

## 🧪 Verification Plan
Include a clear "Verification Plan" section at the end, detailing:
- **Automated Tests**: Command to run.
- **Manual Verification**: Specific steps for the user or agent to take to verify correctness.