jschoubben
f05e4a0dce
Research efforts move from status.md to 00-overview.md with active / graduated / abandoned, matching papa-hq so the two repositories read the same way. Playbooks, skills, README and the ledger follow. Reverses yesterday's withdrawal of the symlink note in GENESIS. The note was right and the withdrawal was wrong: the intent is that the mesh creates no symlinks at all, so a founding document listing "symlinks, not copies" as a design principle does point the opposite way from where this is going, and that is a contradiction rather than a stale detail. ADR 0018 records the position, proposed. ADR 0011 stays as it is — it is the historical decision and the incident behind it is why anyone believes either record — and is superseded in intent, not edited. Its one editorial line, which called the wider reading false, is corrected to state what is actually true: centralising who may link narrowed the incident class without closing it, because a link the installer makes resolves exactly like one made by hand. The argument that kept linking was staleness. ADR 0004 removed it: every managed file is already derived and reconciled, so a copy is the natural form and a pointer into source is the shape the mesh's own model forbids everywhere else. What is not settled, and is marked open, is how staleness gets detected — which is the decision that makes or breaks it.
02-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 two knowledge stores, and what each is for |
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 |
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.