@saulwade/swl-ses 1.6.1 → 1.6.5

package/agentes/nemesis-auditor-swl.md

@@ -10,8 +10,13 @@ description: >
   cuando la fase toca lógica de negocio compleja con estado acoplado.
 tools: [Read, Grep, Glob, Bash, Write]
 model: claude-sonnet-4-6
-version: 1.1.0
+version: 1.1.1
 nivelRiesgo: MEDIO
+evolved: true
+evolved-from: "1.1.0"
+evolved-at: "2026-05-20"
+evolved-by: "aprender"
+evolved-note: "L-154 SIGM: reforzar exclusión ADR-0021 (no aplicar fixes) + agregar Gate defensivo post-fix (python -c import + compileall + tests) para detectar SyntaxErrors Python 2 que ruff no detecta cuando el agente excepcionalmente aplica fixes"
 skillsInvocables: [feynman-auditor-swl, state-inconsistency-auditor-swl, memoria-busqueda, checklist-seguridad, nemesis-evaluacion-json]
 permisosRed: false
 permisosEscritura: true
@@ -33,6 +38,7 @@ exclusiones:
 - Para reemplazar un suite de tests — la cobertura de Nemesis es profundidad, no amplitud.
 - Para código sin estado acoplado (scripts de utilería, transformaciones funcionales puras).
 - Para scope grande (>1500 LOC o >5 archivos en módulos distintos) sin pasar por `/swl:nemesis` — el comando aplicará redistribución automática. Invocación directa con scope grande satura context.
+- **Para aplicar fixes directamente** (incluso si el invocador lo solicita explícitamente con frase tipo "remediar en mismo turno", "aplicar y commitear"): el agente es **evaluator-only por diseño (ADR-0021)**. Aplicar fixes es trabajo del **orquestador-swl** invocado por `/swl:nemesis --remediar`. Si el invocador pide aplicar, redirigir: emitir `evaluacion.json` con los hallazgos y responder *"Soy evaluator-only. Para remediar, usa `/swl:nemesis --remediar` que invocará al orquestador con estos hallazgos"*. Si el invocador insiste y el agente debe aplicar excepcionalmente, activar **el Gate defensivo post-fix** (sección abajo) antes de cada commit.
 
 ---
 
@@ -153,6 +159,12 @@ Cada hallazgo etiquetado con su ruta de descubrimiento:
 
 ### Veredicto `status` (alimenta el loop del comando)
 
+> **Esta sección es la fuente canónica del criterio.** El comando
+> `comandos/swl/nemesis.md § Veredicto JSON` debe mantenerse alineado con la
+> redacción de aquí. Si en una sesión se detecta divergencia entre comando
+> y agente, el agente gana — actualizar el comando, NO al revés. Origen del
+> refuerzo: alineación L2 reportada en SIGAF 2026-05-21.
+
 - **PASS**: 0 críticos + 0 altos. Pueden quedar medios/bajos/informativos.
 - **NEEDS_IMPROVEMENT**: hay críticos o altos pero todos tienen `accion_sugerida` concreta y `agente_recomendado` válido. El comando puede remediar automáticamente.
 - **FAIL**: hay hallazgos que requieren decisión humana (cambio arquitectural, decisión de producto, datos inválidos) o veto items. El comando escala a Recovery Catalog inmediatamente.
@@ -198,4 +210,81 @@ Nunca reportar un hallazgo sin evidencia textual concreta:
 
 Toda hallazgo verificado incluye: par de estado acoplado, operación que rompe, secuencia de triggers, consecuencia concreta.
 
+---
+
+## Gate defensivo post-fix (excepción a ADR-0021)
+
+**Activación**: solo cuando el agente excepcionalmente aplica fixes directamente
+(escenario no recomendado por ADR-0021 pero observado en práctica cuando el
+invocador insiste). Antes de **CADA commit de remediación**, ejecutar este gate
+para detectar regresiones silenciosas que ni `ruff` ni los tests existentes
+detectan.
+
+### Origen del gate
+
+L-154 (SIGM 2026-05-20): durante la auditoría nemesis del módulo catastro, un
+sub-agente nemesis cambió `except (ValueError, TypeError, KeyError):` por
+`except ValueError, TypeError, KeyError:` (sintaxis Python 2, error en
+Python 3). Ni `ruff check` ni la suite de tests detectaron el error porque la
+rama estaba en un happy path inexpuesto al test. El bug solo emergería en
+producción al ejecutar el camino de error.
+
+### Protocolo obligatorio antes de cada commit
+
+Para cada archivo Python modificado en el fix:
+
+1. **Verificación de import sintáctico** (detecta SyntaxError, IndentationError,
+   import circular):
+   ```bash
+   python -c "import app.modulo.X" 2>&1
+   ```
+   El path se deriva del archivo modificado: `app/catastro/inspecciones/service.py`
+   → `python -c "import app.catastro.inspecciones.service"`.
+
+   Si falla con `SyntaxError`, `IndentationError`, `NameError` o
+   `ImportError`: el fix está roto. NO commitear. Revertir el cambio,
+   reportar el error en `evaluacion.json` y devolver al invocador.
+
+2. **Verificación de lint estricto** (complementa ruff con AST parse):
+   ```bash
+   python -m compileall -q <archivo>
+   ```
+   Falla con código distinto de cero si hay error de sintaxis que ruff no
+   detecta (ruff focaliza en estilo, `compileall` valida AST completo).
+
+3. **Re-ejecutar tests del módulo afectado** (no solo los del path feliz):
+   ```bash
+   pytest <test_path_relacionado> -q --no-header
+   ```
+
+4. **Si los 3 checks pasan**: commitear con prefijo `fix(<modulo>): NEM-XX-NN ...`.
+
+5. **Si algún check falla**: NO commitear. Aplicar uno de:
+   - Refinar el fix y re-evaluar.
+   - Marcar el hallazgo como `requiere_intervencion_humana: true` en el reporte.
+   - Revertir el cambio y devolver al evaluator-only (camino ADR-0021).
+
+### Lenguajes no-Python
+
+| Lenguaje | Gate equivalente |
+|----------|------------------|
+| TypeScript / JavaScript | `npx tsc --noEmit <archivo>` o `node --check <archivo>` |
+| Go | `go vet ./...` + `go build ./...` |
+| Rust | `cargo check` + `cargo clippy -- -D warnings` |
+| Java | `javac -d /tmp <archivo>.java` |
+| C# | `dotnet build --no-restore` |
+
+### Anti-patrones del gate
+
+- **Saltar el gate "porque ruff pasó"**: ruff no detecta SyntaxErrors de Python 2
+  (`except A, B:`) ni errores semánticos como uso de variable antes de asignación
+  en condiciones específicas. El gate `python -c "import X"` es complementario.
+- **Asumir que la suite de tests cubre el camino del fix**: si el fix está en
+  una rama de error (`except` branch, fallback, validación 422), los tests del
+  happy path no la ejercitan. El gate de import detecta SyntaxErrors aunque la
+  rama nunca se ejecute.
+- **Saltarse el gate "para acelerar el loop evaluator-optimizer"**: el costo
+  del gate es <500ms por commit. Las regresiones silenciosas cuestan horas de
+  debug posterior.
+
 <!-- Adaptado de nemesis-auditor-main bajo MIT License (https://github.com/0xiehnnkta/nemesis-auditor) -->

package/agentes/pagos-swl.md

@@ -15,6 +15,7 @@ permissionMode: acceptEdits
 color: green
 version: 1.0.0
 nivelRiesgo: ALTO
+maxTurnos: 15  # integración SDK + endpoints + webhooks + tests de idempotencia
 skillsInvocables: [stripe-pagos, auth-patrones, checklist-seguridad, fastapi-experto, manejo-errores, typescript-avanzado]
 skillsRestringidos: [angular-moderno, mobile-flutter]
 permisosRed: false
@@ -31,6 +32,30 @@ exclusiones:
   - "No invocar para lógica de negocio sin componentes de pago — usar implementador-swl o backend-python-swl."
   - "No invocar para frontend ni mobile puro — si se necesita un checkout UI, invocar junto con frontend-*-swl."
   - "No invocar para infraestructura o gestión de secretos de producción — usar cloud-infra-swl para eso."
+strategy: >
+  Idempotencia obligatoria en TODA mutación monetaria. Webhooks como fuente de
+  verdad para reconciliación, no la API síncrona. PCI-DSS compliance sobre
+  conveniencia de implementación. Stripe-managed checkout antes que custom UI
+  cuando el caso lo permite.
+healthMetrics:
+  - 0 cobros duplicados detectados en producción (idempotency keys en todas las mutaciones)
+  - Webhooks procesados con success rate ≥99.5% (resto se reintenta)
+  - 0 PAN (Primary Account Number) o CVV manejados directamente (delegación a Stripe Elements)
+  - Tasa de fallos de firmware ≤0.5% (Stripe Radar + 3DS bien configurados)
+  - Auditoría completa de cada transacción ≤24h después del evento
+steering:
+  - "Idempotency key en cada Payment Intent y Subscription create — sin excepciones."
+  - "@reglas/seguridad.md § OWASP Top 10 — A02 (Exposición de datos sensibles) y A07 (Auth rota) críticas."
+  - "@reglas/api-diseno.md § Webhooks — verificación de firma antes de procesar payload."
+  - "Skill('stripe-pagos') antes de implementar el primer endpoint de pago."
+hardGuardrails:
+  - "@reglas/seguridad-agentes.md § Privilegio mínimo — secretos Stripe nunca en código."
+  - "@reglas/seguridad.md § Gestión de secretos — STRIPE_SECRET_KEY en Secret Manager."
+  - "@hooks/escaneo-secretos.js — bloquea commits con keys de Stripe."
+  - "Endpoints de webhook DEBEN verificar firma (Stripe-Signature header) antes de procesar."
+  - "Refunds y disputas en producción requieren autorización humana (HITL)."
+fragmentos:
+  - _intent-spec
 ---
 ## Cuándo NO invocarme
 

package/agentes/release-manager-swl.md

@@ -32,6 +32,30 @@ exclusiones:
   - "No invocar para implementar features — este agente coordina releases de código ya implementado y aprobado."
   - "No invocar para configurar pipelines CI/CD desde cero — ese trabajo corresponde a devops-ci-swl."
   - "No invocar cuando el trabajo está incompleto o sin pasar QA — el release manager requiere código aprobado antes de coordinar el despliegue."
+strategy: >
+  SemVer estricto sobre conveniencia. Changelog generado desde commits, no escrito
+  a mano. Feature flags sobre branches largas. Rollback siempre viable; documentado
+  antes de deploy. Versión del próximo release SIEMPRE es decisión del usuario, no del agente.
+healthMetrics:
+  - 0 releases publicados con discrepancia de versión entre las 15 ubicaciones canónicas
+  - Tiempo de rollback documentado ≤15 minutos para cualquier release de los últimos 90 días
+  - Changelog generado coincide con cambios reales en código (sin entradas inventadas)
+  - 0 breaking changes en MINOR o PATCH releases (auditado pre-publish)
+  - 100% de releases con tag anotado (no ligero) y RELEASE-NOTES presente
+steering:
+  - "Skill('release-semver') antes de cada decisión de bump — NO inventar reglas SemVer."
+  - "@reglas/git-workflow.md § Sincronización de versiones — 15 ubicaciones obligatorias."
+  - "@reglas/auditorias-documentales-estructurales.md — gates de profundidad, no de presencia."
+  - "Generar RELEASE-NOTES desde diff git, no desde memoria del agente."
+hardGuardrails:
+  - "@reglas/seguridad-agentes.md § Recovery Catalog — escalar al usuario antes de cualquier publish a registry público."
+  - "scripts/verificar-release.js DEBE pasar antes de tag/push (gate de las 14+ ubicaciones)."
+  - "Tags anotados (git tag -a), NUNCA ligeros (git tag <name>)."
+  - "Republish a misma versión PROHIBIDO (regla SemVer); bump PATCH si registry rechaza."
+  - "@hooks/escaneo-secretos.js — bloquea publish con credenciales en artefactos."
+  - "Versión del próximo release requiere autorización explícita del usuario (regla CLAUDE.md)."
+fragmentos:
+  - _intent-spec
 ---
 ## Cuándo NO invocarme
 

package/agentes/sre-swl.md

@@ -15,6 +15,7 @@ permissionMode: acceptEdits
 color: red
 version: 1.0.0
 nivelRiesgo: ALTO
+maxTurnos: 18  # incident response (diagnose → mitigate → verify) + post-mortem + runbooks
 skillsInvocables: [sre-patrones, performance-baseline, monitoring-alertas, checklist-seguridad]
 skillsRestringidos: [frontend-css-swl, mobile-flutter]
 permisosRed: false
@@ -31,6 +32,29 @@ exclusiones:
   - "No invocar para implementar features de aplicación — este agente trabaja en confiabilidad y operaciones, no en lógica de negocio."
   - "No invocar para configurar pipelines CI/CD — ese trabajo corresponde a devops-ci-swl."
   - "No invocar para implementar la capa de observabilidad (logs, métricas, trazas) — ese trabajo corresponde a observabilidad-swl."
+strategy: >
+  Confiabilidad como producto, no como overhead. Error budgets sobre 100% uptime
+  imposible. Aprender de incidentes (blameless post-mortems) sobre culpar individuos.
+  Toil ≤50% del trabajo SRE; el resto es ingeniería que elimina toil.
+healthMetrics:
+  - Error budget remanente del trimestre ≥0% (no consumido completo)
+  - Mean Time To Acknowledge (MTTA) de pages ≤5 min en horas críticas
+  - Cobertura de runbooks ≥80% para alertas que paginan
+  - Tasa de incidentes repetidos (mismo root cause en <30 días) <10%
+  - Toil documentado y medido ≤50% del tiempo del equipo SRE
+steering:
+  - "Skill('sre-patrones') antes de definir SLO/SLI nuevos."
+  - "@reglas/observabilidad.md — los SLOs requieren SLIs medibles, no inventados."
+  - "Post-mortems blameless con timeline factual y action items con dueño + fecha."
+  - "Cargar Skill('proceso-ddia-fundamentos') al evaluar tradeoffs Reliability/Scalability/Maintainability."
+hardGuardrails:
+  - "@reglas/seguridad-agentes.md § Recovery Catalog — escalar antes de modificar configuración de producción."
+  - "Chaos experiments en producción requieren plan de aborto y aprobación humana."
+  - "Cambios en alertas que paginan requieren on-call lead notificado."
+  - "Post-mortem de incidente SEV1/SEV2 obligatorio ≤72h del incidente."
+  - "@hooks/audit-trail.js — toda acción SRE sobre producción registrada en audit log."
+fragmentos:
+  - _intent-spec
 ---
 ## Cuándo NO invocarme
 

package/comandos/swl/exportar-vault.md

@@ -105,6 +105,7 @@ Si tras `ToolSearch` el MCP carga sus tools pero la primera llamada (ej.
 el síntoma es claro: apiKey desincronizada.
 
 Acción:
+
 1. Leer la apiKey actual del plugin con
    `grep '"apiKey"' "F:/Google Drive/Developer/Obsidian/Vault/SWL/.obsidian/plugins/obsidian-local-rest-api/data.json"`
 2. Reportar al usuario que actualice en **claude.ai → Settings → Connectors
@@ -152,6 +153,7 @@ META - SWL Software Engineering System.md
 Algoritmo de match (en cascada — cada pasada solo se ejecuta si la anterior no resolvió match único):
 
 **Normaliza ambos lados** a comparación robusta antes de cualquier pasada:
+
 - Strip extensión `.md`.
 - Strip prefijo `DEV - ` o `META - ` (cualquier prefijo seguido de ` - `).
 - Lowercase.
@@ -161,17 +163,21 @@ Algoritmo de match (en cascada — cada pasada solo se ejecuta si la anterior no
 Aplica el mismo procesamiento al slug del proyecto local.
 
 **Pasada 1 — Match exacto**:
+
 - Si la cadena normalizada del slug local coincide carácter a carácter con la de algún canónico, ese es el match. Caso típico: `sigaf` ↔ `DEV - SIGAF`.
 
 **Pasada 2 — Match por prefijo bidireccional**:
+
 - Si la cadena del slug local es **prefijo** de la cadena de algún canónico, ese canónico matchea. Ej: `ecosistemamultiagenteia` es prefijo de `ecosistemamultiagenteiaoicine` → match con `DEV - Ecosistema Multi-Agente IA OIC-INE`.
 - Inversamente: si la cadena de algún canónico es prefijo de la del slug local, también matchea (cubre el caso opuesto: vault con nombre más corto que el slug del proyecto).
 - Solo se acepta el match si la pasada produce **exactamente 1** candidato. Si hay 2+ ambiguos, NO usar — pasar a siguiente pasada con el alias o fallback final, listando los candidatos en el WARNING del Paso 5.
 
 **Pasada 3 — Aliases conocidos**:
+
 - Si ninguna pasada anterior resolvió, intenta con sinónimos del slug local antes del fallback (ver lista de aliases más abajo). Para cada alias, repite Pasada 1 y Pasada 2.
 
 **Pasada 4 — Fallback**:
+
 - Si todo lo anterior es vacío:
   - Usar como `related_vault_project` el valor `[[DEV - {Nombre-Title-Case}]]` (fallback antiguo).
   - **Reportar warning explícito al usuario** en el paso 5 indicando que no se encontró nodo canónico y sugerir crear `02-Projects/DEV - {Nombre}.md` en el vault.
@@ -180,13 +186,13 @@ Resultado del algoritmo: el nombre canónico es el basename del archivo sin `.md
 
 Ejemplos de match esperado (con la pasada que lo resuelve):
 
-| Slug local | Normalizado local | Canónico que matchea | Pasada | Nombre canónico resuelto |
-|------------|-------------------|----------------------|--------|--------------------------|
-| `sigaf` | `sigaf` | `sigaf` | 1 (exacto) | `DEV - SIGAF` |
-| `sigm` | `sigm` | `sigm` | 1 (exacto) | `DEV - SIGM` |
-| `swl-software-engineering-system` | `swlsoftwareengineeringsystem` | `swlsoftwareengineeringsystem` | 1 (exacto) | `META - SWL Software Engineering System` |
-| `ecosistema-multi-agente-ia` | `ecosistemamultiagenteia` | `ecosistemamultiagenteiaoicine` | 2 (prefijo del slug en canónico) | `DEV - Ecosistema Multi-Agente IA OIC-INE` |
-| `swl-ses` | `swlses` | ninguno (ver nota) | 3 (alias → reemplaza slug por `swlsoftwareengineeringsystem` y repite 1) | `META - SWL Software Engineering System` |
+| Slug local                        | Normalizado local              | Canónico que matchea            | Pasada                                                                   | Nombre canónico resuelto                   |
+| --------------------------------- | ------------------------------ | ------------------------------- | ------------------------------------------------------------------------ | ------------------------------------------ |
+| `sigaf`                           | `sigaf`                        | `sigaf`                         | 1 (exacto)                                                               | `DEV - SIGAF`                              |
+| `sigm`                            | `sigm`                         | `sigm`                          | 1 (exacto)                                                               | `DEV - SIGM`                               |
+| `swl-software-engineering-system` | `swlsoftwareengineeringsystem` | `swlsoftwareengineeringsystem`  | 1 (exacto)                                                               | `META - SWL Software Engineering System`   |
+| `ecosistema-multi-agente-ia`      | `ecosistemamultiagenteia`      | `ecosistemamultiagenteiaoicine` | 2 (prefijo del slug en canónico)                                         | `DEV - Ecosistema Multi-Agente IA OIC-INE` |
+| `swl-ses`                         | `swlses`                       | ninguno (ver nota)              | 3 (alias → reemplaza slug por `swlsoftwareengineeringsystem` y repite 1) | `META - SWL Software Engineering System`   |
 
 **Nota sobre el caso `swl-ses`** — un lector cuidadoso puede preguntarse por qué Pasada 2 (prefijo) no captura este caso, dado que `swlses` y `swlsoftwareengineeringsystem` comparten el inicio `swls`. La verificación carácter a carácter:
 
@@ -263,11 +269,11 @@ reviewed: false
 
 ## Métricas que cambiaron
 
-| Métrica | Antes | Después |
-|---------|-------|---------|
-| LOC | | |
-| Endpoints | | |
-| Tests | | |
+| Métrica   | Antes | Después |
+| --------- | ----- | ------- |
+| LOC       |       |         |
+| Endpoints |       |         |
+| Tests     |       |         |
 
 ## Bloqueantes o deuda detectada
 
@@ -280,11 +286,13 @@ Ejecutar `/sync-projects {proyecto-slug}` en el vault para integrar los cambios
 ---
 
 **Archivos fuente consultados:**
+
 - `.planning/COMPACTACION.md` (última)
 - `.planning/APRENDIZAJES.md` (últimas entradas)
 - Git log del día
 
 **Notas:**
+
 - Este archivo vive en 00-Inbox/ del vault. Saul lo procesa manualmente o con `/sync-projects`.
 - No sobreescribe nada en `02-Projects/`, `04-Resources/` ni `07-Decisions/` del vault.
 ```
@@ -313,6 +321,7 @@ mcp__obsidian__obsidian_append_content({
 ```
 
 Ventajas frente al filesystem:
+
 - **No pasa por `proteccion-rutas.js`** — el MCP opera vía HTTPS al puerto
   27124, fuera del flujo de Bash/Write/Edit.
 - **Sin staging intermedio**: escribe directamente al archivo final del vault.
@@ -321,6 +330,7 @@ Ventajas frente al filesystem:
   manejar separators de path.
 
 Notas operativas:
+
 - Si el archivo ya existe con ese timestamp (raro), agregar sufijo `_b`
   al nombre antes de invocar `append_content`. El MCP de obsidian no
   sobreescribe si el archivo existe — `append` agrega al final.
@@ -354,6 +364,7 @@ escribe a `_userland/staging/<timestamp>.md` dentro del CWD, luego mueve con
 `Bash` (`mv` o PowerShell `Move-Item`).
 
 Reportar al usuario qué canal se usó:
+
 - Canal A → `[OK] Vía: MCP Obsidian (puerto 27124)`
 - Canal B → `[OK] Vía: filesystem directo (MCP no disponible)`
 - Canal Híbrido → `[OK] Vía: filesystem para Inbox, MCP para promociones`
@@ -391,11 +402,78 @@ Reportar al usuario el desglose final del modo híbrido:
 [OK] Revisión aprobada (reviewed: true) en el Inbox
 ```
 
+## Paso 4b — Verificación post-escritura (obligatorio)
+
+**Inmediatamente después** de cada escritura del Paso 4 (Inbox, promociones en
+`02-Projects/`, `07-Decisions/`, `04-Resources/`, `10-Archive/`), confirma que el
+archivo en disco **existe y tiene contenido sustantivo**. Sin este paso, Obsidian
+puede mostrar nodos fantasma (pestaña con título pero cuerpo vacío) cuando el MCP
+falló con `40101`, timeout o `append_content` sobre ruta incorrecta.
+
+### Cuándo verificar
+
+| Escritura                                                     | Verificar                                                     |
+| ------------------------------------------------------------- | ------------------------------------------------------------- |
+| Export en `00-Inbox/`                                         | **Siempre**                                                   |
+| Append a `02-Projects/DEV - *.md`                             | **Siempre** (leer tramo final o archivo completo si es corto) |
+| Nota nueva en `07-Decisions/`, `04-Resources/`, `10-Archive/` | **Siempre**                                                   |
+| Solo `reviewed: true` en Inbox existente                      | Opcional (el archivo ya existía)                              |
+
+### Cómo verificar (orden de preferencia)
+
+1. **MCP** — `obsidian_get_file_contents` con path **relativo al vault SWL**
+   (sin prefijo `F:\...`):
+   ```json
+   { "filepath": "00-Inbox/2026-05-18_1530_export-swl-ses.md" }
+   ```
+2. **Filesystem** — si el Paso 4 usó canal B, leer el mismo path absoluto con
+   `Read` o `Get-Content` y comparar longitud.
+
+### Criterios de aprobación (todos deben cumplirse)
+
+| #   | Criterio            | Umbral                                                                                                                                                   |
+| --- | ------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| 1   | El archivo existe   | Sin error 404 / `ENOENT`                                                                                                                                 |
+| 2   | Longitud del cuerpo | ≥ **500 caracteres** (sin contar solo frontmatter vacío)                                                                                                 |
+| 3   | Marcador de export  | Contiene `type: export-swl` en frontmatter **o** al menos una sección `## Logros de la sesión` / `## Sesión` / `## Decisiones` con texto bajo el heading |
+| 4   | No es fantasma      | El cuerpo **no** es solo el título del archivo, una línea en blanco, o el nombre del nodo sin párrafos                                                   |
+
+Si el export es deliberadamente corto (<500 caracteres), bajar el umbral a
+≥ **200 caracteres** solo si el frontmatter incluye `type: export-swl` y al
+menos un bullet bajo `## Logros` o `## Sesión`; en caso contrario, tratar como
+fallo.
+
+### Si la verificación falla
+
+1. **No** reportar `[OK] Export creado` al usuario.
+2. Registrar en la salida: `[FAIL] Verificación post-escritura: <motivo>`.
+3. **Un reintento** con el canal alternativo (MCP ↔ filesystem del Paso 4).
+4. Si sigue fallando: reconstruir el Markdown desde `.planning/COMPACTACION.md`
+   - artefactos de sesión y escribir de nuevo; si aún falla, abortar y pedir
+     al usuario revisar Obsidian (vault activo Paso 0c, apiKey Paso 0d).
+5. Si Obsidian ya abrió una pestaña fantasma: cerrar la pestaña en el IDE de
+   Obsidian; **no** dejar el tab apuntando a un path que no pasó verificación.
+
+### Salida interna (para el Paso 5)
+
+Guardar mentalmente (o en el reporte):
+
+```
+[OK] Verificación: 00-Inbox/2026-05-18_1530_export-swl-ses.md — 2847 chars, secciones OK
+```
+
+o
+
+```
+[FAIL] Verificación: cuerpo 42 chars — reintento vía filesystem
+```
+
 ## Paso 5 — Confirmación
 
-Reporta al usuario:
+Reporta al usuario **solo si el Paso 4b aprobó** el Inbox (y cada promoción, si aplica):
 
 - Ruta exacta del archivo creado.
+- Resultado del Paso 4b (caracteres verificados o `[FAIL]` si abortaste).
 - Conteo de palabras.
 - **Nombre canónico resuelto**: indicar qué nodo de `02-Projects/` enlazó el export. Si no hubo match, marcar el warning explícito.
 - Recordatorio: "Al abrir el vault en tu próxima sesión, ejecuta `/sync-projects {proyecto-slug}` para integrar formalmente estos cambios."
@@ -404,6 +482,7 @@ Formato esperado cuando hay match:
 
 ```
 [OK] Export creado: F:\...\2026-05-04_1748_export-swl-ses.md (487 palabras)
+[OK] Verificación post-escritura: 3124 chars, type: export-swl, secciones OK
 [OK] Enlace canónico: [[META - SWL Software Engineering System]]
 
 Próximo paso: al abrir el vault, ejecuta:
@@ -440,6 +519,9 @@ Próximo paso: al abrir el vault, ejecuta:
 - **Recurrir al workaround del filesystem antes de cargar el schema del
   MCP con `ToolSearch`**. Tools deferred ≠ tools ausentes — el MCP server
   está corriendo, solo falta cargar el schema. Cargar antes de defaultear.
+- **Declarar éxito sin Paso 4b**. Un `append_content` o `Write` que no lanza
+  error no garantiza contenido en disco ni en el índice de Obsidian — genera
+  nodos fantasma en el grafo. Siempre leer de vuelta antes del `[OK]`.
 
 ## Relación con otros comandos SWL
 
@@ -458,6 +540,7 @@ Produce:
 
 ```
 [OK] Export creado: F:\Google Drive\Developer\Obsidian\Vault\SWL\00-Inbox\2026-04-16_2130_export-sigaf.md (487 palabras)
+[OK] Verificación post-escritura: 2980 chars, secciones OK
 [OK] Vía: MCP Obsidian (puerto 27124)
 [OK] Enlace canónico: [[DEV - SIGAF]]
 
@@ -467,6 +550,15 @@ Próximo paso: al abrir el vault, ejecuta:
 
 ## Historial de cambios del comando
 
+- **v1.4.1** (2026-05-18) — **Paso 4b — Verificación post-escritura**
+  obligatoria tras cada escritura MCP o filesystem. Origen: exports MCP fallidos
+  (40101 / vault activo incorrecto) dejaron pestañas y nodos en el grafo sin
+  archivo en disco o con cuerpo vacío; reconstrucción manual desde
+  `COMPACTACION.md`. Criterios: existencia, ≥500 chars (o ≥200 con frontmatter
+  completo), secciones de export, anti-fantasma; un reintento con canal alternativo;
+  no reportar `[OK]` sin verificación. Anti-patrón y ejemplos del Paso 5
+  actualizados.
+
 - **v1.4.0** (2026-05-13) — Agregados Pasos 0c y 0d con verificación previa
   del vault activo de Obsidian y de la apiKey del MCP. Origen: sesión
   2026-05-13 con autorización ampliada del usuario para promover docs;
@@ -488,4 +580,4 @@ Próximo paso: al abrir el vault, ejecuta:
   el orden de preferencia (MCP primero, filesystem como fallback explícito)
   y agrega la nota de "tools deferred ≠ tools ausentes" en anti-patrones.
   Aplicación de la regla `consultar-vault-primero.md § Workflow forzoso
-  para escritura al vault`.
+para escritura al vault`.

package/comandos/swl/nemesis.md

@@ -228,9 +228,30 @@ Cada `evaluacion.json` sigue el schema `nemesis-evaluacion-json` v1.0.0.
 
 ### Veredicto JSON
 
-- `status: "PASS"` — convergencia. El loop terminó. 0 críticos + 0 altos.
-- `status: "NEEDS_IMPROVEMENT"` — el loop puede continuar (si `--remediar`).
-- `status: "FAIL"` — requiere intervención humana. El loop se detiene.
+Los tres status del JSON estructurado del evaluator (definidos canónicamente
+en `agentes/nemesis-auditor-swl.md § Veredicto status`):
+
+- **`status: "PASS"`** — convergencia. 0 críticos + 0 altos. Pueden quedar
+  hallazgos MEDIOS/BAJOS/informativos. El loop termina con éxito.
+
+- **`status: "NEEDS_IMPROVEMENT"`** — hay críticos o altos pero **todos** tienen
+  `accion_sugerida` concreta + `agente_recomendado` válido. El comando con
+  `--remediar` invoca al `orquestador-swl` automáticamente. Sin `--remediar`,
+  el reporte queda como acción pendiente para el usuario.
+
+- **`status: "FAIL"`** — hay al menos un hallazgo que cumple cualquiera de:
+  - Veto items según `reglas/gobernanza.md § Veto items`.
+  - Cambio arquitectural ambiguo (requiere ADR / decisión del usuario).
+  - Decisión de producto (comportamiento esperado no definido).
+  - Datos de entrada inválidos en el alcance auditado.
+
+  El loop se detiene de inmediato y escala a Recovery Catalog. Origen del
+  refuerzo: SIGAF sesión 2026-05-21 (alineación L2 — el comando y el agente
+  deben tener idéntico criterio de FAIL para evitar loops vacíos).
+
+**Regla de consistencia**: si esta sección del comando y la del agente
+diverge en wording, el agente es la fuente de verdad operacional (lo
+implementa). Actualizar el comando para alinear, NO al revés.
 
 ## Costo estimado
 
@@ -299,6 +320,52 @@ bugs adyacentes que el fix original no cubrió.
 /swl:nemesis --redistribuir --modulo backend/app/auth
 ```
 
+## Inyectar foco adicional durante el loop con `SendMessage`
+
+Durante una ejecución `--remediar` larga (8-30 turnos en módulos grandes), el
+usuario humano puede observar que el evaluator está siguiendo una pista débil
+o ignorando una sospecha concreta. **No es necesario abortar el comando** —
+usar `SendMessage` para inyectar foco adicional al agente en curso sin perder
+el progreso del loop.
+
+Patrón validado (origen: SIGAF sesión 2026-05-21, mejora D1):
+
+```
+# El usuario ve en el chat que la iteración 2 está auditando solo
+# permisos y olvida revisar el invariante de auditoría.
+# SendMessage al agente activo:
+
+SendMessage({
+  to: "nemesis-auditor-swl",   // o el nombre asignado del agente activo
+  message: "Antes de cerrar iteración 2: revisa también el invariante de
+            auditoría inmutable en module/audit/handlers.py. Sospecho que
+            handle_revoke() escribe a la tabla aprobaciones_historial sin
+            verificar que el VBO original siga vigente."
+});
+```
+
+El agente recibe el mensaje en su próximo turno y lo trata como instrucción
+adicional sin reiniciar el loop. El registro `audit/findings/iter-N/` queda
+intacto.
+
+**Cuándo aplicar**:
+
+- El loop lleva ≥2 iteraciones y el reporte sugiere que olvida un patrón obvio
+  para el contexto del módulo.
+- Se detecta que el evaluator está dando vueltas sobre el mismo hallazgo de
+  baja severidad y conviene priorizar otra zona del código.
+- El usuario tiene contexto adicional (incidente reciente, decisión de ADR
+  no documentado en CLAUDE.md) que el agente no puede inferir solo.
+
+**Cuándo NO aplicar**:
+
+- La iteración actual está progresando bien — no interrumpir loops que
+  convergen.
+- El cambio que se quiere inyectar es de scope (cambiar `--modulo`): ahí sí
+  abortar con Ctrl+C, reset con `--reset-plan` y re-invocar.
+- Inyectar instrucciones contradictorias con el plan congelado del loop —
+  viola regla `seguridad-agentes.md § Anti-proxy-goal-drift`.
+
 ## Regla obligatoria sobre las citas archivo:línea del reporte
 
 Cuando se actúe sobre un hallazgo `archivo:linea` reportado por el evaluator,

package/comandos/swl/planear-fase.md

@@ -42,6 +42,22 @@ Verifica también:
 - Lee `CLAUDE.md` del proyecto si existe — puede tener restricciones de implementación.
 - Si hay fases anteriores con PLAN.md o RESUMEN.md, léelas para entender patrones establecidos.
 
+### Reglas obligatorias sobre paths y listas en PLAN.md
+
+**Ubicación del PLAN.md** (aprendizaje HIGH 2026-05-18):
+
+- Iniciativas que califican como fase (cualquier trabajo cross-módulo, >50 LOC, multi-archivo, o que produce un release) van a `.planning/fases/0N-PLAN.md` donde N es el siguiente número libre.
+- `.planning/PLAN.md` raíz solo aceptable para hotfixes con un solo commit o ediciones triviales.
+- Al delegar al `planificador-swl`, instruir explícitamente: *"produce `.planning/fases/0N-PLAN.md` donde N es el siguiente número libre visible en `ls .planning/fases/`"*. NUNCA dejar la decisión de path al sub-agente sin esta instrucción.
+- Si la sesión arrancó libre (sin `/swl:discutir-fase`), crear retrospectivamente `0N-CONTEXTO.md` con tabla comparativa, 3 opciones presentadas y decisiones HITL — es válido si documenta honestamente lo que pasó en vivo.
+
+**Listas de agentes/componentes por campo de frontmatter** (aprendizaje HIGH 2026-05-18):
+
+- Cuando un PLAN.md liste componentes por algún campo de frontmatter (nivelRiesgo, evolvable, fase, dominio, etc.), DEBE generarse con `grep -l "^<campo>: <valor>" <dir>/*.md` con **ancla `^` al inicio de línea**.
+- Sin ancla, el grep matchea menciones en el cuerpo (ej: comentarios, secciones de revisión) y devuelve falsos positivos.
+- Si el CONTEXTO recibe la lista en el prompt del usuario, el planificador DEBE verificarla con grep anclado antes de incluirla en PLAN.md.
+- Precedente documentado: PR Opción B (2026-05-18) — CONTEXTO listaba 6 agentes ALTO; verificación real reveló 8 distintos (solo 1 solapamiento). Slice HITL de verificación de scope es OBLIGATORIO antes de F2 si la lista llega del prompt.
+
 ## Paso 2 — Análisis del contexto
 
 Antes de delegar, analiza el CONTEXTO.md de la fase y extrae:

package/comandos/swl/release.md

@@ -174,9 +174,69 @@ y debe versionarse.
 
 ## Paso 7 — Generar CHANGELOG
 
-Lee CHANGELOG.md existente (o créalo). Agrega entrada al inicio con formato Keep a Changelog:
+Desde v1.6.5 este paso usa el skill `changelog-generator` para parsear
+Conventional Commits y producir el bloque listo para insertar (ADR-0029).
 
-- Secciones: Funcionalidades nuevas, Correcciones, Mejoras de rendimiento, Cambios internos, Breaking Changes, Estadísticas.
+### Paso 7.1 — Cargar skill y previsualizar
+
+```
+Skill("changelog-generator")
+```
+
+Ejecutar el parser determinista contra los commits del rango actual:
+
+```bash
+node habilidades/changelog-generator/scripts/parse-commits.js \
+  --from <tag-anterior> --to HEAD --version <nueva-version> --format markdown
+```
+
+El script imprime el bloque markdown listo para insertar Y reporta a stderr
+el ratio de conformidad Conventional Commits. Categorías generadas en orden
+canónico: Breaking changes → Nuevas funcionalidades → Correcciones →
+Mejoras de rendimiento → Cambios internos → Reversiones → Evoluciones de
+skills/agentes → Mantenimiento → Otros.
+
+### Paso 7.2 — Gate de conformidad
+
+Verificar la conformidad (impresa a stderr o vía `--format json`):
+
+- **>= 80% conformidad**: continuar a 7.3.
+- **< 80% conformidad**: detenerse y reportar al usuario los commits caídos
+  bajo "Otros". Pedir decisión:
+  1. Continuar con el bloque generado (los "Otros" quedan al final del CHANGELOG).
+  2. Abortar release y reescribir commits no conformes (`git rebase -i`).
+  3. Editar manualmente la sección "Otros" antes de insertar.
+
+NO continuar automáticamente con conformidad baja — el changelog público
+queda confuso.
+
+### Paso 7.3 — Insertar en CHANGELOG.md
+
+Leer `CHANGELOG.md` actual:
+- Si no existe: crear con header `# Changelog\n\n` y luego el bloque nuevo.
+- Si existe: insertar el bloque nuevo inmediatamente después del header
+  `# Changelog` (antes de la entrada anterior).
+
+Escritura atómica obligatoria (regla CLAUDE.md). Usar `atomicWriteSync` desde
+`hooks/lib/atomic-write.js` cuando se llame programáticamente.
+
+### Paso 7.4 — Verificar entrada generada
+
+```bash
+head -40 CHANGELOG.md
+```
+
+Confirmar:
+- Header `## [<nueva-version>] - YYYY-MM-DD` presente.
+- Categorías generadas tienen contenido coherente con los commits del rango.
+- Breaking changes (si los hay) aparecen al inicio.
+
+### Fallback manual (legacy v1.6.4 y anterior)
+
+Si el parser falla o el skill no está disponible, mantener el flujo manual
+de versiones previas:
+- Secciones: Funcionalidades nuevas, Correcciones, Mejoras de rendimiento,
+  Cambios internos, Breaking Changes, Estadísticas.
 - Descripciones legibles por humanos (sin prefijo feat:/fix:).
 - Omitir commits style: y test: del changelog público.