jschoubben
a625e6c709
Designed with no reference to what came before, which was asked for. The system this replaces has features — several deployable units inside one module — and they are deliberately absent. That closes something ADR 0001 has been carrying as an open prerequisite. It lists "named features with per-node opt-in" as required, or "every independently deployable unit becomes a module again and the count returns". The premise was right and the remedy already exists in another form: several modules, assignment per node, and a module with requirements and no files of its own. `networking` is exactly that. The count does not return because what made it return — a module is expensive, so put several things in one — is gone. A module here is a manifest and usually nothing else. The manifest in a repository names artifacts; the manifest the mesh holds names digests. Two documents, because a digest is not knowable until something is built and a repository carrying one is wrong the moment anybody edits anything. The builder runs on a node. Building needs a container runtime and a working tree, and what the control plane may send a machine is bounded by the declaration language. A control plane holding a container socket would be the one component that can do anything anywhere. And the host's vocabulary grew from six shapes to eight — user and archive — with the reasoning for each and for the refusals that came with them. The count is asserted by a test precisely because every addition widens what a compromised control plane can express.
03-DESIGN / 01-to-be
The mesh being built toward. Every statement here traces to a record in
02-DECISIONS/; nothing arrives by drafting.
A document here describes an intention. What currently runs is in
00-as-is/, and the two are never merged — when something ships, the as-is
document is written and this one's status becomes implemented.
| Document | Covers | Rests on |
|---|---|---|
00-work-breakdown.md |
How the decomposition gets built, in what order, and where a human must look | ADR 0001 |
01-end-to-end-testing.md |
The lab: a real mesh a change can be run against before it reaches nodes | ADR 0016, 0029 |
02-scenario-declaration.md |
What a scenario declares — the underlay, and what to place on it | ADR 0016 |
03-scenario-lifecycle.md |
What happens to a scenario — raise, snapshot, restore, move, destroy | ADR 0016 |
04-lab-installation.md |
Getting the lab onto a clean machine, and why it verifies capability rather than installation | ADR 0010 |
05-the-node-host.md |
Tier 0 — the one thing installed by hand, and the only thing that changes a machine | ADR 0005 |
06-the-control-plane.md |
Tier 2 — what the term means, and the test for what belongs in it | ADR 0005 |
07-the-substrate.md |
Tier 1 — what the control plane consumes and cannot grant itself | ADR 0004, 0048 |
08-connectivity.md |
One context in full — overlay, resolution, exposure, filtering, certificates | ADR 0007, 0050, 0051, 0055 |
09-the-node-lifecycle.md |
How a machine becomes a node, stays one, and stops being one | ADR 0004, 0051 |
10-delivery.md |
Modules, the three edges, and how a change becomes a running thing | ADR 0010, 0064, 0065 |
Not yet written
- The remaining six contexts.
ADR 0006
settles the list at seven;
connectivityis the first written in full (08) and the other six do not exist yet. The work breakdown says in what order they are needed. Domain grouping outside the core.Not needed. ADR 0009 is superseded by ADR 0009: there is no domain module to group into, so there is no domain list to settle. Relationships are edges, and grouping is a tag and a query.