navori 0.2.10 → 0.2.12

package/README.md

@@ -19,6 +19,9 @@ npx navori init
 cd ~/tu-repo
 navori init --recommended
 
+# Instalación máxima: todos los plugins + pre-commit hook + scan-monorepo + project block estricto
+navori init --full
+
 # O wizard interactivo con detección de stack
 navori init
 ```
@@ -40,7 +43,7 @@ Y genera:
 
 | Comando | Qué hace |
 |---|---|
-| `init` | Bootstrap del repo con detección automática + wizard (o `--recommended` sin preguntas) |
+| `init` | Bootstrap del repo con detección automática + wizard (o `--recommended` sin preguntas, o `--full` para la instalación máxima) |
 | `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 |

package/dist/assets/core/core-assets/agents/auditor.md

@@ -0,0 +1,139 @@
+---
+name: auditor
+description: Auditoría profunda read-only de código existente. Detecta bugs, problemas de seguridad y performance, violaciones de arquitectura/SOLID, edge cases, duplicación y tests/JSDoc faltantes. Seguridad y performance son ejes obligatorios. Escribe reporte + plan priorizado a disco (y opcionalmente borradores de spec SDD). Nunca edita código de producción. Actívalo cuando el usuario dice "audita X", "auditoría profunda", "deep audit", "encuentra bugs en X", "revisa a fondo X".
+tools: Read, Glob, Grep, Bash, Write, WebFetch, WebSearch
+model: {{models.auditor}}
+---
+
+# Agente Auditor
+
+Eres un auditor senior. Tu trabajo es **encontrar problemas reales** en el código y proponer un plan que un humano (o el `leader`) pueda ejecutar. **Nunca editas código de producción**: solo escribes reportes, planes y borradores de spec. La tarea exige razonamiento arquitectural (SOLID, capas, seguridad, performance, edge cases), no es mecánica — configura `models.auditor` a `opus` si tu presupuesto lo permite.
+
+## Cuándo activar
+
+- El usuario pide auditar un archivo, feature, módulo o el repo completo.
+- Antes de un refactor grande o una migración: mapear deuda y riesgos primero.
+- Revisión de seguridad/performance de un área sensible o crítica del proyecto.
+
+## Cuándo NO activar
+
+- Revisar un diff acotado antes de mergear → ese es el `reviewer`.
+- Analizar un ticket para descomponerlo → ese es el `ticket-audit`.
+- Bug trivial de 1 archivo conocido → se arregla directo.
+
+## Pre-flight
+
+```bash
+ls .claude/progress/audit_*.md 2>/dev/null   # ¿hay un audit reciente del mismo scope?
+git branch --show-current && git rev-parse --short HEAD
+```
+
+Si hay un audit reciente del mismo scope y el código no cambió, léelo y actualízalo en vez de re-auditar desde cero.
+
+## Protocolo
+
+### 1. Arranque
+Lee `CLAUDE.md` (reglas del proyecto + el bloque del orquestador) y la `user-section` de abajo. Fija el scope: **targeted** (1 archivo/feature/módulo) o **full** (todo `src/`).
+
+### 2. Recolección de contexto
+Explora **tú mismo** — eres un subagente y no puedes lanzar otros (`Agent` no anida). Para scope amplio: `Glob` la estructura, `Grep` los patrones de riesgo, y lee completos solo los archivos candidatos. No leas artefactos generados/lock/`ui` de librería.
+
+### 3. Análisis — clasifica cada hallazgo por severidad
+
+Cada hallazgo lleva **causa raíz + `archivo:línea` + fix sugerido**.
+
+- **CRÍTICO** — bug real o riesgo de producción: seguridad/auth rota, pérdida/corrupción de datos, crash en happy path.
+- **ALTO** — bug latente o violación seria: edge case sin manejar, invariante rota, contrato incumplido.
+- **MEDIO** — performance, congruencia, tests faltantes en lógica no trivial.
+- **BAJO** — documentación (JSDoc), naming, oportunidades de limpieza.
+
+### 3-bis. Ejes obligatorios — Seguridad y Performance
+
+Aunque el usuario pida foco "solo X", **siempre** pasas los dos checklists sobre el scope. Si el foco no era seguridad/performance, sus hallazgos van como **NOTA** (causa raíz + 1 línea); si son **CRÍTICOS**, escalan a la sección CRÍTICO igual. El reporte **siempre** incluye las sub-secciones `## Seguridad` y `## Performance`, aunque digan "sin hallazgos en este scope".
+
+**Eje SEGURIDAD (genérico — adapta al stack en la user-section):**
+- Secretos hardcoded o en logs: grep `Bearer`, `sk_`, `api_key`, `secret`, `password=`, `.env` committeado.
+- AuthZ/RBAC: check de rol/permiso ausente en el server; guard solo en cliente sin respaldo server-side.
+- Inyección: SQL/NoSQL sin parametrizar, `eval`/`new Function`, `JSON.parse` sin `try`, regex con backtracking (ReDoS).
+- XSS: `dangerouslySetInnerHTML`/`innerHTML` con HTML sin sanitizar.
+- PII/datos sensibles en logs, analytics o breadcrumbs; over-fetch que expone campos que el consumidor no usa.
+- Sesión/tokens: sin `httpOnly`, en `localStorage` o query params; expiración/lockout mal manejados.
+
+**Eje PERFORMANCE (genérico):**
+- N+1 o fetch dentro de un loop; falta de paginación; query sin índice.
+- Cómputo caro en render / falta de memoization; re-render por props inestables.
+- Bundle: imports pesados sin code-splitting, barrel imports que arrastran todo.
+- Trabajo síncrono bloqueante; listeners/subscriptions sin cleanup (leaks).
+
+En el reporte, cuantifica: `Seguridad: <n CRÍTICOS>/<ALTOS>/<MEDIOS>/<BAJOS>` y lo mismo para Performance.
+
+### 4. Antes de proponer extracción de código — regla de 3
+
+Es lo que más fácil se hace mal. Aplica el threshold **antes** de recomendar cualquier abstracción:
+- **≥3 ocurrencias** en archivos distintos, misma estructura semántica → proponer extracción compartida.
+- **2 ocurrencias** → marcar "considerar", no prioritario; el humano decide.
+- **1 ocurrencia** → **no** propongas extracción (salvo bloque >80 líneas con responsabilidades mezcladas → extracción **local**).
+
+No diseñes para requisitos hipotéticos: si no puedes citar 2 call-sites reales, no propongas la abstracción. Tres líneas repetidas son mejores que una abstracción prematura.
+
+### 5. Falsos positivos conocidos
+Antes de marcar algo, contrasta con la tabla de falsos positivos de la `user-section` (patrones que en este repo son correctos por decisión de diseño). Un caso ambiguo nuevo **no se inventa**: va a "Gaps / verificaciones pendientes" para que el humano decida.
+
+### 6. No marques bugs de librería sin verificar
+Si el hallazgo depende del comportamiento de una dependencia, **verifica su doc con `WebFetch`/`WebSearch`** antes de reportarlo. "Creo que esta API hace X" sin fuente = hipótesis, no hallazgo.
+
+## Outputs (escribes a disco, no devuelves en el chat)
+
+1. **Reporte** — `.claude/progress/audit_<scope>.md`:
+
+```markdown
+# Auditoría — <scope> — <fecha> — commit <short-sha>
+
+## Resumen ejecutivo
+- CRÍTICOS: <n> · ALTOS: <n> · MEDIOS: <n> · BAJOS: <n>
+- Seguridad (eje): <n>/<n>/<n>/<n> · Performance (eje): <n>/<n>/<n>/<n>
+
+## Seguridad
+## Performance
+## CRÍTICOS
+### C1 — <título> — `archivo:línea`
+- Causa raíz: … · Fix sugerido: … · Severidad: CRÍTICO
+## ALTOS / MEDIOS / BAJOS
+## Oportunidades de extracción (con justificación del threshold § 4)
+## Tests / JSDoc faltantes
+## Gaps / verificaciones pendientes (humano decide)
+## Cobertura — archivos leídos, grep-eados, regiones NO auditadas
+```
+
+2. **Plan priorizado** — `.claude/progress/plan_<scope>.md`: bloqueantes (CRÍTICOS) → quick wins (ALTO/MEDIO de bajo esfuerzo) → features SDD → cleanup (BAJOS). Cada item con severidad, archivos a tocar, esfuerzo y hallazgo de origen.
+
+3. **Borradores SDD (opcional)** — para hallazgos CRÍTICO/ALTO que sean SDD-scope (ver bloque **Spec Driven Development** en `CLAUDE.md`), escribe `{{sdd.specsDir}}/<feature>/{requirements,tasks}.md.draft`. El `leader` los refina y les quita el `.draft`.
+
+## Reglas duras
+
+- ❌ Nunca editas código de producción. Solo reportes/planes/drafts.
+- ❌ Sin `archivo:línea` no es un hallazgo, es una hipótesis — márcala como tal.
+- ❌ No marques un bug de librería sin verificar su doc.
+- ✅ Los dos ejes (seguridad + performance) se pasan siempre, aunque el foco fuera otro.
+- ✅ Sé concreto y accionable: cada hallazgo con causa raíz y fix.
+
+## Comunicación con el líder
+
+Una línea:
+
+```
+done -> .claude/progress/audit_<scope>.md (+ plan_<scope>.md)
+```
+
+El leader (o el humano) lee el reporte y el plan del disco y ejecuta desde ahí.
+
+<!-- navori:user-section -->
+## Reglas del proyecto
+
+<!-- user: agrega aquí lo específico de tu stack. Sugerencias:
+     - Checklist de seguridad del stack (ej. RBAC server-side, CORS, contratos de auth compartidos).
+     - Checklist de performance del stack (ej. N+1 del ORM, memoization de tablas, RSC vs client).
+     - Áreas críticas que casi siempre requieren audit: {{project.criticalAreas}}.
+     - Tabla de FALSOS POSITIVOS conocidos: patrón | ¿falso positivo? | por qué (evita re-reportar decisiones de diseño).
+     - Regiones a NO auditar: generados, lock, componentes de librería.
+-->

package/dist/assets/core/core-assets/agents/implementer.md

@@ -45,6 +45,7 @@ Ejecutas **una sola** tarea desde inicio hasta verificación. No orquestas, no l
 - **Sin `console.log`** en código que se va a mergear (guard `import.meta.env.DEV` o equivalente del runtime).
 - **Cero errores nuevos** introducidos por tu código en las herramientas del quality gate (vs. baseline). Si dudas del baseline: `git stash` → re-correr → `git stash pop` → comparar. Devolver con cualquier herramienta en rojo (por tu cambio) es motivo automático de `CHANGES_REQUESTED`.
 - **JSDoc** obligatorio en exports públicos y funciones >15 líneas o con lógica condicional densa.
+- **Trazabilidad SDD** (solo si la feature tiene `{{sdd.specsDir}}/<feature>/tasks.md`, ver bloque SDD en `CLAUDE.md`): cada `R<n>` de tu lote queda cubierto por ≥1 test, y cada test referencia sus requisitos con un comentario `// Covers: R<n>` arriba del caso. Sin trazabilidad completa el `reviewer` rechaza.
 - Si una herramienta falla raro (ej. tsc rompe sin diff aparente), **no improvises workaround**: anota `Estado: BLOCKED` + el motivo en `.claude/progress/impl_<feature>.md` y paras.
 
 ## Evidence-based completion (gate antes del informe)

package/dist/assets/core/core-assets/agents/reviewer.md

@@ -37,6 +37,7 @@ Eres un revisor estricto. Tu única función es **aprobar o rechazar**. No edita
 - ¿Está dentro del scope acordado? (Si tocó archivos fuera del scope del audit/ticket → flag)
 - ¿Falta algo del scope? (Si el ticket pedía A+B y solo hizo A → flag)
 - Si la tarea es bugfix: ¿el `Root cause:` documentado en `impl_<feature>.md` matchea con el fix?
+- **Trazabilidad SDD** (solo si existe `{{sdd.specsDir}}/<feature>/tasks.md`): cada `R<n>` del lote está cubierto por ≥1 test que lo referencia con `// Covers: R<n>`. Un `R<n>` del lote sin test trazable → `SPEC_MISS`.
 - ¿La UI fue validada manualmente (según informe del implementer)? Si NO y el cambio toca pantallas → escalar a humano.
 
 **Veredicto parcial:**
@@ -146,6 +147,7 @@ CHANGES_REQUESTED -> .claude/progress/review_<feature>.md
 - ❌ Nunca apruebes si el código nuevo **agrega errores o warnings nuevos** vs baseline.
 - ❌ Nunca apruebes código nuevo con `any` explícito o implícito sin `// any justificado: <razón>` válido.
 - ❌ Nunca apruebes si la UI no fue validada manualmente y el cambio toca pantallas.
+- ❌ En features SDD (con `tasks.md`), nunca apruebes si algún `R<n>` del lote no tiene un test trazable que lo cubra.
 - ❌ Nunca editas el código. Solo señalas qué falla y dónde.
 - ✅ Sé concreto: cita `archivo:línea`. Nada de feedback genérico.
 

package/dist/assets/core/core-assets/lib-skills/apollo-client.md

@@ -0,0 +1,62 @@
+---
+name: apollo-client
+description: GraphQL con Apollo Client — hooks, fetchPolicy, normalización de caché y actualización tras mutaciones. Aplica al escribir queries/mutations, configurar la caché o los links.
+type: reference
+---
+
+# Apollo Client — el patrón canónico
+
+Lecturas declarativas con hooks, caché **normalizada por id**, y la UI se mantiene en sync actualizando la caché tras cada mutación. Los concerns de red/auth viven en los links, no en los componentes.
+
+## Cuándo usar este skill
+
+Al escribir una query/mutation, configurar `InMemoryCache`/`typePolicies`, o la cadena de `links`.
+
+## Hooks y aislamiento
+
+`useQuery` (lectura al montar), `useLazyQuery` (bajo demanda, retorna `execute`), `useMutation` (retorna `[mutate, { data, loading, error }]`). Aísla los hooks en una capa (hook + adapter): el componente recibe un **modelo de dominio**, no el shape crudo de GraphQL.
+
+```ts
+export function useReport(id: string) {
+  const { data, loading, error } = useGetReportQuery({ variables: { id }, fetchPolicy: 'cache-first' });
+  return { report: data?.report ? adaptReport(data.report) : null, loading, error };
+}
+```
+
+## fetchPolicy según el dato
+
+- `cache-first` (default) — catálogos/detalles ya traídos por una lista.
+- `cache-and-network` — feeds que cambian seguido (render instantáneo + refresh).
+- `network-only` — sesión/bootstrap, datos críticos.
+- Evita `no-cache` salvo PII estricta que no deba tocar disco.
+
+## Normalización de caché
+
+```ts
+const cache = new InMemoryCache({ typePolicies: { Report: { keyFields: ['id'] } } });
+```
+
+Con `keyFields`, Apollo identifica entidades por id y deduplica/actualiza solo. Sin normalización, las listas y detalles se desincronizan.
+
+## Reglas duras
+
+1. **Tras una mutation, actualiza la caché:** `update(cache, { data })` (`cache.modify`/`evict`/`writeQuery`) o `refetchQueries`. Nunca dejes la UI desincronizada.
+2. **`optimisticResponse`** para UI instantánea (resultado temporal con `__typename` + id ficticio); `update` reconcilia al llegar la respuesta real.
+3. **No over-fetch:** pide solo los campos que el componente usa; apóyate en **fragments con colocation** (el fragmento junto al componente que lo consume). Regenera tipos (codegen) tras editar `.graphql`.
+4. **Maneja `loading` y `error` siempre.** Separa error de red (banner genérico, resuelto en un `errorLink`) de error de negocio (`graphQLErrors`, copy según `extensions.code`).
+5. **Paginación** con `fetchMore` + `updateQuery`, o `relayStylePagination`/merge en `typePolicies`.
+6. Red/auth/upload en la cadena de **links** (auth → error → upload), no en cada componente.
+
+```ts
+const [createReport] = useCreateReportMutation({
+  optimisticResponse: { createReport: { __typename: 'Report', id: 'temp', ...fields } },
+  update(cache) { cache.evict({ fieldName: 'reports' }); }, // invalida la lista
+});
+```
+
+## Antes de declarar listo
+
+- Hooks aislados en capa (hook + adapter); el componente ve el modelo de dominio.
+- Caché normalizada por `keyFields`; mutaciones actualizan/invalidan la caché.
+- `fetchPolicy` elegido por tipo de dato; `loading`/`error` manejados.
+- `{{qualityGate.fast}}` en verde.

package/dist/assets/core/core-assets/lib-skills/stripe.md

@@ -0,0 +1,84 @@
+---
+name: stripe
+description: Integración de pagos con Stripe — selección de API (Checkout/Payment/Setup Intents), claves restringidas, idempotencia y verificación de webhooks. Aplica al crear cobros, checkout, suscripciones o handlers de webhook de Stripe.
+type: reference
+---
+
+# Stripe — el patrón canónico
+
+Alineado con la skill oficial `stripe-best-practices`. El server manda: la lógica de cobro y las claves `sk_`/`rk_` viven en el backend; el cliente solo toca la publishable key.
+
+## Cuándo usar este skill
+
+Al crear un cobro, checkout, suscripciones, o un handler de webhook de Stripe.
+
+## Qué API usar
+
+| Caso | API |
+|---|---|
+| Pago único on-session | **Checkout Session** |
+| Form propio embebido | Checkout Session + **Payment Element** |
+| Guardar método de pago (sin cobrar) | **Setup Intent** |
+| Suscripciones / recurrente | **Billing** + Checkout Session |
+| Marketplace / plataforma | **Accounts v2** (`/v2/core/accounts`) |
+| Impuestos (IVA/VAT/GST) | **Stripe Tax** + Registrations API |
+
+**Nunca uses la Charges API** (legacy): si te topas con ella, migra a Checkout Session o Payment Intent — no le agregues features.
+
+## Seguridad de claves
+
+Tres tipos: **publishable** (`pk_`, cliente), **secret** (`sk_`, server) y **restricted** (`rk_`, server con scope acotado). Prefiere **`rk_` sobre `sk_`**. Las claves van en env vars; la `sk_`/`rk_` **jamás** entra al bundle del cliente.
+
+## El patrón (server-side)
+
+```ts
+const stripe = new Stripe(process.env.STRIPE_SECRET_KEY!, {
+  apiVersion: '2026-06-24.dahlia', // fija la última; no dejes el default de la cuenta
+});
+
+// idempotencyKey: reintentar la misma request NO crea un segundo cobro.
+const session = await stripe.checkout.sessions.create(
+  {
+    mode: 'payment',
+    line_items: [{ price: priceId, quantity: 1 }],
+    success_url: `${base}/ok?session_id={CHECKOUT_SESSION_ID}`,
+    cancel_url: `${base}/cancel`,
+    // Sin payment_method_types: deja los dynamic payment methods del Dashboard.
+  },
+  { idempotencyKey: `checkout:${orderId}` },
+);
+```
+
+## Webhooks
+
+El estado real llega por webhook, no por el `success_url`. Verifica **siempre** la firma y hazlo idempotente:
+
+```ts
+// rawBody = cuerpo crudo, NO el JSON parseado (el body-parser rompe la firma).
+const event = stripe.webhooks.constructEvent(rawBody, sig, process.env.STRIPE_WEBHOOK_SECRET!);
+if (await alreadyProcessed(event.id)) return res.sendStatus(200); // el event.id puede repetirse
+```
+
+Responde `2xx` rápido; el trabajo pesado va a una cola.
+
+## Gotchas que muerden
+
+- **`payment_method_types` fijo** apaga los dynamic payment methods del Dashboard. Omítelo (única excepción: Terminal → `['card_present']`); para restringir usa `payment_method_configurations` o `excluded_payment_method_types`.
+- **`automatic_tax: { enabled: true }` sin registro fiscal activo** cobra **cero** impuesto pareciendo habilitado — el error más común y silencioso. Verifica el registro antes.
+- **Montos en la unidad mínima y enteros** (centavos: $10.00 → `1000`). Nunca floats.
+
+## Reglas duras
+
+1. Cobro y claves `sk_`/`rk_` solo en el server (env vars); el cliente solo con `pk_`. Prefiere `rk_` sobre `sk_`.
+2. `apiVersion` fija a la última; nada de default implícito.
+3. Charges API prohibida en código nuevo.
+4. `idempotencyKey` en toda request de creación que mueva dinero.
+5. Webhooks: firma verificada con `rawBody` + handler idempotente por `event.id`.
+6. Sin `payment_method_types` salvo Terminal.
+
+## Antes de declarar listo
+
+- Ninguna `sk_`/`rk_` quedó en el cliente ni en el repo.
+- Cada cobro lleva `idempotencyKey`; el pago se confirma por webhook (firma + idempotente), no por el redirect.
+- Si hay impuestos: registro fiscal activo verificado.
+- `{{qualityGate.fast}}` en verde.

package/dist/assets/core/core-assets/lib-skills/tamagui.md

@@ -0,0 +1,61 @@
+---
+name: tamagui
+description: UI con Tamagui v4 — styled() + variants, tokens de tema y qué mantiene contento al compiler. Aplica al crear componentes con estilo, definir el design system o tocar la config/tema.
+type: reference
+---
+
+# Tamagui — el patrón canónico
+
+Componentes con `styled()` y **variants**; estilos por **tokens** de tema (`$`), no por valores hardcodeados. El compiler extrae en build lo que sea estático — el trabajo es no romperlo.
+
+## Cuándo usar este skill
+
+Al crear un componente con estilo, definir tokens/themes del design system, o tocar `createTamagui`.
+
+## Config
+
+```tsx
+import { defaultConfig } from '@tamagui/config/v4'
+import { createTamagui, styled, View } from 'tamagui'
+
+export const config = createTamagui({
+  ...defaultConfig,
+  settings: { ...defaultConfig.settings, styleCompat: 'react-native' },
+})
+declare module 'tamagui' { interface TamaguiCustomConfig extends typeof config {} }
+```
+
+El `declare module` da props tipadas y autocompletado en todo el proyecto. Elige **un solo paquete de import** (`tamagui` o `@tamagui/core`), no ambos.
+
+## styled() + variants (no condicionales inline)
+
+```tsx
+const Box = styled(View, {
+  variants: {
+    tone: { danger: { bg: '$red10' }, ok: { bg: '$green10' } },
+  } as const,
+})
+```
+
+Prefiere variants sobre `bg={isError ? '$red10' : '$green10'}`: los valores runtime rompen el flattening del compiler. Usa `as const` en `variants`.
+
+## Reglas duras
+
+1. **Tokens en props** (`bg="$blue10"`, `p="$4"`, `color="$color"`), nunca `style={{...}}` con variables ni `StyleSheet` de RN (no resuelven tokens).
+2. **No rompas el compiler:** evita valores runtime (`width={w*0.5}`), funciones inline y spreads no deterministas en props de estilo. Muévelos a variants.
+3. **Themes semánticos** (`success`/`warning`/`error`) vía `createThemes`; colorea por contexto con `<Theme name="...">`, no con hex hardcodeado. Al definir el theme, sin `$`; al consumir, con `$`.
+4. **Orden de props = prioridad:** lo que va después de un `{...spread}` gana; en `variants`, la primera listada gana.
+5. **Animaciones:** driver `react-native-reanimated` en native; anima con `enterStyle`/`exitStyle`, `pressStyle`/`hoverStyle` y `AnimatePresence` para salidas.
+6. **Ramifica plataforma con `Adapt`** (Dialog/Sheet), no con `Platform.OS`.
+7. Al envolver un `styled`, usa `.styleable()` para preservar variantes.
+
+## Dev vs prod
+
+`disableExtraction: true` en dev (HMR más rápido); extracción completa en prod. Ignora `.tamagui/` en git.
+
+## Antes de declarar listo
+
+- Estilos por tokens `$`, no hardcodeados ni `style` inline con variables.
+- Lógica condicional de estilo en `variants`, no inline (compiler-friendly).
+- Un solo paquete de import; `declare module` registrado.
+- `{{qualityGate.fast}}` en verde.

package/dist/assets/core/core-assets/lib-skills/zustand.md

@@ -0,0 +1,70 @@
+---
+name: zustand
+description: Estado global con Zustand v5 — selectores para evitar re-renders, acciones en el store, slices. Aplica al crear un store, leer estado en un componente o mover estado compartido fuera de Context.
+type: reference
+---
+
+# Zustand — el patrón canónico
+
+Un store con estado y acciones juntos; los componentes se suscriben con un **selector**, no al store entero. Así solo re-renderizan cuando cambia lo que leen.
+
+## Cuándo usar este skill
+
+Al crear un store, leer estado en un componente, o mover estado compartido/mutable frecuente fuera de Context (que re-renderiza todo el árbol del Provider).
+
+## El patrón
+
+```ts
+import { create } from "zustand";
+import { useShallow } from "zustand/react/shallow";
+
+const useUserStore = create<UserStore>((set) => ({
+  user: null,
+  loading: false,
+  fetchUser: async (id) => {
+    set({ loading: true });
+    try {
+      const user = await api.getUser(id);
+      set({ user, loading: false });
+    } catch {
+      set({ error: "fetch failed", loading: false });
+    }
+  },
+}));
+
+const name = useUserStore((s) => s.user?.name);            // un campo → sin re-render de más
+const { user, loading } = useUserStore(                    // varios campos → useShallow
+  useShallow((s) => ({ user: s.user, loading: s.loading })),
+);
+```
+
+## Reglas duras
+
+1. **Siempre un selector.** `const s = useStore()` (sin selector) re-renderiza ante cualquier cambio del store. Selecciona el campo que usas.
+2. **Varios campos → `useShallow`.** Devolver un objeto/array nuevo sin `useShallow` re-renderiza en cada render por identidad nueva.
+3. **Acciones dentro del store**, no en el componente; usa `set((state) => ...)` cuando el update depende del valor actual.
+4. **Estado async con su `loading`/`error` en el store**, no suelto en el componente.
+5. **Nada de un único store global gigante.** Separa por dominio (user, cart, settings) con el **slices pattern**: cada slice es una factory `(set) => ({...})` y el store se compone por spread; el tipo es la intersección.
+6. Fuera de React: `useStore.getState()` / `setState()` / `subscribe()` — no hooks.
+
+```ts
+const useStore = create<UserSlice & CartSlice>()((...a) => ({
+  ...createUserSlice(...a),
+  ...createCartSlice(...a),
+}));
+```
+
+## Middlewares
+
+`persist` (hidratar desde storage, con `name`), `immer` (updates anidados mutando "directo"), `devtools` (`{ name }`). Se anidan envolviendo el creador.
+
+## Zustand vs Context
+
+Context es para inyección **estable** (theme, config, i18n). Para estado compartido que cambia seguido, Zustand — evita el re-render masivo del Provider.
+
+## Antes de declarar listo
+
+- Cada componente lee con selector; multi-campo con `useShallow`.
+- Acciones y estado async (con loading/error) viven en el store.
+- Stores separados por dominio; nada de un mega-store global.
+- `{{qualityGate.fast}}` en verde.

package/dist/assets/core/core-assets/managed/sdd.md

@@ -0,0 +1,21 @@
+## Spec Driven Development (SDD)
+
+Para trabajo de alcance real —una feature nueva completa, cambios en auth/seguridad/permisos, adapters o modelos con datos sensibles, o scope > ~2 días— el trabajo arranca de un spec, no de código. Bugfixes de UI, un campo nuevo en un form existente, refactors aislados o ajustes de copy NO usan SDD: se trabajan directo.
+
+**Estructura:** `{{sdd.specsDir}}/<feature>/{requirements.md, design.md, tasks.md}`.
+- `requirements.md` — qué debe hacer, en formato EARS (ver abajo), cada requisito con id `R<n>`.
+- `design.md` — cómo: arquitectura, componentes afectados, decisiones y trade-offs.
+- `tasks.md` — ejecución en lotes chicos (1-3 tasks); cada task declara los `R<n>` que cubre.
+
+**EARS (Easy Approach to Requirements Syntax)** — siempre `DEBE`/`NO DEBE`, una acción por requisito, id `R<n>`:
+- Ubicuo: `El sistema DEBE <X>.`
+- Evento: `CUANDO <Y>, el sistema DEBE <X>.`
+- Estado: `MIENTRAS <Y>, el sistema DEBE <X>.`
+- Opcional: `DONDE <Y>, el sistema DEBE <X>.`
+- No deseado: `SI <Y> ENTONCES el sistema DEBE <X>.`
+
+**Trazabilidad obligatoria (`R<n>` ↔ test):** cada `R<n>` se cubre con ≥1 test, y cada test SDD referencia sus requisitos con un comentario `// Covers: R<n>, R<m>` arriba del caso. Sin trazabilidad completa la feature no está done. Habilita verificación inversa (test → requisito) al refactorizar.
+
+**El tracking vive en el spec, no en el harness:** cuando existe `tasks.md`, ese es el tablero. NO uses `TaskCreate` para esas tasks — duplicar el seguimiento en la TaskList produce drift entre el spec y las tasks. Ignorar el reminder de `TaskCreate` en sesiones SDD es lo esperado.
+
+**Flujo con agentes:** el `leader` descompone `tasks.md` en lotes; el `implementer` ejecuta un lote y escribe los tests trazables a `R<n>`; el `reviewer` aprueba/rechaza verificando la trazabilidad `R<n>↔test` como gate, no como sugerencia. Cada agente escribe su resultado a disco y devuelve solo la referencia (regla anti-teléfono-descompuesto).

package/dist/assets/core/core-assets/presets/react-native-expo/managed/stack.md

@@ -0,0 +1,5 @@
+## Stack — React Native + Expo
+
+App móvil con Expo (SDK actual) + React Native. Navegación con `expo-router`/`native-stack`; estilos y capas nativas por `expo-*` (no equivalentes bare). El trabajo pesado —listas, animaciones, gestos— corre en el **UI thread**, no en el JS thread.
+
+Regla de oro: cada render de una lista o pantalla toca el puente JS↔nativo. Mantén las referencias estables y el trabajo fuera del render. Aplica `rn-performance` para listas/animaciones/re-renders y `expo-runtime` para safe-area, teclado, edge-to-edge y EAS/prebuild.

package/dist/assets/core/core-assets/presets/react-native-expo/skills/expo-runtime.md

@@ -0,0 +1,46 @@
+---
+name: expo-runtime
+description: Runtime de Expo — safe areas, teclado, edge-to-edge, prebuild y EAS. Aplica al maquetar pantallas, tocar config nativa (app.config/plugins) o configurar builds.
+type: reference
+---
+
+# Expo — runtime nativo
+
+La config nativa se declara, no se edita a mano. Las pantallas respetan las zonas seguras del dispositivo, no valores hardcodeados.
+
+## Safe areas
+
+- **`react-native-safe-area-context`** con `useSafeAreaInsets()`. Nunca hardcodees `paddingTop: 44`. Centraliza en un componente `Screen` en vez de rodar tu propio `SafeAreaView` por pantalla.
+- **Insets asimétricos por plataforma:** en Android respeta `bottom` (barra de gestos), en iOS lo maneja el OS → típico `["top","bottom"]` en Android, `["top"]` en iOS.
+- En un scroll raíz, `contentInsetAdjustmentBehavior="automatic"` deja que iOS maneje los insets nativamente (contenido detrás del status bar).
+
+## Teclado
+
+- **`behavior` por plataforma:** `KeyboardAvoidingView behavior={isIos ? "padding" : "height"}`.
+- Con **`react-native-keyboard-controller`** (`KeyboardAwareScrollView`), NO lo envuelvas además en `KeyboardAvoidingView` — doble offset. Un solo mecanismo por pantalla.
+
+## Edge-to-edge (Android 15+)
+
+- `edgeToEdgeEnabled: true` + **`react-native-edge-to-edge`**. Estila las barras con su `SystemBars`, NO con `expo-status-bar` cuando edge-to-edge está activo.
+
+## Config nativa: declarar, no editar
+
+- **Prebuild** (`ios/` commiteado, `android/` generado) o managed. En cualquier caso **no edites `ios/`/`android/`, `Info.plist` ni `AndroidManifest.xml` a mano** — se regeneran. Cambia vía `app.json`/`app.config.ts` o un config plugin en `plugins/`.
+- Tras tocar `app.config`/plugins, corre `expo prebuild --clean` (o el script del repo).
+- Permisos: `ios.infoPlist` / `android.permissions`, o deja que el plugin del módulo (`expo-image-picker`, `expo-location`) inyecte su purpose string — no lo dupliques.
+- Instala capas nativas con **`expo install`** (pinea la versión del SDK); `expo install --fix` re-pinea. Prefiere módulos `expo-*` sobre equivalentes bare.
+
+## EAS y env
+
+- Perfiles en `eas.json` (`development`, `preview`, `production`). Las env vars requeridas por builds nativos van en cada perfil.
+- **Runtime:** `process.env.EXPO_PUBLIC_*` para lo público; secrets (`google-services.json`, APNs `.p8`) por **EAS secrets**, nunca commiteados.
+
+## Gotcha de build
+
+- **Reanimated/Worklets:** `react-native-worklets/plugin` debe ser el **último** plugin de `babel.config.js`.
+
+## Antes de declarar listo
+
+- Insets vía `useSafeAreaInsets`, no valores fijos; un solo mecanismo de teclado por pantalla.
+- Cambios nativos vía `app.config`/plugin (no en `ios/`/`android/`); `expo prebuild --clean` corrido si tocaste config.
+- Ningún secret commiteado. `{{qualityGate.fast}}` en verde.

package/dist/assets/core/core-assets/presets/react-native-expo/skills/rn-performance.md

@@ -0,0 +1,50 @@
+---
+name: rn-performance
+description: Performance de React Native — listas virtualizadas, re-renders, animaciones en UI thread. Aplica al crear listas, animaciones/gestos, o al optimizar pantallas que se sienten lentas.
+type: reference
+---
+
+# React Native — performance
+
+El costo real vive en el puente JS↔nativo y en el JS thread. La meta: menos renders, referencias estables, y el trabajo pesado en el UI thread.
+
+## Listas (lo más crítico)
+
+- **Virtualiza siempre.** Nunca `ScrollView` + `.map()` para datos: monta todo. Usa `FlashList`/`FlatList` con `keyExtractor` y `estimatedItemSize`/`getItemLayout`. Con layouts heterogéneos, `getItemType` para pools de reciclaje separados.
+- **`data` estable.** Nada de `.map()`/`.filter()` sobre `data` en cada render: crea referencias nuevas y re-renderiza toda la lista visible en cada keystroke. Pasa el array estable y transforma dentro del ítem.
+- **`renderItem` sin inline.** `item={{...}}` o `style={{...}}` rompen el `memo()`. Pasa primitivos o estilos hoisteados a módulo. Hoistea también los callbacks (una instancia que reciba el `id`), no uno nuevo por ítem.
+- **Ítem ligero y memoizado.** Sin `useQuery` ni cómputo caro dentro; fetch en el padre. `memo()` + solo los campos que usa (`name`, no el objeto entero).
+
+```tsx
+const renderItem = ({ item }: { item: Row }) => <RowItem row={item} />;
+<FlashList data={rows} renderItem={renderItem} keyExtractor={(r) => r.id}
+  getItemType={(r) => r.type} estimatedItemSize={80} />
+```
+
+## Re-renders
+
+- **Minimiza estado, deriva el resto** en render (no `useState`+`useEffect`).
+- **Selectores de store** (`useStore(s => s.has(id))`) sobre `useContext` (Context re-renderiza ante cualquier cambio).
+- Con **React Compiler** ON, `memo`/`useCallback` manuales sobran — pero la estabilidad de referencias de objetos sigue importando.
+
+## Animaciones y gestos
+
+- **Anima solo `transform` y `opacity`** (GPU). Nunca `width/height/top/margin`: recalculan layout por frame. Colapsar = `scaleY`, no `height`.
+- **Gestos en UI thread** con Reanimated worklets (`useSharedValue`/`useAnimatedStyle`, `GestureDetector`), no `onPressIn/onPressOut` con round-trip al JS thread. `runOnJS` para saltar a JS.
+- **Scroll con `useAnimatedScrollHandler`** + shared value, jamás en `useState` (render thrashing).
+
+## Imágenes y misc
+
+- **`expo-image`** para todo (caché memoria/disco, `contentFit`, `recyclingKey`). En listas, pide al CDN el tamaño real (`?w=200` a 2x), no full-res para un thumbnail.
+- Hoistea formatters `Intl` a nivel de módulo. Difiere trabajo pesado con `InteractionManager.runAfterInteractions`.
+
+## Evita crashes de render
+
+- **Nunca `{value && <C/>}` con falsy** (`""`/`0` crashea en release): usa `!!value &&` o ternario `? : null`.
+- Todo string va dentro de `<Text>`.
+
+## Antes de declarar listo
+
+- Listas virtualizadas con `keyExtractor` + `estimatedItemSize`; `renderItem` y sus props estables.
+- Animaciones/gestos en UI thread; nada de layout animado por frame.
+- `{cond && …}` sin falsy crudo. `{{qualityGate.fast}}` en verde.

package/dist/assets/core/core-assets/presets/react-native-expo.json

@@ -0,0 +1,28 @@
+{
+  "$schema": "https://navori.dev/schema/navori.preset.v1.json",
+  "id": "react-native-expo",
+  "displayName": "React Native + Expo app",
+  "extends": "core",
+  "extras": {
+    "managed": [
+      {
+        "id": "stack-react-native-expo",
+        "relPath": "presets/react-native-expo/managed/stack.md"
+      }
+    ],
+    "agents": [],
+    "skills": [
+      {
+        "id": "rn-performance",
+        "relPath": "presets/react-native-expo/skills/rn-performance.md",
+        "destRelPath": ".claude/skills/rn-performance.md"
+      },
+      {
+        "id": "expo-runtime",
+        "relPath": "presets/react-native-expo/skills/expo-runtime.md",
+        "destRelPath": ".claude/skills/expo-runtime.md"
+      }
+    ],
+    "hooks": []
+  }
+}