What a build machine may do, and what is kept

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.
2026-08-30 10:29:01 +02:00
parent 4151c28927
commit 41a4405253
2 changed files with 25 additions and 1 deletions
@@ -21,7 +21,7 @@ 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 | the builder exists; **what is missing is a record of past builds**, since a result is answered to whoever asked and kept nowhere |
+| **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 |