Specification, 93 acceptance tests, guardrails and prompts for an agent to build, in your own environment, a restaurant booking system: web chat and WhatsApp, a Telegram team desk, a waitlist and your own customer base. The system is not implemented yet: this repository is the plan, and you run the implementation.
There is no ready-made app here. There is the contract for what the app must do, the test battery that proves it, and the guardrails that stop the agent from cheating. The builder is Claude Code or Codex, running on your machine under your subscription. The sibling project Atende Clínica was made exactly this way and closed 93 out of 93 tests.
Dining rooms and tables with capacity, shifts by weekday, allocation of the smallest table that fits, "1 confirms / 2 cancels" confirmation, no-show, waitlist and large parties approved by the staff. Python 3 with the standard library only, and SQLite, one restaurant per installation.
A 20-section specification, 93 black-box tests, default decisions already proposed, a map to Raio-X, prompts for /goal and for the headless loop, and the guardrails that freeze the contract. An adversarial validator went through all of it and fixed 13 problems.
The customer contact stays with the restaurant, not the marketplace: the origin field rejects iFood and Rappi, and campaigns only go to people who consented (LGPD, Brazil's privacy law). These rules are Brazilian: marketplace terms such as iFood's and the LGPD are built in. The system returns clientes_novos_mes and retorno_atual_pct to the Raio-X de Margem dashboard.
This is the flow of the planned system, what the agent will build. A Python server with no dependencies, SQLite in a data folder and Docker for the VPS. Evolution and Telegram come in only through environment variables; without them the outbox is simulated and no network call leaves the process.
Through chat or WhatsApp they book in four replies, check and cancel their own booking, get answers from the FAQ, ask for a human and send "PARAR" (stop) when they want no more messages.
Alerts for new bookings, cancellations and large parties. Commands /reservas, /fila, /responder, /encerrar, /aprovar and /recusar, also as a direct reply to the customer's message.
With a token: the day's bookings by shift and dining room, an occupancy map by time slot, arrival and no-show, approve or refuse large parties, records for tables, shifts and FAQ, blocks and the human queue.
To run the plan you only need Python for the tests and an agent logged in through your subscription. Docker only comes in for the final check and the deploy; Evolution and Telegram are optional and yours.
The tests use pytest (a development tool). The application itself will have no dependencies.
# check python3 --version python3 -m pip install pytest
Through the subscription, no paid API. For the headless loop, clone execucao-longa into ~/projetos.
# check codex --version # or: claude --version
Docker does the final build and the VPS deploy. An Evolution instance and a Telegram bot only if you want the channels; credentials stay in the .env.
# check docker --version
The commands below are the repository's own. The cycle: answer the open decisions, freeze the contract, run the agent until 93 passed and LIMITES OK, and check with the independent verification.
There is no ./reserva yet: the repository only holds the plan. Check that the suite is collected without errors and that nothing passes yet (without the implementation the tests fail or error out, which is expected).
git clone https://github.com/inematds/reserva-restaurante && cd reserva-restaurante python3 -m pytest -q --collect-only | tail -1 # 93 tests collected python3 -m pytest -q | tail -1 # 0 passed
Read docs/DECISOES-ABERTAS.md (written in Portuguese): 20 default proposals already applied to the specification and the tests. Answering "ok to all" unblocks the run. If you change anything marked ⚠, edit docs/ESPECIFICACAO.md and the tests before freezing. For a real pilot, also replace exemplos/restaurante.json with your own dining rooms, tables and shifts.
less docs/DECISOES-ABERTAS.md
With everything committed, the script records the hash of tests/, pytest.ini, the specification and the verifier, plus the base commit, in hash-congelado.txt. From then on, any change to the tests is detected.
git add -A && git commit -m "contrato v1" bash longrun/2026-10-05-reservas-v1/congelar.sh
a) Headless loop with Codex (recommended). The loop.env sets 20 cycles of 30 min, 8 GB per cycle, a stop after 3 cycles without progress, model gpt-6-astra and CODEX_ARGS="-c sandbox_workspace_write.network_access=true": without it the Codex sandbox blocks the tests' local server.
~/projetos/execucao-longa/tools/loop-longrun.sh longrun/2026-10-05-reservas-v1
b) /goal in Claude Code. Open a fresh Claude Code session in the project folder and follow longrun/2026-10-05-reservas-v1/prompt-goal-claude.md: paste the /goal condition (the output must show 93 passed and LIMITES OK) and, as the first message, the block from prompt-goal-codex.md starting at RESULTADO:.
claude # fresh session, inside reserva-restaurante
c) Codex TUI, open. Paste the contents of longrun/2026-10-05-reservas-v1/prompt-goal-codex.md.
codex -c sandbox_workspace_write.network_access=true
In the loop, loop.log shows every cycle and progress.md has one line per checkpoint. The loop's exit code tells you what happened: 0 done (the final test passed), 1 cycle cap reached, 2 stopped after 3 cycles without progress, 3 another loop is already running in the folder. A test that conflicts with the specification goes to failures.md: that is a human gate, and the agent must not adjust the test or the specification.
tail -f longrun/2026-10-05-reservas-v1/loop.log cat longrun/2026-10-05-reservas-v1/state.md
When the agent says "done", run the three commands. The last one the agent never saw: it looks for fixture values copied into the code, brings up a restaurant that never appeared before (15-minute step, a single shift, a 3-table combination, no kitchen limit) and does a docker build with a healthcheck. Then open / and /equipe in the browser.
python3 -m pytest -q tests/ # 93 passed bash longrun/2026-10-05-reservas-v1/verificar-limites.sh # LIMITES OK python3 longrun/2026-10-05-reservas-v1/verificar-independente.py # INDEPENDENTE OK
The deploy is yours, with your own credentials. The agent itself writes the deploy README as part of the goal: bringing up docker compose, an HTTPS proxy, the Evolution webhook (event MESSAGES_UPSERT), the Telegram webhook with secret_token and a daily backup in cron. After the deploy, configure a real restaurant and use the system for a few weeks.
cp .env.exemplo .env && chmod 600 .env # fill in EVOLUTION_*, TELEGRAM_*, WEBHOOK_SEGREDO docker compose up -d --build
Everything the agent needs to build, and everything that stops it from pretending it built.
Black-box, over HTTP and the command line, in 10 files.
test_reservas.py 15 test_integracoes.py 17 test_conversa.py 12 test_confirmacao_espera.py 10 test_horarios.py 9 test_cadastros.py 9 test_basico.py 7 test_grupo_canal.py 7 test_docker.py 4 test_lgpd_raiox.py 3
docs/ESPECIFICACAO.md: execution, restaurante.json, schedule and allocation rules, HTTP API, conversation, waitlist, confirmation, large parties and own customer base, export to Raio-X, LGPD, what stays out of v1, pages, records, blocks, database, Evolution, Telegram and Docker. Deposits by Pix, delivery and multiple restaurants are explicitly out.
Frozen hash of tests/, pytest.ini and the specification. File scope: the agent only touches the code and its own logs. No external dependency, no API key, no external URL and no 0.0.0.0 in the code. verificar-limites.sh checks all of it and prints LIMITES OK.
Level 4, hidden from the agent: it looks for fixture values in the code, brings up a never-seen restaurant with every argument explicit, and does a docker build and a container healthcheck. Only then does "93 passed" prove general logic.
Language, channels, allocation, duration by party size, a pending large party holding its tables, kitchen limit, no-show without charges, waitlist, consent rules and what goes to Raio-X. Only the items marked ⚠ change the contract.
A validator that never saw the planning checked tests against the specification, redid the arithmetic and tried to defeat the guardrails. It found and fixed 13 problems, 3 of which would have stalled the run. The full account is in docs/VALIDACAO.md.
The plan is ready and validated. The implementation does not exist yet: it is born when you run the /goal, using the execucao-longa method. Atende Clínica followed the same path and closed 93 out of 93.
93 passed and LIMITES OK, then the independent verification.