SsuperslateDocs

Project structure

Where application behavior, provider integrations, and operational tooling live.

apps/
  web/          React product application
  server/       Bun + Hono API, migrations, and domains
  docs/         Fumadocs + Next.js documentation site
packages/
  contracts/    Shared Zod schemas and inferred types
  billing/      Provider-neutral billing contract and adapters
  email/        React Email source templates
  create-app/   Buyer scaffold and branding workflow
  agent-eval/   Outcome evaluation and evidence harness
  agent-context/ Local read-only documentation MCP server
  tsconfig/     Shared TypeScript policy
agent-tooling/
  skills/       Optional general coding-agent workflows
docs/           Canonical product and operating documentation
infra/          OpenTofu bootstrap, modules, roots, locks, and tests
e2e/            Playwright browser and API boundary coverage
scripts/        Deployment, release, and repository verification
.github/        CI, cloud release, and source release workflows
src/modules/
src/services/
routes.ts
service.ts
repository.ts
migrations/
contracts/
billing/
email/
agent-context/

The studio source checkout may also contain seller-only landing/ and operations/ directories. They are excluded from generated buyer repositories and are not application runtime dependencies.

Domain ownership

Each server domain follows the same route → service → repository path. Routes map HTTP and session state, services own policy and transactions, and repositories own parameterized SQL. The web app consumes the shared contracts rather than recreating API types by hand.

Use this structure as a map, not a restriction on product language. Add product-specific capability inside its own domain/module instead of folding it into generic files.

Keep the flow directional

Contracts describe the wire format. Routes map HTTP. Services own policy. Repositories own SQL. That separation makes ownership and failure behavior discoverable for people and coding agents.

Read Architecture for boundaries and production topology, or jump to Build your first feature for the extension workflow.

On this page