Skip to content

Repository Boundaries

This document records an intentional, open architectural decision: what this repository is, and what it is not yet decided to be.

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 assumed to be

This repository is not assumed to be, or to need to become, a monorepo containing every venture's application code, workbook, or tooling. That would be one possible future, not the default outcome. Treating monorepo consolidation as inevitable would encourage scope creep (see docs/governance/risk-register.md, risk RK-004) and would foreclose reasonable alternatives (e.g. separate repositories per venture, with this repository as the governance/spec hub they all reference) before a deliberate decision has been made.

Why this is left open

At this stage:

  • Neither Shelfery nor Digital Products has implementation code yet.
  • No GitHub organization or remote has been established (see open-questions.md, OQ-005).
  • The team is a single Founder; repository-splitting overhead is not yet justified, but neither is a firm monorepo commitment.

Deciding the final structure now would be premature and would likely need to be revisited anyway once real implementation work begins. Leaving the boundary open, while documenting the range of valid structures, avoids both premature commitment and undocumented drift.

How this gets decided

This boundary question is tracked as:

  • Open question OQ-002 (repository boundaries generally) and OQ-003/OQ-004 (venture-specific placement) in docs/governance/open-questions.md.
  • ADR-0007 — docs/decisions/ADR-0007-implementation-repository-boundary-remains-open.md records this as a formal decision record: the boundary is explicitly left open rather than implicitly defaulting to any one structure.
  • docs/architecture/future-repository-strategy.md — describes the range of future repository strategies under consideration in more technical detail.

Any future change to this boundary (e.g. deciding to consolidate into a monorepo, or to split governance from implementation permanently) should be made via a new ADR that supersedes or amends ADR-0007, not through incremental, undocumented structural drift.

Guidance for contributors and agents in the meantime

  • Do not assume implementation code belongs in this repository unless explicitly instructed.
  • Do not restructure the repository toward a monorepo layout as a side effect of an unrelated task.
  • If a task seems to require deciding this boundary, 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