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.
65 lines
2.9 KiB
Markdown
65 lines
2.9 KiB
Markdown
---
|
|
status: accepted
|
|
date: 2026-07-10
|
|
deciders: jochen
|
|
reconstructed: 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
|
|
|
|
1. **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.
|
|
2. **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.
|
|
3. **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](0007-no-npm-workspace.md) 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](0015-mesh-brokers-nodes-host-agents-think.md) decision 4 extends this from *new*
|
|
applications to the modules already in the monorepo.
|
|
- Knowledge base: `troubleshooting/unregistered-module-source`.
|