Solutions

Each lab has a solution page with the final state of every file the lab creates or changes, what a good run looks like, the three most common wrong turns, and where each file lives in the companion repo.

How to use them

Try the lab first. The harness you build is only half the point. The other half is the moment your first hook gets bypassed, or your first rule fails its own test, and a solution page read in advance takes that moment away.

Come here when you're stuck, when you want to check your work against a known-good version, or when you've fallen behind in a facilitated session and need to catch up. Each page links back to its lab. Answers to the numbered Q-prompts are not on these pages. They are discussion questions, and facilitators have them in the facilitator keys.

The numbers on the solution pages (scoreboard figures, receipts, transcripts) are illustrative, like the ones in the labs, until the workshop has been piloted.

The finished harness in the companion repo

The companion repo, larkspur-payments, carries the finished state of every lab in a folder called harness-reference/. It is the harness after Lab 10, laid out exactly as it would sit at the root of the repo:

Path in harness-reference/	Lab
AGENTS.md	2
.factory/settings.json (permissionRules and sessionDefaultSettings.autonomyLevel)	4
.factory/hooks.json, .factory/hooks/*.mjs and .factory/hooks/lib/protected.mjs	5, 8
.factory/skills/ and .factory/commands/	6
.factory/droids/money-reviewer.md	7
.factory/mcp.json	8
.github/workflows/droid-scoreboard.yml	9
mission.md	10

Jump to the end state

To start from the finished harness, copy the whole folder over your checkout from the repo root:

larkspur-payments

> cp -R harness-reference/. .
> git checkout -- README.md
> git add AGENTS.md .factory .github mission.md && git commit -m "Apply the reference harness"

The trailing /. copies the dot-directories (.factory/, .github/) as well as the visible files. It overwrites any file with the same name, including the root README.md (the reference folder has its own), which is why the second line puts that back. Commit or stash your own work first if you want to compare.

Three things to know straight afterwards:

• Commit before you run the scoreboard. It runs every task in a git worktree made from HEAD, so it only sees what is committed.
• Start a new droid session. Droid snapshots hooks at startup and won't pick up a changed hooks.json mid-session.
• The reference hooks.json wires in the Lab 5 file guard. For the Lab 8 behavior (migrations allowed under an approved ticket), point the first PreToolUse group at protect-paths.lab8.mjs, as the Lab 8 solution shows. Lab 9 also needs a FACTORY_API_KEY repository secret and the Factory Droid GitHub App installed on the repository (for the review job), and its review guidelines skill is one you write yourself.

To catch up to a particular lab rather than the end, copy only the files that lab adds, using the table above or the "Where it lives" section at the bottom of each solution page.

All solutions

Lab	Solution
0 — Establish your readiness baseline	Lab 0 solution
1 — Your first delegation, and reading the session	Lab 1 solution
2 — AGENTS.md: the contract Droid reads first	Lab 2 solution
3 — Spec mode: review the decision before the diff	Lab 3 solution
4 — Autonomy levels and permission rules	Lab 4 solution
5 — Hooks: invariants that cannot be talked past	Lab 5 solution
6 — Skills and slash commands	Lab 6 solution
7 — Custom droids: a reviewer with fresh eyes	Lab 7 solution
8 — MCP: facts from your own systems	Lab 8 solution
9 — Droid in CI with droid exec	Lab 9 solution
10 — Capstone: a Mission to retire float money	Lab 10 solution