ADRs are the durable architecture register for Mission.

Read them when a change touches ownership, naming, state, runtime behavior, repository initialization, Open Mission surfaces, compatibility policy, or documentation authority. Each ADR carries frontmatter so the docs site and architecture skills can treat decisions as structured records.

CONTEXT.md defines the canonical language and relationships. ADRs define the durable rules and trade-offs behind that language. The old specifications corpus has been removed from the active docs tree after its relevant architecture was registered here.

Register Map

Accepted ADRs are binding architecture law. Proposed ADRs are active design candidates and must not be treated as settled rules until their status changes.

ADR numbers use a decimal registry key. The four-digit prefix identifies the architecture family; the decimal suffix orders focused subdecisions inside that family. Families are structural, not chronological: move a decision when its owner, authority level, or subject boundary changes. Use gaps in suffixes only when inserting a decision between existing decisions would clarify the registry.

The register is ordered from system-wide authority to domain contracts, repository control, Mission runtime, daemon services, operator surfaces, and AgentExecution behavior. That order mirrors Mission’s ownership model: durable authority first, runtime coordination next, presentation and adapter-specific interaction after the owning model is clear.

0000 Architecture Governance

System-wide rules for how Mission changes are allowed to evolve. These ADRs constrain the register itself and the discipline used when replacing architecture.

0001 Entity Model And Contract Architecture

Canonical Entity identity, schema roles, class authority, naming, and Entity command contracts. Put decisions here when they define shared domain object structure or cross-boundary Entity contracts.

0002 Repository Control And Setup

Repository-scoped control state, initialization, and repository workflow defaults. Put decisions here when the Repository is the owner before any Mission instance starts.

0003 Mission Runtime And Workflow Law

Mission runtime data, Mission record-backed persistence, State store write rules, and repository-owned workflow law applied by a Running Mission instance. Put decisions here when they govern Mission execution state rather than Repository setup or daemon-wide service supervision.

0004 Daemon Runtime And System Services

Daemon-owned live runtime supervision, system snapshots, and derived services that support Mission or AgentExecution without becoming their domain truth. Put decisions here when the daemon service is the owner and the model is reusable across repository, Mission, or AgentExecution scopes.

0005 Open Mission App And Operator Surfaces

Open Mission app boundaries, host responsibilities, surface-local preferences, and operator-facing read or command surfaces. Put decisions here when a surface reflects or submits daemon-owned truth without owning the underlying domain law.

0006 AgentExecution Model, Interaction, And Adapter Surface

AgentExecution identity, context, structured interaction, transport, persistence, semantic operations, adapter capabilities, and Agent-facing command surfaces. Put decisions here when AgentExecution is the owner or the decision defines how adapters and tools interact with AgentExecution.

Proposed Decisions

Proposed decisions keep their structural family number, but stay outside the accepted family list until accepted.

Table of contents