1# Glossary
2
3Terms whose meaning matters across T3 Code. Architecture and lifecycle constraints belong in the
4[overview](./overview.md), not in these definitions.
5
6## Workspace and conversation
7
8| Term | Meaning |
9| -------------- | ------------------------------------------------------------------------------------------------- |
10| Environment | One running server and the machine, credentials, workspace access, and state it owns. |
11| Client | A web, desktop, or mobile UI connected to an environment. The desktop app can also host a server. |
12| Project | An environment-local workspace record rooted at a directory. |
13| Workspace root | The project's base filesystem directory on the environment. |
14| Worktree | A separate Git checkout a thread can use instead of the project's main checkout. |
15| Thread | The durable conversation and work history for a project. It survives provider process exits. |
16| Turn | One user-to-agent cycle, a V2 run. Provider work can end before checkpoint and diff work settles. |
17| Activity | A non-message timeline item, such as a tool action, approval, or failure. |
18| T3 home | The base data directory. Runtime state normally lives under its `userdata` directory. |
19
20## Orchestration
21
22| Term | Meaning |
23| ----------------------- | --------------------------------------------------------------------------------------------------------- |
24| Command | A request to change domain state. Accepting it does not mean its side effects have finished. |
25| Event | A persisted fact produced by a command. |
26| Orchestrator | The service that serializes commands and decides their events from current state, without I/O. |
27| Projection / read model | A persisted view of current state, committed in the same transaction as the events that change it. |
28| Command receipt | A durable record of a command's result, used to make retries idempotent. |
29| Outbox effect | Side-effect intent committed with the events, such as starting a provider turn or capturing a checkpoint. |
30| Effect worker | The worker that runs outbox effects after commit and feeds their results back as commands. |
31
32## Providers and checkpoints
33
34| Term | Meaning |
35| ------------------- | ------------------------------------------------------------------------------------------------------------ |
36| Provider | The agent runtime T3 Code controls, such as Codex or Claude Code. |
37| Driver | The integration for a provider kind. |
38| Provider instance | One configured provider, with its own settings and lifecycle. Multiple instances can use the same driver. |
39| Adapter | The boundary translating a provider's native protocol into T3 Code operations and events. |
40| Session | The provider runtime attached to a thread. A session can be stopped and resumed without deleting the thread. |
41| Runtime mode | The thread's permission policy. See [permission modes](../user/permission-modes.md). |
42| Interaction mode | How the agent approaches the task, such as planning. Separate from permission policy. |
43| Checkpoint | A saved workspace state used for diffs and restore, stored as a hidden Git ref. |
44| Checkpoint baseline | The workspace state captured before the work being compared. |
45| Turn diff | The workspace changes attributed to one turn. |
46
47## Pull requests
48
49| Term | Meaning |
50| -------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
51| Pull request link | A persisted thread association identified by host, repository, and number. Links can cross projects within an environment and carry a server-maintained snapshot. |
52| Pull request sync | The worker that refreshes each distinct linked review once per cadence and discovers native stack layers. Explicit refreshes and failed stack reads trigger another read. |
53| Current pull request | The link used by single-review controls and older clients. Open work takes precedence; a completed single chain points at its top layer. Unrelated terminal links use the latest update. |
54
55## Composer context
56
57| Term | Meaning |
58| -------------------- | ----------------------------------------------------------------------------------------------------------------------------------- |
59| Context record | The typed payload behind a composer chip, keyed by `contextId` in `message.context.records`. It never holds bytes. |
60| Context reference | One occurrence of a record in message text: `[label](t3-context://v1/<kind>/<contextId>)`. Several references can share one record. |
61| Attachment binding | The link from an image or file record to its server-owned attachment. Its attachment ID can change without changing `contextId`. |
62| Attachment inventory | The ordered image records shown as thumbnails above the prose, including images with no inline references. |
63
64See [composer context references](./composer-context-references.md) for the contract and lifecycle.