Proofline: Tablekeeper

Inspiration A reservation is a promise. When a table closes before dinner, keeping it may require changing several bookings together. What it does Tablekeeper offers booking, recurring visits, dated policies and a manager's seating-repair preview. Apply moves bookings atomically while preserving guest times and accepted terms. The planner supports six tables, four declared pairs and six considered bookings; every confirmed booking overlapping the closure counts. How we built it Shivam Gupta directed the product and configured Proofline: four BAND seats with generic mandates. Coordinator planned, Engineer and Experience implemented, and Verifier checked committed results independently. One human task covered all four stages. Original commits, handoffs and the full room export are preserved. Challenges Verifier found that a corrupted restore could erase an individually changed recurring booking's permanent exception. It rejected the candidate; Engineer repaired history validation and independent rechecks passed. A daemon interruption required an operator restart of the same seats and room, with new provider sessions. No new task or implementation hints were sent. Accomplishments All four stages were accepted. Workspace and fresh-clone isolated runs each passed 120, 145, 152 and 158 required checks for stages one to four, including inherited suites. These are check executions, not distinct requirements. Published tests are partial; hidden-suite success is not claimed. What we learned Independent review matters after public tests pass. The frozen service has ephemeral state and judge controls, so it is not a public production deployment. Provider-billed spend is unknown.