Structure du projet

Configuration et paramètres

Avant toute étape, lisez Avant de commencer et Bases du terminal. Ouvrez le dossier supastack à sa racine — le dossier contenant package.json. Un checkout Mobile contient apps/mobile plus les packages partagés ci-dessous ; le monorepo All Platforms ajoute le backend Web et le shell Desktop. Une variable d'environnement est un paramètre nommé stocké dans un fichier .env local ou votre tableau de bord d'hébergement ; redémarrez l'application après l'avoir modifiée et gardez les secrets serveur hors des valeurs EXPO_PUBLIC_.

1. Ouvrez apps/mobile/app/_layout.tsx dans l'éditeur — le layout racine que partage chaque écran.

2. Parcourez apps/mobile/src/ — un dossier par domaine fonctionnel, chacun contenant sa logique et ses tests.

3. Depuis la racine du dépôt, exécutez corepack pnpm --filter @supastack/mobile start et ouvrez l'aperçu sur votre appareil.

L'application Expo est organisée en routes qui appellent des modules de fonctionnalités. Les routes restent minces — elles rendent des écrans ; la logique qu'elles appellent vit sous src/ avec ses tests à côté. Lisez AGENTS.md et .ai/PROJECT_CONTEXT.md avant de modifier le comportement ; les documents miroir .ai/ consignent des décisions invisibles depuis un fichier seul.

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

Où va une modification

Avant de modifier, décidez quel dossier possède le changement. Règle de base : un fichier de route ne fait que rendre ; la logique réutilisable vit dans un module src/ ; tout ce que le serveur doit décider n'entre jamais dans l'application.

• Construisez votre première fonctionnalité mobile

• Un nouvel écran connecté → apps/mobile/app/(app)/ pour la route plus apps/mobile/src/<feature>/ pour sa logique.
• Un nouvel écran pré-auth ou autonome → apps/mobile/app/ en dehors du groupe (app).
• Un appel au backend → apps/mobile/src/api/client.ts — étendez le client typé plutôt que de fetcher à l'improviste.
• Un visuel partagé entre écrans → les primitives apps/mobile/src/ui/ ; un view-model multiplateforme → packages/ui-native/.
• Couleurs, espacements et valeurs sombre/clair → apps/mobile/src/theme/ adossé à packages/design-tokens/.
• Une nouvelle clé de traduction → les quatre catalogues sous apps/mobile/src/i18n/.
• Tout ce qui est côté serveur — données, permissions, appels de fournisseurs → le dépôt du backend Web, qui est un checkout séparé pour les achats uniquement Mobile.

Processus d’implémentation

Partez du fichier de route, suivez le module de fonctionnalité qu'il rend, puis l'appel du client API — le serveur décide de la propriété ; l'application ne la redéduit jamais. Le skill add-a-mobile-screen dans .agents/skills/ suit ce même ordre.

Exécutez les tests du package et la vérification de types après avoir modifié un package partagé ou le client API ; le client doit conserver le même contrat que celui servi par le backend.

Vérification et dépannage

Si expo start signale un module manquant, exécutez la commande d'installation depuis la racine du dépôt — le dossier de l'application seul ne peut pas résoudre les packages du workspace. Si un écran apparaît sans style, vérifiez qu'il compose des primitives src/ui plutôt que des éléments bruts avec des couleurs codées en dur.

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