Start heresource checked

How to read a changing system

The evidence rules, source labels, revision contract, and reading paths used throughout the book.

What this chapter resolves

Distinguish verbatim source, abridged source, diagrams, and interpretation.
Choose a linear, feature-first, or implementation-first reading path.
Understand what the pinned revision does and does not promise.

This is a field guide to a moving codebase. It therefore treats provenance as part of the interface, not a footnote.

fa219001dPinned source commit

1,844Production/build source files

533,213Production/build source lines

Four evidence labels

Verified behavior is backed by executable code, a test, schema, migration, or workflow at the pinned revision.
Documented intent reports what a maintainer document says without silently upgrading 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 future-work paragraph is never called a supported feature.

Exact source cards are a separate presentation device. Their code is read directly from the locked Git object—not the possibly dirty working tree—and shows real line numbers, a visible checksum prefix, and an immutable GitHub permalink.

packages/contracts/src/orchestration.ts:27–36 ↗verbatim · typescript · 654f6e0a

export const ORCHESTRATION_WS_METHODS = {
  dispatchCommand: "orchestration.dispatchCommand",
  getWorkflowScript: "orchestration.getWorkflowScript",
  getTurnDiff: "orchestration.getTurnDiff",
  getFullThreadDiff: "orchestration.getFullThreadDiff",
  searchThreads: "orchestration.searchThreads",
  getArchivedShellSnapshot: "orchestration.getArchivedShellSnapshot",
  subscribeShell: "orchestration.subscribeShell",
  subscribeThread: "orchestration.subscribeThread",
} as const;

Read this as: The book's source cards use the repository's actual line positions. These eight RPC names are the public orchestration surface on the pinned revision, not a reconstructed list.

Three reading paths

Linear: follow one task

Start with The request trace, then read the numbered chapters in order. This follows a user action from client state through authenticated RPC, commands, events, provider I/O, checkpoints, and back to every UI.

Architecture-first: map then zoom

Open The complete system map, choose a layer, and follow its cross-links. This is useful when you already know event sourcing, provider protocols, or Electron/React Native and want the unfamiliar seams.

Transfer-first: design another orchestrator

Read the ownership model, adapter boundary, domain kernel, connection runtime, and final transfer guide. Those chapters separate reusable patterns from choices that only make sense for T3 Code’s bring-your-own-subscription model.

Status words

Draft: structured and cited, but still awaiting a second source pass.
Source checked: claims and diagrams have been reconciled to the pinned checkout.
Verified: source checked, link checked, and reviewed in the end-to-end narrative.