@saulwade/swl-ses 2.6.1 → 2.8.0

package/habilidades/harness-claude-code/SKILL.md

@@ -10,8 +10,7 @@ description: >
   Cargar cuando el usuario reporte "se acabó la cuota", se prepare una
   sesión Opus larga (>2h), se planifique adopción de MCP servers, o se
   detecte context-rot recurrente.
-version: "1.0.6"
-evolved: false
+version: "1.0.7"
 herramientasPermitidas: [Read]
 exclusiones:
   - "No cargar para teoría general de context-rot y compactación — usar `compactacion-contexto`. Este skill cubre operación day-to-day del harness Claude Code; aquel cubre principios de gestión de contexto independientes de la herramienta."
@@ -283,6 +282,8 @@ Sin observar la métrica, no puedes optimizarla.
 - **`child_process.spawn(cmd, args, { env: {} })` REEMPLAZA el env del padre con vacío, NO hereda** [CONFIRMADO 2026-05-18]: el cliente MCP de Claude Code (y el de Cursor) lee `mcpServers.X.env` del config JSON y lo pasa literal al spawn. Si la config tiene `"env": {}` explícito, el binario hijo arranca SIN ninguna variable de entorno del padre — rompe la herencia de apiKeys que viven en HKCU/registry. Síntoma: MCP server da `40101 Authorization required` aunque `setx OBSIDIAN_API_KEY` esté correcto en HKCU y curl con esa key responda HTTP 200 al plugin. Causa: Node `child_process.spawn` con `env: {}` ≠ sin `env` option. Solución: **OMITIR la clave `env` por completo en el JSON** (no dejarla vacía). Verificado empíricamente con `spawn(binario, [], { /* sin env */ })` → binario heredó `OBSIDIAN_API_KEY`; `spawn(binario, [], { env: {} })` → binario sin env. El patch SWL para Python (`scripts/lib/mcp_config.py::build_stdio_env`) merge `os.environ + overrides` para corregir el mismo síntoma en el lado Python.
 - **MCP server devuelve auth error con apiKey correcta en disco → el proceso vivo arrancó con apiKey vieja** [CONFIRMADO 2026-05-18]: aunque `~/.cursor/mcp.json` y `~/.claude/settings.json` tengan la apiKey actual del plugin, los procesos del binario MCP (ej. `mcp-obsidian.exe`) que ya están corriendo retuvieron la apiKey del momento de su spawn. Síntoma: actualizar JSONs no soluciona 40101. Solución: `taskkill /F /IM mcp-obsidian.exe /T` (Windows) o `pkill mcp-obsidian` (Unix) + **quit total del cliente parent** (Cursor.exe / claude.exe) — no basta reload de ventana. Al reabrir, el cliente respawnea el binario con env actual. Verificar con `ps -W | grep mcp-obsidian` que solo haya procesos con timestamp posterior al reinicio.
 - **Cursor y Claude Code CLI dentro de Cursor son clientes MCP DISTINTOS con procesos independientes** [CONFIRMADO 2026-05-18]: cuando se ejecuta Claude Code CLI en una terminal embebida de Cursor, hay DOS procesos del binario MCP corriendo simultáneamente — uno por cliente. Cada uno lee SU PROPIA config: Cursor lee `~/.cursor/mcp.json`, Claude Code CLI lee `~/.claude/settings.json` + `<proyecto>/.claude/settings.local.json`. Una apiKey actualizada en uno no propaga al otro. Síntoma observado: el agente AI de Cursor responde MCP OK pero Claude Code CLI da 40101 (o viceversa). Solución: usar variable de entorno persistente del SO (`setx OBSIDIAN_API_KEY` → HKCU\Environment) como single source of truth y dejar configs JSON sin clave `env` para heredar del padre. Cada regeneración de apiKey requiere un solo `setx` + reiniciar Cursor (que reinicia ambos clientes).
+- **Un comando encadenado con `&&` donde un paso intermedio es bloqueado por un hook de risk-scoring aborta TODO el resto en silencio** (caso real 2026-07-17): `rm -rf <dir-scratch> && git add .gitignore && git status` — el `rm -rf` fue bloqueado por el hook de risk-scoring (score 0.65 > umbral), y como bash corta la cadena `&&` en el primer fallo, el `git add .gitignore` nunca se ejecutó. El `git status` final tampoco corrió, así que no había señal inmediata de que el segundo paso se hubiera saltado — solo se detectó al revisar el estado real del working tree y notar que `.gitignore` seguía sin stage. Regla: cuando cualquier paso de una cadena `&&` puede ser bloqueado por un hook (destructivo, escritura fuera de scope, comando de alto riesgo), correr los pasos como llamadas Bash separadas — nunca asumir que los pasos posteriores corrieron solo porque el tool call "se completó".
+- **Un timeout de Bash en tu propia verificación NO es evidencia de que el fix falló**: tras corregir un bug de aislamiento en un motor de mutation testing (F32-T07), dos intentos de reproducir la corrida completa vía `node -e` con timeout de 2 y 5 minutos expiraron sin dar resultado — pero eso mide el tiempo de la corrida real (56 min para 2275 mutantes), no la corrección del fix. Tratar el timeout como "no pude confirmarlo, quizá sigue roto" habría sido un falso negativo. La verificación correcta ante un timeout: leer el diff exacto del fix, correr el test de regresión específico por una vía alternativa que no dependa del runner que dio timeout (aquí: `require()` + `--test-name-pattern` en vez de `node --test`), y correr la suite completa (rápida) en vez de forzar la reproducción lenta. Un timeout es una limitación del método de verificación elegido, no del artefacto verificado — cambiar de método antes de degradar la confianza en el fix.
 
 ---
 

package/habilidades/meta-skills-estandar/recursos/convencion-examples.md

@@ -1,93 +1,93 @@
-# Convención `EXAMPLES.md` — recurso opcional para skills críticos
-
-Convención **opcional** para skills cuyo valor depende de ejemplos concretos
-con diff MAL → BIEN. Esta convención NO es retroactiva: las 63 carpetas
-`recursos/` existentes en `habilidades/` no se renombran. Solo aplica a:
-
-- Skills nuevos cuyo dominio se entiende mejor con ejemplos lado a lado.
-- Skills existentes que reciban actualización mayor y agreguen ejemplos.
-
----
-
-## Cuándo aplicarla
-
-Aplicar cuando:
-
-- El skill prescribe **decisiones técnicas** o **patrones** cuyo error es
-  sutil sin un caso concreto (ej: anti-patrones de async, gotchas de framework,
-  decisiones arquitecturales).
-- El skill se beneficia de mostrar 2-4 ejemplos lado a lado: el caso aplicado
-  correctamente vs el caso degenerado.
-- Los ejemplos suman > 100 líneas y meterlos en SKILL.md lo pasaría del
-  límite de 300 líneas.
-
-NO aplicar cuando:
-
-- El skill ya tiene `recursos/` con archivos temáticos específicos
-  (ej: `meta-skills-estandar/recursos/anti-patrones-y-leyes.md`). El nombre
-  temático es más informativo que `EXAMPLES.md`.
-- El skill es un how-to procedural sin antipatrones contrastables.
-- El skill tiene < 80 líneas en SKILL.md y los ejemplos caben en línea.
-
----
-
-## Estructura recomendada
-
-```
-habilidades/<skill-name>/
-├── SKILL.md
-└── recursos/
-    └── EXAMPLES.md
-```
-
-`SKILL.md` enlaza al final con:
-
-```markdown
-Para ejemplos concretos de aplicación, ver [`recursos/EXAMPLES.md`](recursos/EXAMPLES.md).
-```
-
-`EXAMPLES.md` contiene 2-4 ejemplos siguiendo el patrón:
-
-```markdown
-## Ejemplo N — [título corto del escenario]
-
-**Contexto**: [1-2 líneas]
-
-### ❌ Sin <skill-name> (hipotético)
-[código o descripción del enfoque incorrecto + consecuencia observable]
-
-### ✓ Con <skill-name>
-[código o descripción del enfoque correcto + por qué evita la consecuencia]
-```
-
-Cierre de `EXAMPLES.md`: tabla resumen de los ejemplos con la dimensión
-clave que cambió (costo, tiempo, severidad de bug, etc.).
-
----
-
-## Por qué OPCIONAL y no obligatoria
-
-- 63 carpetas `recursos/` ya existen con nomenclatura temática
-  (`anti-patrones-y-leyes.md`, `frameworks-seguridad.md`,
-  `idiomas-framework.md`). Forzar `EXAMPLES.md` rompería información
-  semántica del nombre.
-- La regla core `reglas/skills-estandar.md` ya prescribe que `SKILL.md`
-  no exceda 300 líneas y que los `recursos/` se nombren en kebab-case
-  con sufijo `.md` — esa regla cubre el 95% de los casos.
-- Esta convención **complementa** la regla core para skills donde un nombre
-  semántico genérico (`EXAMPLES.md`) comunica mejor el contenido que un
-  nombre específico (ej: `casos-decisiones-arquitecturales.md` es más largo
-  y menos buscable).
-
----
-
-## Origen
-
-Patrón observado en repos externos analizados el 2026-05-09
-(`temp/agent-skills-main`, `temp/andrej-karpathy-skills-main`):
-varios skills críticos exponen un `EXAMPLES.md` con diffs MAL/BIEN
-auto-cargable como referencia rápida del agente.
-
-Adoptado en `habilidades/doubt-driven-review/recursos/EXAMPLES.md` como
-primera aplicación. Casos futuros: skills de decisiones arquitecturales,
-seguridad, debugging avanzado.
+# Convención `EXAMPLES.md` — recurso opcional para skills críticos
+
+Convención **opcional** para skills cuyo valor depende de ejemplos concretos
+con diff MAL → BIEN. Esta convención NO es retroactiva: las 63 carpetas
+`recursos/` existentes en `habilidades/` no se renombran. Solo aplica a:
+
+- Skills nuevos cuyo dominio se entiende mejor con ejemplos lado a lado.
+- Skills existentes que reciban actualización mayor y agreguen ejemplos.
+
+---
+
+## Cuándo aplicarla
+
+Aplicar cuando:
+
+- El skill prescribe **decisiones técnicas** o **patrones** cuyo error es
+  sutil sin un caso concreto (ej: anti-patrones de async, gotchas de framework,
+  decisiones arquitecturales).
+- El skill se beneficia de mostrar 2-4 ejemplos lado a lado: el caso aplicado
+  correctamente vs el caso degenerado.
+- Los ejemplos suman > 100 líneas y meterlos en SKILL.md lo pasaría del
+  límite de 300 líneas.
+
+NO aplicar cuando:
+
+- El skill ya tiene `recursos/` con archivos temáticos específicos
+  (ej: `meta-skills-estandar/recursos/anti-patrones-y-leyes.md`). El nombre
+  temático es más informativo que `EXAMPLES.md`.
+- El skill es un how-to procedural sin antipatrones contrastables.
+- El skill tiene < 80 líneas en SKILL.md y los ejemplos caben en línea.
+
+---
+
+## Estructura recomendada
+
+```
+habilidades/<skill-name>/
+├── SKILL.md
+└── recursos/
+    └── EXAMPLES.md
+```
+
+`SKILL.md` enlaza al final con:
+
+```markdown
+Para ejemplos concretos de aplicación, ver [`recursos/EXAMPLES.md`](recursos/EXAMPLES.md).
+```
+
+`EXAMPLES.md` contiene 2-4 ejemplos siguiendo el patrón:
+
+```markdown
+## Ejemplo N — [título corto del escenario]
+
+**Contexto**: [1-2 líneas]
+
+### ❌ Sin <skill-name> (hipotético)
+[código o descripción del enfoque incorrecto + consecuencia observable]
+
+### ✓ Con <skill-name>
+[código o descripción del enfoque correcto + por qué evita la consecuencia]
+```
+
+Cierre de `EXAMPLES.md`: tabla resumen de los ejemplos con la dimensión
+clave que cambió (costo, tiempo, severidad de bug, etc.).
+
+---
+
+## Por qué OPCIONAL y no obligatoria
+
+- 63 carpetas `recursos/` ya existen con nomenclatura temática
+  (`anti-patrones-y-leyes.md`, `frameworks-seguridad.md`,
+  `idiomas-framework.md`). Forzar `EXAMPLES.md` rompería información
+  semántica del nombre.
+- La regla core `reglas/skills-estandar.md` ya prescribe que `SKILL.md`
+  no exceda 300 líneas y que los `recursos/` se nombren en kebab-case
+  con sufijo `.md` — esa regla cubre el 95% de los casos.
+- Esta convención **complementa** la regla core para skills donde un nombre
+  semántico genérico (`EXAMPLES.md`) comunica mejor el contenido que un
+  nombre específico (ej: `casos-decisiones-arquitecturales.md` es más largo
+  y menos buscable).
+
+---
+
+## Origen
+
+Patrón observado en repos externos analizados el 2026-05-09
+(`temp/agent-skills-main`, `temp/andrej-karpathy-skills-main`):
+varios skills críticos exponen un `EXAMPLES.md` con diffs MAL/BIEN
+auto-cargable como referencia rápida del agente.
+
+Adoptado en `habilidades/doubt-driven-review/recursos/EXAMPLES.md` como
+primera aplicación. Casos futuros: skills de decisiones arquitecturales,
+seguridad, debugging avanzado.