#85 - Register R92 as a bed: genesis on a runtime that trusts no registry (hq issue 92) — NOT PROVED, blocked by issue 146 - mesh-lab

Conversation 2 Commits 2 Files Changed 5

+462 -2

2 Commits

Author	SHA1	Message	Date
jochen	0714f7a509	Pin R92 to today's genesis: main with every genesis fix, and the same without #91 (hq issue 92) mesh/merge-gate head 0714f7a50933 merged into trunk 6ba65a12f218 — pass: the change touches no module of the mesh's graph Details mesh/repo-check head 0714f7a50933 merged into trunk 6ba65a12f218 — pass: its merge-check.sh passed, each part in its toolchain: merge-check.sh (typescript)… Details mesh/delivery delivered Details At the fix's merge no genesis got past step 6 (issue 146), so neither side of the replay reached the push it replays. Fix is mesh-host main 0d11b4fc; Before is that main with #91 reverted, on the unmerged branch replay/r92-before; the controller and catalogue at their mains on both sides.	2026-10-13 02:59:45 +02:00
jochen	d03f87b00d	Register R92 as a bed: genesis on a runtime that trusts no registry (hq issue 92) The lab's base image trusts the documentation ranges as plain-HTTP registries, so no genesis bed could see the push to an untrusted registry that issue 92 is about (reviews 73 and 76 on mesh-host #91). The bed takes that trust off the anchor before the installer runs and asks the runtime it trusts loopback only, then runs genesis with --registry 192.0.2.10:5000 and holds that the control plane reaches the registry, trusted by the mesh's name too. The prover gains a bed kind: it builds the node-engine and its installer at each commit, the carried builder from the pinned controller, and raises the bed; a bed that never reached the step it replays skips, and a skip is an error, never the fault reproduced. Not proved yet: genesis stops at step 6 on both sides, because the temporary controller has no MESH_BUS_NATS and the bus template is refused by the installer (issue 146).	2026-10-13 02:57:21 +02:00

Author

SHA1

Message

Date

jochen

0714f7a509

Pin R92 to today's genesis: main with every genesis fix, and the same without #91 (hq issue 92)

mesh/merge-gate head 0714f7a50933 merged into trunk 6ba65a12f218 — pass: the change touches no module of the mesh's graph

Details

mesh/repo-check head 0714f7a50933 merged into trunk 6ba65a12f218 — pass: its merge-check.sh passed, each part in its toolchain: merge-check.sh (typescript)…

Details

mesh/delivery delivered

Details

At the fix's merge no genesis got past step 6 (issue 146), so neither side of the replay reached the
push it replays. Fix is mesh-host main 0d11b4fc; Before is that main with #91 reverted, on the
unmerged branch replay/r92-before; the controller and catalogue at their mains on both sides.

2026-10-13 02:59:45 +02:00

jochen

d03f87b00d

Register R92 as a bed: genesis on a runtime that trusts no registry (hq issue 92)

The lab's base image trusts the documentation ranges as plain-HTTP registries, so no genesis bed could
see the push to an untrusted registry that issue 92 is about (reviews 73 and 76 on mesh-host #91). The
bed takes that trust off the anchor before the installer runs and asks the runtime it trusts loopback
only, then runs genesis with --registry 192.0.2.10:5000 and holds that the control plane reaches the
registry, trusted by the mesh's name too.

The prover gains a bed kind: it builds the node-engine and its installer at each commit, the carried
builder from the pinned controller, and raises the bed; a bed that never reached the step it replays
skips, and a skip is an error, never the fault reproduced.

Not proved yet: genesis stops at step 6 on both sides, because the temporary controller has no
MESH_BUS_NATS and the bus template is refused by the installer (issue 146).

2026-10-13 02:57:21 +02:00

Register R92 as a bed: genesis on a runtime that trusts no registry (hq issue 92) — NOT PROVED, blocked by issue 146 #85