Glossary

The smallest unit of executable work. One task should correspond to one PR. Bounded by a concrete size limit as per document types. The full domain treatment — sizing limits, discovered tasks, ready/done — is on the Tasks page.

A coherent user-visible outcome, composed of one or more tasks. The unit of sprint planning. The full domain treatment — themes and epics, sizing, ready/done, cross-sprint continuations — is on the Stories page.

A bounded period of work delivering a set of stories aligned to a sprint mission. Closes with a release.

A one-sentence statement of what the sprint exists to achieve. Used to filter candidate stories.

The artefact a sprint produces when it closes — a tagged build plus release notes capturing the sprint's landed work. The release is the upward signal that work happened (per cybernetic levels information flow). Every sprint cuts a release; not every release ships a version — version-level release decisions sit with System 4.

The named major release target that a version series works towards. A milestone owns the what and why: identity, theme, mission, definition of done, and time horizon. It does not contain sprints — that is the version's job. When the milestone's definition of done is met, the current version series closes and the software cuts the milestone release (e.g. 1.0.0). The next version series then begins.

A release series — a coherent set of sprints producing incremental builds (e.g. 0.0.x, 1.0.x) as it works towards a target milestone. The version name matches the CMake MAJOR component: v0 produces 0.x.x builds; v1 produces 1.x.x builds. A version does not carry a mission statement of its own — that lives in its target milestone.

Deprecated. Identity now lives in the target milestone document, not in the version. See the * Identity section of Milestone v1.0 for the current example.

The durable statement of what ORE Studio is and is not. Used to filter candidate versions, far captures, and feature requests.

A named role that operates the system — what someone (or some LLM session) does when they are wearing a given hat. Each function doc is the priming context an LLM session loads when it takes on the role: its purpose, what to pre-read, which skills to invoke, what not to do. Functions are role-shaped (descriptive); skills are task-shaped (operational). Functions compose skills; skills do not own functions.

A concrete, executable capability — how to do a kind of work — in Claude Code's skill format (doc/llm/skills/<slug>/SKILL.org). Each skill is self-contained: it describes when to use it, the procedure, and any artefacts it expects. A skill is task-shaped: invokable in one session to perform a unit of work. Contrast with function, which is role-shaped: a description of what someone does, listing the skills that role draws on.

A how-to document answering one operational question. Has executable scripts where applicable. Tested by CI.

A named, repeatable composition of recipes and skills into a complete multi-step procedure. Owned by System 2 (Orchestrator) — it coordinates S1 operations into higher-level runbooks. Lives under doc/llm/runbooks/.

A durable factual document about the domain, architecture, or components. Not state, not process — just facts that outlive any sprint.

A transient implementation strategy for a single task or story. Lives next to the work as the * Plan section inside that document. Distilled into the parent story's * Decisions when the work closes; the * Plan section is then cleared. Plans do not outlive their task.

Work spotted in passing while executing another task. Filed without triage in DISCOVERED state; must leave DISCOVERED within one orchestrator session (see lifecycle).

A TODO state, not a folder. Tasks and stories in BACKLOG have been triaged but not started. The product backlog (work not yet pulled into a sprint) lives separately under agile/product_backlog/{inbox,next,deferred,discarded}/ as a tree of captures.

A pre-sprint idea: something we may want to do but have not yet pulled into a sprint as a story. Captures live within the capture document in a sprint, if long-lived. New captures land in inbox/ (untriaged); at triage they move to next/ (candidate for the next version), deferred/ (longer-term wishlist), or discarded/ (explicitly rejected). Captures are not stateful — no TODO keyword, no * Status table. They have only two effective states: pending (the file exists in a bucket) and promoted (the file has been converted into a story). On promotion the file is moved into the appropriate sprint folder and its #+type: flips from capture to story; the :ID: is preserved so existing links keep working.

A short, durable note an LLM session writes for the benefit of future sessions — feedback the user gave, a fact about them, a fact about the work in flight, or a pointer to an external system. One memory per file under doc/llm/memory/; carries #+type: memory and a #+memory_subtype: of feedback, user, project, or reference. Memory captures how to work together; code-derivable facts and architecture belong in knowledge instead.

A formal historical record of a technical investigation. Captures the original problem, the methodology used, paths explored (including failures), and conclusions reached. Designed to preserve knowledge and context for future sessions. See document types for the full contract.

The TODO keyword on a stateful document's * Status headline. The full vocabulary is DISCOVERED BACKLOG STARTED BLOCKED | DONE ABANDONED (active states left of the bar, terminal states right). Documents that are not stateful (knowledge, recipes, functions, meta) have no Status headline. See lifecycle for transitions.

The * Status headline inside a stateful document. Carries the TODO keyword (state) and four subheadings (** Now, ** Waiting on, ** Next, ** Last touched) that describe the live operational detail. Updated every time an orchestrator or agent acts on the document.

A story in a prior sprint that the current story continues. Captured as #+predecessor: <id> frontmatter plus a Continued from: [[id:...][...]] line in the body. See cross-sprint stories in lifecycle.

A story in a later sprint that picks up where this one left off. Captured as #+successor: <id> frontmatter plus a Continued in: [[id:...][...]] note in * Decisions. Audit verifies bidirectional linkage.

A subprocess forked by a System 2 orchestrator LLM to execute one task. Operates at System 1. See execution model for the role and S1 Agent function for the priming context.

The System 2 LLM session the user has assigned to a story. Forks agents, reviews their output, decides what to do with discovered work. See S2 Orchestrator function for the priming context.