Tablekeeper

Tablekeeper is a restaurant reservation service and website. Diners search availability, book a table, get a reference, and cancel or change bookings. Restaurants have table sizes, opening hours, cancellation policies and tables that can be combined for larger groups. It reaches claimed stage 4, the highest in the track. Four messages went into the BAND room, one per stage. Everything after them is the band: the agents wrote the code, reviewed it, rejected it, and reported back. THE FACTORY Three seats, built on one rule: no seat accepts its own work. The coordinator routes work and never writes or judges it. The coder writes and never judges. The verifier judges and cannot edit what it judges, because a seat that can fix the code becomes the author of the work it approves. WHAT IT CAUGHT The coder reported stage 1 finished with all 120 supplied checks passing. The verifier rejected it. It refused to trust the report: it rebuilt the exact commit from a clean archive, confirmed the container runs with outbound network blocked, and derived around 300 assertions from the specification before looking at what was supplied. WHAT WENT WRONG All four stages ended on a model usage limit rather than on a decision. Each still produced a complete buildable folder, because every task said to commit a thin version of every surface before deepening any of them. An earlier run that did not follow that rule lost two hours of finished work and would not have been ranked at all. The verifier judged stage 1 and nothing after it. At each later stage it correctly refused to judge an intermediate milestone and waited for a final revision the limit never allowed. So stages 2 to 4 are unreviewed, and by this factory's own standard their evidence is a claim rather than a fact. FACTORY.md says what we would change: a factory that expects interruption should review each milestone provisionally.