jochen
4a1b218706
Decided with the author: - A seat is held by one assignment, not claimed by a definition. A definition says which seats a module can hold; an assignment says which it does. The store module can run on every node and one assignment holds mesh-store; moving a role changes an assignment, never a definition. The foundation's seats name what the mesh itself uses and route no consumer — database and amqp consumers use co-location, the holder included. This replaces the wrong rationale that the foundation's store is "provider to nobody", which contradicted ADR 0078 and to-be 21. 0079's one-postgres rule becomes one mesh-store holder. - A module is assigned at most once to a node. The instance identity in 0112 and 27 is withdrawn, and the login-length problem with it. Review fixes to 0113: - The bottom of the stack: the vault is installed as soon as the shared runtime base exists, and genesis generates everything needed until then — including the permanent controller's, the control-node agent's, the builder's and the broker provisioner's bus accounts, and the controller's store login. Genesis creates those accounts until the broker's provisioner runs and adopts them. - Genesis's values are delivered recorded as the mesh's own, so 0092's never-replace rule for operator values does not make them unrotatable. - Backend-issued secrets (a forge's once-only API token) enter through the vault. Non-module parties (the controller's logins, node agents' accounts) are answered the same way, the controller asking on their behalf; an enrolment token reaches the controller only as what verifies it. - A secret with no provisioner to apply it is marked not rotatable by the mesh and refused, instead of a restart reported as done. Unused password generators in six provider clients are removed, and a catalogue scan checks no module mints. - Rotation's lock-out cases (offline reader, bus account owner, restarted provisioner) are recorded as open, with overlap and re-confirm-with-safeguards as the two answers, to be chosen before acceptance. 0110, 0111 and 26 are marked proposed: they changed in meaning and are under review, and an accepted record must not rest on proposed ones. To-be 23 and the glossary are restored to main; they change when these records are accepted.
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 modules move across one at a time, until the old registry can be switched off | ADR 0001, ADR 0016 |
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-controller.md |
Tier 2 — what the term means, and the test for what belongs in it | ADR 0005 |
07-the-foundation.md |
Tier 1 — what the controller 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 |
11-a-board.md |
What a person sees of the mesh, and why it is read from what runs | ADR 0008, ADR 0001 |
12-a-module-repository.md |
A module repository, and what builds it | ADR 0009, ADR 0010, ADR 0005 |
13-credentials-and-their-rotation.md |
Credentials, and moving them without a consumer holding one the provider does not know about | ADR 0001, ADR 0009 |
14-model-access.md |
Model access as a provision, and what a licence is bound to | ADR 0024, ADR 0009 |
15-the-agent-session.md |
One mechanism started twice — a node's session and the mesh's | ADR 0004, ADR 0026 |
16-module-coverage.md |
What a module must be able to say, measured against 127 that exist | ADR 0009, ADR 0005 |
17-raising-a-mesh.md |
How a mesh comes into existence, and how a machine joins one that exists | ADR 0067, ADR 0006, ADR 0005 |
18-building-a-module.md |
How a build is modelled, and why a recipe that is always a Dockerfile does not fit what a module is | ADR 0040, ADR 0039, ADR 0009 |
19-the-module-protocol.md |
What a module's code and the mesh say to each other; an SDK is an implementation of it | ADR 0074, ADR 0042, ADR 0043 |
20-writing-a-module.md |
A worked guide: one module, four capabilities, four languages, and the packages it publishes | ADR 0074, ADR 0040, ADR 0039 |
21-the-installation-in-full.md |
Every step from a bare machine to a mesh that maintains itself, and what is not yet true | ADR 0067, ADR 0073, ADR 0014 |
22-the-work-ahead.md |
Everything decided and not yet built, in dependency order, each phase ending at a run | ADR 0074, ADR 0075, ADR 0014 |
23-choosing-a-provider.md |
Which of several providers of a kind serves a consumer, and when a module carries its own instead | ADR 0084, ADR 0027 |
24-the-secrets-vault.md |
The module that owns a secret — a secret provision, and the boundary of what it owns |
ADR 0085, ADR 0031, ADR 0048 |
26-the-seats.md |
What a mesh can have one of, who fills each, and a seat's holder answering for the provision it delivers — including the git seat a build's source can live on |
ADR 0110, ADR 0111, ADR 0109 |
27-a-module-requires-the-mesh-resolves.md |
Proposed. One concept for everything a module needs: a requirement with a contract, answered by one of four kinds of provider, resolved at assignment or refused. Retires settings, placeholders, facts and paths in definitions | ADR 0112, ADR 0113, ADR 0110 |
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.