generated from coulomb/repo-seed
tegwick
747afc27a6
Aligns the v1 architecture with the longer-horizon platform thesis so we can start implementation without the schema-level inconsistencies the prior review surfaced. ADRs (docs/adr/0001..0006): content-addressed dual-digest storage, append-only event log as source of truth, canonical CBOR manifests, control/data-plane contract, v1 tech stack (Python 3.12 / uv / FastAPI / SQLAlchemy Core + asyncpg / Alembic / cbor2 / blake3 / ruff / mypy / pytest / typer), OCI compatibility kept reachable. Architecture blueprint rewritten to v2: library-first (ffmpeg-shaped) module layout, materialised-view data model over the event log, upload-session and event-stream endpoints pinned, retrieval tiering promoted into the schema. Roadmap added (docs/ROADMAP.md) with three phases. WP-0001 rewritten as the Foundation plan (scaffold + kernels + local FS + minimal app). WP-0002..0005 created carrying the existing state_hub_task_ids forward semantically: ingestion API (T004), retention lifecycle (T005), S3-compatible backend (T006), guide-board pilot (T007). T001/T002/T003/T008 remain in WP-0001 with refined acceptance. README and AGENTS.md refreshed to reflect the new repo shape. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
33 lines
1.7 KiB
Markdown
33 lines
1.7 KiB
Markdown
# Architecture Decision Records
|
|
|
|
This directory holds the architectural decisions that govern `artifact-store`.
|
|
Each ADR is a small Markdown file with a status (`proposed`, `accepted`,
|
|
`superseded`, `deprecated`), a concise statement of the decision, the
|
|
forces that pushed it, and the consequences.
|
|
|
|
ADRs are the canonical home for "we are doing X" statements that survive
|
|
multiple workplans. `INTENT.md` says what we build; `SCOPE.md` says where
|
|
the boundary is; `docs/PLATFORM-AMBITION.md` says where we are pointed;
|
|
ADRs say how — and they are the only document that records a *changeable*
|
|
decision in a form that can be superseded cleanly.
|
|
|
|
Workplans cite the ADRs they depend on. The architecture blueprint cites
|
|
the ADRs it operationalises.
|
|
|
|
## Index
|
|
|
|
- [ADR-0001 — Content-Addressed Storage with Dual Digest](0001-content-addressed-storage.md) — accepted
|
|
- [ADR-0002 — Append-Only Event Log as Source of Truth](0002-event-log-source-of-truth.md) — accepted
|
|
- [ADR-0003 — Manifest Canonicalisation = Canonical CBOR (RFC 8949 §4.2.2)](0003-manifest-canonical-cbor.md) — accepted
|
|
- [ADR-0004 — Control Plane / Data Plane Contract](0004-control-plane-data-plane-contract.md) — accepted
|
|
- [ADR-0005 — V1 Technology Stack](0005-v1-tech-stack.md) — accepted
|
|
- [ADR-0006 — OCI Artifact Compatibility Kept Reachable](0006-oci-compatibility-reachable.md) — accepted
|
|
|
|
## Conventions
|
|
|
|
- Filenames: `NNNN-kebab-case-slug.md`, numbered in acceptance order.
|
|
- Status transitions: `proposed → accepted → (superseded | deprecated)`.
|
|
- Supersession is explicit: the new ADR links the old; the old ADR links
|
|
forward and changes status. Never delete an ADR.
|
|
- Each ADR is short. If it is long, it is wrong: split it.
|