You end this lesson with: A running loop on your own repo — one state file, one exit condition — with at least one real unattended commit as proof.

Project 09. Close the Loop (Capstone)

Related Lectures: Lecture 13. Loop Engineering · Lecture 19. Evolving the System

Illustrative composite. A developer sets an unattended loop running before bed and checks the state file first thing in the morning: "3 rounds complete, exit condition met." Satisfied, they move on to the next task without opening the repository. Two days later a teammate asks why the fix never shipped. The git log shows zero commits from that night, the loop's exit condition had fired on a verification command that was silently misconfigured to always pass. The state file wasn't wrong about what it saw; it was wrong about what happened, and nothing checked the one thing that would have caught it: the actual repository state.

That gap, trusting a self-report over the record, is what this capstone is built to close.

What You'll Do

This is the course capstone. Every prior project built one piece of a harness: a readable repo, continuity across restarts, verification that can't be talked past, observability, a loop. This project asks for one thing only: ship a small autonomous loop on your own repository, walk away, and come back to a real unattended commit.

Scope guard, stated up front: this is not "rebuild the academy's own loop." One state file, one exit condition. If your design has more moving parts than that, you are over-building the capstone. Cut it back down.

The Rule This Lab Tests

Use the git log, or your own independent verification command, as ground truth for whether the loop actually did something; use the state file only to track what the loop planned to do next. When the two disagree, trust the log, not the file. The observable signal is in your own run: does the state file's round count match the commit count in the log?

Observable in your run	Trust	Why
State file says "3 rounds, exit met"; git log shows fewer commits than rounds	The git log	The state file is the loop's own self-report; it can go stale the same way a feature list can (Lecture 9)
State file says "round 2 in progress"; you want to know what happens next	The state file	The log won't tell you what the loop planned; that's the state file's job
The loop's final summary claims all checks pass	Run the verification command yourself	A summary is prose, not proof, the same rule this course opened with

Tools You'll Use

Claude Code or Codex (or the CLI agent you used for P07)
Git, on a real repository you own, not a throwaway
Everything you built in P01-P08: harness files, feature list, continuity files, verification gates, run log
A way to let the agent run unattended for at least one full cycle (a terminal you leave open, /loop, a scheduled run, your choice)

Steps

Prep

Pick a real, small, bounded task on a real repository, yours, not a toy. Something you'd actually want done: a missing test file, a small refactor, a docs gap, a dependency bump with verification.
Confirm your harness is in place on that repo: an entry file the agent reads first, a way to verify done, a place to write state.
Write the exit condition before writing anything else: what observable fact means the loop should stop. Not "when it feels done": a command, a file, a check.

Build the Loop

One state file, loop-state.md. Not a state directory, not five files: one file the loop reads at the start of every round and writes at the end. It needs: current round, what happened last round, what's next, and whether the exit condition has fired.
One exit condition. Encode it as something the loop itself can check: a passing verification command, a feature list with every item done, a fixed round cap as a backstop. Write the check, not a description of the check.
Wire the round: read state → do the bounded unit of work → verify → write state → check exit condition → stop or continue. This is the same maker-checker shape from P07, collapsed into one file's worth of ceremony instead of three branches' worth.
Before you start it, predict your failure mode. Unattended loops fail in a small number of predictable ways on a first run: the exit condition fires on a check that's silently misconfigured, the state write happens before the commit instead of after, or the loop stops on a turn cap having never verified anything. Pick the one you think is most likely for your setup and write down why, before you start the loop.

diagram

drawing

One round is the whole capstone: read state, do the bounded work, verify it, write state back, then check the one exit condition before looping again.

Start it and step away. The point of this capstone is not watching it work. It's confirming it doesn't need you to. Leave for at least one full round without checking in.

Verify the Real Thing Happened

Come back and look at your repo's git log, not the agent's summary. Is there a real commit you didn't make?
Check the state file: does its final content match what actually happened in the repo? A loop that writes "done" to its state file while the commit failed is worse than no loop at all. It's a harness lying to you, the exact failure Lecture 09 named.
Run your own verification command by hand, independent of what the loop claims. Confirm it actually passes.

Stretch: A Second Unattended Round (Open)

Pick a second task on the same repository, or a different one you own, and run the whole loop again, state file, exit condition, verify-the-real-thing, without re-reading these steps for the plan. No scaffolding beyond the scope guard: one state file, one exit condition. If the second run breaks differently than the first, that's the data the retro below asks for.

How to Measure Results

Metric	Description
Unattended commit	At least one real commit produced while you were not watching
State accuracy	Whether the state file's final content matches the actual repo state
Exit fidelity	Whether the loop stopped because the exit condition fired, not because you killed it
Scope discipline	One state file, one exit condition, not a rebuilt version of the whole course
Independent verification	Whether your own hand-run check agrees with what the loop claimed

What to Submit

Your loop's state file (loop-state.md), final content, showing at least one complete round
The exit condition, as the actual check (command, file, or config), not a prose description
The git log entry for the unattended commit, with a timestamp gap showing you weren't there
A short retro (half a page): what broke first, what you had to fix, and whether the loop would survive a second unattended run without changes

Key Takeaways

Trust the git log over the loop's own state-file claim about what happened.
Write the exit condition as a check the loop runs, not a description of one.
Keep the state to one file; a directory of files is scope creep, not thoroughness.
Step away for a full round; watching it work defeats the point of the capstone.
Verify the commit by hand, independent of anything the loop reports.

What You Have Now

A running loop on your own repo — one state file, one exit condition — with at least one real unattended commit as proof. harness/loop-state.md and the commit itself are the course's closing artifact: the point where every mechanism from the eighteen lectures and eight projects before it, the readable repo, continuity across restarts, feature lists, verification gates, observability, loop and graph structure, has to hold up with nobody watching.

Lecture 13. Loop Engineering: the state file and exit condition this project asks you to build are exactly what that lecture names
Lecture 19. Evolving the System: what to do with what broke on your first unattended run
Lecture 09. Why Agents Declare Victory Too Early: why you verify the commit yourself instead of trusting the loop's own account
Lecture 12. Why Every Session Must Leave a Clean State: every round of your loop is a session that must leave one