feat(directives): scavenge superpowers plugin (test-driven-development, systematic-debugging): 6 directives

2026-07-04 12:31:40 -04:00
parent 19738b52e7
commit 2a1b1698b9
13 changed files with 286 additions and 1 deletions
@@ -0,0 +1,8 @@
+# three_fix_failures_question_architecture
+
+## v1
+
+**Why this iteration:** Lifted from the global OpenCode superpowers plugin (obra/superpowers) — `skills/systematic-debugging/SKILL.md`. The directive encodes Phase 4.5 (lines 199-213) plus the two red flags at lines 227-228. Counterweight to the LLM default of "one more fix attempt" past two failures, which is sunk-cost driven and signal-blind. After three failures, the architectural question is the right next step, not Fix #4.
+**Source:** superpowers plugin `skills/systematic-debugging/SKILL.md:199-213` (Phase 4.5: If 3+ Fixes Failed) + `:227-228` (Red Flags)
+
+**Lifted:** 2026-07-04 (scavenge sweep: superpowers plugin directives)
@@ -0,0 +1,45 @@
+# After three failed fixes, stop and question the architecture — the pattern is wrong, not the line of code
+
+## The rule
+
+If three or more fix attempts have failed to resolve a bug (each fix revealing a new problem in a different place, each fix requiring "massive refactoring" to implement, each fix creating new symptoms elsewhere), the pattern is wrong, not the code. STOP attempting Fix #4 without architectural discussion.
+
+Per `skills/systematic-debugging/SKILL.md:199-213` (Phase 4.5: If 3+ Fixes Failed):
+
+> **Pattern indicating architectural problem:**
+> - Each fix reveals new shared state/coupling/problem in different place
+> - Fixes require "massive refactoring" to implement
+> - Each fix creates new symptoms elsewhere
+>
+> **STOP and question fundamentals:**
+> - Is this pattern fundamentally sound?
+> - Are we "sticking with it through sheer inertia"?
+> - Should we refactor architecture vs. continue fixing symptoms?
+>
+> **Discuss with your human partner before attempting more fixes**
+>
+> This is NOT a failed hypothesis - this is a wrong architecture.
+
+## Why
+
+A wrong architecture surfaces symptoms in many places. Each symptom fix touches one of those places, but the underlying architectural mistake generates the next symptom in a different place. The fix loop is unbounded; the architecture is the bug.
+
+Continuing to attempt fixes past three is sunk-cost driven and signal-blind. The first fix was a hypothesis; by the third, the hypothesis domain has shifted from "this line is wrong" to "this design is wrong." The agent's tools (line-level edits) are mismatched to the new domain (architectural question).
+
+## The three-failure red flags
+
+Per `skills/systematic-debugging/SKILL.md:227-228`:
+
+- "**One more fix attempt"** (when already tried 2+)
+- **Each fix reveals new problem in different place**
+
+If either flag is true, the agent has reached the architecture-question threshold. Stop.
+
+## What this means in practice
+
+- After failed Fix #1: form a new hypothesis, return to Phase 3 (Hypothesis and Testing).
+- After failed Fix #2: return to Phase 1 (Root Cause Investigation) with the new information from the failed fixes.
+- After failed Fix #3: STOP. The architecture is the bug. Write up the architectural question; surface the pattern of fixes; ask the user or Tier 2 whether to refactor or to try a different design entirely.
+- The agent does NOT attempt Fix #4 without explicit user permission. The architectural question is a decision the user makes, not the agent.
+- "Just one more fix" past three is a red flag, not a heuristic.
+- A fix loop is not "progress because something changes" — it is "regression because each change creates a new symptom."