Architecture decision records¶
Why the system is the way it is. An ADR records one decision with its context, the alternatives that were
rejected and the consequences; its status (accepted, with caveats where something is not yet verified) is the
first thing in each record. A change to a byte format, to merge semantics or to the wire protocol needs a new ADR
(see CONTRIBUTING). Which decision is exercised by
which test: ADR traceability.
| ADR | Decision |
|---|---|
| 0001 | The overall architecture after the critical audit (in Russian, the historical record) |
| 0002 | Embedded engine first; SQLite as the first metadata backend |
| 0003 | Sparse derived-tree cache (keyframes) |
| 0004 | PostgreSQL metadata and S3-compatible objects behind the existing seams |
| 0005 | Rename-aware tree merge |
| 0006 | Flat trees: measured costs, optimizations, and when to go hierarchical |
| 0007 | Several ag-server replicas on one PostgreSQL and one bucket |
| 0008 | ag-mcp: the remote workflow as a Model Context Protocol server |
| 0009 | An identity's name cannot start with the run separator |
| 0010 | Credentials bound to a run, a delegator role, operator calls on tasks and runs |
| 0011 | Proposal paging indexes (metadata schema 3), dated idempotency records, a lease for background work |
| 0012 | A fencing token for job claims (an optional request field, no schema change) |
| 0013 | Directory renames in the tree merge (ag-merge/3); copy detection for blame and show |