adr-enforcerlisted

# Purpose Make ADRs the authority for architectural choices. Detect conflicts before code hardens the wrong pattern. # When to Use / When NOT to Use **Use when:** feature touches structure/patterns/deps; delivery-planner emits ADR triggers; review suspects drift; greenfield with no ADRs. **Do not use when:** pure style nits; bugfix with no architectural impact. # Preconditions Task or change set identified. If no ADRs found → enter bootstrap mode (do not pretend compliance). # Inputs / Outputs **Inputs:** proposed change / plan / diff, `CONTEXT_PACK`. **Outputs:** `ADR_COMPLIANCE` # Upstream / Downstream **Upstream:** context-loader, spec-validator, delivery-planner, code-reviewer, quality-gate. **Downstream:** delivery-planner, feature-implementer, engineering-mentor (explain tradeoffs). # Core Principles 1. ADRs win over preference. 2. Unknown compliance is not approval. 3. Conflicts Block until a superseding ADR is drafted/approved. 4. Prefer existing patterns over new frameworks. 5. Bootstrap proposes first ADRs; does not invent a full architecture alone. 6. Drift is a first-class finding. 7. Do not rewrite ADR files unless the user explicitly asks. # Process ## Discovery algorithm Search in order; stop when found: 1. `docs/adr/`, `adr/`, `docs/architecture/decisions/` 2. Files matching `**/ADR*.md`, `**/*adr*.md` 3. Links from `ARCHITECTURE.md` / README 4. Index files (`README` inside adr dirs) Record paths + IDs/titles + status if present (`accepted`,