# ADR-NNNN: {Title}

**Status:** {Proposed | Accepted | Deprecated | Superseded}
**Date:** {YYYY-MM-DD}

## Context

{What is the issue that we're seeing that is motivating this decision or
change? Include enough background that a reader 12 months from now can
understand WHY this decision was needed without reading the surrounding
codebase. Cite empirical evidence, prior decisions, or codebase artifacts
where possible.}

## Decision

{What is the change that we're proposing or have agreed to implement?
State the decision in declarative terms — what WILL be done, not what
might be considered.}

## Consequences

{What becomes easier or harder to do because of this change? Enumerate
both the positive and negative consequences. The Nygard form is
deliberately neutral — you list both upsides and downsides so a future
reader can weigh whether the trade-off still holds.}

---

## Nygard 3-gate filter (audit trail)

This ADR was written via `apt-tools adr write` and passed all three of
Nygard's filter gates. If any one had failed, the decision would have
stayed in `.aperant/context/notes/{task-id}.md` and no ADR file would
have been created. The filter prevents ADR pollution — only durable,
surprising, trade-off-bearing decisions become ADRs.

- **Hard to reverse:** {true | false} — Could this be undone in a single
  PR if we changed our minds in 6 months? If "yes, easily" → not an ADR.
- **Surprising without context:** {true | false} — Would a new
  contributor reading the code be surprised by this choice and want to
  know why? If "no, this is the obvious approach" → not an ADR.
- **Real trade-off:** {true | false} — Did we genuinely consider an
  alternative and pick the worse-along-one-axis option for a
  better-along-another? If "no, no alternative was real" → not an ADR.

Reversible decisions, obvious decisions, and trade-off-free decisions
all stay in context-notes — they survive the task but don't deserve a
permanent ADR slot.
