Skip to main content
Status: Proposed (RECONSTRUCTION — requires validation) · Date: 2026-08-17 (reconstructed) Refs: ../constitution/founding-constitution.md
⚠️ Reconstructed from the material we have, not recovered. Tags: [derived] is supported by evidence in the repository · [inferred] is deduced · [proposed] is a gap I filled.

Context

A suite of modules sharing a database, an auth realm and a deployment story can live in one repository or several. Several repositories give independent release cycles at the cost of version skew between packages that must agree — the schema, the API client, the permission registry. Separately, an agent-heavy codebase has a specific failure mode: every agent that meets a problem reaches for a new library, and within months the dependency list is nobody’s decision. [inferred]

Decision

One monorepo, one lockfile, one version. [derived] Cross-project imports go through workspace packages, never relative paths across boundaries. The stack is closed. [derived] A new vendor or dependency requires an ADR before its first import, no exceptions, including for adapters. Upgrading an existing dependency does not; replacing one does. Versioning is CalVer YYYY.M.PATCH across every project. [derived]

Consequences

  • The schema, the API client and the permission registry cannot disagree, because they ship together.
  • The dependency list stays a set of decisions rather than an accumulation. − Every genuinely new dependency costs an ADR. That friction is the feature.

What I could not determine

Whether the original ADR also covered the package manager and the task runner, or whether those were tooling choices made without one. [proposed] — I have assumed they were not ADR-worthy.