ralph

[RALPH - ITERACIÓN {{ITERACIÓN}}/{{MÁX}}]

Tu intento anterior no generó la promesa de finalización. Continúa trabajando en la tarea.

<Propósito> Ralph es un bucle de persistencia impulsado por PRD que sigue trabajando en una tarea hasta que TODAS las historias de usuario en prd.json tengan passes: true y estén verificadas por un revisor. Combina persistencia de sesión, reintento automático en caso de fallo, seguimiento estructurado de historias y verificación obligatoria antes de la finalización. </Propósito>

<Cuándo_Usar>

• La tarea requiere finalización garantizada con verificación (no solo "haz tu mejor esfuerzo")
• El usuario dice "ralph", "no pares", "debe completarse", "termina esto" o "sigue hasta terminar"
• El trabajo puede abarcar múltiples iteraciones y necesita persistencia entre reintentos
• La tarea se beneficia de una ejecución estructurada impulsada por PRD con aprobación del revisor </Cuándo_Usar>

<Cuándo_No_Usar>

• El usuario quiere una canalización autónoma completa desde la idea hasta el código: usa autopilot en su lugar
• El usuario quiere explorar o planificar antes de comprometerse: usa la habilidad plan en su lugar
• El usuario quiere una corrección rápida de una sola vez: delega directamente a un agente ejecutor
• El usuario quiere control manual sobre la finalización: delega directamente a un agente ejecutor
• El usuario ya tiene un /goal activo de Claude Code y solo quiere que se monitoree ese bucle de objetivo nativo: adopta el /goal existente explícitamente o usa solo notas de Ultragoal basadas en artefactos en lugar de iniciar Ralph como un bucle de persistencia competidor </Cuándo_No_Usar>

<Por_Qué_Existe_Esto> Las tareas complejas a menudo fallan silenciosamente: las implementaciones parciales se declaran "terminadas", se omiten las pruebas, se olvidan los casos límite. Ralph lo evita al:

1. Estructurar el trabajo en historias de usuario discretas con criterios de aceptación comprobables (prd.json)
2. Iterar historia por historia hasta que cada una pase
3. Rastrear el progreso y los aprendizajes entre iteraciones (progress.txt)
4. Requerir una verificación fresca del revisor contra criterios de aceptación específicos antes de la finalización </Por_Qué_Existe_Esto>

<Modo_PRD> Por defecto, ralph opera en modo PRD. Se genera automáticamente un prd.json de andamio cuando se inicia ralph si no existe ninguno. El estado activo del PRD transitorio tiene alcance de sesión en .omc/state/sessions/{sessionId}/prd.json cuando hay un ID de sesión disponible; los archivos prd.json / .omc/prd.json heredados a nivel de proyecto se leen como entradas de migración de inicio.

Puerta de inicio: Ralph siempre inicializa y valida prd.json al inicio. El texto heredado --no-prd se sanitiza de la solicitud para compatibilidad hacia atrás, pero ya no omite la creación o validación del PRD.

Opt-out de Deslop: Si {{PROMPT}} contiene --no-deslop, omite el pase de deslop posterior a la revisión por completo. Usa esto solo cuando el pase de limpieza esté intencionalmente fuera del alcance de la ejecución.

Selección de revisor: Pasa --critic=arquitecto, --critic=crítico o --critic=códice en la solicitud de Ralph para elegir el revisor de finalización para esa ejecución. arquitecto sigue siendo el predeterminado.

Detección y reconciliación de estado obsoleto (#3669): Si un PRD queda sin terminar por una salida anormal/no del Paso 8 (bloqueo, terminación forzada, cancelación antes de /oh-mi-claudecódice:cancelar, fin de sesión), Ralph muestra una advertencia explícita [ADVERTENCIA DE PRD OBSOLETO] al inicio/reanudación, en el contexto de continuación y al final de la sesión, con recuentos de elementos no terminados, antigüedad del último toque y señales de puntero obsoleto (PRD nombreRama fusionado/desaparecido). NUNCA se infiere finalización del estado de PR/rama/fusión por sí solo; el estado de git es solo una señal de advertencia. Una historia se reconcilia automáticamente a passes: true SOLO cuando el PRD lleva evidencia observable configurada y cada verificación pasa:

{
  "reconciliation": {
    "staleAfterMs": 7200000,
    "observableChecks": {
      "US-001": [
        { "type": "fileContains", "path": "src/landed.ts", "pattern": "LANDED_SYMBOL" },
        { "type": "gitGrep", "ref": "origin/dev", "pattern": "LANDED_SYMBOL" }
      ]
    }
  }
}

Tipos de verificación: fileExists / fileContains (árbol de trabajo) y gitGrep (contenido en una referencia — esto es "verificado por contenido en troncal", nunca estado de PR). Las historias sin verificaciones configuradas nunca se marcan automáticamente. Las historias reconciliadas mantienen architectVerified: false y aún requieren verificación del revisor del Paso 7 antes del Paso 8; cada decisión se agrega al registro de auditoría prd-reconciliation.jsonl y se resume en las notas de la historia. </Modo_PRD>

<Enmiendas_de_Criterio_PRD> Los criterios de aceptación son la autoridad de finalización del PRD: el Paso 4 verifica CADA criterio activo y el Paso 7 revisa contra ellos. Un criterio puede dejar de regir SOLO a través de la ruta de enmienda que preserva evidencia, nunca por eliminación silenciosa o por "satisfacer" un criterio que la medición ha refutado.

Cuando la implementación demuestra que un criterio es empíricamente falso (por ejemplo, un conteo en el resumen de despacho es incorrecto), enmiéndalo:

1. Reemplaza el criterio refutado con la corrección medida, o supéralo cuando no haya reemplazo que rija.
2. Registra la enmienda en el libro mayor criterionAmendments de la historia. El texto del criterio original se conserva textualmente (nunca se reescribe ni elimina) junto con:
   • kind: "replaced" o "superseded"
   • original: el criterio refutado textual (debe estar aún activo cuando se registra la enmienda)
   • replacement: el criterio corregido (solo para replaced)
   • reason: por qué el original ya no rige
   • evidence: la medición acotada que lo refutó (por ejemplo, "enumeró 12 setters, no 16: ...")
   • authority: quién hizo la enmienda (usa el id de sesión de ralph)
   • timestamp: marca de tiempo ISO 8601
3. La verificación de finalización luego verifica solo los criterios ACTIVOS; el libro mayor mantiene la pista de auditoría para que los revisores vean por qué el original ya no rige.

Reglas:

• Una enmienda sin evidencia acotada, razón, autoridad o marca de tiempo es inválida: el PRD falla al cerrarse al leer en lugar de debilitarse silenciosamente.
• Un original que aún está activo no puede enmendarse; un original solo puede enmendarse una vez.
• Ruta programática: amendCriterion(dir, storyId, { original, replacement, reason, evidence, authority }) y supersedeCriterion(dir, storyId, { original, reason, evidence, authority }).
• Los PRD editados manualmente deben preservar las mismas invariantes; un libro mayor contradictorio (original aún activo o enmendado dos veces) hace que el PRD sea inválido.
• Esto no es una herramienta para debilitar objetivos: existe para que "la medición discrepa del plan" se resuelva hacia la medición sin que el bucle pierda su control. </Enmiendas_de_Criterio_PRD>

<Política_de_Ejecución>

• Dispara llamadas de agentes independientes simultáneamente: nunca esperes secuencialmente por trabajo independiente.
• Usa run_in_background: true para operaciones largas (instalaciones, compilaciones, suites de pruebas).
• Siempre pasa el parámetro model explícitamente al delegar en agentes.
• Lee docs/shared/agent-tiers.md antes de la primera delegación para seleccionar los niveles de agente correctos.
• Entrega la implementación completa: sin reducción de alcance, sin finalización parcial, sin eliminar pruebas para que pasen.
• Si se menciona un /goal de Claude Code, trátalo como una transferencia de bucle de sesión nativa/fuente de evidencia solo y usa las políticas de conflicto deterministas refuse, adopt_existing y artifact_only en lugar de manejo de advertencias no determinista. Ralph sigue siendo la autoridad del bucle OMC para esta ejecución; no afirmes que /goal ejecutó pruebas o leyó archivos de forma independiente, y no trates el éxito del evaluador como un sustituto de la verificación del revisor de Ralph. </Política_de_Ejecución>

2. Selecciona la próxima historia: Lee el archivo PRD activo y selecciona la historia de mayor prioridad con passes: false. Este es tu enfoque actual.

3. Implementa la historia actual:

   • Delegar en agentes especialistas en niveles apropiados:
     • Búsquedas simples: nivel BAJO (Haiku) -- "¿Qué devuelve esta función?"
     • Trabajo estándar: nivel MEDIO (Sonnet) -- "Agrega manejo de errores a este módulo"
     • Análisis complejo: nivel ALTO (Opus) -- "Depura esta condición de carrera"
   • Si durante la implementación descubres subtareas, agrégalas como nuevas historias al archivo PRD activo
   • Ejecuta operaciones largas en segundo plano: compilaciones, instalaciones, suites de pruebas usan run_in_background: true

4. Verifica los criterios de aceptación de la historia actual: a. Para CADA criterio de aceptación activo en la historia, verifica que se cumpla con evidencia fresca b. Ejecuta las comprobaciones relevantes (prueba, compilación, lint, verificación de tipos) y lee la salida c. Si la implementación demuestra que un criterio es empíricamente FALSO (la medición lo refuta), NO marques la historia como completa y NO elimines ni debilites silenciosamente el criterio. En su lugar, enmiéndalo a través de la ruta que preserva evidencia descrita en <Enmiendas_de_Criterio_PRD>: reemplázalo o supéralo en los criterios activos y agrega el original (textual) con kind, reason, evidence, authority y timestamp al libro mayor criterionAmendments de la historia. Luego continúa verificando los criterios ACTIVOS restantes d. Si algún criterio activo NO se cumple y NO se enmienda, continúa trabajando -- NO marques la historia como completa

5. Marca la historia como completa: a. Cuando TODOS los criterios de aceptación activos estén verificados, crea una afirmación de finalización vinculada a una revisión: establece passes: true y establece completionCriteriaRevision a la governingCriteriaRevision actual de la historia. No establezcas architectVerified; la aprobación del revisor vincula eso por separado. b. Registra el progreso en progress.txt: qué se implementó, archivos cambiados, aprendizajes para futuras iteraciones c. Agrega cualquier patrón de código base descubierto a progress.txt

6. Verifica la finalización del PRD: a. Lee el archivo PRD activo -- ¿TODAS las historias están marcadas como passes: true (sin criterios activos no verificados)? b. Si NO están todas completas, vuelve al Paso 2 (selecciona la próxima historia) c. Si TODAS están completas, procede al Paso 7 (verificación del revisor)

7. Verificación del revisor (por niveles, contra criterios de aceptación):

   • <5 archivos, <100 líneas con pruebas completas: nivel ESTÁNDAR mínimo (architect-medium / Sonnet)
   • Cambios estándar: nivel ESTÁNDAR (architect-medium / Sonnet)

   • 20 archivos o cambios de seguridad/arquitectura: nivel EXHAUSTIVO (architect / Opus)

   • Si --critic=crítico, usa el agente critic de Claude para el pase de aprobación
   • Si --critic=códice, ejecuta omc ask codex --agent-prompt critic "..." para el pase de aprobación. La solicitud de Codex crítico DEBE incluir:
     1. La lista completa de criterios de aceptación de prd.json para verificación
     2. Una directiva para evaluar si la implementación es ÓPTIMA — no solo correcta, sino si existe un enfoque significativamente mejor (más simple, más rápido, más mantenible) que la implementación pasó por alto
     3. Una directiva para revisar todo el código relacionado con los cambios (llamantes, llamados, tipos compartidos, módulos adyacentes), no solo los archivos modificados directamente
     4. La lista de archivos cambiados durante la sesión de ralph para contexto
   • Piso de Ralph: siempre al menos ESTÁNDAR, incluso para cambios pequeños
   • El revisor seleccionado verifica contra los criterios de aceptación ESPECÍFICOS de prd.json, no un vago "¿está terminado?"
   • En APROBACIÓN: procede inmediatamente al Paso 7.5 en el mismo turno. NO hagas una pausa para informar el veredicto al usuario: la notificación ocurre solo en el Paso 8 (/oh-my-claudecode:cancel) o en el rechazo (Paso 9). Tratar un veredicto aprobado como un punto de control de notificación es un antipatrón de parada cortés.

7.5 Pase de Deslop Obligatorio (se ejecuta incondicionalmente después de la aprobación del Paso 7, a menos que {{PROMPT}} contenga --no-deslop):

• Invoca la habilidad ai-slop-cleaner a través de la herramienta Skill: Skill("oh-my-claudecode:ai-slop-cleaner") — es una Habilidad, no un agente. Si la llamas erróneamente mediante Task(subagent_type="oh-my-claudecode:ai-slop-cleaner"), el enlace PreToolUse de OMC deniega la llamada con el identificador correcto de la herramienta Skill; no sustituyas un agente con nombre similar. Ejecútalo en modo estándar (no --review) en los archivos cambiados durante la sesión actual de Ralph solamente.

• Mantén el alcance limitado al conjunto de archivos cambiados de Ralph; no amplíes el pase de limpieza a archivos no relacionados.

• Si el revisor aprobó la implementación pero el pase de deslop introduce ediciones de seguimiento, mantén esas ediciones dentro del mismo alcance de archivos cambiados antes de continuar.

  7.6 Re-verificación de Regresión:

• Después del pase de deslop, vuelve a ejecutar todas las pruebas relevantes, compilación y verificaciones de lint para la sesión de Ralph.

• Lee la salida y confirma que la ejecución de regresión posterior al deslop realmente pase.

• Si la regresión falla, revierte los cambios del limpiador o ... [truncado para traducción]