Add the replay of issue 340: a verb set what every agent session obeys (hq issue 340) #288

Merged

mesh-admin merged 2 commits from fix/340-replay into main 2026-10-13 01:04:46 +00:00

Conversation 1 Commits 2 Files Changed 2

+77

mesh-admin commented 2026-10-13 00:41:41 +00:00

Contributor

Copy Link

Copy Source

What: one test file, cmd/mesh-controller/replay340_test.go (TestReplay340), written only with what the controller had before its fix (#172): aMesh, register, assign, throughVerb, atTheTerminal and the inventory's Layer, so mesh-lab's prover can lay it over the commit before.

It asserts that through a verb:

• a SessionStart hook in claude-code's managed_settings is refused, for one machine and for the mesh;
• a tool server set through the command verb is refused;
• a url for an identity provider whose mergeable runtime configuration starts empty is refused;
• each layer is left as it was;
• at the terminal the operator's managed settings are taken, and a verb cannot clear them.

Why: issue 340 is a core issue and resolves with a replay in mesh-lab's register. The fix's own tests read what the fix added.

Tested (with MESH_TEST_POSTGRES): go test -run '^TestReplay340$' ./cmd/mesh-controller passes on main. It fails on 4d60628^1 and passes on 4d60628. sh merge-check.sh passes. mesh-lab go run ./cmd/prove R340 says PROVED; before the fix it fails with replay340_test.go:51: a SessionStart hook in the agent's managed settings for one machine through a verb was taken … <nil>. Registered in novox/mesh-lab on the same branch name.

Tests only; no behaviour changes. Replay for issue 340.

What: one test file, `cmd/mesh-controller/replay340_test.go` (`TestReplay340`), written only with what the controller had before its fix (#172): `aMesh`, `register`, `assign`, `throughVerb`, `atTheTerminal` and the inventory's `Layer`, so mesh-lab's prover can lay it over the commit before. It asserts that through a verb: - a SessionStart hook in claude-code's `managed_settings` is refused, for one machine and for the mesh; - a tool server set through the `command` verb is refused; - a `url` for an identity provider whose mergeable runtime configuration starts empty is refused; - each layer is left as it was; - at the terminal the operator's managed settings are taken, and a verb cannot clear them. Why: issue 340 is a core issue and resolves with a replay in mesh-lab's register. The fix's own tests read what the fix added. Tested (with MESH_TEST_POSTGRES): `go test -run '^TestReplay340$' ./cmd/mesh-controller` passes on main. It fails on 4d60628^1 and passes on 4d60628. `sh merge-check.sh` passes. mesh-lab `go run ./cmd/prove R340` says PROVED; before the fix it fails with `replay340_test.go:51: a SessionStart hook in the agent's managed settings for one machine through a verb was taken … <nil>`. Registered in novox/mesh-lab on the same branch name. Tests only; no behaviour changes. Replay for issue 340.

mesh-admin commented 2026-10-13 00:41:58 +00:00

Author

Contributor

Copy Link

Copy Source

Delivery novox/mesh-controller@e44c726a3812 — delivered since 2026-10-13T01:04:57Z

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

Group fix/340-replay, in order: novox/mesh-controller@e44c726a38 → novox/mesh-lab@ea24e7890f

Transitions

• 2026-10-13 00:58 (new) → proposed (announced): novox/mesh-controller#288's head announced
• 2026-10-13 01:04 proposed → checked (checked): a verdict names this commit and the trunk's head as its trunk commit
• 2026-10-13 01:04 checked → ready (accepted): the gate passed or warned, and the repository's own check did not fail
• 2026-10-13 01:04 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 01:04 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-delivery:view --> **Delivery** `novox/mesh-controller@e44c726a3812` — **delivered** since 2026-10-13T01:04:57Z **Delivery plan** — builds nothing: the change touches no module of the mesh's graph **Group** `fix/340-replay`, in order: novox/mesh-controller@e44c726a3812 → novox/mesh-lab@ea24e7890f57 **Transitions** - 2026-10-13 00:58 (new) → proposed (announced): novox/mesh-controller#288's head announced - 2026-10-13 01:04 proposed → checked (checked): a verdict names this commit and the trunk's head as its trunk commit - 2026-10-13 01:04 checked → ready (accepted): the gate passed or warned, and the repository's own check did not fail - 2026-10-13 01:04 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 01:04 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:52:02 +00:00

mesh-admin left a comment

Author

Contributor

Copy Link

Copy Source

Verdict: approve at 6f34f8efea

Independent review. I read the replay in a fresh clone and ran it against a throwaway postgres 17 (MESH_TEST_POSTGRES set; I removed the container afterwards), so none of the runs below skipped.

No blocking findings.

1. It uses only helpers from before #172. aMesh and register (mesh_for_test.go), assign (acts.go), throughVerb and atTheTerminal (terminal_settings_test.go) and Inventory.Layer (internal/inventory/unseen.go) all exist at 4d60628^1 (b13a0f7). #172 added only two tests to terminal_settings_test.go and no helpers.
2. With the database, the replay file laid over each commit fails on 4d60628^1 and passes on 4d60628, on main eb7ee92 and at this head. Before the fix, the verb took the SessionStart hook for one machine and for the mesh, and the identity provider's url ("...through a verb was taken...: "). All three layers then held what the verb set, for example claude-code on laptop held the curl hook. The terminal step also failed, because the planted hook was in the layer. go run ./cmd/prove R340 in mesh-lab #94 gives PROVED.
3. The layer is unchanged after the refusals. After the four refused calls, it reads all three layers they touch (claude-code on laptop and mesh-wide, keycloak on anchor) and requires each to be empty. After the refused clear, it requires the operator's terminal-set layer to be byte-for-byte what it was. A write by any refused call would persist and fail one of these checks, so checking once after the group covers every refusal.
4. merge-check.sh passes at the head with MESH_TEST_POSTGRES set, including the store tests listed in testdata/store-tests.

Non-blocking:

1. The command verb case (settings set through the command verb) was already refused as the terminal's before #172. It passes on b13a0f7 as well, so it guards a regression but does not contribute to the replay failing before the fix.
2. TestReplay340 needs the store but is not listed in testdata/store-tests (issue 459). Without a store, the repo-check runs it as a skip. Listing it would make the repo-check fail when it did not run. replay318, 325 and 336 have the same gap. The lab's prove does catch a skip, because a skip before the fix reads as "passes", which is NOT PROVED.
3. HomeRef in mesh-lab #94 names this head. Merge with a merge commit (the default), not squash or rebase, or that ref becomes unreachable.

Gitea statuses at this head: mesh/merge-gate pending, "out of date: judged against trunk eb7ee921b5, the trunk is now 49102e1645c9; judged again on a recheck or when it is merged". mesh/repo-check pending, with the same text. mesh/delivery pending, "checking". mesh/delivery-group failure, "group fix/340-replay rejected: a member's own check failed", because its member mesh-lab #94 does not merge into its trunk. It needs a recheck after #94 is rebased, and both required checks green, before it merges.

Verdict: approve at 6f34f8efea28d28c5a68b823df0b0a5cd486905f Independent review. I read the replay in a fresh clone and ran it against a throwaway postgres 17 (MESH_TEST_POSTGRES set; I removed the container afterwards), so none of the runs below skipped. No blocking findings. 1. It uses only helpers from before #172. aMesh and register (mesh_for_test.go), assign (acts.go), throughVerb and atTheTerminal (terminal_settings_test.go) and Inventory.Layer (internal/inventory/unseen.go) all exist at 4d60628^1 (b13a0f7). #172 added only two tests to terminal_settings_test.go and no helpers. 2. With the database, the replay file laid over each commit fails on 4d60628^1 and passes on 4d60628, on main eb7ee92 and at this head. Before the fix, the verb took the SessionStart hook for one machine and for the mesh, and the identity provider's url ("...through a verb was taken...: <nil>"). All three layers then held what the verb set, for example claude-code on laptop held the curl hook. The terminal step also failed, because the planted hook was in the layer. `go run ./cmd/prove R340` in mesh-lab #94 gives PROVED. 3. The layer is unchanged after the refusals. After the four refused calls, it reads all three layers they touch (claude-code on laptop and mesh-wide, keycloak on anchor) and requires each to be empty. After the refused clear, it requires the operator's terminal-set layer to be byte-for-byte what it was. A write by any refused call would persist and fail one of these checks, so checking once after the group covers every refusal. 4. merge-check.sh passes at the head with MESH_TEST_POSTGRES set, including the store tests listed in testdata/store-tests. Non-blocking: 1. The `command` verb case (`settings set` through the command verb) was already refused as the terminal's before #172. It passes on b13a0f7 as well, so it guards a regression but does not contribute to the replay failing before the fix. 2. TestReplay340 needs the store but is not listed in testdata/store-tests (issue 459). Without a store, the repo-check runs it as a skip. Listing it would make the repo-check fail when it did not run. replay318, 325 and 336 have the same gap. The lab's prove does catch a skip, because a skip before the fix reads as "passes", which is NOT PROVED. 3. HomeRef in mesh-lab #94 names this head. Merge with a merge commit (the default), not squash or rebase, or that ref becomes unreachable. Gitea statuses at this head: mesh/merge-gate pending, "out of date: judged against trunk eb7ee921b533, the trunk is now 49102e1645c9; judged again on a recheck or when it is merged". mesh/repo-check pending, with the same text. mesh/delivery pending, "checking". mesh/delivery-group failure, "group fix/340-replay rejected: a member's own check failed", because its member mesh-lab #94 does not merge into its trunk. It needs a recheck after #94 is rebased, and both required checks green, before it merges.

jschoubben added 2 commits 2026-10-13 00:57:38 +00:00

Add the replay of issue 340: a verb set what every agent session obeys (hq issue 340) ... 2a13917d6e

The settings verb took the agent module's managed settings and an empty
runtime configuration's url from any caller. The replay uses only what the
controller had before #172, so mesh-lab's prover can show it fails there.

List TestReplay340 among the store tests, so a check without a database cannot count its skip as a pass (hq issue 340, review 144) e44c726a38

jschoubben force-pushed fix/340-replay from 6f34f8efea to e44c726a38 2026-10-13 00:57:38 +00:00 Compare

mesh-admin reviewed 2026-10-13 01:03:20 +00:00

mesh-admin left a comment

Author

Contributor

Copy Link

Copy Source

Verdict: approve at e44c726a38

Independent re-review against the head I reviewed before, 6f34f8ef (review 144).

No blocking findings.

Range-diff: the first commit is unchanged (1: 6f34f8e = 1: 2a13917); it was only rebased onto main 49102e1. The second commit, e44c726, adds one line to testdata/store-tests, ./cmd/mesh-controller TestReplay340. That closes my earlier non-blocking finding: a check without a database now fails instead of counting the skip as a pass. Nothing else changed.

Against a throwaway postgres 17 (MESH_TEST_POSTGRES set, container removed afterwards), TestReplay340 passes at this head. In mesh-lab #94 at ea24e78, go run ./cmd/prove R340 says "R340 (issue 340): PROVED - before its fix fails, on its fix passes". The first failure before the fix is replay340_test.go:51 (the SessionStart hook taken through a verb: ).

As before: mesh-lab #94's HomeRef is now this head, so merge with a merge commit (the default), not squash or rebase.

Gitea statuses at this head when I posted: mesh/merge-gate pending, "building on g14 since 02:58". mesh/delivery pending, "checking". mesh/delivery-group pending, "group fix/340-replay checking: 0 of 2 member(s) ready". There is no mesh/repo-check status yet. Merge only after both required checks are green at this head.

Verdict: approve at e44c726a38125ade30a6d70cee9873a4e2ea6ac2 Independent re-review against the head I reviewed before, 6f34f8ef (review 144). No blocking findings. Range-diff: the first commit is unchanged (`1: 6f34f8e = 1: 2a13917`); it was only rebased onto main 49102e1. The second commit, e44c726, adds one line to testdata/store-tests, `./cmd/mesh-controller TestReplay340`. That closes my earlier non-blocking finding: a check without a database now fails instead of counting the skip as a pass. Nothing else changed. Against a throwaway postgres 17 (MESH_TEST_POSTGRES set, container removed afterwards), TestReplay340 passes at this head. In mesh-lab #94 at ea24e78, `go run ./cmd/prove R340` says "R340 (issue 340): PROVED - before its fix fails, on its fix passes". The first failure before the fix is replay340_test.go:51 (the SessionStart hook taken through a verb: <nil>). As before: mesh-lab #94's HomeRef is now this head, so merge with a merge commit (the default), not squash or rebase. Gitea statuses at this head when I posted: mesh/merge-gate pending, "building on g14 since 02:58". mesh/delivery pending, "checking". mesh/delivery-group pending, "group fix/340-replay checking: 0 of 2 member(s) ready". There is no mesh/repo-check status yet. Merge only after both required checks are green at this head.

mesh-admin merged commit 584ee99196 into main 2026-10-13 01:04:46 +00:00

mesh-admin deleted branch fix/340-replay 2026-10-13 01:04:46 +00:00

Sign in to join this conversation.

Reviewers

No Reviewers

mesh-admin

Labels

No items

No labels

Milestone

No items

No Milestone

Assignees

Clear assignees

jschoubben miel.truyen

No Assignees

2 Participants

Notifications

Subscribe

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: novox/mesh-controller#288