omc-plan

<Propósito> Plan crea planes de trabajo completos y procesables mediante interacción inteligente. Detecta automáticamente si debe entrevistar al usuario (solicitudes amplias) o planificar directamente (solicitudes detalladas), y admite modo consenso (bucle iterativo Planeador/Arquitecto/Crítico con deliberación estructurada RALPLAN-DR) y modo revisión (evaluación Crítica de planes existentes). </Propósito>

<Usar_Cuando>

• El usuario quiere planificar antes de implementar -- "planificar esto", "planificar el", "vamos a planificar"
• El usuario quiere recopilación estructurada de requisitos para una idea vaga
• El usuario quiere que se revise un plan existente -- "revisa este plan", --review
• El usuario quiere consenso desde múltiples perspectivas sobre un plan -- --consensus, "ralplan"
• La tarea es amplia o vaga y necesita delimitación antes de escribir cualquier código </Usar_Cuando>

<No_Usar_Cuando>

• El usuario quiere ejecución autónoma de principio a fin -- usa autopilot en su lugar
• El usuario quiere empezar a codificar inmediatamente con una tarea clara -- usa ralph o delega al ejecutor
• El usuario hace una pregunta simple que se puede responder directamente -- solo responde
• La tarea es una corrección enfocada única con un alcance obvio -- usa un skill de ejecución en lugar de ejecutarlo desde este módulo de planificación </No_Usar_Cuando>

<Por_Qué_Existe>

Saltar al código sin comprender los requisitos conduce a retrabajo, expansión del alcance y omisión de casos límite. Plan proporciona recopilación estructurada de requisitos, análisis de expertos y planes controlados por calidad para que la ejecución comience desde una base sólida. El modo consenso añade validación desde múltiples perspectivas para proyectos de alto riesgo. </Por_Qué_Existe>

<Política_De_Ejecución>

• Detectar automáticamente el modo entrevista vs directo según la especificidad de la solicitud
• Hacer una pregunta a la vez durante las entrevistas -- nunca agrupar múltiples preguntas
• Recopilar hechos de la base de código a través del agente explore antes de preguntar al usuario sobre ellos
• Los planes deben cumplir con los estándares de calidad: 80%+ de las afirmaciones citan archivo/línea, 90%+ de los criterios son comprobables
• El modo consenso se ejecuta completamente automatizado por defecto; añade --interactive para habilitar las indicaciones al usuario en los pasos de revisión del borrador y aprobación final
• El modo consenso usa el modo corto RALPLAN-DR por defecto; cambia al modo deliberado con --deliberate o cuando la solicitud señala explícitamente alto riesgo (autenticación/seguridad, migración de datos, cambios destructivos/irreversibles, incidente de producción, cumplimiento/PII, ruptura de API pública)
• Límite planificación/ejecución: los modos de planificación inspeccionan el contexto y producen únicamente planes/especificaciones/propuestas. Deben marcar los artefactos como pendiente de aprobación a menos que el usuario haya optado explícitamente por la ejecución en el turno actual o a través de la interfaz de aprobación estructurada. Antes de la aprobación explícita de ejecución, los modos de planificación NO DEBEN ejecutar comandos shell de mutación, editar archivos fuente, hacer commit, push, abrir PRs, invocar skills de ejecución, ni delegar tareas de implementación.
• Límite del flujo de trabajo de objetivos: cuando un plan compara /goal de Claude Code, Ralph, Team o Ultragoal solo de artefactos, identifica exactamente una autoridad de bucle principal y utiliza las políticas de conflicto deterministas rechazar, adoptar_existente, y solo_artefacto en lugar de manejo de advertencias no determinista. Los hechos de /goal deben citar solo fuentes de Claude Code/Anthropic (documentación de /goal de Claude Code: https://code.claude.com/docs/en/goal; changelog de Claude Code de Anthropic: https://raw.githubusercontent.com/anthropics/claude-code/main/CHANGELOG.md), y los planes NO DEBEN afirmar que el evaluador de /goal ejecuta comandos o lee archivos de forma independiente; requieren evidencia de prueba presentada antes de cualquier afirmación de finalización.
• Destino del documento del flujo de trabajo de objetivos: para comparaciones orientadas al usuario, mantén los ejemplos alineados con docs/shared/mode-selection-guide.md#goal-oriented-workflow-selection y docs/REFERENCE.md#goal-workflow-ux-goal-ralph-team-ultragoal. </Política_De_Ejecución>

Selección de Modo

Modo	Disparador	Comportamiento
Entrevista	Predeterminado para solicitudes amplias	Recopilación interactiva de requisitos
Directo	--direct, o solicitud detallada	Omitir entrevista, generar plan directamente
Consenso	--consensus, "ralplan"	Bucle Planeador -> Arquitecto -> Crítico hasta el acuerdo con deliberación estructurada RALPLAN-DR (corto por defecto, --deliberate para alto riesgo); añade --interactive para indicaciones al usuario en los pasos de borrador y aprobación
Revisión	--review, "revisa este plan"	Evaluación Crítica del plan existente

Modo Entrevista (solicitudes amplias/vagas)

1. Clasificar la solicitud: Amplia (verbos vagos, sin archivos específicos, toca 3+ áreas) desencadena el modo entrevista
2. Hacer una pregunta enfocada usando AskUserQuestion para preferencias, alcance y restricciones
3. Recopilar hechos de la base de código primero: Antes de preguntar "¿qué patrones usa tu código?", inicia un agente explore para averiguarlo, luego haz preguntas de seguimiento informadas
4. Construir sobre las respuestas: Cada pregunta se basa en la respuesta anterior
5. Consultar al Analista (Opus) para requisitos ocultos, casos límite y riesgos
6. Crear plan cuando el usuario indique estar listo: "crea el plan", "estoy listo/a", "conviértelo en un plan de trabajo"

Modo Directo (solicitudes detalladas)

1. Análisis Rápido: Consulta opcional breve al Analista
2. Crear plan: Generar plan de trabajo completo inmediatamente
3. Revisar (opcional): Revisión Crítica si se solicita

Modo Consenso (--consensus / "ralplan")

Modos RALPLAN-DR: Corto (predeterminado, estructura acotada) y Deliberado (para --deliberate o solicitudes explícitas de alto riesgo). Ambos modos mantienen la misma secuencia Planeador -> Arquitecto -> Crítico y las mismas puertas AskUserQuestion.

Anulaciones de proveedor (soportadas cuando la CLI del proveedor está instalada):

• --architect codex — reemplaza el pase del Arquitecto Claude con omc ask codex --agent-prompt architect "..." para una revisión de arquitectura centrada en la implementación
• --critic codex — reemplaza el pase del Crítico Claude con omc ask codex --agent-prompt critic "..." para una revisión externa antes de la ejecución
• Si el proveedor solicitado no está disponible, notifícalo brevemente y continúa con el paso predeterminado del Arquitecto/Crítico Claude para esa etapa

Ciclo de vida del estado: El hook de parada del modo persistente usa ralplan-state.json para forzar la continuación durante el bucle de consenso. El skill DEBE gestionar este estado:

• Al entrar: Llama a state_write(mode="ralplan", active=true, session_id=<session_id_actual>) antes del paso 1
• Al entregar a ejecución (aprobación → ralph/team): Llama a state_write(mode="ralplan", active=false, session_id=<session_id_actual>). NO uses state_clear aquí — state_clear escribe una señal de cancelación de 30 segundos que deshabilita la aplicación del hook de parada para TODOS los modos, dejando desprotegido el modo de ejecución recién lanzado.
• En salida terminal real (rechazo, salida de plan no interactiva, error/aborto): Llama a state_clear(mode="ralplan", session_id=<session_id_actual>) — no sigue ningún modo de ejecución, por lo que la ventana de señal de cancelación es inofensiva.
• NO liberes durante pasos intermedios como la aprobación del Crítico o la presentación de iteración máxima, ya que el usuario aún podría seleccionar "Solicitar cambios".

Sin limpieza, el hook de parada bloquea todas las paradas posteriores con mensajes de refuerzo [RALPLAN - CONSENSO DE PLANIFICACIÓN] incluso después de que el flujo de trabajo de consenso haya finalizado. Siempre pasa session_id para evitar limpiar el estado de otras sesiones concurrentes.

1. Planeador crea el plan inicial y un resumen RALPLAN-DR compacto antes de cualquier revisión del Arquitecto. El resumen DEBE incluir:

   • Principios (3-5)
   • Impulsores de Decisión (los 3 principales)
   • Opciones Viables (>=2) con pros/contras acotados para cada opción
   • Si solo queda una opción viable, una justificación de invalidación explícita para las alternativas que fueron rechazadas
   • En modo deliberado: un pre-mortem (3 escenarios de fallo) y un plan de pruebas ampliado que cubra pruebas unitarias / integración / e2e / observabilidad

2. Retroalimentación del usuario (solo --interactive): Si se ejecuta con --interactive, DEBE usar AskUserQuestion para presentar el borrador del plan más el resumen de Principios / Impulsores de Decisión / Opciones de RALPLAN-DR para alineación temprana de la dirección con estas opciones:

   • Proceder a revisión — enviar al Arquitecto y al Crítico para evaluación
   • Solicitar cambios — volver al paso 1 con la retroalimentación del usuario incorporada
   • Saltar revisión — ir directamente a la aprobación final (paso 7) Si NO se ejecuta con --interactive, procede automáticamente a la revisión (paso 3).

3. Arquitecto revisa la solidez arquitectónica usando Task(subagent_type="oh-my-claudecode:architect", ...). La revisión del Arquitecto DEBE incluir: el contraargumento de la posición más fuerte (antítesis) contra la opción favorecida, al menos una tensión de compensación significativa, y (cuando sea posible) una ruta de síntesis. En modo deliberado, el Arquitecto debe señalar explícitamente las violaciones de principios. Espera a que este paso se complete antes de proceder al paso 4. NO ejecutes los pasos 3 y 4 en paralelo. El Arquitecto DEBE evaluar la misma instantánea fija del plan producida por el Planeador en el paso 1 sin mutarla; la salida del Arquitecto NO DEBE pasarse al Crítico.

4. Crítico evalúa según los criterios de calidad usando Task(subagent_type="oh-my-claudecode:critic", ...). El Crítico DEBE verificar la coherencia principio-opción, la exploración justa de alternativas, la claridad de mitigación de riesgos, los criterios de aceptación comprobables y los pasos de verificación concretos. El Crítico DEBE rechazar explícitamente alternativas superficiales, contradicciones de impulsores, riesgos vagos o verificación débil. En modo deliberado, el Crítico DEBE rechazar la ausencia/debilidad del pre-mortem o la ausencia/debilidad del plan de pruebas ampliado. Ejecutar solo después de que el paso 3 esté completo. El Crítico DEBE evaluar la misma instantánea fija del plan de forma independiente, como una llamada de Tarea separada, de forma individual y esperada; el Crítico NO DEBE consumir ni recibir la revisión del Arquitecto.

   Revisiones secuenciales independientes de una instantánea fija del plan. El Arquitecto y el Crítico revisan cada uno la misma instantánea fija del plan producida por el Planeador en el paso 1, y ninguna revisión la muta. La salida del Arquitecto NO DEBE pasarse al Crítico. El Arquitecto y el Crítico DEBEN ejecutarse secuencialmente como llamadas de Tarea separadas e individualmente esperadas, nunca en paralelo, y la Tarea del Crítico NO DEBE emitirse hasta que la Tarea del Arquitecto se haya completado y su resultado se haya esperado. El Crítico NO DEBE consumir ni recibir la revisión del Arquitecto. Los resultados del Arquitecto y del Crítico DEBEN ser combinados solo por el Planeador durante la revisión o la síntesis de mejora, y solo después de que ambas revisiones se hayan completado.

5. Bucle de re-revisión (máximo 5 iteraciones): Si el Crítico rechaza, ejecuta este bucle cerrado: a. Recopilar toda la retroalimentación de rechazo del Arquitecto + Crítico (síntesis solo por el Planeador: los resultados del Arquitecto y del Crítico DEBEN ser combinados solo por el Planeador, y solo después de que ambas revisiones se hayan completado). b. Pasar la retroalimentación al Planeador para producir un plan revisado c. Volver al Paso 3 — el Arquitecto revisa el plan revisado d. Volver al Paso 4 — el Crítico evalúa el plan revisado e. Repetir hasta que el Crítico apruebe O se alcancen las 5 iteraciones máximas f. Si se alcanzan las iteraciones máximas sin aprobación, presentar la mejor versión al usuario a través de AskUserQuestion con la nota de que no se alcanzó el consenso de expertos

6. Aplicar mejoras: Cuando los revisores aprueban con sugerencias de mejora, fusionar todas las mejoras aceptadas en el archivo del plan antes de proceder. La salida final del consenso DEBE incluir una sección ADR con: Decisión, Impulsores, Alternativas consideradas, Por qué se eligió, Consecuencias, Seguimientos. Específicamente: a. Recopilar todas las sugerencias de mejora de las respuestas del Arquitecto y del Crítico b. Desduplicar y categorizar las sugerencias c. Actualizar el archivo del plan en .omc/plans/ con las mejoras aceptadas (añadir detalles faltantes, refinar pasos, fortalecer criterios de aceptación, actualizaciones de ADR, etc.) d. Anotar qué mejoras se aplicaron en una breve sección de registro de cambios al final del plan

7. Tras la aprobación del Crítico (con las mejoras aplicadas): marcar el estado del plan como pendiente de aprobación a menos que ya se haya capturado la aprobación explícita de ejecución. (solo --interactive) Si se ejecuta con --interactive, usa AskUserQuestion para presentar el plan con estas opciones:

   • Aprobar ejecución vía team (Recomendado) — aceptación explícita para proceder a través de agentes de equipo paralelos coordinados (/team). Team es la superficie de orquestación canónica desde v4.1.7.
   • Aprobar ejecución vía ralph — aceptación explícita para proceder a través de la persistencia de Ralph con verificación
   • Compactar y luego regresar para aprobación de ejecución — aceptación explícita para compactar primero la ventana de contexto (recomendado cuando el contexto es grande después de la planificación), luego detenerse en el plan pendiente de aprobación guardado y preguntar de nuevo antes de lanzar la ejecución
   • Solicitar cambios — volver al paso 1 con la retroalimentación del usuario
   • Rechazar — descartar el plan por completo Si NO se ejecuta con --interactive, generar el plan final marcado como pendiente de aprobación, llamar a state_clear(mode="ralplan", session_id=<session_id_actual>) y detenerse. No auto-ejecutar.

8. (solo --interactive) El usuario elige a través de la interfaz estructurada AskUserQuestion (nunca pedir aprobación en texto plano). Si el usuario selecciona Rechazar, llamar a state_clear(mode="ralplan", session_id=<session_id_actual>) y detenerse.

9. Tras la aprobación del usuario (cualquier opción que no sea rechazar):

   • Si se selecciona Aprobar ejecución vía team, inicia el modo Team y llama a state_write(mode="ralplan", active=false, session_id=<session_id_actual>). NO uses state_clear aquí.
   • Si se selecciona Aprobar ejecución vía ralph, inicia el modo Ralph y llama a state_write(mode="ralplan", active=false, session_id=<session_id_actual>). NO uses state_clear aquí.
   • Si se selecciona Compactar y luego regresar para aprobación de ejecución, compactar el contexto con task /compact, guardar el plan con estado pendiente de aprobación, llamar a state_clear(mode="ralplan", session_id=<session_id_actual>) y detenerse. El usuario preguntará de nuevo para la ejecución posterior.

Modo Revisión (--review / "revisa este plan")

1. Localizar plan: Buscar plan en .omc/plans/ o el usuario proporciona una ruta
2. Evaluación Crítica: El Crítico evalúa contra: claridad de objetivos (0-10), integridad de requisitos (0-10), viabilidad técnica (0-10), comprobabilidad (0-10), cobertura de riesgos (0-10)
3. Informe: Proporcionar puntuaciones con citas, elementos procesables de alta prioridad y, si la puntuación general es < 7, una recomendación para volver a planificar con el Planeador.

Directrices Generales

• Gestión de errores: Si cualquier paso de agente falla (timeout, error, salida inesperada), informar al usuario y ofrecer reintentar o continuar sin ese paso
• Ruta de archivo: Los planes se guardan en .omc/plans/ con marca de tiempo y nombre descriptivo
• Contexto: Para lograr la máxima cobertura de contexto durante el consenso, empezar cada paso con una sesión de let /context para verificar qué está cargado actualmente y si el tick de seguimiento [build:plans] está activo; usar task /compact en cualquier paso donde los límites de tokens amenacen con truncamiento, y task /clear en la parte superior del bucle de re-revisión del paso 5 para evitar la degradación del rendimiento de la memoria agotada en cada iteración. Después del modo consenso, usar siempre task /compact para preservar el contexto de planificación.