generated from coulomb/repo-seed
T01 Toolchain — vite + pnpm 9.15 + React 18 + strict TS (ADR-0001).
T02 Folder layout — src/{shared,engine,anchor,source,binder,work,app}/
mirroring the future subsystem split, with path aliases.
T03 Boundary lint — eslint-plugin-boundaries enforcing the dependency
edges from wiki/DependencyMap.md §4; verified by a violating fixture.
T04 Canonical normalization v1 — src/shared/text/normalize.ts with
NORMALIZE_VERSION=1; 10/10 vitest covering ligatures, CRLF, soft
hyphens (including line-break reassembly), mixed whitespace.
T05 PDF fixture corpus — 7 user-supplied German PDFs in fixtures/pdfs/
(gitignored binaries) plus a manifest with verbatim known-good
quotes and page counts, ready for CE-WP-0002 selector tests.
T06 README upgrade — umbrella README points at wiki/docs/workplans
and documents the dev workflow.
T07 ADR-0002..0006 stubs in docs/decisions/.
Toolchain end-to-end: pnpm install + lint + typecheck + test all green.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
51 lines
1.8 KiB
Markdown
51 lines
1.8 KiB
Markdown
# 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)
|