jschoubben
cf9357e8e9
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.
54 lines
2.8 KiB
Markdown
54 lines
2.8 KiB
Markdown
# 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.
|