Essential session storage is required to sign in. Optional analytics remain off unless you allow them.
Pick a real architectural decision for a system you know or invent (e.g. 'monolith vs microservices for our MVP', 'PostgreSQL vs DynamoDB for the catalog', 'sync REST vs async events between two services'). Write a proper ADR in the Nygard format: Title, Status, Context (the forces and constraints at play), Decision (what you chose), and Consequences (what becomes EASIER and what becomes HARDER). Tie the decision to the system's driving quality attributes, present at least two options you considered, and be honest about what you give up.
Correct Nygard sections (Title/Status/Context/Decision/Consequences); reads as a record that could be numbered and committed with the code.
Real options compared; consequences list BOTH what gets easier and harder; decision tied to driving quality attributes, not hype.
Context captures the actual forces/constraints so a future reader understands WHY, not just what.
Concise and unambiguous; status set appropriately (proposed/accepted).
Use this README structure to make the work reviewable.
DevPath fetches a read-only, size-capped snapshot. Submitted code is never executed.
# Write an Architecture Decision Record for a real choice ## Goal Pick a real architectural decision for a system you know or invent (e.g. 'monolith vs microservices for our MVP', 'PostgreSQL vs DynamoDB for the catalog', 'sync REST vs async events between two services'). Write a proper ADR in the Nygard format: Title, Status, Context (the forces and constraints at play), Decision (what you chose), and Consequences (what becomes EASIER and what becomes HARDER). Tie the decision to the system's driving quality attributes, present at least two options you considered, and be honest about what you give up. ## Acceptance criteria - [ ] ADR format: Correct Nygard sections (Title/Status/Context/Decision/Consequences); reads as a record that could be numbered and committed with the code. - [ ] Trade-off honesty: Real options compared; consequences list BOTH what gets easier and harder; decision tied to driving quality attributes, not hype. - [ ] Context quality: Context captures the actual forces/constraints so a future reader understands WHY, not just what. - [ ] Clarity: Concise and unambiguous; status set appropriately (proposed/accepted). ## Verification - [ ] Document installation and run commands. - [ ] Record automated checks and their exact commands. - [ ] Add representative output, screenshots, or a short demo where useful. - [ ] Confirm failure paths and known constraints. ## Decision log ### Decision title - Context: - Choice: - Alternatives considered: - Tradeoffs: ## Evidence - Link each rubric criterion to the file, test, or artifact that demonstrates it. ## Known limitations - List what is intentionally out of scope and what should be improved next.