Issue 121: retract step 4 — the forge's service is not built #125

2026-09-26T13:36:30Z

jschoubben commented

2026-09-26 13:36:30 +00:00

This morning's diagnosis claimed the forge cannot exist as a container before the builder has built its image. Wrong, and disprovable in one command.

The forge's server is an upstream public image pinned by digest; what the mesh builds is the forge's runtime sidecar, a separate container. The store and the broker have exactly the same shape — upstream server, built sidecar — and ADR 0078 raises both at genesis as plumbing and adopts them in place as ordinary modules afterwards. Nothing stops the forge being raised the same way, serving git, packages and OCI before anything at all has been built.

So the second arm of the cycle, as the diagnosis stated it, does not exist.

What survives is narrower and still worth answering: a grant is minted and delivered by the provider's runtime sidecar, and that sidecar is built. The question is whether a consumer can be granted a provision whose provider's sidecar is not yet running, and whether raise the service → grant → build the sidecar simply works. That is sequencing inside the mesh's machinery, not a chicken-and-egg about images, and it may not be a deadlock at all — which also means the carried fallback binding in the report's open questions may be answering a problem adopt-in-place already solves.

Retraction written in place with the wrong reasoning left visible, as issues 113 and 108 were handled. The cause is recorded too: the wrong version came from taking a record's bootstrap argument at face value instead of comparing it against how the store and the broker are actually raised.

Checks: cycle 286 documents, the chain holds; records 104, all passed; index current.

This morning's diagnosis claimed the forge cannot exist as a container before the builder has built its image. Wrong, and disprovable in one command. The forge's **server** is an upstream public image pinned by digest; what the mesh builds is the forge's **runtime sidecar**, a separate container. The store and the broker have exactly the same shape — upstream server, built sidecar — and ADR 0078 raises both at genesis as plumbing and **adopts them in place** as ordinary modules afterwards. Nothing stops the forge being raised the same way, serving git, packages and OCI before anything at all has been built. So the second arm of the cycle, as the diagnosis stated it, does not exist. What survives is narrower and still worth answering: a grant is minted and delivered by the **provider's runtime sidecar**, and that sidecar is built. The question is whether a consumer can be granted a provision whose provider's sidecar is not yet running, and whether *raise the service → grant → build the sidecar* simply works. That is sequencing inside the mesh's machinery, not a chicken-and-egg about images, and it may not be a deadlock at all — which also means the carried fallback binding in the report's open questions may be answering a problem adopt-in-place already solves. Retraction written in place with the wrong reasoning left visible, as issues 113 and 108 were handled. The cause is recorded too: the wrong version came from taking a record's bootstrap argument at face value instead of comparing it against how the store and the broker are actually raised. Checks: cycle 286 documents, the chain holds; records 104, all passed; index current.

jschoubben added 1 commit 2026-09-26 13:36:31 +00:00

Issue 121: retract step 4 — the forge's service is not built a1d8b478ec

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.

jschoubben merged commit 112963524f into main

2026-09-26 13:36:36 +00:00

jschoubben deleted branch issue/121-step-4-retracted

2026-09-26 13:36:36 +00:00

jschoubben referenced this pull request

2026-09-26 13:37:55 +00:00

Issue 123: the image registry is named after a role, and *artifact* is defined as one format #126

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: novox/hq#125