jschoubben
333356cff3
Jochen asked whether the order made sense. It did not -- it followed when things happened to be decided, which after consolidation is fictional anyway since record 5 alone folds decisions taken across a week. Concretely wrong before: the domain statement sat at 8, after five engineering rules; the constitution was scattered across 5, 12 and 17; the tiers landed at 15, 16, 21 and 22 with process records in between. Now it walks: what the mesh is (1-3), its tiers from the bottom up (4-8), what runs on them and how it gets there (9-10), how it is built (11-16), how it is checked (17-18), how we work (19-23). Two things made this safe rather than free. It is a permutation, not a compaction, so the renames go through temporary names -- otherwise two files want one slot and one is lost. And the reference rewrite is a single simultaneous pass, because almost every number moved into a slot another number was vacating; replacing one at a time would have cascaded and pointed things at the wrong record while still resolving. Verified: 284 [ADR NNNN](path) links across the repository, all with matching text and target. The ordering principle is now stated in 19 rather than left implicit -- the repository already said "the numbering is the flow" about its folders, and there was no reason for the records to be the exception.
2.9 KiB
status, date, deciders, reconstructed
| status | date | deciders | reconstructed |
|---|---|---|---|
| accepted | 2026-07-10 | jochen | true |
15. 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 0014 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 0001 decision 4 extends this from new applications to the modules already in the monorepo.
- Knowledge base:
troubleshooting/unregistered-module-source.