@saulwade/swl-ses 2.6.1 → 2.8.0

package/habilidades/doubt-driven-review/recursos/EXAMPLES.md

@@ -1,130 +1,130 @@
-# EXAMPLES — Doubt-Driven Review
-
-Tres aplicaciones concretas del skill, dos exitosas y una que detectó decisión bajo-evidencia.
-
----
-
-## Ejemplo 1 — Decisión que pasó como ROBUSTA
-
-**Contexto**: equipo evalúa migrar de PostgreSQL local a un servicio managed (RDS).
-
-### ❌ Sin doubt-driven (hipotético)
-
-> "RDS es la mejor opción porque AWS lo recomienda y todos lo usan."
-
-Costo de revertir no estimado, alternativas no articuladas, cero contraevidencia.
-Decisión se toma. 8 meses después se descubre que la latencia p95 desde el
-único cluster on-premise legacy del cliente sube 40ms y rompe SLA.
-
-### ✓ Con doubt-driven
-
-**Paso 1 — Articular**:
-- Qué se decide: migrar a RDS Aurora PostgreSQL en us-east-1.
-- Qué se descarta: mantener PostgreSQL self-hosted en EC2.
-- Costo de revertir: ~3 semanas (migrar datos de vuelta, reconfigurar backups, ajustar IAM).
-
-**Paso 2 — 3 alternativas**:
-1. **Self-hosted PostgreSQL en EC2**: control total de versión y extensiones; descartada
-   por costo operativo (on-call para BD).
-2. **Cloud SQL en GCP**: feature parity con RDS; descartada porque el resto del
-   stack ya está en AWS y multi-cloud agrega complejidad de red.
-3. **Supabase managed**: incluye Auth + Realtime gratis; descartada porque el
-   equipo no necesita Realtime y el lock-in en API propietario es alto.
-
-**Paso 3 — Contraevidencia**:
-- Falla 1 (prob: media): vendor lock-in si Aurora introduce features no portables → mitigación: limitar uso a SQL estándar.
-- Falla 2 (prob: baja): outage regional de us-east-1 → mitigación: read replica en us-west-2.
-- Falla 3 (prob: baja): costo de I/O excede presupuesto → mitigación: alertas de costo en CloudWatch.
-- Caso histórico: cliente X migró a RDS, descubrió que `pg_cron` no estaba disponible y refactoró 3 jobs.
-- Supuesto sin validar: "la latencia desde nuestros clientes on-premise será aceptable" — necesita pruebas reales.
-
-**Paso 4 — Red flags**: ninguno. Cada argumento está respaldado con caso o métrica.
-
-**Paso 5 — Trigger**:
-- Condición: "p95 de latencia desde el cliente legacy excede 200ms durante 7 días consecutivos" o "costo mensual supera $1500".
-- Fecha de reevaluación: 2026-11-15 (6 meses).
-
-**Veredicto**: ROBUSTA con 1 supuesto pendiente de validar (latencia on-premise → ejecutar prueba antes de migrar).
-
----
-
-## Ejemplo 2 — Decisión BAJO-EVIDENCIA detectada
-
-**Contexto**: agente propone "vamos a usar Kafka para todos los flujos asíncronos del sistema."
-
-**Paso 1 — Articular**:
-- Qué se decide: introducir Apache Kafka como broker único.
-- Qué se descarta: Redis Streams + RabbitMQ ya existentes en el stack.
-- Costo de revertir: alto — requiere rehacer 12 productores y 8 consumidores.
-
-**Paso 2 — 3 alternativas**: el agente solo articula 1 (RabbitMQ) y dice "los demás
-no son comparables." → **Red flag**: incapacidad de articular 3 alternativas reales.
-
-**Paso 3 — Contraevidencia**: el agente dice "Kafka nunca falla en producción
-porque tiene replication." → **Red flag**: argumento sin caso histórico.
-
-**Paso 4 — Red flags**:
-- "Es la mejor práctica para event-driven architectures" (sin fuente).
-- "Todo el mundo lo usa a escala" (sin métrica del proyecto actual).
-- "No hay otra opción razonable" (contradicho por el paso 2 incompleto).
-
-**Paso 5 — Trigger**: "cuando lo necesitemos a más escala" — **Trigger inverificable**.
-Reescribir como "throughput supera 10k msg/s sostenido durante 14 días."
-
-**Veredicto**: BAJO-EVIDENCIA. Reabrir antes de comprometer.
-
-Resultado real: la decisión se difiere; al revisar, se descubre que el throughput
-actual del sistema es ~80 msg/s — Kafka habría sido sobre-ingeniería con costo
-operativo de un cluster que el equipo no tiene capacidad de mantener.
-
----
-
-## Ejemplo 3 — Decisión ACEPTABLE con red flag documentado
-
-**Contexto**: elegir framework frontend para un dashboard interno nuevo.
-
-**Paso 1**:
-- Qué se decide: Next.js App Router + Server Components.
-- Qué se descarta: SPA con Vite + React Query.
-- Costo de revertir: medio — 2 semanas de migración + reescritura de data fetching.
-
-**Paso 2 — 3 alternativas**:
-1. **SPA Vite + React Query**: más simple, menos magia; descartada porque queremos SSR para SEO interno y autenticación server-side.
-2. **Remix**: nested routing nativo; descartada porque el equipo ya tiene experiencia con Next.js y la curva de Remix agrega 2 semanas.
-3. **Astro con islands**: ideal si fuera contenido estático; descartada porque el dashboard es 80% interactivo.
-
-**Paso 3 — Contraevidencia**:
-- Falla 1 (prob: media): App Router introduce breaking changes y rompe el build (ya pasó con v13→v14).
-- Falla 2 (prob: baja): RSC mental model genera bugs sutiles de hidratación.
-- Falla 3 (prob: baja): vendor lock-in con Vercel — mitigación: deploy en Cloudflare Workers o self-hosted.
-- Caso histórico: equipo Y adoptó App Router en beta y tardó 3 meses en estabilizar.
-- Supuesto: "el equipo aprenderá RSC en 2 sprints" — moderadamente optimista.
-
-**Paso 4 — Red flags**:
-- "App Router es el futuro" (cita de blog post de Vercel — sesgo de fuente).
-
-**Paso 5 — Trigger**:
-- Condición: "≥3 bugs de hidratación reportados por usuarios en sprint 5" O "Vercel
-  anuncia deprecation de App Router".
-- Fecha de reevaluación: 2026-08-15 (3 meses, periodo corto por uso de feature reciente).
-
-**Veredicto**: ACEPTABLE — 1 red flag documentado (cita de Vercel como fuente única
-para "futuro"). El equipo procede con awareness del sesgo.
-
----
-
-## Patrón de aplicación
-
-| Ejemplo | Costo revertir | Alternativas articuladas | Red flags | Trigger | Veredicto |
-|---|---|---|---|---|---|
-| 1 — RDS | 3 semanas | 3 sólidas | 0 | Métrico claro | ROBUSTA |
-| 2 — Kafka | 12+8 servicios | 1 (incompleto) | 3 | Inverificable | BAJO-EVIDENCIA |
-| 3 — Next.js | 2 semanas | 3 sólidas | 1 (sesgo de fuente) | Métrico + evento externo | ACEPTABLE |
-
-El skill es útil cuando:
-- El costo de revertir es alto Y
-- Hay tendencia a saltar al "qué" sin articular el "por qué no las otras".
-
-Es overhead cuando:
-- La decisión es reversible en horas O
-- La decisión ya fue auditada por un proceso equivalente (ADR formal con contexto + alternativas + consecuencias).
+# EXAMPLES — Doubt-Driven Review
+
+Tres aplicaciones concretas del skill, dos exitosas y una que detectó decisión bajo-evidencia.
+
+---
+
+## Ejemplo 1 — Decisión que pasó como ROBUSTA
+
+**Contexto**: equipo evalúa migrar de PostgreSQL local a un servicio managed (RDS).
+
+### ❌ Sin doubt-driven (hipotético)
+
+> "RDS es la mejor opción porque AWS lo recomienda y todos lo usan."
+
+Costo de revertir no estimado, alternativas no articuladas, cero contraevidencia.
+Decisión se toma. 8 meses después se descubre que la latencia p95 desde el
+único cluster on-premise legacy del cliente sube 40ms y rompe SLA.
+
+### ✓ Con doubt-driven
+
+**Paso 1 — Articular**:
+- Qué se decide: migrar a RDS Aurora PostgreSQL en us-east-1.
+- Qué se descarta: mantener PostgreSQL self-hosted en EC2.
+- Costo de revertir: ~3 semanas (migrar datos de vuelta, reconfigurar backups, ajustar IAM).
+
+**Paso 2 — 3 alternativas**:
+1. **Self-hosted PostgreSQL en EC2**: control total de versión y extensiones; descartada
+   por costo operativo (on-call para BD).
+2. **Cloud SQL en GCP**: feature parity con RDS; descartada porque el resto del
+   stack ya está en AWS y multi-cloud agrega complejidad de red.
+3. **Supabase managed**: incluye Auth + Realtime gratis; descartada porque el
+   equipo no necesita Realtime y el lock-in en API propietario es alto.
+
+**Paso 3 — Contraevidencia**:
+- Falla 1 (prob: media): vendor lock-in si Aurora introduce features no portables → mitigación: limitar uso a SQL estándar.
+- Falla 2 (prob: baja): outage regional de us-east-1 → mitigación: read replica en us-west-2.
+- Falla 3 (prob: baja): costo de I/O excede presupuesto → mitigación: alertas de costo en CloudWatch.
+- Caso histórico: cliente X migró a RDS, descubrió que `pg_cron` no estaba disponible y refactoró 3 jobs.
+- Supuesto sin validar: "la latencia desde nuestros clientes on-premise será aceptable" — necesita pruebas reales.
+
+**Paso 4 — Red flags**: ninguno. Cada argumento está respaldado con caso o métrica.
+
+**Paso 5 — Trigger**:
+- Condición: "p95 de latencia desde el cliente legacy excede 200ms durante 7 días consecutivos" o "costo mensual supera $1500".
+- Fecha de reevaluación: 2026-11-15 (6 meses).
+
+**Veredicto**: ROBUSTA con 1 supuesto pendiente de validar (latencia on-premise → ejecutar prueba antes de migrar).
+
+---
+
+## Ejemplo 2 — Decisión BAJO-EVIDENCIA detectada
+
+**Contexto**: agente propone "vamos a usar Kafka para todos los flujos asíncronos del sistema."
+
+**Paso 1 — Articular**:
+- Qué se decide: introducir Apache Kafka como broker único.
+- Qué se descarta: Redis Streams + RabbitMQ ya existentes en el stack.
+- Costo de revertir: alto — requiere rehacer 12 productores y 8 consumidores.
+
+**Paso 2 — 3 alternativas**: el agente solo articula 1 (RabbitMQ) y dice "los demás
+no son comparables." → **Red flag**: incapacidad de articular 3 alternativas reales.
+
+**Paso 3 — Contraevidencia**: el agente dice "Kafka nunca falla en producción
+porque tiene replication." → **Red flag**: argumento sin caso histórico.
+
+**Paso 4 — Red flags**:
+- "Es la mejor práctica para event-driven architectures" (sin fuente).
+- "Todo el mundo lo usa a escala" (sin métrica del proyecto actual).
+- "No hay otra opción razonable" (contradicho por el paso 2 incompleto).
+
+**Paso 5 — Trigger**: "cuando lo necesitemos a más escala" — **Trigger inverificable**.
+Reescribir como "throughput supera 10k msg/s sostenido durante 14 días."
+
+**Veredicto**: BAJO-EVIDENCIA. Reabrir antes de comprometer.
+
+Resultado real: la decisión se difiere; al revisar, se descubre que el throughput
+actual del sistema es ~80 msg/s — Kafka habría sido sobre-ingeniería con costo
+operativo de un cluster que el equipo no tiene capacidad de mantener.
+
+---
+
+## Ejemplo 3 — Decisión ACEPTABLE con red flag documentado
+
+**Contexto**: elegir framework frontend para un dashboard interno nuevo.
+
+**Paso 1**:
+- Qué se decide: Next.js App Router + Server Components.
+- Qué se descarta: SPA con Vite + React Query.
+- Costo de revertir: medio — 2 semanas de migración + reescritura de data fetching.
+
+**Paso 2 — 3 alternativas**:
+1. **SPA Vite + React Query**: más simple, menos magia; descartada porque queremos SSR para SEO interno y autenticación server-side.
+2. **Remix**: nested routing nativo; descartada porque el equipo ya tiene experiencia con Next.js y la curva de Remix agrega 2 semanas.
+3. **Astro con islands**: ideal si fuera contenido estático; descartada porque el dashboard es 80% interactivo.
+
+**Paso 3 — Contraevidencia**:
+- Falla 1 (prob: media): App Router introduce breaking changes y rompe el build (ya pasó con v13→v14).
+- Falla 2 (prob: baja): RSC mental model genera bugs sutiles de hidratación.
+- Falla 3 (prob: baja): vendor lock-in con Vercel — mitigación: deploy en Cloudflare Workers o self-hosted.
+- Caso histórico: equipo Y adoptó App Router en beta y tardó 3 meses en estabilizar.
+- Supuesto: "el equipo aprenderá RSC en 2 sprints" — moderadamente optimista.
+
+**Paso 4 — Red flags**:
+- "App Router es el futuro" (cita de blog post de Vercel — sesgo de fuente).
+
+**Paso 5 — Trigger**:
+- Condición: "≥3 bugs de hidratación reportados por usuarios en sprint 5" O "Vercel
+  anuncia deprecation de App Router".
+- Fecha de reevaluación: 2026-08-15 (3 meses, periodo corto por uso de feature reciente).
+
+**Veredicto**: ACEPTABLE — 1 red flag documentado (cita de Vercel como fuente única
+para "futuro"). El equipo procede con awareness del sesgo.
+
+---
+
+## Patrón de aplicación
+
+| Ejemplo | Costo revertir | Alternativas articuladas | Red flags | Trigger | Veredicto |
+|---|---|---|---|---|---|
+| 1 — RDS | 3 semanas | 3 sólidas | 0 | Métrico claro | ROBUSTA |
+| 2 — Kafka | 12+8 servicios | 1 (incompleto) | 3 | Inverificable | BAJO-EVIDENCIA |
+| 3 — Next.js | 2 semanas | 3 sólidas | 1 (sesgo de fuente) | Métrico + evento externo | ACEPTABLE |
+
+El skill es útil cuando:
+- El costo de revertir es alto Y
+- Hay tendencia a saltar al "qué" sin articular el "por qué no las otras".
+
+Es overhead cuando:
+- La decisión es reversible en horas O
+- La decisión ya fue auditada por un proceso equivalente (ADR formal con contexto + alternativas + consecuencias).

package/habilidades/estructura-proyecto-claude/recursos/mcp-json-template.json

@@ -1,57 +1,57 @@
-{
-  "_comentario": "Template de .mcp.json para proyectos Claude-ready. Eliminar los servidores que no se usen. Las variables de entorno con valor vacío deben completarse en .env o exportarse antes de correr claude.",
-  "_instrucciones": [
-    "1. Copiar este archivo a la raíz del proyecto como .mcp.json",
-    "2. Eliminar el bloque _comentario y _instrucciones (no son JSON válido en producción)",
-    "3. Configurar las variables de entorno requeridas por cada servidor activo",
-    "4. Agregar .mcp.json al repositorio (no contiene secretos — los secretos van en env vars)",
-    "5. Agregar a .gitignore cualquier archivo .mcp.local.json con credenciales"
-  ],
-  "_nota_archivados": "Los reference servers @modelcontextprotocol/server-github, server-postgres, server-sqlite, server-brave-search y server-puppeteer fueron ARCHIVADOS por el proyecto MCP. No usarlos en proyectos nuevos — los reemplazos vigentes están abajo (GitHub remoto oficial, Playwright oficial de Microsoft).",
-  "mcpServers": {
-    "context7": {
-      "_descripcion": "Documentación actualizada de librerías. Uso: 'use context7' en el prompt.",
-      "command": "npx",
-      "args": ["-y", "@upstash/context7-mcp@latest"]
-    },
-    "github": {
-      "_descripcion": "GitHub MCP server oficial (remoto): issues, PRs, repos, commits. Reemplaza al archivado @modelcontextprotocol/server-github. Autenticación OAuth al conectar, o PAT vía header.",
-      "type": "http",
-      "url": "https://api.githubcopilot.com/mcp/"
-    },
-    "playwright": {
-      "_descripcion": "Control de navegador con Playwright (oficial de Microsoft). Testing E2E, scraping, automatización web. Reemplaza al archivado server-puppeteer.",
-      "_activar": "Requiere Node 18+ — descarga browsers en el primer uso",
-      "command": "npx",
-      "args": ["-y", "@playwright/mcp@latest"]
-    },
-    "filesystem": {
-      "_descripcion": "Acceso a sistema de archivos fuera del directorio de trabajo. Usar con cuidado.",
-      "_activar": "Descomentar solo si se necesita acceso a paths fuera del proyecto",
-      "command": "npx",
-      "args": [
-        "-y",
-        "@modelcontextprotocol/server-filesystem",
-        "/ruta/al/directorio/permitido"
-      ]
-    },
-    "fetch": {
-      "_descripcion": "Extracción y conversión de contenido web a markdown.",
-      "_activar": "Útil cuando WebFetch nativo no basta (contenido que requiere conversión estructurada)",
-      "command": "npx",
-      "args": ["-y", "@modelcontextprotocol/server-fetch"]
-    },
-    "memory": {
-      "_descripcion": "Memoria persistente entre sesiones. Almacena entidades y relaciones en grafo.",
-      "_activar": "Útil para proyectos largos donde se quiere persistir contexto entre sesiones",
-      "command": "npx",
-      "args": ["-y", "@modelcontextprotocol/server-memory"]
-    },
-    "sequential-thinking": {
-      "_descripcion": "Herramienta de razonamiento estructurado para problemas complejos.",
-      "_activar": "Útil para arquitectura, debugging complejo, decisiones de diseño",
-      "command": "npx",
-      "args": ["-y", "@modelcontextprotocol/server-sequential-thinking"]
-    }
-  }
-}
+{
+  "_comentario": "Template de .mcp.json para proyectos Claude-ready. Eliminar los servidores que no se usen. Las variables de entorno con valor vacío deben completarse en .env o exportarse antes de correr claude.",
+  "_instrucciones": [
+    "1. Copiar este archivo a la raíz del proyecto como .mcp.json",
+    "2. Eliminar el bloque _comentario y _instrucciones (no son JSON válido en producción)",
+    "3. Configurar las variables de entorno requeridas por cada servidor activo",
+    "4. Agregar .mcp.json al repositorio (no contiene secretos — los secretos van en env vars)",
+    "5. Agregar a .gitignore cualquier archivo .mcp.local.json con credenciales"
+  ],
+  "_nota_archivados": "Los reference servers @modelcontextprotocol/server-github, server-postgres, server-sqlite, server-brave-search y server-puppeteer fueron ARCHIVADOS por el proyecto MCP. No usarlos en proyectos nuevos — los reemplazos vigentes están abajo (GitHub remoto oficial, Playwright oficial de Microsoft).",
+  "mcpServers": {
+    "context7": {
+      "_descripcion": "Documentación actualizada de librerías. Uso: 'use context7' en el prompt.",
+      "command": "npx",
+      "args": ["-y", "@upstash/context7-mcp@latest"]
+    },
+    "github": {
+      "_descripcion": "GitHub MCP server oficial (remoto): issues, PRs, repos, commits. Reemplaza al archivado @modelcontextprotocol/server-github. Autenticación OAuth al conectar, o PAT vía header.",
+      "type": "http",
+      "url": "https://api.githubcopilot.com/mcp/"
+    },
+    "playwright": {
+      "_descripcion": "Control de navegador con Playwright (oficial de Microsoft). Testing E2E, scraping, automatización web. Reemplaza al archivado server-puppeteer.",
+      "_activar": "Requiere Node 18+ — descarga browsers en el primer uso",
+      "command": "npx",
+      "args": ["-y", "@playwright/mcp@latest"]
+    },
+    "filesystem": {
+      "_descripcion": "Acceso a sistema de archivos fuera del directorio de trabajo. Usar con cuidado.",
+      "_activar": "Descomentar solo si se necesita acceso a paths fuera del proyecto",
+      "command": "npx",
+      "args": [
+        "-y",
+        "@modelcontextprotocol/server-filesystem",
+        "/ruta/al/directorio/permitido"
+      ]
+    },
+    "fetch": {
+      "_descripcion": "Extracción y conversión de contenido web a markdown.",
+      "_activar": "Útil cuando WebFetch nativo no basta (contenido que requiere conversión estructurada)",
+      "command": "npx",
+      "args": ["-y", "@modelcontextprotocol/server-fetch"]
+    },
+    "memory": {
+      "_descripcion": "Memoria persistente entre sesiones. Almacena entidades y relaciones en grafo.",
+      "_activar": "Útil para proyectos largos donde se quiere persistir contexto entre sesiones",
+      "command": "npx",
+      "args": ["-y", "@modelcontextprotocol/server-memory"]
+    },
+    "sequential-thinking": {
+      "_descripcion": "Herramienta de razonamiento estructurado para problemas complejos.",
+      "_activar": "Útil para arquitectura, debugging complejo, decisiones de diseño",
+      "command": "npx",
+      "args": ["-y", "@modelcontextprotocol/server-sequential-thinking"]
+    }
+  }
+}

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.8"
+version: "1.0.9"
 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."
@@ -305,6 +305,8 @@ Durante `/swl:aprender`, aplicar estas reglas:
 
   **Modo F — sub-agente con mandato explícito de SOLO LECTURA ejecuta un comando destructivo** (caso real 2026-07-11): un agente de auditoría lanzado con "PROHIBIDO modificar cualquier archivo o la BD; solo Read/Grep/Glob y SELECT" ejecutó (vía un sub-agente anidado propio) un `rm -f` que borró un PNG de evidencia en la raíz del repo. El archivo estaba SIN TRACKEAR en git → irrecuperable (los tracked se restauran con `git checkout --`; los untracked no tienen red de seguridad). El agente REPORTÓ el incidente con honestidad en su resultado final — pero el daño ya estaba hecho. Causa: el mandato en el prompt es una instrucción, no una contención; los agentes anidados heredan herramientas, no disciplina. Diferencia con el Modo E: allí el riesgo era aceptar un reporte incompleto; aquí es daño colateral directo al workspace. Patrón doble: (1) `git status` comparativo tras CADA agente; (2) ANTES de lanzar agentes sobre un working tree con archivos untracked valiosos, protegerlos primero — commitearlos, moverlos fuera del repo o copiarlos (el trabajo sin commitear es la única víctima sin recuperación posible).
 
+  **Modo G — revisores adversariales en paralelo verifican la LÓGICA de un módulo pero nunca RE-DERIVAN el número que reporta** (caso real 2026-07-17, swl-ses F32-T07): 4 revisores adversariales corriendo en paralelo (incluido un agente `abogado-diablo-swl` con mandato explícito de refutar) auditaron un motor de mutation testing que reportaba mutation score 100% en 7 de 20 módulos críticos. Los 4 revisaron la lógica del clasificador, el manejo de errores y la cobertura de casos — ninguno detectó que esos 7 módulos "100%" nunca corrían un solo mutante real: todos morían por `MODULE_NOT_FOUND` de un entorno mal aislado, y el clasificador contaba esos fallos como kills. El bug solo apareció cuando el orquestador (no un revisor) reprodujo el cómputo en aislamiento (`ejecutarMutationTesting({modulos:[unicoModulo]})`) para cada módulo "100%" y confirmó que fallaban los 7. Causa: revisar código verifica que la LÓGICA sea razonable; no verifica que la CIFRA agregada que esa lógica produjo sea real — son preguntas distintas, y un panel de revisores de código, por más adversarial que sea, responde la primera, no la segunda. Diferencia con el Modo C (ubicaciones/severidades incorrectas): ahí el revisor mira código y se equivoca sobre el código; aquí el revisor mira código, tiene razón sobre el código, y el bug vive en la intersección entre el código y el entorno de ejecución — invisible sin ejecutar.
+
   **Solución unificada — protocolo de verificación de afirmaciones factuales antes de aceptar propuesta de CUALQUIER sub-agente**:
 
   *Patrón obligatorio aplicable a TODOS los modos*: extraer 2-3 afirmaciones factuales del reporte del sub-agente y verificar cada una con primitivas baratas (`Grep`/`Read`/`wc -l`/`ls`/`git log`) ANTES de aceptar el plan o acción. Tipos de afirmaciones a verificar:
@@ -322,6 +324,8 @@ Durante `/swl:aprender`, aplicar estas reglas:
   *Para agentes de documentación (Modo D)*: todo veredicto **NO-EXISTE / NO-SOPORTADO** sobre una feature de un producto externo exige cita a la doc oficial consultada EN ese turno (URL + extracto). Si el agente "verifica" solo contra el contexto local (configs del usuario, código del repo), su veredicto es inferencia, no verificación — re-verificar con 1 WebFetch a la doc oficial antes de tomar decisiones de diseño sobre él. Regla mnemónica: *ausencia en mi config ≠ ausencia en el producto*.
 
   *Para agentes de implementación en worktree (Modo E)*: cualquier frase tipo "no pude correr X", "el entorno no tenía Y", "solo verifiqué con Z" en el reporte final es una señal de PRIORIDAD MÁXIMA — re-ejecutar exactamente lo que el agente no pudo ejecutar (suite de tests completa, no solo el archivo que tocó) con el entorno correcto del checkout principal ANTES de dar el trabajo por terminado. Nunca degradar esa frase a "nota informativa" solo porque el resto del reporte suena confiado.
+
+  *Para paneles de revisores adversariales sobre un claim NUMÉRICO/AGREGADO (Modo G)*: cuando el artefacto bajo revisión reporta un score, porcentaje o conteo derivado de una corrida (mutation score, cobertura, latencia p95, tasa de éxito), el patrón obligatorio de "verificar 2-3 afirmaciones con Grep/Read" NO alcanza — hay que re-derivar la cifra en un subconjunto aislado y mínimo (un solo módulo, un solo caso) ANTES de aceptar el agregado. Un panel de revisores que solo lee el código del cómputo, sin ejecutar ni un fragmento, no puede detectar bugs que viven en la intersección código↔entorno.
 - **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.

package/habilidades/feynman-auditor-swl/recursos/preguntas-language-agnostic.md

@@ -1,108 +1,108 @@
-# Preguntas Feynman — Language-Agnostic
-
-28 preguntas organizadas en 7 categorías. Aplicar a cada función no trivial del módulo bajo auditoría.
-
----
-
-## Q1 — Propósito
-
-**Q1.1** ¿Qué hace exactamente esta función y solo esta función? Si no puedo describirla en una oración sin usar "y", ¿tiene demasiadas responsabilidades?
-
-**Q1.2** ¿Cuál es el invariante que esta función garantiza al terminar? ¿El código lo garantiza de verdad o solo en el camino feliz?
-
-**Q1.3** ¿Hay alguna condición en que esta función debería rechazar la operación pero no lo hace? ¿Qué pasa si se la llama dos veces seguidas con los mismos argumentos?
-
-**Q1.4** ¿Esta función asume que el estado del sistema está en alguna condición particular antes de ejecutarse? ¿Dónde se verifica esa condición?
-
----
-
-## Q2 — Orden de operaciones
-
-**Q2.1** ¿Importa el orden en que estas líneas se ejecutan? Si cambio el orden de dos líneas adyacentes, ¿el resultado es el mismo?
-
-**Q2.2** ¿Esta función lee un valor y luego lo modifica? Si algo cambia el valor entre la lectura y la escritura, ¿qué pasa?
-
-**Q2.3** ¿El cálculo de recompensa, crédito, o resultado se hace ANTES o DESPUÉS de actualizar el estado base? ¿Debería ser al revés?
-
-**Q2.4** ¿Si esta función llama a un sistema externo (BD, API, caché), el estado local ya está actualizado en ese momento? ¿El sistema externo puede ver un estado inconsistente?
-
----
-
-## Q3 — Consistencia cross-función
-
-**Q3.1** ¿Qué tienen en común esta función y otra que hace algo similar? ¿Una tiene un guard o una actualización que la otra no tiene?
-
-**Q3.2** ¿Existe una función de "camino normal" y una de "camino de emergencia/admin"? ¿Ambas actualizan exactamente el mismo conjunto de estado?
-
-**Q3.3** ¿Esta función inicializa todos los campos que otras funciones esperan encontrar inicializados? ¿Hay algún campo que se lee antes de ser escrito?
-
-**Q3.4** ¿El path que crea un recurso y el path que lo elimina dejan el sistema en un estado simétrico? ¿O el delete deja huérfanos?
-
----
-
-## Q4 — Asunciones implícitas
-
-**Q4.1** ¿Qué asume este código sobre el tipo o el rango del argumento que recibe? ¿Hay alguna validación que debería existir pero no existe?
-
-**Q4.2** ¿El código asume que el actor que llama esta función tiene permiso para hacerlo? ¿Dónde se verifica ese permiso exactamente?
-
-**Q4.3** ¿El código asume que algún recurso externo (BD, archivo, servicio) está disponible y en un estado consistente? ¿Qué pasa si no lo está?
-
-**Q4.4** ¿El código asume que nunca se llamará con valor cero, lista vacía, o string vacío? ¿Se validó eso?
-
----
-
-## Q5 — Límites y casos de borde
-
-**Q5.1** ¿Qué pasa si el valor es exactamente cero? ¿Y si es el máximo representable? ¿Y si es negativo?
-
-**Q5.2** ¿Qué pasa si la lista o colección está vacía? ¿Y si tiene exactamente un elemento? ¿Y si tiene millones?
-
-**Q5.3** ¿Qué pasa si el recurso ya existe cuando se intenta crear? ¿Y si no existe cuando se intenta modificar o eliminar?
-
-**Q5.4** ¿Qué pasa si dos actores ejecutan esta función al mismo tiempo? ¿Hay condición de carrera? ¿El resultado es determinista?
-
----
-
-## Q6 — Returns y manejo de errores
-
-**Q6.1** ¿Qué devuelve esta función cuando el input es inválido? ¿Lanza excepción, devuelve null, devuelve un error tipado, o silencia el problema?
-
-**Q6.2** ¿Si una operación parcial falla a mitad de camino, el estado queda consistente? ¿Hay rollback? ¿O el sistema queda a medias?
-
-**Q6.3** ¿El caller de esta función verifica el valor de retorno? ¿Un error no verificado puede causar daño silencioso más adelante?
-
-**Q6.4** ¿El código captura excepciones de forma demasiado amplia (`except Exception`, `catch (e)` vacío)? ¿Qué errores legítimos podría estar silenciando?
-
----
-
-## Q7 — Interacciones externas
-
-**Q7.1** ¿Esta función llama a un sistema externo (BD, API, caché, cola)? ¿La llamada puede fallar? ¿Qué pasa con el estado local si falla?
-
-**Q7.2** ¿Esta función persiste datos en más de un lugar (ej: BD + caché + índice)? ¿Qué pasa si la segunda escritura falla después de que la primera tuvo éxito?
-
-**Q7.3** ¿El acumulador o índice que esta función usa se actualiza ANTES de modificar el valor base, o DESPUÉS? ¿El orden importa para la correctitud del cálculo?
-
-**Q7.4** ¿Esta función envía una notificación, evento, o mensaje a otro sistema? ¿Lo hace antes o después de confirmar la operación? ¿El receptor puede actuar sobre un estado que aún no se confirmó?
-
-**Q7.5** ¿Esta función lee un valor de caché y lo trata como fresco? ¿Hay algún path donde la caché puede estar desactualizada respecto a la fuente de verdad?
-
-**Q7.6** ¿Esta función modifica datos de otro actor además de los del actor que la llama? ¿Tiene permiso para hacerlo en todos los casos?
-
-**Q7.7** ¿Existe un patrón de acumulador donde el total acumulado se calcula con base en el estado anterior? Si el estado base cambia (insert/update/delete de otro registro), ¿el acumulador refleja el cambio correctamente?
-
-**Q7.8** ¿Esta función delega a otra función que tiene sus propios efectos secundarios? ¿El caller sabe qué estado modifica el callee internamente?
-
----
-
-## Cómo usar estas preguntas
-
-1. Leer la función completa una vez para entender el propósito.
-2. Para cada pregunta de las categorías Q1–Q7, marcar:
-   - ✓ Respondida claramente por el código
-   - ? Requiere rastrear el caller o el sistema externo para responder
-   - ✗ El código no la responde — sospechoso de bug
-3. Todo `✗` o `?` sin resolver es un **sospechoso** para Fase 3 de síntesis.
-
-<!-- Adaptado de nemesis-auditor-main bajo MIT License (https://github.com/0xiehnnkta/nemesis-auditor) -->
+# Preguntas Feynman — Language-Agnostic
+
+28 preguntas organizadas en 7 categorías. Aplicar a cada función no trivial del módulo bajo auditoría.
+
+---
+
+## Q1 — Propósito
+
+**Q1.1** ¿Qué hace exactamente esta función y solo esta función? Si no puedo describirla en una oración sin usar "y", ¿tiene demasiadas responsabilidades?
+
+**Q1.2** ¿Cuál es el invariante que esta función garantiza al terminar? ¿El código lo garantiza de verdad o solo en el camino feliz?
+
+**Q1.3** ¿Hay alguna condición en que esta función debería rechazar la operación pero no lo hace? ¿Qué pasa si se la llama dos veces seguidas con los mismos argumentos?
+
+**Q1.4** ¿Esta función asume que el estado del sistema está en alguna condición particular antes de ejecutarse? ¿Dónde se verifica esa condición?
+
+---
+
+## Q2 — Orden de operaciones
+
+**Q2.1** ¿Importa el orden en que estas líneas se ejecutan? Si cambio el orden de dos líneas adyacentes, ¿el resultado es el mismo?
+
+**Q2.2** ¿Esta función lee un valor y luego lo modifica? Si algo cambia el valor entre la lectura y la escritura, ¿qué pasa?
+
+**Q2.3** ¿El cálculo de recompensa, crédito, o resultado se hace ANTES o DESPUÉS de actualizar el estado base? ¿Debería ser al revés?
+
+**Q2.4** ¿Si esta función llama a un sistema externo (BD, API, caché), el estado local ya está actualizado en ese momento? ¿El sistema externo puede ver un estado inconsistente?
+
+---
+
+## Q3 — Consistencia cross-función
+
+**Q3.1** ¿Qué tienen en común esta función y otra que hace algo similar? ¿Una tiene un guard o una actualización que la otra no tiene?
+
+**Q3.2** ¿Existe una función de "camino normal" y una de "camino de emergencia/admin"? ¿Ambas actualizan exactamente el mismo conjunto de estado?
+
+**Q3.3** ¿Esta función inicializa todos los campos que otras funciones esperan encontrar inicializados? ¿Hay algún campo que se lee antes de ser escrito?
+
+**Q3.4** ¿El path que crea un recurso y el path que lo elimina dejan el sistema en un estado simétrico? ¿O el delete deja huérfanos?
+
+---
+
+## Q4 — Asunciones implícitas
+
+**Q4.1** ¿Qué asume este código sobre el tipo o el rango del argumento que recibe? ¿Hay alguna validación que debería existir pero no existe?
+
+**Q4.2** ¿El código asume que el actor que llama esta función tiene permiso para hacerlo? ¿Dónde se verifica ese permiso exactamente?
+
+**Q4.3** ¿El código asume que algún recurso externo (BD, archivo, servicio) está disponible y en un estado consistente? ¿Qué pasa si no lo está?
+
+**Q4.4** ¿El código asume que nunca se llamará con valor cero, lista vacía, o string vacío? ¿Se validó eso?
+
+---
+
+## Q5 — Límites y casos de borde
+
+**Q5.1** ¿Qué pasa si el valor es exactamente cero? ¿Y si es el máximo representable? ¿Y si es negativo?
+
+**Q5.2** ¿Qué pasa si la lista o colección está vacía? ¿Y si tiene exactamente un elemento? ¿Y si tiene millones?
+
+**Q5.3** ¿Qué pasa si el recurso ya existe cuando se intenta crear? ¿Y si no existe cuando se intenta modificar o eliminar?
+
+**Q5.4** ¿Qué pasa si dos actores ejecutan esta función al mismo tiempo? ¿Hay condición de carrera? ¿El resultado es determinista?
+
+---
+
+## Q6 — Returns y manejo de errores
+
+**Q6.1** ¿Qué devuelve esta función cuando el input es inválido? ¿Lanza excepción, devuelve null, devuelve un error tipado, o silencia el problema?
+
+**Q6.2** ¿Si una operación parcial falla a mitad de camino, el estado queda consistente? ¿Hay rollback? ¿O el sistema queda a medias?
+
+**Q6.3** ¿El caller de esta función verifica el valor de retorno? ¿Un error no verificado puede causar daño silencioso más adelante?
+
+**Q6.4** ¿El código captura excepciones de forma demasiado amplia (`except Exception`, `catch (e)` vacío)? ¿Qué errores legítimos podría estar silenciando?
+
+---
+
+## Q7 — Interacciones externas
+
+**Q7.1** ¿Esta función llama a un sistema externo (BD, API, caché, cola)? ¿La llamada puede fallar? ¿Qué pasa con el estado local si falla?
+
+**Q7.2** ¿Esta función persiste datos en más de un lugar (ej: BD + caché + índice)? ¿Qué pasa si la segunda escritura falla después de que la primera tuvo éxito?
+
+**Q7.3** ¿El acumulador o índice que esta función usa se actualiza ANTES de modificar el valor base, o DESPUÉS? ¿El orden importa para la correctitud del cálculo?
+
+**Q7.4** ¿Esta función envía una notificación, evento, o mensaje a otro sistema? ¿Lo hace antes o después de confirmar la operación? ¿El receptor puede actuar sobre un estado que aún no se confirmó?
+
+**Q7.5** ¿Esta función lee un valor de caché y lo trata como fresco? ¿Hay algún path donde la caché puede estar desactualizada respecto a la fuente de verdad?
+
+**Q7.6** ¿Esta función modifica datos de otro actor además de los del actor que la llama? ¿Tiene permiso para hacerlo en todos los casos?
+
+**Q7.7** ¿Existe un patrón de acumulador donde el total acumulado se calcula con base en el estado anterior? Si el estado base cambia (insert/update/delete de otro registro), ¿el acumulador refleja el cambio correctamente?
+
+**Q7.8** ¿Esta función delega a otra función que tiene sus propios efectos secundarios? ¿El caller sabe qué estado modifica el callee internamente?
+
+---
+
+## Cómo usar estas preguntas
+
+1. Leer la función completa una vez para entender el propósito.
+2. Para cada pregunta de las categorías Q1–Q7, marcar:
+   - ✓ Respondida claramente por el código
+   - ? Requiere rastrear el caller o el sistema externo para responder
+   - ✗ El código no la responde — sospechoso de bug
+3. Todo `✗` o `?` sin resolver es un **sospechoso** para Fase 3 de síntesis.
+
+<!-- Adaptado de nemesis-auditor-main bajo MIT License (https://github.com/0xiehnnkta/nemesis-auditor) -->