From a1d8b478ec0f66da9b9dac355b0597af94e77781 Mon Sep 17 00:00:00 2001 From: jochen Date: Sat, 26 Sep 2026 15:36:19 +0200 Subject: [PATCH] =?UTF-8?q?Issue=20121:=20retract=20step=204=20=E2=80=94?= =?UTF-8?q?=20the=20forge's=20service=20is=20not=20built?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Step 4 claimed the forge cannot exist as a container before the builder has built its image. The forge's server is an upstream public image pinned by digest; only its runtime sidecar is built. The store and the broker have the same shape, and ADR 0078 raises both at genesis as plumbing and adopts them in place — so the forge can be raised the same way and serve git, packages and OCI before anything is built. What survives: a grant is minted by the provider's runtime sidecar, which is built, so the question is whether raise-service, grant, build-sidecar simply works. Sequencing inside the mesh, not images. The wrong version came from taking a record's bootstrap argument at face value instead of comparing it to how the store and broker are raised — one command away in the manifests. --- .../01-diagnosis.md | 30 +++++++++++++++++++ 1 file changed, 30 insertions(+) diff --git a/04-ISSUES/121-builders-real-package-registry-grant-deadlocks-genesis/01-diagnosis.md b/04-ISSUES/121-builders-real-package-registry-grant-deadlocks-genesis/01-diagnosis.md index 769a18e..216e66a 100644 --- a/04-ISSUES/121-builders-real-package-registry-grant-deadlocks-genesis/01-diagnosis.md +++ b/04-ISSUES/121-builders-real-package-registry-grant-deadlocks-genesis/01-diagnosis.md @@ -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` -- 2.54.0