architecture-decision-designlisted

# Architecture Decision Design Use just-enough upfront design followed by explicit, reversible decisions. The goal is a shared model that supports change, testing, security and operation, not a diagram that merely decorates documentation. ## Workflow 1. Inspect existing architecture docs, diagrams, decision numbering and quality attributes. Preserve established IDs and terminology. 2. State the problem, drivers, constraints, stakeholders, system boundary and level of certainty. 3. Choose the smallest useful view: C4 context for actors/systems, container for deployables, component for one container, sequence for a critical interaction, deployment for topology, ER for data. 4. Identify alternatives and evaluate them against measurable quality attributes: security, reliability, performance, operability, maintainability, scalability, usability, cost and compliance as relevant. 5. Write an ADR with status, context, decision, alternatives, consequences, risks, validation and links to work/tests/threats. 6. Validate diagram syntax, links, names, ownership and consistency with implementation; flag unknowns instead of inventing details. ## ADR template ```markdown # ADR-<id>: <decision> - Status: proposed | accepted | superseded | rejected - Date: <YYYY-MM-DD> - Owners: <people/team> - Related work: <FR/REQ/SEC/TC IDs> ## Context ## Decision ## Alternatives considered ## Consequences ## Security and privacy impact ## Operational and testing impact ## Validation and review ## Sup