Kit de plano · reserva de pousada e hotel · código aberto

O plano completo para o quarto nunca ficar vazio

Especificação, 98 testes de aceitação, travas e prompts para um agente construir, no seu ambiente, o sistema de reservas de uma pousada ou hotel pequeno: disponibilidade por noite sem overbooking, tarifas por temporada, reserva direta no chat e no WhatsApp, calendário iCal para a Booking e o Airbnb e a equipe no Telegram. O sistema ainda não está implementado: este repositório é o plano, e você roda a implementação.

Banner do Reserva Hotel: disponibilidade por noite, reserva direta, iCal para Booking e Airbnb e equipe no Telegram
O que é

Um kit para pedir ao agente: do contrato aos 98 testes verdes

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.

Disponibilidade por noite, tarifas por temporada, reserva direta, iCal para Booking e Airbnb, ciclo da estadia, equipe no Telegram, LGPD e Raio-X

🏨 O sistema que sai do plano

Tipos de quarto e quartos numerados, disponibilidade por noite (check-in inclusivo, check-out exclusivo) sem overbooking, estadia mínima, fechamentos e bloqueios. Tarifas por temporada com pacote de baixa (por exemplo, 3 noites pagam 2) e desconto de reserva direta. Python 3 só com biblioteca padrão e SQLite, para uma pousada por instalação.

📦 O kit

Especificação de 20 seções, 98 testes caixa-preta, 17 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, 3 deles travariam a execução.

📈 As regras do Raio-X de Margem

O hóspede que reserva direto não paga comissão de OTA, e a baixa temporada ganha preço e pacote próprios. O sistema devolve receita_ota, retorno_atual_pct, ocupacao_baixa_pct e outros números para o painel do Raio-X de Margem, que é a fonte das regras de negócio.

Como funciona

Do "tem quarto para o feriado?" à estadia concluída

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.

Chat do site ou WhatsApp (Evolution)→ Datas e hóspedes→ Cotação por temporada, com desconto direto→ Reserva sem overbooking→ Lembrete, pré-check-in, check-in e check-out→ Pós-estadia e números do mês para o Raio-X

Hóspede

Pelo chat ou pelo WhatsApp consulta disponibilidade e preço, reserva, vê e cancela a própria reserva conforme a política (grátis até 7 dias antes, no exemplo), tira dúvidas do FAQ, pede atendente e manda "PARAR" quando não quer mais mensagens.

Equipe no Telegram

Avisos de reserva nova e cancelada, e os comandos /chegadas, /ocupacao, /fila, /responder e /encerrar, também em resposta direta à mensagem do hóspede.

Página /equipe

Com token: chegadas e saídas do dia, mapa de ocupação do mês, check-in, check-out e no-show, sinal pago, cadastros de tipos, quartos, temporadas e FAQ, bloqueios e fila humana.

Tarifas e temporadas

Tarifa base por tipo, temporadas (alta, baixa, feriado) com preço por noite, pessoa extra, pacote de baixa e desconto de canal próprio (direta ou balcão), nunca para a OTA. Sinal como política escrita, marcado como pago pela equipe. Centavos com arredondamento meio para cima.

iCal com a Booking e o Airbnb

Exportação por tipo e por quarto, para bloquear as datas nas OTAs. Importação do .ics baixado da OTA, enviado como arquivo: vira reserva de origem booking ou airbnb. Nenhuma URL externa é buscada na v1.

Ciclo da estadia

Lembrete com pré-check-in alguns dias antes, check-in e check-out pela equipe, no-show, pós-estadia convidando a reservar direto (só com consentimento) e lista de espera para datas cheias.

Pré-requisitos

O que você precisa

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.

Python 3.10+ e pytest

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

Claude Code ou Codex

Pela assinatura, sem API paga. Para o loop headless, clone o execucao-longa em ~/projetos.

# conferir
codex --version   # ou: claude --version

Docker, Evolution e Telegram

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
Guia de uso · passo a passo

Do clone ao sistema implementado, no seu ambiente

Os comandos abaixo são os do repositório. O ciclo: responder as decisões, congelar o contrato, rodar o agente até 98 passed e LIMITES OK, e conferir com a verificação independente.

1

Clone o repositório

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-hotel && cd reserva-hotel
python3 -m pytest -q --collect-only | tail -1   # 98 tests collected
python3 -m pytest -q | tail -1                  # 0 passed
2

Responda as decisões abertas

Leia docs/DECISOES-ABERTAS.md: são 17 propostas padrão já aplicadas na especificação e nos testes. Responder "ok em tudo" destrava a execução. Se mudar algo marcado com ⚠ (por exemplo o desconto de reserva direta, o inventário por tipo ou a política de cancelamento), edite docs/ESPECIFICACAO.md e os testes antes de congelar. Para um piloto real, troque também exemplos/pousada.json pelos seus tipos de quarto, quartos, temporadas e FAQ.

less docs/DECISOES-ABERTAS.md
3

Congele o contrato

Com tudo commitado, o script grava o hash de tests/, pytest.ini, da especificação e dos dois verificadores, mais o commit-base em hash-congelado.txt, e faz um commit. Daí em diante, qualquer mudança nos testes é detectada. Se houver alteração pendente, o script para e pede o commit antes.

git add -A && git commit -m "contrato v1"
bash longrun/2026-10-05-reservas-v1/congelar.sh
4

Rode o agente (escolha um caminho)

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 98 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-hotel

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
5

Acompanhe

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
6

Confira com a verificação independente

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 uma pousada que nunca apareceu (outros tipos, preços com centavos, baixa de inverno, pacote 4 pagam 3, desconto de 15 %, sinal de 50 %, outro relógio) e faz docker build com healthcheck. Depois, abra / e /equipe no navegador.

python3 -m pytest -q tests/                                        # 98 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
7

Rode a sua pousada e faça o deploy na VPS

Com o sistema implementado, copie o exemplo, troque TROQUE-ESTE-TOKEN e TROQUE-ESTE-SEGREDO e suba o servidor. O chat do hóspede fica em / e a página da equipe em /equipe (header X-Token).

mkdir -p dados && cp exemplos/pousada.json dados/pousada.json
./reserva serve --porta 8080 --dados dados

O deploy é seu, com as suas credenciais. O próprio agente escreve o README de deploy como parte do goal: subir o docker compose (porta só em 127.0.0.1:8080, atrás de proxy HTTPS), webhook da Evolution em /webhook/evolution/<segredo> (evento MESSAGES_UPSERT), webhook do Telegram com setWebhook e secret_token, a URL /ical/<segredo>/… cadastrada na Booking e no Airbnb, a importação do .ics delas pela página da equipe e o backup diário (./reserva backup no cron).

cp .env.exemplo .env && chmod 600 .env   # preencha EVOLUTION_*, TELEGRAM_*, WEBHOOK_SEGREDO
docker compose up -d --build
O que vem no kit

Contrato, testes e travas, com os números reais

Tudo o que o agente precisa para construir, e tudo o que impede que ele finja ter construído.

98 testes de aceitação

Caixa-preta, por HTTP e por linha de comando, em 10 arquivos.

test_inventario.py            17
test_integracoes.py           16
test_conversa.py              14
test_ciclo.py                 11
test_tarifas.py               10
test_cadastros.py              9
test_ical.py                   7
test_basico.py                 6
test_docker.py                 4
test_lgpd_raiox.py             4

Especificação de 20 seções

docs/ESPECIFICACAO.md: execução, pousada.json, noites e disponibilidade, cálculo das tarifas, autenticação, API HTTP, conversa, lista de espera, ciclo da estadia, cancelamento, iCal, exportação para o Raio-X, LGPD, o que fica fora da v1, páginas, cadastros, banco, Evolution, Telegram e Docker. Pagamento (Pix e cartão), sincronização iCal por URL, venda de extras, preço dinâmico e várias pousadas estão explicitamente fora.

Travas contra atalho

Hash congelado de tests/, pytest.ini, da especificação e dos dois verificadores. 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.

Verificação independente

Nível 4, escondido do agente: procura valores da fixture no código, sobe uma pousada nunca vista, com todos os argumentos explícitos, e faz docker build e healthcheck do container. Só assim "98 passed" prova uma lógica geral.

17 decisões já propostas

Linguagem, canais, desconto de reserva direta e paridade com a Booking, inventário por tipo, OTAs só por iCal, sinal e cancelamento, tarifas, ciclo da estadia, o que vai ao Raio-X, uma pousada por instalação e só PT na v1. Só os itens marcados com ⚠ mudam o contrato.

Validado por um agente adversarial

Um validador que não viu o planejamento conferiu teste contra especificação, refez 70 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.

As regras de negócio vêm do Raio-X

Reserva direta contra comissão de OTA, baixa temporada com pacote e hóspede que volta: docs/MAPA-RAIO-X.md liga cada vazamento do pacote hotel a uma peça da v1 ou ao motivo de ficar fora. Detalhes no guia do Raio-X de Margem.

Regras brasileiras embutidas

A LGPD (lembrete como execução do contrato, pós-estadia só com consentimento, exportar e anonimizar) e o cuidado com a paridade de preços do contrato da Booking no Brasil: nenhuma página pública publica preço, e o desconto direto só aparece na conversa 1:1. O dono da pousada valida esse ponto.

Roadmap

Onde está e para onde vai

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.

Plano ✅
Especificação, testes e travas validadosContrato de 20 seções, 98 testes de aceitação, decisões propostas, mapa para o Raio-X e validação adversarial concluída em 05/10/2026.
Implementação
Você roda o /goalResponder as decisões, congelar o contrato e deixar o agente trabalhar até 98 passed e LIMITES OK, depois a verificação independente. Hoje o sistema não está implementado.
Piloto
Numa pousada realConfigurar tipos, quartos, temporadas e FAQ verdadeiros, publicar na VPS, cadastrar o iCal na Booking e no Airbnb e acompanhar reserva direta, ocupação na baixa e retorno no Painel de Recuperação do Raio-X.
Depois
Fora da v1Pagamento, sincronização iCal por URL, venda de extras, preço dinâmico, várias pousadas e interface em EN/ES ficam para uma próxima versão, com portão humano.