sdd-es 2.0.0

package/skills/gestion-estado.md

@@ -0,0 +1,114 @@
+---
+description: Gestiona el estado persistente del flujo SDD entre sesiones. Lee y escribe estado.json y .estado-tareas.json. Permite reanudar exactamente donde se dejó.
+---
+
+# Skill: Gestión de Estado
+
+## Schemas
+
+### Estado global (`.sdd/estado.json`)
+
+```json
+{
+  "version_plugin": "2.0.0",
+  "version_constitucion": "1.0.0",
+  "inicializado": true,
+  "fase_actual": "implementacion",
+  "stack_detectado": { ... },
+  "especificacion_activa": "2026-06-08-feature-x",
+  "plan_aprobado": true,
+  "tareas_generadas": true,
+  "historial": [
+    {
+      "fase": "constitucion",
+      "version": "1.0.0",
+      "fecha": "2026-06-01T10:00:00Z"
+    },
+    {
+      "fase": "especificacion",
+      "id": "2026-06-08-feature-x",
+      "fecha": "2026-06-08T14:30:00Z"
+    }
+  ],
+  "fecha_inicio": "2026-06-01T10:00:00Z",
+  "ultima_actualizacion": "2026-06-08T15:00:00Z"
+}
+```
+
+### Estado de tareas por spec (`.sdd/especificaciones/{ID}/.estado-tareas.json`)
+
+```json
+{
+  "spec_id": "2026-06-08-feature-x",
+  "total": 10,
+  "completadas": 6,
+  "en_progreso": "T007",
+  "bloqueadas": 0,
+  "tareas": {
+    "T001": {
+      "estado": "completada",
+      "agente": "arquitecto",
+      "modelo": "opus",
+      "depende_de": [],
+      "cubre_cas": ["CA-001-01"],
+      "archivos_modificados": ["src/types.ts"],
+      "fecha_inicio": "2026-06-08T14:35:00Z",
+      "fecha_fin": "2026-06-08T14:50:00Z"
+    }
+  },
+  "bloqueos": {},
+  "ultima_actualizacion": "2026-06-08T15:00:00Z"
+}
+```
+
+## Operaciones
+
+### leer_estado_global()
+```bash
+cat .sdd/estado.json 2>/dev/null || echo '{"inicializado": false}'
+```
+
+### actualizar_estado_global(patch)
+Lee el estado actual, hace merge con el patch, escribe de vuelta. Siempre actualiza `ultima_actualizacion`.
+
+```bash
+# Pseudocódigo
+ESTADO=$(cat .sdd/estado.json)
+NUEVO=$(echo "$ESTADO" | jq '. * $patch | .ultima_actualizacion = now | tostring' --argjson patch "$PATCH")
+echo "$NUEVO" > .sdd/estado.json
+```
+
+### obtener_spec_activa()
+```bash
+grep -o '"especificacion_activa": "[^"]*"' .sdd/estado.json | cut -d'"' -f4
+```
+
+### marcar_tarea(spec_id, tarea_id, estado, metadata)
+Actualiza `.estado-tareas.json` y la barra de progreso en `tareas.md`.
+
+### registrar_historial(fase, id, resultado)
+Añade entrada al array `historial`.
+
+## Reanudación entre sesiones
+
+Cuando un comando SDD inicia con spec activa:
+
+1. Lee estado global
+2. Lee estado de tareas de la spec activa
+3. Determina exactamente dónde quedó
+4. Ofrece reanudar:
+
+```
+🔄 Sesión anterior detectada.
+   Spec: {ID} (fase: implementacion)
+   Última tarea completada: T007
+   Tarea pendiente: T008
+
+¿Continuar desde T008?
+   sí → /sdd.implementar continuar
+   no → /sdd.estado para ver detalle
+```
+
+## Concurrencia
+
+El plugin asume **un único proceso/usuario** modificando el estado a la vez. Si necesitas multi-usuario, los hooks pueden agregar locking.

package/skills/indexador.md

@@ -0,0 +1,199 @@
+---
+description: Detecta lenguajes del proyecto y genera mapas estáticos (estructura, símbolos, dependencias) usando regex por lenguaje. Se invoca por /sdd.mapear.
+---
+
+# Skill: Indexador de Proyecto
+
+Analiza el código del proyecto sin dependencias externas (solo bash + grep + find) y genera 3 mapas estáticos en `.sdd/mapa/`.
+
+## Proceso
+
+### Paso 1: Detectar lenguajes
+
+```bash
+find . -type f -name "*.{ts,js,py,rs,go,java,cs,rb,php}" \
+  -not -path './.git/*' -not -path './node_modules/*' -not -path './.sdd/*' \
+  -not -path './dist/*' -not -path './build/*' \
+  | sed 's/.*\.//' | sort | uniq -c | sort -rn | head -5
+```
+
+Resultado: lista de lenguajes presentes + frecuencia.
+
+### Paso 2: Generar estructura.md
+
+Árbol de directorios con descripciones por archivo.
+
+Para cada archivo, extrae:
+- Ruta
+- 1 línea de descripción (automática o manual)
+
+Descripción automática por lenguaje:
+
+| Patrón de archivo | Descripción automática |
+|------------------|------------------------|
+| `*/service.ts` | Servicio: [nombre extraído] |
+| `*/controller.ts` | HTTP: [métodos detectados] |
+| `*/repo.ts`, `*/repository.ts` | Repositorio: acceso a BD |
+| `*/types.ts`, `*.types.ts` | Tipos: [enums/interfaces detectados] |
+| `*/index.ts` | Exporta símbolos públicos |
+| `auth/` | Autenticación y autorización |
+| `components/` | Componentes UI |
+| `models/` | Modelos de datos |
+| `utils/` | Utilidades y helpers |
+| `tests/`, `__tests__/`, `spec/` | Tests y specs |
+
+### Paso 3: Generar símbolos.md
+
+Símbolos públicos (funciones, clases, tipos) por archivo.
+
+Detección por lenguaje con regex:
+
+**TypeScript/JavaScript**:
+```regex
+^export (function|class|const|type|interface|enum) (\w+)
+  → extrae nombre + tipo
+  → grep -nE '^export (function|const|class|type)' archivo.ts
+```
+
+**Python**:
+```regex
+^(def|class) (\w+)
+  → funciones y clases en módulo principal
+  → grep -nE '^(def|class) ' archivo.py
+```
+
+**Rust**:
+```regex
+^(pub fn|pub struct|pub enum|pub trait)
+  → ítems públicos
+```
+
+**Go**:
+```regex
+^func ([A-Z]\w+)
+  → funciones exportadas (mayúscula inicial)
+```
+
+### Paso 4: Generar dependencias.md
+
+Extrae imports/requires/use por archivo.
+
+**TypeScript/JavaScript**:
+```regex
+^import .* from ['"]([^'"]+)['"]
+^import .* require(['"]([^'"]+)['"])
+  → extrae ruta del módulo
+```
+
+**Python**:
+```regex
+^import (\w+)
+^from (\w+) import
+```
+
+**Rust**:
+```regex
+^use (crate::|super::|std::)?(\w+)
+```
+
+Luego construye grafo:
+- archivo.ts depende de: [lista de archivos/módulos importados]
+- archivo.ts es usado por: [archivos que lo importan]
+
+Detecta dependencias circulares (A → B → A).
+
+### Paso 5: Guardar checksums
+
+Para detección de cambios:
+
+```bash
+md5sum archivo.ts > .sdd/mapa/.checksums
+```
+
+Próxima ejecución compara:
+```bash
+md5sum -c .sdd/mapa/.checksums 2>/dev/null | grep FAILED
+  → archivos modificados desde último mapeo
+```
+
+## Lógica de actualización
+
+### Primera ejecución
+- Re-indexa TODO el proyecto
+- Genera los 3 mapas + `.checksums`
+
+### Ejecuciones posteriores (sin `regenerar`)
+
+1. Compara checksums: `md5sum -c`
+2. Si hay archivos con FAILED: re-indexa solo esos
+3. Si no hay cambios: "ya fresco"
+4. Si hay archivos NUEVOS (no en checksums): indexa también
+
+### Con `regenerar`
+
+- Borra `.sdd/mapa/*` completamente
+- Empieza de cero
+- Re-indexa TODO
+
+## Errores comunes y manejo
+
+| Error | Mitigación |
+|-------|-----------|
+| Proyecto muy grande (>5000 archivos) | Capa un máximo de 2000, avisa al usuario |
+| Archivo binario en src/ | Detecta por magic bytes, lo salta |
+| Import dinámico (`require(variable)`) | Detecta patrón, marca como "???" |
+| Ruta relativa confusa (`../../`) | Resuelve a path absoluto |
+
+## Output de la skill
+
+Tres archivos `.sdd/mapa/`:
+
+```markdown
+# estructura.md
+src/
+├── auth/
+│   ├── login.service.ts        — Servicio: autenticación local+JWT
+│   ├── magic-link.service.ts   — Servicio: magic links por email
+│   └── ...
+├── users/
+│   └── ...
+└── shared/
+    └── logger.ts               — Utilidad: logger con contexto
+
+# simbolos.md
+## src/auth/login.service.ts
+- autenticarUsuario(email, password): Promise<Session>
+- cerrarSesion(sessionId): Promise<void>
+- type AuthResult = { session, user }
+
+## src/users/user.service.ts
+- crearUsuario(datos): Promise<User>
+- obtenerPorId(id): Promise<User>
+- ...
+
+# dependencias.md
+auth/login.service.ts
+  ↳ depende: users/user.repo.ts, shared/logger.ts, auth/session.repo.ts
+  ↳ usado por: auth/auth.controller.ts
+  ↳ importado por: [1 archivo]
+
+users/user.service.ts
+  ↳ depende: users/user.repo.ts, shared/logger.ts
+  ↳ usado por: users/user.controller.ts, auth/login.service.ts
+  ↳ importado por: [2 archivos]
+
+Acoplamientos:
+  shared/logger.ts    → 47 usos (alto, esperado)
+  errors.ts           → 23 usos (medio)
+  
+Ciclos detectados: NINGUNO ✅
+```
+
+## Limitaciones honestas
+
+- ❌ **Imports dinámicos no detectados**: `require(variable)` no se indexa
+- ⚠️ **Descripciones manuales perdidas**: si habías editado `.md`, regenerar sobrescribe. Por eso existe `.original.md`
+- ⚠️ **Lenguajes políglotas complejos**: monorepositorio con 5 lenguajes → cada uno con sus reglas
+- ❌ **Análisis de tipos**: no sigue tipos a través de funciones, solo detecta firmas
+
+Estos son trade-offs aceptables para una solución sin dependencias.

package/skills/modo-guiado/SKILL.md

@@ -0,0 +1,78 @@
+---
+name: modo-guiado
+description: Conduce el flujo SDD-ES para personas que no programan (perfil guiado). Define cómo hablar sin jerga, cuándo confirmar antes de actuar, y cómo tomar las decisiones técnicas por el usuario sin bajar el rigor. Se activa cuando estado.json o sdd.config.yaml indican perfil "guiado".
+---
+
+# Skill: Modo Guiado (para no-programadores)
+
+Esta skill cambia **cómo te comunicas**, no **qué tan bien construyes**. El producto generado mantiene los mismos estándares altos (tests, lint, sin secretos en el código, revisión independiente). Lo único que cambia es que el usuario no toma decisiones técnicas ni ve jerga.
+
+## Cuándo se activa
+
+- `estado.json` tiene `"perfil": "guiado"`, **o**
+- `sdd.config.yaml` tiene `perfil: guiado`, **o**
+- El usuario describe el producto por su función ("quiero una app que…") y no por su tecnología.
+
+Comprobación rápida:
+
+```bash
+grep -q '"perfil": *"guiado"' .sdd/estado.json 2>/dev/null && echo GUIADO
+grep -q '^perfil: *guiado' .sdd/sdd.config.yaml 2>/dev/null && echo GUIADO
+```
+
+## Reglas de comunicación (las 6 reglas)
+
+1. **Sin jerga.** Nunca digas "endpoint", "schema", "ORM", "deploy", "lint", "CI". Di "dirección donde vive el dato", "estructura de la información", "guardar en disco", "publicar en internet", "revisión automática de calidad". Si un término técnico es inevitable, defínelo en la misma frase con una analogía.
+
+2. **Confirma antes de actuar.** Antes de cada paso con consecuencias (crear archivos, instalar, publicar), explica en UNA frase qué vas a hacer y espera un "sí". Ejemplo: *"Voy a construir las pantallas y la lógica. ¿Arranco? (responde sí)"*.
+
+3. **Nunca pidas que edite archivos a mano.** El usuario no abre el editor. Si algo necesita un valor (ej. una clave de un servicio), pídeselo en lenguaje natural y tú lo colocas donde va.
+
+4. **Decide lo técnico por el usuario, y dilo.** Elige el stack, la arquitectura y las librerías. Comunica la decisión en una línea con el *porqué* en términos de beneficio, no de tecnología: *"Lo haré con una base de datos que vive en un solo archivo: así es fácil de respaldar y no necesitas instalar nada extra."*
+
+5. **Una pregunta a la vez.** Nada de cuestionarios. Pregunta lo mínimo, sigue, y vuelve a preguntar solo si hace falta.
+
+6. **Explica el resultado en términos de lo que el usuario puede hacer ahora.** Al terminar un paso: *"Ya puedes crear tareas y marcarlas como hechas. ¿Quieres que lo publiquemos en internet para usarlo desde el móvil?"* — no *"implementé el CRUD con 14 tests, cobertura 87%"*.
+
+## Cómo traducir los pasos del flujo
+
+| Paso técnico interno | Cómo lo nombras al usuario |
+|----------------------|----------------------------|
+| `/sdd.especificar` | "Voy a entender bien qué quieres" |
+| `/sdd.aclarar` | "Tengo un par de dudas para no equivocarme" |
+| `/sdd.planificar` | "Estoy decidiendo cómo construirlo" |
+| `/sdd.tareas` | (no se menciona — es interno) |
+| `/sdd.implementar` | "Lo estoy construyendo" |
+| `/sdd.qa` + `/sdd.verificar` | "Estoy probando que todo funcione de verdad" |
+| `/sdd.desplegar` | "Lo voy a publicar en internet" |
+
+## Preguntas de aclaración sin jerga
+
+Cuando `/sdd.aclarar` encuentre ambigüedades, reformúlalas en lenguaje cotidiano y con opciones concretas. En lugar de:
+
+> ¿El campo `vence_en` usa formato ISO 8601 y zona horaria UTC?
+
+di:
+
+> ¿Las tareas tienen fecha límite?
+> a) Sí, quiero ponerle una fecha a cada tarea
+> b) No, solo saber si está hecha o no
+
+## Lo que NO cambia (rigor intacto)
+
+Aunque el usuario no lo vea, en modo guiado SIEMPRE:
+
+- Se generan tests y deben pasar antes de decir "listo".
+- Se aplican lint/formato y la revisión del agente `revisor`.
+- Se respeta la constitución como restricción dura.
+- No se imprimen ni hardcodean secretos.
+- Se confirma antes de cualquier acción irreversible o hacia afuera (publicar, borrar).
+
+Si una verificación falla, NO digas "el test X falló con assertion error". Di: *"Encontré un detalle que no funcionaba bien y lo estoy corrigiendo"* — y arréglalo antes de continuar.
+
+## Cierre de cada interacción
+
+Termina siempre ofreciendo el siguiente paso como una acción en lenguaje natural, no como un comando:
+
+> ✅ Ya está. Tu lista de tareas funciona.
+> ¿Quieres que **la publique en internet** para usarla desde cualquier lado? (responde *sí*)

package/skills/orquestacion-ptc/SKILL.md

@@ -0,0 +1,96 @@
+---
+name: orquestacion-ptc
+description: Patrón Programmatic Tool Calling para despachar subagentes en paralelo y agregar solo resultados mínimos. Reduce ~85% de tokens en orquestación multi-agente. Aplica en /sdd.implementar y /sdd.analizar.
+---
+
+# Skill: Orquestación PTC (Programmatic Tool Calling)
+
+## ¿Qué es PTC?
+
+En lugar de invocar subagentes uno a uno (secuencial, cada resultado en contexto completo), el orquestador **escribe un bloque de código** que despacha todos los agentes independientes en paralelo dentro de un sandbox de Claude Code, luego **agrega solo el resumen** — estado PASA/FALLA + diff mínimo — antes de devolver el control al modelo.
+
+Resultado: −85% de tokens en orquestación con 3+ agentes independientes (referencia: PTC cookbook de Anthropic).
+
+---
+
+## Cuándo aplicar PTC
+
+### ✅ Aplica PTC cuando:
+
+1. **Tareas independientes en paralelo** — múltiples tareas de `/sdd.implementar` sin dependencias entre sí (distintos archivos, distintas capas).
+2. **Lotes de verificación** — `/sdd.analizar` corre 7 dimensiones de auditoría; las dimensiones son independientes entre sí.
+3. **Revisión multi-agente** — invocar revisor + crítico + seguridad al mismo tiempo cuando sus entradas no cambian entre sí.
+4. **Cualquier fan-out N≥3** donde los subagentes reciben el mismo contexto base y sus resultados se agregan.
+
+### ❌ NO aplica PTC cuando:
+
+1. **El siguiente paso depende del resultado del anterior** — ej. el agente arquitecto diseña, el backend implementa usando esa arquitectura. Secuencial obligatorio.
+2. **Acciones irreversibles** — deploy, escritura en BD de producción, envío de notificaciones. Confirmación explícita primero; nunca paralelizar sin gate.
+3. **El usuario debe revisar entre pasos** — si hay decisión humana en el medio, no hay PTC: es un punto de pausa.
+4. **Solo 1 o 2 agentes** — el overhead de PTC supera el beneficio; invocar directo.
+
+---
+
+## Patrón de implementación
+
+### Estructura del bloque PTC
+
+```javascript
+// Bloque PTC — orquestador despacha en paralelo
+// Entrada: lista de tareas independientes con su agente asignado
+// Salida: array [{id, estado, archivos_modificados, resumen_1_linea}]
+
+const tareas = [
+  { id: "T001", agente: "desarrollador-backend", contexto: "..." },
+  { id: "T003", agente: "tester",                contexto: "..." },
+  { id: "T005", agente: "documentador",           contexto: "..." }
+];
+
+// Despacho paralelo
+const resultados = await Promise.all(
+  tareas.map(t => invocarAgente(t.agente, t.contexto))
+);
+
+// Agregación mínima — solo PASA/FALLA + archivos
+return resultados.map((r, i) => ({
+  id: tareas[i].id,
+  estado: r.verificacion_ok ? "PASA" : "FALLA",
+  archivos: r.archivos_modificados,
+  resumen: r.primera_linea_resultado
+}));
+// El output completo de cada agente NO vuelve al modelo — solo el agregado
+```
+
+### Cuándo incluir más contexto en el agregado
+
+- Si `estado === "FALLA"`: incluir el mensaje de error completo (necesario para el retry).
+- Si hay un hallazgo de seguridad: incluir extracto, no el análisis completo.
+- Nunca incluir diffs completos de archivos en el agregado; solo lista de rutas modificadas.
+
+---
+
+## Fallback secuencial
+
+Si el entorno no soporta ejecución de código programática (sandbox no disponible, Claude Code en modo lectura, política de permisos):
+
+```
+MODO_PTC_DISPONIBLE = false
+→ ejecutar tareas en secuencia con el ciclo estándar del paso 4 de /sdd.implementar
+→ notificar al usuario: "Ejecutando en modo secuencial (PTC no disponible en este entorno)"
+```
+
+El fallback es transparente; el resultado final es idéntico, solo más lento y con más tokens.
+
+---
+
+## Cómo medirlo
+
+Antes de PTC: observar tokens de entrada en la respuesta con `/sdd.estado` + `--verbose`.
+Después de PTC: comparar para la misma spec con 3+ tareas independientes.
+Ahorro esperado: −70 a −85% en tokens de entrada del orquestador.
+
+---
+
+## Referencia
+
+Patrón documentado en: Anthropic Cookbook — "Programmatic Tool Calling" (parallel subagent dispatch + result aggregation).

package/skills/validacion-spec.md

@@ -0,0 +1,52 @@
+---
+description: Valida silenciosamente que la spec activa cumple el mínimo de calidad antes de pasar a la siguiente fase. Se invoca internamente.
+---
+
+# Skill: Validación de Spec
+
+## Checks mínimos (bloquean si fallan)
+
+1. **Objetivo presente**: Sección "Objetivo" no vacía
+2. **Mínimo 1 CA**: Al menos 1 ítem en criterios de aceptación
+3. **Mínimo 1 escenario**: Al menos 1 bloque Dado/Cuando/Entonces
+4. **Sin críticos pendientes**: 0 marcadores `[NECESITA_ACLARACION]` en preguntas críticas
+5. **Frontmatter válido**: YAML bien formado con `id`, `titulo`, `estado`
+
+## Checks de calidad (warnings, no bloquean)
+
+- CAs con palabras vagas ("rápido", "fácil", "bueno", "intuitivo")
+- Escenarios de error ausentes
+- Más de 5 preguntas abiertas sin resolver
+- Sin sección "Fuera de Alcance"
+- Sin métricas de éxito medibles
+- Sin actores definidos
+
+## Implementación (pseudocódigo)
+
+```bash
+SPEC_FILE=".sdd/especificaciones/$(spec_activa)/spec.md"
+
+# Check 1: objetivo
+grep -A2 "## 2. Objetivo" "$SPEC_FILE" | tail -1 | grep -q '\w' || echo "FALTA_OBJETIVO"
+
+# Check 2: CAs
+grep -c "CA-[0-9]" "$SPEC_FILE" | grep -qv '^0$' || echo "SIN_CAS"
+
+# Check 3: escenarios
+grep -c "**Dado**" "$SPEC_FILE" | grep -qv '^0$' || echo "SIN_ESCENARIOS"
+
+# Check 4: marcadores críticos
+N_CRITICOS=$(grep -c "\[NECESITA_ACLARACION\]" "$SPEC_FILE")
+[ "$N_CRITICOS" -gt 0 ] && echo "$N_CRITICOS pendientes"
+
+# Check 5: frontmatter
+head -20 "$SPEC_FILE" | grep -q '^id:' || echo "FRONTMATTER_INCOMPLETO"
+```
+
+## Output
+
+Si pasa todos los críticos: continúa silenciosamente, no muestra nada.
+
+Si falla algún crítico:
+> ❌ La spec no está lista: [razón específica]
+> Usa `/sdd.aclarar` o `/sdd.checklist`.

package/skills/verificador-implementacion.md

@@ -0,0 +1,71 @@
+---
+description: Verifica que el código implementado cumple los criterios de aceptación de la spec. Lee código y tests, no asume.
+---
+
+# Skill: Verificador de Implementación
+
+Cruza el código generado contra los CAs de la spec, archivo por archivo.
+
+## Proceso
+
+### 1. Cargar contexto
+
+```bash
+SPEC_ID=$(spec_activa)
+cat ".sdd/especificaciones/${SPEC_ID}/spec.md"
+```
+
+### 2. Extraer CAs
+
+Lista todos los criterios de aceptación con su ID y descripción.
+
+### 3. Por cada CA
+
+#### 3a. Buscar implementación
+```bash
+# Identificar archivos/funciones que deberían implementar este CA
+# Usar palabras clave del CA para búsqueda fuzzy
+grep -rn "[palabras clave]" --include="*.{ext}" src/
+```
+
+#### 3b. Buscar test
+```bash
+# ¿Existe un test que verifique este CA específicamente?
+grep -rn "[descripción del CA o CA-XXX-XX]" --include="*test*" --include="*spec*"
+```
+
+#### 3c. Verificar manualmente
+Lee el código encontrado y evalúa:
+- ¿Implementa el comportamiento del CA?
+- ¿Maneja los casos borde?
+- ¿El test que lo cubre realmente valida lo que pide el CA?
+
+#### 3d. Clasificar
+- ✅ **Implementado y testeado**: hay código + test
+- ⚠️ **Implementado sin test**: hay código pero no test específico
+- ⚠️ **Implementado parcialmente**: cubre algunos casos pero no todos
+- ❌ **No implementado**: no se encontró código que lo cubra
+
+### 4. Verificar exclusiones
+
+Para cada exclusión explícita de la spec:
+- ¿Se respetó? (no se implementó funcionalidad fuera de scope)
+
+### 5. Reporte
+
+Genera tabla en `.sdd/especificaciones/{ID}/verificacion.md`:
+
+```markdown
+| CA | Descripción | Implementado | Testeado | Archivo | Test |
+|----|-------------|--------------|----------|---------|------|
+| CA-001-01 | [texto] | ✅ | ✅ | src/auth.ts:45 | tests/auth.test.ts:12 |
+| CA-001-02 | [texto] | ⚠️ | ❌ | src/auth.ts:78 | — |
+| CA-002-01 | [texto] | ❌ | — | — | — |
+```
+
+## Output
+
+Veredicto: 
+- **APROBADA**: 100% CAs implementados + tests
+- **APROBADA_CON_OBSERVACIONES**: ≥95% CAs cubiertos
+- **RECHAZADA**: <95% o tests fallando