Project 7 · Break It on Purpose

⚠️ Throwaway repo. Set a limit first. This project deliberately induces failure modes — do it in a fully disposable sandbox with network/write access you can revoke instantly, and keep a hard wall-clock cap running the whole time, not just a run cap.

The scenario

Every failure mode in failure-modes.md and anti-patterns.md reads clean on the page. This project makes you feel one happen, on purpose, on a real (but disposable) codebase — because a guardrail you've only read about is a guardrail you'll trust too much the first time it actually needs to fire. Take a real repo with a nontrivial build (a monorepo with a build step that can legitimately fail for several different reasons) and build a loop with one part missing, chosen from the list below. Watch it fail the way the missing part predicts. Then add the part back and watch the same loop recover.

What you'll build

Pick (or your instructor assigns) one deliberately broken loop:

Build the broken version first — in a worktree, capped at a wall-clock 10 minutes no matter what — and let it run. Capture what you see in the run log. Then add the missing part back and re-run the identical task.

# Claude Code — deliberately missing a stop, capped by wall clock only for safety
> /loop Fix the build. (Intentionally no other instructions — this is the broken
  version.) Log one line every beat. HARD STOP after 10 minutes wall-clock regardless
  of outcome — this cap is a safety net, not the lesson.

# OpenCode — the same missing-stop scenario, capped defensively
timeout 600 bash -c '
  while true; do
    opencode run "Fix the build."
  done
'

Done when (provable stop)

• You have a run-log excerpt showing the broken loop exhibiting exactly the failure its missing part predicts (a doom loop, a false-green, a runaway cost, etc.).
• You have a second run-log excerpt showing the fixed loop (same task, missing part restored) reaching a genuine stop.
• A one-paragraph note names which part was missing, what you observed, and which line in failure-modes.md predicted it.
• The broken run never exceeded its wall-clock safety cap — the lesson is contained, not open-ended.

Going deeper

This project is the practice half of the recovery playbook — read it right after, not before, so the steps land against something you just watched happen rather than abstract advice. infinite-loops.md has the doom-loop and ping-pong scenarios this project draws its "missing parts" table from.

When it goes wrong

---

Sources: the failure catalog and recovery steps come from failure-modes.md, anti-patterns.md, and the recovery playbook, drawing on Panaversity's Loop Engineering: A Crash Course (S1) and Addy Osmani's Loop Engineering (S5). Full attribution: resources/sources.md.