Tablekeeper, built by a six-seat dark factory

Six Claude Code seats on Opus 5.5 built Tablekeeper, a restaurant booking service, in one Band Desktop room, through all four stages. The only human input was one task message per stage, prepared before the run: 4 of the room's 3,260 messages. An architect splits each stage into items. A critic reads every plan before any code is written, a builder writes the code, a verifier checks each item on its own fresh clone, a designer reviews every screen at phone, middle and desktop widths, and a release clerk packages the stage and runs the organizers' harness. BLOCKED from the critic, REFUTED from the verifier and CHANGES from the designer stop work and go to the architect, which routes it back. A check counts only after it has failed on a deliberately broken version, and every seat's commit names the seat. Review changed the result. In stage 3 the verifier re-timed a verified item: 7 of 9 runs went over the 5-second limit. The architect sent it back, and identical reads came down to 0.90 to 1.05 seconds. Different queries still took about 3 seconds, an open risk in the stage-3 report; in stage 4 that code went over the limit, and the band reopened stage 3 and corrected it. In all, the critic blocked 8 plan versions and the verifier refuted 3 items. Stage times (task to final report) add up to 23 h 40 min. Model use was $513 at API list prices; the run used a flat Claude Max plan, about 18.5 % of one weekly limit. On the organizers' harness, from a fresh clone, each stage folder claims its own stage and stage 4 passes every shipped check of suites 1 to 4. The judges run more tests than the shipped ones. Run 1 stopped in stage 4 at Band's 10,000-message room limit; run 2 kept four seats' tool activity out of the room and finished in 3,260 messages. FACTORY.md lists all 20 failures and what each changed. That, the six mandates (none names the track) and the stand-up scripts are what another team needs to point the factory at a different spec.