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`