From afcc3557446f3c8079b573683212a9f28e4f4d76 Mon Sep 17 00:00:00 2001 From: jochen Date: Wed, 26 Aug 2026 23:16:13 +0200 Subject: [PATCH] 011: checked the registry's real consumers, and the question was the wrong shape MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The exclusive-ownership rule turned on whether every reader of the mesh registry could be served another way. Eighteen consumers open a direct connection. Four groups, and only one is work. The owner and its machinery keep reading, because they own it. The node appliers are already resolved — ADR 0037 stops the host querying the mesh database, decided for tier reasons with nothing to do with this. The bulk are FOREIGN TENANTS. The work engine holds ten of its own tables in the registry's database, the knowledge base two, pipeline logs one. Thirteen foreign tables across three contexts, which is how-we-build §4's shared schema counted. So the question was the wrong shape: the problem is not readers needing a new route to data, it is tenants needing to move out. Tasks, agents and teams have nothing to do with nodes and modules and are co-located by history. Give that context its own database and its dependency on the registry shrinks to one table. A handful of genuine cross-context reads remain, small enough to enumerate rather than estimate. The rule holds. Left open: whether those reads want an interface or events. Asking which nodes exist at the moment you need to know is a request; reacting when a node appears is a subscription, and some consumers want both. --- .../011-the-module-graph/worked-provider.md | 36 ++++++++++++++----- 1 file changed, 27 insertions(+), 9 deletions(-) diff --git a/01-RESEARCH/011-the-module-graph/worked-provider.md b/01-RESEARCH/011-the-module-graph/worked-provider.md index 9bcf9ef..885357c 100644 --- a/01-RESEARCH/011-the-module-graph/worked-provider.md +++ b/01-RESEARCH/011-the-module-graph/worked-provider.md @@ -232,17 +232,35 @@ join, and it lags. Today a board queries the mesh's own database directly — th it works, and this rule makes it a migration rather than a preference. The reason to pay it is [`how-we-build`](../../00-META/how-we-build.md) §4's already-measured cost, not elegance. -### What it does not answer +### Checked against the real consumers -**The mesh's own registry is read by many things.** Under this rule they cannot read its tables, -so they consume its events or call its tools. That is achievable and it is a real change from -how the mesh works today, where reading the registry directly is ordinary — and it is the same -change [ADR 0037](../../02-DECISIONS/0037-the-host-applies-it-does-not-decide.md) already forces -on the host for unrelated reasons. +The rule's survival turned on whether every reader of the mesh's own registry could be served +some other way. **Eighteen consumers open a direct connection to it.** Four groups, and only one +of them is work. -Whether *every* consumer of the registry can be served by events and an interface is not -established here. It is the one thing that could make this rule unworkable, and it should be -checked against real consumers before the rule is recorded as a decision. +| Group | What happens under the rule | +|---|---| +| **The owner and its machinery** — the mesh module, the SDK, the environment and configuration synchronisers, secrets | Nothing. It owns the database. | +| **Node appliers** — the overlay, the shell daemon, the resolver | **Already resolved.** [ADR 0037](../../02-DECISIONS/0037-the-host-applies-it-does-not-decide.md) stops the host querying the mesh database, decided for tier reasons with nothing to do with this. | +| **Foreign tenants** — the work engine (10 tables), the knowledge base (2), pipeline logs (1) | They need **their own database**. They are not reading the registry; they are storing their own data in it. | +| **Genuine cross-context reads** — the work engine reads `nodes`; two others read a handful | The only ones needing an interface or events. | + +**Thirteen foreign tables live in the mesh's registry database**, belonging to three separate +contexts. That is [`how-we-build`](../../00-META/how-we-build.md) §4's shared schema, counted. + +**So the question was the wrong shape.** The bulk of the problem is not readers needing a new +route to data — it is **tenants needing to move out**. Tasks, agents and teams have nothing to do +with nodes and modules; they are co-located by history. Give that context its own database and +its dependency on the registry shrinks to a single table. + +What remains is a handful of genuine cross-context reads, small enough to enumerate rather than +estimate. **The rule holds.** + +### What it still does not answer + +Whether those remaining reads want an **interface** or **events**. A consumer asking *which +nodes exist* at the moment it needs to know is a request; one that must react *when a node +appears* is a subscription. Some will want both, and nothing here says which. ## A migration belongs to the consumer and runs on the provider