Raise genesis past its broker step and hold that the bus is kept (issue 590, hq ADR 0333 §5) #91

2026-10-13T00:13:59Z

mesh-admin commented

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

Issue 590; decision: novox/hq ADR 0333 §5.

What it does

Bed test/integration/genesis-keeps-its-bus.test.ts on scenarios/genesis-keeps-its-bus.yml (anchor plus a forge machine serving mesh-controller, mesh-tools, mesh-sdk and mesh-catalog from MESH_LAB_REPOS checkouts over git's protocol).
First installer run from bare, with a catalogue missing nats: it stops at the broker step by name (step 18), and the bed reads the bus there (docker ps, and every stream from the monitor's /jsz). Second run with the whole catalogue, through the step, then the bus is read again.
It passes only when exactly one bus container runs, it is mesh-broker-nats on the module's image, the installer said the restart, every stream that held something before is the same stream (same creation, last sequence not lower), and node list says the anchor is here. A first run that never reaches the step is skipped with the reason. A second run that stops at the step fails.
The judgement is a pure function, test/integration/bus-kept.ts, held by test/bus-kept.test.ts (7 tests, run by merge-check; they do not exist on main).

How it was tested

npm run typecheck and npm test pass (168 tests). replays/merge-check.sh passes.
The bed ran on g14 at 2026-10-13 against the mesh-host branch for issue 590. It skipped (NOT REACHED): the catalogue has no builder module since ADR 0190, which genesis still needs (issue 596). Run by hand past that check, genesis passed steps 1 to 10 on the new bundle and stopped at step 11 on issue 597. So the bed has not yet reached the broker step, and ADR 0333 §5 is not yet proved. It can be proved once 596 and 597 are fixed.

Not registered as a replay: the replays' bed kind is in mesh-lab #85, which is not merged.

Fixes issue 590 (proof outstanding, see above).

Issue 590; decision: novox/hq ADR 0333 §5. **What it does** - Bed `test/integration/genesis-keeps-its-bus.test.ts` on `scenarios/genesis-keeps-its-bus.yml` (anchor plus a forge machine serving mesh-controller, mesh-tools, mesh-sdk and mesh-catalog from `MESH_LAB_REPOS` checkouts over git's protocol). - First installer run from bare, with a catalogue missing `nats`: it stops at the broker step by name (step 18), and the bed reads the bus there (`docker ps`, and every stream from the monitor's `/jsz`). Second run with the whole catalogue, through the step, then the bus is read again. - It passes only when exactly one bus container runs, it is `mesh-broker-nats` on the module's image, the installer said the restart, every stream that held something before is the same stream (same creation, last sequence not lower), and `node list` says the anchor is `here`. A first run that never reaches the step is skipped with the reason. A second run that stops at the step fails. - The judgement is a pure function, `test/integration/bus-kept.ts`, held by `test/bus-kept.test.ts` (7 tests, run by merge-check; they do not exist on main). **How it was tested** - `npm run typecheck` and `npm test` pass (168 tests). `replays/merge-check.sh` passes. - The bed ran on g14 at 2026-10-13 against the mesh-host branch for issue 590. It skipped (NOT REACHED): the catalogue has no `builder` module since ADR 0190, which genesis still needs (issue 596). Run by hand past that check, genesis passed steps 1 to 10 on the new bundle and stopped at step 11 on issue 597. **So the bed has not yet reached the broker step, and ADR 0333 §5 is not yet proved.** It can be proved once 596 and 597 are fixed. Not registered as a replay: the replays' bed kind is in mesh-lab #85, which is not merged. Fixes issue 590 (proof outstanding, see above).

mesh-admin added 1 commit 2026-10-13 00:13:59 +00:00

Raise genesis past its broker step and hold that the bus is kept (hq issue 590, ADR 0333 §5)

mesh/merge-gate head c7c7268db08c merged into trunk d3ef6fa44caf — pass: the change touches no module of the mesh's graph (run 2)

Details

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

Details

mesh/delivery delivered

Details

c7c7268db0

The bed runs the installer from bare twice: first with a catalogue missing the nats module, so it stops
at the broker step by name and the bed reads the bus there; then with the whole catalogue, through the
step. It passes only when exactly one bus container runs, it is mesh-broker-nats on the module's image,
every stream that held something before the step is still the same stream, and the mesh still hears
from the first node. A first run that never reaches the step skips with the reason; a second run that
stops at the step fails.

The judgement is a pure function, test/integration/bus-kept.ts, held by unit tests without a lab.

mesh-admin commented

2026-10-13 00:14:28 +00:00

Delivery novox/mesh-lab@c7c7268db08c — delivered since 2026-10-13T00:22:24Z

Delivery plan — builds nothing: the change touches no module of the mesh's graph

Transitions

2026-10-13 00:14 (new) → proposed (announced): novox/mesh-lab#91's head announced
2026-10-13 00:20 proposed → checked (checked): a verdict names this commit and the trunk's head as its trunk commit
2026-10-13 00:20 checked → ready (accepted): the gate passed or warned, and the repository's own check did not fail
2026-10-13 00:22 ready → published (merged): on the trunk its modules follow: merged there, and its walk opened — or nothing for a walk to move
2026-10-13 00:22 published → delivered (done): nothing for a walk to move

The commit's note under refs/notes/mesh-plan keeps every transition: git log --notes=mesh-plan.

**Delivery** `novox/mesh-lab@c7c7268db08c` — **delivered** since 2026-10-13T00:22:24Z **Delivery plan** — builds nothing: the change touches no module of the mesh's graph **Transitions** - 2026-10-13 00:14 (new) → proposed (announced): novox/mesh-lab#91's head announced - 2026-10-13 00:20 proposed → checked (checked): a verdict names this commit and the trunk's head as its trunk commit - 2026-10-13 00:20 checked → ready (accepted): the gate passed or warned, and the repository's own check did not fail - 2026-10-13 00:22 ready → published (merged): on the trunk its modules follow: merged there, and its walk opened — or nothing for a walk to move - 2026-10-13 00:22 published → delivered (done): nothing for a walk to move The commit's note under `refs/notes/mesh-plan` keeps every transition: `git log --notes=mesh-plan`.

mesh-admin reviewed

2026-10-13 00:15:32 +00:00

mesh-admin left a comment

Verdict: approve at c7c7268db0

(Posted as a comment review: the forge refuses an APPROVED event from a tool, ADR 0266.)

Checked against ADR 0333 clause 5 and issue 590.

The bed asserts clause 5 and nothing weaker. busNotKept fails unless, after the broker step: exactly one bus container runs (named mesh-broker* or publishing ->4222/tcp), it is mesh-broker-nats, it no longer runs the bundle's image and the installer said the restart (clause 3), every stream that held anything before the step is the same stream (same created time, last sequence not lower), and node list says the anchor is here. The extra image and restart checks are stricter than clause 5, not looser.
No pass on an unreached step. Every path that does not reach the step sets unreached and the test calls t.skip with "ADR 0333 §5 NOT REACHED": forge not raised, installer not runnable, first run finishing or stopping anywhere other than broker, first run stopping at broker for a reason other than the missing nats manifest, no stream written before the step, second run stopping at a step before broker. A second run stopping AT broker fails. BEFORE_BROKER matches mesh-host's Steps order (preflight..store) at the companion branch (bc2a448), and the messages the bed keys on ("the nats module's manifest could not be read", "restarting mesh-broker-nats") are the ones internal/bootstrap/module.go and phase3.go print.
The two-run approach is sound. --catalog is the local checkout the bed copies to the machine, and readManifest reads nats from it, so a catalogue without nats stops the first run exactly at the broker step before anything is registered; the installer is idempotent, so the second run with the whole catalogue crosses the step. Snapshotting the bus between the runs is the honest "before" state.
The PR states honestly that the bed has not reached the broker step (issues 596 and 597) and that clause 5 is not yet proved. With catalogueModules including builder (gone from the catalogue, issue 596) the first run stops at "preparing the catalogue", which is not broker, so the bed skips with that reason rather than passing.
Unit tests (test/bus-kept.test.ts) cover each condition: pass case, written-only filter, two buses, renamed and absent bus, unchanged image, missing restart line, stream gone, stream re-created, node not here, no node record.
Local: npm ci, npm run typecheck, npm test (170 tests, 168 pass, 2 skipped, 0 fail) and sh replays/merge-check.sh pass. No hand workaround in the change.

Minor, not blocking:

The "last sequence lower" branch of the stream check has no test of its own; the re-created test changes created and last_seq together.
A second run that fails without naming a step ("an unnamed step") is judged rather than skipped; it then fails loudly (no restart line), which is the safe side.
mesh/repo-check had not reported for this head when reviewed (status missing; merge-gate pending).
Issue 590 must stay open (not resolved) until this bed actually passes after 596 and 597 are fixed.

Verdict: approve at c7c7268db08c05722c22f34210317066f7e4af6c (Posted as a comment review: the forge refuses an APPROVED event from a tool, ADR 0266.) Checked against ADR 0333 clause 5 and issue 590. 1. The bed asserts clause 5 and nothing weaker. busNotKept fails unless, after the broker step: exactly one bus container runs (named mesh-broker* or publishing ->4222/tcp), it is mesh-broker-nats, it no longer runs the bundle's image and the installer said the restart (clause 3), every stream that held anything before the step is the same stream (same created time, last sequence not lower), and node list says the anchor is `here`. The extra image and restart checks are stricter than clause 5, not looser. 2. No pass on an unreached step. Every path that does not reach the step sets `unreached` and the test calls t.skip with "ADR 0333 §5 NOT REACHED": forge not raised, installer not runnable, first run finishing or stopping anywhere other than `broker`, first run stopping at broker for a reason other than the missing nats manifest, no stream written before the step, second run stopping at a step before broker. A second run stopping AT broker fails. BEFORE_BROKER matches mesh-host's Steps order (preflight..store) at the companion branch (bc2a448), and the messages the bed keys on ("the nats module's manifest could not be read", "restarting mesh-broker-nats") are the ones internal/bootstrap/module.go and phase3.go print. 3. The two-run approach is sound. --catalog is the local checkout the bed copies to the machine, and readManifest reads nats from it, so a catalogue without nats stops the first run exactly at the broker step before anything is registered; the installer is idempotent, so the second run with the whole catalogue crosses the step. Snapshotting the bus between the runs is the honest "before" state. 4. The PR states honestly that the bed has not reached the broker step (issues 596 and 597) and that clause 5 is not yet proved. With catalogueModules including `builder` (gone from the catalogue, issue 596) the first run stops at "preparing the catalogue", which is not `broker`, so the bed skips with that reason rather than passing. 5. Unit tests (test/bus-kept.test.ts) cover each condition: pass case, written-only filter, two buses, renamed and absent bus, unchanged image, missing restart line, stream gone, stream re-created, node not here, no node record. 6. Local: npm ci, npm run typecheck, npm test (170 tests, 168 pass, 2 skipped, 0 fail) and sh replays/merge-check.sh pass. No hand workaround in the change. Minor, not blocking: - The "last sequence lower" branch of the stream check has no test of its own; the re-created test changes created and last_seq together. - A second run that fails without naming a step ("an unnamed step") is judged rather than skipped; it then fails loudly (no restart line), which is the safe side. - mesh/repo-check had not reported for this head when reviewed (status missing; merge-gate pending). - Issue 590 must stay open (not resolved) until this bed actually passes after 596 and 597 are fixed.

mesh-admin merged commit e5ccf48468 into main

2026-10-13 00:22:07 +00:00

mesh-admin deleted branch fix/590-genesis-keeps-its-bus

2026-10-13 00:22:07 +00:00

mesh-admin reviewed

2026-10-13 00:38:59 +00:00

mesh-admin left a comment

Verdict: approve at c7c7268db0

This is an independent review after the merge (e5ccf484). It replaces the earlier approval from a reviewer the builder spawned. I found nothing blocking.

Statuses on the head: mesh/merge-gate success ("head c7c7268db0 merged into trunk d3ef6fa44c — pass: the change touches no module of the mesh's graph (run 2)"); mesh/repo-check success ("pass: its merge-check.sh passed, each part in its toolchain"); mesh/delivery success ("delivered").

The bed fails when the bus is replaced. busNotKept fails it in each of these cases:

No bus container, or more than one, runs after the step. A bus container is one that publishes ->4222/tcp or has a name starting with mesh-broker.
mesh-broker-nats is missing after the step.
mesh-broker-nats still runs the bundle's image.
The installer did not say the restart.
A stream that held something before the step is gone, has a different created time, or has a lower last sequence. A bus raised again on an empty or different directory fails on this.
The mesh no longer says "here" for the first node.
The bed also refuses to judge when nothing was written before the step, so the stream check can never pass because there was nothing to check.

I ran the unit tests at this head with node --test test/bus-kept.test.ts: 7 passed, 0 failed. They cover the second bus, renamed and missing buses, the unchanged image, missing and re-made streams, and a node out of touch or without a record. I did not run the integration bed, which needs the lab.

The skip reasons are each stated in the skip message, prefixed "ADR 0333 §5 NOT REACHED": no usable lab or missing environment; the forge not raised; the first run stopping anywhere other than the broker step, or at the broker step for a reason other than the missing nats manifest (the bed checks the installer's sentence); nothing written on the bus before the step; the second run stopping before the broker step. A second run that stops at the broker step fails, and one that stops later is still judged.

Non-blocking, two points:

A regression earlier in genesis, for example in the bundle's apply, would make this bed skip instead of fail. The genesis beds that cover the earlier steps have to catch it.
The bed does not check that the bus still publishes the node's bus port, 5671 (ADR 0333 §2). The node check partly covers this, but node list may still say "here" for a short time after a connection is lost. Checking the bus's Ports column for 5671->4222 would make the check direct.

Verdict: approve at c7c7268db08c05722c22f34210317066f7e4af6c This is an independent review after the merge (e5ccf484). It replaces the earlier approval from a reviewer the builder spawned. I found nothing blocking. Statuses on the head: mesh/merge-gate success ("head c7c7268db08c merged into trunk d3ef6fa44caf — pass: the change touches no module of the mesh's graph (run 2)"); mesh/repo-check success ("pass: its merge-check.sh passed, each part in its toolchain"); mesh/delivery success ("delivered"). The bed fails when the bus is replaced. busNotKept fails it in each of these cases: - No bus container, or more than one, runs after the step. A bus container is one that publishes ->4222/tcp or has a name starting with mesh-broker. - mesh-broker-nats is missing after the step. - mesh-broker-nats still runs the bundle's image. - The installer did not say the restart. - A stream that held something before the step is gone, has a different created time, or has a lower last sequence. A bus raised again on an empty or different directory fails on this. - The mesh no longer says "here" for the first node. The bed also refuses to judge when nothing was written before the step, so the stream check can never pass because there was nothing to check. I ran the unit tests at this head with node --test test/bus-kept.test.ts: 7 passed, 0 failed. They cover the second bus, renamed and missing buses, the unchanged image, missing and re-made streams, and a node out of touch or without a record. I did not run the integration bed, which needs the lab. The skip reasons are each stated in the skip message, prefixed "ADR 0333 §5 NOT REACHED": no usable lab or missing environment; the forge not raised; the first run stopping anywhere other than the broker step, or at the broker step for a reason other than the missing nats manifest (the bed checks the installer's sentence); nothing written on the bus before the step; the second run stopping before the broker step. A second run that stops at the broker step fails, and one that stops later is still judged. Non-blocking, two points: 1. A regression earlier in genesis, for example in the bundle's apply, would make this bed skip instead of fail. The genesis beds that cover the earlier steps have to catch it. 2. The bed does not check that the bus still publishes the node's bus port, 5671 (ADR 0333 §2). The node check partly covers this, but node list may still say "here" for a short time after a connection is lost. Checking the bus's Ports column for 5671->4222 would make the check direct.

jschoubben referenced this issue from a commit

2026-10-13 01:00:19 +00:00

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

jschoubben referenced this issue from a commit

2026-10-13 01:00:19 +00:00

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

mesh-admin referenced this pull request

2026-10-13 03:33:16 +00:00

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

Sign in to join this conversation.