@saulwade/swl-ses 1.6.1 → 1.6.5

package/habilidades/harness-claude-code/SKILL.md

@@ -10,7 +10,7 @@ description: >
   Cargar cuando el usuario reporte "se acabó la cuota", se prepare una
   sesión Opus larga (>2h), se planifique adopción de MCP servers, o se
   detecte context-rot recurrente.
-version: "1.0.0"
+version: "1.0.1"
 evolved: false
 herramientasPermitidas: [Read]
 exclusiones:
@@ -268,6 +268,9 @@ Sin observar la métrica, no puedes optimizarla.
 - **`/clear` mid-session destruye el plan en curso**: usuario pierde el roadmap acumulado. Causa: confundir `/clear` con `/compact`. Solución: `/compact` resume manteniendo conocimiento; `/clear` empieza desde cero. Antes de `/clear`, escribir un handoff a `.planning/COMPACTACION.md` con `/swl:compactar`.
 - **Tag files con `@` apuntando a archivos enormes**: Claude carga el archivo completo en contexto aunque solo necesite una sección. Causa: usar `@` con archivos >500 líneas. Solución: para archivos grandes, citar sección específica en el prompt (`@ src/auth.py líneas 100-150`) o pre-extraer con `Read offset/limit`.
 - **`/effort high` que se queda activo en prompts simples**: el siguiente prompt trivial gasta 2× tokens innecesarios. Causa: el effort se interpreta como "session-wide" cuando es per-prompt. Solución: explícito `/effort medium` (o lo que aplique) en el siguiente prompt si la complejidad bajó.
+- **`child_process.spawn(cmd, args, { env: {} })` REEMPLAZA el env del padre con vacío, NO hereda** [CONFIRMADO 2026-05-18]: el cliente MCP de Claude Code (y el de Cursor) lee `mcpServers.X.env` del config JSON y lo pasa literal al spawn. Si la config tiene `"env": {}` explícito, el binario hijo arranca SIN ninguna variable de entorno del padre — rompe la herencia de apiKeys que viven en HKCU/registry. Síntoma: MCP server da `40101 Authorization required` aunque `setx OBSIDIAN_API_KEY` esté correcto en HKCU y curl con esa key responda HTTP 200 al plugin. Causa: Node `child_process.spawn` con `env: {}` ≠ sin `env` option. Solución: **OMITIR la clave `env` por completo en el JSON** (no dejarla vacía). Verificado empíricamente con `spawn(binario, [], { /* sin env */ })` → binario heredó `OBSIDIAN_API_KEY`; `spawn(binario, [], { env: {} })` → binario sin env. El patch SWL para Python (`scripts/lib/mcp_config.py::build_stdio_env`) merge `os.environ + overrides` para corregir el mismo síntoma en el lado Python.
+- **MCP server devuelve auth error con apiKey correcta en disco → el proceso vivo arrancó con apiKey vieja** [CONFIRMADO 2026-05-18]: aunque `~/.cursor/mcp.json` y `~/.claude/settings.json` tengan la apiKey actual del plugin, los procesos del binario MCP (ej. `mcp-obsidian.exe`) que ya están corriendo retuvieron la apiKey del momento de su spawn. Síntoma: actualizar JSONs no soluciona 40101. Solución: `taskkill /F /IM mcp-obsidian.exe /T` (Windows) o `pkill mcp-obsidian` (Unix) + **quit total del cliente parent** (Cursor.exe / claude.exe) — no basta reload de ventana. Al reabrir, el cliente respawnea el binario con env actual. Verificar con `ps -W | grep mcp-obsidian` que solo haya procesos con timestamp posterior al reinicio.
+- **Cursor y Claude Code CLI dentro de Cursor son clientes MCP DISTINTOS con procesos independientes** [CONFIRMADO 2026-05-18]: cuando se ejecuta Claude Code CLI en una terminal embebida de Cursor, hay DOS procesos del binario MCP corriendo simultáneamente — uno por cliente. Cada uno lee SU PROPIA config: Cursor lee `~/.cursor/mcp.json`, Claude Code CLI lee `~/.claude/settings.json` + `<proyecto>/.claude/settings.local.json`. Una apiKey actualizada en uno no propaga al otro. Síntoma observado: el agente AI de Cursor responde MCP OK pero Claude Code CLI da 40101 (o viceversa). Solución: usar variable de entorno persistente del SO (`setx OBSIDIAN_API_KEY` → HKCU\Environment) como single source of truth y dejar configs JSON sin clave `env` para heredar del padre. Cada regeneración de apiKey requiere un solo `setx` + reiniciar Cursor (que reinicia ambos clientes).
 
 ---
 

package/habilidades/meta-skills-estandar/SKILL.md

@@ -272,6 +272,12 @@ el contenido específico, sin inflar el contexto con cada invocación:
   valor depende de mostrar diff MAL→BIEN lado a lado (decisiones, arquitectura,
   anti-patrones sutiles). NO retroactiva — las 63 carpetas `recursos/` existentes
   no se renombran. Ver [recursos/convencion-examples.md](recursos/convencion-examples.md).
+- **Rúbrica skill-judge (Knowledge Delta + Freedom Calibration + 5 patrones)** —
+  tres lentes complementarios a las 10 dimensiones de `/swl:evaluar-skill`
+  para autoría: detectar contenido redundante, matchear libertad a fragilidad,
+  elegir patrón estructural al inicio. NO reemplaza el gate `/swl:evaluar-skill`;
+  aplica durante la escritura. Ver [recursos/skill-judge-rubrica.md](recursos/skill-judge-rubrica.md).
+  Origen: ADR-0024.
 
 Cada recurso tiene ToC al inicio y es autocontenido — leer solo el relevante
 al caso en cuestión en lugar de los tres.

package/habilidades/meta-skills-estandar/recursos/skill-judge-rubrica.md

@@ -0,0 +1,281 @@
+# Rúbrica skill-judge — 3 dimensiones complementarias a `evaluar-skill`
+
+Recurso opcional que se carga bajo demanda cuando se autora un SKILL.md y se
+quieren aplicar tres lentes adicionales que el comando `/swl:evaluar-skill`
+no mide directamente. Adaptación de la rúbrica `skill-judge` (agent-toolkit,
+8 dimensiones × 120 puntos) para complementar las 10 dimensiones ponderadas
+del comando SWL.
+
+**Origen**: análisis comparativo documentado en ADR-0024 — Opción B.
+**NO reemplaza** `/swl:evaluar-skill`; añade tres lentes de autoría que el
+comando deja fuera por ser difíciles de medir programáticamente.
+
+---
+
+## Por qué este recurso existe
+
+El comando `/swl:evaluar-skill` mide 10 dimensiones que cubren bien:
+trigger, orquestación, scope, progressive disclosure, robustez, completitud
+estructural. Tras comparar con la rúbrica de 8 dimensiones de
+`temp/agent-toolkit/skills/skill-judge/`, detecté tres lentes que aporta
+valor agregado al **autor del skill**, no al evaluador automático:
+
+| Lente skill-judge | Por qué falta en SWL | Cuándo aporta |
+|---|---|---|
+| **Knowledge Delta** | Difícil de medir programáticamente | Al escribir skill nuevo: detectar contenido redundante |
+| **Freedom Calibration** | Subjetivo (alta/media/baja libertad) | Al elegir nivel de prescripción según fragilidad |
+| **Pattern Recognition (5 patrones)** | Clasificación, no calidad | Al elegir estructura del skill al inicio |
+
+Estas tres dimensiones se aplican durante la **autoría**, no la **evaluación
+final**. Para el gate de calidad sigue usándose `/swl:evaluar-skill`.
+
+---
+
+## Lente 1 — Knowledge Delta
+
+> **Buen Skill = Conocimiento de experto − lo que el modelo ya sabe.**
+
+El valor de un skill se mide por su **delta de conocimiento** — la brecha
+entre lo que provee y lo que el modelo ya tiene en sus pesos.
+
+### Las 3 categorías de contenido
+
+| Tipo | Definición | Tratamiento |
+|------|-----------|-------------|
+| **Expert** | El modelo genuinamente no lo sabe | Mantener — es el valor del skill |
+| **Activation** | El modelo lo sabe pero podría no pensar en ello | Mantener si es breve — funciona como recordatorio |
+| **Redundant** | El modelo definitivamente lo sabe | Borrar — desperdicia tokens |
+
+### Red flags (contenido a borrar agresivamente)
+
+- "¿Qué es [concepto básico]?" — el modelo lo sabe.
+- Tutoriales paso a paso para operaciones estándar (open file, read, write).
+- Explicaciones de uso de librerías comunes (cómo usar `requests`,
+  `fetch`, etc.).
+- Best practices genéricas ("escribe código limpio", "maneja errores").
+- Definiciones de términos estándar de la industria.
+
+### Green flags (contenido de alto valor)
+
+- Decision trees para decisiones no obvias ("cuando X falla, intenta Y
+  porque Z").
+- Trade-offs que solo un experto conoce ("A es más rápido pero B maneja
+  el edge case C").
+- Edge cases de experiencia real ("MissingGreenlet pasa cuando…").
+- "NEVER hagas X porque [razón no obvia]".
+- Frameworks de pensamiento específicos del dominio.
+
+### Test mental
+
+Al revisar cada sección de tu SKILL.md, preguntar:
+
+1. *¿El modelo ya sabe esto?* Si sí → marcar como Redundant, borrar.
+2. *¿Esto explica TO el modelo o FOR el modelo?* TO = redundant; FOR = valor.
+3. Calcular ratio E:A:R. Bueno: >70% Expert, <20% Activation, <10% Redundant.
+
+### Conexión con `reducir-entropia`
+
+El skill SWL `reducir-entropia` aplica el mismo principio al codebase
+(menos líneas finales = win). Knowledge delta lo aplica al SKILL.md
+(menos tokens redundantes = win). Mismo lente, distinto target.
+
+---
+
+## Lente 2 — Freedom Calibration
+
+> **Match freedom to fragility.**
+
+Diferentes tareas requieren diferentes niveles de restricción en el skill.
+
+### El espectro
+
+| Tipo de tarea | Debería tener | Por qué |
+|---|---|---|
+| Creativo / Diseño | Alta libertad | Múltiples caminos válidos; diferenciación es el valor |
+| Code review | Libertad media | Hay principios, pero juicio requerido |
+| Operaciones en formato de archivo | Baja libertad | Un byte mal corrompe el archivo |
+
+### Ejemplos
+
+**Alta libertad** (principios, no pasos):
+
+```markdown
+Commit a una dirección estética BOLD. Elige un extremo: minimalismo
+brutal, caos maximalista, retro-futurista, orgánico natural…
+```
+
+**Libertad media** (priorización + criterio):
+
+```markdown
+Prioridad de revisión:
+1. Vulnerabilidades de seguridad (must fix)
+2. Errores de lógica (must fix)
+3. Performance (should fix)
+4. Mantenibilidad (opcional)
+```
+
+**Baja libertad** (script exacto):
+
+```markdown
+**OBLIGATORIO**: usar exactamente `scripts/create-doc.py` con parámetros
+`--title "X" --author "Y"`. NO modificar el script.
+```
+
+### Test
+
+Pregunta: *si el modelo comete error, ¿cuál es la consecuencia?*
+
+- Consecuencia alta → libertad baja (prescriptivo).
+- Consecuencia baja → libertad alta (principios).
+
+### Errores comunes de calibración
+
+- **Rígido para tarea creativa**: skill que prescribe paso a paso una
+  decisión estética destruye el valor del skill.
+- **Vago para operación frágil**: skill que dice "ten cuidado al editar
+  XML" sin reglas exactas garantiza archivos corruptos.
+
+---
+
+## Lente 3 — Patrones reconocibles (5 patrones del agent-toolkit)
+
+Al elegir la **estructura** de un skill nuevo, identificar a cuál de
+estos 5 patrones se ajusta. Ayuda a calibrar tamaño y profundidad.
+
+| Patrón | Líneas | Características clave | Cuándo usarlo |
+|---|---|---|---|
+| **Mindset** | ~50 | Pensamiento > técnica, NEVER list fuerte, alta libertad | Tareas creativas que requieren gusto |
+| **Navigation** | ~30 | SKILL.md mínimo, rutea a sub-archivos en `recursos/` | Múltiples escenarios distintos |
+| **Philosophy** | ~150 | Dos pasos: Filosofía → Express, enfatiza craft | Arte/creación que requiere originalidad |
+| **Process** | ~200 | Workflow por fases, checkpoints, libertad media | Proyectos multi-paso complejos |
+| **Tool** | ~300 | Decision trees, ejemplos de código, libertad baja | Operaciones precisas en formato específico |
+
+### Guía de selección
+
+| Tu tarea es… | Patrón recomendado |
+|---|---|
+| Requiere gusto y creatividad | Mindset (~50 líneas) |
+| Requiere originalidad y craft quality | Philosophy (~150 líneas) |
+| Tiene múltiples sub-escenarios distintos | Navigation (~30 líneas) |
+| Proyecto complejo multi-paso | Process (~200 líneas) |
+| Operación precisa en formato específico | Tool (~300 líneas) |
+
+### Mapeo a skills SWL existentes (referencia)
+
+- `meta-skills-estandar` — Philosophy/Process (526 líneas; rebasa el ideal
+  pero contiene 5 secciones extendidas justificadas por ADR).
+- `tdd-workflow` — Process.
+- `verificar-trabajo` — Process con decision trees.
+- `discutir-fase` — Process.
+- `reducir-entropia` — Mindset (~200 líneas, anti-patrón consciente).
+- `proceso-confianza-pre-implementacion` — Process.
+- `proceso-autoverificacion-evidencias` — Process.
+- `aprender-de-git-diff` — Mindset/Process híbrido.
+- Skills de formato de archivo (cuando aplique) — Tool.
+
+---
+
+## Las 7 fallas comunes (Common Failure Patterns)
+
+Adaptado de skill-judge "Common Failure Patterns". Si tu skill cae en uno
+de estos, refactorizar antes de mergear.
+
+### 1. The Tutorial
+
+**Síntoma**: explica qué es PDF, cómo funciona Python, uso básico de librería.
+**Causa**: autor asume que el skill debe "enseñar" al modelo.
+**Fix**: el modelo ya sabe esto. Borrar todas las explicaciones básicas.
+Enfocar en decisiones de experto, trade-offs, anti-patrones.
+
+### 2. The Dump
+
+**Síntoma**: SKILL.md de 800+ líneas con todo incluido.
+**Causa**: sin diseño de progressive disclosure.
+**Fix**: routing y decision trees en SKILL.md (<300 líneas ideal). Contenido
+detallado a `recursos/`, cargado bajo demanda.
+
+### 3. The Orphan References
+
+**Síntoma**: directorio `recursos/` existe pero los archivos nunca se cargan.
+**Causa**: sin triggers explícitos de carga.
+**Fix**: agregar "OBLIGATORIO — LEER ARCHIVO COMPLETO" en puntos de
+decisión del workflow. Agregar "NO cargar" para prevenir sobre-carga.
+
+### 4. The Checkbox Procedure
+
+**Síntoma**: Paso 1, Paso 2, Paso 3… procedimientos mecánicos.
+**Causa**: autor piensa en procedimientos, no en frameworks de pensamiento.
+**Fix**: transformar en "Antes de hacer X, pregúntate…". Enfocar en
+principios de decisión, no secuencias de operación.
+
+### 5. The Vague Warning
+
+**Síntoma**: "Ten cuidado", "evita errores", "considera edge cases".
+**Causa**: autor sabe que cosas pueden salir mal pero no las articuló.
+**Fix**: NEVER list específico con ejemplos concretos y razones no obvias.
+"NEVER uses X porque [problema específico que solo experiencia enseña]".
+
+### 6. The Invisible Skill
+
+**Síntoma**: gran contenido pero el skill raramente se activa.
+**Causa**: description vaga, sin keywords, sin trigger scenarios.
+**Fix**: description responde WHAT + WHEN + KEYWORDS. "Usar cuando…" +
+escenarios específicos + términos buscables.
+
+### 7. The Over-Engineered
+
+**Síntoma**: README.md, CHANGELOG.md, INSTALLATION_GUIDE.md, CONTRIBUTING.md
+dentro del directorio del skill.
+**Causa**: tratar al skill como proyecto de software.
+**Fix**: borrar todos los archivos auxiliares. Solo incluir lo que el
+modelo necesita para la tarea. Cero documentación sobre el skill mismo.
+
+---
+
+## NUNCA al evaluar (skill-judge)
+
+- **NUNCA** dar score alto solo porque "se ve profesional" o bien formateado.
+- **NUNCA** ignorar token waste — cada párrafo redundante penaliza.
+- **NUNCA** dejar que la longitud te impresione — un skill de 43 líneas
+  puede superar a uno de 500.
+- **NUNCA** saltarse el test mental de los decision trees — ¿realmente
+  llevan a la elección correcta?
+- **NUNCA** perdonar explicaciones básicas con "pero da contexto útil".
+- **NUNCA** subvalorar el campo `description` — pobre description = skill
+  nunca se activa.
+
+---
+
+## La pregunta meta
+
+Al revisar cualquier skill, regresar a:
+
+> **"¿Un experto en este dominio, mirando este skill, diría: 'sí, esto
+> captura conocimiento que me tomó años aprender'?"**
+
+Si la respuesta es sí → valor genuino.
+Si la respuesta es no → comprime lo que el modelo ya sabe → basura.
+
+Los mejores skills son **cerebros expertos comprimidos** — toman 10 años
+de acumulación de un diseñador y los comprimen en 43 líneas, o la
+experiencia operacional de un experto en documentos en un decision tree
+de 200 líneas.
+
+Lo que se comprime debe ser cosas que el modelo NO tiene. De lo contrario,
+es compresión basura.
+
+---
+
+## Cómo aplicar este recurso durante autoría
+
+1. **Antes de escribir**: identificar patrón (Mindset/Navigation/Philosophy/
+   Process/Tool) según la tabla de selección. Esto define tamaño objetivo.
+2. **Durante escritura**: aplicar Freedom Calibration — match libertad a
+   fragilidad.
+3. **Después de primera versión**: pasar el lente de Knowledge Delta sección
+   por sección. Marcar E/A/R. Borrar Redundant agresivamente.
+4. **Antes de commit**: revisar contra las 7 fallas comunes.
+5. **Antes de merge**: ejecutar `/swl:evaluar-skill <nombre>` para el score
+   formal de las 10 dimensiones SWL.
+
+Los 3 lentes de este recurso son aditivos al gate formal. No lo reemplazan.

package/habilidades/postgresql-experto/SKILL.md

@@ -1,12 +1,12 @@
 ---
 name: postgresql-experto
 description: PostgreSQL avanzado. JSONB, arrays, tipos personalizados, búsqueda de texto completo, window functions, CTEs recursivos, Row Level Security y funciones almacenadas.
-version: "1.1.0"
+version: "1.2.0"
 evolved: true
-evolved-from: "1.0.0"
-evolved-at: "2026-05-05"
+evolved-from: "1.1.0"
+evolved-at: "2026-05-20"
 evolved-by: "aprender"
-evolved-note: "3 gotchas nuevos de la sesión SIGM 2026-05-05: RLS bypass por superusuarios, UUIDs hex en seeds, consultar enum_range antes de seedear (L2/L4/L8)"
+evolved-note: "4 gotchas nuevos consolidados SIGM L-152/L-153/L-156 + SIGAF 2026-05-15: race condition SELECT-then-write fuera de transaction (CONFIRMADO x4), UPDATE WHERE col1 sin dimensiones de scoping, drift triple Literal↔validator↔ENUM, partial unique index con WHERE requiere predicado puro (no subqueries)"
 herramientasPermitidas: [Read, Grep]
 exclusiones:
   - "No cargar para optimización de queries SQL (EXPLAIN ANALYZE, índices, partitioning) — para optimización cargar `sql-optimizacion`."
@@ -172,3 +172,79 @@ Si el valor que necesitas no existe, agregar la variante con `ALTER TYPE ... ADD
 **`FORCE ROW LEVEL SECURITY` no protege al usuario dueño de la tabla (superuser/owner)**: el propietario de la tabla y los superusuarios de PostgreSQL bypasean RLS por defecto aunque esté `FORCE` habilitado. Causa: `FORCE` aplica a todos los usuarios excepto al dueño de la tabla y a superusuarios. Fix: si la aplicación conecta como el dueño de la tabla, cambiar el rol de conexión a un rol de aplicación sin privilegios de dueño (`GRANT CONNECT ON DATABASE ... TO app_user`), no usar el usuario `postgres` para conexiones de aplicación.
 
 **`tsvector` `GENERATED ALWAYS AS STORED` no actualiza cuando cambia la configuración de idioma**: si la columna `busqueda_ts` fue generada con `to_tsvector('spanish', ...)` y luego se cambia el contenido con texto en otro idioma, las palabras no se stemmizan correctamente — pero la columna no se regenera. Causa: la columna generada se recalcula solo cuando cambia la fila, no cuando cambia la lógica de la expresión. Fix: si se cambia la expresión de la columna generada, hacer `ALTER TABLE ... DROP COLUMN busqueda_ts; ALTER TABLE ... ADD COLUMN ...` para regenerar todos los valores.
+
+**SELECT-then-INSERT/UPDATE FUERA de `conn.transaction()` produce race condition** (CONFIRMADO x4 en sesiones SIGM 2026-05-20): patrón `SELECT id FROM X WHERE clave=$1` seguido de `INSERT/UPDATE X` sin envolver en transacción permite a otra petición concurrente insertar entre el SELECT y el write — viola unicidad lógica aunque haya UNIQUE constraint (la 2da petición recibe error pero después de hacer trabajo). Casos: doble VIGENTE en valuación, doble documento/orden con mismo folio, subdivisión/fusión/traslado de predios concurrentes. Fix obligatorio:
+```python
+async with self._conn.transaction():
+    # SELECT con lock explícito
+    row = await self._conn.fetchrow(
+        "SELECT id, version FROM tabla WHERE clave=$1 FOR UPDATE",
+        clave,
+    )
+    if row is None:
+        await self._conn.execute(
+            "INSERT INTO tabla (clave, ...) VALUES ($1, ...)",
+            clave, ...,
+        )
+    else:
+        # Si requiere CAS: WHERE clave=$1 AND version=$N en el UPDATE
+        await self._conn.execute(
+            "UPDATE tabla SET ... WHERE id=$1",
+            row["id"],
+        )
+```
+Alternativas:
+- `INSERT ... ON CONFLICT (clave) DO NOTHING/UPDATE` cuando la lógica es upsert puro.
+- `SELECT FOR UPDATE` para bloquear filas existentes durante el chequeo.
+- CAS en `WHERE version=$N` cuando el lock es muy costoso y se prefiere reintento.
+
+Regla de auditoría: cualquier endpoint con `SELECT ... WHERE` seguido de `INSERT`/`UPDATE` sobre la misma tabla DEBE estar dentro de `async with self._conn.transaction():`. El UNIQUE constraint NO sustituye el lock — es defensa de último recurso.
+
+**`UPDATE ... WHERE columna1 = $1` sin filtrar dimensiones adicionales des-actualiza filas hermanas**: SIGM NEM-VA-03 (2026-05-20). `UPDATE valuacion SET es_vigente=false WHERE predio_id=$1` cuando el predio tiene múltiples ejercicios fiscales des-vigentaba TODOS los ejercicios, no solo el actual. El bug pasó UNIQUE constraint (cada fila era válida individualmente) pero rompió integridad de dominio (debe haber 1 VIGENTE por (predio, ejercicio), no 1 VIGENTE por predio). Fix:
+```sql
+-- MAL
+UPDATE valuacion SET es_vigente=false WHERE predio_id=$1;
+
+-- BIEN
+UPDATE valuacion SET es_vigente=false
+WHERE predio_id=$1 AND ejercicio=$2;
+```
+Regla de auditoría: antes de aceptar un UPDATE, listar TODAS las dimensiones de dominio que definen "una fila lógica" (tenant_id, ejercicio, tipo, estatus, ...) y verificar que el WHERE incluye cada dimensión que aplica al scope del cambio. Las dimensiones implícitas (`es_vigente=true`, `activo=true`) también cuentan — un UPDATE que apaga `es_vigente` debe filtrar por la dimensión que define la unicidad de "vigente".
+
+**Drift triple Pydantic `Literal` ↔ validator de schema ↔ ENUM PostgreSQL**: SIGM NEM-VA-11 (2026-05-20). Tres universos incompatibles del mismo concepto: `Literal["A", "B", ..., "F"]` (6 valores) en el schema Pydantic, validator personalizado aceptando 8 valores, ENUM en PostgreSQL declarado con 12 valores. Cast `$N::schema.tipo_enum` falla en BD cuando llega un valor permitido por el Literal pero ausente del ENUM. Fix: **PostgreSQL ENUM como única fuente de verdad** cuando existe. Validar al arrancar la app:
+```python
+from sqlalchemy import text
+
+async def validar_enum_alineado(session, schema: str, enum_name: str, pydantic_values: set[str]):
+    rows = await session.execute(
+        text(f"SELECT enum_range(NULL::{schema}.{enum_name})")
+    )
+    pg_values = set(rows.scalar().strip("{}").split(","))
+    if pydantic_values != pg_values:
+        raise RuntimeError(
+            f"Drift ENUM {enum_name}: pydantic={pydantic_values} pg={pg_values}"
+        )
+```
+O generar el `Literal` Pydantic desde el ENUM PostgreSQL al startup (más estricto pero requiere conexión a BD para arrancar). Tests obligatorios: para cada ENUM, un test que compare `enum_range` contra el `Literal` del schema. La regla simple: si existe ENUM en BD, NO declarar Literal en código — derivarlo. Si NO existe ENUM en BD, NO declarar Literal en código — usar string libre con validator que consulta tabla de catálogo.
+
+**Partial unique index requiere predicado puro sobre columnas de la propia tabla**: SIGAF DT-TRANSICION-UC 2026-05-15. Intento inicial: `CREATE UNIQUE INDEX ... WHERE estatus_destino_id != (SELECT id FROM cat_estatus_acto WHERE clave='CANCELADO')`. PostgreSQL rechaza el predicado en partial index porque no permite subqueries. Workaround común: resolver el UUID en `upgrade()` con `SELECT` y embeber el literal — frágil porque en BD limpia (CI) la tabla está vacía → query retorna None → el índice se crea SIN filtro WHERE → seeds posteriores fallan al insertar lo que el índice ahora rechaza. Fix correcto:
+```sql
+-- 1. Agregar columna discriminadora en la tabla (boolean o enum)
+ALTER TABLE transicion_estatus_acto
+    ADD COLUMN es_automatica BOOLEAN NOT NULL DEFAULT FALSE;
+
+-- 2. Backfill condicional desde el join con la tabla externa
+UPDATE transicion_estatus_acto t
+SET es_automatica = TRUE
+FROM cat_estatus_acto c
+WHERE t.estatus_destino_id = c.id AND c.clave = 'CANCELADO';
+
+-- 3. Partial index con predicado puro sobre columnas propias
+CREATE UNIQUE INDEX uq_transicion_origen_automatica
+ON transicion_estatus_acto (estatus_origen_id)
+WHERE es_automatica = TRUE;
+```
+Regla:
+- El `WHERE` de un partial index DEBE ser sobre columnas de la propia tabla. NUNCA subquery a otra tabla.
+- Si la lógica requiere distinguir filas por relación con otro catálogo, agregar columna discriminadora con backfill desde el JOIN.
+- Toda migración que dependa de datos de catálogo DEBE ser idempotente para BD vacía. NO confiar en que el seed corra antes — en CI fresh corre después.

package/habilidades/proceso-autoverificacion-evidencias/SKILL.md

@@ -0,0 +1,258 @@
+---
+name: proceso-autoverificacion-evidencias
+description: >
+  Protocolo de auto-verificación post-implementación basado en las Four
+  Questions (tests passing / requirements met / assumptions verified /
+  evidence exists) + 7 red flags de alucinación. Cargar al cerrar una
+  feature, bugfix o refactor — antes de reportar "completado" al usuario,
+  antes del commit final, antes de mergear. Adaptación del SelfCheckProtocol
+  de SuperClaude_Framework, accuracy reportada 94% en detección de claims
+  no verificadas.
+version: "1.0.0"
+herramientasPermitidas: [Read, Grep, Glob, Bash]
+exclusiones:
+  - "No cargar para cambios triviales (typo, formato, comentario) — los checks no aportan valor."
+  - "No cargar en mitad de la implementación; este skill aplica al CIERRE. Para verificación pre-implementación usar `proceso-confianza-pre-implementacion`."
+  - "No cargar si ya se ejecutó `/swl:verificar` o el revisor de código emitió veredicto APROBADO — esos cubren el rol al nivel de fase/sesión."
+  - "No cargar para trabajo de research/discovery donde no hay implementación que cerrar."
+evolvable: true
+---
+
+# Habilidad: Auto-verificación con evidencias
+
+## Propósito
+
+Cerrar el trabajo con evidencias verificables, no con claims. El material
+fuente (SuperClaude_Framework `pm_agent/self_check.py`) reporta 94% de
+accuracy detectando los patrones de alucinación más comunes ("tests pass"
+sin mostrar output, "implementación completa" con tests rotos, lenguaje
+de incertidumbre). En SWL este patrón complementa la regla
+`verificar-citas-normativas.md` (que cubre citas durante el trabajo) con
+el protocolo de cierre obligatorio.
+
+## Cuándo cargar
+
+- Antes de reportar "completado" al usuario tras una implementación.
+- Antes del commit final de una feature/bugfix/refactor.
+- Antes de mergear un PR.
+- Cuando un sub-agente reporta éxito y el agente padre debe validar.
+- Cuando el usuario pregunta "¿está terminado?" y el agente está a punto
+  de responder "sí" — pasar por las Four Questions primero.
+
+## Cuándo NO cargar
+
+Listado en el campo `exclusiones` del frontmatter — incluye cambios
+triviales, mitad de implementación, casos donde `/swl:verificar` o el
+revisor ya emitió veredicto.
+
+---
+
+## Las Four Questions
+
+El protocolo es **mandatorio** — todas las cuatro preguntas se responden
+explícitamente. Si una se omite, el trabajo NO está cerrado.
+
+### Pregunta 1 — ¿Pasan todos los tests?
+
+No basta con afirmar "los tests pasan". Hay que **mostrar el output real**
+del runner.
+
+- Ejecutar el suite con el runner del proyecto (`npm test`, `pytest`,
+  `cargo test`, etc.).
+- Mostrar las últimas 20-50 líneas del output que incluyen el resumen
+  ("X passed, 0 failed").
+- Si hay tests skipped, indicar el conteo y la razón documentada.
+- Si los tests aún no se han escrito (TDD inverso, fix urgente), declararlo
+  explícitamente con plan de cierre.
+
+**Anti-patrón crítico**: "tests pasan" sin pegar el output. Es la red
+flag #1 de alucinación detectada por el patrón Reflexion.
+
+### Pregunta 2 — ¿Se cumplen todos los requisitos?
+
+Comparar requirements vs implementación, item por item:
+
+- Listar los requisitos originales del usuario o del plan.
+- Marcar cada uno: ✅ Hecho / ⚠️ Parcial / ❌ Pendiente.
+- Si hay parciales o pendientes: declarar por qué y cuándo se cierran.
+- No declarar "completo" si quedan ❌ no negociados.
+
+La regla `arreglar-al-detectar.md` prohíbe deuda silenciosa: si algo se
+deja para "después", se documenta como DA formal con trigger verificable,
+no como "lo dejo pendiente".
+
+### Pregunta 3 — ¿Hay suposiciones sin verificar?
+
+Toda suposición técnica usada durante la implementación debe estar
+verificada contra fuente autoritativa:
+
+- Suposiciones sobre APIs internas: verificadas leyendo el módulo, no por
+  nombre.
+- Suposiciones sobre librerías externas: verificadas en Context7 o doc
+  oficial (regla `usar-context7.md`).
+- Suposiciones sobre estructura del codebase: verificadas con `Grep`/`Glob`.
+- Suposiciones sobre comportamiento esperado del sistema: verificadas con
+  test o evidencia de ejecución.
+
+**Anti-patrón**: dejar "probablemente funciona", "debería andar", "creo
+que sí". Lenguaje de incertidumbre = red flag #7.
+
+### Pregunta 4 — ¿Hay evidencia?
+
+Evidencia concreta en tres ejes:
+
+- **Test results**: output del runner pegado (no resumen propio).
+- **Code changes**: lista de archivos modificados (`git diff --stat`).
+- **Validation**: lint, typecheck, build exitosos — output pegado.
+
+Si falta cualquiera de los tres, el trabajo NO está cerrado.
+
+---
+
+## Las 7 Red Flags de alucinación
+
+Patrones que indican que el agente está "cerrando sin verificar". Si el
+agente detecta cualquiera de estos en su propio output, debe corregir
+ANTES de reportar:
+
+1. **"Tests pass" sin output** — afirmación sin evidencia.
+2. **"Everything works" sin evidencia** — claim de completitud sin pruebas.
+3. **"Implementation complete" con tests rotos** — contradicción directa.
+4. **Saltar mensajes de error** — el runner reportó errores y el agente
+   los ignora en el reporte.
+5. **Ignorar warnings** — warnings tratados como ruido en lugar de señales
+   accionables.
+6. **Esconder fallos** — reportar éxitos parciales como totales.
+7. **Lenguaje de incertidumbre** — "probably", "should work", "might
+   work" en un reporte de cierre.
+
+Cada red flag detectada bloquea el cierre hasta que se resuelva.
+
+---
+
+## Formato de reporte obligatorio
+
+Al cerrar el trabajo, emitir al usuario (o registrar en
+`.planning/sessions/`) el siguiente formato:
+
+```
+### Auto-verificación de cierre
+
+**Pregunta 1 — Tests passing?**
+<output del runner pegado, últimas 20-50 líneas con resumen>
+Estado: ✅ N passed / ⚠️ M skipped con razón / ❌ K failed
+
+**Pregunta 2 — Requirements met?**
+- ✅ Requisito A: <evidencia / referencia a commit / archivo:línea>
+- ✅ Requisito B: <evidencia>
+- ⚠️ Requisito C: parcial — <qué falta y cuándo cierra>
+- ❌ Requisito D: pendiente — DA formal en `.planning/...` con trigger X
+
+**Pregunta 3 — Assumptions verified?**
+- ✅ Suposición X verificada en <fuente>
+- ✅ Suposición Y verificada con <comando/test>
+
+**Pregunta 4 — Evidence?**
+- Test results: <pegado arriba>
+- Code changes: `git diff --stat` →  <output>
+- Validation: lint/typecheck/build → <output o "no aplica al proyecto">
+
+**Red flags detectadas**: <lista o "ninguna">
+
+**Veredicto**: ✅ Cerrado con evidencias / ❌ Bloqueado por <razón>
+```
+
+Si el veredicto es ❌, el agente NO reporta "completado" al usuario.
+Reporta el bloqueo y propone el siguiente paso.
+
+---
+
+## Reglas obligatorias
+
+1. **Evidencia, no claims**: cualquier afirmación de éxito requiere output
+   pegado, no resumen propio. **Por qué**: el resumen propio puede ser
+   alucinado; el output real del runner no.
+
+2. **Las 4 preguntas son AND, no OR**: las cuatro deben pasar para cerrar.
+   No se puede compensar el fallo de una con el éxito de las otras.
+   **Por qué**: la regla `arreglar-al-detectar.md` exige resolver todo,
+   no esquivar; cerrar con 3 de 4 es deuda silenciosa.
+
+3. **Sin lenguaje de incertidumbre en el reporte**: las palabras
+   "probablemente", "creo que", "debería", "tal vez" están prohibidas en
+   el output de cierre. Si hay incertidumbre, verificarla; si no se puede
+   verificar, declararla explícitamente como gap con plan de cierre.
+
+4. **Re-leer el propio reporte**: antes de enviarlo, escanear las 7 red
+   flags. La detección es self-applied — si el agente no se audita, el
+   skill no funciona.
+
+5. **Si el cierre falla, NO ocultar**: reportar el fallo al usuario en
+   el mismo turno (regla `arreglar-al-detectar.md`). "Detecté que el
+   Check N falla porque X — voy a corregir Y" es la respuesta correcta.
+
+---
+
+## Relación con otras herramientas SWL
+
+- **Regla `verificar-citas-normativas.md`**: aplica DURANTE el trabajo a
+  cada cita verificable (archivo:línea, artículo de ley, etc.). Este
+  skill aplica al CIERRE del trabajo completo.
+- **Skill `proceso-confianza-pre-implementacion`**: aplica al INICIO con
+  las 5 dimensiones de confianza. Este aplica al CIERRE con las 4
+  preguntas. Forman par.
+- **Skill `verificar-trabajo`**: el agente Verificador SWL lo usa para
+  validación de fase con goal-backward 4 niveles. Si se ejecutó
+  `/swl:verificar` y aprobó, este skill no es necesario (cobertura
+  redundante).
+- **`revisor-codigo-swl`**: emite veredicto APROBADO/RECHAZADO sobre
+  código terminado. Si aprobó, este skill no es necesario.
+- **Skill `monitor-ci`** (regla global): aplica a CI post-push. Este
+  skill aplica antes del push.
+
+---
+
+## Ejemplo de uso
+
+Tras implementar el endpoint POST /facturas/cancelar:
+
+```
+### Auto-verificación de cierre
+
+**Pregunta 1 — Tests passing?**
+
+  PASS  tests/api/facturas-cancelar.test.ts
+  PASS  tests/services/factura-service.test.ts
+  Tests: 23 passed, 0 failed, 1 skipped
+  Time: 4.2 s
+
+Estado: ✅ 23 passed, 1 skipped (test de integración E2E pendiente de
+fixture de pago — no bloqueante, documentado en TODO.md).
+
+**Pregunta 2 — Requirements met?**
+- ✅ Endpoint POST /facturas/{id}/cancelar: implementado en
+  `backend/app/api/facturas.py:142`.
+- ✅ Validación de estatus permitido (solo "pendiente" o "emitida"):
+  implementada en `factura_service.py:88-101`.
+- ✅ Auditoría: registro en tabla `factura_historial`: confirmado en
+  test `factura-cancelar-audit.test.py:55`.
+
+**Pregunta 3 — Assumptions verified?**
+- ✅ Modelo Factura tiene método `puede_cancelarse()`: confirmado leyendo
+  `models/factura.py:120-135`.
+- ✅ FastAPI `Depends(get_db)` es la inyección estándar del proyecto:
+  confirmado en ADR-0008 y 12 endpoints existentes.
+
+**Pregunta 4 — Evidence?**
+- Test results: pegado arriba.
+- Code changes:
+  3 files changed, 84 insertions(+), 2 deletions(-)
+  backend/app/api/facturas.py | 32 ++++++++++++++++++--
+  backend/app/services/factura_service.py | 18 +++++++++++
+  backend/tests/api/facturas-cancelar.test.ts | 36 +++++++++++++++++++
+- Validation: `ruff check .` → 0 errors, `mypy backend/` → 0 errors.
+
+**Red flags detectadas**: ninguna.
+
+**Veredicto**: ✅ Cerrado con evidencias.
+```