jschoubben
e1febe8e0f
The consolidation left a sparse sequence -- 1, 4, 6, 7, 9, 10, 12, 15, 16, 18, 19, 25, 34, 35, 36, 37, 40, 42, 44, 45, 48, 49, 58 -- where the gaps were only the archaeology of what used to be there. Renumbered contiguously. Renames run in ascending order, so every target number is already free and no two files ever collide. The reference rewrite is one simultaneous pass rather than a sequence of replacements. Numbers moved into slots other numbers were vacating -- the node host went 37 to 16 while the lab went 16 to 9 -- so replacing one at a time would have cascaded and silently pointed things at the wrong record. Seven plain-text references survived the merges as prose rather than links, naming records that no longer existed: the enrolment token, the link boundary, what a declaration is, reachability, the repository structure. Each mapped to the consolidated record that now holds it. Verified rather than assumed: every [ADR NNNN](path) link now has matching text and target, checked across the whole repository, and the checker passes. Frontmatter `consolidates:` lists dropped -- they named records that are gone, and each consolidated record already says in prose what it absorbed.
2.9 KiB
status, date, deciders, reconstructed
| status | date | deciders | reconstructed |
|---|---|---|---|
| accepted | 2026-07-10 | jochen | true |
6. 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 0004 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 0008 decision 4 extends this from new applications to the modules already in the monorepo.
- Knowledge base:
troubleshooting/unregistered-module-source.