Projektstruktur

Einrichtung und Konfiguration

Lesen Sie vor jedem Schritt Vor dem Start und Terminal-Grundlagen. Öffnen Sie den Ordner supastack an seinem Stamm — dem Ordner, der package.json enthält. Ein Mobile-Checkout enthält apps/mobile plus die unten genannten gemeinsamen Pakete; das All-Platforms-Monorepo fügt das Web-Backend und die Desktop-Shell hinzu. Eine Umgebungsvariable ist eine benannte Einstellung in einer lokalen .env-Datei oder Ihrem Hosting-Dashboard; starten Sie die App nach einer Änderung neu und halten Sie Server-Geheimnisse aus EXPO_PUBLIC_-Werten fern.

1. Öffnen Sie apps/mobile/app/_layout.tsx im Editor — das Root-Layout, das jeder Bildschirm teilt.

2. Durchsuchen Sie apps/mobile/src/ — ein Ordner pro Funktionsbereich, der jeweils seine Logik und Tests enthält.

3. Führen Sie im Repository-Stammverzeichnis corepack pnpm --filter @supastack/mobile start aus und öffnen Sie die Vorschau auf Ihrem Gerät.

Die Expo-App ist als Routen organisiert, die Funktionsmodule aufrufen. Routen bleiben schlank — sie rendern Bildschirme; die Logik, die sie aufrufen, liegt mit ihren Tests unter src/. Lesen Sie AGENTS.md und .ai/PROJECT_CONTEXT.md, bevor Sie Verhalten ändern; die .ai/-Spiegeldokumente halten Entscheidungen fest, die aus einer Datei allein nicht ersichtlich sind.

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

Wohin eine Änderung gehört

Entscheiden Sie vor dem Bearbeiten, welcher Ordner die Änderung besitzt. Faustregel: Eine Routendatei rendert nur; wiederverwendbare Logik lebt in einem src/-Modul; alles, was der Server entscheiden muss, gelangt niemals in die App.

• Erstellen Sie Ihr erstes mobiles Feature

• Ein neuer angemeldeter Bildschirm → apps/mobile/app/(app)/ für die Route plus apps/mobile/src/<feature>/ für seine Logik.
• Ein neuer Vor-Auth- oder eigenständiger Bildschirm → apps/mobile/app/ außerhalb der Gruppe (app).
• Ein Aufruf an das Backend → apps/mobile/src/api/client.ts — erweitern Sie den typisierten Client, statt ad hoc zu fetchen.
• Ein über Bildschirme geteiltes visuelles Element → apps/mobile/src/ui/-Primitives; ein plattformübergreifendes View-Model → packages/ui-native/.
• Farben, Abstände und Dunkel-/Hell-Werte → apps/mobile/src/theme/, gestützt auf packages/design-tokens/.
• Ein neuer Übersetzungsschlüssel → alle vier Kataloge unter apps/mobile/src/i18n/.
• Alles Serverseitige — Daten, Berechtigungen, Provider-Aufrufe → das Web-Backend-Repository, das bei reinen Mobile-Käufen ein separater Checkout ist.

Implementierungsablauf

Beginnen Sie bei der Routendatei, folgen Sie dem Funktionsmodul, das sie rendert, dann dem API-Client-Aufruf — der Server entscheidet über den Besitz; die App leitet ihn nie selbst ab. Der Skill add-a-mobile-screen in .agents/skills/ durchläuft dieselbe Reihenfolge.

Führen Sie nach dem Bearbeiten eines gemeinsamen Pakets oder des API-Clients die Pakettests und die Typprüfung aus; der Client muss denselben Vertrag einhalten, den das Backend bedient.

Überprüfung und Fehlerbehebung

Wenn expo start ein fehlendes Modul meldet, führen Sie den Installationsbefehl im Repository-Stammverzeichnis aus — der App-Ordner allein kann Workspace-Pakete nicht auflösen. Wenn ein Bildschirm ungestylt erscheint, prüfen Sie, ob er src/ui-Primitives zusammensetzt statt roher Elemente mit hartcodierten Farben.

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