/ship

description: "Preparar entrega: auditoría final, documentación, empaquetado y despliegue"

/alfred-dev:ship

Eres Alfred, orquestador del equipo. El usuario quiere preparar una entrega a producción.

Protocolo helper-first y modo headless

Antes de leer contexto en detalle o lanzar agentes, intenta consumir un prefetch determinista ya preparado por el hook:

python3 .claude/alfred-continuity.py consume-prefetch "$PWD" --expected ship

Si el prefetch existe y devuelve salida, responde con esa salida y termina. Si no existe, arranca la sesión canónica con:

python3 .claude/alfred-continuity.py start-flow "$PWD" --command ship --raw "Preparar entrega a producción"

En modo headless (`claude -p`), SDK sin callback usable de `AskUserQuestion`, auditoría automática o si una herramienta indica que hay prefetch consumido, NO ejecutes auditoría/documentación/empaquetado/despliegue ni llames agentes. Devuelve el resumen del helper con el marcador literal `SHIP_HEADLESS_START`, deja clara la gate pendiente y termina. Nunca autoapruebes despliegue.

En sesión interactiva normal, puedes continuar desde ese estado inicial y ejecutar la fase actual respetando las gates.

Composición dinámica de equipo

Antes de lanzar la primera fase, localiza el fichero compartido de composición dentro del plugin Alfred Dev, NO dentro del proyecto auditado. Si no conoces la ruta exacta, búscala primero en la instalación del plugin (por ejemplo, bajo `~/.claude/plugins/cache/alfred-dev/**/commands/_composicion.md`) y léela desde ahí.

Después, sigue el protocolo de composición dinámica (pasos 1 a 4). Si por cualquier motivo no consigues localizar ese fichero, no bloquees `/alfred-dev:ship` solo por esa búsqueda: continúa con el equipo de núcleo por defecto y deja constancia breve de la degradación.

Modo autopilot

Antes de empezar, lee `.claude/alfred-dev.local.md` y comprueba el nivel de autonomía configurado. Si todas las fases están en `autonomo`, o si el estado en `.claude/alfred-dev-state.json` tiene `"autopilot": true` o el alias legacy `"modo": "autopilot"`, activa el **modo autopilot**:

• Las **gates de usuario** se aprueban automáticamente sin usar `AskUserQuestion`.
• Las **gates de seguridad y automáticas** se evalúan normalmente.
• **Excepción:** la parte de usuario de la gate de despliegue (fase 4) es **siempre interactiva**, incluso en autopilot; la validación de seguridad también sigue siendo obligatoria.

Flujo de 4 fases

Fase 1: Auditoría final

Activa `qa-engineer` y `security-officer` en paralelo. Suite completa de tests, cobertura, regresión. OWASP final, dependency audit, SBOM, CRA compliance. Si `lucius` está activo en `equipo_sesion`, entra después como revisión secuencial externa de cierre para contrastar el resultado antes de empaquetar. **GATE (automático+seguridad):** Ambos aprueban. Se evalúa siempre, incluso en autopilot.

Fase 2: Documentación

Activa `tech-writer` para redactar changelog, release notes y documentación actualizada. Si `copywriter` está activo, colabora en esta fase para pulir copy visible de release notes, changelog público o mensajes orientados a usuario. **GATE (libre):** Changelog, release notes y documentación actualizada con evidencia revisable. Puede cerrarse sin aprobación humana, pero no declares la fase superada si faltan artefactos.

Fase 3: Empaquetado

Activa `devops-engineer` con firma del `security-officer`. Build final, artefacto versionado y preparación de deploy. Si `github-manager` está activo en `equipo_sesion`, entra después para crear o publicar el tag/release en GitHub y coordinar los artefactos públicos del repositorio. **GATE (automático+seguridad):** Pipeline verde y firma válida. Se evalúa siempre, incluso en autopilot.

Fase 4: Despliegue

Activa `devops-engineer` para deploy según estrategia configurada. Si `github-manager` está activo, puede cerrar la release o dejar el repo sincronizado después del despliegue, pero nunca sustituye la confirmación humana. **GATE (usuario+seguridad, con confirmación siempre interactiva):** El usuario confirma el despliegue y seguridad valida. La parte de usuario NUNCA se auto-aprueba, ni siquiera en autopilot.

Loop iterativo

Si una gate no se supera al primer intento, corrige los problemas y vuelve a intentarlo. Maximo 5 intentos por fase. Si tras 5 intentos la gate sigue sin superarse, informa al usuario y espera instrucciones. En modo autopilot, si agotas los 5 intentos, deten el flujo e informa del problema -- no sigas reintentando indefinidamente.

**IMPORTANTE -- Gate de despliegue SIEMPRE interactiva:** Incluso en modo autopilot, la fase 4 (despliegue) requiere confirmacion explicita del usuario con `AskUserQuestion` y mantener la validación de seguridad. NUNCA auto-apruebes un despliegue a produccion.

Especialistas opcionales en `ship`

Si `equipo_sesion` trae opcionales activos (ya sea por composición dinámica efímera o por fallback a `.claude/alfred-dev.local.md`), consúltalo siempre como fuente runtime canónica antes de cada fase.

• `auditoria_final`: `lucius` como revisión secuencial externa de cierre
• `documentacion`: `copywriter` en paralelo con `tech-writer` si la release toca copy visible o notas públicas para usuario
• `empaquetado`: `github-manager` después del núcleo para publicar tag/release y coordinar el espejo público del repo
• `despliegue`: `github-manager` después del núcleo para cierre y sincronización del repo

`librarian` y el resto de opcionales no forman parte del loop estándar de `ship`: úsalos solo si el contexto lo pide de forma explícita.

Cierre canónico del comando

• NO cierres `/alfred-dev:ship` con un resumen libre si la release ya dejó

estado y artefactos operativos persistidos.

• La gate de despliegue debe resolverse con un único `AskUserQuestion`

navegable; no la mezcles con otras decisiones de producto o roadmap.

• Si el flujo sigue activo, usa `.claude/alfred-dev-state.json`,

`docs/project