lfe-diagnoselisted

# LFE Diagnose ## Position in Pipeline - **Phase**: 3 (Inspector sub-pipeline, Step 3 — conditional) - **Persona**: Inspector (triggers), Builder (fixes) - **Trigger**: Called by Inspector when `/lfe-inspector` verification fails - **Input**: Failing behavior identified during inspection - **Output**: Fix applied → returns to Builder sub-pipeline for re-verification ## Hard Rules 1. **First-failure only**: Diagnose may only run on the **first** failed inspection of a slice. The Inspector's Cycle Guard (`lfe-inspector/SKILL.md` Cycle Guard step) is responsible for blocking re-entry on the second failure. If you discover that `.plans/inspection_report.md` already records a `status: failed` for the same `slice:`, halt immediately, leave the existing report as-is, and bounce back to Inspector for Brain triage (see `LOOP_ARCHITECTURE.md` Scenario 2.2). This is a defensive belt-and-braces check; the Cycle Guard should have prevented this entry. 2. **Minimal fix only**: Solve the diagnosed problem, nothing more. No opportunistic refactors. ## Process 1. **Feedback Loop**: Build a deterministic repro (test/script) that reliably demonstrates the failure. 2. **Reproduce**: Run the loop and witness the failure. Confirm it matches the Inspector's reported issue. 3. **Hypothesise**: Generate 3-5 ranked, falsifiable hypotheses for the root cause. 4. **Instrument**: Add targeted probes to test hypotheses one at a time. Eliminate hypotheses until the root cause is confirmed. 5. **Fix**: W