Future Repository Strategy¶
This document records 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. It does not resolve the question. See docs/decisions/ADR-0007-implementation-repository-boundary-remains-open.md for the formal decision record stating that this is open.
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 is left open now¶
At the time of writing, Devonshire Digital is a single-founder operation with two ventures, neither of which has product code yet. Committing to a repository boundary now — monorepo, multi-repo, or a specific hybrid — would be a decision made without evidence of the actual costs and benefits in practice. docs/decisions/ADR-0007-implementation-repository-boundary-remains-open.md formally defers this decision rather than defaulting to either extreme.
Criteria that might inform a future decision¶
None of the following are decided or scored today. They are listed as the kinds of evidence that a future decision on this question should look at:
- 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.
Non-resolution¶
This document should not be read as leaning toward any one of the candidate roles above. It exists to make the open question explicit and discoverable, and to give a future decision-maker a starting list of relevant factors rather than a blank page.