Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.getmaito.com/llms.txt

Use this file to discover all available pages before exploring further.

Architecture

Maito is split by surface and responsibility. Preserve this split when adding features.

Surfaces

PathResponsibility
apps/appProduct UI, page routes, client state, SDK usage, and thin browser-facing social callback shells.
apps/webPublic website, blog, public tools, SEO pages, and marketing routes.
apps/apiREST routes, webhook routes, auth middleware, HTTP validation, and route adapters.
apps/mcpMCP transport, OAuth protected-resource metadata, tool registration, and MCP adapters.
apps/schedule-workerBackground execution using backend/domain packages.
packages/backendProduct behavior, domain services, orchestration, and application rules.
packages/dbSchema, migrations, repositories, and persistence models.
packages/contractsZod schemas, response envelopes, shared public request/response types.
packages/sdkTyped API client methods and browser-safe request logic.
packages/cliCLI client that calls the backend API.

Feature Flow

New browser-accessible backend functionality should usually move through the layers in this order:
  1. Define or update contracts in packages/contracts.
  2. Implement domain logic in packages/backend.
  3. Expose an HTTP route in apps/api.
  4. Add typed client support in packages/sdk.
  5. Consume it from apps/app.

App Boundaries

Do not add the following to apps/app:
  • Business logic for documents, drafts, publishing, queues, or newsletters.
  • New generic /api/* proxy routes.
  • MCP endpoints.
  • OAuth well-known metadata endpoints.
  • Backend service containers or runtime composition.
  • Direct database access.
  • Direct imports from packages/backend for domain behavior.
The only intentional browser-facing server shell in apps/app is social connect/callback routing. Those routes should call backend begin/complete endpoints and redirect the browser.

Document Model

The system is document-first:
  • Canonical primitive: document
  • Canonical address: path
  • Public mental model: files/documents
  • Retrieval model: document search/context over stored files
Do not introduce separate product stores for knowledge, memory, bookmarks, or voice profiles when documents and document paths are enough.