Repository and dependency atlas
The monorepo is a product graph—five apps, shared contracts and runtime packages, protocol bridges, remote infrastructure, native modules, and release machinery.
What this chapter resolves
- Map repository folders to runtime and distribution responsibilities.
- Distinguish dependency edges from process and protocol boundaries.
- Understand how the source inventory is reproduced from the pinned Git object.
The repository is large enough that folder-by-folder reading obscures the design. Treat it as a directed product graph: contracts define the language, runtime packages implement reusable algorithms, apps choose a process topology, and infrastructure/native/build layers complete delivery.
These counts are not hand-maintained marketing numbers. source:check enumerates
tracked files at the locked Git commit, applies versioned extension and test-path
rules, and counts lines from Git objects. Assets and the .repos reference clones
are excluded; generated protocol source remains part of the implementation surface.
The atlas
| Area | Primary output | Architectural role |
|---|---|---|
apps/server | published t3 CLI/server | execution authority, persistence, HTTP/WS, providers, workspace services |
apps/web | React browser bundle | local, hosted, and Electron-renderer product UI |
apps/desktop | Electron application | backend ownership, WSL/SSH, exposure, preview, native IPC, updater |
apps/mobile | Expo iOS/Android apps | remote-native UI, durable outbox/share, native terminal/diff, notifications |
apps/marketing | Astro/Vercel static site | download and publication surface, separate from product web |
packages/contracts | Effect schemas/types | canonical product, RPC, auth, provider, usage, and relay vocabulary |
packages/client-runtime | non-visual client library | connection, RPC, snapshot/cursor state, caches, capability logic |
packages/effect-* | protocol bridges | typed Codex app-server and ACP clients |
packages/ssh / tailscale | reachability libraries | remote launch/forward and endpoint provisioning |
infra/relay | Cloudflare Worker/control plane | identity, tunnel allocation, connection credentials, agent awareness |
native | Rust/native artifacts | Ghostty VT and resource monitoring |
scripts / packaging / .github | artifacts and releases | versioning, signing, installers, CI, stores, AUR, hosted aliases |
Dependency is not the same as deployment
Zoom with the controls, +/−, or Ctrl/⌘ + trackpad scroll. Enable Pan to drag, use two-finger scrolling, or use the arrow keys. 0 fits the diagram; Esc leaves Pan or expanded view.
Text equivalent
Contracts feed the server, shared client runtime, web, desktop, and mobile by package dependency. The client runtime feeds web and mobile. Web has a build-order and copy edge into the server distribution and also becomes the Electron renderer and hosted app. The server and web are packaged into local CLI and desktop shapes. Relay infrastructure is separately deployed and connected by a control-plane relationship, not a package dependency.
The arrow from web to server is a build edge: apps/server copies apps/web/dist
into its published client directory. At runtime, a browser still communicates with
the server over authenticated HTTP/WebSocket boundaries. Likewise, Electron imports
shared code and bundles a server, but its renderer remains isolated behind preload
IPC.
Follow one contract into a shipped surface
Move through the build graph; notice where shared code stops and a process boundary begins.
Step 1 of 5: Define
Contracts establish the canonical language
Effect schemas describe domain commands, RPC methods, provider runtime events, authentication, capabilities, and query shapes before any product chooses a renderer or process topology.
- 1. Define · Contracts establish the canonical language (Durable state)
Effect schemas describe domain commands, RPC methods, provider runtime events, authentication, capabilities, and query shapes before any product chooses a renderer or process topology.
packages/contracts/package.json:1–34↗ - 2. Reuse · Client runtime implements non-visual behavior (Client state)
Connection supervision, RPC sessions, caches, snapshot reconciliation, sequence cursors, and capability logic are shared without importing a browser or native UI.
packages/client-runtime/package.json:1–172↗ - 3. Render · The web application binds behavior to React (Client state)
Runtime selection composes local, hosted, and desktop-renderer contexts around the same route tree; this is still build-time reuse, not server co-location.
apps/web/src/main.tsx:21–59↗ - 4. Package · The server distribution copies a completed web build (Transport boundary)
The npm package depends on the web build and copies static output into its client directory so one CLI can serve both API and assets.
apps/server/scripts/cli.ts:143–176↗ - 5. Execute · Runtime communication crosses HTTP and WebSocket boundaries (Runtime work)
Once launched, the browser is a client and the environment server is the trusted executor. A dependency edge has become a protocol and authority boundary.
docs/internals/overview.md:5–28↗apps/server/src/server.ts:123–472↗