navori 0.2.22 → 0.3.0

package/README.md

@@ -4,6 +4,26 @@ Multi-agent harness + SDD scaffolder for Claude Code (and other AI engines).
 
 `navori` lleva tu setup de Claude Code (agentes, skills, hooks, CLAUDE.md, AGENTS.md) a múltiples repos con un solo comando — sin perder customización local, sin sobrescribir lo que ya tenías.
 
+También renderiza un harness Codex completo: `AGENTS.md`, skills en
+`.agents/skills/`, agentes y hooks en `.codex/`, y MCP project-local.
+
+### Perfiles de engines
+
+```jsonc
+// Paridad completa para ambos proveedores
+{ "engines": ["claude", "codex"] }
+
+// Claude completo + guía AGENTS.md ligera para Codex y otras herramientas
+{ "engines": ["claude", "agents-md"] }
+
+// Solo guía universal, con el menor número de archivos
+{ "engines": ["agents-md"] }
+```
+
+`codex` ya incluye y administra `AGENTS.md`; no necesitas combinarlo con
+`agents-md`. Si ambos aparecen en un config, el adapter Codex toma precedencia
+para evitar bloques duplicados.
+
 ## Instalación
 
 ```bash
@@ -47,9 +67,9 @@ Y genera:
 | `add <plugin>` | Activa un plugin y opcionalmente instala la tool externa |
 | `configure <section>` | Ajusta una sección del config sin re-correr el wizard |
 | `update` | Re-detecta el repo, refresca config y corre sync en un paso |
-| `render` | Genera CLAUDE.md y `.claude/` desde el config (preview por default; `--apply` escribe). `--all` renderea todos los repos del registro global; `--prune` limpia los que ya no existen |
+| `render` | Genera los archivos nativos de cada engine configurado (preview por default; `--apply` escribe). `--all` renderea todos los repos del registro global; `--prune` limpia los que ya no existen |
 | `registry <sub>` | Registro global de tus repos con navori, para `render --all` (`ls`, `scan <dir>`, `add`, `remove`, `prune`) |
-| `sync` | Refresca los managed blocks con conflict resolution + backups |
+| `sync` | Refresca todos los engines configurados con conflict resolution + backups |
 | `preset init <id>` | Scaffoldea un preset local en `.navori/presets/<id>/` |
 | `scan` | Detecta workspaces nuevos en monorepos (`pnpm-workspace.yaml` / `package.json#workspaces`) |
 | `doctor` | Audita el config + drift de cada managed block (CLAUDE.md **y AGENTS.md**), orden canónico, markers malformados, desincronización de monorepo y tools externas faltantes (`--strict` para CI) |
@@ -104,7 +124,6 @@ La resolución es **local → bundled**: si tienes un preset local con el mismo
 | `gh` | GitHub Issues, PRs y workflow runs | `gh` |
 | `jscpd` | Detección de duplicación en el diff | `jscpd` (opt-in) |
 | `semgrep` | Security gate local | `semgrep` (opt-in) |
-| `cognitive` | Guardrails de complejidad cognitiva | (ninguna) |
 
 Activar uno:
 ```bash
@@ -212,7 +231,8 @@ Conflict in 'idioma-rol':
   - tu versión
   + versión del Core
 ```
-Y eliges: `skip-conflicts` (mantener tu edit), `apply-all` (pisar) o `abort`.
+Y eliges `skip-conflicts`, resolución interactiva para bloques de `CLAUDE.md`, o `abort`.
+Los conflictos de archivo completo nunca se pisan automáticamente.
 
 Backups automáticos en `~/.navori/backups/<timestamp>/` antes de cada `sync` (retención 30 días).
 
@@ -224,7 +244,7 @@ Cambiar una sola cosa sin re-init:
 navori configure plugins              # multiselect de plugins activos
 navori configure quality-gate         # nuevo comando de quality gate
 navori configure language en          # switch a inglés (fallback a es)
-navori configure engines              # multiselect: claude / agents-md / cursor / copilot
+navori configure engines              # multiselect: claude / codex / agents-md / cursor / copilot
 navori configure branch-base main     # punto de fork / rama protegida
 navori configure pr-target develop    # rama destino del PR (gh pr create --base)
 navori configure workspace bonum      # asociar a un workspace

package/dist/assets/core/core-assets/agents/commit-pr-pilot.md

@@ -49,7 +49,7 @@ Archivo ausente, ambiguo (más de un candidato) o con veredicto/scope que no mat
 
 ### Gate: no correr de más
 
-Tu `git commit`/`push` dispara los hooks `PreToolUse`, que corren **mecánicamente**: `quality-gate-pre-commit` (re-corre `{{qualityGate.fast}}` y bloquea si está en rojo) + jscpd/semgrep/cognitive (duplicación/seguridad/complejidad). Ese es el enforcement que no se puede saltar. Además, el `reviewer` ya corrió `{{qualityGate.fast}}` verde sobre este mismo diff (evidencia en `review_<feature>.md`, este ciclo) y tú **no editas código**.
+Tu `git commit`/`push` dispara los hooks `PreToolUse`, que corren **mecánicamente**: `quality-gate-pre-commit` (re-corre `{{qualityGate.fast}}` y bloquea si está en rojo) + jscpd/semgrep (duplicación/seguridad). Ese es el enforcement que no se puede saltar. Además, el `reviewer` ya corrió `{{qualityGate.fast}}` verde sobre este mismo diff (evidencia en `review_<feature>.md`, este ciclo) y tú **no editas código**.
 
 - ✅ **No corras `{{qualityGate.fast}}` a mano en el pre-flight.** Lo correrías dos veces sobre código ya verificado verde (tu corrida + el hook del commit). Confía en la evidencia del review para proceder; el hook del commit es el backstop mecánico.
 - ▶️ **Córrelo a mano antes de commitear** solo si dudas de que pase: el diff cambió desde el review, hubo rebase/merge, o no hay evidencia fresca del gate verde. Así evitas un commit bloqueado por el hook y el reintento.

package/dist/assets/core/core-assets/hooks/quality-gate-pre-commit.sh

@@ -70,7 +70,6 @@ run_gate() {
 # standalone, so there is no shared lib to import):
 #   plugins/jscpd/scripts/check-jscpd.sh
 #   plugins/semgrep/scripts/check-semgrep.sh
-#   plugins/cognitive/scripts/check-cognitive.sh
 is_git_commit() {
   local input="$1" segment
   # FIX B: join `\<newline>` continuations into a space FIRST, so a command

package/dist/assets/core/core-assets/presets/nextjs/skills/new-resource.md

@@ -0,0 +1,66 @@
+---
+name: new-resource
+description: Crear un recurso/feature de punta a punta en Next.js App Router (tipo → validación → datos → adapter → UI → ruta). Aplica al dar de alta un recurso nuevo; para modificar uno existente, espeja su patrón en vez de rehacerlo.
+type: reference
+maxWords: 800
+---
+
+# new-resource — recurso/feature end-to-end (Next.js App Router)
+
+## Cuándo usar
+
+Al dar de alta un recurso o feature nuevo de punta a punta (datos → UI → ruta). Para tocar uno que ya existe, sigue su patrón; no lo rehagas.
+
+## 0. Antes de crear: reusa y sé consistente (esto primero)
+
+- **Busca un recurso similar YA en el repo y espéjalo**: estructura de carpetas, naming, capa de datos, manejo de estado. Consistencia con el repo > preferencia personal.
+- **Reusa antes de crear**: ¿ya hay un componente / hook / util (el UI kit del repo, `shared/`) que sirve? Úsalo. Crea algo nuevo solo si de verdad no existe uno equivalente.
+- **Sigue el theme / design system**: usa los tokens y componentes de la lib del repo; nada de estilos hardcodeados ni UI fuera de tema.
+- **Una fuente de verdad**: deriva tipos, labels y estados de donde ya viven; no dupliques enums ni constantes.
+
+## Estructura — feature-based + colocación
+
+- Todo lo del recurso **junto, colocado a su feature/ruta** (`_components`, `_lib` privados en App Router — el prefijo `_` los excluye del routing). No lo esparzas en `/components` o `/utils` globales.
+- **Regla shared**: si UN feature lo usa → vive dentro del feature; si DOS o más lo usan → promuévelo a `shared/`. Los features **no se importan entre sí** (si hace falta, compón en la page o sube la pieza a shared).
+- Nesting 2-3 niveles máx. Empieza simple; agregas estructura cuando el recurso realmente crece.
+
+## Pasos (orden estricto — de adentro hacia afuera)
+
+Cada paso depende del anterior; verifica que compila antes de seguir.
+
+1. **Tipo de dominio** — el modelo del recurso en tu capa de tipos, agnóstico del backend o de tipos generados. Enums + sus labels/variants derivados aquí (fuente única).
+2. **Validación en la frontera** — schema (zod) para todo input externo (form, params, respuesta de red). Los DTOs salen del schema (`z.infer`), no se escriben a mano.
+3. **Acceso a datos (server)** — la query/mutation por tu capa de datos: fetch en un Server Component, un Server Action o un route handler. Secretos y sesión quedan en el server.
+4. **Adapter** (solo si hay tipos generados / GraphQL) — mapea el tipo crudo del backend al tipo de dominio y normaliza enums desconocidos a un valor seguro. La UI consume **dominio**, nunca tipos generados.
+5. **UI** — un Server Component que fetchea y compone; empuja `"use client"` a las **hojas** (interactividad, estado, browser APIs), lo más abajo posible. Pasa props serializables hacia abajo y reusa el UI kit.
+6. **Routing / nav** — la page/segment en App Router y su entrada de navegación. Sin esto, el recurso no es accesible.
+
+## Server vs Client (App Router)
+
+- **Server Component por default**: data, secretos, composición. Fetchea en el server y evita el API ping-pong (no re-traigas en el cliente lo que ya trajo el server).
+- **Client Component** (`"use client"`) solo para interacción, estado local o browser APIs, y siempre lo más abajo posible en el árbol.
+
+## Qué NO hacer (evita over-engineering)
+
+- Nada de hexagonal / DDD / CQRS ni capas de abstracción especulativas para un CRUD. Layered simple alcanza.
+- Sin interface o helper genérico con un solo caller, ni parametrización "por si acaso".
+- Sin dependencia nueva para lo que el repo, la plataforma o una lib ya instalada resuelven en unas líneas.
+- No dupliques un componente que ya existe con otro nombre (rompe la fuente única y el theme).
+
+## Antes de declarar listo
+
+- `{{qualityGate.fast}}` en verde.
+- El recurso es accesible (page + entrada de nav) y el golden path anda; el input inválido se rechaza en la frontera (zod).
+- Reusaste lo que existía y seguiste el patrón + theme del repo — no inventaste una variante.
+- La UI consume tipos de dominio (no generados) y `"use client"` está solo donde hace falta.
+
+<!-- navori:user-section -->
+## Convenciones de este repo
+
+<!-- user: documenta aquí lo específico de tu stack para que el scaffold sea exacto:
+     - Rutas exactas donde viven tipos, schemas, capa de datos, adapters y features/UI.
+     - Tu UI kit / design system y dónde está el theme (tokens, componentes base a reusar).
+     - Si usas GraphQL + codegen: el comando (ej. `bun run codegen`) y de dónde salen los tipos generados.
+     - El helper de validación y el contrato de respuestas/errores.
+     - Un recurso EJEMPLO ya hecho que sirva de molde a espejar.
+-->

package/dist/assets/core/core-assets/presets/nextjs.json

@@ -21,6 +21,11 @@
         "id": "nextjs-data-fetching",
         "relPath": "presets/nextjs/skills/nextjs-data-fetching.md",
         "destRelPath": ".claude/skills/nextjs-data-fetching.md"
+      },
+      {
+        "id": "new-resource",
+        "relPath": "presets/nextjs/skills/new-resource.md",
+        "destRelPath": ".claude/skills/new-resource.md"
       }
     ],
     "hooks": []

package/dist/assets/core/core-assets/settings/settings-base.json

@@ -40,6 +40,8 @@
       "Bash(stat:*)",
       "Bash(tree:*)",
       "Bash(grep:*)",
+      "Bash(sg:*)",
+      "Bash(ast-grep:*)",
       "Bash(jq:*)",
       "Bash(diff:*)",
       "Bash(cut:*)",

package/dist/assets/core/core-assets/skills/debug-error.md

@@ -0,0 +1,36 @@
+---
+name: debug-error
+description: Usar cuando un comando (tsc, lint, build, test) o el runtime escupe un muro de errores. Antes de tocar código: filtra el ruido, clasifica el tipo de error, y arregla la CAUSA RAÍZ, no los síntomas en cascada. Los patrones de error de tu stack van en la user-section.
+type: behavior
+maxWords: 600
+---
+
+# Debug error — triage antes de arreglar
+
+Cuando un comando falla con muchas líneas, el error es reaccionar al primero (o al más ruidoso) y tirar un fix. Este skill fuerza el triage previo.
+
+## El protocolo (en orden)
+
+1. **Filtra el ruido.** Aísla los errores reales del chatter de la herramienta: líneas de progreso/éxito (`compiled`, `generating…`), warnings (no son errores) y logs sin stack. Quédate solo con las líneas que son un error de verdad.
+2. **Clasifica el tipo.** Antes de arreglar, identifica la categoría — cada una tiene una forma de causa distinta:
+   - **Tipos / compilador** (tsc): tipo esperado vs recibido; a menudo un tipo desactualizado o una regeneración pendiente (codegen / schema).
+   - **Lint**: mecánico, casi siempre auto-fixable; no lo trates como bug de lógica.
+   - **Build**: config, env, o boundary (server/client, dynamic) — no es el código de negocio.
+   - **Runtime**: `undefined` / `null` no manejado, red, o auth / sesión.
+3. **Encuentra la causa RAÍZ.** Un solo error raíz suele cascadear en 10-20 downstream (un import o tipo faltante rompe todo lo que lo usa). **Arregla la raíz, re-corre y RE-CLASIFICA** — no dispares varios fixes a la vez contra los síntomas.
+4. **Reporta / arregla** con el formato de `formato-respuesta` (`CAUSA` + `archivo:línea` + `FIX` mínimo). Sin preámbulo.
+
+## Reglas
+
+- **Un fix a la vez** contra la raíz, luego re-corre. Si el mismo error persiste tras el fix → cambia a `loop-back-debug` (re-valida la hipótesis, no sigas patcheando).
+- **No arregles síntomas** que van a desaparecer solos al arreglar la raíz.
+- **Warning ≠ error** — un warning no bloquea; no gastes el turno en él salvo que lo pidan.
+
+<!-- navori:user-section -->
+## Patrones de error de tu stack
+
+<!-- user: documenta aquí los errores recurrentes de TU toolchain y su fix, para triage instantáneo. Sugerencias:
+     - Filtros de ruido específicos (líneas del build/runner que NO son errores).
+     - Errores típicos con su causa + fix (ej. codegen no corrido, boundary server/client, import path/alias, env faltante).
+     - Comandos de regeneración/validación (codegen, migrations) que resuelven categorías enteras de errores.
+-->

package/dist/assets/core/core-assets/skills/security-guidance.md

@@ -0,0 +1,63 @@
+---
+name: security-guidance
+description: Usar al correr /security-review o al auditar seguridad. Documenta las invariantes de seguridad de NEGOCIO que el scanner estático (semgrep) y el review built-in no infieren del código solo — autorización server-side, acceso a objetos (IDOR), secretos y env expuesto al cliente, fronteras de confianza, PII en logs. El esqueleto es universal; las reglas de tu stack van en la user-section.
+type: reference
+maxWords: 1200
+---
+
+# Security guidance — capa de seguridad de negocio
+
+Alimenta el flujo `/security-review`. Los patrones genéricos de vuln web (XSS, SSRF, secretos hardcodeados, deserialización insegura, inyección) ya los cubren semgrep y el reviewer built-in. Aquí va lo que el modelo **no puede inferir del código solo**: las invariantes de autorización y confianza que dependen del dominio.
+
+Reporta con severidad `[CRÍTICO]`/`[ALTO]`/`[MEDIO]` y `archivo:línea`, como en `review-diff`. Un bypass de autorización o un secreto expuesto es CRÍTICO.
+
+## 1. Autorización — se enforcea en el servidor
+
+- Toda ruta / endpoint / acción que expone datos o efectos protegidos DEBE verificar el rol o permiso **en el servidor**, antes de la query o el efecto. Falta de guard server-side = **bypass de autorización, CRÍTICO**.
+- Los guards de cliente (render condicional, checks en el componente, un `useAuth()`) **nunca alcanzan solos** — son UX, no enforcement. Una vista protegida que solo confía en el cliente es CRÍTICO.
+- La config de navegación / UI (menús, un `allowedRoles` en el array de nav) filtra la UI, **no** controla acceso. Agregar una entrada ahí sin el guard server-side correspondiente es un hallazgo.
+- El guard debe **fallar cerrado**: sin sesión o backend caído → deniega / redirige, nunca "deja pasar por las dudas". No agregues un path que corte en error hacia el lado permisivo.
+
+## 2. Acceso a objetos (IDOR)
+
+- Un id que viene del input (URL, body, query) NO autoriza por existir. La **propiedad / alcance se verifica server-side** (idealmente en el backend o la capa de acceso), no en el cliente.
+- Una vista que trae un registro por id-de-URL debe confiar en el error de acceso del backend (`ACCESS_DENIED` / 403), no inventar su propio check de ownership ni asumir que el id es válido.
+- Las listas de entidades sensibles nunca se consultan desde el cliente con filtros amplios — van por el servidor con la sesión autenticada.
+
+## 3. Manejo de errores de auth
+
+- Los errores de autenticación / autorización (sesión expirada, cuenta bloqueada, 401/403) se manejan **de forma global y fail-closed** (logout / redirect), no se tragan localmente ni se muestran inline como error de formulario.
+- Define el contrato de códigos de error del backend (ej. 401 sesión, 423 bloqueo, 429 rate-limit) y respétalo. Manejo custom de esos códigos en un componente puntual es un hallazgo.
+
+## 4. Secretos y variables de entorno
+
+- Cero secretos / tokens / URLs internas hardcodeados — **incluido tests y archivos `.env.example`** (usa placeholders). Un secreto en código es CRÍTICO.
+- Las vars que se **bundlean al cliente** (prefijos como `NEXT_PUBLIC_`, `VITE_`, `PUBLIC_`) DEBEN ser seguras de filtrar: nada de API keys, tokens ni URLs internas detrás de ese prefijo. Poner un valor sensible ahí es CRÍTICO.
+
+## 5. Fronteras de confianza / flujo de datos
+
+- Todo dato de fuente externa (backend, red, input) se **valida y normaliza en la frontera** antes de entrar al dominio. No pases valores crudos del backend directo a la UI.
+- Fallbacks de enums / estados desconocidos → a un valor seguro conocido, nunca passthrough crudo ni throw (un enum no confiable crudo en la UI = confusión de estado o potencial XSS).
+- Respeta las fronteras arquitectónicas que declare el repo (qué capa puede importar tipos generados o hablar con qué backend).
+
+## 6. Logging y PII
+
+- Nada de `console.log` / print de datos de usuario, tokens, cookies de sesión o PII (email, teléfono, documentos) en paths de producción. Logs de debug solo detrás de un guard de entorno (ej. `NODE_ENV === 'development'`).
+
+## Cómo usarlo en el review
+
+1. Recorre el diff o el área con estas 6 categorías como checklist.
+2. Reporta con severidad y `archivo:línea`.
+3. Cruza con las **reglas específicas de tu stack** (abajo): los nombres concretos de tus guards, códigos de error y prefijos de env viven ahí — sin eso, el review solo cubre la capa universal.
+
+<!-- navori:user-section -->
+## Invariantes de seguridad de tu stack
+
+<!-- user: documenta aquí lo que el modelo NO puede inferir del código — las reglas concretas de TU dominio. Sugerencias:
+     - AUTORIZACIÓN: nombre y firma del guard server-side obligatorio (ej. `requireRole([...])`), dónde va, sus paths terminales, y qué rutas lo exigen.
+     - IDOR: cómo se identifican los recursos (UUID / CUID / slug), el helper de validación, y qué entidades son sensibles.
+     - ERRORES: el contrato exacto de códigos de tu backend (401/403/423/429…) y el handler global.
+     - ENV: el gestor de secretos (Infisical / Vault / …), el prefijo de vars cliente de tu framework, y qué NUNCA lleva ese prefijo.
+     - FRONTERAS: qué capa puede importar qué (tipos generados, clientes de backend), reglas de adapters y sanitización.
+     - Anti-patterns de tu repo que son auto-CRÍTICO.
+-->

package/dist/assets/core/core-assets/skills/structural-search.md

@@ -0,0 +1,69 @@
+---
+name: structural-search
+description: Usar cuando necesitas localizar formas sintácticas, relaciones estructurales o hacer un refactor multi-sitio; escala desde engram y Grep hacia ast-grep solo con triggers explícitos.
+type: reference
+---
+
+# structural-search — leer lo mínimo correcto
+
+Encuentra primero la región correcta y abre solo el span confirmado. Las herramientas de precisión verifican una hipótesis; no la forman.
+
+## Escalera Rung 0–2
+
+### Rung 0 — orientación con engram
+
+Antes de buscar, consulta memoria para preguntas durables: dónde vive un módulo, entry points, capas, convenciones y decisiones. Usa el resultado como **hipótesis de scope**, nunca como fuente de verdad para líneas, firmas o call sites.
+
+Confirma cada puntero con una búsqueda barata. Si el código contradice la memoria, corrige la observación de inmediato. Guarda punteros estructurales, no snapshots volátiles.
+
+### Rung 1 — texto con Grep/ripgrep (default)
+
+Úsalo cuando conoces un token literal: nombre, import, config key, string de error.
+
+1. Empieza estrecho: archivo, directorio o tipo obtenido en Rung 0.
+2. Pide primero archivos (`rg -l`) o `file:line` con máximo dos líneas de contexto.
+3. Deduplica antes de leer.
+4. Abre únicamente el span que confirma el hit.
+
+Escala a Rung 2 solo si ocurre uno:
+
+- cero resultados después de dos patrones razonables;
+- los resultados son puro ruido;
+- estás escribiendo regex para aproximar sintaxis;
+- necesitas un refactor estructural multi-sitio.
+
+### Rung 2 — estructura con ast-grep
+
+Usa `sg` o `ast-grep` para formas del AST:
+
+```bash
+sg -p 'async function $N($$$) { $$$ }' -l ts src/
+ast-grep -p 'useAuth($$$)' -l tsx apps/
+```
+
+Para reescribir, prueba primero el patrón sin `--rewrite`, limita paths/lenguaje y revisa el diff antes de aplicar. Un nombre literal sigue siendo Rung 1; una pregunta conceptual vuelve a Rung 0.
+
+Si ninguno de los binarios existe, cae a Grep y lectura puntual: **no bloquees la tarea** ni inventes sintaxis de ast-grep.
+
+## Mapa rápido
+
+| Necesidad | Rung |
+|---|---:|
+| Dónde vive un adapter o convención | 0 |
+| Import, símbolo o mensaje conocido | 1 |
+| Hooks/componentes con una forma concreta | 2 |
+| Codemod multi-sitio | 2 |
+| Semántica cross-file con tipos | lectura manual del span confirmado |
+
+## Límites
+
+- No leas archivos completos por reflejo.
+- No corras grep ancho sin scope.
+- No uses regex como AST.
+- Si la búsqueda consume ~15% del contexto, detente: reduce scope o actúa con la evidencia disponible.
+- No montes LSP/Serena; este harness termina en Rung 2.
+
+<!-- navori:user-section -->
+## Patrones estructurales del proyecto
+
+<!-- user: documenta aquí patrones sg/ast-grep comprobados, lenguajes y paths frecuentes. Guarda patrones reutilizables; no pegues resultados ni líneas actuales. -->

package/dist/assets/plugins/engram/managed/engram-protocol.md

@@ -1,6 +1,9 @@
 ## Engram
 
-- `mem_save` proactivo tras decisión / bug-fix-con-root-cause / convención / discovery / preferencia confirmada.
-- `mem_search` al inicio si el primer mensaje referencia el proyecto. Verificar en código que lo recordado siga existiendo antes de afirmarlo.
-- Lo recordado es una foto de cuando se guardó, no un hecho vigente. Si el sistema expone vigencia (`active` / `needs_review`), trata `needs_review` como contexto stale: avisa al usuario y verifícalo contra el código actual antes de apoyarte en eso.
+- **Arranque de sesión (primer paso, obligatorio):** llama `mem_context` al inicio de CADA sesión para recuperar decisiones, discoveries y trabajo de sesiones previas — no esperes a que el usuario lo pida. En hosts que NO cargan la memoria con un hook de arranque (p.ej. Codex), esta llamada explícita ES el arranque de la memoria; no la omitas.
+- **Pre-flight:** `mem_search` con keywords de la tarea para orientar dónde/por qué vive algo antes de buscar código. La memoria da una región e hipótesis; confirma firma, línea y call sites con Grep/structural-search antes de actuar.
+- **Guarda solo lo durable:** decisiones, arquitectura, convenciones, root causes y punteros de módulo. Nunca persistir líneas, firmas actuales, listas de call sites ni estado temporal.
+- `mem_save` proactivo con `topic_key` estable por tema. Reutiliza el mismo key para evolucionar una observación mediante upsert, en vez de crear snapshots repetidos.
+- **Write-back:** si el código contradice una memoria, corrígela con `mem_update`/`mem_save` de inmediato. Trata `needs_review` como contexto stale.
 - `mem_session_summary` obligatorio antes de "listo": Goal · Discoveries · Accomplished · Next Steps · Relevant Files.
+- **Curación al cerrar:** tras guardar el summary, revisa lo creado en la sesión. Consolida duplicados bajo su `topic_key`, asciende lo durable y elimina solo observaciones claramente volátiles o ya cubiertas por el summary. No hagas borrado agresivo ni borres una decisión durable.

package/dist/assets/plugins/engram/plugin.json

@@ -19,6 +19,10 @@
     },
     "postInstall": "claude plugin install engram"
   },
+  "mcpServer": {
+    "command": "engram",
+    "args": ["mcp", "--tools=agent"]
+  },
   "skills": [
     {
       "id": "engram-leader-extension",

package/dist/assets/plugins/engram/skills/engram-leader.md

@@ -8,7 +8,7 @@ type: behavior
 
 Antes de descomponer trabajo: **busca contexto** con `mem_search` usando keywords del ticket. Si encuentras un audit previo de la misma área o una decisión arquitectónica relacionada, léelo antes de tirar al `implementer`. No re-descubrir lo que ya está guardado.
 
-Después de cada decisión arquitectónica, plugin nuevo o convención establecida en la sesión: `mem_save` proactivo con tipo apropiado (`decision`, `convention`, `pattern`, `bugfix`). Encabeza con qué decisión + por qué + dónde aplica.
+Después de cada decisión arquitectónica, plugin nuevo o convención establecida en la sesión: `mem_save` proactivo con tipo apropiado (`decision`, `convention`, `pattern`, `bugfix`) y un `topic_key` estable. Reutiliza el key para evolucionar el tema sin acumular snapshots. Guarda punteros durables; líneas, firmas y call sites se verifican en código y no se persisten.
 
 Antes de cerrar la sesión: `mem_session_summary` obligatorio con:
 
@@ -17,3 +17,5 @@ Antes de cerrar la sesión: `mem_session_summary` obligatorio con:
 - `accomplished` — qué quedó hecho.
 - `next_steps` — qué falta (con paths concretos).
 - `relevant_files` — paths que un futuro agente debería leer primero.
+
+Después del summary, cura la sesión: consolida duplicados, corrige memorias contradichas y elimina solo contenido claramente volátil o redundante. Nunca hagas pruning agresivo de decisiones durables.

package/dist/assets/plugins/jscpd/plugin.json

@@ -30,7 +30,7 @@
     {
       "event": "PreToolUse",
       "matcher": "Bash",
-      "command": "bash .claude/scripts/check-jscpd.sh",
+      "command": "bash \"$CLAUDE_PROJECT_DIR/.claude/scripts/check-jscpd.sh\"",
       "timeout": 180,
       "statusMessage": "navori/jscpd: dup check"
     }

package/dist/assets/plugins/jscpd/scripts/check-jscpd.sh

@@ -34,7 +34,7 @@ cmd=$(extract_cmd)
 # space. Because it matches a segment START, a quoted `echo "git commit"` does
 # NOT trigger it. Known limitation: it cannot see through `sh -c`, `eval`, or
 # obfuscation — a seatbelt, not a sandbox. Body duplicated across the navori quality hooks (they render standalone — no
-# shared lib). The quality-gate/jscpd/cognitive copies gate `git commit` ONLY;
+# shared lib). The quality-gate/jscpd copies gate `git commit` ONLY;
 # the semgrep copy also gates `git push` and `gh pr create` (remote-push
 # security backstop). Keep in sync.
 is_git_commit() {
@@ -87,8 +87,19 @@ if [ -n "$cmd" ] && ! is_git_commit "$cmd"; then
   exit 0
 fi
 
-if ! command -v jscpd >/dev/null 2>&1; then
-  echo "⊘ jscpd no instalado localmente — skip (install: pnpm add -g jscpd)" >&2
+# Resolve jscpd: prefer the repo-pinned binary (node_modules/.bin) over a global
+# one. A global jscpd can be a DIFFERENT major (e.g. 4.x vs the repo's 5.x) whose
+# tokenizer reports different duplication than `pnpm run dup`, so the commit gate
+# would measure something other than what the repo declares. Local-first fixes it.
+JSCPD_BIN=""
+_repo_root="$(git rev-parse --show-toplevel 2>/dev/null || true)"
+if [ -n "$_repo_root" ] && [ -x "$_repo_root/node_modules/.bin/jscpd" ]; then
+  JSCPD_BIN="$_repo_root/node_modules/.bin/jscpd"
+elif command -v jscpd >/dev/null 2>&1; then
+  JSCPD_BIN="jscpd"
+fi
+if [ -z "$JSCPD_BIN" ]; then
+  echo "⊘ jscpd no disponible (ni pinneado en el repo ni instalado global) — skip (install: pnpm add -D jscpd)" >&2
   exit 0
 fi
 
@@ -121,7 +132,7 @@ echo "▶ jscpd: ${#files[@]} archivo(s) modificados vs {{branchBase}}" >&2
 tmpdir=$(mktemp -d)
 trap 'rm -rf "$tmpdir"' EXIT
 
-jscpd \
+"$JSCPD_BIN" \
   --min-tokens 100 \
   --min-lines 10 \
   --mode strict \

package/dist/assets/plugins/semgrep/plugin.json

@@ -29,7 +29,7 @@
     {
       "event": "PreToolUse",
       "matcher": "Bash",
-      "command": "bash .claude/scripts/check-semgrep.sh",
+      "command": "bash \"$CLAUDE_PROJECT_DIR/.claude/scripts/check-semgrep.sh\"",
       "timeout": 180,
       "statusMessage": "navori/semgrep: security scan"
     }

package/dist/assets/plugins/semgrep/scripts/check-semgrep.sh

@@ -1,8 +1,14 @@
 #!/usr/bin/env bash
 # Generated by @navori/plugin-semgrep. Runs semgrep over TS/TSX files changed
-# vs `{{branchBase}}` with the `auto` ruleset. Skips silently if semgrep or
+# vs `{{branchBase}}` with the `p/default` ruleset. Skips silently if semgrep or
 # git are absent — the tool is optional.
 #
+# NOTE: `p/default` (not `auto`) on purpose. `--config=auto` is INCOMPATIBLE
+# with `--metrics=off` in semgrep >=1.x ("Cannot create auto config when metrics
+# are off") because auto uploads project metadata to fetch tailored rules. A
+# static ruleset keeps telemetry off AND runs deterministically — better for a
+# gate anyway (same rules on every machine).
+#
 # Triggered as a PreToolUse(Bash) hook (gated to git commit / push / gh pr create) and as a
 # Stop hook (runs unconditionally at session close).
 
@@ -35,7 +41,7 @@ cmd=$(extract_cmd)
 # space. Because it matches a segment START, a quoted `echo "git commit"` does
 # NOT trigger it. Known limitation: it cannot see through `sh -c`, `eval`, or
 # obfuscation — a seatbelt, not a sandbox. Body duplicated across the navori quality hooks (they render standalone — no
-# shared lib). The quality-gate/jscpd/cognitive copies gate `git commit` ONLY;
+# shared lib). The quality-gate/jscpd copies gate `git commit` ONLY;
 # the semgrep copy also gates `git push` and `gh pr create` (remote-push
 # security backstop). Keep in sync.
 is_scan_trigger() {
@@ -120,7 +126,7 @@ fi
 echo "▶ semgrep: ${#files[@]} archivo(s) modificados vs {{branchBase}}" >&2
 
 semgrep scan \
-  --config=auto \
+  --config=p/default \
   --error \
   --metrics=off \
   "${files[@]}"