architectural-decision-recordlisted

# Architectural Decision Record ## Purpose and boundary Create a durable record for a consequential architecture, platform, data, security, or workflow decision. An ADR captures why a choice was made, what it costs, what evidence supports it, and when it should be revisited. It is not an implementation plan, a design specification, or proof that the chosen option has already been approved. Default to an authorized draft in `docs/adr/`; do not modify application code, silently create architecture policy, expose private discussions, or mark a proposal accepted without the actual decision owner. Preserve uncertainty and label inferred reasoning. Never copy secrets or private customer information into an ADR. ## Decision contract Before writing, identify: - one decision question and the consequence of delaying it; - context, constraints, goals, non-goals, scope, and affected systems/people; - decision owner, authors, reviewers, date, target revision, and expiry/review trigger; - observed evidence, assumptions, unknowns, and confidence for each important claim; - alternatives considered, evaluation criteria, rejected rationale, and decision boundaries; - status: Proposed, Accepted, Rejected, Superseded, or Deprecated; - consequences, migration/rollback implications, validation signals, and follow-up owners. If the decision question or owner cannot be determined, create a clearly marked framing draft or report the missing input. Do not fill required fields with plausible nam