Circuit breaker

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:

1. Name the loop. Say it plainly: "Changed this a few times, still failing. Stopping to find the cause before changing more." Breaks the autopilot.
2. 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.
3. 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.
4. 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.
5. Still unclear -> shrink it. Isolate the smallest reproducible piece. Change one variable at a time so each result means something.
6. 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

1. First attempt. Normal trying isn't thrashing. Never gate the first try.
2. Genuinely new problem. A fresh, different bug is not a loop.
3. 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.