Backend Architecture

Goal

This structure keeps the Day 1 runtime stable while giving the backend a clear home for shared HTTP concerns, shared types, OpenAPI work, and feature modules. The current runtime still lives in server/index.js, but everything new should be shaped around the layout below.

Structure

server/
  index.js
  start.js
  src/
    app.ts
    bootstrap.ts
    config/
      runtime.ts
    shared/
      http/
        api-response.ts
        async-handler.ts
        error-handler.ts
        not-found-handler.ts
        request-context.ts
      platform/
        runtime-platform.ts
        text.ts
        stream.ts
        shell.ts
        path.ts
      types/
        app.ts
        http.ts
      docs/
        openapi.ts
      utils/
        app-error.ts
        logger.ts
    modules/
      auth/
      cli-auth/
      user/
      settings/
      projects/
      files/
      sessions/
      git/
      taskmaster/
      agent/
      providers/
        claude/
        codex/
        cursor/
        gemini/
        mcp/
        plugins/

File And Folder Roles

server/index.js Temporary compatibility boundary for the old monolith. Day 1 keeps behavior here so the new TypeScript layout can grow around a stable runtime. Example: the existing websocket handlers, inline routes, and provider startup still live here until they are migrated module by module.
server/start.js Thin production entrypoint for the compiled backend output. Example: server:start uses this file to verify server/dist/bootstrap.js exists and then loads it.
src/bootstrap.ts Executable backend entrypoint used by npm run server and npm run server:dev. Example: bootstrap.ts should stay thin and do nothing except start the app, so later it remains safe to call in dev, prod, tests, or worker modes.
src/app.ts Composition root for the backend application. Example: today it bridges into index.js; later it will create the Express app, apply shared middleware, register modules, attach websocket setup, and return the running application shape.
src/config/ Runtime configuration helpers and environment-aware path logic. Example: config/runtime.ts resolves the project root, server root, legacy runtime path, and built bootstrap path without scattering path math across the app.
src/shared/http/ Shared HTTP-level behavior that every module can reuse. Example: api-response.ts is where standard API response builders live. Example: error-handler.ts is where thrown AppError instances get translated into JSON payloads. Example: request-context.ts is where request IDs, timestamps, and per-request metadata are attached. Example: async-handler.ts removes repeated try/catch(next) wrappers in controllers. Example: not-found-handler.ts is the generic fallback for unknown API routes.
src/shared/platform/ Shared OS-adapter helpers for shell spawning, line ending normalization, streaming stdout/stderr parsing, and path normalization. Example: platform/stream.ts is where process output gets split into complete lines without leaking CRLF edge cases into feature code. Example: platform/shell.ts is where PowerShell-vs-bash command construction lives so provider modules do not branch on process.platform.
src/shared/types/ Global type aliases that are safe to share across modules. This layer uses type, not interface. Example: types/http.ts defines ApiMeta, ApiErrorShape, RequestContext, AuthenticatedRequest, and EndpointInventoryRecord. Example: types/app.ts defines RuntimePaths, AppLocals, and ServerApplication.
src/shared/docs/ Shared documentation helpers and future OpenAPI registry code. Example: docs/openapi.ts is the future home for global tags like Auth, Projects, Files, Git, and Providers, plus reusable schema registration.
src/shared/utils/ Shared non-HTTP utilities that stay generic and reusable. Example: utils/app-error.ts defines AppError, which feature modules can throw without knowing how HTTP serialization works. Example: utils/logger.ts is the centralized logger surface so modules do not ad-hoc console.log everywhere.
src/modules/ Feature boundaries. Every business area gets its own folder so request schemas, controllers, services, serializers, and docs stay close to the feature they belong to.
src/modules/auth/ Local authentication flows. Example: login, register, logout, and auth-status endpoints belong here.
src/modules/cli-auth/ CLI/provider authentication status flows for Claude, Cursor, Codex, and Gemini CLIs. Example: /api/cli/claude/status belongs here because it checks local CLI auth rather than app-user auth.
src/modules/user/ User-specific settings and onboarding state. Example: git identity setup and onboarding completion endpoints belong here.
src/modules/settings/ App-level stored secrets and toggles. Example: API keys and credential storage endpoints belong here because they configure backend access rather than user identity.
src/modules/projects/ Workspace and project registration concerns. Example: project listing, project creation, workspace creation, and project rename/delete flows belong here.
src/modules/files/ File tree and workspace file operations only. Example: read file, save file, upload file, create file, rename file, delete file, and image upload endpoints belong here. Example boundary rule: this module should not decide how projects are discovered; it only operates inside an already resolved project/workspace.
src/modules/sessions/ Conversation and provider session history concerns. Example: list sessions, fetch session messages, rename sessions, delete sessions, token-usage lookups, and conversation search belong here.
src/modules/git/ Repository operations and git intelligence. Example: status, diff, branch listing, checkout, commit, push, publish, discard, and AI commit-message generation endpoints belong here.
src/modules/taskmaster/ TaskMaster-specific project workflows. Example: detect installation, initialize TaskMaster, manage PRDs, add/update tasks, parse PRDs, and apply templates belong here.
src/modules/agent/ External agent execution API. Example: /api/agent belongs here because it orchestrates provider selection, cloning, project reuse, branch creation, streaming, and optional PR creation.
src/modules/providers/ Provider-specific integrations that are narrower than the general agent API. Example: provider session readers or provider-specific config endpoints should live here so Claude, Codex, Cursor, and Gemini logic do not bleed into unrelated modules.
src/modules/providers/claude/ Claude-specific runtime concerns. Example: if Claude gets module-specific schemas or adapters later, they belong here rather than inside generic session code.
src/modules/providers/codex/ Codex-specific config, session, and MCP-adjacent logic. Example: Codex MCP CLI endpoints and session history parsing can move here over time.
src/modules/providers/cursor/ Cursor-specific config, MCP, and stored session behavior. Example: Cursor config reads, MCP server mutation, and SQLite-backed session history belong here.
src/modules/providers/gemini/ Gemini-specific config and session behavior. Example: Gemini session message history and provider CLI lifecycle hooks belong here.
src/modules/providers/mcp/ MCP surfaces that are shared across providers or not owned by a single provider module. Example: generic Claude MCP CLI/config endpoints and helper endpoints belong here.
src/modules/providers/plugins/ Plugin runtime and plugin asset delivery. Example: plugin listing, installation, update, enable/disable, and asset serving can move here even though plugins are not an LLM provider; this keeps third-party integration surfaces grouped together.

Boundary Rules

app.ts wires modules together; it should not contain feature logic.
config/ resolves environment and filesystem context; it should not know HTTP payload details.
shared/http/ owns transport concerns; it should not know feature rules like how to rename a project.
shared/types/ only contains reusable type aliases; avoid feature-specific types here unless multiple modules truly share them.
modules/<feature>/ owns its own future routes, controllers, services, schemas, and docs.
projects, files, and sessions stay separate on purpose: projects decides what a workspace/project is. files operates inside a resolved workspace. sessions manages chat/session history and search.
agent stays separate from providers: agent is orchestration for external callers. providers/* are provider-specific adapters and APIs.

Day 1 Notes

The runtime still executes through server/index.js for safety.
The new src/ structure is now the required home for all new backend code.
The generated inventory in docs/backend/endpoint-inventory.* is the source of truth for what must be migrated into these folders next.

Package Scripts

These scripts live in package.json. The key distinction is:

server and server:dev run the backend directly from TypeScript.
server:start runs the compiled backend through server/start.js.
build only builds the frontend.
server:build only builds the backend.
start runs the full production-style flow.

Development Scripts

npm run dev Starts the frontend and backend together. Use this for normal full-stack development when you want Vite and the API server running at the same time. Example: you are editing a React screen that calls /api/projects and also changing the backend route behavior.
npm run server:dev Starts the backend in watch mode with tsx watch --tsconfig server/tsconfig.json server/src/bootstrap.ts. Use this for backend-only development. Example: you are refactoring request handling, logging, module structure, or shared HTTP utilities and want automatic restarts.
npm run server Starts the backend once from TypeScript with tsx --tsconfig server/tsconfig.json server/src/bootstrap.ts. Use this when you want a stable one-shot backend process. Example: you want to reproduce a startup bug, inspect logs without reload noise, or test one backend flow manually.
npm run client Starts only the Vite frontend dev server. Use this for frontend-only work when a backend is already running elsewhere. Example: you are polishing UI layout or fixing a component state bug and do not need to restart the API server.

Build And Runtime Scripts

npm run build Builds the frontend into dist/. Use this to verify production frontend bundling. Example: you changed React routing, code-splitting, or CSS and want to confirm the frontend still builds.
npm run server:build Compiles the backend TypeScript using server/tsconfig.json into server/dist/. Use this to verify backend build correctness. Example: you changed server/src/app.ts, shared types, or future module imports and want to confirm compiled output is valid.
npm run server:start Starts the built backend through server/start.js. Use this after npm run server:build when you want to run compiled backend output only. Example: dev mode works, but you want to make sure the production entrypoint and compiled files also work correctly.
npm run start Runs npm run build, then npm run server:build, then npm run server:start. Use this as the closest local equivalent to a production run. Example: before shipping, you want to confirm the built frontend and built backend work together, not just the watch-mode setup.
npm run preview Serves the built frontend bundle with Vite preview. Use this when you want to inspect the built frontend output specifically. Example: you want to check whether a client-side issue only appears in production assets. Note: this does not replace the backend server. API routes still require the backend to be running separately.

Validation Scripts

npm run typecheck:client Runs TypeScript checking for the frontend only. Use this after frontend code changes. Example: you changed hook types, component props, or frontend shared models.
npm run typecheck:server Runs TypeScript checking for the backend only. Use this after backend code changes. Example: you changed shared HTTP helpers, backend imports, or module boundaries.
npm run typecheck Runs both frontend and backend typechecks. Use this as the default correctness check before commit or PR. Example: you changed src/ and server/src/ in the same branch and want one command to validate both.
npm run lint Runs ESLint on src/ only. Use this for frontend lint validation. Example: you changed React files and want to catch unused imports, hook issues, or style violations.
npm run lint:fix Runs ESLint on src/ and auto-fixes what it can. Use this after frontend edits when you want quick cleanup. Example: you renamed components and want ESLint to remove stale imports and apply automatic fixes.

Release And Lifecycle Scripts

npm run release Runs release.sh, which loads GITHUB_TOKEN from .env and then executes release-it. Use this only when intentionally creating a release. Example: you are cutting a new tagged version and want versioning/changelog automation.
prepublishOnly Runs automatically before npm publish. It builds both frontend and backend first. Example: this prevents publishing a broken package that was never built.
postinstall Runs automatically after npm install. It executes scripts/fix-node-pty.js. Example: this helps keep native terminal integration working after dependency installation.
prepare Runs automatically during install in development contexts. It sets up Husky hooks. Example: this ensures local git hooks are installed without requiring a separate setup command.

Recommended Workflows

Full-stack local development: npm install then npm run dev
Backend-only refactor work: npm run server:dev then npm run typecheck:server
Frontend-only work: npm run client, npm run typecheck:client, and npm run lint
Pre-PR validation: npm run typecheck, npm run lint, npm run build, and npm run server:build
Production-style local verification: npm run start
Release preparation: npm run typecheck, npm run build, npm run server:build, and npm run release

14 KiB Raw Blame History