Decisions (ADRs)
The platform's load-bearing decisions are recorded as ADRs in the repo's
knowledge/decisions/adrs/ directory. This page is the index; each ADR is the durable "why"
behind a piece of the architecture.
| ADR | Decision | Status | Pages |
|---|---|---|---|
| ADR-001 | Backend stack: Fastify + Drizzle + Postgres | canonical | api |
| ADR-002 | Repo layout: pnpm workspace monorepo (Turborepo) | canonical | Platform map |
| ADR-003 | Frontend state: Zustand + TanStack Query | canonical | admin |
| ADR-004 | Plans become a DB-backed graph engine (editable + actionable) — supersedes file-based MDX plans | accepted | Plan Engine |
| ADR-005 | Tasks on the graph; GitHub issues kept synced (elimination deferred) | accepted | Plan Engine |
| ADR-006 | The effort workflow is the training-trace engine; GitHub is SoT; MDX plans retired | canonical | Effort model |
| ADR-007 | Per-client data / memory / assistant — 4 layers; schema-per-client + pgvector | canonical | Data, memory & assistant |
How the recent ADRs connect
- ADR-004 → ADR-005 → ADR-006 is one through-line about our dev workflow. Plans moved from files to a graph (004), tasks followed (005), and the effort model made that workflow doubly useful — it is also a training-trace corpus for a future builder model, with GitHub as the operative source of truth (006). See Plan Engine and Effort model.
- ADR-006 → ADR-007 draws the product/workflow boundary at the data layer: tenant/client data (ADR-007's four layers) lives in a separate database from the dev-workflow graph and never enters the training corpus. See Product SoR and Data, memory & assistant.
Reading the ADRs
The ADRs themselves live in the repo (knowledge/decisions/adrs/), each with status / owner /
updated frontmatter and a Context → Decision → Consequences structure. The running decision log
(knowledge/decisions/log.md) is the tie-breaker when two docs conflict: the latest decision wins.