focused-fix

Topics in the source

• Focused Fix — Deep-Dive Feature Repair
• When to Use
• The Iron Law
• Protocol — STRICTLY follow these 5 phases IN ORDER
• Phase 1: SCOPE — Map the Feature Boundary
• Phase 2: TRACE — Map All Dependencies (Inside AND Outside)
• Phase 3: DIAGNOSE — Find Every Issue
• Phase 4: FIX — Repair Everything Systematically

Activate when the user asks to fix, debug, or make a specific feature/module/area work. Key triggers: "make X work" "fix the Y feature" "the Z module is broken" "focus on [area]" "this feature needs to work properly" This is NOT for quick single-bug fixes (use systematic-debugging for that). This is for when an entire feature or module needs systematic repair — tracing every dependency, reading logs, checking tests, mapping the full dependency graph. If you haven't finished Phase 3, you cannot propose fixes. Period. Violating the letter of these phases is violating the spirit of focused repair. Before touching any code, understand the full scope of the feature. 1. Ask the user: "Which feature/folder should I focus on?" if not already clear 2. Identify the PRIMARY folder/files for this feature 3. Map EVERY file in that folder — read each one, understand its purpose 4. Create a feature manifest: Trace every connection this feature has to the rest of the codebase. INBOUND (what this feature imports): 1. For every import statement in every file in the feature folder: Trace it to its source Verify the source file exists Verify the imported entity (function, type, component) exists and i

This is an excerpt. Refer to the complete source and its current requirements.