Skip to content

Latest commit

 

History

History

Folders and files

NameName
Last commit message
Last commit date

parent directory

..
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

README.md

Architecture Decision Records

ADRs record durable decisions. The code cannot explain these decisions alone. Each record is a short markdown file. The file has a date. The file has a number in creation order (NNNN-kebab-title.md).

When to add an ADR

Add a record when a decision is:

  • load-bearing — changing it breaks correctness, portability, or a frozen contract.
  • non-obvious — a reader cannot reconstruct the reasoning from the code alone. For example: why a specific ort feature flag is pinned, why a cursor is monotonic, why two resampler caches must not be shared.

Do not add an ADR for clear code. Do not add an ADR for release history. Release history lives in CHANGELOG.md. Do not add an ADR for frozen IPC interfaces. Frozen IPC interfaces live in docs/references/contracts/.

Format

# ADR NNNN — <imperative title>

Date: YYYY-MM-DD
Status: accepted | superseded by NNNN | deprecated

## Context

<one paragraph: the problem and the forces that make it non-obvious>

## Decision

<one paragraph: what we chose>

## Consequences

<bullet list: what this forces on future code, and what it rules out>

Writing rules

Write new ADRs in ASD-STE100 Simplified English. See docs/agents/engineering.md for the rules. Use short sentences. Use active voice. Use one topic per sentence. Use one word for one meaning.

Do not rewrite accepted ADRs. To supersede one: write a new ADR, then change only the old ADR’s Status line (for example to superseded by NNNN). Leave every other line of the old ADR untouched. Do not delete accepted records.

Index