@saulwade/swl-ses 1.1.2 → 1.1.4

package/CLAUDE.md

@@ -1,4 +1,4 @@
-# CLAUDE.md — @saulwade/swl-ses v1.1.2
+# CLAUDE.md — @saulwade/swl-ses v1.1.4
 
 ## Reglas de máxima prioridad (aplican SIEMPRE, sin excepción)
 
@@ -23,7 +23,7 @@ El Read tool sigue siendo correcto para `.pdf` (≤20 páginas), `.md`, `.txt` y
 ## Qué es este repositorio
 
 Sistema de ingeniería de software auto-evolutivo multi-runtime polyglot (SDLC completo).
-11 lenguajes, 5 runtimes, 59 agentes, 151 skills, 42 comandos, 62 reglas, 39 hooks.
+11 lenguajes, 5 runtimes, 59 agentes, 151 skills, 42 comandos, 64 reglas, 39 hooks.
 **Idioma**: 100% español (México) para componentes SWL y skills Anthropic en inglés.
 
 ## Estructura del repositorio
@@ -87,7 +87,7 @@ scripts/       bin/            _userland/      .claude/        .planning/
 | `/swl:contribuir` | Contribuir evoluciones de _userland/ al core vía PR (filtro dominio + PluginEval ≥80) |
 | `/swl:ayuda` | Ayuda interactiva: catálogo, detalle de comando, búsqueda por keyword |
 
-## Reglas obligatorias (22 base + 40 por lenguaje)
+## Reglas obligatorias (24 base + 40 por lenguaje)
 
 | Regla | Carga cuando |
 |-------|-------------|
@@ -111,6 +111,8 @@ scripts/       bin/            _userland/      .claude/        .planning/
 | `patrones.md` | Patrones de diseño y arquitectura |
 | `testing.md` | test*/, *.test.*, *.spec.* |
 | `usar-context7.md` | OBLIGATORIA al generar código que importe librerías/frameworks externos. Aplica a `backend-*-swl`, `frontend-*-swl`, `mobile-*-swl`, `implementador-swl`, `llm-apps-swl`, `pagos-swl`, `datos-swl`. Verifica versión actual y deprecaciones via Context7 MCP antes de agregar deps o generar imports. |
+| `arreglar-al-detectar.md` | Siempre — al detectar cualquier error, bug, inconsistencia o anomalía durante cualquier trabajo: informar y resolver en el mismo turno, sin deuda silenciosa ni bypass |
+| `analisis-previo-tareas-grandes.md` | Cuando la solicitud implica >10 archivos, >500 LOC, cross-módulo, porte de sistema o repo en `temp/`: auditar primero, presentar tabla comparativa + 3 opciones de alcance, esperar confirmación |
 
 Reglas por lenguaje (5 por lenguaje × 8 lenguajes): Java, Go, Rust, C#, Kotlin, Swift, PHP, Next.js — en `reglas/` con subdirectorios.
 

package/README.md

@@ -1,4 +1,4 @@
-# swl-ses v1.1.2
+# swl-ses v1.1.4
 
 > El paquete anterior `@saulwadeleon/swl-software-engineering-system` está deprecado. Migrar a `@saulwade/swl-ses` (npmjs.org canónico) o `@saul-wade/swl-ses` (mirror en GitHub Packages) — el CLI `swl-ses` no cambia.
 
@@ -177,7 +177,7 @@ claude
 | `mobile` | Android + iOS + React Native/Flutter + UX |
 | `devops` | CI/CD + cloud + observabilidad + releases + seguridad |
 | `polyglot` | Todos los lenguajes: 11 lenguajes + revisores + build resolvers |
-| `completo` | Todo: 59 agentes + 151 habilidades + 42 comandos + 62 reglas + 39 hooks |
+| `completo` | Todo: 59 agentes + 151 habilidades + 42 comandos + 64 reglas + 39 hooks |
 
 ### Targets soportados
 

package/comandos/swl/exportar-vault.md

@@ -44,6 +44,86 @@ Normaliza el slug del proyecto a kebab-case sin acentos. Ejemplos válidos:
 - `swl-software-engineering-system`
 - `ecosistema-multi-agente-ia`
 
+## Paso 1.5 — Resolución del nombre canónico desde el vault (CRÍTICO)
+
+Antes de redactar el frontmatter, **debes resolver el nombre canónico exacto** del proyecto leyendo `02-Projects/` del vault. Sin esto, el campo `related_vault_project` queda con un nombre fabricado que no enlaza con ningún nodo del grafo de Obsidian.
+
+Listar proyectos del vault:
+
+```bash
+ls "F:/Google Drive/Developer/Obsidian/Vault/SWL/02-Projects/" 2>/dev/null
+```
+
+Resultado típico:
+
+```
+DEV - Ecosistema Multi-Agente IA OIC-INE.md
+DEV - SIGAF.md
+DEV - SIGM.md
+META - SWL Software Engineering System.md
+```
+
+Algoritmo de match (en cascada — cada pasada solo se ejecuta si la anterior no resolvió match único):
+
+**Normaliza ambos lados** a comparación robusta antes de cualquier pasada:
+- Strip extensión `.md`.
+- Strip prefijo `DEV - ` o `META - ` (cualquier prefijo seguido de ` - `).
+- Lowercase.
+- Sin acentos.
+- Reemplaza espacios y guiones por nada (compactar).
+
+Aplica el mismo procesamiento al slug del proyecto local.
+
+**Pasada 1 — Match exacto**:
+- Si la cadena normalizada del slug local coincide carácter a carácter con la de algún canónico, ese es el match. Caso típico: `sigaf` ↔ `DEV - SIGAF`.
+
+**Pasada 2 — Match por prefijo bidireccional**:
+- Si la cadena del slug local es **prefijo** de la cadena de algún canónico, ese canónico matchea. Ej: `ecosistemamultiagenteia` es prefijo de `ecosistemamultiagenteiaoicine` → match con `DEV - Ecosistema Multi-Agente IA OIC-INE`.
+- Inversamente: si la cadena de algún canónico es prefijo de la del slug local, también matchea (cubre el caso opuesto: vault con nombre más corto que el slug del proyecto).
+- Solo se acepta el match si la pasada produce **exactamente 1** candidato. Si hay 2+ ambiguos, NO usar — pasar a siguiente pasada con el alias o fallback final, listando los candidatos en el WARNING del Paso 5.
+
+**Pasada 3 — Aliases conocidos**:
+- Si ninguna pasada anterior resolvió, intenta con sinónimos del slug local antes del fallback (ver lista de aliases más abajo). Para cada alias, repite Pasada 1 y Pasada 2.
+
+**Pasada 4 — Fallback**:
+- Si todo lo anterior es vacío:
+  - Usar como `related_vault_project` el valor `[[DEV - {Nombre-Title-Case}]]` (fallback antiguo).
+  - **Reportar warning explícito al usuario** en el paso 5 indicando que no se encontró nodo canónico y sugerir crear `02-Projects/DEV - {Nombre}.md` en el vault.
+
+Resultado del algoritmo: el nombre canónico es el basename del archivo sin `.md` (con su prefijo `DEV - ` o `META - ` original intacto).
+
+Ejemplos de match esperado (con la pasada que lo resuelve):
+
+| Slug local | Normalizado local | Canónico que matchea | Pasada | Nombre canónico resuelto |
+|------------|-------------------|----------------------|--------|--------------------------|
+| `sigaf` | `sigaf` | `sigaf` | 1 (exacto) | `DEV - SIGAF` |
+| `sigm` | `sigm` | `sigm` | 1 (exacto) | `DEV - SIGM` |
+| `swl-software-engineering-system` | `swlsoftwareengineeringsystem` | `swlsoftwareengineeringsystem` | 1 (exacto) | `META - SWL Software Engineering System` |
+| `ecosistema-multi-agente-ia` | `ecosistemamultiagenteia` | `ecosistemamultiagenteiaoicine` | 2 (prefijo del slug en canónico) | `DEV - Ecosistema Multi-Agente IA OIC-INE` |
+| `swl-ses` | `swlses` | ninguno (ver nota) | 3 (alias → reemplaza slug por `swlsoftwareengineeringsystem` y repite 1) | `META - SWL Software Engineering System` |
+
+**Nota sobre el caso `swl-ses`** — un lector cuidadoso puede preguntarse por qué Pasada 2 (prefijo) no captura este caso, dado que `swlses` y `swlsoftwareengineeringsystem` comparten el inicio `swls`. La verificación carácter a carácter:
+
+```
+pos:    0 1 2 3 4 5
+swlses: s w l s e s
+swlsof: s w l s o f t w a r e ...
+                ^
+                divergen aquí (e vs o)
+```
+
+`swlses` **no es prefijo** de `swlsoftwareengineeringsystem` — comparten 4 caracteres pero divergen en la posición 4. Por eso Pasada 2 falla y se necesita la sustitución de alias en Pasada 3. Esta nota existe para prevenir el malentendido común de que "comparten algunas letras iniciales" implica "uno es prefijo del otro".
+
+**Aliases conocidos** — si el slug local no matchea directo, intenta estos sinónimos antes del fallback:
+
+- `swl-ses` → buscar `swl-software-engineering-system` o `swlsoftwareengineeringsystem`.
+- Cualquier slug que empiece con `swl-` y termine en `-ses` o `-software-engineering-system` → trata como `swl-software-engineering-system`.
+
+Guarda el resultado en dos variables internas para usar más abajo:
+
+- `nombre_canonico_completo` — ej. `META - SWL Software Engineering System`. Va dentro de `[[ ]]` en el frontmatter.
+- `proyecto_slug` — el slug original sin alterar. Va en el filename y en tags.
+
 ## Paso 2 — Recolección del contenido de la sesión
 
 Junta estas fuentes (las que existan):
@@ -67,7 +147,7 @@ created: {fecha-hoy YYYY-MM-DD}
 source: swl-ses
 project: "{nombre-proyecto}"
 project_path: "{ruta-absoluta}"
-related_vault_project: "[[DEV - {nombre-en-vault}]]"
+related_vault_project: "[[{nombre_canonico_completo}]]"
 reviewed: false
 ---
 
@@ -150,8 +230,30 @@ Reporta al usuario:
 
 - Ruta exacta del archivo creado.
 - Conteo de palabras.
+- **Nombre canónico resuelto**: indicar qué nodo de `02-Projects/` enlazó el export. Si no hubo match, marcar el warning explícito.
 - Recordatorio: "Al abrir el vault en tu próxima sesión, ejecuta `/sync-projects {proyecto-slug}` para integrar formalmente estos cambios."
 
+Formato esperado cuando hay match:
+
+```
+[OK] Export creado: F:\...\2026-05-04_1748_export-swl-ses.md (487 palabras)
+[OK] Enlace canónico: [[META - SWL Software Engineering System]]
+
+Próximo paso: al abrir el vault, ejecuta:
+  /sync-projects swl-ses
+```
+
+Formato esperado cuando NO hay match:
+
+```
+[OK] Export creado: F:\...\2026-05-04_1748_export-mi-proyecto.md (487 palabras)
+[WARNING] No se encontró nodo canónico en 02-Projects/. Usado fallback: [[DEV - Mi Proyecto]]
+  Sugerencia: crear F:\...\02-Projects\DEV - Mi Proyecto.md en el vault para que el grafo conecte el export con el proyecto.
+
+Próximo paso: al abrir el vault, ejecuta:
+  /sync-projects mi-proyecto
+```
+
 ## Restricciones
 
 - **No sobrescribir** archivos existentes con el mismo nombre. Si por azar existe uno con el mismo timestamp (raro), agrega sufijo `_b`.

package/manifiestos/modulos.json

@@ -836,7 +836,9 @@
         "reglas/brevedad-output.md",
         "reglas/seguridad-agentes.md",
         "reglas/memoria-consolidada.md",
-        "reglas/usar-context7.md"
+        "reglas/usar-context7.md",
+        "reglas/arreglar-al-detectar.md",
+        "reglas/analisis-previo-tareas-grandes.md"
       ],
       "targets": [
         "claude",

package/manifiestos/skills-lock.json

@@ -1,6 +1,6 @@
 {
   "lockfileVersion": 1,
-  "generatedAt": "2026-05-04T23:40:51.194Z",
+  "generatedAt": "2026-05-05T16:50:32.441Z",
   "skillsCount": 151,
   "lockHash": "sha256:9eb487b296412d9bd32ec2f62684741c3c0e542a1f1631ffad85d9b8eebdd7c8",
   "skills": [

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "@saulwade/swl-ses",
-  "version": "1.1.2",
-  "description": "Sistema de ingenieria de software auto-evolutivo multi-runtime polyglot con 59 agentes, 151 habilidades, 42 comandos, 60 reglas y 37 hooks. Soporta 11 lenguajes y 5 runtimes: Claude Code, Copilot, OpenCode, Codex y Gemini CLI. 100% en espanol (Mexico). Incluye gateway bidireccional con relay Telegram a Claude Code.",
+  "version": "1.1.4",
+  "description": "Sistema de ingenieria de software auto-evolutivo multi-runtime polyglot con 59 agentes, 151 habilidades, 42 comandos, 64 reglas y 39 hooks. Soporta 11 lenguajes y 5 runtimes: Claude Code, Copilot, OpenCode, Codex y Gemini CLI. 100% en espanol (Mexico). Incluye gateway bidireccional con relay Telegram a Claude Code.",
   "bin": {
     "swl-ses": "bin/swl-ses.js",
     "swl-telegram-bot": "bin/swl-telegram-bot.js"

package/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "swl-ses",
-  "version": "1.1.2",
-  "description": "Sistema de ingenieria de software auto-evolutivo multi-runtime polyglot. 59 agentes, 151 habilidades, 42 comandos, 60 reglas y 37 hooks. 60 librerias. 11 lenguajes. Soporta Claude Code, Copilot, OpenCode, Codex y Gemini CLI.",
+  "version": "1.1.4",
+  "description": "Sistema de ingenieria de software auto-evolutivo multi-runtime polyglot. 59 agentes, 151 habilidades, 42 comandos, 64 reglas y 39 hooks. 62 librerias. 11 lenguajes. Soporta Claude Code, Copilot, OpenCode, Codex y Gemini CLI.",
   "author": "Saul Wade Leon",
   "license": "MIT",
   "repository": "https://github.com/saul-wade/swl-ses",

package/reglas/analisis-previo-tareas-grandes.md

@@ -0,0 +1,172 @@
+# Regla: Análisis previo ante tareas grandes
+
+Esta regla es OBLIGATORIA y aplica a todo trabajo donde la solicitud del usuario
+implique cambio masivo: porte de sistema, refactor cross-módulo, replicación de
+arquitectura externa, migración de stack, instalación de framework completo,
+adopción de patrón en N módulos.
+
+---
+
+## Principio
+
+> Cuando el usuario pide "replicar íntegramente X", "portar todo Y", "implementar
+> el sistema completo Z", **responde primero con análisis comparativo (qué ya
+> existe vs. qué falta) y propón 3 opciones de alcance** (mínima / media /
+> completa) antes de escribir código. Nunca arrancar el porte literal sin
+> confirmación explícita tras presentar opciones.
+
+---
+
+## Cómo aplicar
+
+### Detección — qué cuenta como "tarea grande"
+
+Cualquier solicitud que tenga al menos uno de estos atributos:
+
+- Más de ~10 archivos a crear, mover o reescribir.
+- Más de ~500 LOC estimadas a tocar en un solo turno.
+- Toca más de un dominio (backend + frontend, o varios módulos backend).
+- "Replicar X" donde X es un sistema externo con su propia arquitectura.
+- "Portar todo de Y" donde Y es un repo, framework o lib voluminoso.
+- "Implementar todo Z" donde Z es una fase, un sub-sistema, una capa nueva.
+- Análisis de un repo en `temp/` con la pregunta abierta "¿qué adoptamos?".
+
+Si la solicitud encaja en cualquiera de estas, aplicar la regla.
+
+### Paso 1 — Auditar lo que ya existe
+
+Antes de proponer el porte:
+
+- `Glob` / `Grep` / `Read` para mapear el código actual del usuario.
+- Identificar componentes que ya cubren parte de la solicitud.
+- Verificar versiones, dependencias, convenciones del proyecto.
+- Si es repo externo en `temp/`: aplicar **filtro de dominio** primero
+  (ver `reglas/arquitectura.md` § "Análisis de repositorios externos").
+  Descartar 80-95% del contenido vertical antes de análisis profundo.
+
+### Paso 2 — Tabla comparativa
+
+Producir una tabla con tres columnas:
+
+| Componente del sistema externo | Equivalente actual del usuario | Gap |
+|---|---|---|
+| ... | ya existe / parcial / no existe | qué falta agregar |
+
+Sin la tabla, no se proponen opciones. La tabla es la base objetiva de la decisión.
+
+### Paso 3 — Tres opciones de alcance
+
+Siempre presentar tres opciones:
+
+- **Mínima** — solo cierra los gaps críticos (lo que NO existe). Esfuerzo
+  estimado bajo. Usuario acepta vivir con diferencias menores en lo demás.
+- **Media** — cierra gaps + alinea componentes parciales con el patrón externo.
+  Esfuerzo medio. Convergencia parcial sin reescribir lo que ya funciona.
+- **Completa** — porte literal de todo lo que el usuario pidió, sin reusar
+  componentes existentes. Esfuerzo alto. Justificable solo cuando la
+  arquitectura externa es estrictamente superior.
+
+Cada opción incluye:
+
+- Estimación de esfuerzo (turnos, LOC, archivos afectados).
+- Lista de tareas concretas si se elige.
+- Riesgos / tradeoffs específicos.
+
+### Paso 4 — Recomendación explícita
+
+Tras las tres opciones, **recomendar una** con razonamiento. No dejar la
+decisión "abierta" — el usuario espera tu juicio técnico.
+
+Patrón de recomendación:
+
+> **Recomiendo la opción [N]** porque [razón concreta]. Las opciones [otras]
+> son válidas si [condición específica].
+
+### Paso 5 — Esperar confirmación
+
+Después de presentar tabla + opciones + recomendación: detenerse y esperar.
+
+NO arrancar a escribir código asumiendo aprobación implícita. La autorización
+debe ser literal del usuario ("procede con la opción 2", "adelante con la
+mínima", "hagamos la completa").
+
+---
+
+## Excepciones — cuándo NO aplicar la regla
+
+NO aplicar cuando:
+
+1. **El usuario ya pidió explícitamente la opción**: "implementa la versión
+   mínima de X" o "porta solo el módulo Y" — la elección ya está hecha.
+2. **El alcance es trivial** — menos de 5 archivos, una sola dependencia.
+3. **El usuario pidió análisis y ya decidió**: si ya hubo una sesión previa con
+   la tabla comparativa y el usuario eligió, proceder sin re-presentar.
+4. **Es un fix urgente de producción** — bug crítico, vulnerabilidad activa,
+   incidente. El análisis se reduce a confirmar la causa y aplicar el fix
+   específico.
+
+---
+
+## Cómo presentar la tabla y opciones
+
+### Formato de tabla comparativa (mínimo)
+
+```markdown
+| Componente | Sistema externo | Tu sistema actual | Gap |
+|---|---|---|---|
+| Auth | OAuth2 + PKCE | JWT custom | parcial — falta PKCE |
+| Storage | S3 + presigned | filesystem local | falta — pendiente migración |
+| ... | ... | ... | ... |
+```
+
+### Formato de las tres opciones (mínimo)
+
+```markdown
+**Opción A — Mínima** (~3 turnos, ~15 archivos)
+- Cerrar solo gaps críticos: PKCE, presigned URLs.
+- No tocar lo que ya funciona.
+- Riesgo: leve divergencia con sistema externo en convenciones menores.
+
+**Opción B — Media** (~6 turnos, ~30 archivos)
+- Cerrar gaps + alinear `auth/` con patrón OAuth2 completo.
+- Mantener storage actual con migración planeada en fase futura.
+- Riesgo: refactor en `auth/` puede romper integraciones existentes.
+
+**Opción C — Completa** (~15 turnos, ~80 archivos)
+- Porte literal del sistema externo completo.
+- Reemplaza todo lo equivalente, no importa que ya funcione.
+- Riesgo: regresiones en funcionalidad madura.
+
+**Recomiendo la Opción A**: el sistema actual cubre el 80% del valor;
+los gaps específicos resuelven el caso concreto sin riesgo de regresión.
+```
+
+---
+
+## Anti-patrones
+
+- Arrancar a escribir código tras "replícame X" sin tabla comparativa.
+- Presentar las opciones sin recomendar — pasar la pelota al usuario.
+- Listar 5+ opciones cuando 3 son suficientes (mínima / media / completa).
+- Estimar esfuerzo en términos vagos ("bastante trabajo", "no mucho") sin
+  cuantificar turnos / archivos / LOC.
+- Omitir la auditoría de lo que ya existe y proponer porte literal de todo.
+- Cuando el usuario pide la opción mínima, expandir el alcance "porque
+  conviene" sin pedir confirmación.
+
+---
+
+## Origen de esta regla
+
+Consolidada el 2026-05-04 desde feedback del usuario en sesión 2026-04-18 sobre
+porte de Hermes Agent: tras pedir "replicar íntegramente Hermes Agent" (~960
+archivos Python), aceptó la propuesta de cerrar solo 3 gaps específicos
+(perfil de usuario, cron natural, auto-evolución). Lección: la auditoría previa
++ opciones explícitas evita re-implementar 80% de funcionalidad ya existente.
+
+Reforzada en análisis de repos en `temp/` durante v1.1.0 de swl-ses (2026-04-23):
+filtro de dominio descartó 97% del contenido de 5 repos antes de análisis
+profundo, ahorrando horas de trabajo en arquitectura externa irrelevante.
+
+Memoria nativa local correspondiente (`feedback_analisis_previo.md` en swl-ses):
+redundante tras esta regla; el contenido operativo vive aquí.

package/reglas/arreglar-al-detectar.md

@@ -0,0 +1,147 @@
+# Regla: Detectar → Informar → Arreglar en el mismo turno
+
+Esta regla es OBLIGATORIA y aplica a todo trabajo que Claude ejecute en cualquier
+proyecto del usuario. Consolida cuatro feedbacks repetidos en sesiones distintas
+entre 2026-04-23 y 2026-05-03 con la misma señal: el usuario rechaza entregas
+parciales, deuda silenciosa y bypass de errores ajenos.
+
+---
+
+## Principio
+
+> Cuando detectes un error, bug, inconsistencia, anomalía o problema secundario
+> durante la ejecución de cualquier trabajo, **informa al usuario brevemente Y
+> procede a resolverlo en el mismo turno**. Nunca lo dejes como pendiente, deuda
+> implícita, "ya estaba antes" ni "fuera del scope".
+
+Esta regla resume cuatro feedbacks separados que el usuario reforzó como mismo
+principio:
+
+- "No me gustan las cosas a medias" — rechazo de entregas parciales (2026-04-23).
+- "Cuando detectes errores, bugs, inconsistencias y demás informes al usuario y
+  procedas a solucionar y/o arreglar, además nunca debes dejar pendientes, ni
+  diferir" (2026-04-30).
+- "Resuelve los test que fallan, no bypass" — al detectar intento de excluir
+  tests del glob para evitar arreglarlos (2026-04-30).
+- "Si el job CI falla, hay que arreglarlo todo" — al ver tests rotos
+  presentados como "preexistentes, no críticos" (2026-05-03).
+
+---
+
+## Cómo aplicar
+
+### Al detectar un problema secundario durante el trabajo principal
+
+- Reportarlo brevemente al usuario: qué se detectó, dónde, severidad.
+- Resolverlo en el mismo turno o en commit separado de la misma sesión.
+- NUNCA ofrecer "lo documento como deuda" como primera opción.
+- NUNCA usar frases como "son tests con mocks pre-existentes que ya estaban rotos",
+  "esto estaba antes", "no es del scope inmediato" para evitar el trabajo.
+
+### Al ejecutar tests, builds, lints, validadores
+
+- Si hay failures, listarlos todos y atacarlos todos.
+- No distinguir "bugs reales" vs "tests con mocks mal configurados" como excusa
+  para arreglar solo unos. Si están rotos, arreglarlos.
+- Excepción: bugs que requieran decisión arquitectural ambigua del usuario —
+  pedir esa decisión explícitamente, no diferir como "tu decisión".
+
+### Al modificar código adyacente
+
+- Si tocas líneas con problemas adyacentes (None checks faltantes, schemas
+  obsoletos, mocks inconsistentes, contadores stale, paths inválidos),
+  arreglarlos en el mismo commit o en commit separado de la misma sesión.
+
+### Al refactorizar
+
+- Si encuentras código adyacente que se quedó obsoleto por un refactor previo,
+  actualizarlo. No dejar deuda residual.
+
+### Al detectar un error ajeno al trabajo actual
+
+- NO bypassear (excluir tests del glob, comentar checks, `|| true`,
+  downgradear a warning, ignorar).
+- Resolver de raíz o, si requiere decisión, abrir explícitamente la decisión
+  con el usuario antes de bypassear.
+- El default es resolver, no esquivar.
+
+### Al presentar planes con sub-tareas
+
+- Dar primero la opción "todo completo" con esfuerzo estimado.
+- Si por capacity hay que partir el trabajo, hacerlo explícito con razón
+  concreta: "esta sesión cubre 3.1 a 3.4; la 3.5 va en commit separado por
+  X razón concreta", no por preferencia genérica.
+
+### Al recomendar diferir un patrón o feature
+
+- Redactar **simultáneamente** el ítem de deuda formal con criterio de disparo
+  verificable. La oferta "lo dejo apuntado" sin entrada formal no es aceptable.
+- Distinción de categorías:
+  - **DT (deuda técnica)** con plan de cierre.
+  - **DA (decisión arquitectural)** con trigger verificable.
+  - **OP (pendiente operacional)** con responsable.
+- "Mediano plazo / Q3 / cuando aparezca demanda" sin trigger verificable es
+  deuda silenciosa. Convertir a DA formal en mismo commit.
+- Trigger verificable significa condición observable: "≥2 clientes distintos
+  reportan", "p95 > 60s en producción documentado", "uso > N veces/mes",
+  no "cuando sea relevante" o "más adelante".
+
+---
+
+## Excepciones legítimas
+
+NO aplicar la regla al pie de la letra cuando:
+
+1. **El fix es ambiguo** — varias opciones razonables sin criterio claro para
+   elegir. Presentar opciones concretas con la recomendación y esperar
+   decisión rápida.
+2. **El fix es destructivo** — `rm -rf`, `git reset --hard`, `git push --force`,
+   eliminar tablas de BD. Esos siguen requiriendo confirmación explícita por
+   separado, sin importar que el problema esté detectado.
+3. **El fix tiene blast radius alto** — modifica configuración de CI, infra
+   compartida, contratos públicos de API. Presentar plan, pedir confirmación.
+4. **El bug requiere decisión de producto** — comportamiento esperado ambiguo,
+   breaking change. Explícito al usuario y esperar.
+
+En todos los casos: presentar la opción y la recomendación, NO dejar el
+problema sin reportar.
+
+---
+
+## Anti-patrones explícitos
+
+- "Lo dejo como deuda residual" — sin DT/DA formal con criterio de disparo.
+- "Esos tests ya estaban rotos antes" — usado para evitar arreglarlos.
+- "No es parte del scope inmediato" — para esquivar un fix obvio.
+- "Lo documento y tú decides" — para diferir trabajo claro al usuario.
+- "Mediano plazo" sin trigger verificable.
+- Excluir tests del glob, comentar checks, `|| true`, downgradear severidad de
+  un linter — para que el CI deje de fallar sin arreglar la causa.
+- Mover archivos a `legacy/` o `deprecated/` sin plan de eliminación con
+  criterio de disparo.
+
+---
+
+## Relación con otras reglas
+
+- `seguridad-agentes.md` — sección "Anti-fallback silencioso y anti-degradación"
+  cubre el mismo principio aplicado a agentes autónomos. Esta regla lo extiende
+  al trabajo del usuario.
+- `git-workflow.md` — los commits siguen siendo atómicos; arreglar un problema
+  detectado puede requerir varios commits, no uno solo gigante.
+- `pruebas.md` — los tests rotos son violaciones a esta regla. No se mergea
+  con tests rotos (excepción: tests rotos por decisión de producto en proceso).
+
+---
+
+## Origen de esta regla
+
+Consolidada el 2026-05-04 a partir de cuatro feedbacks repetidos del usuario en
+memorias nativas de Claude Code de los proyectos sigm, swl-ses y emaia
+(2026-04-23 a 2026-05-03). Antes vivía duplicada en 4 archivos de feedback
+distintos en 2 de los 3 proyectos. Promovida a regla global para eliminar
+duplicación y aplicar uniformemente a todo proyecto del usuario.
+
+Memoria nativa local correspondiente: redundante tras esta regla; mantener solo
+una mención mínima en MEMORY.md de cada proyecto si se desea preservar el rastro
+histórico, pero el contenido operativo vive aquí.