Project
Architecture decision records
An ADR records one significant decision: the situation, what we chose, what it costs, and what we rejected. They explain why the code looks the way it does. The overall design is in architecture.md.
| ADR | Title | Status | Date |
|---|---|---|---|
| 0001 | Curated task tools, toolsets and a read-only generic GET | Accepted | 2026-11-07 |
| 0002 | Hand-written zod schemas instead of types generated from the spec | Accepted | 2026-11-07 |
| 0003 | Permission tiers and human confirmation | Accepted; browser mode over HTTP amended by 0007 | 2026-11-07 |
| 0004 | stdio by default, stateless remote HTTP with OAuth | Superseded by 0006 | 2026-11-07 |
| 0005 | Trunk-based development and automated releases | Accepted | 2026-11-07 |
| 0006 | Built-in authorization server and a small grant store | Accepted | 2026-11-09 |
| 0007 | Approval inbox over HTTP | Accepted; browser sessions amended by 0008 | 2026-11-09 |
| 0008 | File transfer over HTTP | Accepted | 2026-11-09 |
| 0009 | Local profiles and the OS keychain | Accepted | 2026-11-09 |
Writing a new ADR#
- Copy the structure of an existing ADR into
NNNN-short-title.mdwith the next free number. - Sections: Status (
Proposed,Accepted,Superseded by NNNNorRejected), Date, Context, Decision, Consequences, Alternatives considered. Keep it short and cite sources as links. - Open it as a PR with status
Proposed. It becomesAcceptedwhen merged. - Do not rewrite an accepted decision. If it changes, write a new ADR that supersedes it and update the old one's status line only. If the new ADR changes only part of it, the old status line says which part it amends (as 0003 does).
- Add the ADR to the table above.