@saulwade/swl-ses 2.4.3 → 2.5.1

package/habilidades/meta-reglas-extendido/recursos/gobernanza.md

@@ -0,0 +1,291 @@
+# Gobernanza — extendido
+
+> Extendido de `reglas/gobernanza.md` (Fase D ola 2, dieta de contexto). El núcleo
+> instalado en `~/.claude/rules/` es la norma vigente; aquí viven los formatos de
+> log, tablas de mapeo a agentes SWL, plantillas, veto items con detalle,
+> ejemplos y checklists.
+
+## Índice
+
+- [Políticas de aprobación](#políticas-de-aprobación)
+- [Auditoría](#auditoría)
+- [Separación revisor / ejecutor](#separación-revisor--ejecutor)
+- [Veto items y cap enforcement (auditor-class pattern)](#veto-items-y-cap-enforcement-auditor-class-pattern)
+- [Control de cambios del sistema](#control-de-cambios-del-sistema)
+- [Plugins de terceros](#plugins-de-terceros)
+- [Checklist de gobernanza antes de release](#checklist-de-gobernanza-antes-de-release)
+
+---
+
+## Políticas de aprobación
+
+### Cambios de alto riesgo
+
+Los siguientes cambios requieren aprobación explícita del líder técnico antes
+de incorporarse al sistema activo. "Aprobación explícita" significa una revisión
+deliberada (no automática) con evidencia documentada en `.planning/AUDITORIA.md`.
+
+Cambios que requieren aprobación:
+
+- Modificación de reglas de seguridad (`reglas/seguridad.md`)
+- Cambios en umbrales de risk scoring en `manifiestos/hooks-config.json`
+- Adición de hooks con `blocking: true`
+- Modificación de agentes con `nivelRiesgo: ALTO`
+- Cambios en manifiestos de instalación (`manifiestos/modulos.json`, `manifiestos/perfiles.json`)
+- Eliminación de reglas o agentes del sistema base
+
+### Skills generados automáticamente
+
+Los skills generados por `auto-evolucion-swl` o `/swl:evolucionar`:
+
+- Se instalan primero en `_userland/plugins/` como período de prueba.
+  NUNCA se incorporan directamente al sistema base sin revisión.
+- Requieren validación en al menos 3 sesiones de trabajo independientes
+  antes de ser promovidos al perfil `completo`.
+- Deben pasar la verificación de `/swl:status salud` sin degradar el score actual.
+- **Gate G8 — evidencia de calidad obligatoria**: antes de mover un skill
+  desde `_userland/plugins/` a `habilidades/`, ejecutar
+  `/swl:evaluar-skill <nombre>` y exigir badge ≥ **Plata** (score ≥ 70).
+  Skills con Bronce o sin badge se devuelven a `_userland/` con feedback
+  de qué dimensiones bajan el score. Detalle del flujo en
+  `agentes/auto-evolucion-swl.md` sección "Gate G8". Origen ADR 0013
+  sección 3C.
+- La promoción se registra en `.planning/AUDITORIA.md` con justificación
+  Y en `.planning/evolution/evoluciones.jsonl` con evento
+  `tipo: "promocion-skill"` y `score`.
+
+### Reglas nuevas obligatorias
+
+Una regla nueva que se declare obligatoria para todos los agentes es un cambio
+`MAJOR` del sistema (ver sección de versionado). Requiere:
+
+1. Propuesta documentada: qué problema resuelve y por qué es obligatoria.
+2. Período de revisión de al menos 48 horas antes de activarse.
+3. Comunicación al equipo con tiempo suficiente para adaptarse.
+4. Entrada en el CHANGELOG con descripción del impacto.
+
+---
+
+## Auditoría
+
+### Log de operaciones de alto riesgo
+
+Toda operación marcada como `nivelRiesgo: ALTO` debe registrarse en
+`.planning/AUDITORIA.md` con el siguiente formato:
+
+```markdown
+## [YYYY-MM-DD HH:MM] <tipo-de-operacion>
+
+**Agente**: nombre-agente-swl
+**Operación**: descripción breve de qué se hizo
+**Justificación**: por qué fue necesario
+**Aprobado por**: nombre o "individual" si es proyecto personal
+**Archivos afectados**: lista de rutas modificadas
+**Estado**: completado / revertido
+```
+
+El hook `risk-scoring` genera entradas automáticas para operaciones detectadas.
+Las operaciones manuales de alto riesgo deben registrarse manualmente.
+
+### Supresión de verificaciones
+
+Cuando se necesita suprimir un hook (via `SWL_DISABLED_HOOKS` u otro mecanismo):
+
+- Usar el scope más estrecho posible: archivo o directorio específico,
+  no desactivación global del hook.
+- Documentar en `.planning/AUDITORIA.md`:
+  - Fecha y duración de la supresión
+  - Razón técnica por la que fue necesario
+  - Alcance exacto (qué hook, qué archivos)
+  - Plan de reactivación
+
+Una supresión sin documentación en AUDITORIA.md se considera deuda de gobernanza
+que debe resolverse antes del próximo release.
+
+### Retención de logs
+
+- `.planning/AUDITORIA.md` es un archivo append-only. NUNCA borrar entradas antiguas.
+- Los instintos degradados por `degradacion-instintos.js` se registran
+  automáticamente en el log de instintos, no en AUDITORIA.md.
+- Revisar AUDITORIA.md mensualmente para identificar patrones de operaciones de riesgo.
+
+---
+
+## Separación revisor / ejecutor
+
+Un agente que ejecuta cambios NUNCA verifica su propio trabajo. La verificación
+cruzada entre roles distintos reduce hallucaciones y errores de confirmación.
+
+### Principio
+
+| Rol | Permisos | Responsabilidad |
+|-----|----------|-----------------|
+| **Ejecutor** | Write, Edit, Bash | Implementa cambios según el plan. NO se auto-revisa. |
+| **Revisor** | Read, Grep, Glob, Bash (solo lectura) | Emite veredictos estructurados. NO ejecuta correcciones. |
+
+### Reglas obligatorias
+
+- El ejecutor NUNCA emite un veredicto de aprobación sobre su propio trabajo.
+  Si termina una fase, reporta completitud — el revisor valida.
+- El revisor NUNCA modifica código de producción. Si detecta un problema,
+  emite un veredicto `Fail` con instrucciones concretas en `nextStep.instructions`.
+  El ejecutor aplica las correcciones.
+- En el flujo del orquestador, el revisor y el ejecutor son agentes distintos
+  o invocaciones independientes con contexto separado.
+- Las instrucciones del revisor son específicas: archivo, línea, qué cambiar.
+  "Mejorar el código" no es una instrucción válida.
+- El ejecutor sigue las instrucciones del revisor sin inventar mejoras adicionales
+  no solicitadas. No crea un plan nuevo — ejecuta lo indicado.
+
+### Mapeo a agentes SWL
+
+| Fase | Ejecutor | Revisor |
+|------|----------|---------|
+| Implementación | implementador-swl, backend-*-swl, frontend-*-swl | revisor-codigo-swl, revisor-*-swl |
+| Seguridad | (cualquier implementador) | revisor-seguridad-swl |
+| Testing | tdd-qa-swl (escribe tests) | (el test runner es el revisor) |
+| Verificación de fase | (agente que implementó) | verificar-trabajo (skill) |
+
+### Anti-patrones
+
+- Un agente que dice "revisé mi propio código y se ve bien" — viola la separación.
+- Un revisor que aplica un fix directamente en lugar de emitir instrucciones.
+- Un ejecutor que ignora el veredicto del revisor y marca la tarea como completada.
+- Un loop de reparación infinito — máximo 2 intentos antes de escalar a humano.
+
+---
+
+## Veto items y cap enforcement (auditor-class pattern)
+
+Algunos hallazgos son **no negociables**: violaciones de reglas globales del
+sistema cuya presencia debe bloquear la aprobación independientemente de qué
+tan limpio esté el resto del trabajo. El patrón "veto items + cap enforcement"
+formaliza este criterio para todos los revisores SWL.
+
+### Principio
+
+Un revisor declara una **lista finita y específica de veto items** asociados a
+su dominio. Si detecta CUALQUIER veto item:
+
+- El **score máximo** del reporte queda CAP a un valor de "no aprobado"
+  (ejemplo: `60/100` para reportes en escala 0-100, `6.0/10` para reportes
+  por dimensión).
+- El **veredicto automático** pasa a `RECHAZADO` o `APROBADO CON CORRECCIONES`,
+  nunca `APROBADO` limpio.
+- 2+ veto items → cap más estricto (ej. `30/100` o `3.0/10`).
+
+El cap NO se compensa con scores altos en otras dimensiones. La presencia de un
+veto item indica violación de una regla global no opcional.
+
+### Reglas
+
+1. **Cada revisor declara explícitamente sus veto items** en su agente
+   (sección dedicada en el `.md` del agente, antes del formato de reporte).
+2. **Los veto items mapean a reglas del sistema** (`reglas/seguridad.md`,
+   `reglas/estilo-codigo.md`, `reglas/arquitectura.md`, etc.). NO son criterios
+   inventados ad-hoc por el revisor.
+3. **El reporte muestra los veto items detectados** al inicio, antes de la
+   tabla de scores, en bloque dedicado:
+   ```
+   ### VETO ITEMS DETECTADOS
+   - [VI-1] <descripción del veto>: `archivo.py:42`
+   - [VI-3] <descripción del veto>: `app/util.py:88`
+   → score CAP a X/Y (N veto items). Veredicto: RECHAZADO.
+   ```
+   Si no hay: `### VETO ITEMS DETECTADOS\n- Ninguno`.
+4. **El cap no se levanta por negociación**. Solo se levanta cuando se
+   demuestra remediación (commit + test que prueba la corrección) y el revisor
+   re-ejecuta la auditoría.
+5. **Un veto item siempre referencia una regla global**. Si el revisor cree
+   que algo "debería ser veto" pero no hay regla que lo respalde, primero
+   actualiza la regla, luego agrega el veto.
+
+### Aplicabilidad
+
+Revisores SWL que DEBEN implementar veto items:
+
+- `revisor-seguridad-swl` (10 veto items: secret hardcodeado, SQL injection,
+  eval con input, path traversal, CVE crítico, etc.)
+- `revisor-codigo-swl` (10 veto items: función >100 líneas, complejidad >15,
+  console.log en prod, dependencia circular, DRY mayor, etc.)
+
+Revisores específicos de lenguaje (`revisor-typescript-swl`, `revisor-react-swl`,
+`revisor-rust-swl`, etc.) PUEDEN agregar veto items adicionales propios de su
+dominio, pero deben heredar los del revisor base correspondiente.
+
+Plantilla reusable: `plantillas/auditor-veto-template.md`.
+
+### Anti-patrones
+
+- **Veto inventado sin regla**: "código feo" no es veto válido — necesita
+  regla global que lo prohíba.
+- **Veto suavizado por presión de entrega**: bajar de "veto" a "menor" porque
+  el equipo dispute es invalidación del sistema.
+- **Veto sin evidencia**: cada veto item reportado debe citar archivo:línea.
+- **Veto que no se persiste**: si el cap se levanta sin re-revisión y commit
+  de corrección, el sistema pierde su valor.
+
+---
+
+## Control de cambios del sistema
+
+### Versionado
+
+Todo cambio al sistema SWL sigue SemVer estricto:
+
+| Tipo de cambio | Versión |
+|----------------|---------|
+| Regla nueva marcada como obligatoria | MAJOR |
+| Cambio breaking en schema de agentes o skills | MAJOR |
+| Agente nuevo, skill nuevo, comando nuevo | MINOR |
+| Feature en agente o skill existente | MINOR |
+| Bug fix, corrección de typo, actualización de ejemplo | PATCH |
+| Mejora de descripción sin cambio de comportamiento | PATCH |
+
+El comando `/swl:release` maneja el versionado automáticamente.
+
+### Rollback
+
+Ante un cambio que degrada el sistema:
+
+- La versión anterior debe permanecer disponible (via git) por al menos 1 semana
+  antes de considerarse obsoleta.
+- Los hooks nuevos pueden desactivarse individualmente via variable de entorno
+  `SWL_DISABLED_HOOKS=nombre-hook` sin afectar el resto del sistema.
+- Los agentes nuevos NO reemplazan a los existentes sin un período de transición
+  documentado. Durante la transición, ambas versiones coexisten.
+- Si `/swl:status salud` baja su score tras un cambio: revertir antes de continuar.
+
+### Freeze de cambios pre-release
+
+Durante las 24 horas previas a un release:
+
+- Solo se permiten bug fixes críticos (PATCH).
+- No se agregan features ni reglas nuevas.
+- El comando `/swl:status salud` debe pasar sin advertencias antes de publicar.
+
+---
+
+## Plugins de terceros
+
+Los plugins instalados via `/swl:plugins install` tienen restricciones adicionales:
+
+- No pueden modificar componentes del sistema base (`agentes/`, `habilidades/`,
+  `reglas/`, `hooks/` en la raíz).
+- Sus hooks con `blocking: true` requieren revisión explícita antes de activarse.
+- Si un plugin no recibe actualizaciones en 6 meses y tiene issues conocidos:
+  marcarlo como deprecado en `.planning/PLUGINS.md`.
+- Los plugins de fuentes no verificadas no se instalan sin auditoría de su código.
+
+---
+
+## Checklist de gobernanza antes de release
+
+- [ ] Todos los cambios de alto riesgo tienen aprobación documentada en AUDITORIA.md
+- [ ] Los skills auto-generados fueron validados en al menos 3 sesiones
+- [ ] Ninguna supresión de hook activa sin justificación documentada
+- [ ] El CHANGELOG.md está actualizado con todos los cambios observables
+- [ ] Los schemas de validación pasan para todos los manifiestos modificados
+- [ ] El comando `/swl:status salud` pasa sin errores ni advertencias críticas
+- [ ] La versión en `package.json` refleja el tipo de cambio realizado
+- [ ] Los plugins de terceros instalados siguen siendo compatibles con la versión nueva

package/habilidades/meta-reglas-extendido/recursos/memoria-consolidada.md

@@ -0,0 +1,263 @@
+# Consolidación de memoria — extendido
+
+> Extendido de `reglas/memoria-consolidada.md` (Fase D, dieta de contexto). El
+> núcleo instalado es la norma; aquí viven las tablas de asignación completas,
+> el eje cognitivo desarrollado, el scoring de instintos con código y los
+> anti-patrones detallados.
+
+## Índice
+
+- [Los 5 canales de memoria](#los-5-canales-de-memoria)
+- [Eje cognitivo de memoria (semantic | episodic | procedural)](#eje-cognitivo-de-memoria-semantic--episodic--procedural)
+- [Regla de asignación — dónde va CADA tipo de dato](#regla-de-asignación--dónde-va-cada-tipo-de-dato)
+- [Precedencia en caso de conflicto](#precedencia-en-caso-de-conflicto)
+- [Reglas de no-duplicación](#reglas-de-no-duplicación)
+- [Validación automática](#validación-automática)
+- [Anti-patrones a detectar](#anti-patrones-a-detectar)
+- [Scoring de instintos: decay exponencial + maturity](#scoring-de-instintos-decay-exponencial--maturity)
+- [Source tracing en instintos y APRENDIZAJES](#source-tracing-en-instintos-y-aprendizajes)
+- [Checklist antes de escribir a memoria](#checklist-antes-de-escribir-a-memoria)
+
+---
+
+## Los 5 canales de memoria
+
+| # | Canal | Formato | Fuente de verdad de |
+|---|-------|---------|---------------------|
+| 1 | **Memoria nativa de Claude Code** (`~/.claude/projects/.../memory/`) | Archivos `.md` con frontmatter `user`/`feedback`/`project`/`reference` | Perfil general del usuario y del proyecto, auto-gestionado por el harness |
+| 2 | **`.planning/APRENDIZAJES.md`** | Markdown con entradas `### [YYYY-MM-DD] Título` agrupadas por sección | Conocimiento del dominio (anti-patrones, patrones, decisiones, gotchas) |
+| 3 | **`instintos/proyecto.yaml` / `global.yaml` / `perfil-usuario.yaml`** | YAML estructurado con confidence, scope, evidence_count | Patrones aprendidos inductivamente, con promoción/degradación |
+| 4 | **`.planning/sessions/search-index.json`** | Índice FTS de sesiones pasadas | Búsqueda histórica de trabajo (qué se hizo, cuándo) |
+| 5 | **`.planning/evolution/*`** | JSONL (nudges, agentes) + JSON (métricas, alertas, evoluciones) | Estado del ciclo de auto-evolución |
+
+---
+
+## 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
+
+| Tipo de dato | Canal correcto | NO va a |
+|---|---|---|
+| Rol profesional, años de experiencia | 1 (memoria `user`) + 3 (perfil-usuario.yaml) | APRENDIZAJES, sessions, proyecto.yaml |
+| Stack preferido del usuario | 3 (perfil-usuario.yaml) | APRENDIZAJES |
+| Corrección explícita del usuario ("prefiero X", "nunca Y") | 1 (memoria `feedback`) + 3 (perfil-usuario.yaml vía perfilador-usuario-swl) | APRENDIZAJES |
+| Preferencia de idioma, formalidad, longitud | 3 (perfil-usuario.yaml) | — |
+| Límites explícitos ("no guardes X") | 3 (perfil-usuario.yaml `limites_explicitos`) | — |
+
+### B. Conocimiento del dominio (aplicable al proyecto o transversal)
+
+| Tipo de dato | Canal correcto | NO va a |
+|---|---|---|
+| Anti-patrón descubierto (ej: bug recurrente) | 2 (APRENDIZAJES.md sección "Anti-patrones") | perfil-usuario, instintos directamente |
+| Patrón exitoso reutilizable | 2 (APRENDIZAJES.md) → eventual skill nuevo (tipo C) | perfil-usuario |
+| Decisión de arquitectura tomada | 2 (APRENDIZAJES.md sección "Decisiones") + eventualmente CLAUDE.md | perfil-usuario, instintos sin consolidar primero |
+| Gotcha específico de una librería | 2 (APRENDIZAJES.md) o skill existente | perfil-usuario |
+
+### C. Estado del sistema y observabilidad
+
+| Tipo de dato | Canal correcto |
+|---|---|
+| Nudge emitido por un hook | 5 (`.planning/evolution/nudges.jsonl`) |
+| Evento de subagente terminado | 5 (`.planning/auto-evolution/agentes.jsonl`) |
+| Evolución aplicada/revertida a skill | 5 (`.planning/evolution/evoluciones.jsonl`) |
+| Alerta persistente (nudges ignorados) | 5 (`.planning/evolution/alertas-persistentes.json`) |
+| Métricas agregadas (health score) | 5 (`.planning/evolution/metricas.json`) |
+| Traza de ejecución de agente | `.planning/traces/` (OTLP-lite) |
+| Audit trail inmutable | `.planning/audit.jsonl` + Merkle |
+
+### D. Patrones consolidados (inductivos, con confidence)
+
+| Tipo de dato | Canal correcto |
+|---|---|
+| Patrón observado ≥1 vez con confidence < 0.5 | 3 (instintos/proyecto.yaml como draft) |
+| Patrón consolidado (confidence ≥ 0.5, evidence_count ≥ 3) | 3 (instintos/proyecto.yaml activo) |
+| Patrón validado cross-proyecto (confidence > 0.8) | 3 (instintos/global.yaml tras promoción) |
+| Patrón contradicho (degradado ≥3 veces) | 3 (instintos/proyecto.yaml status `degraded`) o borrado |
+
+### E. Búsqueda histórica
+
+| Tipo de dato | Canal correcto |
+|---|---|
+| "¿Qué hicimos la semana pasada en X?" | 4 (sessions/search-index.json) — vía `habilidades/memoria-busqueda` |
+| Sesión completa archivada | `.planning/sessions/*.json` |
+
+---
+
+## Precedencia en caso de conflicto
+
+Si un mismo dato aparece en múltiples canales, la prioridad de verdad es:
+
+```
+CLAUDE.md (regla explícita)
+  > Memoria nativa tipo feedback del usuario (corrección explícita)
+  > instintos con confidence ≥ 0.9
+  > APRENDIZAJES.md (si es tipo Decisión)
+  > perfil-usuario.yaml
+  > instintos con confidence < 0.9
+  > sesiones pasadas
+```
+
+---
+
+## Reglas de no-duplicación
+
+1. **Un dato vive en exactamente un canal** (salvo referencias explícitas).
+   Si necesitas citarlo desde otro, usa un puntero/path, no copies el contenido.
+
+2. **perfil-usuario.yaml NUNCA duplica APRENDIZAJES.md.** Una corrección del
+   usuario va al perfil; un anti-patrón técnico va a APRENDIZAJES.
+
+3. **instintos/proyecto.yaml bootstrap desde APRENDIZAJES.md** es válido
+   (hace `scripts/bootstrap-instintos.js`), pero la fuente de verdad post-bootstrap
+   es `instintos/proyecto.yaml`. Nuevos APRENDIZAJES no deben entrar a instintos
+   automáticamente — primero se promueven con `/swl:aprender` (tipo C).
+
+4. **La memoria nativa del harness no se sobreescribe** con contenido de SWL.
+   El flujo es al revés: señales del usuario pueden alimentar ambos canales
+   (native + perfil SWL), pero ninguno es copia del otro.
+
+5. **Cuando detectes duplicación cross-canal**, registrarla como anti-patrón
+   en APRENDIZAJES.md y corregir con `scripts/validar-memoria.js`.
+
+---
+
+## Validación automática
+
+El script `scripts/validar-memoria.js` detecta duplicaciones y violaciones
+de esta regla. Se ejecuta:
+
+- Manualmente: `node scripts/validar-memoria.js`
+- Automáticamente dentro de `scripts/validar.js` (parte del pipeline CI)
+
+Reporta: duplicación cross-canal, canal incorrecto para un tipo de dato
+conocido, datos en canales deprecados.
+
+---
+
+## Anti-patrones a detectar
+
+- **Corrección del usuario escrita a APRENDIZAJES.md** → debe ir al perfil
+- **Anti-patrón técnico escrito al perfil del usuario** → debe ir a APRENDIZAJES
+- **Métrica persistida en APRENDIZAJES.md** → debe ir a `.planning/evolution/`
+- **Secreto/credencial en cualquier canal** → bloqueo inmediato (`privacy-memoria`)
+- **Dato duplicado en proyecto.yaml y global.yaml** → uno debe borrarse
+  (promover a global SOLO cuando confidence > 0.8 Y validado cross-proyecto)
+- **Instinto activo con `last_validated` antiguo (>180 días) sin feedback**
+  → el `effective_confidence` ya está bajo `0.25`. Re-validar manualmente o
+  marcar `status: archived`.
+
+---
+
+## Scoring de instintos: decay exponencial + maturity
+
+El campo `confidence` en instintos es **estático** (asignado al crear). El valor
+**efectivo** se computa dinámicamente con dos factores:
+
+1. **Decay temporal**: la confianza decae exponencialmente desde `last_validated_at`.
+   Half-life por defecto: 90 días. Tras 1 half-life → confianza × 0.5; tras 2 → × 0.25.
+2. **Penalización por feedback dañino**: si `harmful_count / (helpful_count + harmful_count) > 0.3`
+   con al menos 3 eventos, el instinto se propone para `status: degraded`.
+
+Implementación pura en `scripts/lib/scoring-instintos.js`:
+
+```js
+const { effectiveConfidence, maturityState, applyFeedback } = require('./scoring-instintos');
+
+// Lectura
+const eff = effectiveConfidence(instinto, new Date());
+const maturity = maturityState(instinto, new Date());
+// → 'candidate' | 'established' | 'proven' | 'deprecated'
+
+// Escritura (pure)
+const conFeedback = applyFeedback(instinto, 'helpful');
+```
+
+**Cuándo recomputar**:
+- `/swl:status salud` reporta instintos con `effective_confidence < 0.3` para revisión.
+- `hooks/degradacion-instintos.js` puede marcar `status_proposed: degraded`
+  cuando `shouldAutoDeprecate(instinto)` devuelve `true`.
+- `bootstrap-instintos.js` emite los nuevos instintos con `decay_half_life_days: 90`,
+  `helpful_count: 0`, `harmful_count: 0` por defecto.
+
+**Backward compat**: instintos antiguos sin los campos nuevos siguen siendo
+válidos. `effectiveConfidence` cae a `confidence * decay` cuando no hay feedback,
+y `last_validated` (sin `_at`) se usa como fallback.
+
+---
+
+## Source tracing en instintos y APRENDIZAJES
+
+Cada instinto puede declarar la **evidencia que lo respalda** mediante:
+
+- `source_sessions: ["sess-abc", "sess-def"]` — sesiones que lo generaron o validaron
+- `source_agents: ["orquestador-swl", "implementador-swl"]` — agentes que lo aplicaron exitosamente
+- `evidence_count: N` — total numérico (compatibilidad legacy)
+
+**Reglas**:
+
+1. Un instinto con `confidence ≥ 0.7` debe tener al menos 1 entrada en
+   `source_sessions` o `source_agents` para justificar la confianza.
+2. Para promover de `instintos/proyecto.yaml` a `instintos/global.yaml`, el
+   instinto debe tener `source_agents.length ≥ 2` o `source_sessions.length ≥ 3`
+   — un solo punto de evidencia no es suficiente para impacto cross-proyecto.
+3. El campo `source_sessions` referencia IDs de `.planning/sessions/`. No copiar
+   el contenido — usar el ID como puntero.
+4. `addSource()` en `scripts/lib/scoring-instintos.js` mantiene unicidad
+   automática. NUNCA editar manualmente con duplicados.
+
+**Anti-patrón**: instinto con `evidence_count: 10` pero `source_sessions: []` y
+`source_agents: []` — la cifra es opaca, no se puede auditar de dónde viene.
+
+---
+
+## Checklist antes de escribir a memoria
+
+Antes de que cualquier agente, skill o hook persista un dato, debe responder:
+
+1. ¿Es información del **usuario**, del **dominio**, de **estado del sistema**,
+   un **patrón inductivo**, o **búsqueda histórica**? → identifica canal A-E.
+2. ¿El canal elegido es el correcto según la tabla de asignación?
+3. ¿El dato ya existe en otro canal? Si sí, actualiza ese, no dupliques.
+4. ¿El dato contiene PII, secretos o contenido sensible? → cargar `privacy-memoria`.
+5. ¿El dato viene de texto del usuario? → escanear con `prompt-injection-scanner`.