Estructura del proyecto

Configuración y ajustes

Antes de cualquier paso, lea Antes de empezar y Conceptos básicos de la terminal. Abra la carpeta supastack en su raíz: la carpeta que contiene package.json. Un checkout de Mobile contiene apps/mobile más los paquetes compartidos siguientes; el monorepo All Platforms añade el backend Web y el shell de Desktop. Una variable de entorno es una configuración con nombre almacenada en un archivo .env local o en su panel de hosting; reinicie la aplicación después de cambiarla y mantenga los secretos del servidor fuera de los valores EXPO_PUBLIC_.

1. Abra apps/mobile/app/_layout.tsx en el editor: el layout raíz que comparte cada pantalla.

2. Explore apps/mobile/src/: una carpeta por área de funcionalidad, cada una con su lógica y sus pruebas.

3. Desde la raíz del repositorio ejecute corepack pnpm --filter @supastack/mobile start y abra la vista previa en su dispositivo.

La aplicación Expo está organizada como rutas que llaman a módulos de funciones. Las rutas se mantienen delgadas: renderizan pantallas; la lógica que llaman vive bajo src/ con sus pruebas al lado. Lea AGENTS.md y .ai/PROJECT_CONTEXT.md antes de cambiar el comportamiento; los documentos espejo de .ai/ registran decisiones que no se ven solo en un archivo.

apps/mobile/app/          Expo Router routes — sign-in, onboarding, invite, paywall
apps/mobile/app/(app)/    Signed-in screens — home, chat, notifications, settings, content, commerce, assistant
apps/mobile/src/          Feature modules — auth, api, purchases, offline, push, ui, theme, i18n
packages/ui-native/       Shared native view-models
packages/design-tokens/   Shared theme tokens
apps/mobile/app.config.ts Scheme and allowed-origin derivation
apps/mobile/eas.json      EAS build and submit profiles
docs/                     Runbooks incl. store submission
.agents/skills/           Task guides for coding agents

Dónde pertenece un cambio

Antes de editar, decida qué carpeta es dueña del cambio. La regla general: un archivo de ruta solo renderiza; la lógica reutilizable vive en un módulo de src/; cualquier cosa que el servidor deba decidir nunca entra en la aplicación.

• Construya su primera funcionalidad móvil

• Una nueva pantalla con sesión iniciada → apps/mobile/app/(app)/ para la ruta más apps/mobile/src/<feature>/ para su lógica.
• Una nueva pantalla de preautenticación o independiente → apps/mobile/app/ fuera del grupo (app).
• Una llamada al backend → apps/mobile/src/api/client.ts: extienda el cliente tipado en lugar de hacer fetch ad hoc.
• Un elemento visual compartido entre pantallas → primitives de apps/mobile/src/ui/; un view-model multiplataforma → packages/ui-native/.
• Colores, espaciado y valores de oscuro/claro → apps/mobile/src/theme/ respaldado por packages/design-tokens/.
• Una nueva clave de traducción → los cuatro catálogos bajo apps/mobile/src/i18n/.
• Cualquier cosa del lado del servidor —datos, permisos, llamadas a proveedores— → el repositorio del backend Web, que es un checkout separado para compras solo de Mobile.

Flujo de implementación

Comience en el archivo de ruta, siga el módulo de funcionalidad que renderiza, luego la llamada del cliente API: el servidor decide la propiedad; la aplicación nunca la re-deriva. El skill add-a-mobile-screen en .agents/skills/ recorre este mismo orden.

Ejecute las pruebas del paquete y la verificación de tipos después de editar un paquete compartido o el cliente API; el cliente debe mantener el mismo contrato que sirve el backend.

Verificación y solución de problemas

Si expo start informa de un módulo faltante, ejecute el comando de instalación desde la raíz del repositorio: la carpeta de la aplicación sola no puede resolver paquetes del workspace. Si una pantalla aparece sin estilo, compruebe que compone primitives de src/ui en lugar de elementos en bruto con colores hardcodeados.

corepack pnpm --filter @supastack/mobile test
corepack pnpm --filter @supastack/mobile typecheck