theus-cli-linux-arm64 1.2.2 → 1.3.0

package/vendor/theus-arsenal/rules/react/security.md

@@ -1,180 +0,0 @@
----
-paths:
-  - "**/*.tsx"
-  - "**/*.jsx"
-  - "**/components/**/*.ts"
-  - "**/app/**/*.ts"
-  - "**/pages/**/*.ts"
----
-# Seguridad en React
-
-> Este archivo extiende [typescript/security.md](../typescript/security.md) y [common/security.md](../common/security.md) con contenido específico de React.
-
-## XSS vía `dangerouslySetInnerHTML`
-
-CRÍTICO. El nombre de la prop es intimidante a propósito — trata cada uso como un alto obligatorio en la revisión de código.
-
-```tsx
-// CRÍTICO: entrada de usuario sin sanitizar
-<div dangerouslySetInnerHTML={{ __html: userBio }} />
-
-// Opciones CORRECTAS:
-// 1. Renderizar como texto
-<div>{userBio}</div>
-
-// 2. Renderizar markdown parseado con una librería que sanitiza
-<ReactMarkdown>{userBio}</ReactMarkdown>
-
-// 3. Si se requiere HTML crudo, sanitizar primero con DOMPurify
-import DOMPurify from "isomorphic-dompurify";
-<div dangerouslySetInnerHTML={{ __html: DOMPurify.sanitize(userBio) }} />
-```
-
-Checklist de auditoría para cada llamada a `dangerouslySetInnerHTML`:
-
-- ¿La entrada está siempre bajo nuestro control? Documenta la fuente.
-- Si deriva del usuario: ¿se sanitiza en el **mismo punto de llamada**? (Sanitizar en la frontera de la API solo es aceptable si todos los consumidores están verificados.)
-- ¿La configuración del sanitizador usa lista de permitidos de etiquetas, no lista de bloqueados?
-
-## Esquemas de URL inseguros
-
-Las URLs `javascript:` y `data:` en `href`, `src` y `xlink:href` ejecutan código arbitrario.
-
-```tsx
-// CRÍTICO: inyección de URL javascript:
-<a href={user.website}>Visit</a>   // si user.website = "javascript:alert(1)"
-
-// CORRECTO: validar el esquema
-function safeUrl(url: string): string | undefined {
-  try {
-    const parsed = new URL(url);
-    if (["http:", "https:", "mailto:"].includes(parsed.protocol)) return url;
-  } catch {
-    return undefined;
-  }
-  return undefined;
-}
-<a href={safeUrl(user.website)}>Visit</a>
-```
-
-React advierte sobre URLs `javascript:` en `href` en modo desarrollo, pero no las bloquea en runtime. Las URLs `data:` y otros esquemas también se cuelan. Valida siempre.
-
-## `target="_blank"` sin `rel`
-
-Un `<a target="_blank">` sin `rel="noopener noreferrer"` permite que la página destino acceda a `window.opener` y ejecute secuestros de navegación.
-
-```tsx
-// INCORRECTO
-<a href={externalUrl} target="_blank">External</a>
-
-// CORRECTO
-<a href={externalUrl} target="_blank" rel="noopener noreferrer">External</a>
-```
-
-Los navegadores modernos aplican `noopener` por defecto con `target="_blank"`, pero no dependas de los valores por defecto del navegador — sé explícito.
-
-## Validación de entrada en Server Actions
-
-Las Server Actions (`"use server"`) corren con el mismo nivel de confianza que un endpoint de API público. Valida cada entrada.
-
-```tsx
-"use server";
-import { z } from "zod";
-
-const Input = z.object({
-  email: z.string().email(),
-  age: z.number().int().min(0).max(120),
-});
-
-export async function updateUser(_state: unknown, formData: FormData) {
-  const parsed = Input.safeParse({
-    email: formData.get("email"),
-    age: Number(formData.get("age")),
-  });
-  if (!parsed.success) return { error: parsed.error.flatten() };
-  // ...
-}
-```
-
-- Autentica dentro de la acción — no confíes en el gate de ruta del lado cliente
-- Autoriza: confirma que el usuario actual tiene permiso sobre el registro específico que está mutando
-- Aplica rate limiting a las acciones sensibles
-
-## Exposición de secretos vía variables de entorno
-
-Las variables de entorno con prefijo se empaquetan en el cliente. Trátalas como públicas.
-
-| Framework | Prefijo público | Privadas |
-|---|---|---|
-| Next.js | `NEXT_PUBLIC_*` | Todas las demás |
-| Vite | `VITE_*` | `.env` solo del lado servidor |
-| Create React App | `REACT_APP_*`, más `NODE_ENV` y `PUBLIC_URL` | Todas las demás (cualquier variable sin el prefijo `REACT_APP_` es solo del lado servidor) |
-| Remix | Acceso a `process.env` solo en `loader`/`action` | Igual |
-
-```ts
-// CRÍTICO: secreto filtrado al bundle del cliente
-const apiKey = process.env.NEXT_PUBLIC_STRIPE_SECRET_KEY;
-```
-
-Audita en cada PR que toque variables de entorno: ¿sería un problema que esta cadena apareciera en el bundle público?
-
-## Autenticación / autorización
-
-- Nunca guardes sesiones en `localStorage` — accesible para cualquier XSS. Usa cookies httpOnly seguras.
-- Nunca confíes en estado fijado por el cliente para proteger UI sensible. El gating en el JSX evita mostrar, no evita el acceso — la API debe imponerlo.
-- CSRF: la autenticación basada en cookies requiere tokens CSRF o cookies `SameSite=Strict`/`Lax`
-- Usa cookies double-submit o verificación de origen para form actions cuando no uses los valores por defecto del framework
-
-## Content Security Policy (CSP)
-
-Se configura del lado servidor. La CSP mínima aceptable para una app React:
-
-```
-default-src 'self';
-script-src 'self' 'nonce-{REQUEST_NONCE}';
-style-src 'self' 'unsafe-inline';
-img-src 'self' data: https:;
-connect-src 'self' https://api.example.com;
-frame-ancestors 'none';
-```
-
-- Evita `unsafe-inline` y `unsafe-eval` en `script-src`
-- Para SSR con scripts inline (streaming de Next.js, datos de hidratación), usa nonces por petición — tanto Next.js como Remix soportan inyección de nonces
-- `style-src 'unsafe-inline'` suele ser inevitable con librerías CSS-in-JS — documenta el compromiso
-
-## Contaminación de prototipos vía spread de objetos
-
-```tsx
-// INCORRECTO: JSON no confiable esparcido directamente al estado
-const update = await req.json();
-setState({ ...state, ...update });    // el atacante controla __proto__
-
-// CORRECTO: parsear con un esquema, o proteger las claves
-const Allowed = z.object({ name: z.string(), email: z.string().email() });
-const parsed = Allowed.parse(await req.json());
-setState({ ...state, ...parsed });
-```
-
-## Inyección de plantillas en SSR
-
-Al usar `renderToString` o `renderToPipeableStream`:
-
-- Todos los valores renderizados dentro del JSX son escapados por React — seguro
-- Los valores pasados a `dangerouslySetInnerHTML` NO se escapan — mismas reglas que en el cliente
-- El HTML construido manualmente alrededor de la salida de React debe escaparse o sanitizarse — nunca concatenes entrada de usuario en la plantilla HTML circundante
-
-## Componentes de terceros
-
-- Ejecuta `npm audit` antes de añadir cualquier librería de UI
-- Verifica que la librería no use internamente `dangerouslySetInnerHTML` sobre su entrada (p. ej., editores de texto enriquecido)
-- Fija versiones y revisa los changelogs antes de actualizaciones mayores
-- Desconfía de componentes que aceptan cadenas HTML como props
-
-## Exposición de source maps en producción
-
-Los builds de producción deben publicarse sin source maps, o con los source maps subidos a un rastreador de errores (Sentry) y eliminados del bundle público. Los source maps públicos filtran lógica interna y la estructura de archivos.
-
-## Soporte con agentes
-
-- Usa el agente `revisor-seguridad` para auditorías de seguridad integrales en toda la base de código
-- Usa el agente `revisor-react` para patrones específicos de React y las reglas anteriores durante la revisión activa de código

package/vendor/theus-arsenal/rules/react/testing.md

@@ -1,208 +0,0 @@
----
-paths:
-  - "**/*.test.tsx"
-  - "**/*.test.jsx"
-  - "**/*.spec.tsx"
-  - "**/*.spec.jsx"
-  - "**/__tests__/**/*.ts"
-  - "**/__tests__/**/*.tsx"
----
-# Testing en React
-
-> Este archivo extiende [typescript/testing.md](../typescript/testing.md) y [common/testing.md](../common/testing.md) con contenido específico de React.
-
-## Elección de librería
-
-- **React Testing Library (RTL)** — el estándar para pruebas de componentes. Prueba el comportamiento a través del DOM renderizado.
-- **Vitest** — runner preferido para proyectos nuevos basados en Vite. Más rápido que Jest, ESM nativo, misma API.
-- **Jest** — sigue siendo el valor por defecto en proyectos Next.js / CRA. RTL funciona de forma idéntica.
-- **Playwright Component Testing** — cuando las pruebas de componentes necesitan un motor de navegador real (animación, layout, eventos complejos)
-- **Cypress Component Testing** — runner alternativo de componentes en navegador real
-
-Elige un solo runner de pruebas de componentes por proyecto — no mezcles RTL + Playwright CT en el mismo repositorio.
-
-## Principio central
-
-Prueba lo que el usuario ve y hace, no detalles de implementación.
-
-- Consulta primero por rol accesible, luego por label, luego por texto — recurre a `data-testid` solo cuando nada más encaja
-- Nunca hagas aserciones sobre estado interno, props pasadas a hijos ni sobre qué hooks se llamaron
-- Refactorizar sin romper las pruebas = la prueba probaba comportamiento; esa es la meta
-
-## Prioridad de queries
-
-RTL expone queries en tres familias. Usa este orden de prioridad de arriba hacia abajo:
-
-1. **Accesibles para todos**
-   - `getByRole(role, { name })` — opción principal
-   - `getByLabelText` — para inputs de formulario
-   - `getByPlaceholderText` — cuando no hay label disponible (y añade un label)
-   - `getByText` — para texto no interactivo
-   - `getByDisplayValue` — para campos de formulario con un valor actual
-
-2. **Queries semánticas**
-   - `getByAltText` — para imágenes
-   - `getByTitle` — último recurso, bajo valor de accesibilidad
-
-3. **Test IDs**
-   - `getByTestId("some-id")` — solo como vía de escape, cuando nada de lo anterior funciona
-
-`getBy*` lanza excepción cuando no hay coincidencia. `queryBy*` devuelve null (úsalo para afirmar ausencia). `findBy*` devuelve una promesa (úsalo para lo asíncrono).
-
-## Interacción del usuario
-
-Prefiere `userEvent` sobre `fireEvent`. `userEvent` simula secuencias reales del navegador (focus, keydown, beforeinput, input, keyup) — `fireEvent` despacha un único evento sintético.
-
-```tsx
-import userEvent from "@testing-library/user-event";
-
-test("submits the form", async () => {
-  const user = userEvent.setup();
-  render(<UserForm onSubmit={handleSubmit} />);
-
-  await user.type(screen.getByLabelText("Email"), "user@example.com");
-  await user.click(screen.getByRole("button", { name: /save/i }));
-
-  expect(handleSubmit).toHaveBeenCalledWith({ email: "user@example.com" });
-});
-```
-
-- Usa siempre `await` en las llamadas a `userEvent` — son asíncronas
-- Llama a `userEvent.setup()` una vez al inicio de cada prueba y reutiliza el `user` devuelto
-
-## Aserciones asíncronas
-
-```tsx
-// INCORRECTO: query síncrona para contenido renderizado de forma asíncrona
-expect(screen.getByText("Loaded")).toBeInTheDocument();   // lanza — aún no está en el DOM
-
-// CORRECTO: findBy* (devuelve una promesa, reintenta)
-expect(await screen.findByText("Loaded")).toBeInTheDocument();
-
-// CORRECTO: waitFor para aserciones que no son sobre elementos
-await waitFor(() => expect(saveSpy).toHaveBeenCalled());
-```
-
-- `findBy*` para la aparición asíncrona de elementos
-- `waitFor` para expectativas asíncronas sobre efectos secundarios u otros matchers
-- Nunca `setTimeout` + aserción — es flaky
-
-## Mocking de red con MSW
-
-Usa Mock Service Worker para cualquier prueba que toque una frontera de red. MSW opera en la capa de red, por lo que el componente, los hooks y la librería de fetch se comportan como en producción.
-
-```tsx
-// configuración de la prueba
-import { setupServer } from "msw/node";
-import { http, HttpResponse } from "msw";
-
-const server = setupServer(
-  http.get("/api/users/:id", ({ params }) =>
-    HttpResponse.json({ id: params.id, name: "Alice" }),
-  ),
-);
-
-beforeAll(() => server.listen());
-afterEach(() => server.resetHandlers());
-afterAll(() => server.close());
-```
-
-Sobrescritura por prueba:
-
-```tsx
-test("renders error on 500", async () => {
-  server.use(http.get("/api/users/:id", () => new HttpResponse(null, { status: 500 })));
-  render(<UserPage id="1" />);
-  expect(await screen.findByText(/something went wrong/i)).toBeInTheDocument();
-});
-```
-
-## Evita los snapshot tests para componentes
-
-Los snapshots de la salida renderizada son frágiles, difíciles de revisar y los revisores los aprueban sin mirar. Úsalos solo para:
-
-- Serialización pura de datos (p. ej., un transformador que produce una cadena estable)
-- Detectar regresiones no intencionadas en salida no visual
-
-Para regresión visual de componentes, usa capturas de Playwright / Cypress / Percy — diffs visuales reales, no diffs del DOM.
-
-## Helpers de configuración de pruebas
-
-Envuelve los providers una sola vez:
-
-```tsx
-function renderWithProviders(ui: React.ReactElement) {
-  return render(
-    <QueryClientProvider client={new QueryClient()}>
-      <ThemeProvider theme={lightTheme}>
-        <Router>{ui}</Router>
-      </ThemeProvider>
-    </QueryClientProvider>,
-  );
-}
-```
-
-Expórtalo desde `test-utils.tsx` y úsalo en todas partes.
-
-## Pruebas de hooks personalizados
-
-Usa `renderHook` de RTL:
-
-```tsx
-import { renderHook, act } from "@testing-library/react";
-
-test("useCounter increments", () => {
-  const { result } = renderHook(() => useCounter());
-  act(() => result.current.increment());
-  expect(result.current.count).toBe(1);
-});
-```
-
-- Envuelve siempre las llamadas que cambian estado en `act`
-- Prueba siempre a través de la API pública del hook, no de la implementación interna
-
-## Aserciones de accesibilidad
-
-```tsx
-import { axe } from "vitest-axe";   // o jest-axe
-
-test("UserCard has no a11y violations", async () => {
-  const { container } = render(<UserCard user={mockUser} />);
-  expect(await axe(container)).toHaveNoViolations();
-});
-```
-
-Ejecuta aserciones de axe en las pruebas de componentes — detecta labels faltantes, mal uso de ARIA y contraste de color (limitado).
-
-## Cuándo recurrir a Playwright / Cypress
-
-Una prueba de componente con RTL + JSDOM no puede:
-
-- Probar layout real (flexbox, grid, renderizado dependiente del viewport)
-- Probar scroll, drag-and-drop, pegado desde el portapapeles
-- Probar animación nativa del navegador ni transiciones CSS
-- Probar interacciones entre frames (iframes, popups)
-
-Para eso, usa Playwright Component Testing o ejecuciones end-to-end con Playwright/Cypress. Consulta la [skill testing-e2e](../../skills/testing-e2e/SKILL.md).
-
-## Objetivos de cobertura
-
-| Capa | Objetivo |
-|---|---|
-| Funciones de utilidad puras | ≥90% |
-| Hooks personalizados | ≥85% |
-| Componentes (presentacionales) | ≥80% — comportamiento, no líneas |
-| Componentes contenedores | ≥70% — caminos felices + estados de error |
-| Páginas (cubiertas aparte con E2E) | Como mínimo un smoke test por ruta |
-
-## Antipatrones
-
-- Aserciones sobre `container.querySelector` — se salta las queries de accesibilidad
-- Aserciones sobre el número de renders — detalle de implementación
-- Mockear hooks de React (`jest.mock("react", ...)`) — refactoriza el componente en su lugar
-- Mockear componentes hijos por defecto — prueba la integración, no el padre en aislamiento
-- Ignorar las advertencias de `act()` manuales — indican bugs reales
-
-## Referencia de skill
-
-Consulta `skills/testing-react/SKILL.md` para ejemplos de pruebas end-to-end, patrones de MSW y andamiaje de pruebas de accesibilidad.

package/vendor/theus-arsenal/rules/react-native/accessibility.md

@@ -1,55 +0,0 @@
----
-paths:
-  - "**/*.ts"
-  - "**/*.tsx"
----
-# Accesibilidad en React Native / Expo
-
-> Extiende el listón de calidad del arsenal a la accesibilidad (a11y). Trátala como requisito de release, no como una ocurrencia tardía.
-> Objetivo: usable con lectores de pantalla (VoiceOver en iOS, TalkBack en Android) y con tamaños de fuente grandes.
-
-## Etiquetado
-
-- Todo elemento interactivo tiene un `accessibilityRole` y un `accessibilityLabel` (o texto hijo legible).
-- Los botones de solo icono DEBEN tener `accessibilityLabel` — no hay texto visible que el lector pueda anunciar.
-- Usa `accessibilityHint` solo cuando la acción no sea obvia; mantenlo corto.
-- Agrupa elementos relacionados con `accessible` en el contenedor para que se anuncien como una sola unidad cuando corresponda.
-
-```tsx
-<Pressable
-  accessibilityRole="button"
-  accessibilityLabel="Eliminar elemento"
-  onPress={onDelete}
->
-  <TrashIcon />
-</Pressable>
-```
-
-## Estado y regiones vivas
-
-- Comunica el estado con `accessibilityState` (p. ej. `{ disabled, selected, checked, expanded }`).
-- Anuncia los cambios asíncronos/transitorios (toasts, errores de validación) vía `accessibilityLiveRegion` (Android) y `AccessibilityInfo.announceForAccessibility` cuando haga falta.
-- Refleja los estados de carga/error/vacío en texto alcanzable por el lector — no solo spinners o color.
-
-## Áreas táctiles y layout
-
-- Área táctil mínima de ~44x44 pt (iOS) / 48x48 dp (Android); usa `hitSlop` para agrandar controles pequeños.
-- Respeta Dynamic Type / el escalado de fuentes — evita alturas fijas que recorten el texto escalado; prueba con el tamaño de fuente de accesibilidad más grande.
-- Honra `prefers-reduced-motion` (`AccessibilityInfo.isReduceMotionEnabled`) — condiciona la animación no esencial.
-
-## Color y contraste
-
-- No transmitas significado solo por color; acompáñalo con texto, icono o forma.
-- Cumple el contraste WCAG AA: 4.5:1 para texto de cuerpo, 3:1 para texto grande y elementos de UI/gráficos con significado.
-- Verifica ambos temas, claro y oscuro.
-
-## Foco y navegación
-
-- Orden de foco lógico; mueve el foco al contenido nuevo (modales, pantallas) al abrir y restáuralo al cerrar.
-- Asegúrate de que los componentes personalizados sean alcanzables y operables con el lector de pantalla, no solo por toque.
-
-## Testing
-
-- Prueba manualmente con VoiceOver y TalkBack en dispositivos reales — las verificaciones automatizadas no lo detectan todo.
-- En los tests de componentes, consulta por rol/etiqueta (ver testing.md) para que la a11y y los tests se refuercen mutuamente.
-- Añade la a11y a la puerta pre-release: los flujos clave superan un recorrido con lector de pantalla.

package/vendor/theus-arsenal/rules/react-native/coding-style.md

@@ -1,71 +0,0 @@
----
-paths:
-  - "**/*.ts"
-  - "**/*.tsx"
----
-# Estilo de código React Native / Expo
-
-> Este archivo extiende [common/coding-style.md](../common/coding-style.md) con contenido específico de React Native / Expo.
-
-## Componentes
-
-- Define las props con una `interface` o `type` con nombre; no uses `React.FC`.
-- Mantén las pantallas delgadas: una pantalla compone hooks + componentes de presentación, no contiene lógica pesada.
-- Un componente por archivo para todo lo reutilizable; co-ubica los subcomponentes privados pequeños.
-- Prefiere componentes de función y hooks. Sin componentes de clase.
-
-```tsx
-interface AvatarProps {
-  uri: string
-  size?: number
-  onPress?: () => void
-}
-
-export function Avatar({ uri, size = 40, onPress }: AvatarProps) {
-  return (
-    <Pressable onPress={onPress}>
-      <Image source={{ uri }} style={{ width: size, height: size, borderRadius: size / 2 }} />
-    </Pressable>
-  )
-}
-```
-
-## Estilos
-
-Elige UN sistema de estilos por proyecto y mantén la consistencia. `StyleSheet.create()` es la opción nativa del framework; las librerías de clases utilitarias (p. ej. NativeWind) son una alternativa común. Esta regla es agnóstica de librería — lo que importa es la consistencia y evitar asignaciones inline.
-
-- StyleSheet: define los estilos con `StyleSheet.create()` a nivel de módulo — nunca construyas objetos de estilo inline dentro del `render`/JSX en rutas calientes (asigna memoria en cada render).
-- Enfoque de clases utilitarias: extrae las cadenas de clases repetidas a constantes compartidas o a un helper de variantes.
-- Nunca hardcodees colores, espaciados o tamaños de fuente crudos repartidos por los archivos. Centraliza los tokens de diseño (archivo de tema o configuración).
-
-```tsx
-// INCORRECTO: objeto de estilo inline recreado en cada render
-<View style={{ padding: 16, backgroundColor: '#fff' }} />
-
-// CORRECTO (StyleSheet)
-const styles = StyleSheet.create({ card: { padding: 16, backgroundColor: '#fff' } })
-<View style={styles.card} />
-
-// CORRECTO (NativeWind)
-<View className="p-4 bg-white" />
-```
-
-## Diferencias de plataforma
-
-- Usa archivos específicos por plataforma (`Component.ios.tsx`, `Component.android.tsx`) para divergencias sustanciales.
-- Usa `Platform.select()` / `Platform.OS` solo para diferencias pequeñas.
-- Gestiona las áreas seguras con `react-native-safe-area-context`; no hardcodees offsets de barra de estado / notch.
-
-## Imports y estructura del proyecto
-
-- Usa el alias de rutas de Expo/TS (p. ej. `@/components/...`) en lugar de cadenas relativas largas.
-- Organiza por feature/dominio, no por tipo. Mantén los archivos enfocados (200-400 líneas típico, 800 máximo).
-
-## Logging
-
-- Nada de `console.log` en el código que se distribuye. Usa un logger y elimina los logs en los builds de producción.
-- Muestra los errores de cara al usuario a través del estado de la UI, no de la consola.
-
-## TypeScript
-
-Aplican todas las reglas de TypeScript de `rules/typescript/` (tipos explícitos en APIs públicas, evitar `any`, Zod para validación, actualizaciones inmutables). Este archivo solo añade la guía específica de RN encima.

package/vendor/theus-arsenal/rules/react-native/hooks.md

@@ -1,28 +0,0 @@
----
-paths:
-  - "**/*.ts"
-  - "**/*.tsx"
----
-# Hooks de React Native / Expo
-
-> Este archivo extiende [common/hooks.md](../common/hooks.md) con guía de automatización específica de React Native / Expo.
-
-Estas son automatizaciones PostToolUse recomendadas para mantener sano el código RN/Expo. Cablealas en tu runtime de hooks (o ejecútalas a mano); adapta los comandos a tu gestor de paquetes.
-
-## Verificaciones PostToolUse sugeridas (al editar *.ts/*.tsx)
-
-- **Verificación de tipos:** `tsc --noEmit` — atrapa los errores de tipos temprano.
-- **Lint:** `npx expo lint` (usa `eslint-config-expo`; el flat config `eslint.config.js` es el valor por defecto desde el SDK 53+).
-- **Formato:** `prettier --write` sobre los archivos modificados.
-
-## Pre-release / periódicas
-
-- `npx expo-doctor` — valida la salud de las dependencias nativas y la configuración de Expo.
-- `npx expo install --check` — mantiene las dependencias nativas alineadas con el SDK de Expo instalado.
-- `npm audit` — escaneo de vulnerabilidades en dependencias.
-
-## Notas
-
-- No ejecutes builds nativos pesados dentro de hooks de edición rápidos; limita los hooks de edición a typecheck/lint/formato.
-- Reserva `eas build` / E2E para comandos explícitos o CI, no para automatización por edición.
-- Mantén todo esto consistente con los controles del runtime de hooks del arsenal (`THEUS_HOOK_PROFILE`, `THEUS_DISABLED_HOOKS`).

package/vendor/theus-arsenal/rules/react-native/patterns.md

@@ -1,88 +0,0 @@
----
-paths:
-  - "**/*.ts"
-  - "**/*.tsx"
----
-# Patrones de React Native / Expo
-
-> Este archivo extiende [common/patterns.md](../common/patterns.md) con patrones específicos de React Native / Expo.
-> Nota: NO instales el conjunto de reglas `web/` en un proyecto React Native — esos patrones asumen el DOM (p. ej. URL como estado) y no aplican aquí.
-
-## Navegación (Expo Router)
-
-Expo Router es el router integrado de Expo basado en archivos (directorio `app/`); React Navigation es la alternativa establecida. Los ejemplos usan Expo Router; los principios aplican en ambos casos.
-
-- Mantén los archivos de ruta (`app/**`) delgados — cablean params + hooks hacia un componente de pantalla que vive en `components/` o `features/`.
-- Tipa los parámetros de ruta; valida los params no confiables (p. ej. de deep links) con Zod antes de usarlos.
-- Usa los helpers de navegación tipados (`useLocalSearchParams`, `Link`, `router.push`).
-- Centraliza la configuración de linking; nunca confíes en parámetros de deep links sin validación.
-
-```tsx
-// app/user/[id].tsx
-import { useLocalSearchParams, router } from 'expo-router'
-import { z } from 'zod'
-
-const Params = z.object({ id: z.string().uuid() })
-
-export default function UserScreen() {
-  // Usa safeParse, no parse: un deep link malformado lanzaría durante el
-  // render y tumbaría la pantalla. Redirige en lugar de lanzar.
-  const parsed = Params.safeParse(useLocalSearchParams())
-  if (!parsed.success) {
-    router.replace('/not-found')
-    return null
-  }
-  return <UserProfile userId={parsed.data.id} />
-}
-```
-
-## Gestión de estado
-
-La regla es mantener estas preocupaciones separadas y no duplicar datos del servidor en stores del cliente. Las herramientas listadas son elecciones comunes, no requisitos — elige lo que encaje en tu proyecto.
-
-| Preocupación | Elecciones comunes |
-|---------|---------|
-| Estado del servidor | una librería de caché de servidor (TanStack Query, SWR) |
-| Estado de cliente/UI | un store ligero (Zustand, Jotai) o Context |
-| Estado de navegación/ruta | params de Expo Router (NO un store global) |
-| Estado de formularios | una librería de formularios (p. ej. React Hook Form) con validación por esquema |
-| Persistencia segura | `expo-secure-store` |
-| Persistencia no segura | `AsyncStorage` / MMKV |
-
-- Deriva valores en lugar de almacenar estado calculado redundante.
-- Mantén el estado global de cliente al mínimo; prefiere `useState` local hasta que compartir sea realmente necesario.
-
-## Fetch de datos
-
-Usa una librería de caché de servidor (TanStack Query, SWR) en lugar de fetch ad hoc dentro de `useEffect`. Los ejemplos usan TanStack Query.
-
-- Enruta las lecturas de servidor a través de la caché (p. ej. `useQuery`) y las mutaciones a través de ella (p. ej. `useMutation`) con invalidación de caché.
-- Valida las respuestas de la API con Zod en la frontera; infiere los tipos desde el esquema. (Zod ya es el valor por defecto de validación en las reglas `typescript/` del arsenal.)
-- Maneja explícitamente los tres estados en la UI: cargando, error, vacío.
-- Usa actualizaciones optimistas para interacciones rápidas: toma un snapshot, aplica, revierte en fallo con feedback visible.
-- Trae los datos independientes en paralelo; evita cascadas de peticiones entre padre e hijo.
-
-```tsx
-function useUser(id: string) {
-  return useQuery({
-    queryKey: ['user', id],
-    queryFn: async () => userSchema.parse(await api.getUser(id)),
-  })
-}
-```
-
-## Listas
-
-- Usa `FlatList`/`SectionList` (o `FlashList` para listas grandes/pesadas) — nunca hagas `.map()` de un array grande dentro de un `ScrollView`.
-- Proporciona un `keyExtractor` estable; memoiza `renderItem`.
-- Pagina o virtualiza los conjuntos de datos largos.
-
-## Hooks personalizados
-
-- Extrae la lógica reutilizable (datos, permisos, APIs del dispositivo) a hooks `use*`.
-- Mantén los efectos secundarios (llamadas al SDK de Expo, suscripciones) dentro de hooks, no en el JSX.
-
-## Asincronía y efectos
-
-- Limpia las suscripciones, temporizadores y listeners en la función de retorno del efecto.
-- Cancela o ignora los resultados asíncronos obsoletos al desmontar para evitar setState tras el desmontaje.

package/vendor/theus-arsenal/rules/react-native/performance.md

@@ -1,45 +0,0 @@
----
-paths:
-  - "**/*.ts"
-  - "**/*.tsx"
----
-# Rendimiento en React Native / Expo
-
-> Este archivo extiende [common/performance.md](../common/performance.md) con contenido específico de React Native / Expo.
-
-## Renderizado
-
-- Memoiza los componentes costosos con `React.memo`; memoiza los callbacks/valores pasados a los hijos con `useCallback`/`useMemo` solo donde prevengan re-renders reales.
-- Mantén el estado del componente local y acotado — subir el estado demasiado alto re-renderiza subárboles grandes.
-- Evita crear objetos/arrays/funciones nuevos inline en las props en rutas calientes; rompen la memoización.
-- Divide las pantallas grandes para que un cambio de estado re-renderice el subárbol más pequeño posible.
-
-## Listas
-
-- Usa `FlatList`/`SectionList`, o `FlashList` (de Shopify) para listas grandes o heterogéneas.
-- Proporciona `keyExtractor`, un `renderItem` memoizado y alturas de ítem estables cuando sea posible (`getItemLayout`).
-- Ajusta `initialNumToRender`, `windowSize`, `maxToRenderPerBatch` para filas pesadas.
-- Nunca renderices conjuntos de datos grandes con `.map()` dentro de un `ScrollView`.
-
-## Imágenes y assets
-
-- Usa `expo-image` para caché, prioridad y placeholders; sirve imágenes con el tamaño apropiado.
-- Evita cargar imágenes a resolución completa en miniaturas pequeñas.
-
-## Animaciones
-
-- Prefiere `react-native-reanimated` (corre en el hilo de UI) sobre la API `Animated` dirigida por JS.
-- Para `Animated` legado, establece `useNativeDriver: true` donde esté soportado.
-- Mantén el cómputo pesado fuera del hilo de JS; descárgalo a worklets de Reanimated o a módulos nativos.
-
-## Runtime y build
-
-- Construye sobre la **Nueva Arquitectura** (Fabric + TurboModules). Es el valor por defecto en los SDK recientes de Expo (aún se puede desactivar en SDK 53–54) y es obligatoria — no se puede desactivar — desde el SDK 55+. Verifica que cada dependencia nativa sea compatible con la Nueva Arquitectura antes de publicar.
-- Asegúrate de que **Hermes** esté habilitado (por defecto en Expo moderno) para un arranque más rápido y menos memoria.
-- Difiere el trabajo no crítico hasta después del primer paint; carga en diferido las pantallas/módulos pesados.
-- Usa `InteractionManager.runAfterInteractions` para el trabajo que pueda esperar a que terminen las animaciones.
-
-## Medición
-
-- Perfila con el profiler de React DevTools, el profiler de muestreo de Hermes y el monitor de rendimiento integrado en la app. (Evita Flipper — está obsoleto y no tiene soporte en la Nueva Arquitectura.)
-- Vigila: listas largas sin virtualización, imágenes sobredimensionadas, re-renders frecuentes del árbol completo y trabajo síncrono en el hilo de JS.