How to read this guide
Choose a product, workflow, or architecture route and understand the evidence labels used throughout the book.
What this chapter resolves
- Choose the shortest reading path for your goal.
- Move from a product task to the implementation that supports it.
- Distinguish verified behavior, documented intent, inference, and proposals.
The book has a product path and a technical path. Read them in order for the full story, or enter through the task you need to complete.
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.
Product-first route
Read Chapters 1–13 if you want a complete operating guide. They move from first installation to parallel tasks, rich prompts, provider choice, workbench tools, source control, remote access, mobile supervision, device testing, personalization, usage, updates, and troubleshooting. No architecture knowledge is assumed.
Workflow-first route
Use Contents or search to jump directly to the relevant product chapter. The final product chapter includes complete recipes for local feature work, parallel worktrees, remote supervision, pull-request review, and device verification. Follow its links backward when a recipe needs setup or a feature decision.
Architecture-first route
Open The complete system map, then One request, every boundary. Continue with Chapter 16 to follow execution ownership, boot, RPC, authorization, the durable domain kernel, six providers, work lifecycle, clients, access routes, distribution, and operations.
From product questions to technical chapters
| Product question | Technical destination |
|---|---|
| Why can I close one client and continue elsewhere? | Turn lifecycle, projections, shared client runtime, and reconnect. |
| Why do providers expose different choices? | ProviderAdapter, provider instances, and the provider-specific chapters. |
| What exactly does revert restore? | Checkpoints and context ownership. |
| Why does remote setup belong to one machine? | Environment auth, access transports, and T3 Connect. |
| How can a simulator run on another host? | Device hosts, targets, sessions, and agent control. |
| Why can a thread hold several reviews? | Projections, workbench services, and source-control integration. |
Evidence labels
- Verified behavior is backed by executable code, a test, schema, migration, or workflow.
- Documented intent reports what a maintainer document says without turning prose into runtime behavior.
- Inference names a design consequence derived from cited evidence. The sources prove the inputs; the book owns the interpretation.
- Future / proposed is explicitly unshipped. A builder capability, community request, or idea is never called a supported feature.
Exact source cards are read from the locked Git object and show line numbers, checksum prefixes, and immutable permalinks. When documentation and executable behavior disagree, the book calls out the discrepancy and follows the executable contract for statements about behavior.