adrlisted

<!-- managed-by: harness-setup --> ## When to Trigger - "Create an ADR for..." - "Document this architectural decision" - "Why did we choose X over Y — write it down" - "Record the decision about..." - "ADR for the authentication strategy" - "Document this trade-off" - "We decided to use X, create the record" ## Overview Architecture Decision Records (ADRs) capture significant architectural choices alongside their context and consequences. They are stored in `docs/decisions/` and numbered sequentially so the history of decisions is traceable. An ADR is warranted whenever a decision: - Has long-term impact on the codebase or team - Involves meaningful trade-offs between alternatives - Would otherwise be lost in a commit message or verbal discussion ## Workflow ### 1 — Determine the next ADR number List existing files in `docs/decisions/` and find the highest `ADR-NNN` number. The new ADR uses the next sequential number. ``` docs/decisions/ ├── ADR-001-database-choice.md ├── ADR-002-authentication-strategy.md └── ADR-003-multi-tenancy-approach.md ← next would be ADR-004 ``` If `docs/decisions/` does not exist, create it. ### 2 — Write the ADR Use this exact format: ```markdown # ADR-NNN — Title **Status:** Proposed | Accepted | Deprecated | Superseded by ADR-XXX **Date:** YYYY-MM-DD ## Context What is the situation, constraint, or problem that forced this decision? Include relevant background: team size, scale, existing technology, time pressure. ## Decision