Struttura del progetto

Installazione e configurazione

Prima di qualsiasi passaggio, leggi Prima di iniziare e Nozioni di base sul terminale. Apri la cartella supastack alla sua radice — la cartella che contiene package.json. Un checkout Mobile contiene apps/mobile più i pacchetti condivisi qui sotto; il monorepo All Platforms aggiunge il backend Web e la shell Desktop. Una variabile d'ambiente è un'impostazione con nome archiviata in un file .env locale o nella tua dashboard di hosting; riavvia l'app dopo averla modificata e tieni i segreti del server fuori dai valori EXPO_PUBLIC_.

1. Apri apps/mobile/app/_layout.tsx nell'editor — il layout radice che ogni schermata condivide.

2. Esplora apps/mobile/src/ — una cartella per area funzionale, ognuna contenente la sua logica e i suoi test.

3. Dalla radice del repository esegui corepack pnpm --filter @supastack/mobile start e apri l'anteprima sul tuo dispositivo.

L'app Expo è organizzata come route che chiamano moduli di funzionalità. Le route restano sottili — rendono schermate; la logica che chiamano vive sotto src/ con i suoi test accanto. Leggi AGENTS.md e .ai/PROJECT_CONTEXT.md prima di modificare il comportamento; i documenti specchio .ai/ registrano decisioni non visibili da un file da solo.

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

Dove va una modifica

Prima di modificare, decidi quale cartella possiede la modifica. Regola pratica: un file di route rende soltanto; la logica riutilizzabile vive in un modulo src/; qualsiasi cosa il server debba decidere non entra mai nell'app.

• Costruisci la tua prima funzionalità mobile

• Una nuova schermata con accesso → apps/mobile/app/(app)/ per la route più apps/mobile/src/<feature>/ per la sua logica.
• Una nuova schermata pre-autenticazione o autonoma → apps/mobile/app/ fuori dal gruppo (app).
• Una chiamata al backend → apps/mobile/src/api/client.ts — estendi il client tipizzato invece di fare fetch ad hoc.
• Un elemento visivo condiviso tra schermate → i primitivi apps/mobile/src/ui/; un view-model multipiattaforma → packages/ui-native/.
• Colori, spaziatura e valori scuro/chiaro → apps/mobile/src/theme/ supportato da packages/design-tokens/.
• Una nuova chiave di traduzione → tutti e quattro i cataloghi sotto apps/mobile/src/i18n/.
• Qualsiasi cosa lato server — dati, permessi, chiamate ai provider → il repository del backend Web, che è un checkout separato per gli acquisti solo Mobile.

Flusso di implementazione

Parti dal file di route, segui il modulo di funzionalità che rende, poi la chiamata del client API — il server decide la proprietà; l'app non la ricalcola mai. Lo skill add-a-mobile-screen in .agents/skills/ percorre questo stesso ordine.

Esegui i test del pacchetto e il typecheck dopo aver modificato un pacchetto condiviso o il client API; il client deve mantenere lo stesso contratto che il backend serve.

Verifica e risoluzione dei problemi

Se expo start segnala un modulo mancante, esegui il comando di installazione dalla radice del repository — la cartella dell'app da sola non può risolvere i pacchetti del workspace. Se una schermata appare senza stile, verifica che componga i primitivi src/ui invece di elementi grezzi con colori hardcoded.

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