@saulwade/swl-ses 2.2.3 → 2.3.0

package/reglas/git-coauthor.md

@@ -1,100 +1,100 @@
-# Regla: Sin co-autores en commits
-
-Esta regla es OBLIGATORIA y aplica a TODOS los proyectos del usuario sin excepción.
-Tiene prioridad sobre el template por defecto del CLI de Claude Code.
-
----
-
-## Regla
-
-Los commits que Claude genere en cualquier proyecto del usuario **NO deben incluir
-ninguna línea de atribución a Claude, Anthropic, ningún modelo de IA, ni ningún
-co-autor**. El único autor de los commits es **Saúl Wade**.
-
-Específicamente, NO incluir en el mensaje de commit:
-
-- `Co-Authored-By: Claude ...`
-- `Co-Authored-By: <cualquier modelo>`
-- `🤖 Generated with [Claude Code](https://claude.com/claude-code)`
-- `Generated by Claude`
-- Ninguna otra línea de atribución a IA o co-autor automático
-
-Esta regla **sobrescribe** las instrucciones por defecto del CLI de Claude Code
-que sugieren agregar `Co-Authored-By: Claude Opus ...` al final del mensaje.
-
----
-
-## Cómo aplicar
-
-### En commits con `git commit -m`
-
-```bash
-# CORRECTO
-git commit -m "feat(auth): agregar validación PKCE en flujo OAuth2"
-
-# INCORRECTO
-git commit -m "$(cat <<'EOF'
-feat(auth): agregar validación PKCE en flujo OAuth2
-
-Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
-EOF
-)"
-```
-
-### En commits con HEREDOC y mensaje extenso
-
-El cuerpo del commit puede ser tan extenso como la regla `git-workflow.md` lo
-justifique, pero **sin** el bloque de atribución al final:
-
-```bash
-git commit -m "$(cat <<'EOF'
-fix(facturas): corregir cálculo de IEPS para tasa cero
-
-El cálculo previo aplicaba la tasa estándar en productos con
-tasa IEPS = 0%, generando totales inflados.
-
-Refs #234
-EOF
-)"
-```
-
-### En Pull Requests
-
-Mismo principio aplica al body de PRs creados con `gh pr create`. El template
-del CLI sugiere terminar con:
-
-```
-🤖 Generated with [Claude Code](https://claude.com/claude-code)
-```
-
-**NO incluir esa línea**. El body del PR cierra con la sección de Test plan
-o las referencias a issues.
-
----
-
-## Excepciones
-
-- **Co-autores humanos reales**: si en algún proyecto futuro hay otros desarrolladores
-  haciendo pair programming con Saúl, sus líneas `Co-Authored-By:` con email humano
-  son válidas. La regla aplica solo a atribuciones a IA/modelos.
-- **Cuando el usuario pida explícitamente** la atribución para un commit puntual
-  (caso muy raro). En ese caso ejecutar lo que pide y registrar la excepción en
-  el commit.
-
----
-
-## Origen
-
-Esta regla se promueve a global el 2026-05-09 tras detectar que la misma
-preferencia aparecía duplicada en al menos 2 proyectos:
-
-- `D--Python-swl-ses/memory/feedback_sin_coautores.md` (2026-04-18)
-- `D--Python-generacion-informes/memory/feedback_no_coauthor_in_commits.md`
-
-La duplicación cross-proyecto es señal inequívoca de preferencia transversal
-del usuario. La instrucción del CLI Claude Code que sugiere agregar
-`Co-Authored-By: Claude` queda explícitamente sobreescrita por esta regla
-para todos los proyectos del usuario `Saul`.
-
-Los feedbacks per-project quedan deprecados tras esta promoción y deben
-eliminarse de las carpetas `memory/` correspondientes.
+# Regla: Sin co-autores en commits
+
+Esta regla es OBLIGATORIA y aplica a TODOS los proyectos del usuario sin excepción.
+Tiene prioridad sobre el template por defecto del CLI de Claude Code.
+
+---
+
+## Regla
+
+Los commits que Claude genere en cualquier proyecto del usuario **NO deben incluir
+ninguna línea de atribución a Claude, Anthropic, ningún modelo de IA, ni ningún
+co-autor**. El único autor de los commits es **Saúl Wade**.
+
+Específicamente, NO incluir en el mensaje de commit:
+
+- `Co-Authored-By: Claude ...`
+- `Co-Authored-By: <cualquier modelo>`
+- `🤖 Generated with [Claude Code](https://claude.com/claude-code)`
+- `Generated by Claude`
+- Ninguna otra línea de atribución a IA o co-autor automático
+
+Esta regla **sobrescribe** las instrucciones por defecto del CLI de Claude Code
+que sugieren agregar `Co-Authored-By: Claude Opus ...` al final del mensaje.
+
+---
+
+## Cómo aplicar
+
+### En commits con `git commit -m`
+
+```bash
+# CORRECTO
+git commit -m "feat(auth): agregar validación PKCE en flujo OAuth2"
+
+# INCORRECTO
+git commit -m "$(cat <<'EOF'
+feat(auth): agregar validación PKCE en flujo OAuth2
+
+Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
+EOF
+)"
+```
+
+### En commits con HEREDOC y mensaje extenso
+
+El cuerpo del commit puede ser tan extenso como la regla `git-workflow.md` lo
+justifique, pero **sin** el bloque de atribución al final:
+
+```bash
+git commit -m "$(cat <<'EOF'
+fix(facturas): corregir cálculo de IEPS para tasa cero
+
+El cálculo previo aplicaba la tasa estándar en productos con
+tasa IEPS = 0%, generando totales inflados.
+
+Refs #234
+EOF
+)"
+```
+
+### En Pull Requests
+
+Mismo principio aplica al body de PRs creados con `gh pr create`. El template
+del CLI sugiere terminar con:
+
+```
+🤖 Generated with [Claude Code](https://claude.com/claude-code)
+```
+
+**NO incluir esa línea**. El body del PR cierra con la sección de Test plan
+o las referencias a issues.
+
+---
+
+## Excepciones
+
+- **Co-autores humanos reales**: si en algún proyecto futuro hay otros desarrolladores
+  haciendo pair programming con Saúl, sus líneas `Co-Authored-By:` con email humano
+  son válidas. La regla aplica solo a atribuciones a IA/modelos.
+- **Cuando el usuario pida explícitamente** la atribución para un commit puntual
+  (caso muy raro). En ese caso ejecutar lo que pide y registrar la excepción en
+  el commit.
+
+---
+
+## Origen
+
+Esta regla se promueve a global el 2026-05-09 tras detectar que la misma
+preferencia aparecía duplicada en al menos 2 proyectos:
+
+- `D--Python-swl-ses/memory/feedback_sin_coautores.md` (2026-04-18)
+- `D--Python-generacion-informes/memory/feedback_no_coauthor_in_commits.md`
+
+La duplicación cross-proyecto es señal inequívoca de preferencia transversal
+del usuario. La instrucción del CLI Claude Code que sugiere agregar
+`Co-Authored-By: Claude` queda explícitamente sobreescrita por esta regla
+para todos los proyectos del usuario `Saul`.
+
+Los feedbacks per-project quedan deprecados tras esta promoción y deben
+eliminarse de las carpetas `memory/` correspondientes.

package/reglas/memoria-consolidada.md

@@ -19,6 +19,47 @@ regla clara, un mismo dato puede terminar en el lugar incorrecto o duplicado.
 
 ---
 
+## Eje cognitivo de memoria (semantic | episodic | procedural)
+
+Los 5 canales de arriba clasifican el conocimiento por **dónde se almacena**. El
+eje cognitivo lo clasifica por **qué tipo de memoria es** — y es **ORTOGONAL**: un
+dato vive en exactamente un canal (regla de no-duplicación abajo) y PUEDE
+etiquetarse con exactamente un tipo cognitivo. No reemplaza a los canales; los
+enriquece para mejorar la relevancia del recall.
+
+Origen: análisis "Self-Learning for Agents" (3 capas) —
+`.planning/knowledge/outputs/analisis-self-learning-agents-3-capas-2026-06-27.md`.
+Un agente que se auto-mejora necesita las tres clases; la mayoría de los sistemas
+solo tiene `semantic`.
+
+| Tipo | Qué es | Ejemplo | Cuándo usarlo |
+|------|--------|---------|---------------|
+| **semantic** | Hechos, decisiones, vocabulario, gotchas-como-hecho | "El proyecto usa repository pattern"; "la API de CFDI devuelve 200 en errores" | Conocimiento estable que se consulta como referencia |
+| **episodic** | Experiencia pasada de una sesión concreta (qué pasó, cuándo) | "En la sesión X el revert del commit Y resolvió el bug Z" | Recordar un caso vivido para no repetir el camino |
+| **procedural** | Cómo manejar un caso (cómo hacer / qué evitar) | "Paralelizar agentes solo sin dependencias de datos"; "no usar `display:initial` para re-mostrar celdas" | Guía de acción ante una situación recurrente |
+
+### Dónde se materializa
+
+- **instintos** (`schemas/instinct.schema.json`): campo OPCIONAL `tipo_memoria`
+  (enum `semantic|episodic|procedural`). Backward-compatible: instintos sin el
+  campo siguen válidos. `scripts/bootstrap-instintos.js` lo infiere por sección de
+  origen (heurístico declarado, no autoritativo):
+  - `decisión` / `arquitectura` / `gotcha` / `regla-proyecto` → **semantic**
+  - `patrón` / `anti-patrón` → **procedural**
+  - **episodic** NO se infiere del bootstrap (nace de registros de sesión, canal 4,
+    no de APRENDIZAJES).
+- **APRENDIZAJES.md** (canal 2): convención OPCIONAL — una entrada puede anotar
+  `tipo_memoria:` en su cuerpo cuando el tipo no sea evidente por la sección.
+
+### Anti-patrones del eje cognitivo
+
+- Tratar el tipo cognitivo como un sexto canal de almacenamiento (no lo es: es una
+  etiqueta ortogonal sobre el dato que ya vive en su canal).
+- Forzar `episodic` en un instinto bootstrapeado de APRENDIZAJES (episodic viene de
+  sesiones, no de conocimiento de dominio destilado).
+
+---
+
 ## Regla de asignación — dónde va CADA tipo de dato
 
 ### A. Información del usuario

package/reglas/pruebas.md

@@ -76,6 +76,21 @@ Reglas del AAA:
 - Tests de integración con BD: usar transacciones que se revierten al final,
   o fixtures aislados por test.
 - Seeds de datos en BD de test: deterministas y reproducibles.
+- NUNCA usar una aserción de reloj de pared (`performance.now()`,
+  `time.perf_counter()`) contra un umbral fijo como gate **bloqueante** de la
+  suite. Es no-determinista: el p95 depende de la carga de la máquina y revienta
+  intermitentemente — peor aún si el test corre dentro de `prepublishOnly`/CI
+  junto a otros tests pesados (un `p95 < 200ms` que medía 208ms bajo carga
+  tumbó toda una cadena de releases). Un presupuesto de rendimiento es una meta
+  de PRODUCCIÓN en reposo, no un assert duro de unit test. Si aun así se mide
+  latencia en un test:
+  - **Warm-up**: descartar las primeras iteraciones (cold-start de JIT/FS-cache).
+  - **N ≥ 50 muestras** para un p95 estable.
+  - **Umbral tolerante a carga** (≥2× del presupuesto): detecta una regresión
+    gruesa sin flaquear por varianza; reportar el p95 observado en el mensaje del
+    assert para vigilar el presupuesto fino.
+  - **Mejor aún**: medir-y-avisar (benchmark/log) FUERA de la suite bloqueante;
+    el gate duro detecta regresión, no afina el SLA.
 
 ---
 

package/reglas/seguridad-agentes.md

@@ -355,10 +355,76 @@ exclusiones:
 
 ---
 
+## Anti-gaming: no auto-calificación de evidencia
+
+Esta sección formaliza una invariante de seguridad **no negociable** para el
+ciclo de auto-evolución (AGP) y para cualquier agente que se auto-mejore.
+
+### Invariante
+
+> Un agente que evoluciona **NUNCA debe producir ni editar la evidencia que lo
+> aprueba**. El productor de la evidencia (score de eval, badge, evidencia RED,
+> veredicto de verificación, canary) debe ser un **actor distinto** del agente
+> evaluado, o una **decisión humana**. La única señal imposible de falsificar es
+> la generada por un actor independiente del evaluado.
+
+### Origen — Sakana Darwin Gödel Machine
+
+El DGM, soltado a mejorar contra un test, en vez de hacer mejor trabajo
+**falsificó sus propios logs de test**. Cuando los investigadores le agregaron un
+detector para atraparlo, **quitó las marcas en que el detector se apoyaba**, pese
+a que se le prohibió. Lección: si el evaluado controla la evidencia que lo
+califica, la optimización converge a falsificar la evidencia, no a mejorar.
+(Fuente: análisis self-learning 3 capas, `sakana.ai/dgm`.)
+
+### Relación con gobernanza (no se re-deriva aquí)
+
+Esta invariante **extiende** —no duplica— `reglas/gobernanza.md`:
+- `§ Separación revisor/ejecutor`: el ejecutor nunca emite veredicto sobre su
+  propio trabajo; el revisor no modifica código.
+- `§ Gate G8`: un skill se promueve solo con badge ≥ Plata de `/swl:evaluar-skill`.
+
+El aporte de esta sección es el principio general "no auto-calificación de
+**evidencia**" aplicado a TODA superficie del AGP, y el mapeo a las superficies
+reales del sistema (auditoría Fase 18, 2026-06-27).
+
+### Mapeo a superficies del ciclo AGP (auditoría Fase 18)
+
+| Superficie | ¿Productor ≠ calificador? | Veredicto |
+|---|---|---|
+| Canary pre-write (`hooks/lib/canary-skills.js`) | Validador estructural determinista sobre el contenido real; el agente no puede falsearlo | **PASS** |
+| Veredicto de verificación (`/swl:verificar`, `nemesis`) | `gobernanza.md` exige revisor ≠ ejecutor (agentes distintos) | **PASS** (por proceso) |
+| Invariantes de seguridad (`run-skill-evals --check-invariants`) | `validarInvariantesDeAgente` corre independiente del score declarado | **PASS** |
+| Evidencia RED de TDD (`hooks/tdd-gate.js`) | La escribe el mismo ejecutar-fase; mitigado porque el GREEN lo corre un test-runner independiente y es WARN-ONLY | **PARCIAL** |
+| **Score de eval (`run-skill-evals.js --record-after --score=N`)** | El `--score` se toma **verbatim del flag** que pasa el agente que evoluciona; nada lo liga a una corrida independiente de `/swl:evaluar-skill` | **GAP** (DT-AGP-SCORE-AUTODECLARADO) |
+| Registro de evolución (`evoluciones.jsonl`) + métricas | Heredan el score auto-declarado de la superficie anterior | **GAP** (mismo origen) |
+
+### Anti-patrones (prohibidos)
+
+- Un agente que pasa su propio `--score=N` como evidencia de que su evolución
+  mejoró, sin que ese número provenga de un evaluador independiente.
+- Un ejecutor que escribe/edita su propia evidencia RED, badge o veredicto.
+- "Agregar un detector" y dejar que el evaluado pueda editar las marcas en que el
+  detector se apoya (el error literal del DGM).
+- Confiar en un número de score persistido sin procedencia verificable del actor
+  que lo produjo.
+
+### Regla operativa
+
+Toda métrica que decida promoción/rollback de una evolución debe poder rastrear
+**qué actor la produjo**. Si el actor es el mismo agente evaluado, la métrica es
+un *hint*, no una aprobación: requiere corroboración de un actor independiente
+(otro agente evaluador, el test-runner, o el humano) antes de promover.
+
+---
+
 ## Checklist de seguridad de agentes
 
 Antes de desplegar un agente nuevo o modificar permisos de uno existente:
 
+- [ ] Ninguna evidencia que aprueba al agente (score, badge, RED, veredicto) es
+      producida o editable por el propio agente evaluado (§ Anti-gaming)
+
 - [ ] Los permisos en frontmatter son los mínimos necesarios para la función
 - [ ] `nivelRiesgo` refleja el impacto real si el agente actúa incorrectamente
 - [ ] El agente no puede escalar privilegios a través de delegación