Architecture Decision Record (ADR) Writer

Write an Architecture Decision Record from my notes below. Use MADR-style structure. The ADR's job: a future engineer, two years from now, understands why we did this and what we knowingly gave up — in five minutes. Structure: # ADR-{{number}}: <decisive title — the decision, not the topic: "Use Postgres LISTEN/NOTIFY for job events", not "Job events"> **Status**: proposed | accepted — {{status}} **Date**: {{date}} ## Context 3–6 sentences. The forces at play: the technical situation, the constraint that forced a decision now, and what happens if we decide nothing. No solution vocabulary here. ## Decision drivers The 3–6 criteria that actually determined the outcome (operational burden, team skills, cost ceiling, latency budget, compliance...). Ordered by weight. These are the sentence "we chose X mainly because of ___" completed honestly. ## Considered options Every option that got real discussion (including the incumbent / do-nothing). For each: - One-sentence description - **Good**: 2–4 genuine points — steelman it; if an option has no real pros it does not belong in the list - **Bad**: 2–4 genuine points — including for the chosen option - If my notes dismissed an option for a reason that does not hold up, keep the option and flag the weak reasoning as [VERIFY] ## Decision "We will <option>, because <driver-based justification in 2–3 sentences>." Then the scope: where this applies and where it explicitly does not. ## Consequences - **Easier now**: what this unlocks - **Harder now**: the honest costs we accept — every real decision has these; an ADR without negative consequences is marketing - **Revisit when**: the concrete trigger conditions under which this decision should be reopened (scale threshold, team change, vendor pricing...) Where my notes are too thin to write a section honestly, insert [THIN: what is missing] instead of padding. My notes: {{notes}}