adr_gatelisted

# ADR Gate — Architectural Decision Record discipline Apply this gate once at the END of any non-trivial implementation task, immediately before declaring "done." Most tasks will not produce an ADR — that is the correct and expected outcome. ## The bar is HIGH The default answer is: **no ADR needed.** An ADR is only warranted when a future contributor would be genuinely confused about *why* the system works a certain way — and that confusion would cost them real time or lead them to inadvertently break a structural invariant. **Do NOT write an ADR for:** - Bug fixes with no design decision (one obvious fix, no real alternative) - Pure refactors where behaviour is unchanged - Config value or threshold changes - Test additions or fixes - Documentation, comment, or copy changes - UI tweaks, renaming, small cleanups - Anything trivially reversible without data migration or cross-repo coordination ## Write an ADR only when BOTH conditions hold **Condition A — A real design choice was made:** You chose A over B, and that choice non-trivially constrains future code. There was a genuine alternative. **Condition B — At least one structural trigger applies:** - New or changed protocol, wire format, audit schema field, MCP tool contract, or CLI flag shape - New security or compliance mechanism (anything touching L10, L16, L34, L35, GDPR, EU AI Act) - Irreversible or hard-to-reverse default: fail-open/closed, deny/allow, opt-in/opt-out - Decision binds two or more repos (e.g. Corv