Stage 02 — The bug hunt: six defects, found and fixed

You will produce: six diagnosed and fixed defects, each with a one-line explanation in your notes — and a game that plays exactly as before (or better). Warm-up: the three-latency table from stage 01, reproduced from memory.

Why this exists#

This project ships six real defects — a mix of a live bug, dead weight, and loaded traps that only fire under conditions you haven't hit yet. AI-written code fails in exactly these quiet ways: it runs, so nobody looks. Auditing means looking.

The hunt — what you get is the symptom, not the location#

Diagnose before fixing: for each, write where, why, fix in your notes. Use the tools, not grep-and-hope: the profiler for #1, the warning panel, Output prints, and the official demo as a reference implementation.

The disk grinder. Something in this project writes a file to disk roughly sixty times per second while you play. Find it with the profiler or by reasoning about _process scope — then explain two distinct things wrong with the line you find (when it runs, and where it writes — think about what res:// becomes in an exported game).
The unreachable feature. There's a whole recording branch that cannot ever execute. Prove it can't, then decide — your judgment, written down — whether to delete it or wire it up. (If you wire it: the chart it records will be systematically early or late. By how much, and why? Stage 01's table answers this.)
The vestigial limbs. At least two declared things are never read by anyone. Find them; delete them; explain what each was probably meant to do.
The baked-in typo. One exported property's name is misspelled — and because it's exported, the typo lives in scene files too. Fix it everywhere and explain what would have broken if you'd renamed the script side only.
The cargo cult. One scene sets a process-mode flag that does nothing today — and would actively break a pause feature tomorrow. Find it, explain the interaction with get_tree().paused, and remove or justify it (pausing docs).
The unstoppable miss. Compare what happens to a note that scrolls past unhit versus one you hit badly. One of these keeps doing something it shouldn't. The official demo distinguishes these two cases explicitly — find how, then fix yours.

Checkpoint — definition of done#

All six: where/why/fix written down, fixes committed one per commit (git init first if this project never got a repo — it didn't)
The game plays identically; the disk is quiet (verify with the profiler, not vibes)
Warning panel: clean, including the typed-declaration warnings if you enable them here (do — this project predates your typing rules and it will complain; fixing those is optional scope, counting how many there are is not)
You can explain: which of the six could have shipped to a player and which could not, and why?

If you get stuck#

#1 refuses to show itself → Debugger → Profiler, sort by calls; sixty-per-second stands out.
#6's comparison → play the demo and the prototype side by side, miss on purpose, watch the note in both.
General rule for the hunt: write your hypothesis down before testing it — wrong hypotheses ruled out are progress, and the habit is the actual lesson here.