Combobulating

Architecture Decision Records

This directory holds Aura’s Architecture Decision Records (ADRs) in MADR format.

Why we keep ADRs

An ADR captures one non-trivial decision, the context that forced it, the chosen option, the consequences, and the alternatives that were rejected. We write one when a decision will outlive a single sprint, when it constrains future engineering choices, or when reversing it would be expensive.

ADRs let a future contributor (and a Samsung judge in Phase 2) reconstruct why the system is shaped the way it is without reading every commit. They also force clarity at decision time — if the decision can’t be written down in five sections it usually isn’t a decision yet.

Format — MADR

Every ADR in this directory uses the MADR template:

Sections are required. Empty sections are not allowed; “no alternatives considered” is itself an answer that has to be defended.

How to add an ADR

  1. Pick the next four-digit number. The current highest is 0011.
  2. Create ADR-NNNN-<short-slug>.md. Slug is lowercase, hyphen-separated, six words or fewer.
  3. Fill the five sections. Keep total length under 800 words. Cite specific lines of plan.md or technical_spec.md if the decision derives from them.
  4. Open a PR titled docs(adr): NNNN <slug>. Two reviewers required (contributing.md).
  5. Once merged, link the ADR from the relevant code or doc surface. Decisions about agent contracts go on the agent’s docstring; decisions about UI rules go on the relevant view; decisions about platform strategy go in architecture.md §7.3.

Index

Superseded ADRs

When an ADR is replaced, set its Status to Superseded by ADR-NNNN and add a one-line forward link at the top. Do not delete superseded ADRs — they explain why the current shape exists.

End.