@saulwade/swl-ses 1.4.2 → 1.5.1

package/habilidades/protocolo-revision-swl/SKILL.md

@@ -0,0 +1,276 @@
+---
+name: protocolo-revision-swl
+description: >
+  Protocolo de revisión adversarial per-task con git diff como single source of
+  truth. Adapta el patrón task-local review de cc-sdd al ecosistema SWL: los
+  revisores existentes (revisor-codigo-swl, revisor-seguridad-swl, revisor-*-swl)
+  aplican este protocolo cuando trabajan sobre una sola tarea atómica en lugar
+  de una fase completa. Devuelve APPROVED o REJECTED con findings de severidad
+  estructurados y boundary checks. Cargar desde el agente revisor cuando
+  ejecutar-fase corre en modo --iterative (task por task) o cuando se solicita
+  revisión acotada a un commit / patch específico.
+version: "1.0.0"
+herramientasPermitidas: [Read, Grep, Glob, Bash]
+exclusiones:
+  - "No cargar para revisión de fase completa multi-archivo — usar el flujo estándar del revisor con `/swl:revisar` y `/swl:verificar`."
+  - "No cargar para auditoría de seguridad profunda — usar `revisor-seguridad-swl` con `checklist-seguridad`."
+  - "No cargar como sustituto de la verificación goal-backward post-ejecución — `verificar-trabajo` cubre eso a nivel de fase."
+  - "No cargar para revisar código que no ha sido staged ni commiteado todavía — el protocolo requiere un diff o set de archivos definido."
+evolvable: true
+---
+
+# Protocolo de revisión per-task
+
+## Propósito
+
+Revisar el resultado de UNA tarea atómica de implementación (no una fase
+completa) con el rigor de un revisor adversarial. El protocolo está diseñado
+para coexistir con los revisores especializados existentes (`revisor-codigo-swl`,
+`revisor-react-swl`, `revisor-typescript-swl`, etc.): esos agentes cargan
+este skill cuando el alcance es task-local en lugar de phase-wide.
+
+Adaptado del patrón `kiro-review` de cc-sdd. Mantiene los principios de
+swl-ses (separación revisor/ejecutor de `reglas/gobernanza.md`, veto items
+y cap enforcement, scoring 9.0+ obligatorio para APPROVED).
+
+## Cuándo cargar
+
+- El orquestador ejecuta `/swl:ejecutar-fase --iterative` y necesita revisión task-por-task
+- Un agente implementador reportó `READY_FOR_REVIEW` para una sub-tarea específica
+- El usuario pide "revisa este último commit" o "revisa lo que acabo de hacer"
+- Tras una remediación de un finding previo y se necesita re-verificación acotada
+
+## Cuándo NO cargar
+
+Ver `exclusiones` en frontmatter.
+
+---
+
+## Inputs requeridos
+
+Antes de empezar, identifica los siguientes inputs. Si falta cualquiera, pide
+clarificación al caller (orquestador o implementador) en lugar de proceder
+con asunciones.
+
+| Input | Forma | Obligatorio |
+|-------|-------|-------------|
+| Task ID | Texto de la tarea desde PLAN.md (ej. "3.2 — Crear endpoint POST /facturas") | Sí |
+| Boundary scope | Lista de paths/módulos que la tarea puede modificar | Sí |
+| Spec references | IDs de requirements y design sections que la tarea satisface | Sí — si existen |
+| Diff | `git diff <base>..HEAD` o set de archivos modificados | Sí |
+| Validation commands | Comandos descubiertos por el caller (test, build, lint, smoke) | Sí — si aplica el stack |
+| Implementer status report | El reporte estructurado del ejecutor (`READY_FOR_REVIEW`, archivos tocados, decisiones) | Recomendado |
+
+---
+
+## Paso 1 — Primera acción obligatoria: `git diff`
+
+Antes de leer cualquier otro archivo, ejecuta:
+
+```bash
+git diff --stat       # alcance del cambio
+git diff <base>..HEAD # contenido real
+```
+
+El reporte del implementador NO es fuente de verdad. El diff sí. Si el diff
+es grande, lee los archivos modificados directamente — no resuamen ni inferas
+desde el reporte del ejecutor.
+
+**Por qué**: el implementador puede honestamente reportar "implementé X" pero
+haber introducido Y como efecto colateral. El diff captura todo, incluido lo
+que el ejecutor no recuerda haber tocado.
+
+---
+
+## Paso 2 — Checks mecánicos (resultado = señal primaria)
+
+Estos checks son determinísticos y producen evidencia directa. Aplica TODOS
+antes de pasar a interpretación.
+
+### Check 1: Regression safety
+
+Corre la suite de tests del proyecto con las `validation_commands` provistas.
+Ejemplo:
+
+```bash
+npm test               # o pytest, o cargo test, etc.
+```
+
+- **Tests pasan** → continuar.
+- **Tests fallan** → `REJECTED` inmediato. Incluye el conteo y nombres de tests fallidos en el reporte.
+- **Tests skipped aumentan vs base** → riesgo de regresión silenciosa (regla `monitor-ci.md`). Reportar el delta como finding de severidad MAJOR.
+
+### Check 2: Sin marcadores placeholder nuevos
+
+```bash
+git diff <base>..HEAD | grep -E "\+.*\b(TBD|TODO|FIXME|HACK|XXX)\b" || true
+```
+
+Marcadores nuevos solo se aceptan con justificación explícita en el reporte
+del implementador asociada al PLAN.md vigente (referencia a task ID, no texto suelto).
+Sin justificación → finding MAYOR.
+
+### Check 3: Sin secretos hardcodeados
+
+```bash
+git diff <base>..HEAD | grep -E "(api[_-]?key|password|secret|token)\s*[=:]\s*[\"'][^\"'\s]{8,}[\"']" -i || true
+```
+
+Cualquier match → `REJECTED` con finding CRÍTICO. Aplica los patrones
+documentados en `reglas/seguridad-agentes.md` § "Protección de secretos".
+
+### Check 4: Boundary violations
+
+Lista de archivos modificados:
+
+```bash
+git diff --name-only <base>..HEAD
+```
+
+Cada archivo modificado DEBE estar dentro del `boundary scope` declarado en
+la tarea. Si un archivo fuera del boundary aparece modificado:
+
+- Si es modificación trivial (formateo, comentario) → finding MENOR.
+- Si es modificación funcional → finding MAYOR. La tarea debe declarar el
+  boundary extendido o el cambio se devuelve al implementador para extraer
+  a una tarea aparte.
+
+---
+
+## Paso 3 — Verificación de alineación con spec
+
+Lee directamente:
+
+- El texto de la tarea en `PLAN.md` (no parafrases — copia literal).
+- Los requirements citados en el campo `requirements` de la tarea.
+- Las secciones de design citadas si existen.
+
+Para cada requirement/design ref, verifica:
+
+| Pregunta | Cómo verificar |
+|----------|----------------|
+| ¿El código implementa lo que el requirement dice? | Mapear líneas concretas del diff al texto del requirement |
+| ¿Falta algo del requirement que el código no cubre? | Listar gaps específicos |
+| ¿Hay código fuera del scope del requirement? | Comparar con design — si no está justificado, es scope creep |
+
+Si hay gap de cobertura → finding MAYOR con cita del requirement y línea
+faltante en el diff.
+
+---
+
+## Paso 4 — Veto items (heredados del revisor base)
+
+Los revisores SWL existentes declaran sus propios veto items (ver
+`reglas/gobernanza.md` § "Veto items y cap enforcement"). Cuando este
+protocolo se carga desde uno de ellos, los veto items del revisor padre
+aplican íntegros.
+
+**Si detectas CUALQUIER veto item**:
+
+- Score CAP automático a 6.0/10.
+- Verdict pasa a `REJECTED` independientemente de qué tan limpio esté el resto.
+- 2+ veto items → cap a 3.0/10.
+
+Lista de veto items del revisor padre debe estar disponible en su SKILL/agente.
+Si no se puede determinar, reporta `MANUAL_VERIFY_REQUIRED` en lugar de inventar.
+
+---
+
+## Paso 5 — Emitir veredicto estructurado
+
+### Formato del reporte
+
+```json
+{
+  "protocol": "protocolo-revision-swl",
+  "task_id": "3.2 — Crear endpoint POST /facturas",
+  "verdict": "APPROVED | REJECTED",
+  "score": 9.2,
+  "score_cap_applied": null,
+  "mechanical_checks": {
+    "regression_safety": "PASS",
+    "no_new_placeholders": "PASS",
+    "no_hardcoded_secrets": "PASS",
+    "boundary_respected": "PASS | VIOLATIONS_FOUND"
+  },
+  "spec_alignment": {
+    "requirements_covered": ["R-12", "R-13"],
+    "requirements_gap": [],
+    "design_drift": "NONE | SLIGHT | SIGNIFICANT"
+  },
+  "veto_items": [],
+  "findings": [
+    {
+      "severity": "CRITICAL | MAJOR | MINOR",
+      "file": "app/api/facturas.py:42",
+      "issue": "Descripción breve",
+      "remediation": "Qué cambiar y cómo"
+    }
+  ],
+  "summary": "Una oración resumiendo el veredicto y la razón principal.",
+  "next_action": "MERGE | FIX_AND_RE_REVIEW | ESCALATE_TO_HUMAN"
+}
+```
+
+### Reglas de scoring (compatibles con `checklist-calidad`)
+
+- `APPROVED` requiere `score >= 9.0` Y `veto_items.length === 0` Y todos los
+  mechanical_checks en PASS.
+- Severidad MAJOR baja el score 1.0 punto cada una.
+- Severidad MINOR baja 0.3 puntos cada una.
+- Severidad CRITICAL → automaticamente `REJECTED` (score irrelevante).
+- 1 veto item → cap a 6.0. 2+ veto items → cap a 3.0.
+
+### Reglas del `next_action`
+
+- `MERGE`: APPROVED — el caller (orquestador) puede commitear y avanzar a la siguiente tarea.
+- `FIX_AND_RE_REVIEW`: REJECTED con findings MAYORES — el implementador aplica remediation, se vuelve a invocar este protocolo. Máximo 2 ciclos antes de escalar.
+- `ESCALATE_TO_HUMAN`: 2 ciclos de FIX no convergieron, O hay CRÍTICO sin remediación clara, O hay decisión de scope ambigua. Activa el `notificador-swl` si está configurado.
+
+---
+
+## Persistencia del veredicto
+
+El veredicto JSON se persiste en:
+
+```
+.planning/audit/reviews/<task-id>-<timestamp>.json
+```
+
+Esto permite que `auto-evolucion-swl` y `/swl:metricas` calculen tasas de
+APPROVED vs REJECTED por agente revisor y por tipo de tarea — datos
+necesarios para identificar revisores con calibración floja o tipos de
+tarea sistemáticamente problemáticos.
+
+---
+
+## Gotchas / Errores comunes no obvios
+
+- **Confiar en el reporte del implementador como source of truth**: el primer paso obligatorio es `git diff`. Saltarse esto y derivar el veredicto del status report del implementador deja pasar bugs colaterales no reportados. Causa: optimización falsa para ahorrar tokens. Solución: `git diff --stat` siempre antes de cualquier interpretación.
+- **Boundary violation reportada como MENOR sin verificar funcionalidad**: el revisor ve que se modificó un archivo fuera del boundary y lo marca MENOR porque "se ve pequeño". Causa: no se inspeccionó qué hace el cambio. Solución: para CUALQUIER archivo fuera del boundary, abrir el cambio y clasificar trivial vs funcional antes de asignar severidad.
+- **Tests skipped tratados como tests pasados**: el conteo de tests verde no distingue entre pasados y saltados. Causa: parsing superficial del output del runner. Solución: comparar `skipped` count vs base — si aumenta sin causa documentada en el diff, es regresión silenciosa (regla `monitor-ci.md`).
+- **APPROVED con score < 9.0 "porque la tarea era pequeña"**: el revisor reduce el umbral subjetivamente. Causa: ceder a presión de entrega. Solución: la regla es 9.0 estricto; tareas pequeñas que no llegan a 9.0 indican findings que valen MENOR o MAYOR — emitir como findings y devolver al implementador.
+- **Veto items ignorados porque "el resto está limpio"**: el cap de score es no-negociable. Causa: el revisor pondera "promedio" de calidad. Solución: 1 veto item = score capped automáticamente, sin compensación posible desde otras dimensiones.
+
+---
+
+## Relación con otros componentes SWL
+
+| Componente | Relación |
+|-----------|----------|
+| `revisor-codigo-swl` y revisores de lenguaje | Cargan este skill cuando trabajan task-local en lugar de phase-wide |
+| `ejecutar-task-iterativo` (Sub-fase 4) | Invoca este protocolo después de cada implementer dispatch en modo `--iterative` |
+| `verificar-trabajo` | Complementario — verificar-trabajo es goal-backward post-fase; este protocolo es task-local post-implementación |
+| `reglas/gobernanza.md` | Veto items + cap enforcement heredados |
+| `checklist-calidad` | Score >=9.0 unificado |
+| `auto-evolucion-swl` | Consume los veredictos persistidos para detectar revisores descalibrados |
+
+## Checklist de cierre del protocolo
+
+- [ ] `git diff --stat` ejecutado y diff leído antes de cualquier interpretación
+- [ ] 4 mechanical checks ejecutados (regression, placeholders, secretos, boundary)
+- [ ] Alineación con spec verificada citando IDs concretos
+- [ ] Veto items del revisor padre evaluados
+- [ ] Score calculado y cap aplicado si corresponde
+- [ ] Veredicto JSON persistido en `.planning/audit/reviews/`
+- [ ] `next_action` claro (MERGE / FIX_AND_RE_REVIEW / ESCALATE_TO_HUMAN)

package/habilidades/tdd-workflow/SKILL.md

@@ -1,12 +1,12 @@
 ---
 name: tdd-workflow
 description: Flujo completo de Test-Driven Development. Ciclo RED (el test falla) → GREEN (implementación mínima) → REFACTOR (limpieza). Incluye cobertura mínima obligatoria, tests de frontera, factories, fixtures y estrategias para diferentes tipos de código (APIs, services, componentes Angular).
-version: "1.0.2"
+version: "1.0.3"
 evolved: true
-evolved-from: "1.0.1"
-evolved-at: "2026-05-14"
+evolved-from: "1.0.2"
+evolved-at: "2026-05-15"
 evolved-by: "aprender"
-evolved-note: "Patrón reloj inyectable (parámetro `ahora` con default Date.now()) para tests deterministas sin freezegun/jest.useFakeTimers — validado en 3 módulos sesión webhook Opción C"
+evolved-note: "Gotcha process.cwd() cacheado al require() rompe tests con process.chdir(): fix con parámetro cwd opcional + fallback dinámico. Caso real scripts/derivar-feature-list.js v1.5.0."
 herramientasPermitidas: [Read, Bash]
 evolvable: true  # default para skill estandar
 exclusiones:
@@ -330,3 +330,32 @@ assert.equal(b.consumir(5, T0 + 5000), true);      // 5 seg después: 5 tokens
 Aplica también a tests de clock skew (tiempo retrocede por NTP): pasar `T0 - 1000` y validar que la lógica no rompe. Origen: rate-limit-ip.js + webhook-dedup.js sesión 2026-05-13.
 
 **Tests nombrados por feature (`test_emitir_factura_exitosa`) pierden poder regresivo; nombrados por causa raíz (`test_repository_no_usa_columna_inexistente_p_monto`) detectan regresiones específicas sin reproducción manual** [CONFIRMADO en SIGM Opción C F1.4]: cuando se descubre un bug por una causa raíz concreta (typo en nombre de columna SQL, omisión de `selectinload`, mock que devuelve dict en vez de objeto, schema obsoleto), el test de regresión que se escribe debe llevar el nombre de la causa, no del feature afectado. Caso real: durante F1.4 de SIGM, el repository de pagos referenciaba `p.monto` cuando la columna se llamaba `p.monto_pagado`; el test escrito como `test_repository_no_usa_columna_inexistente_p_monto` falló inmediatamente en la siguiente sesión cuando otro agente reintrodujo el typo, sin necesidad de reproducir el escenario de negocio (emitir cobro real, verificar respuesta). Causa: los nombres orientados a feature (`test_pago_exitoso`) son ambiguos sobre QUÉ falla — si el test falla, el desarrollador debe diagnosticar; los nombres orientados a causa raíz (`test_X_no_usa_Y`, `test_query_incluye_selectinload_Z`, `test_service_devuelve_dict_no_objeto`) son auto-diagnósticos. Fix: para cada bug que cueste >30 min diagnosticar, escribir UN test adicional cuyo nombre describa la condición técnica violada, no el escenario de negocio. Convención: `test_<componente>_<condicion_tecnica>` o `test_<componente>_no_<anti_patron>`. Estos tests son tu segunda línea de defensa contra regresiones de la misma causa raíz, complementarios a los tests de comportamiento.
+
+**`process.cwd()` cacheado al `require()` rompe tests con `process.chdir(sandbox)`** [PATRÓN GENÉRICO TESTING CLI]: scripts Node exportables que leen `process.cwd()` en el scope del módulo (al cargar) congelan el cwd al directorio de invocación. Los tests que crean sandboxes con `fs.mkdtempSync()` y luego `process.chdir(sandbox)` no afectan al cwd cacheado — el script sigue leyendo del cwd original y los assertions fallan con paths inesperados. Caso real (swl-ses `scripts/derivar-feature-list.js` 2026-05-15): la función `enriquecerDesdeFases(fases)` leía `const CWD = process.cwd()` calculado al `require()`; 2 tests con `process.chdir(sandbox)` retornaron `[]` en lugar de detectar el PLAN.md fixture. Causa: el constante se evaluó cuando el `node --test` cargó el módulo desde el cwd del proyecto, no desde el sandbox del test individual. Fix obligatorio: funciones exportables deben aceptar `cwd` como parámetro opcional con fallback dinámico (`function fn(args, opciones = {}) { const cwd = opciones.cwd || process.cwd(); ... }`). El código de producción no cambia (sin args extras), pero los tests pueden inyectar el cwd correcto. Aplica también a Python (`def fn(args, cwd: str | None = None): cwd = cwd or os.getcwd()`) y a cualquier lenguaje con tests que usen chdir.
+
+```js
+// MAL — cwd cacheado al require, tests con process.chdir() fallan
+const CWD = process.cwd();
+const PLANNING_DIR = path.join(CWD, '.planning');
+
+function enriquecerDesdeFases(fases) {
+  const archivos = fs.readdirSync(path.join(PLANNING_DIR, 'fases'));  // cwd congelado
+  // ...
+}
+
+// BIEN — cwd dinámico con parámetro opcional para tests
+function enriquecerDesdeFases(fases, opciones = {}) {
+  const cwd = opciones.cwd || process.cwd();  // recalcula al llamar
+  const archivos = fs.readdirSync(path.join(cwd, '.planning', 'fases'));
+  // ...
+}
+
+// En el test:
+const sandbox = fs.mkdtempSync(path.join(os.tmpdir(), 'test-'));
+fs.mkdirSync(path.join(sandbox, '.planning', 'fases'), { recursive: true });
+// Opción A: pasar cwd explícito (recomendado)
+const r = enriquecerDesdeFases([], { cwd: sandbox });
+// Opción B: process.chdir() — solo funciona con cwd dinámico
+process.chdir(sandbox);
+const r2 = enriquecerDesdeFases([]);
+```

package/habilidades/verificar-trabajo/SKILL.md

@@ -1,12 +1,12 @@
 ---
 name: verificar-trabajo
-description: Verificación goal-backward del trabajo ejecutado en 4 niveles progresivos — EXISTE, SUSTANTIVO, CONECTADO, DATOS_FLUYEN. Detecta stubs, componentes huérfanos, integraciones rotas y flujos incompletos. Produce veredictos estructurados JSON con clasificación de riesgo (Low/Medium/High) y evidencia verificable. Soporta loop de reparación cuando el veredicto es Fail.
-version: "1.1.1"
+description: Verificación goal-backward del trabajo ejecutado en 4 niveles progresivos — EXISTE, SUSTANTIVO, CONECTADO, DATOS_FLUYEN. Clasifica claims en 4 tipos (TASK, FIX, TEST_OR_BUILD, FEATURE_GO) con evidencia proporcional. Detecta stubs, componentes huérfanos, integraciones rotas y flujos incompletos. Produce veredictos estructurados JSON con clasificación de riesgo (Low/Medium/High) y evidencia verificable. Soporta loop de reparación cuando el veredicto es Fail.
+version: "1.2.1"
 evolved: true
-evolved-from: "1.1.0"
-evolved-at: "2026-05-05"
+evolved-from: "1.2.0"
+evolved-at: "2026-05-15"
 evolved-by: "aprender"
-evolved-note: "Gotcha de la sesión SIGM 2026-05-05 (L7): tests + linter no detectan schema-seed drift; cuando el alcance toca BD, Nivel 4 obligatorio con docker compose down -v && up fresco"
+evolved-note: "Gotchas v1.5.1 acumulados en este ciclo: (1) health-check post-hoc que recalcula contexto del install desde cwd actual → falso positivo (caso doctor 2026-05-15); (2) smoke E2E obligatorio para features cross-cutting (Sub-fase 11.5: transformarAgente nunca invocado pese a suite 100% verde); (3) auto-reparación debe verificar que el chequeo subsecuente ya no detecta el problema, si no → loop infinito (Sub-fase 12: doctor)."
 herramientasPermitidas: [Read, Write, Edit, Bash, Glob, Grep]
 exclusiones:
   - "No cargar durante la implementación activa de una tarea; la verificación es posterior a la implementación, no concurrente."
@@ -60,6 +60,50 @@ El skill `verificacion-evidencia` tiene el detalle completo de este protocolo.
 
 ---
 
+## Taxonomía de claims (clasifica ANTES de verificar)
+
+El nivel de evidencia requerido depende del tipo de claim que se quiere validar.
+Antes de aplicar los 4 niveles, identifica qué clase de claim estás verificando.
+
+Inspirado en `kiro-verify-completion` (cc-sdd) — ver `temp/cc-sdd-main/tools/cc-sdd/templates/agents/claude-code-skills/skills/kiro-verify-completion/SKILL.md`.
+
+### Los 4 tipos de claim
+
+| Claim type | Cuándo aplica | Evidencia mínima obligatoria |
+|------------|---------------|-------------------------------|
+| **TASK** | "Esta tarea está completa" — una sub-tarea atómica del PLAN.md | Niveles 1-3; tests locales de la tarea pasan; sin findings de revisor bloqueantes; evidencia alineada al boundary de la tarea |
+| **FIX** | "Este bug está arreglado" — corrección de un defecto reportado | Síntoma original reproducido antes del fix + ya no se reproduce después; sin regresiones en el scope relevante |
+| **TEST_OR_BUILD** | "Los tests pasan" / "el build pasa" — claim mecánico | Output literal del comando + exit code 0; conteo de pass/fail/skipped explícito; NO inferir desde checks no relacionados |
+| **FEATURE_GO** | "Esta feature/fase está lista para producción" — claim de cierre mayor | Suite de tests completa verde + smoke test runtime (la app realmente arranca a estado usable) + cobertura de requisitos evaluada + alineación end-to-end con design + integración cross-task verificada |
+
+### Reglas duras
+
+1. **Identifica el claim type ANTES** de seleccionar evidencia. No reverse-engineer "qué tipo es" desde la evidencia que ya tienes.
+2. **Rechaza claims más amplios que la evidencia**. Si solo verificaste una tarea (TASK), no puedes emitir FEATURE_GO. Reporta el alcance real.
+3. **Para TEST_OR_BUILD**: la evidencia es el output del comando, no la inferencia. Si los tests pasan pero hay 47 skipped por preconditions falsas, NO es un Pass limpio — reporta los skipped como riesgo (ver regla `monitor-ci.md` § "verde con N skipped").
+4. **Para FEATURE_GO**: un test suite verde NO basta. Requiere también smoke runtime, cobertura de requisitos y alineación end-to-end.
+5. **Si la validación canónica no puede completarse** (sin BD disponible, sin red, sin runtime), retorna `MANUAL_VERIFY_REQUIRED` en lugar de inventar evidencia.
+
+### Mapeo a salidas del veredicto
+
+El claim type se incluye en el veredicto estructurado JSON:
+
+```json
+{
+  "claim_type": "TASK | FIX | TEST_OR_BUILD | FEATURE_GO",
+  "claim_text": "Tarea 3.2 — Crear endpoint POST /facturas",
+  "verdict": "VERIFIED | NOT_VERIFIED | MANUAL_VERIFY_REQUIRED",
+  "scope_evidence_match": "exact | broader_claim_than_evidence | narrower_claim_than_evidence",
+  ...
+}
+```
+
+Si `scope_evidence_match` es `broader_claim_than_evidence`, el verdict se
+degrada automáticamente a `NOT_VERIFIED` con instrucción de re-emitir el
+claim con scope acotado.
+
+---
+
 ## Los 4 niveles de verificación
 
 ### Nivel 1 — EXISTE
@@ -296,6 +340,11 @@ estructurado JSON, ver [recursos/plantilla-verificacion.md](recursos/plantilla-v
 - **Loop de reparación sin re-verificación completa**: tras el fix, el agente re-verifica solo el item que falló en lugar del veredicto completo. Causa: optimización incorrecta para ahorrar tiempo. Solución: el paso 3 del loop de reparación dice explícitamente "re-ejecutar la verificación COMPLETA" — un fix puede resolver un fallo pero introducir otro.
 - **Hollow Component no detectado en Nivel 2**: el componente Angular tiene template pero no usa ninguna señal del componente. El agente verifica que el archivo existe (Nivel 1) y que tiene contenido (Nivel 2), pero no detecta que el contenido es decorativo. Causa: la definición de "stub" en Nivel 2 no se aplicó al caso de templates sin binding. Solución: verificar explícitamente que el template usa al menos una variable/señal del componente.
 - **Verificación con tests + linter pasa pero al levantar BD fresca todo se rompe**: tests Python con mocks y `ruff check` retornan verde, pero `docker compose down -v && up` falla porque hay drift entre `database/schemas/`, seeds, funciones SQL y vistas. Caso real (SIGM 2026-05-04): primera pasada de `/swl:verificar` reportó "APROBADO 21/22" sin detectar que ~10 seeds tenían columnas obsoletas, UUIDs inválidos y un script `02-crear-buckets-minio.sh` que abortaba initdb del contenedor postgres. Causa: la verificación corre solo contra el código (que mockea BD); nunca aplica el SQL real. Solución: cuando el alcance toca cualquier archivo en `database/schemas/`, `database/seeds/`, `database/functions/` o `database/views/`, ejecutar como Nivel 4 (DATOS_FLUYEN) obligatorio: `docker compose down -v && docker compose up -d db && wait_for_health && docker logs <db_container> | grep -E "ERROR|skipped"`. Cualquier ERROR en logs de init invalida el veredicto Pass.
+- **Health-check post-hoc que recalcula contexto del install desde cwd actual produce falso positivo**: un verificador (doctor, validador, monitor) que recalcula filtros — aplicados al momento del install — desde el `process.cwd()` actual genera discrepancia falsa cuando se ejecuta desde un dir distinto. Caso real (swl-ses doctor v1.4.3, 2026-05-15): reportaba "reglas: 65 (perfil esperaba 25)" porque recalculaba `filtrarReglasPorStack(detectarStack(cwd))` con `cwd` vacío de indicadores, mientras las 40 reglas-lenguajes se habían instalado correctamente con stack detectado en el dir del proyecto. Causa: el filtro depende del contexto del momento del install, no del momento del check. Solución obligatoria: **persistir el contexto del install en el state file** (en este caso `allLangs` + `stackInstalado` en `.swl-install-state.json`). Si el state es legacy (sin estos campos), **inferir el contexto desde los archivos realmente instalados** (ej: subdirs presentes bajo `reglas/lenguajes/<lang>/`), NO recalcular desde cwd. Aplica como regla general a cualquier check post-hoc cuya validez depende del contexto del install.
+
+- **Suite 100% verde con bug latente cross-cutting que solo aparece en smoke E2E real**: las unit tests del transformador pasaban, los tests del instalador pasaban, los tests del manifiesto pasaban — pero el smoke `install --target codex --local --force` reveló que `instalarArchivo()` hacía `fs.copyFileSync(archivo.origen, destino)` literal sin invocar `transformarAgente()`. Los `.toml` de Codex y los `.md` normalizados de Cursor NUNCA se generaban en disco aunque las unit tests del transformador retornaran contenido correcto. Caso real (Sub-fase 11.5 v1.5.1, 2026-05-15): la integración de las dos capas (transformador + instalador) jamás se testeaba E2E porque cada una se probaba en aislamiento con mocks. **Regla obligatoria para features cross-cutting** (multi-capa: transformador + instalador + filesystem; o lib + bin + cliente; o backend + frontend + cache): el Nivel 4 DATOS_FLUYEN exige al menos un smoke E2E real que ejercite las tres capas con archivos reales en disco temporal. NO sustituible por unit tests aunque la suite sea 100% verde. Comando mínimo: `mkdir tmp && cd tmp && bin/CLI <comando-happy-path> && ls -R` + inspección del primer archivo generado.
+
+- **Auto-reparación ejecuta acción sin verificar que el chequeo subsecuente ya no detecta el problema**: el doctor reporta "faltan reglas: 0/25" en Codex, el usuario elige "reparar automáticamente", el doctor invoca `instalador.install({force:true})`, reinstala 230 archivos, vuelve a chequear y reporta lo mismo. Loop infinito. Caso real (Sub-fase 12 v1.5.1, 2026-05-15): los 4 falsos positivos del doctor sobre Codex/Cursor persistían tras cada "reparación" porque la causa raíz era un filtro hardcoded (`tiposPrincipales = ['agentes', 'habilidades', 'comandos', 'reglas']` sin respetar `runtime.tiposSoportados` ni `dir<Tipo>`). Cada reinstalación dejaba el filtro intacto, el chequeo seguía detectando el "problema". **Regla**: toda función de auto-reparación debe ejecutar el chequeo subsecuente ANTES de reportar "Reparado" — si el chequeo sigue detectando el problema, NO marcar como reparado y reportar "no se pudo reparar, requiere diagnóstico manual". Implementación: wrap la acción en `try { accion(); const res = chequeo(); if (!res.ok) throw new Error('reparación sin efecto'); }`.
 
 ## Regla de oro del verificador