Merge pull request 'Issue 121: retract step 4 — the forge's service is not built' (#125) from issue/121-step-4-retracted into main

2026-09-26 13:36:36 +00:00
parent 1489d17238 a1d8b478ec
commit 112963524f
1 changed files with 30 additions and 0 deletions
@@ -40,6 +40,36 @@ toolchain's build and runtime bases like every other built module. `builder` is
 build. So both arms stand: the builder cannot be assigned before the forge provides the registry,
 and the forge cannot exist as a container before the builder has built its image.

+## 2026-09-26, later — Step 4 is retracted: the forge's service is not built
+
+Step 4 said the forge's runtime image is compiled by the builder, so the forge cannot exist as a
+container before the builder has built it. **That is not what the forge's definition says**, and it
+took one command to disprove.
+
+The forge's **server** is an upstream public image pinned by digest. What the mesh builds is the
+forge's **runtime sidecar** — its own agent beside the service, a separate container. The store and
+the broker have exactly the same shape: an upstream server image, a built sidecar. And that shape is
+the point, because [ADR 0078](../../02-DECISIONS/0078-the-store-and-broker-are-modules.md) raises the
+store and the broker at genesis as plumbing and **adopts them in place** as ordinary modules
+afterwards. Nothing stops the forge being raised the same way: its service can be serving git,
+packages and OCI before anything at all has been built.
+
+So the second arm of the cycle, as this diagnosis stated it, does not exist.
+
+**What survives is narrower and is still worth answering.** A grant — the credential the builder
+would use against the package registry — is minted and delivered by the **provider's runtime
+sidecar**, and that sidecar is built. So the question is whether a consumer can be granted a
+provision whose provider's sidecar is not yet running, and whether the ordering
+*raise the service → grant → build the sidecar* simply works. That is sequencing inside the mesh's
+own machinery, not a chicken-and-egg about images, and it may not be a deadlock at all.
+
+The report's open questions should be read against this. In particular, a carried fallback binding
+may be answering a problem that adopt-in-place already solves.
+
+**Why the error is recorded rather than edited away:** the wrong version was reached by taking a
+record's bootstrap argument at face value instead of checking it against how the store and the broker
+are actually raised — which is the one comparison the manifests make available in a single command.
+
 ## What did change, and why it is the part worth recording

 The three tests that pinned the carried-fallback design — the builder's own `package-binding`