thuanleandClaude Opus 4.7
92121278bb
- ADR-0002: external rules pipeline architecture - README: updated flow to show safety checks → rules → dispatch - .env.example: added BLOCKLIST_EMAILS Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
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.
---
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 |
| 0002 | Ingress uses a configurable external rules pipeline before dispatch | active |