3 Commits

Include renames

Author	SHA1	Message	Date
jschoubben	77f3a4cea7	Consolidate: 65 decision records to 23 ... Every remaining cluster merged. Each was one design that had been split across several records because it was worked out over days rather than at once. the node host 8 -> 1 applies not decides, depends on nothing, per operating system, root service, the launcher, episodic, what a declaration is, actions from the bundle only a node and how it joins 4 -> 1 what a node is, joining, the link as security boundary, the enrolment token modules and the graph 7 -> 1 everything is a module, no domain modules, three edges, provisioning, the core library substrate and control 6 -> 1 the test, seven contexts, one control plane, plane the authority is not a database, the named products, the pinned bundle connectivity 3 -> 1 a route is a grant, reachability declared, filter rules delivery 5 -> 1 reconciliation not a pipeline, artifacts, the three silos, a failed step, the verdict the lab 5 -> 1 (earlier) how this repository 10 -> 1 (earlier) works Nothing was dropped. Each consolidated record carries the reasoning of the ones it absorbs -- the measurements, the incidents, the alternatives rejected -- because that reasoning is the only reason to keep a record at all. What is gone is the fragmentation: eight files to read to understand tier 0, when tier 0 is one component. The four superseded records went too. They existed to point at their successors, and the successors now contain what they said. The checker made this safe. Each merge left dangling links -- 38 files after the host merge alone -- and it named every one. Nothing was found by reading, and a manual pass would certainly have missed some, including references inside AGENTS.md which every session loads.	2026-08-28 20:03:24 +02:00
jschoubben	fa9889536c	011: tools have a different audience, migrations cross the edge, provisioning is early ... Three additions, and the third kills an assumption. Tools are the most common content in the catalogue — 56 of 126 modules, more than carry a service — and they survive the split without fitting either half. A tool is not an artifact and not node state; it is a contract the mesh publishes on a module's behalf, and what consumes it is an AGENT rather than another module. That is a second audience the design has not described. Whether it is one relation with two audiences or two relations is cheap to decide now and expensive later. A migration belongs to the CONSUMER and runs on the PROVIDER. A game's migrations run against the database the store granted it: owned by the consumer, hosted inside something it does not control, ordered after the provisioning edge because there is nothing to migrate until the grant exists, and scoped to that grant. Ownership crosses the edge, which nothing in provides and requires expresses — and it gives a consumer's own install an internal order, provisioned then migrated then started, that depends on an edge rather than on its contents. And provisioning is EARLY, not late. The assumption worth killing is that it is something the control plane does for consumers once a mesh is running. The mesh's own registry database is provisioned before there is a mesh, and so is its virtual host on the broker: the store runs from the carried bundle, a database is created in it, the mesh's own schema is applied, and only then does a control plane exist. Steps two and three happen before there is a mesh to do them, so provisioning is part of the bootstrap and part of what the bundle has to express. Which strains ADR 0043. The host applies declared state ON THIS MACHINE, and a database inside a running store is not a file or a unit. At bootstrap it is at least local — the store is on the same machine. Afterwards a consumer on one node provisioned from a store on another is the ordinary case and reaching it is not the host's job. The same operation is local at bootstrap and remote later, which is either two mechanisms or one with a tier boundary crossing inside it. Currently the sharpest unresolved thing in the effort.	2026-08-26 23:02:52 +02:00
jschoubben	c9c2dfe686	011: what a feature is, and what it splits into ... The operator wants features gone, and 006 left it open. Measured, and the answer is that nothing replaces them because they were never one concept. A feature is a kind of content a module carries, detected from its directory: twenty-one of them, each with a handler owning six stages — build, publish, install, configure, start, verify. The structural finding: EVERY handler implements EVERY stage. `configs` writes files onto a node, has nothing to build, and has a build stage. `npm` publishes to a registry, has nothing to start, and has a start stage. One interface spans build-time and apply-time, so every kind of content must implement both halves and most do nothing in one — and a stage that does nothing looks exactly like a stage that failed to do anything. They split four ways, across three tiers. Artifacts built once per version and published, where no node is involved — delivery. Resources that are desired state on a machine, which is what ADR 0043 already describes and the host already does — tier 0. Actions run once against something that is not this machine, like a migration against a database on another node — delivery, and seeds go entirely. And checks: the prerequisites are REQUIREMENTS IN DISGUISE, a module saying what must be true before it can be installed, which is what an edge in the graph says; the verifiers are the read-back the host already performs. So `feature` is one word for four things spanning three tiers, which is why the pipeline is hard to reason about. One property must survive the split, and it is the thing the current design got right: content is DETECTED, relationships are DECLARED. A module that says it has migrations and has none is a fault nobody sees until it matters — but what it requires and provides is not visible in a directory and has to be said.	2026-08-26 22:51:19 +02:00