hq issue 305.mesh-delivery.recheck asked the controller's delivery-check for the same head the forge had already judged. The forge keeps the newest status of each context, and nobody reset mesh/merge-gate / mesh/repo-check: the forge's holder sets pending only when it announces a new head, and the controller's recheck path (PullUpdated called directly) bypasses that announcement. So the old green stood and branch protection would merge on it while the fresh check ran (mesh-controller #112, 2026-10-07; #127/#116 later turned red).
mesh-delivery: Recheck tries the transition on a copy, then asks the forge's holder to set mesh/merge-gate (always) and mesh/repo-check (when the head holds one: a verdict that says none would leave a pending one standing for ever) to pending, "checking again: ", and only then moves the delivery and asks the check. A forge that cannot be told refuses the recheck whole: state unchanged, nothing asked on a stale verdict.
gitea: gitea_commit_status takes pending, and only pending, on the merge check's contexts — no verdict by hand, so issue 293 holds.
Tests: recheck_test.go (TestARecheck*) fails on main, passes here — the replay R305 (novox/mesh-lab PR, proved). gitea test/delivery.test.ts fails on main, passes here.
Rollout order: gitea before mesh-delivery — until the holder takes pending, every recheck is refused (safe, but refused).
**hq issue 305.** `mesh-delivery.recheck` asked the controller's `delivery-check` for the same head the forge had already judged. The forge keeps the newest status of each context, and nobody reset `mesh/merge-gate` / `mesh/repo-check`: the forge's holder sets pending only when it announces a *new* head, and the controller's recheck path (`PullUpdated` called directly) bypasses that announcement. So the old green stood and branch protection would merge on it while the fresh check ran (mesh-controller #112, 2026-10-07; #127/#116 later turned red).
- **mesh-delivery**: `Recheck` tries the transition on a copy, then asks the forge's holder to set `mesh/merge-gate` (always) and `mesh/repo-check` (when the head holds one: a verdict that says none would leave a pending one standing for ever) to `pending`, "checking again: <why>", and only then moves the delivery and asks the check. A forge that cannot be told refuses the recheck whole: state unchanged, nothing asked on a stale verdict.
- **gitea**: `gitea_commit_status` takes `pending`, and only pending, on the merge check's contexts — no verdict by hand, so issue 293 holds.
Tests: `recheck_test.go` (`TestARecheck*`) fails on main, passes here — the replay R305 (novox/mesh-lab PR, proved). gitea `test/delivery.test.ts` fails on main, passes here.
Rollout order: **gitea before mesh-delivery** — until the holder takes pending, every recheck is refused (safe, but refused).
A recheck asks of the head the forge already judged, and the forge keeps
the newest status of each context on it. Nobody reset mesh/merge-gate or
mesh/repo-check, so the old green stood and branch protection would merge
on it while the fresh check ran; rechecked heads did turn red.
mesh-delivery's recheck now asks the forge's holder to set the gate, and
the repository check when the head holds one, to pending ("checking
again: <why>") before it asks the controller; a forge that cannot be told
refuses the recheck whole. The gitea holder takes pending, and only
pending, on the merge check's statuses by hand: no verdict, so issue 293
still holds.
Deliverynovox/mesh-catalog@74f912e1fb4b — delivered since 2026-10-08T08:38:08Z
Delivery plan — builds gitea, mesh-delivery → novox; no bus step
tier 0: gitea, mesh-delivery
novox: receives gitea, mesh-delivery
gitea provides npm-package-registry, git: its consumers are sent again after it
gitea keeps data (ADR 0233): what it holds is backed up before it moves
Machines
gitea on novox: passed — healthy 3 times over 2m40s
mesh-delivery on novox: passed — judged with gitea: healthy 3 times over 2m40s
route-proxy on ace: judging — carried by plan-1791447797407441990
gitea on the rest running it: sent
mesh-delivery on the rest running it: sent
Transitions
2026-10-08 08:12 (new) → proposed (announced): novox/mesh-catalog#118's head announced
2026-10-08 08:14 proposed → checked (checked): the verdict names this commit
2026-10-08 08:14 checked → ready (accepted): the gate passed or warned, and the repository's own check did not fail
2026-10-08 08:34 ready → published (merged): on the trunk its modules follow: merged there, and its walk opened — or nothing for a walk to move
2026-10-08 08:34 published → delivering (go): its walk started: let go by this owner in its group's order, by a person, or on the controller's own path
2026-10-08 08:38 delivering → delivered (done): its walk is done: every machine of its deploy plan passed, or was left as its policy says
The commit's note under refs/notes/mesh-plan keeps every transition: git log --notes=mesh-plan.
<!-- mesh-delivery:view -->
**Delivery** `novox/mesh-catalog@74f912e1fb4b` — **delivered** since 2026-10-08T08:38:08Z
**Delivery plan** — builds gitea, mesh-delivery → novox; no bus step
- tier 0: gitea, mesh-delivery
- novox: receives gitea, mesh-delivery
- gitea provides npm-package-registry, git: its consumers are sent again after it
- gitea keeps data (ADR 0233): what it holds is backed up before it moves
**Machines**
- gitea on novox: passed — healthy 3 times over 2m40s
- mesh-delivery on novox: passed — judged with gitea: healthy 3 times over 2m40s
- route-proxy on ace: judging — carried by plan-1791447797407441990
- gitea on the rest running it: sent
- mesh-delivery on the rest running it: sent
**Transitions**
- 2026-10-08 08:12 (new) → proposed (announced): novox/mesh-catalog#118's head announced
- 2026-10-08 08:14 proposed → checked (checked): the verdict names this commit
- 2026-10-08 08:14 checked → ready (accepted): the gate passed or warned, and the repository's own check did not fail
- 2026-10-08 08:34 ready → published (merged): on the trunk its modules follow: merged there, and its walk opened — or nothing for a walk to move
- 2026-10-08 08:34 published → delivering (go): its walk started: let go by this owner in its group's order, by a person, or on the controller's own path
- 2026-10-08 08:38 delivering → delivered (done): its walk is done: every machine of its deploy plan passed, or was left as its policy says
The commit's note under `refs/notes/mesh-plan` keeps every transition: `git log --notes=mesh-plan`.
mesh/merge-gate: PASS — every machine composes with the change as it did without (4 of 4 compose) (modules: gitea, mesh-delivery)
mesh/repo-check: PASS — its merge-check.sh passed
Delivery plan — builds gitea, mesh-delivery → novox; no bus step
tier 0: gitea, mesh-delivery
novox: receives gitea, mesh-delivery
gitea provides npm-package-registry, git: its consumers are sent again after it
gitea keeps data (ADR 0233): what it holds is backed up before it moves
Run by the build seat on shanks as build-1791447133414166486 (builds --log build-1791447133414166486).
--- the gate: gitea, mesh-delivery
gitea: ok, keeps data (valuable); WARNING: server stay(s) up and say(s) not how it is ready — judged by liveness alone, refused from 2026-11-18 (ADR 0240 rule 8)
mesh-delivery: ok, 1 tool(s), invokes seat:mesh-controller.delivery-plan, seat:mesh-controller.delivery-order, seat:mesh-controller.delivery-check, seat:mesh-controller.deliver, seat:mesh-controller.delivery-stop, seat:mesh-controller.delivery-walks, gitea.gitea_note_append, gitea.gitea_delivery_view, gitea.gitea_commit_status, gitea.gitea_commit_statuses, keeps state deliveries, groups
long-running resources without health: 1
2 manifest(s) checked. Judged against the seats this binary carries; a claim on one of the mesh's own seats is judged fully at registration, and a seat declared by a module not given here reads as unknown. Identities judged on a 6-character machine name, against the bounds of the providers given here
judging 1 module(s) changed against 4 machine(s), as the snapshot of 2026-10-08T00:58:30Z says they run
composing every machine as the mesh is
the bus's user list leaves out 5 user(s) the mesh has minted no credential for: controller, node.f35, node.idt, node.ygcyr, node.yvbpsm. Each is a user that cannot connect until one is issued
the bus's user list leaves out 5 user(s) the mesh has minted no credential for: controller, node.f35, node.idt, node.ygcyr, node.yvbpsm. Each is a user that cannot connect until one is issued
composing every machine with the change
the bus's user list leaves out 5 user(s) the mesh has minted no credential for: controller, node.f35, node.idt, node.ygcyr, node.yvbpsm. Each is a user that cannot connect until one is issued
the bus's user list leaves out 5 user(s) the mesh has minted no credential for: controller, node.f35, node.idt, node.ygcyr, node.yvbpsm. Each is a user that cannot connect until one is issued
merge gate: PASS — every machine composes with the change as it did without (4 of 4 compose)
judged by controller development build against the facts of 2026-10-08T00:58:30Z
modules the change moves:
- gitea (changed)
machines:
- a machine (f35): composes
- holds mesh-dns-resolver (idt): composes
- holds git, holds mesh-artifact-store, holds mesh-broker, holds mesh-catalog, holds mesh-delivery, holds mesh-dns-resolver, holds mesh-store, holds mesh-vault, holds npm-package-registry, the control node, the hub (ygcyr): composes
- a machine (yvbpsm): composes
a merge would rebuild 2 module(s) in 1 tier(s): gitea, mesh-delivery
--- its merge-check.sh (go toolchain)
ok git.novox.be/novox/mesh-catalog/checks/words 0.002s
words: 12 retired words, none in the 28287 strings of 524 files
long-running resources without health: 70, as kept
NOT TESTED HERE: modules/gitea is TypeScript; the gate judges its manifest
testing modules/mesh-delivery
ok mesh-delivery/cmd/mesh-delivery 1.124s
**Merge check** at `74f912e1`
- `mesh/merge-gate`: **PASS** — every machine composes with the change as it did without (4 of 4 compose) (modules: gitea, mesh-delivery)
- `mesh/repo-check`: **PASS** — its merge-check.sh passed
**Delivery plan** — builds gitea, mesh-delivery → novox; no bus step
- tier 0: gitea, mesh-delivery
- novox: receives gitea, mesh-delivery
- gitea provides npm-package-registry, git: its consumers are sent again after it
- gitea keeps data (ADR 0233): what it holds is backed up before it moves
Run by the build seat on shanks as `build-1791447133414166486` (`builds --log build-1791447133414166486`).
```
--- the gate: gitea, mesh-delivery
gitea: ok, keeps data (valuable); WARNING: server stay(s) up and say(s) not how it is ready — judged by liveness alone, refused from 2026-11-18 (ADR 0240 rule 8)
mesh-delivery: ok, 1 tool(s), invokes seat:mesh-controller.delivery-plan, seat:mesh-controller.delivery-order, seat:mesh-controller.delivery-check, seat:mesh-controller.deliver, seat:mesh-controller.delivery-stop, seat:mesh-controller.delivery-walks, gitea.gitea_note_append, gitea.gitea_delivery_view, gitea.gitea_commit_status, gitea.gitea_commit_statuses, keeps state deliveries, groups
long-running resources without health: 1
2 manifest(s) checked. Judged against the seats this binary carries; a claim on one of the mesh's own seats is judged fully at registration, and a seat declared by a module not given here reads as unknown. Identities judged on a 6-character machine name, against the bounds of the providers given here
judging 1 module(s) changed against 4 machine(s), as the snapshot of 2026-10-08T00:58:30Z says they run
composing every machine as the mesh is
the bus's user list leaves out 5 user(s) the mesh has minted no credential for: controller, node.f35, node.idt, node.ygcyr, node.yvbpsm. Each is a user that cannot connect until one is issued
the bus's user list leaves out 5 user(s) the mesh has minted no credential for: controller, node.f35, node.idt, node.ygcyr, node.yvbpsm. Each is a user that cannot connect until one is issued
composing every machine with the change
the bus's user list leaves out 5 user(s) the mesh has minted no credential for: controller, node.f35, node.idt, node.ygcyr, node.yvbpsm. Each is a user that cannot connect until one is issued
the bus's user list leaves out 5 user(s) the mesh has minted no credential for: controller, node.f35, node.idt, node.ygcyr, node.yvbpsm. Each is a user that cannot connect until one is issued
merge gate: PASS — every machine composes with the change as it did without (4 of 4 compose)
judged by controller development build against the facts of 2026-10-08T00:58:30Z
modules the change moves:
- gitea (changed)
machines:
- a machine (f35): composes
- holds mesh-dns-resolver (idt): composes
- holds git, holds mesh-artifact-store, holds mesh-broker, holds mesh-catalog, holds mesh-delivery, holds mesh-dns-resolver, holds mesh-store, holds mesh-vault, holds npm-package-registry, the control node, the hub (ygcyr): composes
- a machine (yvbpsm): composes
a merge would rebuild 2 module(s) in 1 tier(s): gitea, mesh-delivery
--- its merge-check.sh (go toolchain)
ok git.novox.be/novox/mesh-catalog/checks/words 0.002s
words: 12 retired words, none in the 28287 strings of 524 files
long-running resources without health: 70, as kept
NOT TESTED HERE: modules/gitea is TypeScript; the gate judges its manifest
testing modules/mesh-delivery
ok mesh-delivery/cmd/mesh-delivery 1.124s
```
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
hq issue 305.
mesh-delivery.recheckasked the controller'sdelivery-checkfor the same head the forge had already judged. The forge keeps the newest status of each context, and nobody resetmesh/merge-gate/mesh/repo-check: the forge's holder sets pending only when it announces a new head, and the controller's recheck path (PullUpdatedcalled directly) bypasses that announcement. So the old green stood and branch protection would merge on it while the fresh check ran (mesh-controller #112, 2026-10-07; #127/#116 later turned red).Rechecktries the transition on a copy, then asks the forge's holder to setmesh/merge-gate(always) andmesh/repo-check(when the head holds one: a verdict that says none would leave a pending one standing for ever) topending, "checking again: ", and only then moves the delivery and asks the check. A forge that cannot be told refuses the recheck whole: state unchanged, nothing asked on a stale verdict.gitea_commit_statustakespending, and only pending, on the merge check's contexts — no verdict by hand, so issue 293 holds.Tests:
recheck_test.go(TestARecheck*) fails on main, passes here — the replay R305 (novox/mesh-lab PR, proved). giteatest/delivery.test.tsfails on main, passes here.Rollout order: gitea before mesh-delivery — until the holder takes pending, every recheck is refused (safe, but refused).
A recheck asks of the head the forge already judged, and the forge keeps the newest status of each context on it. Nobody reset mesh/merge-gate or mesh/repo-check, so the old green stood and branch protection would merge on it while the fresh check ran; rechecked heads did turn red. mesh-delivery's recheck now asks the forge's holder to set the gate, and the repository check when the head holds one, to pending ("checking again: <why>") before it asks the controller; a forge that cannot be told refuses the recheck whole. The gitea holder takes pending, and only pending, on the merge check's statuses by hand: no verdict, so issue 293 still holds.Delivery
novox/mesh-catalog@74f912e1fb4b— delivered since 2026-10-08T08:38:08ZDelivery plan — builds gitea, mesh-delivery → novox; no bus step
Machines
Transitions
The commit's note under
refs/notes/mesh-plankeeps every transition:git log --notes=mesh-plan.Merge check at
74f912e1mesh/merge-gate: PASS — every machine composes with the change as it did without (4 of 4 compose) (modules: gitea, mesh-delivery)mesh/repo-check: PASS — its merge-check.sh passedDelivery plan — builds gitea, mesh-delivery → novox; no bus step
Run by the build seat on shanks as
build-1791447133414166486(builds --log build-1791447133414166486).