ADRs
Architecture Decision Records
This section stores Architecture Decision Records (ADRs) made at the Florete project.
What Is an ADR?
An ADR represents a significant architectural decision, its context, rationale and consequences. Think of it as a "decision log" for why our systems are built in a certain way.
Current ADRs
| Number | Title | Status | Date |
|---|---|---|---|
| 0001 | Record ADRs | Accepted | 2026-03-26 |
| 0002 | Use Single-Crate Project | Accepted | 2026-03-27 |
| 0003 | Use DI Framework | Accepted | 2026-03-29 |
| 0004 | Use Single Tokio Runtime for C1 | Accepted | 2026-03-31 |
Proposing a New ADR
Copy template.mdx to XXXX-short-title.mdx (next sequential number)
Fill in the template
Update the table of ADRs above and in meta.json
Submit a PR for review
The document title should begin with a verb in the infinitive form: it should answer the question "what to do?", i.e., what decision was made. To reference architectural decisions, use the form ADR-XXXX: Title with a link if necessary. For example:
[ADR-0001: Record ADRs](https://florete.tech/docs/contributing/adr/0001-record-adrs/)ADR Statuses
- Proposed — Under discussion
- Accepted — Decision made and implemented
- Rejected — Decision considered and rejected (such ADR must refer to the reason for rejection)
- Obsoleted by
[ADR-XXXX: Title](link)— Updated or replaced by newer ADR
How Statuses Are Assigned
For straightforward decisions with clear consensus, ADRs may be submitted directly with Accepted status. If a decision requires extended community discussion or experimentation, start with Proposed and update to Accepted or Rejected once resolved. When a newer ADR supersedes an existing one, update the older record's status to Obsoleted by [ADR-XXXX: Title](link) to maintain a clear decision lineage.
Status workflow
Simple decisions — start as Accepted.
Controversial or exploratory ones — start as Proposed.
When superseding — mark previous ADR as Obsoleted by [ADR-XXXX: Title](link).