Launch (Lanzamiento)

¿Qué hace Launch (Lanzamiento)?

Launch es la ejecución de entrega del astillero: desde el brief de misión hasta el cambio verificado y enviado. Se sitúa en el límite de la verificabilidad: los agentes ejecutan continuamente todo lo que es repetible y aceptable por evidencia; los humanos deciden lo que el sistema no puede juzgar o lo que resulta costoso fallar. El objetivo no es la automatización máxima, sino la delegación máxima del trabajo verificable, de modo que el tiempo humano se dedique solo a las decisiones que solo un humano puede tomar.

La prueba de verificabilidad, aplicada a cada paso: si esto se hace mal, ¿puede el sistema detectarlo? ¿Puede rehacerlo o revertirlo automáticamente? Si ambas son afirmativas → agente. Si no hay una respuesta única, el sistema no puede juzgarlo o es costoso fallar → humano.

Launch asume que el astillero existe y se niega a ejecutarse si no es así. La puerta del astillero es la primera acción de cada invocación, antes de la resolución del idioma del documento y antes de leer cualquier especificación proporcionada:

• Ejecutar la auditoría completa --check de dique seco — superficies faltantes, un CONTEXT.md faltante o con documentLanguage de frontmatter no válido, rutas muertas, términos del glosario no utilizados en el código, estándares nunca referenciados. Este es el único criterio: Launch no realiza ningún inventario de instalación por separado.
• Los hallazgos procesables / de alta confianza bloquean la ejecución de forma permanente: enumera cada uno de esos hallazgos textualmente, señala /oh-my-claudecode:drydock, indica que la ejecución nunca comenzó y no se produjeron artefactos, y detente. Sin una anulación explícita, trata cualquier hallazgo como bloqueante.
• Anulación estricta (solo con intención explícita): los hallazgos de baja confianza, los hallazgos clasificados explícitamente como falsos positivos en el informe de dique seco, o un repositorio de prueba/descartable declarado explícitamente por el usuario pueden anularse solo con una intención de usuario deliberada y por invocación: la anulación debe nombrar el/los hallazgo(s) o el ámbito descartable y nunca debe tragarse silenciosamente un hallazgo procesable de alta confianza. Sin bandera de omisión general.
• Limitación actual de la auditoría: hoy --check es una lista de verificación de instrucciones de skill sin un contrato de hallazgos/gravedad legible por máquina ni ejecutable; la clasificación de gravedad se basa en la redacción del informe de dique seco hasta que exista un contrato estructurado. Un contrato de salida de hallazgos/gravedad legible por máquina es el seguimiento previsto; la redacción de la puerta se mantiene honesta sobre lo que puede y no puede confiar mecánicamente.
• Una auditoría limpia (o un ámbito de baja confianza/falso positivo/descartable anulado explícitamente) admite la ejecución. Cada ranura de registro (CONTEXT.md, docs/adr/, docs/business/) y superficie de la instalación ya existe en ese punto; Launch llena el registro a medida que las decisiones se asientan, pero nunca crea las ranuras.
• La entrada de reglas es CLAUDE.md — el mapa del astillero no reconoce sustituto.

El límite

Puntos de control humanos (el 20% crítico)	Ejecución continua del agente (el 80% mecánico)
C1 redactar el brief de la misión (objetivo + alcance)	búsqueda de hechos y exploración del repositorio, autoservicio
C2 aprobar criterios de aceptación + lista de costuras de prueba	preparación de la entrevista: preguntas fronterizas agrupadas con respuestas recomendadas
C3 aprobar descomposición de tickets (granularidad, bordes bloqueantes)	redacción de especificaciones y tickets, validación mecánica (independencia, demostrabilidad, cabe en un contexto)
C4 responder decisiones irreversibles que surgen durante la ejecución (agrupadas, asíncronas)	implementación tdd en las costuras acordadas, compilaciones, pruebas, regresiones
C5 aceptar el informe de finalización; vetar mediante Supuestos Abiertos y la lista de sedimentos por línea	revisión de código, verificación en todo el cambio, programación de fronteras del equipo, todo el registro

Entre los puntos de control, el pipeline nunca está inactivo: los agentes siguen trabajando en cada ticket fronterizo que no dependa de una respuesta humana pendiente.

Postura del ciclo de vida

Launch es una composición sin estado sobre el ciclo de vida existente de OMC — no posee una máquina de estados en tiempo de ejecución:

• El equipo es propietario de los estados de las tareas, las transiciones, la cancelación y la limpieza en tiempo de ejecución; Launch nunca los muta fuera del contrato del Equipo.
• Las superficies canónicas plan → execute → review → verify poseen su propio comportamiento de ciclo de vida existente. Los artefactos creados por Launch se limitan a .omc/specs/<feature-slug>/, CONTEXT.md, docs/adr/ y docs/business/ — más, solo después de la aprobación C5, las ranuras de sedimento nombradas en la tabla de la Fase 5.
• Launch no tiene reanudación automática. Después de una interrupción, vuelve a leer los artefactos y el estado actual del Equipo, pero continúa solo a través de una nueva invocación explícita de Launch después de que el ciclo de vida del Equipo propietario haya alcanzado un límite de terminación/limpieza compatible. Nunca inferir una aprobación humana ni reproducir una tarea in_progress.
• Los esfuerzos nebulosos son jurisdicción del navegador: cuando la puerta de niebla dirige a /oh-my-claudecode:ask-navigator, la ejecución nunca comenzó — sin artefactos, sin estado parcial. El mapa del navegador es el único portador entre sesiones; Launch se reanuda solo desde el brief de misión que este devuelve.
• Launch no agrega recibo de aprobación, contador de revisión, registro de reproducción, ruta de cancelación, mecanismo de reversión ni ciclo de vida de limpieza propio.

Cualquier afirmación de durabilidad en este skill es una afirmación sobre los archivos en disco, no sobre un tiempo de ejecución oculto.

Fase 0 — Entrada

Una ejecución llega a esta fase solo a través de una puerta de astillero limpia. Antes de leer una especificación proporcionada o entrar en la Fase 1, resuelve el idioma del documento. Una elección humana explícita en la invocación actual gana; de lo contrario, lee una etiqueta BCP-47 válida del frontmatter de CONTEXT.md en la clave estable exacta documentLanguage; de lo contrario, requiere una inferencia unánime de alta confianza de CLAUDE.md y luego README.md. Una etiqueta china persistida, simple o solo de región, es ambigua en cuanto a escritura y debe preguntarse una vez en ese nivel de autoridad, nunca omitirse por inferencia. La evidencia china faltante, mixta, conflictiva, de baja confianza, explícitamente no válida o ambigua en cuanto a escritura requiere una pregunta de idioma agrupada; no adivines. El chino debe resolverse en una etiqueta de escritura explícita zh-Hans o zh-Hant. zh-Hans-* selecciona el compañero Simplificado y zh-Hant-* selecciona el compañero Tradicional, mientras que la etiqueta normalizada completa se persiste. Persiste la etiqueta normalizada resuelta de vuelta a CONTEXT.md antes de cualquier artefacto creado por Launch para que una invocación explícita fresca pueda leerla sin estado de conversación oculto. El humano lee y mantiene estos artefactos; los agentes son independientes del idioma.

Localiza solo prosa, etiquetas orientadas al humano y valores escalares localizables. Las rutas, los comandos slash, las banderas, los bloques de código, los marcadores de posición, las claves de frontmatter y los valores semánticos de máquina, las claves YAML/JSON, los tokens de ciclo de vida (plan, execute, review, verify), los enums de estado (pending, in_progress, completed, failed, ready-for-agent), los IDs, los blockedBy de tickets, los blocked_by públicos del Equipo y todos los tokens de control/analizador permanecen byte a byte estables. Los compañeros de idioma de referencia son mutuamente excluyentes: emite exactamente una representación seleccionada, nunca encabezados o etiquetas duplicados bilingües.

• Autocomprobación breve antes de cualquier otra cosa: ¿el brief nombra un objetivo, un límite de alcance y no objetivos? Si faltan dos o más, dilo y pide una ronda de refinamiento (sharpening pass) — ejecutar el pipeline con un brief blando convierte la ambigüedad en resultados que parecen seguros.
• Puerta de niebla (Fog gate): después de la ronda de refinamiento, aplica la prueba de niebla del navegador — P1: ¿se puede declarar el destino en una sola oración (la especificación, decisión o cambio hacia el que este esfuerzo se está dirigiendo)? P2: ¿se pueden establecer las primeras tres decisiones con precisión ahora mismo, aunque ninguna pueda responderse todavía? Si alguna respuesta es no → la ejecución nunca comienza: indícalo claramente, señala que no se produjeron artefactos, recomienda /oh-my-claudecode:ask-navigator (el navegador del astillero traza la niebla como un mapa de tickets de decisión y devuelve un brief de misión) y detente. Entrega las preguntas residuales y el vocabulario ya establecido, para que el W1 del navegador no las vuelva a preguntar.
• Verificación del mapa (Map check): antes de leer una especificación proporcionada o entrar en la Fase 1, busca un navigator:map abierto (etiqueta del rastreador, o en .omc/wayfinder/). Si existe y esta invocación no proporciona un nuevo brief → recomienda /oh-my-claudecode:ask-navigator para trabajar la siguiente decisión en ese mapa, y detente. Si existe y se proporciona un nuevo brief → haz una pregunta — continuar con el mapa abierto, o comenzar un nuevo esfuerzo — antes de proceder.
• Ruta de especificación proporcionada → léela, salta a la Fase 2.
• Brief de misión → Fase 1.
• Arreglo de un solo punto → entrégaselo a execute, sal.

Fase 1 — Convergencia (humano decide, agente prepara)

Ejecuta la entrevista con el protocolo del árbol de diseño: mapea las decisiones y sus dependencias, luego trabaja en rondas fronterizas — agrupa cada pregunta actualmente formulable en una ronda, numerada, cada una con una respuesta recomendada. El humano responde; el árbol se reforma; recalcula la frontera. Los hechos siempre son autoatendidos por subagentes a partir de la evidencia del repositorio — al humano solo se le pregunta lo que ninguna cantidad de exploración puede resolver.

Registro, escrito en el momento en que cada elemento se asienta:

• vocabulario del dominio → CONTEXT.md en la raíz del repo (una entrada por término)
• decisiones que pasan la prueba ADR (difíciles de revertir, sorprendentes sin contexto, compensación real) → docs/adr/NNNN-<slug>.md
• reglas de negocio y antecedentes descubiertos durante la convergencia → docs/business/ (un artículo por pregunta de negocio, el párrafo inicial indica por qué es importante)

La no convergencia aquí es trabajo normal, no un fallo: si la frontera no se vacía, presenta las preguntas residuales clasificadas — esto es la entrada de C2, no un error. Si las preguntas residuales mismas no pueden establecerse con precisión (la prueba de niebla P2 falla), el destino en sí mismo no está establecido y eso está más allá de la autoridad de C2: detente, anota lo que ya se ha establecido (vocabulario en CONTEXT.md, preguntas respondidas), recomienda /oh-my-claudecode:ask-navigator y sal — el pipeline nunca inventa un destino.

Desvío al loft (Loft detour). Una pregunta residual que es precisa pero no puede resolverse en prosa — necesita ser vista o cliqueada, no descrita (cómo debería verse la interfaz de usuario, si un modelo de estado se siente correcto) — se responde con un artefacto, no con más preguntas: llama a la herramienta Skill con "loft", deja que el capitán reaccione, e incorpora esa reacción de vuelta a la entrevista. El artefacto del loft es la entrada de C2; el capitán firma lo que vio, no lo que le dijeron.

Briefs del puerto (Harbor briefs). Un brief de misión entregado por /oh-my-claudecode:harbor lleva decisiones firmadas con enlaces y condiciones aplicables: consúmelos como ya tomadas — no vuelvas a preguntar objetivos de negocio sin cambios. Si el código se ha movido desde que se recopiló la evidencia (nuevo head, base cambiada), verifica nuevamente la evidencia técnica afectada; el nuevo alcance de implementación más allá del brief firmado aún obtiene su propia aprobación.

Fase 2 — Síntesis de especificaciones (agente redacta → C2 aprueba)

Sintetiza .omc/specs/<feature-slug>/spec.md:

# Especificación de <Funcionalidad>
## Problema
## Solución
## Historias de Usuario        (numeradas, cada una con criterios de aceptación comprobables)
## Decisiones de Implementación
## Decisiones de Prueba   (solo comportamiento externo)
## Fuera de Alcance

Redacta todo, luego detente en C2: presenta los criterios de aceptación y la lista de costuras de prueba para la aprobación humana. Las costuras se seleccionan mediante la evidencia del repositorio y la disciplina de módulos profundos (interfaces públicas, costuras de prueba existentes, análisis de profundidad); el humano confirma o corrige la lista — una costura que el humano no ha aprobado no recibe pruebas.

Puerta de durabilidad (aplicada por el agente, sin necesidad de aprobación): la especificación y los tickets llevan contratos, nunca coordenadas — sin rutas de archivo, sin números de línea. Los fragmentos que codifican una decisión mejor que la prosa (máquinas de estado, reductores, esquemas) son la excepción y establecen su origen (generalmente un loft).

Fase 3 — Descomposición de tickets (agente redacta → C3 aprueba)

Divide en slices verticales bajo .omc/specs/<feature-slug>/tickets/:

• NN-slug.md, un archivo por ticket, ordenados por dependencia, cada uno declarando blockedBy: [ids]
• cada ticket cruza todas las capas, es demostrable de forma independiente y cabe en un contexto nuevo
• las refactorizaciones amplias siguen expandir-contraer: añade la nueva forma, migra en lotes, elimina la antigua — cada lote es un ticket

La validación mecánica del lado del agente se ejecuta primero (independencia, demostrabilidad, ajuste de contexto). Luego C3: presenta granularidad, bordes bloqueantes y fusiones/divisiones propuestas para la aprobación humana. Iterar hasta que se apruebe. Marca cada ticket como ready-for-agent.

Regla de cableado de integración: cada slice vertical incluye su propio cableado y una aserción de humo — un slice cuya salida nada monta, sirve o importa no está terminado. Las costuras entre slices que ningún slice posee individualmente (montaje de rutas, servicio estático, cableado de punto de entrada) obtienen un ticket de integración explícito como el último elemento de la frontera.

Fase 4 — Ejecutar la frontera

La frontera es cada ticket cuyos bloqueadores están todos completos.

Paralelo (predeterminado, 2+ tickets). Entrega tickets al equipo: cada ticket se convierte en una tarea del equipo, los bordes blockedBy se transfieren — los mecanismos de reclamo del equipo seleccionan solo tareas de frontera. Genera N trabajadores. Cada trabajador implementa con la disciplina tdd en las costuras aprobadas en C2, aplicando /oh-my-claudecode:minimal-code-discipline como la disciplina de tiempo de escritura (permanece opt-in); un ticket se cierra solo después de que la revisión de código pase en el diff, declarado por el revisor — el implementador nunca se autoaprueba.

Serial (ticket único, o --serial). Delega un ticket a la vez a un subagente ejecutor; misma puerta de revisión.

Puerta de revisión de dos ejes. La revisión de cierre se ejecuta a lo largo de dos ejes, en paralelo, reportados por separado — nunca fusionados ni clasificados de forma cruzada, porque un cambio puede pasar un eje y fallar el otro (conforme a los estándares pero con comportamiento incorrecto; fiel pero que rompe convenciones). El revisor falla el ticket cuando falla cualquiera de los ejes:

• Eje de estándares — el diff contra el volumen de docs/standards/ correspondiente, más una línea base de olores solo de juicio (un estándar de repositorio documentado anula la línea base; cualquier cosa que las herramientas ya apliquen se omite). Este es el consumidor permanente que mantiene las superficies de estándares referenciadas.
• Eje de especificación — el diff contra los criterios de aceptación de este ticket (la especificación es el libro de contabilidad total del cual se descompusieron los tickets; se consulta solo para rastrear de dónde vino un criterio y para dictaminar sobre el alcance introducido de contrabando — comportamiento que ningún ticket autorizó).

Fase 5 — Verificación de cierre

Solo después de que todos los tickets de esta ronda estén completed o failed, y después del ultimátum de C4 (el humano ha respondido por las decisiones que la ejecución encontró irreversibles), se compila el informe de finalización para C5.

El informe de finalización contiene:

• Resumen de cambios: cada archivo tocado, clasificado por ticket, con el hash del diff.
• Supuestos abiertos: decisiones tomadas durante la implementación que dependen de una suposición que el humano debe conocer (por ejemplo, "asumimos que el límite de tarifa sigue siendo 10 req/s").
• Lista de sedimentos por línea: cada importación de dependencia, configuración de herramienta, elección de constante mágica, estructura de datos elegida sobre otra — todo lo que podría discutirse pero que un revisor de código no detectaría. Nombrado por archivo y número de línea.
• Mapa de registro completo: enlaces a cada artefacto creado en la Fase 1 y la Fase 2, y el estado del ticket.

C5: el humano acepta o veta. Un veto puede ser:

• Especificar una corrección en un supuesto abierto → volver a la Fase 4 para ese ticket.
• Rechazar una línea de sedimento por completo → reabrir ese ticket con una instrucción explícita.

Solo después de la aceptación de C5, los cambios se envían a la rama de integración. Los slots de sedimento nombrados en esta fase — docs/adr/ y docs/business/ — se actualizan si la decisión de C5 lo requiere.

Guarda de integridad transversal

Launch se detiene inmediatamente si:

• Un ticket se desvía de su especificación (criterio de aceptación violado sin nuevo acuerdo de C2).
• La puerta de dique seco falla (superficie faltante, CONTEXT.md inválido, etc.).
• La puerta de niebla detecta que el destino no se puede establecer.
• Un ticket falla su revisión de código en cualquiera de los dos ejes y no se puede reconciliar en una ronda.
• El humano ordena una parada directa.

En cada parada, se produce un informe de parada: lo que se completó, lo que estaba en progreso y por qué se detuvo. No se produce ningún otro artefacto.

Resumen de comandos

Comando	Acción
launch	Inicia el pipeline desde la Fase 0
launch --serial	Fuerza ejecución serie de tickets (un ticket a la vez)
launch --spec-path <ruta>	Salta a la Fase 2 con una especificación preexistente
launch --override	Anula la puerta de dique seco para hallazgos de baja confianza / falsos positivos / ámbito descartable (requiere especificación de ámbito)
launch --status	Informa el estado actual del pipeline (solo lectura; no muta nada)