Skip to content

ADR-0014: Venture Implementation Repositories Are the Default Pattern

Status

approved — ratified by the Founder on 2026-07-12.

Date

2026-07-12

Context

ADR-0007 deliberately left open whether venture implementation code would live inside this repository (a monorepo) or in separate repositories, deferring the question until either venture had substantial implementation work, a team beyond a single founder, or an established release cadence.

That evidence has since arrived, at least in part. ADR-0010 (approved 2026-07-11) recorded that Shelfery's implementation already exists as a separate, production-deployed repository (pantryplus), predating this repository's own Shelfery documentation, and formally recognized that repository rather than migrating it into a monorepo. ADR-0010 was explicit that it resolved the boundary question only for Shelfery — it did not supersede ADR-0007, which remained the controlling record for Digital Products and any future venture.

The Founder has now requested (GitHub issue #1) that this stop being decided venture-by-venture and instead become general policy: venture implementation code gets its own repository by default, going forward, for every venture — not because monorepo was tried and failed, but because the one case with real operational evidence (Shelfery/pantryplus) came down clearly in favor of separation, and there is no longer a reason to keep the general question open pending "more evidence" that isn't expected to point the other way. The issue also asks that brand identity development and asset creation remain centralized in this repository regardless of where implementation code lives, with finished assets transferred to venture repositories as needed — and that this repository gain tooling to scaffold a new venture implementation repository consistently, modeled on the pattern that already proved out in pantryplus.

Decision

  1. Venture implementation code lives in a separate, venture-owned repository — one per venture, not a company-wide monorepo, and not one repository per product within a venture. This repository (devonshire-digital) does not host application/product implementation code for any venture, now or as a future default. pantryplus (ADR-0010) is the first instance of this pattern, not a special case within an otherwise-open question.

  2. A venture's implementation repository is created only once that venture has been approved for implementation work — not preemptively, and not for a venture that exists here only as strategy/specification. Digital Products has no implementation repository today per portfolio/repository-registry.json; this ADR does not create one. It resolves the pattern that will apply once Digital Products, or any new venture, reaches that stage.

  3. Brand identity development and asset creation remain centralized in this repository. Logos, marks, color systems, and the GIMP-based production tooling used to create them (docs/design/, scripts/gimp_*.py, and related brand records) stay here as the source of truth, consistent with ADR-0005. Finished assets are exported and copied into a venture's implementation repository as needed (as pantryplus/public/brand/ already does); the implementation repository is a consumer of those assets, not where they are designed or where the canonical originals live.

  4. This repository gains scaffolding tooling to create new venture implementation repositories consistently. A template and script (see Follow-up Actions) let a venture implementation repository be spun up in a way that starts from the pattern already proven in pantryplus — an AGENTS.md/CLAUDE.md pair, a docs/ai/ durable knowledge base with an index (docs/ai/README.md), a CI gate, and a PR-gated branch workflow — without forcing pantryplus's specific technology choices (Next.js, Supabase, Clerk) on a venture that doesn't need them. The scaffold is a starting structure, not a mandate that every venture use the same stack.

This ADR supersedes ADR-0007. ADR-0007 remains readable as the historical record of why the question was left open at the time; it is no longer the controlling statement of current policy.

Consequences

  • The general question ADR-0007 posed is now resolved: future ventures do not require a fresh ADR to decide "monorepo or separate repository" — separate repository is the default, and a future ADR would only be needed to justify a deliberate exception to that default, not to establish the default itself.
  • docs/governance/repository-boundaries.md and docs/architecture/future-repository-strategy.md need follow-up edits so they no longer describe the boundary as fully open (they should instead describe the now-settled default and note that a specific venture could still deviate from it with its own ADR, if a concrete reason arose).
  • Building and maintaining venture-scaffolding tooling in this repository is new, ongoing surface area (a template directory plus a script) that has to be kept in sync with whatever this repository's own governance/agent-facing conventions become, or it will drift and produce outdated scaffolds.
  • Centralizing brand asset creation here while implementation lives elsewhere means every venture repository depends on a manual or scripted asset-transfer step; nothing in this ADR builds automated syncing, so staleness between "the canonical asset here" and "the copy over there" is a standing risk each transfer has to guard against.
  • This does not retroactively change anything about Digital Products' actual status — it still has no implementation repository, because it has no implementation work yet. The registry entry in portfolio/repository-registry.json stays unresolved for that venture until it does.

Alternatives Considered

  • Leave ADR-0007 open and keep deciding per venture. Rejected: the Founder has stated the general intent directly (GitHub issue #1), and the one case with real evidence already supports the same answer a company-wide default would give. Continuing to relitigate this per venture adds process overhead without a plausible scenario in which a future venture's answer would differ, given the stated intent.
  • Decide the opposite general default (monorepo unless a venture opts out). Rejected: contrary to both the Founder's explicit instruction and the only operational data point available (pantryplus), which already exists, is in production, and was not built as part of this repository.
  • Fold implementation code for future ventures into this repository selectively, case by case, with no stated default. Rejected: this is close to the status quo ADR-0007 already established and is exactly what this ADR is intended to move past — an explicit default reduces ambiguity for whoever (human or agent) stands up the next venture's implementation work.

Follow-up Actions

  • Build a scaffolding template (templates/implementation-repository/ or similar) and a script (scripts/create_implementation_repository.py, mirroring the conventions of scripts/create_venture.py) that generates a new venture implementation repository skeleton modeled on pantryplus's structure, framework-agnostic beyond that structural pattern. Tracked as a companion work item to this ADR.
  • Update docs/governance/repository-boundaries.md to describe the now-settled default instead of an open question.
  • Update docs/architecture/future-repository-strategy.md to record that the general question is resolved, retaining the candidate-roles discussion only as historical context for how the decision was reached.
  • Update portfolio/repository-registry.json's schema/notes if needed so a "scaffolded but not yet created on GitHub" repository has a clear status value distinct from unresolved and active (planned already exists in schemas/repository.schema.json and appears sufficient — confirm when the tooling is built).

Report an issue about this page