Files
hq/03-DESIGN/01-to-be
jschoubben 51f5ce5c0f 4.5 done: the catch-up needed nothing built, which was the answer
Three ways to do the replay were weighed and the right answer was that the bus being
moved to already does it. A queue on the old bus receives only what is published after
it is bound, so everything built before the catalogue existed was announced to nobody. A
stream is a log and a consumer is a position in it: a consumer created later starts at
the beginning and the builds are simply there. Checked against a running server, because
the decision rested on it.

So "who replays" has no answer because nothing replays. The mechanism was never about
builds — it was about a queue that could not remember, and carrying it across would have
carried a workaround for a limitation that no longer exists, with nothing looking wrong.

Retiring it belongs to step 5, with the rest of what only the old bus needs.
2026-09-27 17:23:49 +02:00
..
2026-09-26 21:08:40 +02:00

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
25-the-bus-on-nats.md Proposed. The architecture of the mesh's bus on NATS: what rides which subject under which guarantee and whose account, how a node joins, how a person reaches a tool, and how the mesh moves from the bus it has ADR 0106, ADR 0116, ADR 0043, ADR 0083
26-the-seats.md Proposed. 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 0118 (superseding 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 0114, ADR 0118 (superseding ADR 0110)
28-building-the-bus.md Proposed. The five steps of the bus work in the order their dependencies allow, each ending at a bed — with the surface measured, so no step's size is a guess ADR 0116, ADR 0106, ADR 0074

| 29-what-a-module-declares.md | Proposed. What a module declares and what the bus derives from it: three namespaces, subjects from local names, queues never declared, the five relationships, and the build-publish-deploy lifecycle on one bus | ADR 0118, ADR 0119 (superseding ADR 0117), ADR 0041 |

Not yet written

  • The remaining six contexts. ADR 0006 settles the list at seven; connectivity is 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.