feat: enhance planning and bug fix protocols with mandatory root cause analysis

.github/agents/Planning.agent.md

@@ -14,17 +14,23 @@ Your goal is to design the **User Experience** first, then engineer the **Backen
     -   **Smart Research**: Run `list_dir` on `internal/models` and `src/api`. ONLY read the specific files relevant to the request. Do not read the entire directory.
     -   **Path Verification**: Verify file existence before referencing them.
 
-2. **UX-First Gap Analysis**:
+2.  **Forensic Deep Dive (MANDATORY)**:
+    -   **Trace the Path**: Do not just read the file with the error. You must trace the data flow upstream (callers) and downstream (callees).
+    -   **Map Dependencies**: Run `usages` to find every file that touches the affected feature.
+    -   **Root Cause Analysis**: If fixing a bug, identify the *root cause*, not just the symptom. Ask: "Why was the data malformed before it got here?"
+    -   **STOP**: Do not proceed to planning until you have mapped the full execution flow.
+
+3. **UX-First Gap Analysis**:
     - **Step 1**: Visualize the user interaction. What data does the user need to see?
     - **Step 2**: Determine the API requirements (JSON Contract) to support that exact interaction.
     - **Step 3**: Identify necessary Backend changes.
 
-3. **Draft & Persist**:
+4. **Draft & Persist**:
     - Create a structured plan following the <output_format>.
     - **Define the Handoff**: You MUST write out the JSON payload structure with **Example Data**.
     - **SAVE THE PLAN**: Write the final plan to `docs/plans/current_spec.md` (Create the directory if needed). This allows Dev agents to read it later.
 
-4. **Review**:
+5. **Review**:
     - Ask the user for confirmation.
 
 </workflow>
@@ -52,17 +58,25 @@ Your goal is to design the **User Experience** first, then engineer the **Backen
 }
 ```
 
-### 🏗️ Phase 1: Backend Implementation (Go)
+### 🕵️ Phase 1: QA & Security
+
+  1. Build tests for coverage of perposed code additions and chages based on how the code SHOULD work
+
+
+### 🏗️ Phase 2: Backend Implementation (Go)
 
   1. Models: {Changes to internal/models}
   2. API: {Routes in internal/api/routes}
   3. Logic: {Handlers in internal/api/handlers}
+  4. Tests: {Unit tests to verify API behavior}
+  5. Triage any issues found during testing
 
 ### 🎨 Phase 2: Frontend Implementation (React)
 
   1. Client: {Update src/api/client.ts}
   2. UI: {Components in src/components}
   3. Tests: {Unit tests to verify UX states}
+  4. Triage any issues found during testing
 
 ### 🕵️ Phase 3: QA & Security
 

.github/agents/prompt_template/bug_fix.md

@@ -0,0 +1,13 @@
+"I am seeing bug [X].
+
+Do not propose a fix yet. First, run a Trace Analysis:
+
+List every file involved in this feature's workflow from Frontend Component -> API Handler -> Database.
+
+Read these files to understand the full data flow.
+
+Tell me if there is a logic gap between how the Frontend sends data and how the Backend expects it.
+
+Once you have mapped the flow, then propose the plan."
+
+---

.github/copilot-instructions.md

@@ -16,6 +16,20 @@ Every session should improve the codebase, not just add to it. Actively refactor
 - **Single Backend Source**: All backend code MUST reside in `backend/`.
 - **No Python**: This is a Go (Backend) + React/TypeScript (Frontend) project. Do not introduce Python scripts or requirements.
 
+ ## 🛑 Root Cause Analysis Protocol (MANDATORY)
+**Constraint:** You must NEVER patch a symptom without tracing the root cause.
+If a bug is reported, do NOT stop at the first error message found.
+
+**The "Context First" Rule:**
+Before proposing ANY code change or fix, you must build a mental map of the feature:
+1.  **Entry Point:** Where does the data enter? (API Route / UI Event)
+2.  **Transformation:** How is the data modified? (Handlers / Middleware)
+3.  **Persistence:** Where is it stored? (DB Models / Files)
+4.  **Exit Point:** How is it returned to the user?
+
+**Anti-Pattern Warning:** - Do not assume the error log is the *cause*; it is often just the *victim* of an upstream failure.
+- If you find an error, search for "upstream callers" to see *why* that data was bad in the first place.
+
 ## Big Picture
 
 - Charon is a self-hosted web app for managing reverse proxy host configurations with the novice user in mind. Everything should prioritize simplicity, usability, reliability, and security, all rolled into one simple binary + static assets deployment. No external dependencies.