# ADR-0002 — Monorepo vs polyrepo for the six subsystems

- Status: proposed
- Date: 2026-05-24
- Workplan: CE-WP-0001-T07 (stub)

## Context

The umbrella-first MVP lives entirely in `citation-evidence/` under
`src/{shared,engine,anchor,source,binder,work,app}/`. Each folder is named
after its eventual extracted package. At some point — driven by an external
consumer needing one subsystem, or by independent release cadence — code
will move out into its sister repo.

We need a written answer to: when that moment comes, do we (a) keep one
repository with pnpm workspaces, (b) split into six independent repos with
published packages, or (c) something in between?

The decision affects: dependency management, release cadence, CI surface
area, contributor friction, and how `wiki/SharedContracts.md` is enforced
across the boundary.

## Options

- **A. Single repo, pnpm workspaces**
  - Pros: one CI, one version of every dep, atomic cross-package PRs, easy
    refactors. Shared contracts enforced by the type checker.
  - Cons: any consumer outside this repo needs a private registry or
    git-tag-based installs. Release cadence is shared.

- **B. Six independent repos, published packages**
  - Pros: clean external publish story, independent versioning. Forces the
    contract to be a real package boundary.
  - Cons: dependency upgrades require coordinated PR trains. Refactors that
    span subsystems become multi-repo dances. Hard to keep
    `SharedContracts.md` in sync across repos.

- **C. Hybrid — monorepo with publishable workspaces**
  - Pros: best of both: one repo for dev, but `pnpm publish` from any
    workspace package. Tools: changesets / nx / turbo.
  - Cons: more tooling to learn; per-workspace `package.json` cuts to
    maintain.

## Decision

(blank — to be answered before the first subsystem extraction lands.)

## Consequences

(blank)