Architecture Decision Records
ADRs document significant architectural decisions, their context, and consequences. They are living documents stored in .context/decisions/ and synced here by CI.
info
ADRs are never deleted. Superseded decisions get status: superseded with a pointer to the replacement. The full history is preserved.
All decisions
| ADR | Title | Status | Tags |
|---|---|---|---|
| ADR-001 | Single monorepo over multi-repo | Accepted | architecture, repository, agents |
| ADR-002 | Bazel with staged adoption | Accepted | build, tooling, bazel |
| ADR-003 | Monolith-first backend | Accepted | architecture, backend, deployment |
| ADR-004 | ML as top-level workspace | Accepted | architecture, ml, python |
| ADR-005 | PostgreSQL+JSONB for KG MVP | Accepted | architecture, database, knowledge-graph |
| ADR-006 | Task files + cascading context | Accepted | agents, context, workflow |
| ADR-007 | public/ for publishable packages | Accepted | architecture, cli, packaging |
Process
To propose a new ADR:
- Copy
.context/decisions/TEMPLATE.md→.context/decisions/ADR-NNN-slug.md - Fill in context, decision, alternatives, and consequences
- Submit a PR — discussion happens in the review
- After acceptance, CI syncs the ADR to this docs site
See the spec-driven development workflow for how ADRs fit into the broader development process.