Arquitectura de system

Capas

app/route
  -> module component
  -> module hook / Zustand
  -> @repo/app-services
  -> @repo/firebase-client-adapter
  -> Firebase

Para operaciones que requieren privilegios elevados, la app debe invocar una callable function. La lógica server-side vive en apps/functions y/o @repo/app-function-services, no en componentes de system.

App Router

• app/page.tsx: entrada raíz.
• app/(auth): layouts y páginas de autenticación.
• app/(dashboard): shell protegido de la aplicación.
• Los nombres entre paréntesis son route groups y no forman parte de la URL.
• Los [id] representan rutas dinámicas.

Layouts

1. app/layout.tsx carga estilos, fonts, sesión raíz y estado de preparación global.
2. app/(auth)/layout.tsx agrega el Toaster para los flujos de auth.
3. app/(dashboard)/layout.tsx inicializa auth, sidebar, navbar, navegación y toaster.

No mover inicialización de sesión a cada página. Los componentes de página deben consumir el estado preparado por los hooks del módulo.

Módulos

Cada módulo mantiene cerca entre sí sus componentes, hooks, tipos, constantes y mocks. La lógica que se reutiliza entre apps debe extraerse a packages/, siguiendo packages/README.md.

Los módulos no deben importar desde otro módulo mediante rutas internas si existe una utilidad común apropiada. Las dependencias entre dominios deben ser pequeñas y explícitas.

Server y client components

En Next.js los componentes son Server Components por defecto. En system, las áreas que dependen de hooks, Zustand, localStorage, Firebase client o eventos del navegador deben declarar 'use client'. No convertir layouts o páginas completas en Client Components sin una necesidad concreta.