sdd-es 2.0.0 → 2.6.0

package/commands/sdd.implementar.md

@@ -1,6 +1,6 @@
 ---
 description: Ejecuta las tareas con los agentes especializados configurados. Modos: todas en secuencia (sin args), tarea específica (T003), continuar (continuar). Cada tarea se verifica antes de la siguiente.
-allowed-tools: Read, Write, Edit, Bash, Task, TodoWrite, mcp__sdd-figma__analizar_sistema_diseño, mcp__sdd-figma__evaluar_ui_existente, mcp__sdd-figma__conectar_figma, mcp__sdd-figma__listar_componentes, mcp__sdd-figma__traer_componente, mcp__sdd-figma__mapear_estilos, mcp__sdd-figma__generar_componente, mcp__sdd-figma__sugerir_mejoras
+allowed-tools: Read, Write, Edit, Bash, Task, TodoWrite
 handoffs:
   - etiqueta: "Verificar contra spec"
     comando: sdd.verificar
@@ -42,11 +42,94 @@ cat .sdd/memoria/constitucion.md
 | `fase A` | **Por fase**: solo las tareas de la Fase A |
 | `revisar` | **Revisión**: invocar revisor sobre tareas completadas |
 
-## PASO 3 — Crear TODO list para visualización
+## PASO 3 — Gate Humano (aprobación antes de ejecutar)
+
+Antes de tocar cualquier archivo, muestra este resumen al usuario y espera confirmación:
+
+```
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+🏗️  PLAN DE IMPLEMENTACIÓN — {SPEC_ID}
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+
+📋 Tareas en cola:       [N] tareas
+🤖 Agentes que activarán: [lista única de agentes]
+📁 Archivos a modificar:  [lista de rutas, deducida de tareas.md]
+⏱️  Tiempo estimado:      [S: <15min / M: 15-45min / L: >45min]
+💡 Modo de ejecución:     [PTC paralelo / Secuencial]
+
+⚡ Nivel de esfuerzo recomendado: [según agentes activos]
+   • Si hay agentes OPUS (arquitecto/critico/seguridad/asesor-datos):
+     Escribe `/effort xhigh` en Claude Code antes de responder sí.
+   • Si solo hay agentes SONNET: `/effort medium` (o el default está bien)
+   • Si solo hay agentes HAIKU: `/effort low`
+   Puedes ignorar esto si ya lo configuraste o si prefieres el default.
+
+¿Procedo con la implementación?
+→ Responde **sí** para comenzar
+→ Responde **editar** para ajustar tareas antes
+→ Responde **cancelar** para salir
+```
+
+**Bypass automático** (no pide confirmación) cuando:
+- La variable de entorno `SDD_AUTO=1` está definida
+- El argumento incluye la palabra `forzar` (ej: `/sdd.implementar forzar`)
+- El modo es `continuar` (ya hubo confirmación previa)
+
+Si el usuario responde `editar` → detente y ofrece abrir `tareas.md` con un editor.
+Si responde `cancelar` → detente con mensaje: "Implementación cancelada. Cuando quieras continuar: `/sdd.implementar`"
+
+## PASO 3.5 — Crear TODO list para visualización
 
 Usa `TodoWrite` para mostrar el progreso en tiempo real al usuario. Crea un TODO por tarea pendiente.
 
-## PASO 3.5 — Planificación PTC (Programmatic Tool Calling)
+## PASO 4 — Model routing (asignación de modelo por agente)
+
+Antes de despachar cada agente, aplica esta tabla de routing. El modelo correcto se inyecta en el prompt del agente:
+
+```
+ROUTING DE MODELOS:
+
+Grupo OPUS (decisiones de alto impacto, razonamiento extendido):
+  → arquitecto, critico, seguridad, asesor-datos
+  → Modelo: claude-opus-4-8
+
+Grupo SONNET (implementación estándar, análisis medio):
+  → desarrollador-backend, desarrollador-frontend, tester
+  → desarrollador-mobile, operaciones, disenador-api, revisor
+  → Modelo: claude-sonnet-4-6
+
+Grupo HAIKU (búsqueda, resumen, tareas de baja complejidad):
+  → investigador, documentador
+  → Modelo: claude-haiku-4-5-20251001
+
+Override: si userConfig.modelo_principal está definido en plugin.json,
+aplícalo solo al Grupo OPUS (respeta preferencia del usuario para
+decisiones críticas sin afectar el costo de tareas rutinarias).
+```
+
+## PASO 4.5 — Planificación PTC (Programmatic Tool Calling) + revisión paralela
+
+Antes de ejecutar, clasifica las tareas seleccionadas según la skill `orquestacion-ptc`.
+
+**Revisión paralela post-implementación (B3):** Al terminar todas las tareas de implementación, si la spec toca áreas sensibles (auth, datos, APIs externas, seguridad), despacha revisor + crítico + seguridad en paralelo con PTC — los tres reciben el mismo diff y sus reportes se agregan en el reporte final. Esto es más barato que invocarlos secuencialmente.
+
+```javascript
+// PTC revisión paralela (solo si la spec toca áreas sensibles)
+const revisores = [
+  { agente: "revisor",   prompt: promptRevision(diff, spec, plan) },
+  { agente: "critico",   prompt: promptCritico(diff, spec, plan) },
+  { agente: "seguridad", prompt: promptSeguridad(diff, spec) },
+];
+const reportes = await Promise.all(
+  revisores.map(r => Task(r.agente, r.prompt))
+);
+// Agregar solo veredictos + hallazgos bloqueantes
+return reportes.map((r, i) => ({
+  agente:      revisores[i].agente,
+  veredicto:   r.veredicto,       // APROBADO | OBSERVACIONES | RECHAZADO
+  bloqueantes: r.bloqueantes,     // array de strings, vacío si no hay
+}));
+```
 
 Antes de ejecutar, clasifica las tareas seleccionadas según la skill `orquestacion-ptc`:
 
@@ -95,11 +178,11 @@ Tras el bloque PTC, **procesa las tareas del siguiente nivel del grafo** de form
 
 ---
 
-## PASO 4 — Ciclo por tarea
+## PASO 5 — Ciclo por tarea
 
 Para CADA tarea seleccionada, ejecuta este ciclo:
 
-### 4.1 — Verificar precondiciones
+### 5.1 — Verificar precondiciones
 
 ```bash
 # La tarea no debe estar completada/bloqueada
@@ -109,7 +192,7 @@ Para CADA tarea seleccionada, ejecuta este ciclo:
 Si una dependencia no está completa:
 > ⏸️ T00X depende de T00Y (no completada). Cambio el orden y ejecuto T00Y primero.
 
-### 4.2 — Anunciar inicio
+### 5.2 — Anunciar inicio
 
 ```
 🔧 T00X — [Nombre]
@@ -121,40 +204,13 @@ Si una dependencia no está completa:
 
 Marca la tarea como `en_progreso` en `.estado-tareas.json` y actualiza el TodoWrite.
 
-### 4.3 — Hook por tarea (opcional)
+### 5.3 — Hook por tarea (opcional)
 
 ```bash
 [ -f ".sdd/hooks/antes_cada_tarea.sh" ] && bash .sdd/hooks/antes_cada_tarea.sh "$TAREA_ID"
 ```
 
-### 4.4 — Activar MCP de Figma si la tarea es de UI/frontend
-
-**Antes de delegar al agente frontend**, verifica si la tarea es de tipo UI:
-
-```
-SI el agente asignado es "desarrollador-frontend"
-O el tipo/área de la tarea contiene: ui, componente, interfaz, diseño, vista, pantalla, layout, figma:
-
-  1. Ejecuta: mcp__sdd-figma__analizar_sistema_diseño({ project_root: "." })
-     → Guarda el perfil en contexto para el agente
-
-  2. SI la constitución o config del proyecto tiene figma_file_key definido:
-     a. Ejecuta: mcp__sdd-figma__conectar_figma({ file_key: "<key>" })
-     b. Si la tarea menciona un componente específico de Figma:
-        - mcp__sdd-figma__traer_componente({ file_key, node_id })
-        - mcp__sdd-figma__mapear_estilos({ file_key, node_id, project_root: "." })
-     c. Inyecta el resultado del mapeo en el contexto del agente
-
-  3. Si hay tokens sin mapear (matchType: "new"), avisa al usuario:
-     > ⚠️ Figma tiene [N] colores sin equivalente en el proyecto.
-     > El agente usará el valor hex directo. ¿Continuar?
-
-SI el agente NO es frontend → salta este paso
-```
-
-> **Sin PAT / sin Figma:** Si `FIGMA_PAT` no está definido o la conexión falla, continúa sin el MCP — no bloquea la implementación.
-
-### 4.5 — Constitutional AI pre-check
+### 5.4 — Constitutional AI pre-check
 
 Antes de delegar al agente, extrae las restricciones de constitución relevantes para la tarea:
 
@@ -173,7 +229,7 @@ esac
 
 Inyecta el resultado en el contexto del agente como **restricciones explícitas**, no como contexto de fondo.
 
-### 4.6 — Delegar al agente
+### 5.6 — Delegar al agente
 
 Usa la herramienta `Task` para invocar al agente asignado. El agente recibe:
 
@@ -183,18 +239,18 @@ Usa la herramienta `Task` para invocar al agente asignado. El agente recibe:
 - Constitución
 - Tareas ya completadas en este ciclo (contexto)
 - Lista de archivos modificados hasta ahora
-- **[Si es UI]** Perfil del sistema de diseño + mapeo de estilos Figma (del paso 4.4)
+- **[Si es UI]** Perfil del sistema de diseño del proyecto
 
 El agente debe:
 1. Leer el código existente relacionado antes de escribir
 2. Seguir patrones del codebase actual
 3. Implementar SOLO lo que la tarea pide
 4. Respetar la constitución
-5. **[Si es UI]** Usar `mcp__sdd-figma__generar_componente` como punto de partida si hay node_id disponible
+5. **[Si es UI]** Leer el sistema de diseño local antes de generar componentes
 6. Devolver lista de archivos modificados
 7. **NUNCA modificar `package.json` ni instalar paquetes** salvo que la spec lo indique de forma explícita — usar exclusivamente las dependencias ya presentes en el proyecto
 
-### 4.6 — Checkpoint de salida por tarea
+### 5.7 — Checkpoint de salida + Evaluator-Optimizer
 
 Antes de marcar la tarea como completada, verifica en dos niveles:
 
@@ -219,6 +275,35 @@ Antes de marcar la tarea como completada, verifica en dos niveles:
 # Python: python -m pytest [directorio_afectado] -q
 ```
 
+**Nivel 4 — Evaluator-Optimizer (solo para agentes del Grupo OPUS: arquitecto, critico, seguridad, asesor-datos)**
+
+Si el agente de la tarea es del Grupo OPUS, activa el ciclo Evaluador-Optimizador:
+
+```
+CICLO EVALUADOR-OPTIMIZADOR (máx. 3 iteraciones):
+
+1. El agente implementador entrega su output (iteración actual)
+
+2. El agente REVISOR evalúa el output contra los CAs de la tarea:
+   - Puntúa cada CA de 0 a 10
+   - Score final = promedio
+   - Umbral de aprobación: 8/10
+
+3. Si score ≥ 8 → PASA directamente (el output es aceptable)
+
+4. Si score < 8 e iteraciones < 3:
+   - El revisor devuelve feedback específico al agente implementador
+   - El agente implementador mejora el output incorporando el feedback
+   - Repetir desde paso 2
+
+5. Si score < 8 tras la 3ª iteración:
+   → FALLA con reporte detallado (score, CAs que no pasan, razón)
+   → No se hacen más intentos automáticos
+
+Importante: el ciclo NO se aplica a agentes del Grupo SONNET ni HAIKU
+para evitar consumo excesivo de tokens en tareas rutinarias.
+```
+
 Si cualquier nivel falla:
 1. Marca como `bloqueada` con descripción del fallo
 2. **NO continúa con tareas dependientes**
@@ -230,7 +315,7 @@ Si cualquier nivel falla:
    > b) Saltar y continuar (no recomendado)
    > c) Detener y revisar manualmente
 
-### 4.7 — Actualizar estado
+### 5.8 — Actualizar estado
 
 ```bash
 # .estado-tareas.json: T00X → completada
@@ -238,13 +323,13 @@ Si cualquier nivel falla:
 # .sdd/estado.json: ultima_actualizacion
 ```
 
-### 4.8 — Hook post-tarea (opcional)
+### 5.9 — Hook post-tarea (opcional)
 
 ```bash
 [ -f ".sdd/hooks/despues_cada_tarea.sh" ] && bash .sdd/hooks/despues_cada_tarea.sh "$TAREA_ID"
 ```
 
-### 4.9 — Reportar
+### 5.10 — Reportar
 
 ```
 ✅ T00X completada
@@ -253,15 +338,82 @@ Si cualquier nivel falla:
    [N]/[M] tareas completadas ([X]%)
 ```
 
+### 5.10.5 — Gate de calidad automático (antes de marcar DONE)
+
+Antes de marcar cualquier tarea como `completada`, ejecuta este gate en orden. **Los 3 puntos deben pasar**; si alguno falla, la tarea queda en `en_progreso` con el motivo anotado.
+
+**Punto 1 — Tests corren y pasan**
+```bash
+# Detectar framework y correr solo los tests relacionados con los archivos modificados
+TS_FILES=$(echo "$ARCHIVOS_MODIFICADOS" | tr ',' ' ')
+
+# Intento rápido (tests relacionados):
+npx jest --passWithNoTests --findRelatedTests $TS_FILES 2>/dev/null \
+  || python -m pytest $TS_FILES -q 2>/dev/null \
+  || echo "SKIP_NO_FRAMEWORK"
+
+# Si no hay tests relacionados detectables, corre la suite completa en modo quiet:
+# npm test -- --silent 2>/dev/null || echo "NO_TESTS_OK"
+```
+Resultado esperado: exit code 0 o "SKIP_NO_FRAMEWORK" / "NO_TESTS_OK".
+Si hay fallos de test → tarea queda `en_progreso`: `"Tests fallando: [detalle]"`.
+
+**Punto 2 — Linter pasa (o no hay linter configurado)**
+```bash
+# Detectar linter y ejecutar solo sobre archivos modificados
+if [ -f ".eslintrc*" ] || [ -f "eslint.config*" ]; then
+  npx eslint $TS_FILES --max-warnings=0 2>/dev/null
+elif [ -f "pyproject.toml" ] || [ -f ".flake8" ]; then
+  flake8 $TS_FILES 2>/dev/null || ruff check $TS_FILES 2>/dev/null
+else
+  echo "NO_LINTER_CONFIGURADO"
+fi
+```
+Resultado esperado: exit code 0 o "NO_LINTER_CONFIGURADO".
+Si hay errores de linter → tarea queda `en_progreso`: `"Linter fallando: [detalle]"`.
+
+**Punto 3 — Criterio de aceptación de la tarea se cumple**
+
+Lee la sección "Criterio de verificación" de la tarea en `tareas.md` y ejecuta el comando definido ahí. Si no hay comando definido, verifica manualmente que los artefactos esperados existen y exportan correctamente (según paso 5.7 niveles 1 y 2).
+
+Resultado esperado: el comando retorna exit 0 O la inspección manual confirma que el CA está cubierto.
+Si el CA no se cumple → tarea queda `en_progreso`: `"CA no cumplido: [razón]"`.
+
+**Decisión final:**
+```
+SI los 3 puntos pasan  → marcar tarea como `completada` → continuar al paso 5.10
+SI alguno falla        → marcar tarea como `en_progreso` con campo "motivo_bloqueo"
+                       → NO avanzar a tareas dependientes
+                       → Reportar al usuario:
+                         ⚠️ T00X no pasó el gate de calidad: [motivo]
+                         ¿Qué hacemos?
+                         a) Reintentar corrección automática
+                         b) Saltar (no recomendado, registra deuda técnica)
+                         c) Detener y revisar manualmente
+```
+
+### 5.11 — Checkpoint de contexto (compresión automática)
+
+Lleva un contador de tareas completadas en este ciclo. **Tras cada 5 tareas completadas**, ejecuta automáticamente la compresión de contexto para evitar el desbordamiento de la ventana en sesiones largas:
+
+```
+SI (tareas_completadas_en_ciclo % 5 == 0) Y tareas_completadas_en_ciclo > 0:
+  → Notificar: "🧹 Checkpoint de contexto: 5 tareas completadas, comprimiendo contexto…"
+  → Ejecutar: /sdd.comprimir aplicar
+  → Continuar con la siguiente tarea
+```
+
+Esto se hace de forma silenciosa y no requiere confirmación del usuario: es un mantenimiento automático del presupuesto de tokens. Si quedan menos de 5 tareas pendientes, no se fuerza un checkpoint extra (la compresión final ocurre en el PASO 6).
+
 ## VALIDACIÓN DE SALIDA
 
-El checkpoint de salida se aplica por tarea (ver paso 4.6 — tres niveles: criterio de tarea, artefactos esperados, no regresión). Al final de todas las tareas, la validación global se ejecuta en el PASO 5 mediante el revisor y la suite de tests completa.
+El checkpoint de salida se aplica por tarea (ver paso 5.7 — cuatro niveles: criterio de tarea, artefactos esperados, no regresión, Evaluator-Optimizer para agentes OPUS). Al final de todas las tareas, la validación global se ejecuta en el PASO 6 mediante el revisor y la suite de tests completa.
 
 **Condición de bloqueo**: si cualquier checkpoint individual falla y el usuario no elige continuar explícitamente, la implementación se detiene y no avanza a `/sdd.verificar`.
 
-## PASO 5 — Al terminar todas las tareas
+## PASO 6 — Al terminar todas las tareas
 
-### 5.1 — Invocar revisor
+### 6.1 — Invocar revisor
 
 ```bash
 # Usar el agente revisor con modelo de su config (recomendado: opus)
@@ -272,7 +424,7 @@ El revisor cruza el código generado contra:
 - Las decisiones del plan
 - Los principios de la constitución
 
-### 5.2 — Invocar tester para correr toda la suite
+### 6.2 — Invocar tester para correr toda la suite
 
 ```bash
 # Detectar framework de tests automáticamente y correr
@@ -284,11 +436,11 @@ npm test 2>/dev/null || pnpm test 2>/dev/null || yarn test 2>/dev/null || \
   echo "NO_FRAMEWORK_DETECTADO"
 ```
 
-### 5.3 — Invocar seguridad (si la tarea tocaba área sensible)
+### 6.3 — Invocar seguridad (si la tarea tocaba área sensible)
 
 Auditoría automática si la implementación tocó: autenticación, manejo de datos personales, queries dinámicas, APIs externas, manejo de archivos.
 
-## PASO 6 — Reporte final exhaustivo
+## PASO 7 — Reporte final exhaustivo
 
 ```markdown
 ## 📊 Implementación Completada: {ID}
@@ -342,7 +494,7 @@ Cubre: {Lista de CAs}
 ```
 ```
 
-## PASO 7 — Actualizar estado global
+## PASO 8 — Actualizar estado global
 
 ```json
 {
@@ -356,13 +508,81 @@ Cubre: {Lista de CAs}
 }
 ```
 
-## PASO 8 — Hook post-ejecución
+## PASO 9 — Hook post-ejecución
 
 ```bash
 [ -f ".sdd/hooks/despues_implementar.sh" ] && bash .sdd/hooks/despues_implementar.sh
 ```
 
-## PASO 9 — Siguientes pasos
+## PASO 10 — Deploy automático (si está configurado)
+
+**Solo si perfil == "guiado" Y vercel configurado:**
+
+```bash
+# Verificar si Vercel está configurado
+if grep -q "deploy.platform: vercel" .sdd/sdd.config.yaml; then
+  echo ""
+  echo "━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━"
+  echo "🚀 DESPLIEGUE AUTOMÁTICO"
+  echo "━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━"
+  echo ""
+  echo "✅ Tu app está lista para internet."
+  echo ""
+  echo "CHECKLIST PRE-DEPLOY:"
+  echo "  ✅ Código construido y verificado"
+  echo "  ✅ Tests pasando"
+  echo "  ✅ Sin secretos en el código"
+  echo ""
+  echo "¿Publico tu app en internet?"
+  echo "(Responde: sí / cambio algo / después)"
+  echo ""
+  
+  read -p "Tu respuesta: " DEPLOY_CHOICE
+  
+  if [ "$DEPLOY_CHOICE" = "sí" ]; then
+    echo ""
+    echo "⏳ Publicando en Vercel..."
+    echo ""
+    
+    # Invocar skill vercel-deploy
+    bash "$(dirname "$0")/../skills/vercel-deploy/vercel-deploy.sh" \
+      --spec-id "$SPEC_ID" \
+      --profile "guiado"
+    
+    if [ $? -eq 0 ]; then
+      echo ""
+      echo "✅ ¡Tu app está en internet!"
+      echo ""
+      # Leer URL del archivo de estado de Vercel
+      VERCEL_URL=$(grep "app_url" .sdd/.vercel-deploy.json 2>/dev/null | cut -d'"' -f4)
+      if [ -n "$VERCEL_URL" ]; then
+        echo "   Acceso: $VERCEL_URL"
+        echo ""
+        echo "Puedes compartir este link con quien quieras."
+      fi
+    else
+      echo ""
+      echo "⚠️  Hubo un problema publicando."
+      echo ""
+      echo "Opciones:"
+      echo "  1. Reintentar: /sdd.desplegar"
+      echo "  2. Cambiar algo: edita y ejecuta /sdd.implementar continuar"
+      echo "  3. Dejar para después: los cambios están en GitHub"
+    fi
+  elif [ "$DEPLOY_CHOICE" = "cambio algo" ]; then
+    echo ""
+    echo "✅ Esos cambios se guardarán automáticamente."
+    echo "Cuando estés listo, ejecuta: /sdd.implementar continuar"
+  else
+    echo ""
+    echo "✅ Sin problema. Cuando quieras publicar, ejecuta: /sdd.desplegar"
+  fi
+fi
+```
+
+---
+
+## PASO 11 — Siguientes pasos
 
 ```
 🎉 Implementación terminada
@@ -370,7 +590,7 @@ Cubre: {Lista de CAs}
 SIGUIENTES PASOS RECOMENDADOS:
    /sdd.verificar       — verificación final contra spec original
    /sdd.snapshot        — actualizar SNAPSHOT.md del producto
-   (commit a tu sistema de control de versiones manualmente)
+   /sdd.retro           — retrospectiva: qué aprendimos
 
 ¿Quieres empezar otra feature?
    /sdd.especificar [descripción]