Especificación, 93 pruebas de aceptación, salvaguardas y prompts para que un agente construya, en tu propio entorno, el sistema de reservas de un restaurante: chat web y WhatsApp, equipo en Telegram, lista de espera y base propia de clientes. El sistema todavía no está implementado: este repositorio es el plan, y tú ejecutas la implementación.
Aquí no hay una aplicación lista. Hay el contrato de lo que la aplicación debe hacer, la batería de pruebas que lo demuestra y las salvaguardas que impiden que el agente haga trampa. Quien construye es Claude Code o Codex, ejecutándose en tu máquina, con tu suscripción. El proyecto hermano Atende Clínica se hizo exactamente así y cerró 93 de 93 pruebas.
Salones y mesas con capacidad, turnos por día de la semana, asignación de la mesa más pequeña que sirve, confirmación "1 confirma / 2 cancela", no-show, lista de espera y grupos grandes con aprobación del equipo. Python 3 solo con biblioteca estándar y SQLite, un restaurante por instalación.
Especificación de 20 secciones, 93 pruebas de caja negra, decisiones ya propuestas, mapa hacia Raio-X, prompts para /goal y para el bucle headless, y las salvaguardas que congelan el contrato. Un validador adversarial revisó todo y corrigió 13 problemas.
El contacto del cliente se queda con el restaurante, no con el marketplace: el origen no acepta iFood ni Rappi, y las campañas solo llegan a quien dio su consentimiento (LGPD, la ley de privacidad de Brasil). Estas reglas son de Brasil: los términos de marketplaces como iFood y la LGPD vienen incorporados. El sistema devuelve clientes_novos_mes y retorno_atual_pct al panel del Raio-X de Margem.
Este es el flujo del sistema planificado, lo que el agente va a construir. Servidor Python sin dependencias, SQLite en una carpeta de datos y Docker para el VPS. Evolution y Telegram entran solo por variables de entorno; sin ellas, la bandeja de salida es simulada y ninguna llamada de red sale del proceso.
Por el chat o por WhatsApp reserva en cuatro respuestas, consulta y cancela su propia reserva, resuelve dudas con las preguntas frecuentes, pide un humano y envía "PARAR" cuando no quiere más mensajes.
Avisos de reserva nueva, cancelada y grupo grande. Comandos /reservas, /fila, /responder, /encerrar, /aprovar y /recusar, también como respuesta directa al mensaje del cliente.
Con token: reservas del día por turno y salón, mapa de ocupación por horario, llegada y no-show, aprobar o rechazar grupos grandes, registros de mesas, turnos y preguntas frecuentes, bloqueos y cola humana.
Para ejecutar el plan basta Python para las pruebas y un agente con sesión iniciada por suscripción. Docker solo entra en la verificación final y en el despliegue; Evolution y Telegram son opcionales y tuyos.
Las pruebas usan pytest (herramienta de desarrollo). La aplicación en sí no tendrá dependencias.
# comprobar python3 --version python3 -m pip install pytest
Por suscripción, sin API de pago. Para el bucle headless, clona execucao-longa en ~/projetos.
# comprobar codex --version # o: claude --version
Docker hace el build final y el despliegue en el VPS. Una instancia de Evolution y un bot de Telegram solo si quieres los canales; las credenciales quedan en el .env.
# comprobar docker --version
Los comandos de abajo son los del repositorio. El ciclo: responder las decisiones abiertas, congelar el contrato, ejecutar el agente hasta 93 passed y LIMITES OK, y comprobar con la verificación independiente.
Todavía no existe ./reserva: el repositorio solo tiene el plan. Comprueba que la suite se recoge sin errores y que aún nada pasa (sin la implementación las pruebas fallan o dan error, y eso es lo 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
Lee docs/DECISOES-ABERTAS.md (escrito en portugués): son 20 propuestas por defecto ya aplicadas en la especificación y en las pruebas. Responder "ok a todo" desbloquea la ejecución. Si cambias algo marcado con ⚠, edita docs/ESPECIFICACAO.md y las pruebas antes de congelar. Para un piloto real, cambia también exemplos/restaurante.json por tus salones, mesas y turnos.
less docs/DECISOES-ABERTAS.md
Con todo confirmado en git, el script graba el hash de tests/, pytest.ini, de la especificación y del verificador, más el commit base en hash-congelado.txt. Desde ahí, cualquier cambio en las pruebas se detecta.
git add -A && git commit -m "contrato v1" bash longrun/2026-10-05-reservas-v1/congelar.sh
a) Bucle headless con Codex (recomendado). El loop.env define 20 ciclos de 30 min, 8 GB por ciclo, parada tras 3 ciclos sin avance, modelo gpt-6-astra y CODEX_ARGS="-c sandbox_workspace_write.network_access=true": sin esto el sandbox de Codex bloquea el servidor local de las pruebas.
~/projetos/execucao-longa/tools/loop-longrun.sh longrun/2026-10-05-reservas-v1
b) /goal en Claude Code. Abre una sesión nueva de Claude Code en la carpeta del proyecto y sigue longrun/2026-10-05-reservas-v1/prompt-goal-claude.md: pega la condición de /goal (la salida debe mostrar 93 passed y LIMITES OK) y, como primer mensaje, el bloque de prompt-goal-codex.md a partir de RESULTADO:.
claude # sesión nueva, dentro de reserva-restaurante
c) Codex TUI abierto. Pega el contenido de longrun/2026-10-05-reservas-v1/prompt-goal-codex.md.
codex -c sandbox_workspace_write.network_access=true
En el bucle, loop.log muestra cada ciclo y progress.md trae una línea por checkpoint. El código de salida del bucle dice qué pasó: 0 concluido (la prueba final pasó), 1 tope de ciclos alcanzado, 2 detenido por 3 ciclos sin avance, 3 ya hay otro bucle corriendo en la carpeta. Una prueba en conflicto con la especificación va a failures.md: es una compuerta humana, y el agente no debe ajustar la prueba ni la especificación.
tail -f longrun/2026-10-05-reservas-v1/loop.log cat longrun/2026-10-05-reservas-v1/state.md
Cuando el agente diga "concluido", ejecuta los tres comandos. El último el agente nunca lo vio: busca valores de la fixture copiados en el código, levanta un restaurante que nunca apareció (paso de 15 min, un solo turno, combinación de 3 mesas, sin límite de cocina) y hace un docker build con healthcheck. Después abre / y /equipe en el 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
El despliegue es tuyo, con tus propias credenciales. El propio agente escribe el README de despliegue como parte del goal: levantar el docker compose, proxy HTTPS, webhook de Evolution (evento MESSAGES_UPSERT), webhook de Telegram con secret_token y respaldo diario en cron. Tras el despliegue, configura un restaurante real y usa el sistema unas semanas.
cp .env.exemplo .env && chmod 600 .env # completa EVOLUTION_*, TELEGRAM_*, WEBHOOK_SEGREDO docker compose up -d --build
Todo lo que el agente necesita para construir, y todo lo que le impide fingir que construyó.
Caja negra, por HTTP y por línea de comandos, en 10 archivos.
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: ejecución, restaurante.json, reglas de horario y asignación, API HTTP, conversación, lista de espera, confirmación, grupos grandes y base propia, exportación a Raio-X, LGPD, lo que queda fuera de la v1, páginas, registros, bloqueos, base de datos, Evolution, Telegram y Docker. Señal por Pix, delivery y varios restaurantes están explícitamente fuera.
Hash congelado de tests/, pytest.ini y de la especificación. Alcance de archivos: el agente solo toca el código y sus propios registros. Sin dependencia externa, sin clave de API, sin URL externa y sin 0.0.0.0 en el código. verificar-limites.sh comprueba todo y imprime LIMITES OK.
Nivel 4, oculto al agente: busca valores de la fixture en el código, levanta un restaurante nunca visto con todos los argumentos explícitos y hace docker build y healthcheck del contenedor. Solo así "93 passed" prueba una lógica general.
Lenguaje, canales, asignación, duración según el tamaño del grupo, grupo grande pendiente que ocupa mesa, límite de cocina, no-show sin cobro, lista de espera, reglas de consentimiento y lo que va a Raio-X. Solo los ítems marcados con ⚠ cambian el contrato.
Un validador que no vio la planificación comparó pruebas con la especificación, rehizo las cuentas e intentó burlar las salvaguardas. Encontró y corrigió 13 problemas, 3 de ellos bloquearían la ejecución. El relato completo está en docs/VALIDACAO.md.
El plan está listo y validado. La implementación todavía no existe: nace cuando ejecutas el /goal, con el método execucao-longa. Atende Clínica siguió el mismo camino y cerró 93 de 93.
93 passed y LIMITES OK, y luego la verificación independiente.