Entiende por qué el agente cree que terminó
Una tarea larga puede ser migrar hojas de cálculo, crear un sitio o revisar cien archivos. A mitad del camino, el agente pierde detalles y empieza a creer que ya terminó. Escribe "todo listo" con total convicción.
La receta R6 cambia las reglas del juego: el agente solo termina cuando los criterios prueban que terminó, y no cuando él cree. Quien da el veredicto es un script, el runtime/scripts/verificar.mjs.
🆕 ¿Eres nuevo aquí? Cuatro palabras de este módulo
- Goal — un archivo de texto con el resultado que quieres y la lista de criterios para darlo por terminado.
- Criterio — una línea que dice «ejecuta este comando; la respuesta debe mostrar este texto». Respuesta sí o no.
- Salida 0 / salida 1 — todo comando termina con un número. 0 quiere decir "salió bien"; cualquier otro, "salió mal". Los scripts y agentes leen ese número.
- Puerta humana — un punto del goal en el que el agente se detiene y espera tu aprobación.
Cómo leer el diagrama: arriba, el camino de la suposición: la tarea termina cuando el agente se convence. Abajo, el camino de la R6: entre el trabajo y el final está la caja morada, y la flecha discontinua devuelve al agente al trabajo cada vez que falla.
✗ Listo por suposición
- ✗ "Revisé todo y está excelente"
- ✗ Nadie puede revisarlo después
- ✗ Depende del humor del modelo en ese momento
- ✗ Descubres el error solo al usarlo
✓ Listo con pruebas
- ✓
4/4 critérios OKy salida 0 - ✓ Lo vuelves a ejecutar mañana y da el mismo resultado
- ✓ Se aplica a Claude Code y a Codex
- ✓ El error aparece con nombre y línea
resultado + criterios
comando → salida
el juez de lo que está listo
solo con tu aprobación
Escribe criterios comando → resultado
Cada criterio es una línea de lista con dos fragmentos entre comillas invertidas: el comando y el texto que debe aparecer en la salida, separados por una flecha.
El kit incluye un goal listo, sobre el puente de la agenda de Clara y el resumen de ventas de Sônia. Este es el archivo completo, tal como está en el kit:
# Goal de exemplo — ponte da agenda ## Resultado A ponte MCP lê a agenda e o resumo de vendas, e o kit continua saudável. ## Critérios de pronto - [ ] `node runtime/pontes/mcp-modelo/server.mjs --selftest` → `tools: 2` - [ ] `node runtime/pontes/mcp-modelo/server.mjs --selftest` → `2026-10-06 09:00 · Dra. Ana` - [ ] `node runtime/pontes/mcp-modelo/server.mjs --selftest` → `TOTAL: R$ 856.00` - [ ] `node runtime/scripts/doctor.mjs` → `PRONTO` Rode da raiz do kit: `node runtime/scripts/verificar.mjs runtime/exemplos/goal-exemplo.md`
✓ Buen criterio
- ✓ Se puede verificar con un comando
- ✓ La respuesta es sí o no
- ✓ Es imposible avanzar sin hacer el trabajo
- ✓ Ej.: el total de Sônia,
TOTAL: R$ 856.00, verificado manualmente
✗ No es un criterio
- ✗ "Dejarlo bien"
- ✗ "Revisar con cuidado"
- ✗ Un texto que aparece incluso si el trabajo no está hecho
- ✗ Algo que solo tú sabes responder al verlo
💡 Cómo decide el script
Desde el código del verificar.mjs, un criterio solo se cumple si ocurren ambas cosas: el comando termina con salida 0 e la salida contiene el texto esperado. Un texto correcto con un comando roto no pasa.
línea de lista
entre acentos graves
la flecha separa
texto de la salida
Ejecuta el verificar en el goal de ejemplo
Antes de entregarle el goal a un agente, ejecuta el verificador por tu cuenta. No llama a ningún modelo: solo ejecuta los comandos de los criterios. Puedes ejecutarlo cuantas veces quieras.
Ejecútalo siempre desde la raíz del kit, porque los comandos del goal usan rutas que empiezan en runtime/.
En la terminal, en la raíz de la carpeta del kit:
node runtime/scripts/verificar.mjs runtime/exemplos/goal-exemplo.md
Salida real (05/10/2026, Linux), salida 0:
OK node runtime/pontes/mcp-modelo/server.mjs --selftest OK node runtime/pontes/mcp-modelo/server.mjs --selftest OK node runtime/pontes/mcp-modelo/server.mjs --selftest OK node runtime/scripts/doctor.mjs 4/4 critérios OK
4/4 critérios OK. Si aparece FALHA en doctor, vuelve al módulo 1.2; si es en selftest, al módulo 2.2.| Línea de salida | Criterio verificado | De quién |
|---|---|---|
| 1.ª OK | tools: 2: el puente tiene las dos herramientas | ponte-modelo |
| 2.ª OK | 2026-10-06 09:00 · Dra. Ana: horario disponible leído | agenda de Clara |
| 3.ª OK | TOTAL: R$ 856.00: suma de las ventas | ERP de Sônia |
| 4.ª OK | PRONTO: el kit sigue funcionando bien | doctor |
Qué revisar en la tabla: las tres primeras líneas de la salida muestran el mismo comando. Lo que diferencia a cada una es el texto esperado de cada criterio, que OK no repite.
💡 El total de Sônia se verificó a mano
10×18,50 + 25×5,20 + 40×5,20 + 6×18,50 + 12×18,50 = 185 + 130 + 208 + 111 + 222 = 856. Un criterio solo es válido si el valor esperado es correcto. Verifica el número una vez, con calma, antes de confiar en él para siempre.
dónde ejecutar
no llama al modelo
la última línea
todo pasó
Incumple un criterio a propósito
Un juez que siempre dice "OK" no sirve para nada. Antes de confiar en verificar, mira cómo rechaza algo. Trabaja en una copia, para que el goal de ejemplo siga intacto.
Es la misma prueba que hizo el kit en la evaluación de la versión 0.2.0.
Crea la copia
Crea meu-goal.md en la raíz del kit con el mismo contenido que el goal-exemplo.md, con tu editor de texto o pidiéndoselo al agente.
Cambia un valor esperado
En la copia, cambia el texto entre comillas invertidas después de una flecha. Por ejemplo, el total de Sônia de R$ 856.00 para otro valor.
Ejecuta el verificar en la copia
Usa el comando del cuadro de abajo, el mismo que el prompt de R6 indica que el agente ejecute.
Deshacer el cambio
Devuelve el valor correcto a la copia. Se convierte en el punto de partida de tu propio goal.
En la terminal, en la raíz del kit, después de cambiar un valor esperado en meu-goal.md:
node runtime/scripts/verificar.mjs meu-goal.md
Resultado comprobado en CHANGELOG 0.2.0:
con un valor esperado incorrecto: FALLA, salida 1
FALHA en lugar de OK. Según el código del script, justo debajo de ella viene el texto esperado: y las últimas líneas de la salida real, para que puedas compararlas.Cómo leer el diagrama: el diseño se repite para cada línea del goal. La caja morada contiene toda la regla del script. Basta con que una línea caiga a la derecha, abajo, para que el número de salida sea 1, y ese es el número que el agente lee para saber si puede detenerse.
meu-goal.md
cambiado a propósito
con lo esperado y el resultado
el agente no se detiene
Ejecuta el agente hasta que pase
Con el goal escrito y el verificar probado, entrégale la tarea al agente. La solicitud de R6 indica tres cosas: cumple el goal, ejecuta el verificar después de cada etapa y detente solo cuando todo esté OK o ante un control humano.
Funciona en Claude Code y en Codex, porque el juez es el mismo script para ambos.
🆕 ¿Eres nuevo aquí? Qué es /goal
Las palabras que comienzan con una barra y se escriben dentro de la sesión son comandos del agente. O /goal le da al agente un objetivo que perseguir hasta el final, en varias etapas, en lugar de una sola respuesta.
Abre claude (o codex) en la carpeta del kit y pega:
/goal Cumple el goal en meu-goal.md. Después de cada etapa, ejecuta node runtime/scripts/verificar.mjs meu-goal.md. Detente solo cuando todo esté OK o en un punto de aprobación humana del goal.
meu-goal.md. La última línea debe mostrar todos los criterios en OK. Si no los muestra, no terminaste.El agente realiza una etapa
Crea, corrige o ajusta lo que pide el goal.
Ejecuta el verificar
Lee las líneas OK y FALHA y el número de salida.
Salida 1: volver al paso 1
La línea FALHA indica qué faltó, con el resultado esperado y el resultado real.
Salida 0 o bloqueo: detenerse
Terminó de verdad o llegó a un punto en el que solo tú decides.
💡 Sin pantalla, durante horas
En Linux, para ejecutar sin pantalla, con límites de tiempo y memoria, el kit indica el método completo de ejecución prolongada: github.com/inematds/execucao-longa. Empieza con la solicitud de arriba, mientras tú observas.
objetivo hasta el final
haz, verifica, corrige
el mismo juez
la última ronda
Coloca controles humanos y anota los fallos
Un agente que funciona durante horas no puede decidir por sí solo qué es irreversible. La R6 exige puertas de aprobación humana escritas en el propio goal, para cuatro tipos de acción: gasto, envío, borrar y publicar.
Y pide un hábito: cuando algo se rompa, una línea en FALHAS.md; cuando el entorno lo impida, una línea en el LIMITES.md.
| Puerta en el goal | Límite en POLITICA | Ejemplo |
|---|---|---|
| Gasto | N1: prepara, tú ejecutas | contratar un servicio nuevo |
| Envío | N2: pide cada vez | Que Clara envíe la confirmación al paciente |
| Borrar | N1 + copia de seguridad | limpiar exportaciones antiguas del ERP |
| Publicar | N2 (es un envío: push, post) | Que Sônia publique el informe para el cliente |
Qué revisar en la tabla: ninguna puerta pasa de N2. En un goal largo, escribe la frase de la puerta en el lugar exacto de la etapa, por ejemplo "antes de enviar, detente y pregúntame".
| data | o que quebrou | menor correção | prompt \| infra | |---|---|---|---| | 2026-10-05 | `doctor.mjs` dizia "codex sem login" com o Codex logado | ler stdout **e** stderr (`codex login status` responde no stderr) | infra |
⚠️ Una puerta que no está escrita no existe
Si el goal no dice "detente antes de enviar", un agente que busca el OK puede tratar el envío como un paso más. Antes de poner en marcha un goal largo, revísalo buscando gastos, envíos, borrados y publicaciones. Cada uno necesita su propia frase de detención.
Prueba rápida (opcional): ¿cuál de estas líneas es un criterio que el verificar.mjs ¿aceptas?
N1
N2
N1 + copia de seguridad
una línea cada uno
🎓 Resumen del módulo
Próxima ruta:
Ruta 4 — Gobernar y aprender (empieza en el 4.1, Política de autonomía)