autopilot

<Propósito> Autopilot toma una breve idea de producto y maneja de forma autónoma todo el ciclo de vida: análisis de requisitos, diseño técnico, planificación, implementación en paralelo, ciclos de QA y validación desde múltiples perspectivas. Produce código funcional y verificado a partir de una descripción de 2-3 líneas. </Propósito>

<Usar_Cuando>

• El usuario desea una ejecución autónoma de extremo a extremo desde una idea hasta código funcional
• El usuario dice "autopilot", "auto pilot", "autonomous", "build me", "create me", "make me", "full auto", "handle it all" o "I want a/an..."
• La tarea requiere múltiples fases: planificación, codificación, pruebas y validación
• El usuario desea una ejecución sin intervención y está dispuesto a dejar que el sistema ejecute hasta el final </Usar_Cuando>

<No_Usar_Cuando>

• El usuario quiere explorar opciones o hacer una lluvia de ideas: use la habilidad plan
• El usuario dice "solo explica", "solo borrador" o "qué sugerirías": responda de forma conversacional
• El usuario quiere un cambio de código único y enfocado: use ralph o delegue a un agente ejecutor
• El usuario quiere revisar o criticar un plan existente: use plan --review
• La tarea es una corrección rápida o un error pequeño: use delegación directa a un ejecutor </No_Usar_Cuando>

<Por_Qué_Existe> La mayoría de las tareas de software no triviales requieren fases coordinadas: comprender los requisitos, diseñar una solución, implementar en paralelo, probar y validar la calidad. Autopilot orquesta todas estas fases automáticamente para que el usuario pueda describir lo que quiere y recibir código funcional sin gestionar cada paso. </Por_Qué_Existe>

<Política_de_Ejecución>

• Cada fase debe completarse antes de que comience la siguiente
• La ejecución en paralelo se utiliza dentro de las fases cuando sea posible (Fase 2 y Fase 4)
• Los ciclos de QA se repiten hasta 5 veces; si el mismo error persiste 3 veces, deténgase e informe el problema fundamental
• La validación requiere la aprobación de todos los revisores; los elementos rechazados se corrigen y se vuelven a validar
• Cancele con /oh-my-claudecode:cancel en cualquier momento; el progreso se conserva para reanudar </Política_de_Ejecución>

<Perfiles_de_Flujo_de_Trabajo>

Perfiles de etapas con nombre (v1)

Seleccione un perfil configurado solo con /autopilot --workflow <nombre> <tarea>. Un perfil es un programa de etapas propiedad de autopilot, no un comando, modo, plugin, nombre de archivo o identidad de estado separada. Sin --workflow, autopilot conserva su ciclo de vida y comportamiento heredados.

Los perfiles de flujo de trabajo con nombre requieren Linux con la utilidad flock en v1 porque su límite de evidencia de transcripción utiliza un recorrido de descriptor de archivo sin seguimiento de Linux y su bloqueo de mutación recuperable utiliza bloqueo de asesoramiento del kernel. Los entornos no compatibles rechazan la activación explícita de --workflow antes de la mutación de estado; use el autopilot heredado en su lugar.

Los perfiles se configuran en JSONC de proyecto o usuario como autopilot.workflows.<slug>. Cada perfil v1 tiene exactamente version: 1 y stages; no se aceptan otras claves de perfil. Las únicas secuencias de etapas admitidas son:

{
  "autopilot": {
    "workflows": {
      "plan-build-qa": {
        "version": 1,
        "stages": ["ralplan", "execution", "qa"]
      }
    }
  }
}

[ralplan, execution]
[ralplan, execution, ralph]
[ralplan, execution, qa]
[ralplan, execution, ralph, qa]

ralplan crea el plan consumido por execution; execution crea el espacio de trabajo implementado requerido por ralph y qa. Por lo tanto, los requisitos previos omitidos o reordenados, las etapas duplicadas y las etapas no integradas no son válidas. Los nombres de perfil usan ^[a-z][a-z0-9-]{0,62}$, son solo metadatos validados y no pueden chocar con etapas integradas, nombres de autopilot/modo o alias obsoletos.

Las fuentes de configuración de usuario y proyecto se validan cada una antes de la composición. Los nombres diferentes coexisten; un perfil de proyecto con el mismo nombre reemplaza el perfil de usuario completo en lugar de fusionarlo en profundidad. La configuración del entorno no puede definir ni reemplazar perfiles.

En la selección exitosa, autopilot crea atómicamente su estado existente con ámbito de sesión con un descriptor normalizado inmutable y seguimiento de canalización solo seleccionada. El descriptor contiene el nombre del flujo de trabajo, la versión del perfil, las etapas canónicas y un hash SHA-256 de perfil determinista; excluye el texto de la tarea y el progreso mutable. Reanudar y Detener verifican ese hash y rechazan una discrepancia sin recargar la configuración ni emitir un mensaje de etapa. Cancelar, reanudar, limpiar, inspección de estado, HUD y continuación de Detener siguen siendo propiedad de autopilot.

Los hooks de Detener del plugin instalado y de la instalación independiente avanzan solo después de que aparece un registro de finalización de asistente autorizado para la etapa activa después del límite de transcripción de activación persistida de esa etapa. Vinculan la evidencia a la sesión propietaria y a la transcripción limitada sin enlace simbólico; rechazan la salida de comandos de usuario/herramienta/local y evidencia obsoleta o de etapa incorrecta; y usan actualizaciones de seguimiento de comparar antes de escribir para que los eventos de Detener duplicados o concurrentes avancen exactamente una vez. El estado público, HUD y la salida de Detener muestran solo metadatos de flujo de trabajo y progreso seguros, nunca la tarea, los internos del descriptor, las referencias de transcripción, los desplazamientos ni los hashes de registro.

Diferimientos v1

V1 no admite stageModels, enrutamiento de modelos, selección de proveedor o rol; ejecución en línea/sin generación; comandos, modos o archivos de estado dinámicos; etapas, mensajes, plugins, ramas, bucles, DAGs o devoluciones de llamada arbitrarios; o definiciones de perfil definidas por el entorno. La discrepancia del analizador de frontmatter de matriz en línea de habilidad personalizada separada también se difiere. </Perfiles_de_Flujo_de_Trabajo>

2. Fase 1 - Planificación: Cree un plan de implementación a partir de la especificación

   • Si existe un plan de consenso ralplan: Omita — ya está hecho en la canalización de 3 etapas
   • Arquitecto (Opus): Crear plan (modo directo, sin entrevista)
   • Crítico (Opus): Validar plan
   • Salida: .omc/plans/autopilot-impl.md

3. Fase 2 - Ejecución: Implemente el plan usando agentes ejecutores con persistencia Ralph cuando sea necesario

   • Ejecutor (Haiku): Tareas simples
   • Ejecutor (Sonnet): Tareas estándar
   • Ejecutor (Opus): Tareas complejas
   • Ejecute tareas independientes en paralelo

4. Fase 3 - QA: Ciclo hasta que todas las pruebas pasen

   • Construir, lint, probar, corregir fallos
   • Repetir hasta 5 ciclos
   • Detener antes si el mismo error se repite 3 veces (indica un problema fundamental)

5. Fase 4 - Validación: Revisión desde múltiples perspectivas en paralelo

   • Arquitecto: Integridad funcional
   • Revisor de seguridad: Verificación de vulnerabilidades
   • Revisor de código: Revisión de calidad
   • Todos deben aprobar; corregir y volver a validar en caso de rechazo

6. Fase 5 - Limpieza: Elimine todos los archivos de estado al completarse con éxito

   • Elimine .omc/state/autopilot-state.json, ralph-state.json (y las copias heredadas obsoletas ultraqa-state.json/ultrawork-state.json si existen)
   • Ejecute /oh-my-claudecode:cancel para una salida limpia

<Uso_de_Herramientas>

• Use Task(subagent_type="oh-my-claudecode:architect", ...) para la validación de arquitectura en la Fase 4
• Use Task(subagent_type="oh-my-claudecode:security-reviewer", ...) para la revisión de seguridad en la Fase 4
• Use Task(subagent_type="oh-my-claudecode:code-reviewer", ...) para la revisión de calidad en la Fase 4
• Los agentes forman su propio análisis y lo devuelven; el LÍDER luego genera cualquier agente de validación cruzada por sí mismo. No dependa de que un subagente genere más subagentes sin verificar la configuración de profundidad de Claude Code: Claude Code 2.1.217–2.1.218 estableció CLAUDE_CODE_MAX_SUBAGENT_SPAWN_DEPTH en 1, mientras que 2.1.219+ lo establece en 3. Mantenga la validación cruzada en el nivel del LÍDER a menos que la delegación anidada sea deliberada y esté soportada por el tiempo de ejecución activo.
• Nunca se bloquee con herramientas externas; proceda con los agentes disponibles si la delegación falla </Uso_de_Herramientas>

<Condiciones_de_Escalada_y_Detención>

• Deténgase e informe cuando el mismo error de QA persista en 3 ciclos (problema fundamental que requiere entrada humana)
• Deténgase e informe cuando la validación siga fallando después de 3 rondas de revalidación
• Deténgase cuando el usuario diga "stop", "cancel" o "abort"
• Si los requisitos eran demasiado vagos y la expansión produce una especificación poco clara, ofrezca redirigir a /deep-interview para aclaración socrática, o pause y pida al usuario una aclaración antes de continuar </Condiciones_de_Escalada_y_Detención>

<Lista_de_Verificación_Final>

• Todas las 5 fases completadas (Expansión, Planificación, Ejecución, QA, Validación)
• Todos los validadores aprobaron en la Fase 4
• Las pruebas pasan (verificado con la salida de una nueva ejecución de pruebas)
• La compilación tiene éxito (verificado con la salida de una nueva compilación)
• Los archivos de estado se limpiaron
• Se informó al usuario de la finalización con un resumen de lo que se construyó </Lista_de_Verificación_Final>

Advertencias de sesiones paralelas

• Anclaje de espacio de trabajo multirepo: coloque un marcador .omc-workspace en el directorio padre para que varias sesiones en sub-repos compartan un .omc/. Orden de resolución: OMC_STATE_DIR > .omc-workspace > git > cwd. Consulte docs/REFERENCE.md.
• Fuente del ID de sesión: la variable de entorno OMC_SESSION_ID prevalece en contextos CLI; los datos del hook data.session_id prevalecen en contextos de hook.
• ID de plan (cuando corresponda): El estado de Autopilot tiene ámbito de sesión. Dos autopilots en el mismo espacio de trabajo requieren IDs de sesión distintos.
• Veredicto paralelo: soportado (estado con ámbito de sesión)

Opciones de configuración en .claude/omc.jsonc (proyecto) o ~/.config/claude-omc/config.jsonc (usuario):

{
  "autopilot": {
    "maxIterations": 10,
    "maxQaCycles": 5,
    "maxValidationRounds": 3,
    "pauseAfterExpansion": false,
    "pauseAfterPlanning": false,
    "skipQa": false,
    "skipValidation": false,
    "execution": "solo"
  }
}

Para ejecutar la implementación de autopilot a través del tiempo de ejecución del equipo CLI de tmux y preferir trabajadores ejecutores de Cursor:

{
  "autopilot": {
    "execution": "team",
    "team": { "agentTypes": ["cursor"] }
  }
}

Con esa configuración, la etapa de ejecución debe lanzar trabajo de tipo ejecutor a través de:

omc team 1:cursor "<implementation task>"

o la superficie de compatibilidad de barra diagonal de Claude Code:

/omc-teams 1:cursor "<implementation task>"

Limitaciones:

• Los trabajadores de Cursor admiten roles de equipo de implementación y revisor. Los trabajadores critic, code-reviewer, security-reviewer y test-engineer deben emitir el archivo de veredicto estructurado consumido por el líder del equipo; la aprobación final sigue siendo responsabilidad de la sesión líder.
• Cursor requiere que el CLI cursor-agent esté instalado y autenticado. Si cursor-agent no está disponible, informe ese requisito de configuración en lugar de recurrir silenciosamente a la ejecución solo con Claude.

Reanudar

Si autopilot fue cancelado o falló, ejecute /oh-my-claudecode:autopilot nuevamente para reanudar desde donde se detuvo.

Mejores prácticas para la entrada

1. Sea específico sobre el dominio — "bookstore" no "store"
2. Mencione las características clave — "with CRUD", "with authentication"
3. Especifique las restricciones — "using TypeScript", "with PostgreSQL"
4. Déjelo ejecutar — evite interrumpir a menos que sea realmente necesario

Solución de problemas

¿Atascado en una fase? Verifique la lista TODO para tareas bloqueadas, revise .omc/autopilot-state.json o cancele y reanude.

¿Ciclos de QA agotados? El mismo error 3 veces indica un problema fundamental. Revise el patrón de error; puede ser necesaria una intervención manual.

¿La validación sigue fallando? Revise los problemas específicos. Es posible que los requisitos hayan sido demasiado vagos: cancele y proporcione más detalles.

Integración de entrevista profunda

Cuando se invoca a autopilot con una entrada vaga, la Fase 0 puede redirigir a /deep-interview para aclaración socrática:

Usuario: "autopilot build me something cool"
Autopilot: "Su solicitud es abierta. ¿Le gustaría ejecutar una entrevista profunda primero?"
  [Sí, entrevista primero (Recomendado)] [No, expandir directamente]

Si ya existe una especificación de entrevista profunda en .omc/specs/deep-interview-*.md, autopilot la usa directamente como salida de la Fase 0 (la especificación ya ha sido validada matemáticamente para mayor claridad).

Canalización de 3 etapas: deep-interview → ralplan → autopilot

La canalización completa recomendada encadena tres puertas de calidad:

/deep-interview "vague idea"
  → Q&A socrático → especificación (ambigüedad ≤ 20%)

...

[truncado para traducción]