12. Ralph loop — el camino del PRD al release, recorrido sin el operador

La Parte 10 — PRD dijo qué construir. La Parte 11 — Release gates dijo cuándo está construido.

Este artículo trata sobre qué llena el hueco entre esos dos — sin el operador en el teclado.

Ralph. El bucle autónomo que toma un PRD con gates y recorre el camino por sí solo, un commit verificado a la vez. Trabaja en segundo plano. Hace push cuando puede. Pone en cola decisiones cuando no puede. El operador se despierta, ejecuta un slash command, toma unas pocas decisiones y vuelve a lo que estuviera haciendo. El sistema hizo el trabajo.

Este es el tercer artículo de la extensión de flujo de trabajo de la serie, y aquel donde todo lo anterior se compone. La persona estrecha el espacio de decisión. La memoria guarda el porqué. Los skills comprimen los verbos. Los hooks disparan lo que se olvidaría. El Multi-Agent reparte la carga. La verificación fija "listo." La economía de tokens protege la señal. Los PRDs sostienen la intención. Los release gates aplican la llegada. Ralph ejecuta toda la disposición, en un reloj.

0. La premisa — la autonomía no es "confiar más en el agente"

Una mala versión de autonomía es "dejar que el agente haga lo que quiera y rezar." Eso colapsa por la misma razón por la que el flujo de trabajo sin PRD de la Parte 10 colapsa — la mente del operador no tiene un lugar duradero donde vivir, y el agente termina improvisando.

Una versión funcional de autonomía es la opuesta. El operador escribe el PRD. El operador escribe los gates. La discreción del agente está nítidamente acotada — puede hacer cualquier cosa que no cambie qué es el sistema, y no puede hacer nada que sí lo cambie. Dentro de ese límite, el agente funciona sin supervisión. Fuera de él, el agente para y espera.

La autonomía funciona cuando la mente está fijada en código y la mano de obra es lo que se delega.

Ralph es el arnés que hace operacionalmente real esta distinción.

1. Qué es realmente ralph

Ralph son dos scripts y una carpeta.

• ralph-code.sh — ejecuta una fase a la vez. Lee un PRD-N. Elige el siguiente ítem [ ]. Lo implementa. Ejecuta verify. Hace commit si verify pasa. Repite.
• ralph-orchestrator.sh — ejecuta muchas fases seguidas. Lee un Master Plan. Para cada fase, llama a ralph-code.sh. Entre fases, comprueba el gate. O pasa el gate (Auto), o para y pone en cola una decisión (Manual).
• ralph-loop/ — una carpeta por proyecto que contiene los PRDs, el master plan, el log de progreso, la lista de bloqueadores y — lo más importante — la cola DECISIONS.

El proceso hijo no es un agente de larga vida. Es una sesión fresca por iteración. Cada iteración es un ítem: implementar, verificar, commit. La siguiente iteración empieza desde cero, leyendo el PRD de nuevo para encontrar el siguiente [ ]. La deriva no puede acumularse entre iteraciones porque no hay contexto compartido en el que derivar.

El padre — el orchestrator — no implementa nada. Su único trabajo es aplicar gates. Tras cada fase, pregunta "¿pasó el gate?" Si sí, avanzar. Si no, parar y escribir a la cola.

2. El Master Plan — PRD y gates fundidos

Un Master Plan es el documento que Ralph lee. Tiene forma de PRD con los gates incorporados por fase:

Approved-By: lead, 2026-05-18

Phase P1 — Privacy and compliance scrub
  PRD: ralph-loop/PRD-P1.md
  Auto-Gate: pnpm verify:privacy && pnpm build && pnpm lint
  Manual-Gate: lead approves privacy policy text
  Items: 12

Phase P2 — Asset SHA-256 enforcement
  PRD: ralph-loop/PRD-P2.md
  Auto-Gate: pnpm verify:assets && pnpm build
  Manual-Gate: —
  Items: 7

Phase P3 — i18n locale expansion (4 new locales)
  PRD: ralph-loop/PRD-P3.md
  Auto-Gate: pnpm build && pnpm verify:i18n
  Manual-Gate: lead approves machine-translated content for each locale
  Items: 24

...

Tres propiedades importan.

Approved-By: es una línea obligatoria. El orchestrator se niega a empezar sin ella. Si el líder no ha firmado el Master Plan, Ralph no se ejecuta.

Cada fase tiene su PRD pre-generado. No "el orchestrator generará PRD-P3 cuando llegue" — PRD-P3.md existe al inicio, escrito por Alice a partir del Master Plan. La pre-generación es una red de seguridad contra la deriva: un PRD-P3 en vuelo no tiene revisión del operador.

Auto-Gate y Manual-Gate se nombran por fase. Auto es un comando de shell. Manual es un aprobador nombrado y lo que aprueba. Ninguna fase avanza sin que pase su gate.

3. Cómo se ejecuta realmente el bucle

Un trazo simplificado de una iteración de ralph-code.sh:

1. cd al worktree
2. leer PRD-N.md
3. encontrar el primer ítem marcado [ ]
4. si no quedan ítems [ ] → salir (ALL DONE)
5. iniciar una sesión fresca de Claude Code
6. system prompt: "implementa exactamente este único ítem, luego para"
7. el hijo escribe código
8. el hijo ejecuta verify (el script nombrado en el PRD)
9. si verify pasa:
     - el hijo hace commit con un mensaje que incluye el ID del ítem
     - el padre vuelve a ejecutar verify (defensa en profundidad)
     - si el verify del padre también pasa → marcar [ ] como [x], continuar
     - si el verify del padre falla → revertir, escribir a BLOCKERS, continuar con el siguiente ítem
10. si verify falla:
     - registrar en BLOCKERS
     - reintentar una vez
     - si sigue fallando → marcar como bloqueado, continuar con el siguiente ítem
11. si BLOCKERS alcanza el umbral (por defecto 3 por fase) → abortar
12. volver al paso 2

Propiedades clave de este bucle, y por qué cada una tiene la forma que tiene.

Un ítem por iteración. El hijo no puede hacer "ya que estoy aquí, déjame también arreglar...". El system prompt lo limita explícitamente a una fila del PRD. Esto es lo que detiene en seco la deriva de alcance.

Sesión fresca por iteración. Ningún contexto cargado entre ítems. El siguiente ítem lee el PRD fresco. Si el ítem anterior dejó suposiciones malas y sutiles, no se propagan.

El padre re-verifica. El verify del hijo es una comprobación. El verify del padre es el mismo script, ejecutado de nuevo fuera de la sesión del hijo, sobre el estado committeado. Si discrepan, la afirmación del hijo está equivocada y el commit se revierte. Así sobrevive el sistema a una línea alucinada "verify passed."

Tope de bloqueadores. Tras N bloqueadores en una fase, la fase aborta. El operador inspecciona qué seguía bloqueando y o arregla la causa raíz o reescribe el PRD. Ralph no sigue chocando contra el mismo muro para siempre.

4. El orchestrator — los límites entre fases son donde viven los humanos

ralph-code.sh maneja los ítems dentro de una fase. ralph-orchestrator.sh maneja la transición entre fases.

Tras la salida ALL DONE del ralph-code.sh de una fase:

1. el padre ejecuta el comando Auto-Gate de la fase
2. si Auto-Gate falla:
     - registrar en DECISIONS como "Auto-Gate failed, see verify output"
     - parar el orchestrator
3. si Auto-Gate pasa y no hay Manual-Gate:
     - marcar la fase [x] en ORCHESTRATOR-STATE.md
     - avanzar a la siguiente fase
4. si Auto-Gate pasa y HAY un Manual-Gate:
     - registrar en DECISIONS como "Manual-Gate awaits: <approver> approves <thing>"
     - parar el orchestrator
5. cada 5 fases (sin importar el estado):
     - forzar un checkpoint de DECISIONS
     - parar el orchestrator
     - el operador ejecuta /btw para confirmar la dirección

Tres paradas intencionales, cada una correspondiente a una responsabilidad exclusivamente humana distinta.

Auto-Gate falló. Es un evento técnico, pero la interpretación es humana. ¿Estaba mal el script de verify? ¿Estaba mal la spec? ¿Cambió el mundo? El operador decide. El orchestrator no reintenta para siempre.

Manual-Gate alcanzado. Este es el handoff explícito. El líder aprueba la privacy policy, o el contenido semilla, o la elección de scopes de OAuth. No hay forma de automatizar esta fila, así que el orchestrator se detiene en la puerta.

Checkpoint forzado. Cada cinco fases, aunque nada haya salido mal, el orchestrator se detiene y pide dirección. Esta es una red de seguridad contra la deriva. El modo de fallo más duro de la autonomía de larga duración es "todo funcionó pero fue en la dirección equivocada," y la única contramedida conocida es revisión humana periódica a cadencia fija.

5. La cola DECISIONS — poner en cuarentena el "necesito un humano"

Tres archivos se acumulan en ralph-loop/:

Archivo	Qué contiene	Disparador	Cómo se procesa
PROGRESS.md	Una línea por iteración, éxito o fallo	cada iter	append-only, solo auditoría
BLOCKERS.md	Fallos técnicos que el agente no pudo resolver	verify falla dos veces, etc.	cuenta hacia el umbral de aborto
DECISIONS.md	Cosas que solo un humano puede decidir	elecciones de opciones, seguridad/DB, añadir dependencias	el operador procesa con /btw

La disciplina que hace funcionar esto está en cómo un hijo clasifica una situación que no puede resolver.

el hijo encuentra una situación que no sabe manejar:
  ├── "creo que sé qué hacer, pero la spec calla" → BLOCKER
  ├── "hay dos opciones razonables y solo el líder puede elegir" → DECISION
  └── "esto requiere una nueva dependencia / revisión de seguridad / cambio de API pública" → DECISION

En duda: clasificar como DECISION, no BLOCKER. Clasificar mal una decisión como bloqueador solo desperdicia iteraciones. Clasificar mal un bloqueador como decisión despierta al operador innecesariamente, pero no corrompe el código. La asimetría es el punto.

Un ítem del PRD con estado [?] (decisión pendiente) es saltado por Ralph. El bucle sigue corriendo sobre ítems [ ]. Cuando todo lo que se puede hacer está hecho, solo quedan ítems [?] — y el bucle sale de forma natural, señalando "turno del operador."

6. /btw — el lado del operador en el bucle

En el lado del operador, la interacción entera es un slash command.

/btw

Qué hace:

1. Lee ralph-loop/DECISIONS.md en cada proyecto conocido
2. Ordena las decisiones pendientes por prioridad (seguridad/DB peso +10, peso por tiempo de espera)
3. Las presenta al operador como una pregunta agrupada con opciones
4. Para cada respuesta:
   • Mueve la decisión de "pendiente" a "resuelta" con la respuesta y un timestamp
   • En el PRD, cambia [?] de vuelta a [ ] y actualiza el contenido de la fila según la decisión
   • Hace commit con el mensaje [Decision] D-NNN R0N: <summary>
5. Pregunta al operador si reiniciar Ralph en las fases afectadas

El modelo mental del operador es — estoy respondiendo preguntas, no ejecutando trabajo. El orchestrator manejó el trabajo real. El orchestrator se topó con algo que solo yo puedo decidir. Decido. El orchestrator continúa.

Una interacción con forma real:

operador (mañana): /btw

Alice: 3 decisiones pendientes en 2 proyectos.

  Proyecto A (esperando 14 h):
    D-007  Fase P5 — ¿Usar Resend o Postmark para email transaccional?
           La spec calla. El precio favorece a Resend, la entregabilidad favorece a Postmark.
  Proyecto A (esperando 14 h):
    D-008  Fase P6 — ¿Añadir la dependencia `zod` para validación en runtime?
           La spec no anticipó un validador en runtime. Dos alternativas:
           (a) zod (~14 kB)
           (b) validadores hechos a mano

  Proyecto B (esperando 2 h):
    D-002  Fase P2 — Manual-Gate: ¿el líder aprueba el contenido traducido por máquina?
           24 archivos, 4 locales × 6 categorías. Diff de muestra adjunto.

operador: D-007: Resend. D-008: zod. D-002: aprobado.

Alice: Registradas las tres. Proyecto A Fase P5 reanudada.
       Proyecto B Fase P2 avanzó a P3. Proyecto B continúa.

Esa conversación es la interacción entera. El operador no escribió código. El operador no ejecutó un build. El operador tomó tres decisiones en menos de un minuto. Ralph hizo el resto antes de la conversación y sigue haciendo el resto después.

7. Cuándo ralph es la herramienta equivocada

Ralph no es un martillo universal. Es bueno en una forma de trabajo y malo en otra.

Buenos ajustes.

• Muchos ítems similares, cada uno verificable. (Aplicar un pase de pulido a 36 archivos MDX. Generar boilerplate para 48 variantes de lens. Refactorizar 24 sitios de llamada de una función renombrada.)
• Tests o docs generados que el script de verify puede comprobar.
• Lotes de lint o format o type-strict que mueven una gran superficie en una dirección.

Malos ajustes.

• Decisiones de arquitectura. (Todo el punto es que las decisiones van a DECISIONS, pero si cada ítem es una decisión, Ralph no hace trabajo y solo produce ruido en la cola.)
• Cambios de seguridad o esquema de DB. Ambos tocan invariantes que Ralph no puede verificar por completo, y ambos tienen modos de fallo donde "pasó" es peligrosamente erróneo.
• Cambios de API pública. El script de verify puede confirmar que el cambio local funciona pero no puede confirmar que los consumidores downstream siguen funcionando.
• Cualquier cosa con una nueva dependencia. Siempre es una decisión.

En duda, la heurística: ¿estaría cómodo con que este commit aterrizara mientras duermo? Si sí, Ralph. Si no, hacerlo en una sesión normal con el operador presente.

8. Barandillas de seguridad — qué evita que la autonomía se vuelva un incendio

Varias barandillas se componen para mantener a Ralph seguro de dejar corriendo.

Aislamiento por worktree. Ralph corre en un git worktree, nunca en main. El worktree está en una rama dedicada (ralph/master-plan o ralph/{phase}). El operador siempre puede inspeccionar y descartar la rama entera.

Línea Approved-By. El orchestrator se niega a iniciar un Master Plan sin Approved-By: lead, <date>. La firma del operador se aplica mecánicamente — no "el líder dijo que vale en el chat," sino una cadena en el archivo que el orchestrator parsea.

Verify es la única vía al commit. El hijo no puede hacer commit sin que el script de verify salga con 0. El padre vuelve a ejecutar verify sobre el estado committeado. Dos pases independientes del mismo gate.

Alcance acotado por iteración. El system prompt del hijo dice "implementa exactamente esta única fila del PRD, luego para." La deriva de alcance a nivel de iteración está bloqueada mecánicamente.

Umbrales de aborto por fase. Tras N bloqueadores en una fase, la fase aborta. Tras M bloqueadores en todo el plan, el orchestrator aborta. El sistema abandona cuando el camino se vuelve irreconocible, en lugar de intentar forzar el paso.

Checkpoints humanos forzados. Cada 5 fases, el orchestrator se detiene y pregunta. Aunque nada haya salido visiblemente mal, el operador confirma la dirección. Las ejecuciones largas sin supervisión y sin revisión humana son el modo más peligroso; esta barandilla lo descarta.

Cuarentena de decisiones. Las cosas que solo el operador puede decidir se enrutan a DECISIONS y Ralph las salta. El agente nunca adivina en una pregunta que pertenece a un humano.

Tope de coste. El monitoreo de coste es responsabilidad del operador (una herramienta externa como ccusage). Una fase que se vuelve inesperadamente cara es también una señal de que algo derivó y vale una comprobación.

9. Un principio

La forma entera de Ralph se reduce a una línea.

"Cualquier cosa que la mente del operador trataría como rutina, deja que el sistema la recorra por sí solo. Cualquier cosa que la mente del operador trataría como decisión, ponla en cola y espera."

Y esa línea es también donde termina esta extensión de tres artículos — y donde la serie misma llega a su reposo.

La Parte 1 — Por qué Alice preguntó: ¿cómo acumulo mi mente para que la IA no la pierda?

Los primeros nueve artículos respondieron: construir una persona que trace el límite de la mente, una memoria que la guarde entre sesiones, skills que compriman sus verbos, hooks que disparen lo que se olvidaría, Multi-Agent para evitar que un único contexto lo cargue todo, verificación para fijar "listo," economía de tokens para proteger los espacios de señal y protocolos de sesión para que cada día arranque y se apague en el mismo lugar.

Los últimos tres artículos respondieron: escribe un PRD para que la intención sobreviva a la sesión. Escribe release gates para que "listo" se vuelva un hecho. Ejecuta un bucle para que el camino entre intención y llegada se recorra solo mientras el operador maneja únicamente las decisiones que son suyas.

Cuando las doce piezas están en su lugar, el operador deja de ser la persona que hace el trabajo y se convierte en la persona que decide qué trabajo vale la pena hacer. La mente — la cosa original, irreducible de la Parte 1 — está finalmente donde debería estar: en la cima de la pila, decidiendo, mientras todo lo de abajo carga la mano de obra.

Esa es la versión de trabajar con IA hacia la que he construido durante los últimos meses. La herramienta puede ser Claude, puede ser Codex, puede ser lo que venga después. Las doce decisiones anteriores no dependen de la herramienta. Esperan a cualquiera que decida construir su propio colaborador en lugar de usar uno.

Si esta serie acortó aunque sea un poco el tiempo hasta esas decisiones, la intención del operador aterrizó donde se pretendía.