Especificação, 93 testes de aceitação, travas e prompts para um agente construir, no seu ambiente, o sistema de reserva de um restaurante: chat e WhatsApp, equipe no Telegram, lista de espera e base própria de clientes. O sistema ainda não está implementado: este repositório é o plano, e você roda a implementação.
Aqui não há aplicativo pronto. Há o contrato do que o aplicativo deve fazer, a bateria de testes que prova isso e as travas que impedem o agente de trapacear. Quem constrói é o Claude Code ou o Codex, rodando na sua máquina, pela sua assinatura. O irmão Atende Clínica foi feito exatamente assim e fechou 93 de 93 testes.
Salões e mesas com capacidade, turnos por dia da semana, alocação da menor mesa que serve, confirmação "1 confirma / 2 cancela", no-show, lista de espera e grupo grande com aprovação da equipe. Python 3 só com biblioteca padrão e SQLite, para um restaurante por instalação.
Especificação de 20 seções, 93 testes caixa-preta, decisões já propostas, mapa para o Raio-X, prompts para /goal e para o loop headless, e as travas que congelam o contrato. Um validador adversarial já passou por tudo e corrigiu 13 problemas.
O contato do cliente fica com o restaurante, e não com o marketplace: a origem não aceita iFood nem Rappi, e campanha só vai a quem consentiu (LGPD). O sistema devolve clientes_novos_mes e retorno_atual_pct para o painel do Raio-X de Margem.
Este é o fluxo do sistema planejado, o que o agente vai construir. Servidor Python sem dependências, SQLite numa pasta de dados e Docker para a VPS. Evolution e Telegram entram só por variáveis de ambiente; sem elas, a caixa de saída é simulada e nenhuma chamada de rede sai.
Pelo chat ou pelo WhatsApp reserva em quatro respostas, consulta e cancela a própria reserva, tira dúvidas do FAQ, pede atendente e manda "PARAR" quando não quer mais mensagens.
Avisos de reserva nova, cancelada e grupo grande. Comandos /reservas, /fila, /responder, /encerrar, /aprovar e /recusar, também em resposta direta à mensagem do cliente.
Com token: reservas do dia por turno e salão, mapa de ocupação por horário, chegada e no-show, aprovar ou recusar grupo grande, cadastros de mesas, turnos e FAQ, bloqueios e fila humana.
Para rodar o plano basta Python para os testes e um agente logado pela assinatura. Docker só entra na verificação final e no deploy; Evolution e Telegram são opcionais e seus.
Os testes usam pytest (ferramenta de desenvolvimento). A aplicação em si não terá dependências.
# conferir python3 --version python3 -m pip install pytest
Pela assinatura, sem API paga. Para o loop headless, clone o execucao-longa em ~/projetos.
# conferir codex --version # ou: claude --version
Docker faz o build final e o deploy na VPS. Uma instância Evolution e um bot do Telegram só se quiser os canais; as credenciais ficam no .env.
# conferir docker --version
Os comandos abaixo são os do repositório. O ciclo: responder as decisões, congelar o contrato, rodar o agente até 93 passed e LIMITES OK, e conferir com a verificação independente.
Ainda não há ./reserva: o repositório só tem o plano. Confira que a suíte é coletada sem erro e que nada passa ainda (faltando a implementação, os testes falham ou dão erro, e isso é o esperado).
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
Leia docs/DECISOES-ABERTAS.md: são 20 propostas padrão já aplicadas na especificação e nos testes. Responder "ok em tudo" destrava a execução. Se mudar algo marcado com ⚠, edite docs/ESPECIFICACAO.md e os testes antes de congelar. Para um piloto real, troque também exemplos/restaurante.json pelos seus salões, mesas e turnos.
less docs/DECISOES-ABERTAS.md
Com tudo commitado, o script grava o hash de tests/, pytest.ini, da especificação e do verificador, mais o commit-base em hash-congelado.txt. Daí em diante, qualquer mudança nos testes é detectada.
git add -A && git commit -m "contrato v1" bash longrun/2026-10-05-reservas-v1/congelar.sh
a) Loop headless com o Codex (recomendado). O loop.env define 20 ciclos de 30 min, 8 GB por ciclo, parada após 3 ciclos sem avanço, modelo gpt-6-astra e CODEX_ARGS="-c sandbox_workspace_write.network_access=true": sem isso o sandbox do Codex bloqueia o servidor local dos testes.
~/projetos/execucao-longa/tools/loop-longrun.sh longrun/2026-10-05-reservas-v1
b) /goal no Claude Code. Abra uma sessão nova do Claude Code na pasta do projeto e siga longrun/2026-10-05-reservas-v1/prompt-goal-claude.md: cole a condição de /goal (a saída precisa mostrar 93 passed e LIMITES OK) e, como primeira mensagem, o bloco de prompt-goal-codex.md a partir de RESULTADO:.
claude # sessão nova, dentro de reserva-restaurante
c) Codex TUI aberto. Cole o conteúdo de longrun/2026-10-05-reservas-v1/prompt-goal-codex.md.
codex -c sandbox_workspace_write.network_access=true
No loop, o loop.log mostra cada ciclo e progress.md traz uma linha por checkpoint. O código de saída do loop diz o que houve: 0 concluído (o teste final passou), 1 teto de ciclos atingido, 2 parado por 3 ciclos sem avanço, 3 outro loop já roda na pasta. Teste em conflito com a especificação vai para failures.md: é portão humano, e o agente não deve ajustar teste nem especificação.
tail -f longrun/2026-10-05-reservas-v1/loop.log cat longrun/2026-10-05-reservas-v1/state.md
Quando o agente disser "concluído", rode os três comandos. O último o agente nunca viu: ele procura valores da fixture copiados no código, sobe um restaurante que nunca apareceu (passo de 15 min, um turno, combinação de 3 mesas, sem limite de cozinha) e faz docker build com healthcheck. Depois, abra / e /equipe no navegador.
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
O deploy é seu, com as suas credenciais. O próprio agente escreve o README de deploy como parte do goal: subir o docker compose, proxy HTTPS, webhook da Evolution (evento MESSAGES_UPSERT), webhook do Telegram com secret_token e backup diário no cron. Depois do deploy, configure um restaurante real e use o sistema por algumas semanas.
cp .env.exemplo .env && chmod 600 .env # preencha EVOLUTION_*, TELEGRAM_*, WEBHOOK_SEGREDO docker compose up -d --build
Tudo o que o agente precisa para construir, e tudo o que impede que ele finja ter construído.
Caixa-preta, por HTTP e por linha de comando, em 10 arquivos.
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: execução, restaurante.json, regras de horário e alocação, API HTTP, conversa, lista de espera, confirmação, grupo grande e base própria, exportação para o Raio-X, LGPD, o que fica fora da v1, páginas, cadastros, bloqueios, banco, Evolution, Telegram e Docker. O que é sinal por Pix, delivery e vários restaurantes está explicitamente fora.
Hash congelado de tests/, pytest.ini e da especificação. Escopo de arquivos: o agente só mexe no código e nos próprios registros. Sem dependência externa, sem chave de API, sem URL externa e sem 0.0.0.0 no código. O verificar-limites.sh confere tudo isso e imprime LIMITES OK.
Nível 4, escondido do agente: procura valores da fixture no código, sobe um restaurante nunca visto, com todos os argumentos explícitos, e faz docker build e healthcheck do container. Só assim "93 passed" prova uma lógica geral.
Linguagem, canais, alocação, duração por tamanho do grupo, grupo grande pendente ocupando mesa, limite da cozinha, no-show sem cobrança, lista de espera, regras de consentimento e o que vai ao Raio-X. Só os itens marcados com ⚠ mudam o contrato.
Um validador que não viu o planejamento conferiu teste contra especificação, refez as contas e tentou burlar as travas. Achou e corrigiu 13 problemas, 3 deles travariam a execução. O relato completo está em docs/VALIDACAO.md.
O plano está pronto e validado. A implementação ainda não existe: ela nasce quando você roda o /goal, pelo método execucao-longa. O Atende Clínica seguiu o mesmo caminho e fechou 93 de 93.
93 passed e LIMITES OK, depois a verificação independente.