Skip to content

ADR-0007: Implementation Repository Boundary Remains Open

Status

proposed — decided during initial drafting; not yet formally ratified by a human review checkpoint. Note: unlike most ADRs, the decision this record captures is explicitly to leave a question open, not to resolve it.

Date

2026-07-10

Context

This repository currently holds company governance, standards, decisions, and (as they are written) product specifications for Shelfery and Digital Products. Neither venture yet has product implementation code. A natural question is where that code should eventually live: inside this same repository (a monorepo arrangement), in separate per-venture or per-product repositories, or in some hybrid. Deciding this prematurely — before either venture has real implementation work, a team beyond a single founder, or an established release cadence — risks locking in a structure based on guesses rather than evidence.

Decision

The long-term boundary between this repository and product implementation repositories remains open and unresolved. This repository currently holds documentation, specifications, and governance; actual product code (the Shelfery app, Digital Products workbooks) may end up in this repository, in separate repositories, or in a hybrid arrangement. That determination is deferred until there is enough evidence — team size, release cadence differences between ventures, tooling overhead of each option — to make an informed choice, per the criteria listed in docs/architecture/future-repository-strategy.md.

This ADR does not commit to a monorepo, a multi-repo split, or any specific hybrid. It commits only to not deciding yet, and to documenting the decision as open rather than leaving it undocumented and ambiguous.

Consequences

  • Nobody working in this repository should assume a monorepo outcome (e.g., by hardcoding paths or tooling that only make sense if implementation code lives here) or a multi-repo outcome (e.g., by refusing to ever add implementation code here) without checking this ADR first.
  • portfolio/repository-registry.json is designed to accommodate either outcome — it can register this repository alone, or this repository plus one or more implementation repositories, without requiring rework.
  • Revisiting this decision later requires someone to actually apply the criteria in docs/architecture/future-repository-strategy.md and write a follow-up ADR — leaving it open is not the same as never resolving it.

Alternatives Considered

  • Decide now: monorepo. Rejected: would commit both ventures to shared tooling and repository structure before either has implementation code, based on no operational evidence.
  • Decide now: multi-repo (separate implementation repos per venture from the start). Rejected: same objection in the other direction — premature commitment to overhead (separate CI, separate access management) that may not be justified for a single-founder operation with no code yet.

Follow-up Actions

Report an issue about this page