# Architecture Decision Records

This directory contains Architecture Decision Records (ADRs) for durable technical decisions in this repository.

## Purpose

ADRs capture cross-cutting or behavior-defining decisions that future contributors need to preserve.

Use an ADR when a change introduces or locks in a decision such as:

- runtime behavior that future work must preserve
- repository-wide technical policy
- architecture or integration contracts
- storage or threading semantics
- quality gate or workflow policy

Do not use ADRs for:

- temporary implementation plans
- agent execution checklists
- one-off debugging notes
- PR-local task breakdowns

## Format

Each ADR is a markdown file with YAML frontmatter.

```md
---
type: ADR
id: "NNNN"
title: "Short decision title"
status: active
date: YYYY-MM-DD
---

## Context

Why does this decision need to exist now?

## Decision

**State the decision clearly in one or two sentences.**

## Options considered

- **Option A** (chosen): description with pros and cons
- **Option B**: description with pros and cons
- **Option C**: description with pros and cons

## Consequences

What becomes easier?
What becomes harder?
What risks were accepted?
What would trigger re-evaluation?

## Advice

Optional. Capture important external input or review notes.
```

## Rules

- One decision per file.
- Name files `NNNN-short-kebab-title.md`.
- Once active, do not rewrite an ADR's meaning later. Supersede it with a new ADR instead.
- Keep the index below aligned with the current files in this directory.
- Do not keep placeholder or mock entries in the index.

## Index

| ID | Title | Status |
|----|-------|--------|
| 0001 | IMAP thread resolution prefers In-Reply-To and falls back to References | active |