Skip to content

Repository Boundaries

This document originally recorded an intentional, open architectural decision. As of ADR-0014 (proposed 2026-07-12, pending Founder ratification), the general question is resolved: venture implementation code lives in its own separate repository by default. This document is retained, updated to describe that resolution, because it still documents what this repository is and is not — a distinction that remains true regardless of the boundary decision.

What this repository is

This repository (devonshire-digital) can operate, at different points in time or simultaneously, as:

  • The company governance repository — policies, standards, decision records, and AI instructions for Devonshire Digital LLC.
  • The product portfolio source of truth — the canonical description of what ventures and products exist and how they relate (see docs/company/portfolio-strategy.md).
  • A documentation and specification repository — company-, venture-, and product-level specifications that constrain implementation wherever that implementation lives.
  • A registry of related implementation repositories — pointing to where Shelfery, Digital Products, or other venture code actually lives, if it lives elsewhere.
  • Optionally, in the future, a monorepo containing implementation code directly — but only if and when that is explicitly decided.

What this repository is not

This repository is not a monorepo containing every venture's application code, workbook, or tooling, and — per ADR-0014 — is not expected to become one by default. Venture implementation code lives in its own separate repository (pantryplus for Shelfery, per ADR-0010; one repository per venture as each reaches implementation stage going forward). A specific venture could still deviate from this default, but doing so requires its own ADR justifying the exception, not incremental, undocumented drift toward a monorepo.

Why this was left open, and how it was resolved

At the time ADR-0007 was written, neither Shelfery nor Digital Products had implementation code, and the team was a single Founder — repository-splitting overhead wasn't yet justified, but neither was a firm monorepo commitment. That changed once real evidence arrived: Shelfery's implementation already existed as a separate, production-deployed repository (pantryplus), predating this repository's own Shelfery documentation (ADR-0010). ADR-0014 generalized that outcome into the default policy for every venture, rather than continuing to decide the question venture-by-venture with no expectation the answer would differ.

How this gets decided

This boundary question is recorded in:

  • ADR-0007 — docs/decisions/ADR-0007-implementation-repository-boundary-remains-open.md — the original record of the question being left open. Retained as historical context; no longer the controlling statement of current policy.
  • ADR-0010 — docs/decisions/ADR-0010-shelfery-implementation-repository-pantryplus.md — the Shelfery-specific precedent that supplied the evidence for the general decision.
  • ADR-0014 — docs/decisions/ADR-0014-venture-implementation-repositories-are-the-default-pattern.md — the current controlling record: venture implementation code lives in its own repository by default, created once a venture is approved for implementation work.
  • docs/architecture/future-repository-strategy.md — describes the range of repository strategies that were under consideration before ADR-0014, retained as historical context for how the decision was reached.

Any future change to this default (e.g. reverting to a monorepo, or a specific venture opting out) should be made via a new ADR that supersedes or amends ADR-0014, not through incremental, undocumented structural drift.

Guidance for contributors and agents

  • Do not scaffold or place implementation code for a venture in this repository — per ADR-0014, it belongs in that venture's own implementation repository. Use scripts/create_implementation_repository.py to scaffold a new one once a venture is approved for implementation work.
  • Do not restructure this repository toward a monorepo layout as a side effect of an unrelated task.
  • If a task seems to require deviating from this default for a specific venture, treat it as a company-level ADR decision (see docs/governance/change-management.md) and escalate rather than deciding unilaterally.

Report an issue about this page