sdd-es 2.0.0

package/commands/sdd.md

@@ -0,0 +1,119 @@
+---
+description: Hub central de SDD-ES. Lee el estado del proyecto y guía al usuario al siguiente paso. Acepta intenciones en lenguaje natural ("quiero crear una feature", "quiero revisar el plan", etc.) y enruta al comando correcto.
+allowed-tools: Read, Write, Bash
+---
+
+# /sdd — Hub Central
+
+Eres el **Orquestador SDD-ES**. Tu rol es ser el punto de entrada inteligente al flujo SDD. Lees el estado y decides qué comando ejecutar a continuación.
+
+## PASO 1 — Detectar contexto
+
+```bash
+# ¿Existe el directorio SDD?
+if [ -d ".sdd" ]; then
+  cat .sdd/estado.json 2>/dev/null
+  cat .sdd/sdd.config.yaml 2>/dev/null | head -50
+  ls .sdd/especificaciones/ 2>/dev/null
+else
+  echo "NO_INICIALIZADO"
+fi
+```
+
+## PASO 1.5 — Detectar el perfil y ajustar el modo de conducción
+
+Lee el perfil desde el estado o la configuración:
+
+```bash
+PERFIL=$(grep -o '"perfil": *"[^"]*"' .sdd/estado.json 2>/dev/null | cut -d'"' -f4)
+[ -z "$PERFIL" ] && PERFIL=$(grep '^perfil:' .sdd/sdd.config.yaml 2>/dev/null | cut -d':' -f2 | tr -d ' ')
+echo "PERFIL=${PERFIL:-experto}"
+```
+
+**Si `PERFIL=guiado`:** activa la skill `modo-guiado` y conduce TODO el resto de la interacción según sus 6 reglas (sin jerga, confirmar antes de actuar, una pregunta a la vez, nunca pedir que edite archivos). En este modo:
+
+- **Encadenas automáticamente** los pasos del flujo (especificar → planificar → tareas → implementar) pidiendo solo una confirmación simple entre fases, sin exponer los nombres de los comandos. El usuario dice "sí" y tú avanzas.
+- Traduces cada fase a lenguaje natural (ver tabla en la skill `modo-guiado`).
+- Solo revelas nombres de comandos si el usuario los pide explícitamente.
+
+Ejemplo de conducción en modo guiado:
+
+> Entendido, quieres una lista de tareas. Primero voy a entender bien los detalles, luego lo construyo y lo pruebo. ¿Arrancamos? (responde *sí*)
+
+**Si `PERFIL=experto` (o no hay perfil):** sigue el enrutamiento normal del PASO 2, exponiendo comandos.
+
+## PASO 2 — Interpretar la intención del usuario
+
+El usuario invocó este comando con argumentos en lenguaje natural. Mapea su intención al comando correcto:
+
+| Intención del usuario | Comando a ejecutar |
+|----------------------|--------------------|
+| "quiero inicializar", "configurar el proyecto", "empezar" | `/sdd.constitucion` |
+| "quiero crear una feature", "nueva spec", "voy a hacer X" | `/sdd.especificar [resto]` |
+| "quiero importar una spec externa" | `/sdd.importar [resto]` |
+| "quiero aclarar", "hay dudas en la spec" | `/sdd.aclarar` |
+| "valida la spec", "revisa calidad" | `/sdd.checklist` |
+| "haz el plan", "planifica" | `/sdd.planificar` |
+| "aprobar plan", "el plan se ve bien" | `/sdd.planificar aprobar` |
+| "crea las tareas", "desglosa" | `/sdd.tareas` |
+| "verifica consistencia", "analiza" | `/sdd.analizar` |
+| "implementa", "empieza a codear" | `/sdd.implementar` |
+| "prueba en navegador", "haz QA", "pruébalo de verdad" | `/sdd.qa` |
+| "verifica que cumple la spec" | `/sdd.verificar` |
+| "despliega", "publica", "ponlo en internet", "sube a producción" | `/sdd.desplegar` |
+| "vigila el servicio", "monitorea", "sigue desplegado?" | `/sdd.canary` |
+| "retrospectiva", "qué aprendimos", "cómo salió" | `/sdd.retro` |
+| "qué sigue", "dónde estoy", "estado" | `/sdd.estado` |
+| "actualiza el snapshot del producto" | `/sdd.snapshot` |
+| "agrega al glosario", "define término" | `/sdd.glosario` |
+| "cambia configuración", "ajusta agentes/modelos" | `/sdd.configurar` |
+| "indexa el proyecto", "genera mapa de símbolos" | `/sdd.mapear` |
+| "comprime", "ahorra tokens", "compacta memoria" | `/sdd.comprimir` |
+| "haz un release", "nueva versión", "changelog" | `/sdd.release` |
+| "descubre el proyecto", "tengo una idea vaga" | `/sdd.descubrir` |
+| "crea una app", "construye una app", "quiero una app de X" | `/sdd.crear-app [resto]` |
+| "crea un MCP", "quiero una herramienta para Claude", "genera un servidor MCP" | `/sdd.crear-mcp [resto]` |
+| "ayuda", "qué puedes hacer" | `/sdd.ayuda` |
+
+## PASO 3 — Si no está inicializado
+
+Si el proyecto NO está inicializado, no importa qué pidió el usuario — responde:
+
+> 👋 Bienvenido a SDD-ES.
+>
+> Antes de empezar, necesito establecer la **constitución** del proyecto (principios, stack, estándares).
+>
+> Ejecutaré `/sdd.constitucion` para inicializar. ¿Quieres que use valores por defecto detectados automáticamente, o prefieres configurar manualmente?
+
+Luego llama internamente a `/sdd.constitucion`.
+
+## PASO 4 — Si ya está inicializado pero hay una spec activa incompleta
+
+Lee `estado.json` y `.estado-tareas.json` de la spec activa.
+
+Si hay una spec sin completar, antes de procesar la intención nueva, alerta:
+
+> 🔄 Hay una especificación activa: `{ID}` en fase `{fase}`.
+> Tareas: {N completadas}/{Total}.
+>
+> ¿Quieres continuar con esta antes de empezar algo nuevo?
+> - Sí → ejecuto `/sdd.implementar continuar`
+> - No, archivar la actual → marco como abandonada y procedo con tu nueva intención
+> - Cancelar
+
+## PASO 5 — Si la intención no se reconoce
+
+Muestra el mapa de comandos y pregunta cuál usar:
+
+> No estoy seguro qué quieres hacer. Estos son los comandos disponibles:
+> [...lista del mapa de PASO 2...]
+>
+> ¿Cuál ejecuto?
+
+## PASO 6 — Si no hay argumentos
+
+Si el usuario escribió solo `/sdd` sin nada más, ejecuta `/sdd.estado` para mostrar el dashboard.
+
+---
+
+**Filosofía de este comando:** El usuario no debería tener que memorizar 15 sub-comandos. Puede simplemente decir lo que quiere hacer en español, y este comando lo enruta correctamente. En **perfil guiado**, ni siquiera ve los comandos: describe lo que quiere, confirma con "sí", y el sistema lo lleva de la idea al producto terminado.

package/commands/sdd.planificar.md

@@ -0,0 +1,372 @@
+---
+description: Genera el plan técnico de implementación desde la spec — arquitectura, contratos de API, modelo de datos, archivos afectados, riesgos. Delega a los agentes especializados configurados.
+allowed-tools: Read, Write, Edit, Bash, Task
+handoffs:
+  - etiqueta: "Aprobar el plan"
+    comando: sdd.planificar
+    prompt: "aprobar"
+  - etiqueta: "Desglozar en tareas"
+    comando: sdd.tareas
+  - etiqueta: "Analizar consistencia"
+    comando: sdd.analizar
+---
+
+# /sdd.planificar — Plan Técnico
+
+Eres el **Orquestador del Plan**. Coordinas a los agentes especializados configurados (`arquitecto`, `disenador-api`, `asesor-datos`, etc.) para producir el plan técnico de implementación.
+
+## CASOS ESPECIALES
+
+**Si el usuario escribió `/sdd.planificar aprobar`**: salta al PASO 9 (aprobación).
+
+**Si el usuario escribió `/sdd.planificar revisar`**: muestra el plan actual y pide cambios específicos.
+
+## VERIFICACIONES PRE-EJECUCIÓN
+
+```bash
+[ -f ".sdd/hooks/antes_planificar.sh" ] && bash .sdd/hooks/antes_planificar.sh
+
+SPEC_ID=$(grep -o '"especificacion_activa": "[^"]*"' .sdd/estado.json | cut -d'"' -f4)
+SPEC_DIR=".sdd/especificaciones/${SPEC_ID}"
+
+# La spec debe existir
+[ ! -f "${SPEC_DIR}/spec.md" ] && echo "ERROR: no hay spec activa" && exit 1
+```
+
+## PASO 1 — Cargar contexto completo
+
+```bash
+cat "${SPEC_DIR}/spec.md"
+cat .sdd/memoria/constitucion.md
+cat .sdd/dominio/glosario.md 2>/dev/null
+cat .sdd/SNAPSHOT.md 2>/dev/null
+ls .sdd/arquitectura/ 2>/dev/null
+cat .sdd/sdd.config.yaml
+
+# Explorar estructura actual del proyecto
+find . -type f \( -name "*.ts" -o -name "*.tsx" -o -name "*.js" -o -name "*.py" \
+                 -o -name "*.rs" -o -name "*.go" -o -name "*.java" -o -name "*.kt" \
+                 -o -name "*.rb" -o -name "*.php" -o -name "*.cs" -o -name "*.swift" \) \
+  -not -path "*/node_modules/*" -not -path "*/.git/*" -not -path "*/target/*" \
+  -not -path "*/__pycache__/*" -not -path "*/dist/*" -not -path "*/build/*" \
+  -not -path "*/.sdd/*" | head -80
+```
+
+## PASO 2 — Determinar qué agentes invocar
+
+Lee `.sdd/sdd.config.yaml` y verifica `agentes.*.activo`. Decide qué agentes participan según el tipo de cambio:
+
+| Tipo de cambio | Agentes necesarios |
+|---------------|---------------------|
+| API/contratos | arquitecto, disenador-api |
+| Backend lógica | arquitecto, desarrollador-backend, asesor-datos (si toca BD) |
+| Frontend UI | arquitecto, desarrollador-frontend |
+| Full-stack | arquitecto, disenador-api, desarrollador-backend, desarrollador-frontend |
+| Infra/Deploy | arquitecto, operaciones |
+| Migración BD | arquitecto, asesor-datos |
+| Refactor | arquitecto, revisor (asesor) |
+| Crítico/Seguridad | + seguridad |
+
+Si algún agente requerido está desactivado en config, AVISAR al usuario:
+> ⚠️ Esta tarea se beneficiaría del agente `seguridad`, pero está desactivado en config. ¿Activarlo solo para este plan?
+
+## PASO 3 — Invocar agentes en orden
+
+Invoca cada agente con el contexto relevante usando la herramienta `Task`. Cada agente devuelve su sección del plan.
+
+Orden estándar:
+1. **arquitecto** → estructura general, decisiones técnicas, archivos afectados
+2. **disenador-api** → contratos de API (si aplica)
+3. **asesor-datos** → modelo de datos, queries, índices (si aplica)
+4. **desarrollador-backend** → revisa factibilidad técnica de backend
+5. **desarrollador-frontend** → revisa factibilidad técnica de frontend
+6. **operaciones** → necesidades de infra/deploy (si aplica)
+7. **critico** → riesgos y puntos ciegos
+8. **seguridad** → consideraciones de seguridad (si aplica)
+
+Cada agente recibe:
+- La spec completa
+- La constitución
+- Su sección previa del plan (si ya existe)
+- Las secciones generadas por agentes anteriores en este ciclo
+
+## PASO 4 — Generar el plan completo
+
+Lee plantilla `plantillas/plan.md`. Si no existe, usa esta estructura:
+
+```markdown
+---
+spec_id: {SPEC_ID}
+plan_id: {SPEC_ID}-plan
+estado: pendiente_aprobacion
+creado: {FECHA}
+constitucion_version: {VERSION}
+agentes_participantes: [arquitecto, ...]
+---
+
+# Plan Técnico: [TÍTULO_SPEC]
+
+## 1. Resumen Ejecutivo
+
+[3-5 frases. Qué se va a construir técnicamente, con qué tecnología, en qué archivos principales.]
+
+## 2. Verificación de Constitución (Constitution Check)
+
+Antes de implementar, verifica:
+
+| Principio | Cumple | Justificación |
+|-----------|--------|--------------|
+| [Principio I] | ✅/❌/⚠️ | [explicación] |
+| [Principio II] | ✅ | [explicación] |
+
+> Si hay ❌ o ⚠️: debe documentarse en sección "Complejidad Justificada" o detenerse el plan.
+
+## 3. Enfoque Técnico
+
+[2-4 párrafos del enfoque elegido y por qué.]
+
+## 4. Decisiones Técnicas (ADRs implícitos)
+
+| # | Decisión | Opción elegida | Alternativas descartadas | Razón |
+|---|----------|---------------|--------------------------|-------|
+| 1 | [decisión] | [opción] | [otras] | [razón técnica concreta] |
+
+> Decisiones no triviales también se documentan como ADR en `.sdd/arquitectura/`.
+
+## 5. Estructura de Carpetas Afectada
+
+```
+[Diagrama de árbol mostrando dónde van los archivos nuevos]
+```
+
+## 6. Archivos Afectados
+
+| Acción | Ruta | Propósito | Agente responsable |
+|--------|------|-----------|--------------------|
+| CREAR | `ruta/archivo.ext` | [qué hace] | desarrollador-backend |
+| MODIFICAR | `ruta/existente.ext` | [qué cambia y por qué] | desarrollador-backend |
+| ELIMINAR | `ruta/obsoleto.ext` | [por qué] | — |
+
+## 7. Modelo de Datos
+
+### Entidades nuevas
+```[lenguaje]
+// Tipos / interfaces / schemas
+```
+
+### Cambios en entidades existentes
+[Migraciones requeridas, compatibilidad hacia atrás]
+
+### Queries críticas
+[SQL/NoSQL queries importantes con justificación de índices]
+
+## 8. Contratos de API
+
+### Endpoints / Operaciones nuevas
+```yaml
+# OpenAPI / GraphQL schema / proto / etc según stack
+```
+
+### Cambios en endpoints existentes
+[Breaking? Si sí, plan de migración]
+
+### Eventos / Mensajes (si aplica)
+[Topics, formatos, idempotencia]
+
+## 9. Estrategia de Tests
+
+### Tests unitarios
+- Qué unidades se testean
+- Mocks necesarios
+- Cobertura objetivo
+
+### Tests de integración
+- Qué integraciones se prueban
+- Setup requerido
+
+### Tests E2E (si aplica)
+- Flujos críticos a cubrir
+
+### Tests de regresión
+- Tests existentes que pueden romperse
+
+## 10. Dependencias Nuevas
+
+| Paquete | Versión | Justificación | Alternativas consideradas |
+|---------|---------|--------------|---------------------------|
+| [paquete] | [versión] | [por qué se necesita] | [otras opciones y por qué no] |
+
+> ⚠️ Cada dependencia nueva debe justificarse. Preferir cero dependencias nuevas si es posible.
+
+## 11. Riesgos Técnicos
+
+| # | Riesgo | Probabilidad | Impacto | Mitigación |
+|---|--------|--------------|---------|-----------|
+| 1 | [riesgo] | A/M/B | A/M/B | [acción concreta] |
+
+## 12. Plan de Implementación en Fases
+
+### Fase 1: Fundamentos
+[Tipos, interfaces, schemas, migraciones]
+
+### Fase 2: Capa de datos
+[Repositorios, queries, acceso a datos]
+
+### Fase 3: Lógica de negocio
+[Servicios, casos de uso]
+
+### Fase 4: Interfaz / API
+[Controllers, handlers, UI]
+
+### Fase 5: Integración
+[Conexiones, tests E2E]
+
+### Fase 6: Verificación
+[Tests cruzados, cumplimiento de spec]
+
+## 13. Cambios Breaking
+
+[Lista de cambios que rompen compatibilidad. Vacío si ninguno.]
+
+| Qué rompe | Quién afectado | Plan de migración |
+|-----------|---------------|-------------------|
+
+## 14. Métricas y Observabilidad
+
+[Qué hay que loguear / métricas a exponer / alarmas a configurar]
+
+## 15. Complejidad Justificada
+
+[Solo si hay desviaciones de la constitución que se justifican.]
+
+| Desviación | Justificación | Cuándo revisar |
+|-----------|--------------|----------------|
+
+## 16. Estimación
+
+- Complejidad global: [Baja / Media / Alta]
+- Tareas estimadas: [N]
+- Esfuerzo equivalente humano: [horas/días aproximados]
+
+## 17. Aportes por Agente
+
+### Arquitecto
+[Resumen de las decisiones de alto nivel]
+
+### Diseñador de API (si aplica)
+[Resumen del diseño de contratos]
+
+### Asesor de datos (si aplica)
+[Resumen de decisiones de BD]
+
+### Crítico
+[Riesgos principales identificados]
+
+### Seguridad (si aplica)
+[Consideraciones de seguridad]
+```
+
+## PASO 5 — Verificación de Constitución (Constitutional AI Constraint)
+
+Antes de presentar el plan al usuario, aplica el skill `constitucion-constraint`:
+
+1. Carga solo las restricciones relevantes para el tipo de cambio (arquitectura, stack, seguridad, API — según qué agentes participaron)
+2. Evalúa cada restricción aplicable contra el plan generado
+3. Si hay incumplimiento de un principio `DEBE`/`NUNCA`: **detén el plan** y reporta al usuario antes de continuar
+4. Si hay desviación justificable: documenta en sección "Complejidad Justificada" y continúa con advertencia visible
+5. Incluye el reporte del constraint check en el PASO 8 (solicitud de aprobación)
+
+> Este check es una restricción dura, no una sugerencia. Un plan que viola la constitución sin justificación no puede avanzar a tareas.
+
+## PASO 6 — Guardar el plan
+
+```bash
+# Guardar plan principal
+cat > "${SPEC_DIR}/plan.md" << 'EOF'
+[contenido generado]
+EOF
+
+# Si hubo decisiones técnicas no triviales, generar ADRs
+# Cada ADR va en .sdd/arquitectura/YYYY-MM-DD-titulo.md
+```
+
+## PASO 7 — Actualizar índice
+
+```bash
+# Actualizar entrada de INDICE.md: "plan: ✅"
+```
+
+## PASO 8 — Pedir aprobación del plan
+
+Si `comportamiento.requerir_aprobacion_plan: true` en config:
+
+```
+📋 Plan técnico generado
+📁 .sdd/especificaciones/{ID}/plan.md
+🤖 Agentes participantes: [lista]
+
+RESUMEN:
+   • [N] archivos afectados
+   • [M] dependencias nuevas
+   • [K] decisiones técnicas
+   • [J] riesgos identificados
+
+⚠️  PUNTOS DESTACADOS:
+   [Cualquier riesgo alto o decisión importante que el usuario debe revisar]
+
+POR FAVOR REVISA EL PLAN. Cuando estés listo:
+   /sdd.planificar aprobar         — continuar al desglose en tareas
+   /sdd.planificar revisar         — discutir cambios al plan
+   /sdd.analizar                   — auditoría de consistencia primero
+```
+
+## PASO 9 — Aprobación (si el usuario escribió "aprobar")
+
+```bash
+# Actualizar plan: estado: aprobado
+# Actualizar .sdd/estado.json: plan_aprobado: true
+# Actualizar INDICE.md
+```
+
+```
+✅ Plan aprobado
+📁 .sdd/especificaciones/{ID}/plan.md
+
+SIGUIENTE PASO:
+   /sdd.tareas        — desglose en tareas atómicas implementables
+```
+
+## VALIDACIÓN DE SALIDA
+
+Antes de presentar el plan al usuario, verifica su integridad estructural:
+
+```bash
+SPEC_ID=$(grep -o '"especificacion_activa": "[^"]*"' .sdd/estado.json 2>/dev/null | cut -d'"' -f4)
+PLAN_FILE=".sdd/especificaciones/${SPEC_ID}/plan.md"
+
+# Estructura mínima requerida
+grep -q "## 2. Verificación de Constitución" "$PLAN_FILE" || echo "FALTA: Constitution Check"
+grep -q "## 4. Decisiones Técnicas"          "$PLAN_FILE" || echo "FALTA: Decisiones Técnicas"
+grep -q "## 6. Archivos Afectados"           "$PLAN_FILE" || echo "FALTA: Archivos Afectados"
+grep -q "## 11. Riesgos Técnicos"            "$PLAN_FILE" || echo "FALTA: Riesgos Técnicos"
+grep -q "## 12. Plan de Implementación"      "$PLAN_FILE" || echo "FALTA: Plan de Fases"
+
+# No debe haber incumplimientos de constitución sin justificación
+INCUMPL=$(grep -c "❌" "$PLAN_FILE" 2>/dev/null || echo 0)
+[ "$INCUMPL" -gt 0 ] && grep -q "## 15. Complejidad Justificada" "$PLAN_FILE" \
+  || echo "ADVERTENCIA: hay ❌ en Constitution Check sin sección Complejidad Justificada"
+
+# El frontmatter debe existir
+grep -q "^spec_id:" "$PLAN_FILE"  || echo "FALTA: spec_id en frontmatter del plan"
+grep -q "^estado:" "$PLAN_FILE"   || echo "FALTA: estado en frontmatter del plan"
+
+echo "Validación completada"
+```
+
+Si falta alguna sección requerida, complétala antes de pedir aprobación.
+
+## VERIFICACIONES POST-EJECUCIÓN
+
+```bash
+[ -f ".sdd/hooks/despues_planificar.sh" ] && bash .sdd/hooks/despues_planificar.sh
+```

package/commands/sdd.qa.md

@@ -0,0 +1,108 @@
+---
+description: Prueba el producto en un navegador real generando casos E2E a partir de los Criterios de Aceptación de la spec activa. Va más allá de los tests unitarios: comprueba que el usuario final puede hacer lo prometido. Usa un MCP de navegador (Playwright).
+allowed-tools: Read, Write, Edit, Bash
+handoffs:
+  - etiqueta: "Verificar contra la spec"
+    comando: sdd.verificar
+  - etiqueta: "Desplegar"
+    comando: sdd.desplegar
+---
+
+# /sdd.qa — QA en Navegador Real
+
+Eres el **Ingeniero de QA**. No te conformas con que los tests unitarios pasen: compruebas que el producto funciona de verdad para una persona que lo usa. Inspirado en `/qa` de gstack (navegador real, casos generados desde los requisitos).
+
+## Requisito — MCP de navegador
+
+Este comando usa un servidor MCP de navegador (Playwright / Chrome DevTools) para manejar un navegador real. Si no está disponible:
+
+```bash
+command -v npx >/dev/null 2>&1 && echo "npx OK"
+# El MCP de Playwright se declara en plugin.json (mcpServers.navegador).
+# Si no hay MCP de navegador, degrada a tests E2E con el runner del proyecto
+# (Playwright/Cypress) en vez de control interactivo.
+```
+
+Si no hay MCP ni runner E2E, informa al usuario qué falta y ofrece generar solo los **casos de prueba** (sin ejecutarlos) para que los corra él.
+
+## PASO 1 — Cargar spec activa y perfil
+
+```bash
+PERFIL=$(grep -o '"perfil": *"[^"]*"' .sdd/estado.json 2>/dev/null | cut -d'"' -f4)
+SPEC_ID=$(grep -o '"especificacion_activa": "[^"]*"' .sdd/estado.json 2>/dev/null | cut -d'"' -f4)
+SPEC_FILE=".sdd/especificaciones/${SPEC_ID}/spec.md"
+
+# Extraer los criterios de aceptación
+grep -E "CA-[0-9]" "$SPEC_FILE" 2>/dev/null
+```
+
+Cada **Criterio de Aceptación** es la fuente de un caso de prueba E2E.
+
+## PASO 2 — Determinar la URL bajo prueba
+
+```bash
+# Local (dev server) o desplegado
+URL_LOCAL="http://localhost:[puerto]"   # detecta el puerto del proyecto
+URL_DEPLOY=$(grep -o 'https\?://[^"]*' .sdd/estado.json 2>/dev/null | head -1)
+```
+
+Prioriza el entorno que el usuario indique. Si va a probar local, asegúrate de que el servidor de desarrollo esté arriba (o levántalo).
+
+## PASO 3 — Generar casos de prueba desde los CAs
+
+Por cada CA, genera un caso E2E con pasos concretos de navegador. Ejemplo a partir de `CA-001-01: POST /tareas crea una tarea con título`:
+
+```
+Caso QA-001 (cubre CA-001-01): Crear una tarea
+  1. Abrir [URL]
+  2. Escribir "Comprar pan" en el campo de nueva tarea
+  3. Pulsar "Agregar"
+  4. Esperar que "Comprar pan" aparezca en la lista
+  ✓ Resultado esperado: la tarea aparece visible en la lista
+```
+
+Cubre también los **caminos de error** que los CAs definan (ej. `CA-001-05: sin título → error`).
+
+## PASO 4 — Ejecutar en navegador real (vía MCP)
+
+Usa las herramientas del MCP de navegador para ejecutar cada caso: navegar, rellenar campos, hacer clic, leer el DOM/screenshot, y aseverar el resultado esperado. Registra para cada caso: PASA / FALLA + evidencia (texto encontrado o screenshot).
+
+> Regla del proyecto: verificar revisando, no abrir el navegador manualmente. El MCP automatiza el navegador; tú lees el resultado que devuelve, no haces capturas a mano.
+
+## PASO 5 — Reportar resultados
+
+Escribe `.sdd/especificaciones/${SPEC_ID}/qa.md` y muestra:
+
+```
+🧪 QA en navegador real — [URL]
+
+   CA-001-01  Crear tarea            ✅ PASA
+   CA-001-02  Listar ordenadas        ✅ PASA
+   CA-001-03  Marcar completa         ✅ PASA
+   CA-001-05  Error sin título        ✅ PASA  (mostró el mensaje esperado)
+   CA-001-06  404 si no existe        ❌ FALLA (devolvió 500)
+
+   5/6 casos pasaron · 1 fallo
+```
+
+Si hay fallos:
+- **experto**: lista el CA fallido + qué se esperaba vs qué pasó.
+- **guiado**: *"Probé tu producto como lo haría una persona. Casi todo funciona; encontré un detalle que falla y lo voy a arreglar antes de seguir."* — y corrige antes de continuar.
+
+## VALIDACIÓN DE SALIDA
+
+```bash
+SPEC_ID=$(grep -o '"especificacion_activa": "[^"]*"' .sdd/estado.json 2>/dev/null | cut -d'"' -f4)
+QA_FILE=".sdd/especificaciones/${SPEC_ID}/qa.md"
+
+# Debe existir el reporte y cubrir cada CA con un caso
+grep -q "QA en navegador" "$QA_FILE" 2>/dev/null || echo "FALTA: reporte de QA"
+N_CAS=$(grep -cE "CA-[0-9]" ".sdd/especificaciones/${SPEC_ID}/spec.md" 2>/dev/null || echo 0)
+N_CASOS=$(grep -cE "CA-[0-9]" "$QA_FILE" 2>/dev/null || echo 0)
+echo "CAs en spec: $N_CAS · CAs cubiertos por QA: $N_CASOS"
+```
+
+Cada CA debe tener al menos un caso de QA. Si falta cobertura, genera los casos restantes.
+
+---
+**HOOK:** `.sdd/hooks/despues_qa.sh`