jschoubben
418261213c
mesh/merge-gate pass: the change touches no module of the mesh's graph
mesh/repo-check pass: THE CHANGE ALTERS ITS OWN CHECK (merge-check.sh): main's version judged it; the change's judges the pull requests after it merges; it…
mesh/delivery superseded: a newer head of the same pull request
ADR 0290 rule 9: once the import is checked record by record, hq keeps no copy. The records and efforts are removed; every link or path to them reads "ADR NNNN" or "research NNN"; a design's decisions: lists "ADR NNNN". 02-DECISIONS keeps a pointer README with the reading order's six topics, which the knowledge base reads through the records module; 01-RESEARCH keeps a pointer README. The checks drop the rules that judged records (the knowledge base holds each at propose; checks/README.md says where) and refuse a record written here again. Playbooks 01 and 02 and the skills write and read records with the knowledge base's verbs.
03-DESIGN / 00-as-is
The mesh as it stands. These documents describe what runs, including the parts nobody would choose again — an as-is layer that only records the good decisions is a brochure.
They are written from the implementation and from the operational record, not from intent. Where the two disagree, the implementation wins and the disagreement is stated.
| Document | Covers |
|---|---|
00-overview.md |
The whole in one pass — what a node is, what a module is, how work reaches it |
01-mesh-and-transport.md |
The mesh database, the broker, discovery, and how a call reaches another node |
02-modules-and-manifests.md |
The module, the manifest, and features as the unit of work |
03-provisioning.md |
Declared requirements, provisioners, credentials, and cross-node grants |
04-delivery.md |
Push to running: the three silos, levels, and what a green pipeline proves |
05-runtime-and-installation.md |
The node runtime, its modes, and how a node comes into being |
06-configuration-and-secrets.md |
Managed files, value resolution, and where secrets live |
07-knowledge.md |
The mesh keeps no store: what it knows is what modules answer, and the record is read by one |
08-agents-and-work.md |
Agents as employees, tasks, workflows, and the meeting model |
09-interfaces-and-observability.md |
How the mesh is reached and watched — tools, board, proxy, health, thoughts |
10-module-catalogue.md |
The catalogue's shape, and what its shape says |
11-the-lab.md |
The lab — the first piece of the new shape that exists, and what it does not yet do |
12-the-seats.md |
The seats the mesh defines, who holds one, and where a seat changes resolution |
13-the-console.md |
The mesh's tools on the machine a person sits at, served by a module the mesh assigned there |
14-a-modules-state.md |
A module's current state on the bus: what the controller creates, the runtime serves, and the first live use showed |
15-the-agent-and-its-licences.md |
The operator's agent on every machine and the licence manager that keeps its licences |
What these documents are not
They are not a runbook. Operational procedure — how to fix one occurrence of something — lives in the knowledge base, which is indexed on symptoms and is the right place to search when something is broken.
They are not exhaustive. A subsystem is described to the depth at which its design is visible; below that is code.