@saulwade/swl-ses 1.8.0 → 2.0.0

package/habilidades/drift-detection/SKILL.md

@@ -1,179 +1,179 @@
----
-name: drift-detection
-version: 1.0.0
-herramientasPermitidas: [Read]
-description: "Detección de drift de métricas de agentes/skills via ventana deslizante (7d) vs baseline (4 semanas). Integrado al operador Reflect del ciclo AGP."
-exclusiones:
-  - "No cargar para detectar drift en código de aplicación (regressions de negocio); este skill detecta drift en métricas de uso de agentes/skills del sistema SWL."
-  - "No cargar si hay menos de 7 días de trazas en `.planning/traces/`; el baseline de 4 semanas no existirá y los resultados serán estadísticamente inválidos."
-  - "No cargar para observabilidad de la aplicación en producción; usar `monitoring-alertas` para eso."
-  - "No cargar manualmente cuando el ciclo AGP ya ejecuta `ejecutarDriftAutomatico()` en cada SubagentStop — invocarlo dos veces dobla el trabajo sin beneficio."
-author: swl-ses
-evolvable: true
-evolvable_scope: [content, examples]
-domain: ingeniería-de-software
-tags: [agp, observabilidad, drift, métricas, ciclo-agp]
----
-# drift-detection — Detección de drift para el ciclo AGP
-
-Algoritmo de ventana deslizante que compara métricas recientes (últimos 7 días)
-contra un baseline histórico (4 semanas previas) para detectar degradación de
-skills y agentes antes de que el health score lo refleje.
-
-Adaptado de `runDriftCheck`/`getDriftTimeline` en mission-control-main (MIT).
-
-## Módulo principal
-
-`scripts/lib/drift-detector.js` — zero-deps, Node stdlib únicamente.
-
-## Cuándo se activa
-
-- Manual: desde cualquier script o agente que necesite análisis de degradación.
-- Automático (vía `hooks/auto-evolucion.js`): el hook ejecuta `ejecutarDriftAutomatico()`
-  en cada `SubagentStop` con un throttle de 24 h (configurable con `SWL_DRIFT_THROTTLE_H`).
-  Se evalúan los últimos 5 archivos JSONL de trazas. Opt-out total con `SWL_DRIFT_DISABLED=1`.
-- Automático (vía ciclo AGP): `hooks/lib/reflect-classifier.js` expone
-  `ejecutarDriftReflect(rutaJsonl, nombreAgente)` como punto de extensión alternativo.
-- Las trazas de agentes viven en `.planning/traces/YYYY-MM-DD.jsonl`.
-
-## Exports del módulo
-
-```js
-const { detectarDrift, generarLineaTemporal } = require('./scripts/lib/drift-detector');
-```
-
-### `detectarDrift(opts)`
-
-```js
-detectarDrift({
-  rutaJsonl:           '/ruta/a/traces.jsonl',
-  ventanaDias:         7,       // default
-  baselineSemanasBase: 4,       // default
-  umbralPct:           10,      // warn si |drift| > 10%
-  metricas:            ['tokens_promedio_por_sesion', 'tasa_exito_tool', 'tasa_finalizacion_tarea'],
-  agente:              'backend-python-swl',  // para nudges
-})
-```
-
-**Retorna:**
-
-```json
-{
-  "drifts": [
-    {
-      "metrica": "tokens_promedio_por_sesion",
-      "baseline": 1000,
-      "reciente": 2100,
-      "driftPct": 110.0,
-      "estado": "critico"
-    },
-    {
-      "metrica": "tasa_exito_tool",
-      "baseline": 0.9,
-      "reciente": 0.85,
-      "driftPct": -5.56,
-      "estado": "ok"
-    }
-  ],
-  "timestamp": "2026-04-19T12:00:00.000Z",
-  "estado_global": "critico"
-}
-```
-
-**Estados por métrica:**
-
-| Condición | Estado |
-|-----------|--------|
-| `abs(driftPct) <= umbralPct` | `ok` |
-| `abs(driftPct) > umbralPct` | `warn` |
-| `abs(driftPct) > umbralPct * 2` | `critico` |
-
-**Estado global:** el peor estado entre todas las métricas.
-
-### `generarLineaTemporal(opts)`
-
-```js
-generarLineaTemporal({
-  rutaJsonl: '/ruta/a/traces.jsonl',
-  dias:      30,   // default
-})
-// → [{ fecha: '2026-04-19', tokens: 3200, exitos: 12, fallos: 1 }, ...]
-```
-
-Retorna un array de longitud `dias`, uno por día, para visualización en
-el dashboard o en reportes de salud.
-
-## Estructura de eventos esperada en el JSONL
-
-El módulo es permisivo: extrae métricas de cualquier campo que coincida.
-
-| Métrica | Campos aceptados en el evento |
-|---------|-------------------------------|
-| Tokens | `atributos.tokens_totales`, `tokens`, `total_tokens` |
-| Éxito de tool | `success`, `exito`, `atributos.success` |
-| Finalización de tarea | `estado`, `status`, `atributos.estado` (valores: `OK`, `done`, `completado`) |
-| Timestamp | `timestamp`, `ts`, `inicio`, `created_at` |
-
-Formato nativo de `.planning/traces/YYYY-MM-DD.jsonl`:
-
-```json
-{"traceId":"...","nombre":"agent:backend-python-swl","inicio":"2026-04-19T10:00:00.000Z","estado":"OK","atributos":{"tokens_totales":1500}}
-```
-
-## Integración con el ciclo AGP
-
-El operador Reflect (`hooks/lib/reflect-classifier.js`) expone:
-
-```js
-const { ejecutarDriftReflect } = require('./hooks/lib/reflect-classifier');
-
-const resultado = ejecutarDriftReflect(
-  '.planning/traces/2026-04-19.jsonl',
-  'backend-python-swl'
-);
-// resultado: { drifts, timestamp, estado_global } o null si módulo no disponible
-```
-
-Cuando `estado_global === 'critico'`, el módulo emite automáticamente un nudge
-a `.planning/evolution/nudges.jsonl`:
-
-```json
-{
-  "timestamp": "2026-04-19T12:00:00.000Z",
-  "tipo": "drift-detectado",
-  "agente_o_skill": "backend-python-swl",
-  "metrica": "tokens_promedio_por_sesion",
-  "drift_pct": 110.0,
-  "estado": "critico"
-}
-```
-
-El agente `auto-evolucion-swl` consume estos nudges para proponer mejoras.
-
-## Cómo interpretar los resultados
-
-- **`ok`**: métricas estables. Sin acción requerida.
-- **`warn`**: degradación moderada. Revisar en el próximo ciclo de evolución.
-- **`critico`**: degradación severa. Invocar `/swl:evolucionar` con el agente
-  identificado. El nudge ya fue emitido — aparecerá en `/swl:salud`.
-
-## Cuándo NO cargar
-
-- Se busca detectar regresiones en el código de la aplicación (tests fallando, performance degradada); para eso usar `monitoring-alertas` o el revisor de código correspondiente.
-- El proyecto tiene menos de 7 días de trazas — el baseline de 4 semanas no puede calcularse y `detectarDrift` retornará resultados sin significado estadístico.
-- El ciclo AGP ya tiene configurado el throttle automático de 24 h; invocar el drift manualmente en el mismo intervalo produce el mismo nudge dos veces sin nuevo valor.
-
-## Gotchas / Errores comunes no obvios
-
-- **Timestamps inválidos en eventos JSONL provocan líneas ignoradas silenciosamente**: el módulo es permisivo con los campos pero si ningún campo de timestamp (`timestamp`, `ts`, `inicio`, `created_at`) tiene una fecha ISO válida, el evento se descarta del cálculo. Causa: eventos generados con timestamps de formato local (ej. `"19/04/2026"`) no pasan la validación. Solución: verificar que todos los eventos JSONL del trace tengan al menos un campo de timestamp en formato ISO 8601 — si el baseline aparece como 0, es el primer síntoma de eventos descartados.
-- **Estado `critico` emitido por baseline con muy pocos eventos**: si el baseline de 4 semanas tiene solo 3 eventos y la ventana de 7 días tiene 8, el `driftPct` de tokens se dispara al 166% cuando en realidad el agente está más activo, no degradado. Causa: el módulo no valida que el baseline tenga suficientes eventos para ser estadísticamente válido. Solución: antes de interpretar un estado `critico`, verificar que el baseline tiene al menos 20 eventos — si no, marcar el resultado como `insufficient-data` en lugar de accionar.
-- **Nudge duplicado en `.planning/evolution/nudges.jsonl` por falta de deduplicación**: el hook se ejecuta dos veces en el mismo `SubagentStop` (por bug de throttle) y emite el mismo nudge dos veces. Causa: el throttle `SWL_DRIFT_THROTTLE_H` no validó correctamente el timestamp del último run. Solución: el archivo `nudges.jsonl` es append-only — antes de emitir un nudge, verificar si el último evento del mismo `agente_o_skill` y `metrica` tiene un timestamp dentro de la ventana de throttle.
-- **`atomicWriteJSON` usado para escribir en nudges.jsonl**: escribir el archivo completo en lugar de hacer append corrompe el historial de nudges previos. Causa: confusión entre archivos de estado mutable (usan `atomicWriteJSON`) y archivos de eventos de alta frecuencia (usan `fs.appendFileSync`). Solución: `nudges.jsonl` es un JSONL de alta frecuencia — siempre usar `fs.appendFileSync(ruta, JSON.stringify(nudge) + '\n')`, nunca reescribir el archivo completo.
-
-## Referencia cruzada
-
-- Módulo: `scripts/lib/drift-detector.js`
-- Tests: `tests/lib/drift-detector.test.js`
-- Operador Reflect: `hooks/lib/reflect-classifier.js`
-- Ciclo AGP: `.planning/evolution/nudges.jsonl`
-- Origen (adaptado de): `temp/mission-control-main/src/lib/agent-evals.ts` — MIT
+---
+name: drift-detection
+version: 1.0.0
+herramientasPermitidas: [Read]
+description: "Detección de drift de métricas de agentes/skills via ventana deslizante (7d) vs baseline (4 semanas). Integrado al operador Reflect del ciclo AGP."
+exclusiones:
+  - "No cargar para detectar drift en código de aplicación (regressions de negocio); este skill detecta drift en métricas de uso de agentes/skills del sistema SWL."
+  - "No cargar si hay menos de 7 días de trazas en `.planning/traces/`; el baseline de 4 semanas no existirá y los resultados serán estadísticamente inválidos."
+  - "No cargar para observabilidad de la aplicación en producción; usar `monitoring-alertas` para eso."
+  - "No cargar manualmente cuando el ciclo AGP ya ejecuta `ejecutarDriftAutomatico()` en cada SubagentStop — invocarlo dos veces dobla el trabajo sin beneficio."
+author: swl-ses
+evolvable: true
+evolvable_scope: [content, examples]
+domain: ingeniería-de-software
+tags: [agp, observabilidad, drift, métricas, ciclo-agp]
+---
+# drift-detection — Detección de drift para el ciclo AGP
+
+Algoritmo de ventana deslizante que compara métricas recientes (últimos 7 días)
+contra un baseline histórico (4 semanas previas) para detectar degradación de
+skills y agentes antes de que el health score lo refleje.
+
+Adaptado de `runDriftCheck`/`getDriftTimeline` en mission-control-main (MIT).
+
+## Módulo principal
+
+`scripts/lib/drift-detector.js` — zero-deps, Node stdlib únicamente.
+
+## Cuándo se activa
+
+- Manual: desde cualquier script o agente que necesite análisis de degradación.
+- Automático (vía `hooks/lib/etapa-auto-evolucion.js`): el hook ejecuta `ejecutarDriftAutomatico()`
+  en cada `SubagentStop` con un throttle de 24 h (configurable con `SWL_DRIFT_THROTTLE_H`).
+  Se evalúan los últimos 5 archivos JSONL de trazas. Opt-out total con `SWL_DRIFT_DISABLED=1`.
+- Automático (vía ciclo AGP): `hooks/lib/reflect-classifier.js` expone
+  `ejecutarDriftReflect(rutaJsonl, nombreAgente)` como punto de extensión alternativo.
+- Las trazas de agentes viven en `.planning/traces/YYYY-MM-DD.jsonl`.
+
+## Exports del módulo
+
+```js
+const { detectarDrift, generarLineaTemporal } = require('./scripts/lib/drift-detector');
+```
+
+### `detectarDrift(opts)`
+
+```js
+detectarDrift({
+  rutaJsonl:           '/ruta/a/traces.jsonl',
+  ventanaDias:         7,       // default
+  baselineSemanasBase: 4,       // default
+  umbralPct:           10,      // warn si |drift| > 10%
+  metricas:            ['tokens_promedio_por_sesion', 'tasa_exito_tool', 'tasa_finalizacion_tarea'],
+  agente:              'backend-python-swl',  // para nudges
+})
+```
+
+**Retorna:**
+
+```json
+{
+  "drifts": [
+    {
+      "metrica": "tokens_promedio_por_sesion",
+      "baseline": 1000,
+      "reciente": 2100,
+      "driftPct": 110.0,
+      "estado": "critico"
+    },
+    {
+      "metrica": "tasa_exito_tool",
+      "baseline": 0.9,
+      "reciente": 0.85,
+      "driftPct": -5.56,
+      "estado": "ok"
+    }
+  ],
+  "timestamp": "2026-04-19T12:00:00.000Z",
+  "estado_global": "critico"
+}
+```
+
+**Estados por métrica:**
+
+| Condición | Estado |
+|-----------|--------|
+| `abs(driftPct) <= umbralPct` | `ok` |
+| `abs(driftPct) > umbralPct` | `warn` |
+| `abs(driftPct) > umbralPct * 2` | `critico` |
+
+**Estado global:** el peor estado entre todas las métricas.
+
+### `generarLineaTemporal(opts)`
+
+```js
+generarLineaTemporal({
+  rutaJsonl: '/ruta/a/traces.jsonl',
+  dias:      30,   // default
+})
+// → [{ fecha: '2026-04-19', tokens: 3200, exitos: 12, fallos: 1 }, ...]
+```
+
+Retorna un array de longitud `dias`, uno por día, para visualización en
+el dashboard o en reportes de salud.
+
+## Estructura de eventos esperada en el JSONL
+
+El módulo es permisivo: extrae métricas de cualquier campo que coincida.
+
+| Métrica | Campos aceptados en el evento |
+|---------|-------------------------------|
+| Tokens | `atributos.tokens_totales`, `tokens`, `total_tokens` |
+| Éxito de tool | `success`, `exito`, `atributos.success` |
+| Finalización de tarea | `estado`, `status`, `atributos.estado` (valores: `OK`, `done`, `completado`) |
+| Timestamp | `timestamp`, `ts`, `inicio`, `created_at` |
+
+Formato nativo de `.planning/traces/YYYY-MM-DD.jsonl`:
+
+```json
+{"traceId":"...","nombre":"agent:backend-python-swl","inicio":"2026-04-19T10:00:00.000Z","estado":"OK","atributos":{"tokens_totales":1500}}
+```
+
+## Integración con el ciclo AGP
+
+El operador Reflect (`hooks/lib/reflect-classifier.js`) expone:
+
+```js
+const { ejecutarDriftReflect } = require('./hooks/lib/reflect-classifier');
+
+const resultado = ejecutarDriftReflect(
+  '.planning/traces/2026-04-19.jsonl',
+  'backend-python-swl'
+);
+// resultado: { drifts, timestamp, estado_global } o null si módulo no disponible
+```
+
+Cuando `estado_global === 'critico'`, el módulo emite automáticamente un nudge
+a `.planning/evolution/nudges.jsonl`:
+
+```json
+{
+  "timestamp": "2026-04-19T12:00:00.000Z",
+  "tipo": "drift-detectado",
+  "agente_o_skill": "backend-python-swl",
+  "metrica": "tokens_promedio_por_sesion",
+  "drift_pct": 110.0,
+  "estado": "critico"
+}
+```
+
+El agente `auto-evolucion-swl` consume estos nudges para proponer mejoras.
+
+## Cómo interpretar los resultados
+
+- **`ok`**: métricas estables. Sin acción requerida.
+- **`warn`**: degradación moderada. Revisar en el próximo ciclo de evolución.
+- **`critico`**: degradación severa. Invocar `/swl:evolucionar` con el agente
+  identificado. El nudge ya fue emitido — aparecerá en `/swl:status salud`.
+
+## Cuándo NO cargar
+
+- Se busca detectar regresiones en el código de la aplicación (tests fallando, performance degradada); para eso usar `monitoring-alertas` o el revisor de código correspondiente.
+- El proyecto tiene menos de 7 días de trazas — el baseline de 4 semanas no puede calcularse y `detectarDrift` retornará resultados sin significado estadístico.
+- El ciclo AGP ya tiene configurado el throttle automático de 24 h; invocar el drift manualmente en el mismo intervalo produce el mismo nudge dos veces sin nuevo valor.
+
+## Gotchas / Errores comunes no obvios
+
+- **Timestamps inválidos en eventos JSONL provocan líneas ignoradas silenciosamente**: el módulo es permisivo con los campos pero si ningún campo de timestamp (`timestamp`, `ts`, `inicio`, `created_at`) tiene una fecha ISO válida, el evento se descarta del cálculo. Causa: eventos generados con timestamps de formato local (ej. `"19/04/2026"`) no pasan la validación. Solución: verificar que todos los eventos JSONL del trace tengan al menos un campo de timestamp en formato ISO 8601 — si el baseline aparece como 0, es el primer síntoma de eventos descartados.
+- **Estado `critico` emitido por baseline con muy pocos eventos**: si el baseline de 4 semanas tiene solo 3 eventos y la ventana de 7 días tiene 8, el `driftPct` de tokens se dispara al 166% cuando en realidad el agente está más activo, no degradado. Causa: el módulo no valida que el baseline tenga suficientes eventos para ser estadísticamente válido. Solución: antes de interpretar un estado `critico`, verificar que el baseline tiene al menos 20 eventos — si no, marcar el resultado como `insufficient-data` en lugar de accionar.
+- **Nudge duplicado en `.planning/evolution/nudges.jsonl` por falta de deduplicación**: el hook se ejecuta dos veces en el mismo `SubagentStop` (por bug de throttle) y emite el mismo nudge dos veces. Causa: el throttle `SWL_DRIFT_THROTTLE_H` no validó correctamente el timestamp del último run. Solución: el archivo `nudges.jsonl` es append-only — antes de emitir un nudge, verificar si el último evento del mismo `agente_o_skill` y `metrica` tiene un timestamp dentro de la ventana de throttle.
+- **`atomicWriteJSON` usado para escribir en nudges.jsonl**: escribir el archivo completo en lugar de hacer append corrompe el historial de nudges previos. Causa: confusión entre archivos de estado mutable (usan `atomicWriteJSON`) y archivos de eventos de alta frecuencia (usan `fs.appendFileSync`). Solución: `nudges.jsonl` es un JSONL de alta frecuencia — siempre usar `fs.appendFileSync(ruta, JSON.stringify(nudge) + '\n')`, nunca reescribir el archivo completo.
+
+## Referencia cruzada
+
+- Módulo: `scripts/lib/drift-detector.js`
+- Tests: `tests/lib/drift-detector.test.js`
+- Operador Reflect: `hooks/lib/reflect-classifier.js`
+- Ciclo AGP: `.planning/evolution/nudges.jsonl`
+- Origen (adaptado de): `temp/mission-control-main/src/lib/agent-evals.ts` — MIT

package/habilidades/ejecutar-fase/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: ejecutar-fase
-description: Ejecuta el PLAN.md de una fase con commits atómicos por tarea. Aplica reglas de desviación, maneja checkpoints HITL, soporta TDD opcional, y mantiene ESTADO.md y HOJA-RUTA.md actualizados tras cada tarea completada.
-version: "1.1.0"
+description: Ejecuta el PLAN.md de una fase con commits atómicos por tarea. Aplica reglas de desviación, maneja checkpoints HITL, ejecuta TDD por default con evidencia RED en telemetría (opt-out declarado), y mantiene ESTADO.md y HOJA-RUTA.md actualizados tras cada tarea completada.
+version: "1.2.0"
 herramientasPermitidas: [Read, Write, Edit, Bash, Glob, Grep]
 exclusiones:
   - "No cargar si no existe PLAN.md con `estado: aprobado` — ejecutar `planear-fase` primero."
@@ -31,7 +31,7 @@ antipatrón de acumular cambios sin verificar y commitear "todo de golpe".
 
 ## Cuándo NO cargar
 
-- No hay PLAN.md o el plan tiene `estado: propuesto` (no aprobado) — ejecutar `planear-fase` y obtener aprobación primero.
+- No hay PLAN.md o el plan no tiene `estado: aprobado` — ejecutar `planear-fase` y aprobar con `/swl:aprobar-plan N` (firma el lock G1) antes de ejecutar.
 - El objetivo es solo verificar calidad del trabajo ya implementado; usar `verificar-trabajo`.
 - Hay un checkpoint `decision` o `human-action` sin resolver en ESTADO.md — resolver el checkpoint antes de continuar la ejecución.
 - Se quiere ejecutar solo una sub-tarea fuera de la secuencia de oleadas del plan; hacerlo rompe el grafo de dependencias y el estado en ESTADO.md.
@@ -41,6 +41,26 @@ antipatrón de acumular cambios sin verificar y commitear "todo de golpe".
 Leer `.planning/fases/0N-PLAN.md` y `.planning/ESTADO.md` (si existe) antes de
 ejecutar la primera tarea.
 
+### Gate G1 — integridad del plan firmado
+
+Antes de la primera tarea Y al inicio de cada slice, verificar que el PLAN no
+fue mutado tras su aprobación:
+
+```bash
+node -e "const {verificarPlan}=require('./scripts/lib/plan-lock'); console.log(JSON.stringify(verificarPlan('.planning/fases/0N-PLAN.md')))"
+```
+
+- `modo: "firmado"` → continuar.
+- `modo: "legacy"` (plan aprobado sin lock, cláusula de gracia D-05 para planes
+  pre-Fase09) → advertencia visible al usuario y continuar sin verificación de
+  integridad. Para activar el gate: `/swl:aprobar-plan N`.
+- `modo: "mutado"` → DETENER. El plan cambió tras la firma; reportar
+  `hashEsperado`/`hashActual` y remitir a `/swl:aprobar-plan N`.
+- cualquier otro `ok: false` → DETENER y reportar el `motivo`.
+
+La firma se escribe en `.planning/locks/0N-PLAN.md.lock` (versionado en git).
+La única vía válida de aprobar+firmar es `/swl:aprobar-plan`.
+
 ---
 
 ## Protocolo de ejecución por tarea
@@ -146,11 +166,16 @@ Reglas:
 - Detalle adicional si es necesario
 - Referencia a la tarea del plan
 
-Co-Authored-By: SWL Agent <noreply@swl.dev>
+Refs: REQ-NN[, REQ-MM]
 ```
 
 Tipos de commit válidos: `feat`, `fix`, `test`, `refactor`, `docs`, `chore`, `migration`
 
+El footer `Refs: REQ-NN` cierra la cadena de trazabilidad REQ→T→commit (G4):
+lleva los REQ que la tarea declara en su campo `**Verifica REQ**` del PLAN.
+Omitirlo solo en fases legacy sin REQ-IDs. SIN co-autores ni atribuciones a IA
+(regla global `git-coauthor.md` — el único autor es el usuario).
+
 ---
 
 ## Modo Pipeline: acumulación de resultados entre tareas
@@ -267,23 +292,44 @@ B) [opción B]
 
 ---
 
-## TDD opcional (activar si el CONTEXTO.md lo requiere)
+## TDD por default con evidencia RED (gate G2 — opt-out declarado)
+
+TDD es **default ON** desde la Fase 10 (vNext H2). Solo se omite cuando el
+CONTEXTO.md declara `**TDD**: off — razón: [...]` (excepción registrada en
+AUDITORIA.md por `discutir-fase`). Sin esa declaración, toda tarea de código
+sigue el ciclo con evidencia.
 
-Cuando el CONTEXTO.md indica que la fase requiere TDD:
+### Ciclo RED → GREEN → REFACTOR por tarea (con telemetría)
 
-### Ciclo RED → GREEN → REFACTOR por tarea
+Al iniciar la primera tarea de código de la fase, abrir la corrida de evidencia:
+
+```bash
+node -e "const lt=require('./hooks/lib/loop-telemetry');const r=lt.iniciarCorrida({tipo:'tdd',direccion:'lower_is_better',config:{fase:'0N',tarea:'T-NN'}});console.log(r.dir)"
+```
 
 **RED**: Escribir el test que describe el comportamiento esperado.
 El test DEBE fallar. Verificar que falla por la razón correcta, no por error
-de sintaxis o configuración.
+de sintaxis o configuración. **Registrar la evidencia** (métrica = tests fallando,
+descripción = fallo exacto):
+
+```bash
+node -e "const lt=require('./hooks/lib/loop-telemetry');lt.registrarIteracion('<dir>',{iteracion:0,metrica:<N_fallan>,delta:0,estado:'baseline',descripcion:'RED T-NN: <fallo exacto del runner>'})"
+```
 
 **GREEN**: Escribir la implementación mínima que hace pasar el test.
-"Mínima" significa: no implementar más de lo que el test exige. Resistir la
-tentación de añadir casos no cubiertos por tests.
+"Mínima" significa: no implementar más de lo que el test exige. Registrar:
+
+```bash
+node -e "const lt=require('./hooks/lib/loop-telemetry');lt.registrarIteracion('<dir>',{iteracion:1,metrica:0,delta:-<N>,estado:'keep',descripcion:'GREEN T-NN: suite verde'})"
+```
 
 **REFACTOR**: Limpiar el código sin cambiar el comportamiento.
 El test DEBE seguir pasando después del refactor. Hacer commit solo en este paso.
 
+La fila RED en `.planning/loops/tdd-*/iteraciones.tsv` es la evidencia que
+`hooks/tdd-gate.js` busca al commitear (warn-only, ADR-0035) — cierra F-TDD-6
+("el RED no deja evidencia"). Sin registro, el gate emite nudge `tdd-red-evidence`.
+
 ### Cobertura mínima en modo TDD
 
 - Toda función pública tiene al menos 1 test de camino feliz
@@ -344,10 +390,10 @@ Actualizar ESTADO.md después de cada tarea (no al final de la oleada):
 - Pendientes: N-M-K
 
 ## Estado por tarea
-| ID   | Nombre | Estado | Commit | Notas |
-|------|--------|--------|--------|-------|
-| T-01 | [nombre] | COMPLETADA | abc1234 | |
-| T-02 | [nombre] | COMPLETADA | def5678 | |
+| ID   | Nombre | Estado | Commit | REQ | Notas |
+|------|--------|--------|--------|-----|-------|
+| T-01 | [nombre] | COMPLETADA | abc1234 | REQ-01 | |
+| T-02 | [nombre] | COMPLETADA | def5678 | REQ-01, REQ-02 | |
 | T-03 | [nombre] | EN_PROGRESO | — | |
 | T-04 | [nombre] | PENDIENTE | — | depende T-03 |
 | T-05 | [nombre] | BLOQUEADA | — | [descripción del bloqueo] |
@@ -466,3 +512,7 @@ NO proceder con el deploy hasta aprobar este gate.
 - [ ] Decisiones HITL registradas con respuesta del usuario
 - [ ] Tests pasan en el estado final del código
 - [ ] No hay `console.log`, `print()` de debug ni pendientes sin ticket en el código nuevo
+- [ ] `.planning/locks/fase-activa.json` eliminado (libera el gate G0 — el `.lock`
+      del plan NO se toca: es evidencia versionada)
+- [ ] `/swl:verificar --until-converge` invocado automáticamente (gate G4) — o
+      desviación `--sin-verify` registrada en RESUMEN.md con razón

package/habilidades/estructura-proyecto-claude/SKILL.md

@@ -6,9 +6,9 @@ description: >
   Cargar al inicializar proyecto nuevo, migrar proyecto existente al sistema SWL,
   auditar estructura Claude-ready, agregar extensiones (commands, skills, agents,
   hooks, plugins), o configurar MCP. Cubre arquitectura de 4 capas, jerarquía
-  de memoria, 6 tipos de extensión, 27 hook events, frontmatter de skills/agents/commands
+  de memoria, 6 tipos de extensión, 30 hook events, frontmatter de skills/agents/commands
   y settings avanzados.
-version: "1.0.0"
+version: "1.1.0"
 herramientasPermitidas: [Read, Write, Edit, Bash, Glob, Grep]
 exclusiones:
   - "No cargar para iniciar un proyecto desde cero — ese flujo usa `/swl:nuevo-proyecto` que incluye entrevista de contexto antes de generar la estructura; este skill genera estructura pero no recoge requisitos de negocio."
@@ -53,7 +53,7 @@ mi_proyecto/
 |   +-- plugins/                           # Plugins distribuibles
 +-- .planning/                             # Estado de planificación SWL
 |   +-- PROYECTO.md, REQUISITOS.md, HOJA-RUTA.md, ESTADO.md
-|   +-- research/
+|   +-- fases/, adrs/, research/
 +-- .mcp.json                              # Configuracion de servidores MCP
 ```
 
@@ -74,17 +74,19 @@ mi_proyecto/
 
 | Scope | Path | Aplica a |
 |-------|------|----------|
-| **Managed Policy** | Sistema | Todos los usuarios org |
+| **Managed Policy** | Sistema (ej. Windows: `C:\Program Files\ClaudeCode\CLAUDE.md`) | Todos los usuarios org |
 | **User** | `~/.claude/CLAUDE.md` | Todos tus proyectos |
-| **Project** | `./CLAUDE.md` | Proyecto (repo) |
+| **Project** | `./CLAUDE.md` o `./.claude/CLAUDE.md` | Proyecto (repo) |
+| **Local** | `./CLAUDE.local.md` (en `.gitignore`) | Solo tú, este proyecto |
 | **Subdirectory** | `packages/frontend/CLAUDE.md` | Paquete del monorepo |
 
 ### Comportamiento de carga
 
-- **Ancestor (ARRIBA)**: al inicio, carga TODOS los CLAUDE.md desde cwd hasta la raíz del sistema de archivos — siempre se cargan
-- **Descendant (ABAJO)**: lazy — solo carga cuando Claude navega a un subdirectorio
+- **Ancestor (ARRIBA)**: al inicio, carga TODOS los CLAUDE.md y CLAUDE.local.md desde cwd hasta la raíz del sistema de archivos — siempre se cargan, concatenados (raíz primero, cwd al final)
+- **Descendant (ABAJO)**: lazy — solo carga cuando Claude lee archivos en ese subdirectorio
 - **Siblings**: NUNCA se cargan entre sí
-- Solo las **primeras 200 líneas** de cada CLAUDE.md se inyectan al prompt del sistema
+- Cada CLAUDE.md se carga **completo** sin importar su longitud — el límite de 200 líneas es recomendación de adherencia, no truncado. (El truncado de 200 líneas / 25KB aplica al `MEMORY.md` de auto memory, no a CLAUDE.md.)
+- **Auto memory** (complementario): Claude escribe notas propias en `~/.claude/projects/<proyecto>/memory/` — activado por defecto, gestionable con `/memory` o `autoMemoryEnabled`
 
 **Reglas clave**: Menos de 200 líneas por CLAUDE.md. Subdirectorios agregan, NUNCA sobreescriben.
 
@@ -94,8 +96,8 @@ mi_proyecto/
 
 | Tipo | Activación | Ubicación |
 |------|-----------|-----------|
-| **Skills** | Auto-activación | `.claude/skills/` |
-| **Commands** | Manual (`/comando`) | `.claude/commands/` |
+| **Skills** | Auto-activación o `/nombre` | `.claude/skills/` |
+| **Commands** | Manual (`/comando`) — fusionados con skills, mismo frontmatter | `.claude/commands/` |
 | **Subagents** | Spawn por orquestador | `.claude/agents/` |
 | **Hooks** | Event-driven | `settings.json` hooks |
 | **MCP Servers** | Siempre disponibles | `.mcp.json` |
@@ -116,7 +118,7 @@ mi_proyecto/
 ```yaml
 ---
 name: nombre-skill              # kebab-case, max 64 chars
-description: >                  # max 1024 chars — QUÉ + CUÁNDO
+description: >                  # QUÉ + CUÁNDO (description + when_to_use truncados a 1,536 chars combinados)
   Describe qué hace y cuándo Claude debe auto-activarla.
 allowed-tools: ["Read", "Grep", "Glob"]
 paths:
@@ -129,7 +131,7 @@ Ver referencia completa en [recursos/frontmatter-y-hooks-referencia.md](recursos
 
 ---
 
-## Hook Events (14 críticos de 27 oficiales)
+## Hook Events (7 críticos de 30 oficiales)
 
 | Evento | Cuándo se dispara | Uso típico |
 |--------|-------------------|-----------|
@@ -141,8 +143,9 @@ Ver referencia completa en [recursos/frontmatter-y-hooks-referencia.md](recursos
 | **PostCompact** | Después de compactar | Re-inyectar contexto |
 | **Notification** | Claude espera input | Alertas desktop |
 
-Los 20 eventos restantes, frontmatter de agents (16 campos) y commands (13 campos),
-opciones avanzadas de hooks y orden de resolución en
+Los 23 eventos restantes, frontmatter de agents (16 campos) y de skills/commands
+(unificados — los commands se fusionaron con skills), opciones avanzadas de hooks
+y orden de resolución en
 [recursos/frontmatter-y-hooks-referencia.md](recursos/frontmatter-y-hooks-referencia.md).
 
 ---