HQ — the mesh's own documentation

What the mesh is, what it is becoming, and why. Implementation lives in the
code repositories; the reasoning lives here.

  00-GENESIS   mission, engineering context, effect, and the rules that hold
  01-RESEARCH  investigations, before they harden into design
  02-DESIGN    the authoritative specification
  adr          numbered decisions — what was chosen, and what was rejected
  DECISIONS.md the ledger: every decision, in the order it was taken

Written for a reader who is not its author and has no access to the mesh it
describes. Addresses use the documentation ranges of RFC 5737 and RFC 1918;
nodes are named by role.

Single initial commit by intent. The prior history came from a private
repository and carried operational detail — a routable address identified as a
VPN hub, real domain names, a hosting provider — which sanitising a tip commit
would not have removed from the log.

01-RESEARCH/002-local-mesh/status.md

@@ -0,0 +1,53 @@
+# 002 — A mesh that runs locally
+
+- **Status:** GRADUATED — the design is [`02-DESIGN/01-end-to-end-testing.md`](../../02-DESIGN/01-end-to-end-testing.md)
+- **Initiated by:** jochen, 2026-08-22
+- **Areas touched:** `install.d/`, `hal/meshware`, `hal/coordinator`, `hal/brain`,
+  `hal/developer` (`dev_up`), `hal/sdk` (env generation, feature handlers, artifact
+  manager), `test/pipeline/`, `test/dev-mesh/`, the provisioning path in
+  `modules/postgres/`.
+
+## Summary
+
+Phase 0 of [`02-DESIGN/00-work-breakdown.md`](../../02-DESIGN/00-work-breakdown.md) requires
+a mesh that comes up in containers, runs its own pipeline, and reproduces known faults on
+demand. Nothing else in the decomposition starts until it exists, because every fault the
+decomposition addresses was found in production — there was nowhere else to find it.
+
+This effort establishes what already runs in a container, what is welded to the host, and
+what it would take to close the gap. It does **not** choose an approach: the central
+question — how a containerised node executes a module service, when a module service is
+defined today as a systemd unit shelling to `docker compose` in `/services/` — is not
+answered by ADR 0001 and is recorded below rather than decided.
+
+## What was established
+
+- The two existing container harnesses are **neither of them a mesh**, and one of them has
+  not been able to build since 2026-06-04.
+- Node identity is already portable — a single environment variable, no host handshake.
+- Four concrete host couplings block a containerised node, all with known locations.
+- All three Phase 0 fixtures are reproducible; one of them is documented in the knowledge
+  base with an open root cause and is the cheapest place to start.
+
+Detail and evidence in [`analysis.md`](analysis.md).
+
+## Questions — all settled 2026-08-22
+
+**Phase 0 is a development environment**, not a fixture rig — it is what the host-borrowing
+dev tooling becomes.
+
+**The trigger is a real source-forge container**, because the webhook relay is part of what
+is under test.
+
+**A node is a system container**, promotable to a virtual machine per node. This answered
+the question the effort was stuck on, and dissolved it rather than solving it: against a
+real node with a real init, the four host couplings catalogued in `analysis.md` §3 are not
+couplings — they are how a node works. They were obstacles only to a node modelled as an
+application container.
+
+Consequently [`003-service-supervision`](../003-service-supervision/) **no longer blocks
+Phase 0**. It remains a live architecture question, on its own timeline.
+
+The remaining questions in `analysis.md` — what replaces host paths in a container, and how
+faithful the lab must be — are answered in the design: nothing replaces them, because the
+paths are real; and the divergences are enumerated rather than discovered.