For AI agents: fetch the complete documentation index at /llms.txt, the full documentation corpus at /llms-full.txt, the agent skill at /skill.md, or this page as Markdown at /de/docs/web/project-structure.md (or send Accept: text/markdown).

Projektstruktur

Finden Sie die Anwendungen, gemeinsamen Pakete und ihre jeweiligen Grenzen.

Zu dieser Anleitung fragen

Einrichtung und Konfiguration

Lesen Sie vor jedem Schritt Bevor Sie beginnen und Terminal-Grundlagen. Bei diesen Anweisungen wird davon ausgegangen, dass Sie das vollständige Supastack-Monorepo in VS Code geöffnet haben. Sein Stamm package.json markiert den Repository-Stamm. In pnpm-Befehlen ist ein Arbeitsbereichspaket eine App oder ein Ordner mit gemeinsam genutztem Code. Im Produkt ist ein Arbeitsbereich der Datencontainer und die Sicherheitsgrenze eines Teams. corepack pnpm --filter ... wählt ein Paket aus dem Monorepo aus, während Befehle von seinem Stammverzeichnis aus ausgeführt werden. Wenn Sie nur einen synchronisierten Mobil- oder Desktop-Ordner geöffnet haben, enthält dieser weder das Web-Backend, Docker-Setup noch Root-Skripte: Führen Sie das Backend von diesem Monorepo oder einem erreichbaren gehosteten Server aus und verwenden Sie die eigenen Skripte des Plattformordners. Eine Umgebungsvariable ist eine benannte Einstellung, die in einer lokalen .env-Datei oder Ihrem Hosting-Dashboard gespeichert ist; Starten Sie die entsprechende App neu, nachdem Sie sie geändert haben, und halten Sie Servergeheimnisse von den Werten NEXT_PUBLIC_ und EXPO_PUBLIC_ fern.

1. Öffnen Sie die Root-Datei package.json in VS Code und durchsuchen Sie dann apps/web nach der Website, apps/mobile nach Expo, apps/desktop nach der Desktop-Shell und Pakete nach gemeinsam genutzten Teilen.

2. Führen Sie im Repository-Root den Befehl corepack pnpm --filter @supastack/web dev aus.

3. Öffnen Sie http://localhost:3000.. Erwartet: Die Web-App startet von apps/web, während freigegebene Pakete in demselben Repository verbleiben. Das Desktop-Fenster umschließt diese Web-App, anstatt ein zweites Produkt zu enthalten.

Der pnpm-Workspace enthält Next.js unter apps/web, Expo unter apps/mobile und gemeinsame Pakete unter packages. Führen Sie Workspace-Befehle im Stammverzeichnis des Repositorys aus. Anwendungsrouten setzen gemeinsame Module zusammen; produktspezifisches Verhalten gehört in das jeweilige Produkt.

Lesen Sie AGENTS.md und .ai/PROJECT_CONTEXT.md, bevor Sie Verhalten ändern. Die Dateispiegel unter .ai/ erläutern Entscheidungen und Einschränkungen, die aus einer einzelnen Komponente möglicherweise nicht ersichtlich sind.

apps/web/app/       Routes and layouts
apps/web/src/       Web components and server composition
apps/mobile/        Expo application
packages/           Shared contracts and adapters
tests/              Cross-module and browser checks
docs/               Operational guides

Befehle zum Kopieren

Befolgen Sie die Kommentare, um zu sehen, in welchem Ordner ein Befehl ausgeführt wird. Wenn zwei Terminals gekennzeichnet sind, öffnen Sie zwei Terminalfenster und lassen Sie den ersten Befehl laufen, während Sie den zweiten verwenden.

corepack pnpm --filter @supastack/web dev

Wohin eine Änderung gehört

Entscheiden Sie vor dem Bearbeiten, welche App oder welches Paket die Änderung besitzt. Faustregel: Wenn nur eine Produktoberfläche sie braucht, gehört sie in diese App; wenn jede Oberfläche sie braucht, gehört sie in ein gemeinsames Paket unter packages/.

Das Web-Repository und das All-Platforms-Monorepo enthalten jeden der folgenden Ordner. Ein eigenständiger Mobile- oder Desktop-Checkout enthält nur die eigene App — der Servercode bleibt im Web-Repository.

Bauen Sie Ihr erstes Feature

Eine neue Marketing- oder Landingpage → apps/web/app/ — die öffentliche Website.
Ein neuer Bildschirm im angemeldeten Produkt → apps/web/app/ für die Route plus apps/web/src/ für die Logik — Seiten komponieren die gemeinsamen Pakete.
Eine neue API-Route → apps/web/app/api/ — die Serverhälfte der Web-App.
Eine Änderung, die alle Apps teilen — eine Datenbanktabelle, ein Vertrag, ein Anbieteradapter → der passende Ordner in packages/.
Ein nur fürs Telefon bestimmter Bildschirm → apps/mobile/ — er spricht mit der API der Web-App, statt ein eigenes Backend zu beherbergen.
Ein nur für den Desktop bestimmtes Verhalten → apps/desktop/ — die Tauri-Hülle umfasst die Web-App und spaltet fast nie Produkt-UI ab.

Implementierungsablauf

Beginnen Sie bei der Route, der die Benutzeraktion gehört, folgen Sie ihrem serverseitigen Handler und sehen Sie sich danach das aufgerufene gemeinsame Paket an. Eine UI-Komponente sollte Workspace-Auflösung, Abrechnungsautorisierung oder Provider-Auswahl nicht neu implementieren.

Entscheiden Sie beim Hinzufügen einer Route, ob sie öffentlich oder authentifiziert ist. Ermitteln Sie authentifizierte Zuständigkeit auf dem Server, bevor Sie auf Benutzerdatensätze zugreifen, und halten Sie Server-Zugangsdaten von Client-Imports fern.

Überprüfung und Fehlerbehebung

Wenn der Befehl meldet, dass kein Projekt zum Filter passt, prüfen Sie, ob das Terminal im Ordner mit der package.json im Repository-Stamm geöffnet ist. Wird Port 3000 bereits verwendet, beenden Sie zuerst den anderen lokalen Web-Server. Suchen Sie nicht nach einer eigenen Desktop-Chat- oder Anmeldeimplementierung; die Desktop-Hülle lädt das Web-Backend.

Führen Sie nach einer Änderung am Paketvertrag die relevanten Tests und die Typprüfung aus. Prüfen Sie bei Änderungen an gemeinsamen Typen auch die Web- und Mobile-Nutzer. Ein erfolgreicher Web-Build belegt allein keine Kompatibilität mit der nativen App.