jschoubben
c0b35652d0
papa-hq reads 01 research -> 03 decision -> 02 design. The order is a scar, not a choice: 02-DESIGN existed from its initial commit, and when adr/ was finally promoted on 2026-07-13 it took the next free number rather than its place in the sequence. By then design was too settled to renumber. hal-hq was three commits old, so it is not. adr/ becomes 02-DECISIONS and 02-DESIGN becomes 03-DESIGN, and following the folder numbers now walks the process in the order it happens: research produces a decision, the decision authorises a design. 00-GENESIS becomes 00-META, matching papa's rename from the same restructure. Every path reference rewritten across documents, frontmatter, playbooks and skills. All links resolve; all 58 frontmatter blocks parse and their path fields still point at files that exist.
2.9 KiB
status, date, deciders, reconstructed
| status | date | deciders | reconstructed |
|---|---|---|---|
| accepted | 2026-07-10 | jochen | true |
10. Applications live in their own repository; the monorepo is for the mesh
Reconstructed after the fact from the evidence cited below.
Context
The module system makes adding anything to the monorepo trivial — a directory and a manifest. That ease is the problem. Standalone applications, sites and side-projects accumulated beside the mesh's own components, and once there they inherited the monorepo's review cadence, its pipeline detection, and its history.
The mesh's own code and an application that merely runs on the mesh have nothing in common except the manifest format. They change for different reasons, are reviewed by different criteria, and have no reason to share a branch.
Considered options
- Everything in the monorepo. Rejected — it is what existed. The monorepo becomes an inventory of one installation's applications, and every application change queues behind mesh review.
- A second monorepo for applications. Rejected: the same coupling with an extra name. Applications have no more in common with each other than with the mesh.
- One repository per application, registered with the mesh as a build source. Chosen.
Decision
Every standalone application, site or side-project lives in its own repository, with a manifest at the root. It registers with the mesh as a build source and is then built, provisioned, deployed and verified by exactly the same pipeline as anything in the monorepo.
The monorepo holds the mesh: the runtime, the core modules, the delivery machinery, and the shared infrastructure the mesh itself provisions against.
Creating an application directory in the monorepo is a convention violation, and reviewers reject it.
Consequences
- An application's cadence is its own. It is not reviewed as mesh code and does not queue behind mesh work.
- The separation is safe only because the pipeline and provisioning are identical either side of it — which ADR 0007 is what makes true. Without standalone packages this decision would fork the build.
- The monorepo stops being an inventory of the installation, which is a precondition for publishing anything about it.
- Discovery gets harder: there is no single listing of everything the mesh runs, and the registry of build sources becomes the closest thing to one.
- A module source that is not registered is silently skipped by the pipeline. The cost of being outside the monorepo is that being forgotten is possible.
References
- The rule is stated in the governed constitution page authored 2026-07-10, §3, as a convention violation reviewers must reject.
- ADR 0015 decision 4 extends this from new applications to the modules already in the monorepo.
- Knowledge base:
troubleshooting/unregistered-module-source.