Future Repository Strategy¶
This document originally recorded an intentionally open architectural question: what this
repository is for, long-term, relative to the eventual implementation code of Shelfery, Digital
Products, and any future ventures. That question is now resolved by
docs/decisions/ADR-0014-venture-implementation-repositories-are-the-default-pattern.md:
role (d) below — this repository as governance/documentation/registry, with implementation
code in separate per-venture repositories — is the settled default. This document is retained as
historical context for the candidate roles that were considered and the reasoning that led to
that decision, not as a still-open question.
Candidate roles for this repository¶
This repository could end up serving any one, or a combination, of the following roles. These are not mutually exclusive, and more than one may turn out to be true simultaneously.
(a) Company governance repository. Holds company-wide policy, standards, and decision records, with implementation code living elsewhere entirely. This role is true today regardless of how the other candidate roles resolve.
(b) Product portfolio source of truth. Holds product specifications and lifecycle state for every product across every venture, even if the code that implements those products lives elsewhere.
(c) Documentation and specification repository. A narrower version of (b): specifications and standards, without necessarily tracking full product lifecycle or portfolio management detail (which might instead live primarily in Notion or another management tool, per docs/decisions/ADR-0006-notion-as-management-not-canonical-source.md).
(d) Registry of related implementation repositories. This repository stays documentation-only, and every venture's actual product code lives in its own separate repository, referenced from portfolio/repository-registry.json.
(e) Future monorepo. If later approved, product implementation code (the Shelfery app, Digital Products workbooks and build scripts) could be brought into this same repository, alongside the documentation, under ventures/<slug>/.
Why this was left open, and how it was resolved¶
At the time of writing, Devonshire Digital was a single-founder operation with two ventures,
neither of which had product code yet. Committing to a repository boundary at that point —
monorepo, multi-repo, or a specific hybrid — would have been a decision made without evidence of
the actual costs and benefits in practice, so
docs/decisions/ADR-0007-implementation-repository-boundary-remains-open.md
formally deferred it rather than defaulting to either extreme.
The evidence arrived sooner than expected: Shelfery's implementation already existed as a
separate, production-deployed repository (pantryplus), recognized in
ADR-0010. Rather than
continuing to wait for a second, independent data point that was unlikely to point the other way,
ADR-0014
generalized multi-repo (role (d)) into the default for every venture.
Criteria that informed the decision¶
The following were the kinds of evidence identified, at the time this question was still open, as relevant to a future decision. They are retained here for historical context on how ADR-0014 was reached, not as still-open scoring criteria:
- Team size and structure. A single founder working across ventures may prefer one repository for simplicity; distinct teams per venture may prefer isolation (separate access control, separate history, separate release cadence).
- Deployment cadence differences between ventures. If Shelfery ships frequent app updates while Digital Products ships infrequent workbook releases, tying them to the same repository and CI/CD pipeline may create friction or unwanted coupling.
- Tooling overhead of multi-repo. Multiple repositories multiply the cost of shared tooling, dependency updates, and cross-cutting changes (e.g., updating a company-wide standard's automated check across every repository).
- Tooling overhead of monorepo. A single large repository can slow down tooling (CI runtime, checkout size) and make it harder to grant venture-specific or product-specific access without exposing the rest of the company's material.
- Confidentiality and access boundaries. If a future venture needs different collaborators, contractors, or access restrictions than others, repository-level separation may become necessary regardless of other convenience factors.
- Actual product code complexity. A handful of Excel workbooks with a small build script and a full mobile app codebase have very different infrastructure needs; the right answer may differ per venture rather than being uniform.
- Registry and cross-linking maturity. If
portfolio/repository-registry.jsonand related tooling make it easy to navigate across repositories, the practical cost of splitting drops; if not, staying unified is more attractive.
Resolution¶
Role (d) — this repository as governance/documentation/registry, implementation code in separate per-venture repositories — is the settled default per ADR-0014. A specific venture could still deviate from it, but only via its own ADR justifying the exception with concrete reasons, not by default or by drift.