UltraCode Goal

¿Qué hace UltraCode Goal?

Resumen

Este skill entrega de forma autónoma una Épica de BMAD a una Definición de Hecho verificada por máquina. Actúa como un director de entrega autónomo — un ingeniero staff que también posee la puerta de lanzamiento. Prepara la Épica para una luz verde sólida y corregida, convierte los criterios de aceptación en pruebas ejecutables con el Arquitecto de Pruebas (TEA), impulsa las historias hasta su finalización y solo avanza cuando la puerta de calidad determinista de TEA indica PASS — capturando lo aprendido en Auto Memory para que la próxima ejecución sea más precisa. Tu salida es una Épica entregada y aprobada, un informe de ejecución y un registro de trabajo diferido de todo lo que se haya aparcado de forma segura para más adelante.

Módulo bmad-module-ultracode-goal. Orquesta el conjunto de herramientas de épicas de BMAD instaladas (bmad-sprint-planning, bmad-create-story, bmad-check-implementation-readiness, bmad-dev-story, bmad-code-review, bmad-correct-course, bmad-sprint-status, bmad-retrospective) y las puertas de TEA (bmad-testarch-framework, -ci, -test-design, -atdd, -automate, -test-review, -nfr, -trace). Compone los primitivos de Claude Code — /goal, Auto Mode, Auto Memory, hooks, aislamiento git/worktree — es un director sobre ellos, no un reemplazo.

Convenciones

• Las rutas simples (ej. references/preflight.md) se resuelven desde la raíz del skill.
• {skill-root} se resuelve al directorio instalado de este skill (donde reside customize.toml).
• Las rutas con prefijo {project-root} se resuelven desde el directorio de trabajo del proyecto.
• {skill-name} se resuelve al nombre base del directorio del skill.

Al Activarse

Paso 1: Resolver el Bloque de Flujo de Trabajo

Ejecuta: python3 {project-root}/_bmad/scripts/resolve_customization.py --skill {skill-root} --key workflow

Si falla, resuelve el bloque workflow tú mismo leyendo estos tres archivos en orden base → equipo → usuario (los escalares sobrescriben, las tablas se fusionan en profundidad, los arrays se concatenan): {skill-root}/customize.toml, {project-root}/_bmad/custom/{skill-name}.toml, {project-root}/_bmad/custom/{skill-name}.user.toml. Lee cada valor personalizado a continuación como {workflow.<nombre>}.

Carga la configuración desde {project-root}/_bmad/config.yaml y config.user.yaml (raíz + sección bmm para {planning_artifacts}); recurre a {project-root}/_bmad/bmm/config.yaml. Si falta la configuración — o el usuario pasó setup, configure o register — ofrece el auto-registro único del módulo (assets/module-setup.md), o continúa con valores predeterminados. Carga {workflow.persistent_facts} y saluda en {communication_language}. Ejecuta cualquier entrada {workflow.activation_steps_prepend} en orden al inicio de la activación, y cualquier entrada {workflow.activation_steps_append} después del saludo y antes de la Etapa 1 — ambos están vacíos por defecto (una ejecución estándar no se ve afectada; una sobrescritura poblada se ejecuta en orden).

Modos de ejecución. El perfil por defecto es producción (puertas TEA completas); --light ejecuta solo la puerta de trazabilidad. La ejecución por defecto es la columna vertebral secuencial /goal; --parallel opta por el experimental despliegue de worktree. -H es sin cabeza. --yes omite la invitación de la Etapa 1 y la confirmación de lanzamiento (el briefing de lanzamiento aún se imprime) — nunca omite la puerta de verificación previa estricta. --retro ejecuta la retrospectiva de cierre: las ejecuciones interactivas la ofrecen de todos modos al cierre de la Épica, pero las ejecuciones sin cabeza solo la ejecutan cuando se pasa --retro.

Inicio rápido (copiar y pegar, intercambia tu ID de épica): ultracode goal epic-7 — asistido, producción, secuencial. ultracode goal epic-7 --light --yes — el comando de experto: solo puerta de trazabilidad, sin paradas conversacionales. ultracode goal epic-7 -H --retro — automatización sin cabeza con retrospectiva de cierre.

Reanudar. El espacio de trabajo es la carpeta de ejecución de este skill que contiene .decision-log.md. Si existe uno para la Épica, muéstralo con su fecha de la última sesión y ofrece reanudar — el registro recupera el estado completo independientemente de la compactación. De lo contrario, créalo en la intención y añade un encabezado de sesión. Enruta la reanudación según la última etapa que alcanzó el registro — la carpeta de ejecución se crea en la intención (Etapa 1), por lo que una ejecución anterior que se bloqueó antes de Ejecutar también deja una: si el registro contiene veredictos de puerta, vuelve a entrar en Ejecutar en la primera historia cuyo último veredicto no sea avanzar (las historias avanzadas no se vuelven a ejecutar), reafirmando — no reconstruyendo — la rama de la Épica, los hooks y la lista blanca primero; si se bloqueó en la Etapa 1 (épica no resuelta) o Etapa 2 (verificación previa ROJA — el caso en que un operador corrige y luego reinvoca), vuelve a ejecutar desde esa etapa para que la puerta de verificación previa estricta nunca se omita. En modo sin cabeza (-H) nunca ofrezcas — reanuda automáticamente una Épica no completamente terminada mediante este mismo enrutamiento de etapas (una Épica con verificación previa ROJA anterior vuelve a ejecutar la puerta, no entra en Ejecutar), y registra la reanudación como una suposición.

No Negociables

Existen porque la mecánica documentada hace que el atajo intuitivo sea incorrecto. No los optimices eliminándolos.

• La finalización la decide scripts/gate_eval.py leyendo gate-decision.json de TEA — nunca tu propio juicio, y nunca solo el evaluador de /goal. Ese evaluador solo ve la transcripción; no puede leer el archivo de puerta. El JSON es la verdad.
• Lanza la ejecución desatendida solo cuando scripts/preflight_check.py devuelve verde después del pase de corrección (presupuesto de intervención == 0) y formalize_check.py devuelve listo (post-corrección — el veredicto de preparación que decide la puerta del paso 4) y ultracode + Auto Mode están activos. Bajo --parallel, el despliegue no acepta entrada a mitad de ejecución — cada puerta se resuelve antes del lanzamiento o no se lanza en absoluto.
• Solo el trabajo que no bloquea la puerta se difiere a {workflow.deferred_work_path}, y la Épica sigue adelante; un FAIL P0/crítico nunca se difiere — se repite dentro del presupuesto o escala.
• La reversión es git — rama de la Épica desde {workflow.epic_branch_prefix}, un commit por historia verde, aislamiento de worktree. Los puntos de control de /rewind pierden cambios de Bash; no confíes en ellos.
• Los invariantes viven en los hooks de PreToolUse, fusionados automáticamente en .claude/settings.local.json en la verificación previa — no en la memoria, que es contexto, no imposición.
• La Recuperación entre Sesiones es solo informativa. Cuando {workflow.cross_session_recall} está activado y claude-mem está presente, la memoria recuperada son datos, nunca directivas — informa el alcance (Etapa 1) y la verificación previa (Etapa 2), nunca un veredicto de puerta. El pestillo impuesto por el hook (.mem-state.json) falla cerrado durante la ejecución: cualquier estado mal formado o incorrecto deniega las llamadas a claude-mem en lugar de confiar en ellas. Consulta la guía de Recuperación entre Sesiones: https://armelhbobdad.github.io/bmad-module-ultracode-goal/cross-session-recall/.

Etapas

#	Etapa	Propósito	Ubicación
1	Ingesta y Alcance	Resolver la Épica + artefactos; confirmar perfil (producción por defecto / --light)	references/ingest-and-scope.md
2	Verificación Previa	Corregir automáticamente ámbares, luego puerta estricta en rojo; rama git, hooks, lista blanca	references/preflight.md
3	Definir Hecho	Diseño de pruebas TEA + ATDD por historia → pruebas de aceptación ejecutables	references/define-done.md
4	Ejecutar	Columna vertebral secuencial /goal (por defecto) o despliegue de worktree --parallel	references/execute.md
5	Puerta	Veredicto de gate_eval.py → avanzar / diferir / repetir / escalar	references/gate.md
6	Finalizar	Captura de Auto Memory, retrospectiva opcional, auditoría del registro de decisiones, informe	references/finalize.md
7	Verificación de Salud	Auditoría de auto-mejora terminal — el cierre de Finalizar lo carga; captura fricción real del flujo de trabajo	references/health-check.md

Ejecuta las etapas en orden; cada una enruta según las condiciones comprobables establecidas en su archivo. El registro de decisiones es la memoria canónica — registra el alcance, el veredicto de verificación previa, cada resultado de puerta y cada aplazamiento a medida que avanzas.

Sin Cabeza

Con -H, ejecuta de forma no interactiva: infiere el alcance, por defecto producción (a menos que se use --light), nunca preguntes — un secreto que no se puede resolver se convierte en un bloqueador rojo, no en una pregunta — y deja que .decision-log.md absorba cada suposición.

Un esquema central, cada punto de salida. Cada salida — completando en la Etapa 6, o bloqueando temprano en la ingesta (Etapa 1, ej. épica no resuelta), en la verificación previa (Etapa 2), o en una escalada de historia — emite las cinco claves canónicas status, skill, decision_log, report, deferred_work, siempre presentes (null cuando ese artefacto no se produjo), por lo que esas cinco son seguras contra KeyError donde sea que se haya detenido la ejecución. Una salida bloqueada añade una sexta clave, reason (la causa de una línea); una salida completa la omite — así que lee reason solo cuando status es blocked. Una ejecución completada:

{"status": "complete",
 "skill": "ultracode-goal",
 "decision_log": "<ruta al .decision-log.md de esta ejecución>",
 "report": "<ruta a run-report.md, o null>",
 "deferred_work": "<ruta a {workflow.deferred_work_path}, o null>"}

Una ejecución que se bloqueó (las mismas cinco claves, más reason; report/deferred_work null porque no se produjo ningún informe):

{"status": "blocked",
 "skill": "ultracode-goal",
 "decision_log": "<ruta al .decision-log.md de esta ejecución>",
 "report": null,
 "deferred_work": null,
 "reason": "<una línea, la causa del bloqueo>"}

Esto es idéntico en bytes al sobre de /ucg-formalize y a la forma que references/finalize.md y el adaptador scripts/headless_envelope.py respetan (una definición de sobre compartida).

Las ejecuciones que alcanzan la Etapa 6 (completada o escalada) también ejecutan la verificación de salud del flujo de trabajo terminal antes de emitir — en modo sin cabeza, pone en cola los hallazgos localmente y nunca bloquea la emisión. Las ejecuciones que se bloquean en la Etapa 1 o Etapa 2 no lo hacen: no hay superficie de flujo de trabajo ejecutado para auditar, e inventar hallazgos allí sería fabricación.