Eleven records, each stating a context, a decision, its consequences, and what it rejected. They are the canonical answer to "why is it built this way" for the choices they cover.
An ADR is a record of a decision at a point in time, so its status line is historical. Several
were accepted during Phase 0 dependency characterization, before the adapter code existed, and say
so. The decision still stands; the current implementation status is in
requirements/ledger.yaml and, in prose, on the plane page for
that concern.
Three patterns run through all eleven, and they are worth reading across rather than one at a time:
- A pinned upstream, consumed as a release. Exact versions, never ranges or path dependencies; the framework adapts rather than forks.
- The contract stays framework-owned. Engine types never appear in a public interface, and the conformance kit — not a bespoke test — is what proves an implementation interchangeable.
- A gap in an upstream is mitigated in the adapter and recorded as debt, not designed around by changing the contract. The RVF integrity manifest and the RuVector tenant pre-filter are the clearest cases.
- ../explanation/why-adapters.md — the rules these records instantiate, with the current inventory.
- ../reference/verification.md — the ledger, gates, and evidence that say what is implemented today.
- ../../.agents/DEBT.md — the debt register the statuses above refer to.
- ../documentation-map.md — which page owns which concept.
