@saulwade/swl-ses 1.4.0 → 1.4.1

package/CLAUDE.md

@@ -1,4 +1,4 @@
-# CLAUDE.md — @saulwade/swl-ses v1.4.0
+# CLAUDE.md — @saulwade/swl-ses v1.4.1
 
 ## Reglas de máxima prioridad (aplican SIEMPRE, sin excepción)
 
@@ -92,7 +92,7 @@ El Read tool sigue siendo correcto para `.pdf` (≤20 páginas), `.md`, `.txt` y
 ## Qué es este repositorio
 
 Sistema de ingeniería de software auto-evolutivo multi-runtime polyglot (SDLC completo).
-11 lenguajes, 5 runtimes, 59 agentes, 155 skills, 43 comandos, 64 reglas, 41 hooks.
+11 lenguajes, 5 runtimes, 60 agentes, 158 skills, 44 comandos, 65 reglas, 41 hooks.
 
 ## Estructura del repositorio
 
@@ -123,7 +123,8 @@ Para la lista completa con descripción ver `@COMANDOS.md`. Comandos más usados
 | `/swl:claudemd` | Auditar/refactorizar/inicializar CLAUDE.md (audit, refactor, init-user, check) |
 | `/swl:aprender` / `/swl:evolucionar` / `/swl:autoresearch` | Aprendizaje y auto-evolución |
 | `/swl:salud` / `/swl:metricas` / `/swl:dashboard` | Diagnóstico y observabilidad |
-| `/swl:revisar` / `/swl:verificar` | Calidad de código (revisión por stack, verificación goal-backward) |
+| `/swl:revisar` / `/swl:verificar` | Calidad de código (revisión por stack, verificación goal-backward). `/swl:verificar --full` activa parallel scorecard con 4 audits paralelos |
+| `/swl:nemesis` | Auditoría iterativa Feynman + State Inconsistency (loop hasta convergencia, ADR-0018). Flags: `--pass1`, `--pass2`, `--continue`, `--modulo <ruta>` |
 | `/swl:release` | Ciclo de release SemVer |
 | `/swl:configurar-ci` | Workflows CI/CD para proyectos del usuario |
 | `/swl:wiki` / `/swl:mapear-codebase` | Conocimiento de proyecto |

package/README.md

@@ -1,4 +1,4 @@
-# swl-ses v1.4.0
+# swl-ses v1.4.1
 
 > 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.
 
@@ -6,17 +6,18 @@ Sistema de ingeniería de software auto-evolutivo **multi-runtime** con agentes
 
 Soporta 6 runtimes de IA: Claude Code, OpenClaude, OpenCode y Gemini CLI (soporte completo), GitHub Copilot y Codex CLI (soporte parcial: agentes, reglas, hooks experimentales y MCP). Incluye sistema de transformadores que adapta el formato canónico SWL al formato nativo de cada runtime.
 
-Cubre el SDLC completo: discovery, requisitos, arquitectura, UX/UI, frontend, backend, mobile, datos, testing, seguridad, CI/CD, observabilidad, releases, documentación, notificaciones y auto-evolución. Incluye sistema de notificaciones Telegram opt-in: hook saliente al terminar cada turno, bot bidireccional con 15 comandos y autostart en Windows, Linux y macOS sin privilegios elevados.
+Cubre el SDLC completo: discovery, requisitos, arquitectura, UX/UI, frontend, backend, mobile, datos, testing, seguridad, CI/CD, observabilidad, releases, documentación, notificaciones y auto-evolución. Incluye sistema de notificaciones Telegram opt-in (hook saliente, bot bidireccional con 15 comandos, autostart cross-platform) y **auditoría profunda Nemesis** (loop iterativo Feynman + State Inconsistency hasta convergencia) con 8 tools ejecutables JSON-output para code-profiler, pentest-scanner, dep-doctor, bundle-tracker y más (ADR-0018, v1.4.1).
 
 ## Inventario
 
 | Componente | Cantidad |
 |-----------|----------|
-| Agentes SWL | 59 |
-| Habilidades | 151 (todas <=300 líneas, con divulgación progresiva a recursos/) |
-| Comandos (/swl:*) | 42 (todos <=300 líneas, delegan a skills) |
-| Reglas | 20 base + 40 por lenguaje (8 lenguajes x 5) |
-| Hooks | 37 + 60 librerías en hooks/lib/ |
+| Agentes SWL | 60 |
+| Habilidades | 158 (todas <=300 líneas, con divulgación progresiva a recursos/) |
+| Comandos (/swl:*) | 44 (todos <=300 líneas, delegan a skills) |
+| Reglas | 25 base + 40 por lenguaje (8 lenguajes x 5) |
+| Hooks | 41 + 66 librerías en hooks/lib/ |
+| Tools ejecutables (audit-tools) | 8 (code-profiler, pentest-scanner, dep-doctor, bundle-tracker, env-validator, migration-checker, canary-monitor, audit-history) |
 | Schemas | 15 |
 | Perfiles de instalación | 17 |
 | Contextos | 3 (dev, review, research) |
@@ -177,7 +178,7 @@ claude
 | `mobile` | Android + iOS + React Native/Flutter + UX |
 | `devops` | CI/CD + cloud + observabilidad + releases + seguridad |
 | `polyglot` | Todos los lenguajes: 11 lenguajes + revisores + build resolvers |
-| `completo` | Todo: 59 agentes + 155 habilidades + 43 comandos + 64 reglas + 41 hooks |
+| `completo` | Todo: 60 agentes + 158 habilidades + 44 comandos + 65 reglas + 41 hooks |
 
 ### Targets soportados
 
@@ -477,12 +478,12 @@ swl-ses/
       manifiestos.js        # Resolución de perfiles/módulos
       seguridad.js          # Validaciones de seguridad
   manifiestos/              # Perfiles y módulos de instalación
-  agentes/                  # 59 agentes especializados
-  habilidades/              # 155 habilidades modulares
-  comandos/swl/             # 43 comandos slash
-  reglas/                   # 20 reglas base + 40 por lenguaje
-  hooks/                    # 39 hooks + 62 librerías en hooks/lib/
-  schemas/                  # 14 JSON Schemas
+  agentes/                  # 60 agentes especializados
+  habilidades/              # 158 habilidades modulares
+  comandos/swl/             # 44 comandos slash
+  reglas/                   # 25 reglas base + 40 por lenguaje
+  hooks/                    # 41 hooks + 66 librerías en hooks/lib/
+  schemas/                  # 15 JSON Schemas
   contextos/                # 3 modos de desarrollo
   instintos/                # Instintos YAML con confianza
   plantillas/               # Templates para .planning/

package/agentes/nemesis-auditor-swl.md

@@ -0,0 +1,161 @@
+---
+name: nemesis-auditor-swl
+description: >
+  Auditor de doble paso iterativo (Feynman + State Inconsistency) que encuentra
+  bugs en la intersección que ningún paso individual detecta. Language-agnostic
+  (Python, TypeScript, Go, Rust, Java, C#). Invocar tras revisor-codigo-swl y
+  revisor-seguridad-swl 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.0.0
+nivelRiesgo: MEDIO
+skillsInvocables: [feynman-auditor-swl, state-inconsistency-auditor-swl]
+permisosRed: false
+permisosEscritura: true
+permisosComandos: true
+maxTurnos: 20
+evolvable: true
+exclusiones:
+  - "No invocar para pattern-matching de CVEs conocidos — usar revisor-seguridad-swl."
+  - "No invocar para refactor o implementación — solo audita, no modifica código."
+  - "No invocar como sustituto de tests — Nemesis complementa, no reemplaza testing."
+  - "No invocar para análisis de blockchain — el agente fue generalizado a Python/TS/Go/Rust/Java/C#."
+---
+
+# Cuándo NO invocarme
+
+- Para búsqueda de vulnerabilidades conocidas (CVE, OWASP Top 10) — usar `revisor-seguridad-swl`.
+- Para refactor, limpiar deuda técnica o implementar funcionalidad nueva — Nemesis audita, no toca código.
+- 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).
+
+---
+
+# Nemesis Auditor
+
+Dos auditores en bucle de retroalimentación. Cada uno alimenta al siguiente con sus hallazgos. El ciclo continúa hasta que ninguno encuentre algo nuevo (convergencia) o se alcancen 6 pasadas.
+
+```
+PASADA 1: Feynman Auditor (corrida completa)
+  Cuestiona cada línea. Expone asunciones. Marca sospechosos.
+
+        | feed forward |
+
+PASADA 2: State Inconsistency Auditor (corrida completa, enriquecido por Pasada 1)
+  Mapea estado acoplado. Encuentra gaps de mutación. Usa sospechosos de Feynman como objetivos.
+
+        | feed forward |
+
+PASADA 3+: Pasadas alternantes dirigidas hasta convergencia
+  Cada pasada interroga los nuevos hallazgos de la anterior.
+  Máximo 6 pasadas. Nada sobrevive.
+```
+
+---
+
+## Proceso — Fase 0: Contexto
+
+Antes de la Pasada 1, establecer:
+
+1. ¿Qué archivos o módulos están en scope? (sin scope → el auditor infiere desde el directorio de trabajo)
+2. ¿Hay un comando específico (`/nemesis`, `/nemesis --pass1`, `/nemesis --pass2`, `/nemesis --continue`)?
+3. ¿Hay un target de un solo módulo (`/nemesis --contract <nombre>`)?
+4. ¿Existen hallazgos previos en `.audit/findings/`?
+
+---
+
+## Proceso — Fase 1: Pasada Feynman
+
+Cargar `Skill("feynman-auditor-swl")` y ejecutar la auditoría completa.
+
+- Salida cruda: `.audit/findings/feynman-pass1.md`
+- Registrar sospechosos de alta confianza para alimentar la Pasada 2.
+
+---
+
+## Proceso — Fase 2: Pasada State Inconsistency
+
+Cargar `Skill("state-inconsistency-auditor-swl")` con los sospechosos de Feynman como contexto adicional.
+
+- Los sospechosos de Feynman se convierten en **objetivos dirigidos** para el mapeo de estado acoplado.
+- Salida cruda: `.audit/findings/state-pass1.md`
+
+---
+
+## Proceso — Fases 3+: Convergencia
+
+Continuar alternando pasadas mientras alguna encuentre hallazgos nuevos:
+
+```
+Pasada N (Feynman dirigida):
+  Objetivos: funciones que rodean los hallazgos de State de la pasada anterior.
+  ¿Nuevos hallazgos? → Pasada N+1
+
+Pasada N+1 (State dirigida):
+  Objetivos: funciones que rodean los hallazgos de Feynman de la pasada anterior.
+  ¿Nuevos hallazgos? → Pasada N+2
+
+Convergencia: ninguna pasada produce hallazgos nuevos.
+Límite duro: 6 pasadas totales (3 Feynman + 3 State).
+```
+
+---
+
+## Proceso — Fase 7: Reporte Final
+
+Consolidar todos los hallazgos verificados en `.audit/findings/nemesis-verified.md`.
+
+Cada hallazgo etiquetado con su ruta de descubrimiento:
+
+- `[Feynman-solo]` — detectado solo por la técnica Feynman
+- `[State-solo]` — detectado solo por el mapeado de estado
+- `[Cross-feed]` — el hallazgo emergió de la retroalimentación entre ambas pasadas
+
+### Tabla de severidad
+
+| Severidad | Criterio |
+|-----------|----------|
+| CRÍTICO | Corrupción de datos inmediata, pérdida de información, escalada de privilegios |
+| ALTO | Fallo condicional de funcionalidad crítica, contabilidad incorrecta en paths comunes |
+| MEDIO | Contabilidad degradada, griefing, errores en casos de borde frecuentes |
+| BAJO | Problemas cosméticos, inaccuracy de eventos/logs, errores de casos de borde raros |
+
+---
+
+## Comandos
+
+| Comando | Acción |
+|---------|--------|
+| `/nemesis` | Auditoría completa iterativa |
+| `/nemesis --pass1` | Solo Pasada 1 — Feynman completo |
+| `/nemesis --pass2` | Solo Pasada 2 — State sobre output existente de Pasada 1 |
+| `/nemesis --continue` | Continuar desde la última pasada |
+| `/nemesis --contract <nombre>` | Auditoría completa sobre un módulo específico |
+
+---
+
+## Adaptación por lenguaje
+
+Detectar el lenguaje del codebase y adaptar:
+
+| Concepto | Python | TypeScript | Go | Rust | Java | C# |
+|---------|--------|------------|-----|------|------|-----|
+| Estado mutable | atributos de clase / variables de módulo | propiedades de clase / estado de módulo | campos de struct / variables globales | campos de struct | campos de clase | propiedades |
+| Almacenamiento persistente | BD / Redis / archivo | BD / Redis / localStorage | BD / Redis | BD / archivos | BD / caché | BD / caché |
+| Actor de la operación | `request.user` / `actor_id` | `req.user` / `userId` | `ctx.UserID` | `actor_id` | `principal` | `User.Identity` |
+| Mutación interna | método privado | método privado | función interna | `pub(crate) fn` | método privado | método privado |
+
+---
+
+## Protocolo anti-alucinación
+
+Nunca reportar un hallazgo sin evidencia textual concreta:
+
+- La función que rompe el invariante, con su path completo
+- La secuencia de triggers que produce el bug
+- El estado inconsistente resultante y su consecuencia observable
+
+Toda hallazgo verificado incluye: par de estado acoplado, operación que rompe, secuencia de triggers, consecuencia concreta.
+
+<!-- Adaptado de nemesis-auditor-main bajo MIT License (https://github.com/0xiehnnkta/nemesis-auditor) -->

package/comandos/swl/nemesis.md

@@ -0,0 +1,122 @@
+---
+name: swl:nemesis
+description: >
+  Auditoría iterativa Feynman + State Inconsistency (loop hasta convergencia).
+  Invoca el agente nemesis-auditor-swl con los 2 skills subordinados.
+  Persiste hallazgos en .planning/audit/findings/.
+allowed-tools: [Read, Grep, Glob, Bash, Write, Agent]
+argument-hint: "[--pass1 | --pass2 | --continue | --modulo <ruta>]"
+---
+
+# /swl:nemesis — Auditoría iterativa de profundidad
+
+Dos auditores en loop: Feynman interroga suposiciones línea por línea; State
+Inconsistency mapea pares de estado acoplado y encuentra mutaciones
+incompletas. Cada pasada alimenta la siguiente hasta que no aparecen hallazgos
+nuevos o se llega al máximo de 6 pasadas.
+
+## Cuándo invocar
+
+- El módulo pasó `/swl:revisar` con score ≥ 9.0 pero hay sospechas de bugs
+  de lógica profunda que el revisor de código no captura (suposiciones
+  incorrectas, invariantes rotos, condiciones de carrera sutiles).
+- Antes de un release de componente crítico: auth, pagos, contratos, permisos.
+- Cuando un bug en producción se atribuye a lógica aparentemente correcta —
+  usar Nemesis para encontrar el patrón de fallo subyacente.
+- Para módulos legacy con alta deuda técnica donde los tests no cubren los
+  caminos de estado.
+
+## Cuándo NO invocar
+
+- El módulo tiene menos de 200 LOC y es CRUD simple sin lógica de negocio.
+- Se necesita revisión de estilo, naming o cobertura de tests — usar
+  `/swl:revisar` en su lugar.
+- El proyecto no tiene `agentes/nemesis-auditor-swl.md` instalado — verificar
+  con `ls agentes/ | grep nemesis` antes de invocar.
+- La tarea urgente es un hotfix en producción — Nemesis es deliberado (8-20
+  turnos); en incidente activo, usar `/swl:verificar` acotado.
+
+## Modos disponibles
+
+| Modo | Flag | Descripción |
+|---|---|---|
+| Loop completo (default) | (sin flag) | Pasada 1 (Feynman) + Pasada 2 (State) + N pasadas alternadas hasta convergencia, máximo 6 en total |
+| Solo Feynman | `--pass1` | Una pasada Feynman exhaustiva; no ejecuta State |
+| Solo State | `--pass2` | Una pasada State Inconsistency; puede alimentarse con findings previos de Feynman si existen en `.planning/audit/findings/` |
+| Retomar | `--continue` | Continúa desde la última pasada registrada en `.planning/audit/findings/`; útil si la sesión se interrumpió |
+| Acotar módulo | `--modulo <ruta>` | Limita el scope a un archivo o subdirectorio específico; se puede combinar con cualquier otro flag |
+
+## Qué produce
+
+Todos los archivos se crean en `.planning/audit/findings/`:
+
+| Archivo | Cuándo se genera |
+|---|---|
+| `feynman-pass[N].md` | Al completar cada pasada Feynman (N = número de pasada) |
+| `state-pass[N].md` | Al completar cada pasada State Inconsistency |
+| `nemesis-verified.md` | Al final del loop completo; consolida todos los hallazgos con estado de verificación |
+
+Si el directorio `.planning/audit/findings/` no existe, el agente lo crea antes
+de la primera escritura.
+
+## Cómo interpretar el reporte
+
+Cada hallazgo en los archivos de pasada usa este formato:
+
+```
+## [SEVERIDAD] Título del hallazgo
+
+**Discovery path**: Feynman-only | State-only | Cross-feed Pass N → Pass M
+**Verification**: Code trace | PoC test | Both
+**Líneas afectadas**: archivo:L1-L2
+
+Descripción del problema y por qué es un bug y no solo código sospechoso.
+```
+
+**Severidades**:
+
+| Nivel | Criterio |
+|---|---|
+| CRITICAL | Explotable sin precondiciones; pérdida de datos o control total |
+| HIGH | Explotable bajo condiciones razonables; impacto severo |
+| MEDIUM | Requiere condiciones específicas; impacto moderado |
+| LOW | Impacto menor o difícil de explotar; documentar para trazabilidad |
+
+**Discovery path** indica cuándo se encontró:
+
+- `Feynman-only`: Feynman lo detectó; State no lo confirmó ni refutó.
+- `State-only`: State Inconsistency lo encontró analizando mutaciones.
+- `Cross-feed Pass N → Pass M`: Feynman marcó un sospechoso en la pasada N;
+  State lo confirmó como bug real en la pasada M (o viceversa). Estos
+  hallazgos son los más confiables.
+
+**Verification** indica la evidencia disponible:
+
+- `Code trace`: el path al bug se puede seguir leyendo el código.
+- `PoC test`: hay un caso de prueba que demuestra el comportamiento incorrecto.
+- `Both`: lo más sólido; implica un test listo para agregar a la suite.
+
+## Costo estimado
+
+| Modo | Turnos aproximados |
+|---|---|
+| Loop completo, módulo pequeño (< 500 LOC) | 8-12 turnos |
+| Loop completo, módulo mediano (500-2000 LOC) | 12-18 turnos |
+| Loop completo, módulo grande (> 2000 LOC) | 18-30 turnos |
+| Solo `--pass1` o `--pass2` | 4-8 turnos |
+
+Para módulos mayores a 5000 LOC, usar `--modulo <ruta>` para acotar el scope.
+Un loop sobre un módulo gigante puede tomar 30+ turnos sin garantía de que los
+hallazgos sean más útiles que los de un subconjunto bien elegido.
+
+## Ejemplos de invocación
+
+```
+/swl:nemesis                               # loop completo del proyecto
+/swl:nemesis --modulo src/auth             # acotado al módulo auth
+/swl:nemesis --pass1 --modulo src/auth     # solo Feynman sobre auth
+/swl:nemesis --pass2                       # solo State sobre findings existentes
+/swl:nemesis --continue                    # retoma desde la última pasada guardada
+```
+
+<!-- Adaptado de nemesis-auditor-main bajo MIT License (transmissions11/nemesis-auditor) -->

package/comandos/swl/salud.md

@@ -33,6 +33,34 @@ echo "Reglas: $(ls reglas/*.md 2>/dev/null | wc -l)" && \
 echo "Hooks: $(ls hooks/*.js 2>/dev/null | wc -l)"
 ```
 
+## Paso 0.5 — Detección automática de tier del proyecto
+
+Antes de ejecutar los pasos de diagnóstico, /swl:salud detecta el tier del proyecto contando archivos relevantes:
+
+```bash
+find . -type f \
+  -not -path '*/node_modules/*' \
+  -not -path '*/.git/*' \
+  -not -path '*/dist/*' \
+  -not -path '*/build/*' \
+  -not -path '*/.next/*' \
+  -not -path '*/coverage/*' \
+  -not -path '*/__pycache__/*' \
+  -not -path '*/.cache/*' \
+  -not -path '*/.planning/sessions/*' \
+  | wc -l
+```
+
+| Tier | Rango | Características esperadas |
+|---|---|---|
+| **Simple** | <500 archivos | 1 contributor, CI mínimo o ninguno. CLAUDE.md opcional. Skills/agentes opcionales. |
+| **Standard** | 500–5,000 archivos | Equipo pequeño con CI. CLAUDE.md + 1-2 reglas. 2-4 skills. Hooks básicos. |
+| **Complex** | >5,000 archivos | Múltiples contributors, CI activo. Setup completo de 6 capas: agentes + skills + reglas + hooks + instintos + memoria. |
+
+El tier detectado se reporta al inicio del SALUD.md generado.
+
+**Default ante ambigüedad**: si el conteo cae cerca de 500 (490-510) o 5000 (4900-5100), aplicar el tier superior. Es preferible diagnosticar de más que de menos.
+
 ## Paso 1 — Diagnóstico de agentes (determinista)
 
 Ejecutar script Bash que verifica cada agente mecánicamente:
@@ -65,6 +93,8 @@ echo "Agentes: $ok OK, $warns advertencias, $errors errores"
 
 Score de agentes = `(ok / total) * 100`
 
+**Restricción de tier**: el análisis cruzado de agentes (cross-check entre `exclusiones` declaradas y rutas reales en `manifiestos/modulos.json`) se ejecuta solo en proyectos **Standard** o **Complex**. En tier Simple, reportar el conteo básico y omitir la validación cruzada.
+
 ## Paso 2 — Diagnóstico de skills (determinista)
 
 ```bash
@@ -109,6 +139,8 @@ grep -r "Skill(" agentes/ comandos/ 2>/dev/null | grep -o '"[^"]*"' | sort | uni
 
 Score de skills = `((total - errors*10 - warns*2) / total) * 100`, mínimo 0
 
+**Restricción de tier**: la detección de skills huérfanos (no referenciados en ningún agente ni comando) se ejecuta solo en proyectos **Standard** o **Complex**. En tier Simple, donde hay menos de 10 skills esperados, la verificación de huérfanos genera falsos positivos y se omite.
+
 ## Paso 3 — Diagnóstico de comandos (determinista)
 
 ```bash
@@ -413,3 +445,5 @@ Presenta resumen con los problemas más críticos. Si hay errores, listarlos tod
 - Los scores son aritmética pura. No ajustar el score "porque parece un sistema sano".
 - Si no hay git, omitir verificaciones dependientes y notar la omisión.
 - Si detectas un patrón sistémico (mismo error en múltiples componentes), mencionarlo en recomendaciones.
+
+<!-- Patrón de 3 tiers adaptado de Waza/skills/health bajo MIT License (tw93/Waza) -->

package/comandos/swl/verificar.md

@@ -13,6 +13,7 @@ Eres el coordinador de verificación SWL. Tu trabajo es asegurar la calidad del
 | Flag | Efecto |
 |------|--------|
 | (sin flag) | Verificación estándar: tests + linter + revisor-codigo-swl + revisor-seguridad-swl |
+| `--full` | Añade 4 audits ejecutables en paralelo al flujo estándar: `code-profiler.js`, `pentest-scanner.js`, `dep-doctor.js` y secret-scanner. Produce un scorecard agregado 0-100 con thresholds de aprobación. Ver sección "Modo `--full`". |
 | `--ultra` | Añade tercera pasada de **revisión profunda** con Opus 4.7 sobre los hallazgos de los dos revisores. Consolida, prioriza, detecta contradicciones entre reviewers y genera plan de acción. Ideal para fases críticas (auth, pagos, migraciones de schema, endpoints públicos). |
 | `--solo-codigo` | Ejecuta solo revisor-codigo-swl (salta seguridad). Usar solo para refactors internos sin impacto externo. |
 | `--solo-seguridad` | Ejecuta solo revisor-seguridad-swl (salta código). Usar para auditorías de seguridad focalizadas. |
@@ -576,6 +577,48 @@ El comando:
 repetía 2+ veces por sesión con alta variación sobre el alcance exacto. Formalizar
 con flag elimina los 2 mensajes de fricción y deja el scope auditable en el comando.
 
+## Modo `--full` — Parallel Scorecard
+
+Al pasar el flag `--full`, /swl:verificar lanza en paralelo 4 audits ejecutables además del flujo secuencial estándar (revisor-codigo-swl + revisor-seguridad-swl). Cada audit produce score 0-100 y findings JSON. El scorecard final agrega resultados con thresholds estándar.
+
+### Audits paralelos invocados
+
+| Tool | Detecta | Comando |
+|---|---|---|
+| `code-profiler.js` | N+1 queries, sync I/O en async, memory leaks, ReDoS, queries unbounded | `node scripts/audit-tools/code-profiler.js .` |
+| `pentest-scanner.js` | XSS, SQLi, SSTI, CORS misconfig, JWT vulnerabilities, prototype pollution | `node scripts/audit-tools/pentest-scanner.js <target>` |
+| `dep-doctor.js` | Deps no usadas, outdated, heavy deps con alternativa | `node scripts/audit-tools/dep-doctor.js .` |
+| `secret-scanner` (hook existente) | Credenciales hardcodeadas | (vía hook) |
+
+### Thresholds del scorecard
+
+| Score | Status | Acción |
+|---|---|---|
+| ≥80 | READY | Listo para mergear |
+| 60-79 | NEEDS WORK | Hallazgos menores; mergear bajo decisión informada |
+| <60 | NOT READY | Hallazgos críticos; bloquear merge |
+
+### Salida agregada
+
+El comando produce un reporte tipo:
+
+```
+SCORECARD — Audits paralelos
+─────────────────────────────────
+code-profiler:    95 / 100  [READY]
+pentest-scanner:  82 / 100  [READY]
+dep-doctor:       70 / 100  [NEEDS WORK]
+secret-scanner:  100 / 100  [READY]
+─────────────────────────────────
+Score promedio:   86.75     [READY]
+Total findings:   3 (0 críticos, 2 mayores, 1 menor)
+```
+
+### Cuándo usar `--full` vs flujo estándar
+
+- **Flujo estándar** (`/swl:verificar`): revisión cualitativa por agentes con criterio editorial. Adecuado para PRs pequeños/medianos donde la calidad arquitectónica importa más que cobertura mecánica.
+- **Flag `--full`**: agrega análisis estático y dinámico ejecutable. Adecuado pre-release, audit de seguridad mensual, o features que tocan endpoints, dependencias o lógica compleja.
+
 ## Reglas de comportamiento
 
 - NUNCA marques una fase como APROBADO si hay hallazgos CRÍTICOS de seguridad.
@@ -583,3 +626,5 @@ con flag elimina los 2 mensajes de fricción y deja el scope auditable en el com
 - Si los tests fallan, es siempre CRÍTICO, sin excepción.
 - Las SUGERENCIAS son de largo plazo — no bloquean el avance pero deben documentarse.
 - Si el RESUMEN.md no existe, usa git diff para inferir el alcance. Nunca te bloquees.
+
+<!-- El patrón parallel scorecard adaptado de Houseofmvps/ultraship /ship bajo MIT License -->

package/habilidades/feynman-auditor-swl/SKILL.md

@@ -0,0 +1,123 @@
+---
+name: feynman-auditor-swl
+description: >
+  Auditor de bugs de lógica de negocio mediante la técnica Feynman: cuestiona
+  cada línea, cada orden de operaciones, cada presencia/ausencia de guard, y
+  cada asunción implícita. Language-agnostic (Python, TS, Go, Rust, Java, C#).
+  Cargar cuando se necesite revisión profunda de funciones individuales en
+  módulos críticos, especialmente tras un revisor-codigo-swl que pasó pero
+  donde sospechas que algo no está bien.
+---
+
+# Cuándo cargar
+
+- El módulo maneja dinero, inventario, permisos, o datos críticos irreversibles.
+- `revisor-codigo-swl` pasó pero hay sospecha de bug de lógica de negocio.
+- Nemesis está corriendo su Pasada 1.
+- Se necesita revisión profunda de una función específica antes de merge.
+
+# Cuándo NO cargar
+
+- Para escaneo de vulnerabilidades conocidas (CVE, inyecciones) — usar `revisor-seguridad-swl`.
+- Para revisión de estilo o cobertura de tests — usar `revisor-codigo-swl`.
+- Para funciones de utilería sin estado (formateo, parsing puro).
+- Como sustituto de tests de regresión.
+
+---
+
+# Feynman Auditor
+
+Encuentra bugs de lógica de negocio cuestionando cada línea como si tuvieras que explicarle el código a alguien que no asume nada.
+
+Las preguntas detalladas están en [recursos/preguntas-language-agnostic.md](recursos/preguntas-language-agnostic.md).
+
+---
+
+## Mentalidad de base
+
+Antes de leer el primer archivo, adoptar esta perspectiva:
+
+> "Este código tiene un bug. Mi trabajo es encontrarlo.
+> No estoy aquí para confirmar que el código es correcto.
+> Cada línea que no entiendo completamente es un sospechoso."
+
+Dos fuentes principales de bugs de lógica:
+
+1. **Bugs de guard ausente**: la condición correcta existe en función A pero falta en función B que hace lo mismo por un path diferente.
+2. **Bugs de orden de operaciones**: el cálculo es correcto, pero se ejecuta antes o después del momento en que los datos son válidos.
+
+---
+
+## Fase 0: Inventario de scope
+
+Antes de auditar, mapear:
+
+- ¿Qué módulos/archivos están en scope?
+- ¿Cuáles son las funciones de punto de entrada (endpoints, handlers, métodos públicos)?
+- ¿Qué datos persisten (BD, caché, archivos, estado en memoria)?
+- ¿Qué actores pueden llamar qué funciones?
+
+---
+
+## Fase 1: Auditoría de funciones individuales
+
+Para cada función no trivial, hacer las preguntas Q1–Q7 del archivo de recursos.
+
+Categorías de preguntas:
+- **Q1** — Propósito: ¿qué hace exactamente esta función y solo esta función?
+- **Q2** — Orden: ¿importa el orden de estas operaciones?
+- **Q3** — Consistencia cross-función: ¿qué tienen en común dos funciones que parecen similares?
+- **Q4** — Asunciones implícitas: ¿qué asume este código sin verificarlo?
+- **Q5** — Límites: ¿qué pasa en los extremos (cero, máximo, vacío, ya-existe)?
+- **Q6** — Returns y errores: ¿qué devuelve esta función cuando algo falla?
+- **Q7** — Interacciones externas: ¿qué puede pasar mal cuando se llama a otro sistema?
+
+Registrar como sospechoso cualquier función donde una pregunta no tenga respuesta clara en el código.
+
+---
+
+## Fase 2: Auditoría cross-función
+
+Buscar divergencias entre funciones que deberían comportarse igual:
+
+- ¿Función A y B hacen lo mismo pero una tiene un guard que la otra no tiene?
+- ¿La función de creación inicializa todos los campos que la función de lectura usa?
+- ¿El path de happy path y el path de error manejan el estado de la misma manera?
+
+---
+
+## Fase 3: Síntesis de hallazgos
+
+Convertir sospechosos en hallazgos concretos:
+
+Para cada sospechoso, construir:
+1. La pregunta Feynman que lo identificó
+2. La asunción que el código hace implícitamente
+3. El contraejemplo concreto que rompe esa asunción
+4. La consecuencia observable del bug
+
+---
+
+## Fase 4: Verificación
+
+Todo hallazgo CRÍTICO, ALTO y MEDIO debe verificarse antes del reporte final.
+
+**Patrón de falsos positivos frecuentes:**
+- El guard existe pero en un nivel superior (middleware, decorator, caller).
+- El orden parece incorrecto pero hay un comentario que explica el diseño intencional.
+- La función parece no validar, pero el tipo de dato ya garantiza el invariante.
+
+**Formato de salida**: `.audit/findings/feynman-passN.md`
+
+---
+
+## Adaptación por lenguaje
+
+| Concepto | Python | TypeScript | Go | Rust | Java | C# |
+|---------|--------|------------|-----|------|------|-----|
+| Actor | `request.user` | `req.user` / `userId` | `ctx.UserID` | `actor_id` | `principal` | `User.Identity` |
+| Guard | decorador / `if not user:` | middleware / `if (!user)` | `if ctx.UserID == ""` | `if actor_id.is_none()` | `@PreAuthorize` | `[Authorize]` |
+| Mutación interna | método privado `_fn` | método privado | función local | `pub(crate) fn` | método `private` | método `private` |
+| Transacción | `with db.begin():` | `await trx.begin()` | `tx, _ := db.Begin()` | `conn.execute("BEGIN")` | `@Transactional` | `using var tx =` |
+
+<!-- Adaptado de nemesis-auditor-main bajo MIT License (https://github.com/0xiehnnkta/nemesis-auditor) -->