What a builder-as-a-module can and cannot reach

The broker's fingerprint travels with its credential, and the machine's filesystem does not travel at all — it runs in a container, which is the arrangement working rather than a limitation to route around.
2026-08-31 01:53:35 +02:00
parent 8448219de1
commit 6b1c80b442
1 changed files with 13 additions and 0 deletions
@@ -138,6 +138,19 @@ file arrives readable only by that machine, names the scoped account rather than
 and the build completes — which is the only proof the credential authenticates, because a
 container that is up holding a credential it cannot use looks identical from outside.*
 **And it is told what to check the broker against**, not only who to connect as. A mesh's broker
 presents a certificate of the mesh's own, which is in no public trust store, so a URL alone reaches
 only a broker somebody else vouches for — which is no mesh broker at all. The credential carries
 the fingerprint beside the URL: **the same two facts a node's token carries**
 ([ADR 0004](../../02-DECISIONS/0004-a-node-and-how-it-joins.md)), for the same reason, arriving by
 a path other than the thing being trusted.
 **A builder that is a module cannot see the machine's filesystem.** It runs in a container, so a
 local path exists for the machine and not for it. That is not a limitation to work around — it is
 the arrangement working: a build machine shares the runtime it was given rather than the machine
 it sits on. **A module is cloned from the forge over a URL**, and "build this directory" is a
 convenience for a builder somebody started by hand.
 ## What is kept
 **Every result, including the failures.** A failed build that leaves no trace is indistinguishable