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.

00-META/repos.md

@@ -0,0 +1,51 @@
+---
+status: canonical
+updated: 2026-08-23
+---
+
+# The HAL repositories
+
+The map of where implementation lives. Humans use it for orientation; agents use it for issue
+triage (playbook [`process/03-issues.md`](process/03-issues.md)). The `code:` frontmatter
+field in design documents points at entries here.
+
+Repository *names* are recorded; hosts, URLs and owners are not — this repository is public,
+and a forge address is an operational detail (see [`README`](../README.md)).
+
+| Repository | Owns |
+|---|---|
+| `hal` | The monorepo — the node runtime, the module catalogue, the delivery machinery, and the bootstrap scripts. Every core module lives here. |
+| `hal-hq` | This repository — mission, research, design, decisions, issue diagnosis. The source of truth for *why*. Carries no implementation. |
+| *(one per application)* | Every standalone application, site or side-project gets its own repository, with `module.yml` at the root. Registered with the mesh as a build source; built and deployed by the same pipeline as anything in the monorepo. |
+
+## What lives where inside the monorepo
+
+Named by role, because the layout is itself part of the as-is design — see
+[`03-DESIGN/00-as-is/`](../03-DESIGN/00-as-is/).
+
+| Area | Holds |
+|---|---|
+| Module catalogue | One directory per module, each with a manifest. Core modules sit under the mesh's own namespace; everything else at the top level. |
+| Node runtime | The daemon and interactive runtime that every node runs. |
+| Bootstrap scripts | First-node initialisation, joining an existing mesh, and node rescue. |
+| Shared library | The SDK every module builds against. |
+| Pipeline test harness | End-to-end coverage of the delivery pipeline. Currently unbuildable — see [`04-ISSUES/005`](../04-ISSUES/005-pipeline-test-harness-unbuildable/00-report.md). |
+
+## Why applications do not live in the monorepo
+
+A standalone application in the monorepo is a convention violation, and reviewers reject it.
+The reasoning is recorded in [`02-DECISIONS/0010`](../02-DECISIONS/0010-applications-live-in-their-own-repository.md):
+the mesh installs, provisions for, and ships an application through exactly the same machinery
+whether or not its source sits beside the mesh's own — so co-location buys nothing and costs
+the monorepo's review cadence.
+
+## There is no npm workspace
+
+Each module is a standalone package that consumes its dependencies from the private registry,
+not from a sibling directory. The workspace was removed after it caused build-versus-development
+divergence — a workspace member importing another resolved to local unbuilt source in the
+pipeline and to a published version in development. Recorded in
+[`02-DECISIONS/0007`](../02-DECISIONS/0007-no-npm-workspace.md).
+
+Consequence, and it is a real one: a cross-package change is two steps — publish, then consume
+— and a repository-wide `npm install` does not exist.