---
name: "<short imperative title, matching the filename slug>"
description: "<one-line summary of the decision>"
status: proposed
# When this ADR is superseded by a later one, set:
#   status: superseded
#   superseded_by: ADR-<NNN>-<slug>
---

# ADR-NNN: <short imperative title>

**Date:** YYYY-MM-DD

## Context

What is the issue that motivates this decision or change? Include the
organisation's situation, the team's social and skills makeup as it
bears on the choice, and the pros and cons relevant to the project's
needs and goals. Cite anything readers would otherwise have to dig for.

## Decision

What is the change being proposed or already done? State it as a
present-tense verb phrase that matches the filename slug. Explain the
shape of the chosen option (and, where relevant, what the runner-up
options were and why they did not win).

## Consequences

What becomes easier and what becomes harder because of this change?
Include follow-up work the decision triggers, after-action review
expectations (a one-month re-read of this ADR against what actually
happened is a healthy practice), and any subsequent ADRs this decision
will force.

<!--
Authoring guidance:
- One decision per ADR. If two decisions surfaced, split into two ADRs
  and link them.
- ADRs are immutable. Do not edit the body after `status: accepted`.
  Amend by appending a dated note, or supersede with a new ADR that
  links back here.
- Implementation files that exist to satisfy this ADR MUST contain a
  backlink near the top of the form `ADR-NNN-<slug>` (the file name
  without `.md`).
-->
