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 /docs/web/project-structure.md (or send Accept: text/markdown).
Project structure
Find the application, shared packages, and the boundaries between them.
Setup and configuration
Before any step, read Before you start and Terminal basics. These instructions assume you opened the full supastack monorepo in VS Code; its root package.json marks the repository root. In pnpm commands, a workspace package is an app or shared-code folder; in the product, a workspace is a team's data container and security boundary. corepack pnpm --filter ... selects one package from the monorepo while commands run from its root. If you opened only a synced mobile or desktop folder, it does not contain the Web backend, Docker setup, or root scripts: run the backend from this monorepo or a reachable hosted server, and use the platform folder's own scripts. An environment variable is a named setting stored in a local .env file or your hosting dashboard; restart the relevant app after changing it, and keep server secrets out of NEXT_PUBLIC_ and EXPO_PUBLIC_ values.
1. Open the root package.json in VS Code, then browse apps/web for the website, apps/mobile for Expo, apps/desktop for the desktop shell, and packages for shared pieces.
2. From the repository root run corepack pnpm --filter @supastack/web dev.
3. Open http://localhost:3000. Expected: the Web app starts from apps/web while shared packages remain in this same repository; the Desktop window wraps this Web app rather than containing a second product.
The pnpm workspace contains Next.js in apps/web, Expo in apps/mobile, and shared packages under packages. Run workspace commands from the repository root. Application routes compose shared modules; product-specific behavior belongs in the consuming product.
Read AGENTS.md and .ai/PROJECT_CONTEXT.md before changing behavior. File mirrors in .ai/ explain decisions and constraints that may not be apparent from a component alone.
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 guidesCommands to copy
Follow the comments to see which folder a command runs in. If two terminals are labeled, open two terminal windows and keep the first command running while you use the second.
corepack pnpm --filter @supastack/web devWhere a change belongs
Before editing, decide which app or package owns the change. The rule of thumb: if only one product surface needs it, put it in that app; if every surface needs it, put it in a shared package under packages/.
The Web repository and the All Platforms monorepo contain every folder below. A standalone Mobile or Desktop checkout contains only its own app — the server code stays in the Web repository.
- A new marketing or landing page →
apps/web/app/— the public website. - A new screen inside the signed-in product →
apps/web/app/for the route plusapps/web/src/for its logic — pages compose the shared packages. - A new API route →
apps/web/app/api/— the server half of the Web app. - A change every app shares — a database table, a contract, a provider adapter → the matching folder in
packages/. - A phone-only screen →
apps/mobile/— it talks to the Web app's API rather than holding its own backend. - A desktop-only behavior →
apps/desktop/— the Tauri shell wraps the Web app and almost never forks product UI.
Implementation workflow
Start with the route that owns the user action, follow its server handler, and then inspect the shared package it calls. A UI component should not recreate workspace resolution, billing authorization, or provider selection.
When adding a route, decide whether it is public or authenticated. Resolve authenticated ownership on the server before accessing user records, and keep server credentials outside client imports.
Verification and troubleshooting
If the command reports that no project matches the filter, check that the terminal is in the folder containing the root package.json. If port 3000 is already in use, stop the other local Web server first. Do not look for a separate Desktop chat or login implementation; the desktop shell loads the Web backend.
Run the relevant tests and typecheck after changing a package contract. Inspect both web and mobile consumers when changing shared types. A successful web build alone does not establish compatibility with the native app.