Skip to content

DR-001: Use Mono-Repository Layout (Single-Repository Type)

Home › Reference › Decision Records › Dr001

Status

  • [x] Accepted
  • [ ] Proposed
  • [ ] Rejected
  • [ ] Deprecated
  • [ ] Superseded

Date: 2025-11-03

Context

Platform has CLI, VSCode extension, MCP servers, docs, automation, and contracts. Needs coordinated development, atomic commits, code sharing, and independent module versioning.

Problem: How to organize codebase for maintainability and velocity?

Decision

Mono-repository with clear module boundaries.

Structure:

cli/
├── go/            # Go source (eac/, r2r/)
├── .vscode/       # VSCode extension
├── automation/    # Scripts
├── docs/          # Documentation
├── contracts/     # Deployable modules
└── specs/         # Specifications

Module Detection: go.mod, package.json, pyproject.toml, conventional directories (docs/, automation/, contracts/)

Versioning: Independent per module via semantic versioning in commit messages

Consequences

Positive: Atomic commits, simplified dependencies, easy code sharing, unified tooling, single clone

Negative: Larger repo, build complexity, no per-module access control, merge conflict potential

Alternatives Considered

  1. Multi-Repository: Rejected - tight coupling makes cross-repo coordination costly
  2. Git Submodules: Rejected - adds complexity without enough benefits
  3. Workspaces Only: Rejected - limited to one language, codebase is multi-language

Tutorials | How-to Guides | Explanation | Reference

You are here: Reference — information-oriented technical descriptions of the system.