stepbacklisted

# Stepback - Strategic Reassessment **Core principle:** If you've tried 2+ fixes for the same class of problem, you're probably patching symptoms. Stop. Zoom out. Research the architecture. ## When to Trigger ```dot digraph stepback { "Fix attempt failed?" [shape=diamond]; "Is this the 2nd+ attempt?" [shape=diamond]; "Same root system?" [shape=diamond]; "Keep debugging" [shape=box]; "STOP — Run /stepback" [shape=box, style=bold]; "Fix attempt failed?" -> "Is this the 2nd+ attempt?" [label="yes"]; "Fix attempt failed?" -> "Keep debugging" [label="no, first try"]; "Is this the 2nd+ attempt?" -> "Same root system?" [label="yes"]; "Is this the 2nd+ attempt?" -> "Keep debugging" [label="no"]; "Same root system?" -> "STOP — Run /stepback" [label="yes"]; "Same root system?" -> "Keep debugging" [label="different systems"]; } ``` **Symptoms that demand /stepback:** - Same error returns after a "fix" - Fix A reveals error B reveals error C (cascade) - Locally it works, deployed it doesn't - Multiple components broken by the same underlying cause - Fixes feel like whack-a-mole **Proactive triggers (don't wait for failure):** - Touching deployment config, build pipeline, or infrastructure - Changing middleware, routing, or auth at the platform level - Modifying `next.config.js`, `vercel.json`, Dockerfile, CI/CD ## Execution ### STEP 1 — Stop and Inventory List every fix attempt so far in this session. For each: - What symptom it addressed - Whether it worke