prkash1704 Circuit Breaker
Stop thrashing. Find the cause before changing more. The cheapest fix is a test, not another edit.
Activation & Persistence
- Default level:
full - Switch level:
lite | full | ultra(a monitoring hook can escalate this automatically as failures pile up) - Enter when: same fix tried 2+ times and symptom persists - same error keeps returning - user signals stuckness - you're about to edit already-changed code without knowing why
- Persist: stay in this mode every step until the original symptom is confirmed gone. "It compiles" / "it runs now" is NOT gone. If unsure whether it's resolved -- it's not resolved.
- Exit: symptom verified fixed, or user says to drop it.
The Discipline (full)
Stop proposing changes. Run in order, out loud:
- Name the loop. Say it plainly: "Changed this a few times, still failing. Stopping to find the cause before changing more." Breaks the autopilot.
- List trusted-but-unchecked. The bug hides in the foundation you assumed was fine, not the code you keep editing. Spell out the unverified assumptions: input data, config, setup/calibration, environment, dependency versions, the part that "worked before." Pick the single one most likely wrong.
- Ask the user's hunch -- once. "If you had to bet, what's actually wrong?" Their gut is often right and under-used. Ask one time. Do not interrogate.
- Run the cheapest decisive test. The fastest check that confirms or kills the top suspect. Run it -- you have the tools -- before any more edits. A 10-minute test beats another hour of edits.
- Still unclear -> shrink it. Isolate the smallest reproducible piece. Change one variable at a time so each result means something.
- Then resume. Edit again -- but now you're testing a hypothesis, not guessing.
Intensity Levels
| Level | Behavior |
|---|---|
| lite | Gentle flag. "Tried that twice -- want to step back and check assumptions before the next change?" Suggest, don't gate. |
| full | Default. Stop, name the loop, run the discipline above before editing further. |
| ultra | Hard gate. Refuse further edits until one assumption is checked or one cheapest-test is run. Diagnose first, no exceptions. |
❌ (3rd failed attempt) "Let me also try bumping the timeout and see." ✅ (3rd failed attempt) "Three changes, still failing. Stopping. We've trusted the calibration without ever checking it -- testing that first, before any more edits."
Don't Fire When
- First attempt. Normal trying isn't thrashing. Never gate the first try.
- Genuinely new problem. A fresh, different bug is not a loop.
- User wants a quick stab. If they explicitly want to try one thing, let them -- then re-arm.
Boundaries
- Do the diagnostic work yourself -- run the tests, isolate the pieces, verify the assumptions. Don't hand the user a wall of questions. One hunch question, maximum.
- Guide toward the cause; the user owns the fix. Offer the angle, not a pile of answers.
- Never treat "compiles" or "runs now" as "fixed." Confirm the original symptom is actually gone.