Reconcile: adopt initialization's consolidated HQ as canonical, re-home this session's new work #24
@@ -165,7 +165,7 @@ Struck-through rows are answered, with where. The rest are live.
|
||||
| ~~Is there one kind of edge?~~ | **No — two.** *Presence*, where a thing must exist, and *instantiation*, where a provider makes something for a consumer and hands back credentials. Instantiation implies presence, not the reverse. |
|
||||
| ~~When two modules provide one name, who chooses?~~ | Neither the consumer naming a node nor the consumer not caring. The consumer declares the **scope of its own need** — shared across its instances, or one each — the mesh binds, and the binding is written down and sticky. Where it is written follows the scope. |
|
||||
| ~~Can several modules share one database?~~ | **No.** A module is granted only what it exclusively owns — no shared writes and no read role on another's store, because reading couples you to its layout just as firmly. |
|
||||
| ~~What about a dashboard reading a dozen stores?~~ | The rule catches it correctly: a board is a *surface*, and surfaces speak to the control plane's interface. Exclusive ownership turns out to be **the tier rule expressed in terms of storage**. |
|
||||
| ~~What about a dashboard reading a dozen stores?~~ | **The rule is about contexts, not processes.** The mesh's own board reading the mesh's own store is the mesh showing its own data — not a boundary crossing. Everything inside a context reads its store freely; what is forbidden is a *different* context reading it. An earlier answer here was wrong. |
|
||||
| ~~Can every registry consumer be served another way?~~ | **Largely dissolves.** Of eighteen direct consumers, the owner keeps its database, node appliers are already stopped by ADR 0037, and the bulk are **foreign tenants** — thirteen tables across three contexts — who need to move out rather than read differently. |
|
||||
|
||||
### Live
|
||||
|
||||
@@ -208,29 +208,23 @@ first clear instance:
|
||||
against itself.
|
||||
- **A whole class of permission modelling** that a shared store would otherwise need.
|
||||
|
||||
### The hardest case for it: a dashboard reading everything
|
||||
### The rule is about contexts, not processes
|
||||
|
||||
Raised immediately, and it is the right test — a board showing nodes, modules, pipelines, agents
|
||||
and tasks wants to read a dozen stores. Under this rule it cannot read any of them.
|
||||
An earlier version of this file argued that a dashboard reading a dozen stores was caught by the
|
||||
rule, because a dashboard is a surface and surfaces speak to an interface. **That was wrong, and
|
||||
it drew the line in the wrong place.**
|
||||
|
||||
**It survives, and not by luck: the board is a surface, and surfaces already may not do this.**
|
||||
The skeleton puts `api/` in the control plane as *the one interface every surface speaks to*, and
|
||||
tier 3 as *thin; no logic lives here*. A board reading stores directly is a surface reaching past
|
||||
the context that owns the data — which the tier rule forbids for reasons that have nothing to do
|
||||
with databases.
|
||||
The mesh's own board showing nodes, modules and deployments is not a separate context reaching
|
||||
across a boundary. It is the mesh showing its own data. Reading that store is not a violation
|
||||
however it is done, and requiring it to go through an interface to reach facts its own context
|
||||
owns would be ceremony.
|
||||
|
||||
So the dashboard is not a counter-example. It is an instance the rule catches, and the two rules
|
||||
turn out to be one rule seen from two sides: **exclusive ownership is the tier rule, expressed in
|
||||
terms of storage.**
|
||||
**The rule is: a context is granted what it exclusively owns.** Everything inside that context —
|
||||
its service, its surface, its tools — reads it freely. What is forbidden is a *different*
|
||||
context reading it.
|
||||
|
||||
**The general shape, for anything that needs to see across many things:** consume the record and
|
||||
own your own view. A reporting context builds a projection from events and reads its own store.
|
||||
It does not read anybody else's.
|
||||
|
||||
**And the cost is not small, so it should be said plainly.** A projection is more work than a
|
||||
join, and it lags. Today a board queries the mesh's own database directly — that is ordinary,
|
||||
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.
|
||||
Which is exactly what the count below shows: the problem was never surfaces. It was three other
|
||||
contexts keeping their tables in the mesh's database.
|
||||
|
||||
### Checked against the real consumers
|
||||
|
||||
|
||||
Reference in New Issue
Block a user