Stage 07 — Consolidation: prove the slice is yours

You will build: nothing new — and that's the hard part. This stage verifies the whole slice lives in your head, not in these documents. Concepts: none new. Recall, rebuild, review, plan.

Part A — The full-slice checkpoint#

Run the game and tick the overview's definition of done, every box, in one sitting:

• 8-way movement, collision, sliding, camera limits — all holding
• Till → plant → grow (N-key days) → harvest → inventory count, for two crop kinds
• Act is gated by the state machine (no mid-swing actions, no queued spam)
• Warning panel completely clean across every script
• git log tells the slice's story in commits

Part B — The rebuild test (the honest one)#

New scratch scene, blank script, docs closed: rewrite the player's movement + state machine from memory. Not verbatim — working. You get the class reference (that's not cheating, that's the job); you don't get stages 01/05. When it runs, diff it mentally against the real one: what did you forget, and was it structure or syntax? Structure gaps go in your project notes as things to revisit; syntax gaps are nothing — the editor catches those forever.

Then delete the scratch. It was a test, not a fork.

Part C — Self-review battery#

Answer in writing, in your project notes — one or two sentences each, no peeking:

1. Draw the state machine: states, arrows, and what triggers each arrow.
2. A plot's journey: every field of PlotState from grass to harvested, in order.
3. Why does deleting the Ground node lose zero game truth?
4. turnip.tres is open in the Inspector while the game runs; you change days_per_stage. What happens to already-planted turnips, and why?
5. Layers vs masks, one sentence each, no notes.
6. Where does the decision live when act must choose till/plant/harvest — and why is that better in one place than three?
7. Which two things would you serialize to save this farm, and which nodes rebuild from them?
8. The typing contract: what has it actually caught for you so far? (Honest answer; "nothing yet" is data too.)

Wrong or shaky answers aren't failures — they're next session's warm-up questions. Note them.

Part D — Get your code read#

The one step you can't do alone: have someone else read your scripts against the architecture doc — a friend, a forum, a code review with whatever help you trust. Fresh eyes catch the habits you've already stopped seeing. If truly nobody's available, leave the code for three days and review it yourself cold; distance is a decent substitute for a stranger.

Part E — Choose the next module (and this time, write the plan yourself)#

The deferred list, with what each teaches:

The core game's architecture was handed to you. The next module's isn't: before building anything, write its architecture amendment yourself — a systems-map row, a signal entry, a design decision if there's a real choice — using the existing document as your model. That's this whole almanac's loop closing: the documentation you're reading was built so that, eventually, you'd be the one writing it.

Improvement every day. This was several of them.