The numbering is the flow: decisions are 02, design is 03

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.

02-DECISIONS/0010-applications-live-in-their-own-repository.md

@@ -0,0 +1,64 @@
+---
+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`.