Two additions to the module-repository design, both from building it. A build machine has its own credential and it is not a node's: read the build queue, write the mesh exchange, nothing else. A node's queue carries that node's declarations. The answer goes through the exchange and never the default one, because permission there is per exchange rather than per queue — anything allowed to use it can publish into any node's queue. The price is that every asker sees every result and filters by correlation, which is cheap against a builder never needing that permission. And every result is kept, failures included, because one that leaves no trace is indistinguishable from a build nobody asked for. That is what a builds view reads; the board page is corrected to say so.
56 lines
2.9 KiB
Markdown
56 lines
2.9 KiB
Markdown
---
|
|
layer: to-be
|
|
status: designed
|
|
code: []
|
|
updated: 2026-08-30
|
|
decisions:
|
|
- 02-DECISIONS/0008-a-context-owns-its-store.md
|
|
- 02-DECISIONS/0001-mesh-brokers-nodes-host-agents-think.md
|
|
---
|
|
|
|
# A board
|
|
|
|
**A place to see the mesh.** Read from a survey of the one that exists, so what is proposed here
|
|
is a shorter list than what is there, deliberately.
|
|
|
|
## What the existing board does, and what of it belongs here
|
|
|
|
Eight sections. Four are about work and workers and are held back with the rest of that domain;
|
|
the other four are about the mesh itself.
|
|
|
|
| | what it shows | where it stands here |
|
|
|---|---|---|
|
|
| **the mesh** | every node, what each runs, what each takes from another, module versions | **everything behind it exists** — it is a reader, not a second source |
|
|
| **builds** | a build, its stages, its log | **everything behind it exists** — every result is kept, failures included |
|
|
| **sessions** | model sessions, their usage, and switching between accounts | [ADR 0024](../../02-DECISIONS/0024-model-access-is-a-provision.md) |
|
|
| **channels** | nodes messaging each other | the agent layer |
|
|
|
|
## The constraint that matters, and it is not a feature
|
|
|
|
**The existing board is one service that reads every context's database.** It joins nodes to
|
|
provisions to modules to sessions by querying each store directly, because that is the shortest
|
|
path to a page that shows all of them at once.
|
|
|
|
That is [ADR 0008](../../02-DECISIONS/0008-a-context-owns-its-store.md) violated by the one
|
|
component with a reason to violate it, and the cost is not hypothetical — it is the same cost the
|
|
shared library has: **a boundary nothing may cross is a boundary that can move; one thing crossing
|
|
it is enough to freeze it.** A board that reads the provisioning tables directly is a board that
|
|
breaks when provisioning changes its tables, and the change then gets weighed against the board.
|
|
|
|
**So a board reads through interfaces and holds nothing.** Everything on the mesh page above is
|
|
already answerable by asking the control plane — what nodes exist, what each resolves to, what it
|
|
takes from elsewhere, which module came from which commit. A board that asks those questions is a
|
|
client. A board that queries `inventory` is a second control plane with a worse contract.
|
|
|
|
**It stores nothing of its own.** No cache that can disagree, no table of "what the mesh looked
|
|
like last time". If a question is slow to answer, the answer belongs in the context that owns it,
|
|
where everything else asking gets it too.
|
|
|
|
## What it is not
|
|
|
|
- **Not the way to change things.** Reading is the whole of it to begin with. Every action the
|
|
board could offer already exists as a command, and a button that does something no command does
|
|
is a second implementation of a decision.
|
|
- **Not a dashboard of graphs.** What a person needs from a mesh is *which machine is not doing
|
|
what it was told*, and that is a list, not a chart.
|