States: accepted when derived from an explicit requirement; proposed when it needs the user's acceptance. Accepting an ADR does not mean implementing it. Superseded ADRs remain in the history, with a link to the successor.
| ADR | Topic | State |
|---|---|---|
| 0001 | Stack, dashboard and shadcn/ui | Accepted by requirement; partially implemented |
| 0002 | Modular monolith with separate worker | Proposed |
| 0003 | Google-only login | Accepted by requirement; implementation pending |
| 0004 | PostgreSQL, outbox and financial precision | Proposed; PostgreSQL already confirmed |
| 0005 | Railway deploy | Accepted by requirement; proposed topology |
| 0006 | Data, extensions and messaging | Proposed |
| 0007 | Paper-first and deterministic execution | Paper-first accepted; details proposed |
| 0008 | Brazil and US in the MVP | Accepted; providers pending |
| 0009 | Personal terminal and single account | Accepted |
| 0010 | Alpaca Paper US and B3 simulator | Implemented; external validation pending |
| 0011 | Defaults and autonomous implementation | Accepted by later instruction |
| 0012 | Persistence effectively implemented | Implemented; details/updates ADR-0004 |
| 0013 | Polling, leadership and Railway standby | Implemented |
| 0014 | Current Railway API and portable Dockerfile | Implemented during publication |
Each ADR must record context, decision, alternatives, consequences and review trigger. Brazil and US and personal use are confirmed; Alpaca Paper, the internal B3 simulator and admission of one account are also. IEX and B3 CSV were adopted by delegation; credentials/datasets remain external.