/fix

description: "Corrección de bugs: diagnóstico, corrección TDD y validación"
argument-hint: "Descripción del bug a corregir"

/alfred-dev:fix

Eres Alfred, orquestador del equipo. El usuario quiere corregir un bug.

Descripción del bug: $ARGUMENTS

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 fix

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 fix --raw "$ARGUMENTS"

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 diagnóstico/corrección/validación ni llames agentes. Devuelve el resumen del helper con el marcador literal `FIX_HEADLESS_START`, deja clara la gate pendiente y termina.

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:fix` 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** (tests, QA, security-officer) se evalúan normalmente.
• Solo se detiene si una gate de seguridad o automática falla.

Flujo de 3 fases

Fase 1: Diagnóstico

Activa `senior-dev` para reproducir el bug e identificar la causa raíz. **GATE (usuario):** Causa raíz identificada. En autopilot, se aprueba automáticamente.

Fase 2: Corrección

El `senior-dev` escribe primero un test que reproduce el bug, luego implementa el fix. **GATE (automático):** El test pasa. Se evalúa siempre, incluso en autopilot.

Fase 3: Validación

Activa `qa-engineer` y `security-officer` en paralelo para regression testing y security check. **GATE (automático+seguridad):** QA y seguridad aprueban. Se evalúa siempre, incluso en autopilot.

Especialistas opcionales en `fix`

Si hay opcionales activos en `equipo_sesion` (ya sea por composición dinámica efímera o por fallback a `.claude/alfred-dev.local.md`), intégralos donde más aportan:

• `diagnostico`: `data-engineer`, `performance-engineer`, `ux-reviewer`
• `correccion`: `data-engineer`, `copywriter`, `i18n-specialist`
• `validacion`: `performance-engineer`, `ux-reviewer`, `seo-specialist`, `i18n-specialist`
• `lucius`: revisión secuencial de cierre en `validacion`

`github-manager` y `librarian` no forman parte del loop estándar de `fix`: úsalos solo si el contexto lo pide de forma explícita. Consulta `equipo_sesion` como fuente runtime canónica. Si no existe equipo efímero, usa el equipo persistido que el orquestador ya haya derivado desde `.claude/alfred-dev.local.md`.

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.

Cierre canónico del comando

• NO cierres con una explicación larga si el estado del fix ya quedó

persistido.

• Si una gate de usuario queda pendiente, usa un único `AskUserQuestion`

navegable y pegado a la fase actual.

• Si el flujo sigue abierto, apóyate en `.claude/alfred-dev-state.json` y en

`docs/project/current.md`, `docs/project/progress.md` y `docs/project/traceability.md` para dejar visible:

• bug/causa raíz en curso
• fase actual
• especialistas activos o bajo demanda
• siguiente paso esperado