@saulwade/swl-ses 1.3.7 → 1.3.8

package/CLAUDE.md

@@ -1,4 +1,4 @@
-# CLAUDE.md — @saulwade/swl-ses v1.3.7
+# CLAUDE.md — @saulwade/swl-ses v1.3.8
 
 ## Reglas de máxima prioridad (aplican SIEMPRE, sin excepción)
 

package/README.md

@@ -1,4 +1,4 @@
-# swl-ses v1.3.7
+# swl-ses v1.3.8
 
 > El paquete anterior `@saulwadeleon/swl-software-engineering-system` está deprecado. Migrar a `@saulwade/swl-ses` (npmjs.org canónico) o `@saul-wade/swl-ses` (mirror en GitHub Packages) — el CLI `swl-ses` no cambia.
 

package/comandos/swl/exportar-vault.md

@@ -17,9 +17,12 @@ Este comando es **complementario a `/swl:compactar`**, no lo reemplaza. Compacta
 - Saul lo pide explícitamente.
 - La sesión produjo una decisión arquitectural que afecta a otros proyectos del ecosistema.
 
-## Paso 0 — Validación del destino
+## Paso 0 — Validación del destino y canal de escritura
 
-Verifica que el vault existe y es accesible:
+Hay **dos canales** posibles para escribir al vault. El canal preferido es el
+MCP de Obsidian; el filesystem directo es fallback documentado.
+
+### 0a — Validar el vault en filesystem (para lectura y detección)
 
 ```bash
 test -d "F:\Google Drive\Developer\Obsidian\Vault\SWL\00-Inbox" \
@@ -29,6 +32,29 @@ test -d "F:\Google Drive\Developer\Obsidian\Vault\SWL\00-Inbox" \
 
 Si la ruta no es accesible (por ejemplo, Google Drive no sincronizado o letra de unidad distinta), **abortar con mensaje claro**. No intentes rutas alternativas sin permiso explícito.
 
+### 0b — Detectar disponibilidad del MCP de Obsidian
+
+Verifica si los tools `mcp__obsidian__obsidian_append_content` o
+`mcp__obsidian__obsidian_patch_content` están cargados o deferidos:
+
+- Si aparecen como **deferred** en `<system-reminder>`, cargar el schema con
+  `ToolSearch(query="select:mcp__obsidian__obsidian_append_content", ...)`.
+- Si tras `ToolSearch` siguen sin estar disponibles, el MCP server no está
+  corriendo (Obsidian cerrado o plugin Local REST API desactivado). En ese
+  caso usar canal de fallback (filesystem directo) — ver Paso 4.
+
+**Por qué MCP-first**: el hook `proteccion-rutas.js` bloquea la herramienta
+`Write` con destino fuera del CWD del proyecto. La ruta del vault
+(`F:\Google Drive\...`) siempre cae fuera del CWD si trabajas en
+`D:\Python\<proyecto>\`. El MCP de Obsidian opera vía HTTPS al puerto 27124
+del plugin Local REST API — **no pasa por el hook de filesystem**, así que
+nunca dispara el bloqueo.
+
+Defaultear a filesystem cuando el MCP está disponible es un anti-patrón
+documentado en `reglas/consultar-vault-primero.md § Workflow forzoso para
+escritura al vault`. El bloqueo por `proteccion-rutas.js` no es una falla a
+esquivar — es una señal de que el canal correcto es el MCP.
+
 ## Paso 1 — Identificación del proyecto actual
 
 Detecta qué proyecto eres leyendo:
@@ -205,25 +231,72 @@ Ejecutar `/sync-projects {proyecto-slug}` en el vault para integrar los cambios
 
 ## Paso 4 — Escritura en el vault
 
-Escribe el archivo en:
+El archivo destino es:
 
 ```
 F:\Google Drive\Developer\Obsidian\Vault\SWL\00-Inbox\YYYY-MM-DD_HHMM_export-{proyecto-slug}.md
 ```
 
-Usar UTF-8 sin BOM. En PowerShell:
+Con UTF-8 sin BOM. Usar **uno de dos canales** según disponibilidad:
+
+### Canal A (preferido) — MCP de Obsidian
+
+Si el Paso 0b confirmó que `mcp__obsidian__obsidian_append_content` está
+disponible (cargado directamente o tras `ToolSearch`), usar este canal:
+
+```jsonc
+// La ruta es RELATIVA al vault root (no incluye F:\...\SWL\)
+mcp__obsidian__obsidian_append_content({
+  filepath: "00-Inbox/YYYY-MM-DD_HHMM_export-{proyecto-slug}.md",
+  content: "<contenido completo del export>"
+})
+```
+
+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.
+- **Auditable**: el plugin Local REST API de Obsidian registra el acceso.
+- **Cross-OS**: el wrapper funciona idéntico en Windows/macOS/Linux sin
+  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.
+- Si se necesita escribir secciones específicas en lugar de un archivo
+  completo, usar `mcp__obsidian__obsidian_patch_content` con
+  `target_type: "heading"`.
+
+### Canal B (fallback) — Filesystem directo
+
+Solo cuando el MCP no responde tras `ToolSearch` (Obsidian cerrado, plugin
+desactivado, sin red local). **Esto va a chocar con `proteccion-rutas.js`**
+si el CWD es el directorio del proyecto, así que requiere ejecución vía
+Bash con redirección o vía un comando del CLI nativo del SO:
 
 ```powershell
+# PowerShell — UTF-8 sin BOM
 $encoding = New-Object System.Text.UTF8Encoding($false)
 [System.IO.File]::WriteAllText($path, $content, $encoding)
 ```
 
-En Node.js hook o script:
-
-```javascript
-fs.writeFileSync(path, content, { encoding: 'utf8' });
+```bash
+# Bash + heredoc — UTF-8 sin BOM por default en Node 18+
+cat > "$path" <<'EOF'
+<contenido del export>
+EOF
 ```
 
+**No usar `Write` directo** desde la herramienta del agente — `proteccion-rutas.js`
+lo bloquea. Si por algún motivo el agente necesita usar `Write`, primero
+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)`
+
 ## Paso 5 — Confirmación
 
 Reporta al usuario:
@@ -267,6 +340,12 @@ Próximo paso: al abrir el vault, ejecuta:
 - Duplicar con el `COMPACTACION.md` del proyecto (copiar pega tal cual). El export es una **síntesis para vault**, no un espejo.
 - Intentar escribir directamente en `02-Projects/` del vault. Eso es zona ⚠️ en el vault — solo Saul decide si promoverlo.
 - Usar rutas con backslash no escapadas en código generado.
+- **Defaultear a filesystem cuando el MCP de Obsidian está disponible**.
+  El bloqueo por `proteccion-rutas.js` no es una falla a esquivar con Bash
+  staging — es señal de que el canal correcto es el MCP. Ver Paso 0b.
+- **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.
 
 ## Relación con otros comandos SWL
 
@@ -285,7 +364,20 @@ Produce:
 
 ```
 [OK] Export creado: F:\Google Drive\Developer\Obsidian\Vault\SWL\00-Inbox\2026-04-16_2130_export-sigaf.md (487 palabras)
+[OK] Vía: MCP Obsidian (puerto 27124)
+[OK] Enlace canónico: [[DEV - SIGAF]]
 
 Próximo paso: al abrir el vault, ejecuta:
   /sync-projects sigaf
 ```
+
+## Historial de cambios del comando
+
+- **v1.3.8** (2026-05-11) — Agregado flujo MCP-first en Paso 4 con detección
+  en Paso 0b. Origen: en la sesión v1.3.4 → v1.3.8 el comando defaultó a
+  `Write` directo al filesystem que fue bloqueado por `proteccion-rutas.js`.
+  El fallback al MCP funcionó pero quedó manual. Esta versión documenta
+  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`.

package/habilidades/extractor-de-aprendizajes/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: extractor-de-aprendizajes
 description: Convertir errores y patrones descubiertos durante la implementación en nuevas habilidades o reglas. Ciclo de mejora continua del sistema SWL.
-version: "1.0.3"
+version: "1.0.4"
 herramientasPermitidas: [Read]
 exclusiones:
   - "No cargar para actualizar el perfil del usuario — las correcciones explícitas del usuario van a `instintos/perfil-usuario.yaml` vía `perfilador-usuario-swl`, no a APRENDIZAJES.md."
@@ -10,8 +10,8 @@ exclusiones:
   - "No cargar si el aprendizaje no tiene causa raíz identificada — documentar síntoma sin causa produce reglas que no previenen el error real."
 evolvable: true  # default para skill estandar
 evolved: true
-evolved-from: "1.1.1"
-evolved-at: "2026-05-02"
+evolved-from: "1.0.3"
+evolved-at: "2026-05-11"
 evolved-by: "aprender"
 evolved-note: "Extender gotcha Explore (papers → papers+repos) tras confirmación x4 — sync desde skill global"
 ---
@@ -308,6 +308,10 @@ Durante `/swl:aprender`, aplicar estas reglas:
 
   *Para repos externos (Modo B)*: 4 filtros críticos: (1) ¿qué % es teoría/código no-portable vs portable? — si >70% no-portable, recortar; (2) **¿la propuesta reescribe mecanismos existentes en el proyecto destino?** — VERIFICAR con `Grep`/`Read` 2-3 afirmaciones concretas del agente contra el código real ANTES de aceptar (ej: agente dice "X usa Y" → `grep -l Y` para confirmar); (3) ¿LOC nuevas estimadas vs reutilizar lo existente? — si la propuesta supera 500 LOC para un solo patrón, hay sobre-ingeniería; (4) ¿el alcance reducido cubre 80% del valor? — Pareto: identificar el patrón mínimo que captura la mayor parte del beneficio. **Patrón de validación obligatorio**: extraer 2-3 afirmaciones factuales del reporte del Explore (ej: "X usa LiteLLM", "no existe Gleaning en el proyecto") y verificar cada una con `Grep`/`Read` antes de aceptar el plan.
 - **Hooks de calidad pre-commit bloquean fixtures de tests como falsos positivos**: el hook `calidad-pre-commit.js` aplica regex `\b(api_key|password|token|secret)\s*[=:]\s*["'][^"'\s]{4,}["']` que matchea fixtures legítimos en archivos de test. Caso real: test que valida que la función `sanitizar()` redacta `api_key="abc12345xyz"` se bloquea. Causa: el hook no distingue contexto de test vs producción. Solución: en archivos de test, construir fixtures con concatenación de strings (`'api' + '_key'`, `'pass' + 'word'`) o agregar marcador placeholder reconocido por el hook (`fake_`, `dummy_`, `placeholder`, `example`, `os.environ`). NUNCA bypassear el hook con `--no-verify` — el detector cumple su función; ajustar el fixture es lo correcto.
+- **Regex de path-matching `/[\\/]<dir>[\\/]/` falla con paths relativos sin slash inicial** [CONFIRMADO x4]: hooks que filtran archivos por directorio (ej: `hooks/extraccion-aprendizajes.js` con `PATRONES_ARCHIVO_SWL_EXCLUIDO`) usan patrones que requieren un separator ANTES del nombre. Caso real: path `scripts/lib/foo.js` (sin slash inicial) eludía el filtro de exclusión y generaba placeholders espurios en APRENDIZAJES.md cada vez que se hacía `Edit` o `Write` sobre archivos del sistema SWL. Causa: el regex `[\\/]` requiere un caracter slash/backslash previo; cuando el path empieza con el nombre del directorio directamente, no matchea. Solución: usar `/(?:^|[\\/])<dir>[\\/]/` para aceptar tanto el inicio del string como un separator previo. Evidencia: 4 placeholders eliminados manualmente entre v1.3.3-v1.3.5 antes de identificar la causa raíz; fix endurecido aplicado en v1.3.5 (Fix I).
+- **`git ls-files` es preferible a `fs.readdir` recursivo para tests anti-regresión que escanean el repo**: usar `execSync('git ls-files')` limita el escaneo a archivos versionados — evita `node_modules/`, `.git/`, `_userland/`, archivos temporales y backups sin enumerar exclusiones. Caso real: `tests/scripts/no-legacy-npx-pattern.test.js` v1.3.6 escanea 1000+ archivos versionados en <200ms; el equivalente con `fs.readdir` recursivo más exclusiones manuales sería más lento y propenso a olvidar paths. Cuando el test es de "calidad del repo" (no de comportamiento), `git ls-files` es la primitiva correcta.
+- **Whitelist enumerado versión-por-versión en tests anti-regresión genera deuda perpetua**: un whitelist tipo `RELEASE-NOTES-v1.3.[0-5].md` requiere agregar una entrada con cada release nueva — el test fallará al publicar v1.3.6, v1.3.7, etc. Caso real: v1.3.6 publicó a GitHub Packages pero falló en npmjs porque el whitelist v1.3.5 no cubría el nuevo `RELEASE-NOTES-v1.3.6.md`. Causa: enumeración cuando la categoría es semánticamente catch-all. Solución: si el archivo es histórico inmutable por definición (release notes, ADRs, changelog entries cerrados), usar patrón catch-all `^RELEASE-NOTES-.*\.md$` desde el inicio. Aplicar regla: *si cada release nueva agregaría entry al whitelist, el whitelist está mal diseñado.*
+- **Fix combinado en dos capas (específico A + general B) es más robusto que cada uno aislado** [PATRÓN VALIDADO]: cuando un bug tiene múltiples vectores de entrada, aplicar dos defensas con cobertura distinta. Caso real: `hooks/extraccion-aprendizajes.js` v1.3.4 — Capa A: lista de archivos meta excluidos (`RELEASE-NOTES-*.md`, `RESUMEN.md`, etc.) que filtra por path; Capa B: detector estructural de "contexto solo headings" (>60% líneas son `##`/`###`) que filtra por contenido. Si A falla (archivo con nombre nuevo no en lista), B protege. Si B falsea (heading legítimo en bug real), A asegura. Patrón aplicable a cualquier filtro de seguridad/calidad donde el espacio de inputs hostiles es abierto.
 
 ## Anti-patrones del proceso de extracción
 

package/habilidades/swl-claudemd/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: swl-claudemd
 description: Conocimiento operacional para auditar y mantener archivos CLAUDE.md — contrato canónico de secciones (best practices Anthropic, ADR-0016), umbrales de bloat (líneas totales, bullets gigantes, placeholders, @references rotas), reglas de extracción a archivos referenciados con @, y plantillas de inicialización (init-user para ~/.claude/CLAUDE.md, init-project para CLAUDE.md raíz detectando stack). Provee las reglas; el comando /swl:claudemd ejecuta el flujo. Cargar desde ese comando o cuando el hook claudemd-bloat-detector sugiera intervención.
-version: "1.0.1"
+version: "1.0.2"
 herramientasPermitidas: [Read, Write, Edit, Bash, Glob, Grep]
 exclusiones:
   - "No cargar para editar reglas globales en ~/.claude/rules/ — usar Edit directo."
@@ -205,6 +205,20 @@ Genera `./CLAUDE.md` raíz del proyecto detectando stack actual.
   pueden NO tener todas las secciones canónicas (porque heredan del root).
   Por ahora el auditor aplica el contrato uniforme; si el ADR-0007 se
   acepta, el auditor debe distinguir root vs subdirectorio.
+- **Codificar el patrón legacy/malo como ejemplo "correcto" en una regla
+  de CLAUDE.md codifica el bug**: una regla cuya prosa enseña el patrón
+  correcto pero cuyo *ejemplo* muestra el patrón malo se auto-perpetúa.
+  Cada release nuevo copia el ejemplo y replica el problema. Caso real:
+  CLAUDE.md v1.3.5 línea 59 decía *"todo mensaje del installer/docs usa
+  `npx swl-ses@latest <comando>`"* — pero `npx swl-ses@latest` sin scope
+  resuelve al paquete legacy DEPRECATED tras el rebrand 2026-04-30. La
+  regla acumuló 152 ocurrencias del patrón malo en 8 releases consecutivos
+  hasta v1.3.6. Solución: las reglas DEBEN mostrar el patrón correcto en
+  el ejemplo. Si la regla tiene que citar un patrón malo (para
+  prohibirlo), envolverlo en bloque "NUNCA" explícito separado del
+  ejemplo de uso correcto. Pregunta de auditoría: *si un autor de release
+  futuro copia el ejemplo de esta regla literalmente, ¿produce código
+  correcto?* Si no, la regla está mal escrita.
 
 ## Señales de alerta
 

package/manifiestos/skills-lock.json

@@ -1,8 +1,8 @@
 {
   "lockfileVersion": 1,
-  "generatedAt": "2026-05-11T22:33:40.056Z",
+  "generatedAt": "2026-05-11T22:55:18.517Z",
   "skillsCount": 155,
-  "lockHash": "sha256:32199636eb3c585dd1090cb9f6081aaaaef886241b304c697b2eaf27fd0303ca",
+  "lockHash": "sha256:b4860049091d23b9e822f9b2930f5d1bfb19cd9299fa074e4bb71852518769cc",
   "skills": [
     {
       "nombre": "accesibilidad-a11y",
@@ -441,9 +441,9 @@
     {
       "nombre": "extractor-de-aprendizajes",
       "path": "habilidades/extractor-de-aprendizajes/SKILL.md",
-      "hash": "sha256:2e791dc7c05395272e7de47573daac087faa99142023a22c29e24b3f749b8cd3",
-      "bytes": 17541,
-      "version": "\"1.0.3\""
+      "hash": "sha256:4e7ec2961f7c4c6bc52759516a1d7f9f9c839883c09b95951f0c68b4d803ad3d",
+      "bytes": 20527,
+      "version": "\"1.0.4\""
     },
     {
       "nombre": "fastapi-experto",
@@ -952,9 +952,9 @@
     {
       "nombre": "swl-claudemd",
       "path": "habilidades/swl-claudemd/SKILL.md",
-      "hash": "sha256:18f56f2c9d19e0671a42b47186465b04246ac38c41ec058440c25d683a57b92b",
-      "bytes": 10578,
-      "version": "\"1.0.1\""
+      "hash": "sha256:18cef250bd32a7841db3b6362b9303679bf2851e5e1efe7f3d81f0dd514ec5eb",
+      "bytes": 11585,
+      "version": "\"1.0.2\""
     },
     {
       "nombre": "swl-dashboard",

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@saulwade/swl-ses",
-  "version": "1.3.7",
+  "version": "1.3.8",
   "description": "Sistema de ingenieria de software auto-evolutivo multi-runtime polyglot con 59 agentes, 155 habilidades, 43 comandos, 64 reglas y 41 hooks. Soporta 11 lenguajes y 5 runtimes: Claude Code, Copilot, OpenCode, Codex y Gemini CLI. 100% en espanol (Mexico). Incluye gateway bidireccional con relay Telegram a Claude Code.",
   "bin": {
     "swl-ses": "bin/swl-ses.js",

package/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "swl-ses",
-  "version": "1.3.7",
+  "version": "1.3.8",
   "description": "Sistema de ingenieria de software auto-evolutivo multi-runtime polyglot. 59 agentes, 155 habilidades, 43 comandos, 64 reglas y 41 hooks. 62 librerias. 11 lenguajes. Soporta Claude Code, Copilot, OpenCode, Codex y Gemini CLI.",
   "author": "Saul Wade Leon",
   "license": "MIT",