Tablekeeper — Built by A Dark Factory

Tablekeeper is a restaurant reservation service where a table can never be double-booked — under concurrency, retries and time zones. All four stages of the track are complete and passing: 158 shipped checks green in the graded isolated configuration — no network, 2 CPUs, 2 GiB. No human wrote a line of its application code. A three-seat AI software factory, running in one BAND Desktop room, built it one stage at a time. The human sent one task per stage and nothing else — four messages in total. The factory is the deliverable. Tablekeeper is what came out of it. Architect (OpenCode, MiniMax-M2.5) plans and routes every handoff. Developer (Claude Code, claude-sonnet-5-5) writes all application code. QA Lead (OpenCode, MiniMax-M2.5) reviews on a different model family than the implementer, so the checker does not share the builder's blind spots. Three decisions carry the whole thing. The mandates name nothing about this track — search them for "tablekeeper" and you get nothing, so swapping the dispatch keeps the factory. QA writes acceptance tests from the specification rather than from the shipped checks, and builds every reviewed revision from a clean checkout. And the full specification is pasted into every handoff, never referenced, because each seat sees only what is addressed to it. It caught real defects. Stage 1: QA found 10 of 120 checks failing and rejected the revision with three root causes. Stage 3, with every shipped check green: QA reported PASS on the harness, kept reading the specification, and failed the build anyway over two deviations the checks never exercise. A passing test suite is not a passing spec. The service is Go standard library, SQLite with WAL and bcrypt — a static binary in one container that builds and serves with no outbound network, with a server-rendered browser UI over the same JSON API. 1 h 44 min. $0.88. Sixteen commits across the stage folders, not one of them human.