Record each loop turn — code state, error, fix, what you learned — into a clean, commit-ready log.

Challenge

1. Challenge 01

   For each build-test-revise turn, log four things: what you changed, what broke (paste the real error), what fixed it, and what you learned that the spec didn't tell you. A clean log makes your work reproducible — and gives you the commit messages the build-week larp asks for.

   Show sample answer
2. Challenge 02

   After each failed build, before you fix it, write down your hypothesis: why do you think it broke? What do you expect the error message to say? Then run it and compare your hypothesis to the actual error. Log the gap between what you predicted and what happened.

   Show sample answer
3. Challenge 03

   Run the same test or build twice with no code changes between them. If the result is different (timing-dependent failures, order changes, resource limits), log that you found a fluke. What conditions trigger it? What do you need to change to make it deterministic?

   Show sample answer
4. Challenge 04

   When you fix a bug, log not just the fix but also the REASON it was a bug. What rule did your code break? Why did the rule matter? This is the 'learned' part — it prevents you from writing the same bug in a different shape.

   Show sample answer
5. Challenge 05

   Pick a turn where you spent more than 5 minutes debugging. Walk backward: what was the first thing you changed before the error appeared? Did you test immediately after that change, or did you keep coding? Log whether you could have caught this error sooner.

   Show sample answer
6. Challenge 06

   When a fix works, note whether you understand WHY it works or whether you just tried things until one stuck. If you got lucky, investigate the working code until you can explain it in one sentence. Log that explanation — future you will read it.

   Show sample answer
7. Challenge 07

   At the end of each session, look at your log and identify a pattern: did you make the same mistake twice? Did one type of error show up in multiple places? If so, write a bullet-point 'anti-pattern' — the thing to avoid — and keep it visible while you code next time.

   Show sample answer
8. Challenge 08

   Before you commit, re-read your log. For each turn, ask: could someone else understand what I did and why by reading this entry? If not, expand it with one more sentence of context. A log you can hand to a reviewer is a log worth writing.

   Show sample answer