Register R340: a verb set what every agent session obeys (hq issue 340) #94

Merged
mesh-admin merged 1 commits from fix/340-replay into main 2026-10-13 01:07:07 +00:00
Contributor

What: one entry in replays/register.go.

  • R340 (issue 340). The fix is mesh-controller #172, merge 4d60628f37530c23c072011a697e6014de14b3f6. Before it, the settings verb took a SessionStart hook in the agent module's managed settings, a tool server of the caller's, and a url for an identity provider's empty runtime configuration, from any caller. The entry asserts that through a verb, any change to the layer of a module with a mergeable file not marked trusted: false is refused and leaves the layer as it was.

The replay's file lives in mesh-controller (Home), on branch fix/340-replay at 6f34f8efea28d28c5a68b823df0b0a5cd486905f. That pull request adds it, and HomeRef stays reachable once it merges. The replay needs a store: MESH_TEST_POSTGRES.

Tested: go run ./cmd/prove --repos <clones> R340 gives:

R340 (issue 340): PROVED — before its fix fails, on its fix passes
  before: replay340_test.go:51: a SessionStart hook in the agent's managed settings for one machine through a verb was taken, or not refused as the terminal's: <nil>

go vet ./... and TestEveryReplayIsWhole pass. Merge the mesh-controller pull request first.

Replay for issue 340.

What: one entry in replays/register.go. - R340 (issue 340). The fix is mesh-controller #172, merge 4d60628f37530c23c072011a697e6014de14b3f6. Before it, the settings verb took a SessionStart hook in the agent module's managed settings, a tool server of the caller's, and a `url` for an identity provider's empty runtime configuration, from any caller. The entry asserts that through a verb, any change to the layer of a module with a mergeable file not marked trusted: false is refused and leaves the layer as it was. The replay's file lives in mesh-controller (Home), on branch fix/340-replay at 6f34f8efea28d28c5a68b823df0b0a5cd486905f. That pull request adds it, and HomeRef stays reachable once it merges. The replay needs a store: MESH_TEST_POSTGRES. Tested: `go run ./cmd/prove --repos <clones> R340` gives: ``` R340 (issue 340): PROVED — before its fix fails, on its fix passes before: replay340_test.go:51: a SessionStart hook in the agent's managed settings for one machine through a verb was taken, or not refused as the terminal's: <nil> ``` `go vet ./...` and `TestEveryReplayIsWhole` pass. Merge the mesh-controller pull request first. Replay for issue 340.
Author
Contributor

Delivery novox/mesh-lab@ea24e7890f57 — delivered since 2026-10-13T01:07:28Z

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 01:01 (new) → proposed (announced): novox/mesh-lab#94'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:07 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:07 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-lab@ea24e7890f57` — **delivered** since 2026-10-13T01:07:28Z **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 01:01 (new) → proposed (announced): novox/mesh-lab#94'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:07 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:07 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`.
Author
Contributor

Merge check at 5c82e196
Judged: head 5c82e196155b merged into trunk b7f46559f053

  • mesh/merge-gate: FAIL — head 5c82e19615 does not merge cleanly into trunk b7f46559f0: in conflict replays/register.go
  • mesh/repo-check: FAIL — head 5c82e19615 does not merge cleanly into trunk b7f46559f0: in conflict replays/register.go

Run by the build seat on shanks as build-1791852115456121471 (builds --log build-1791852115456121471).

head 5c82e196155b does not merge cleanly into trunk b7f46559f053: in conflict replays/register.go
**Merge check** at `5c82e196` Judged: head `5c82e196155b` merged into trunk `b7f46559f053` - `mesh/merge-gate`: **FAIL** — head 5c82e196155b does not merge cleanly into trunk b7f46559f053: in conflict replays/register.go - `mesh/repo-check`: **FAIL** — head 5c82e196155b does not merge cleanly into trunk b7f46559f053: in conflict replays/register.go Run by the build seat on shanks as `build-1791852115456121471` (`builds --log build-1791852115456121471`). ``` head 5c82e196155b does not merge cleanly into trunk b7f46559f053: in conflict replays/register.go ```
mesh-admin left a comment
Author
Contributor

Verdict: request changes at 5c82e19615

Independent review. I read the diff in a fresh clone at the head, with mesh-controller cloned beside it (holding #288's head 6f34f8e), and ran the replay against a throwaway postgres 17. I removed the container afterwards.

Blocking:

  1. The head does not merge into the current trunk. mesh-lab main is now b7f4655, which added R166 (#92) at the end of Register. This branch is based on e5ccf48 and appends R340 at the same place, so replays/register.go conflicts. The gate says so too (see the statuses below). Please rebase onto main, keep R166 and put R340 after it, then ask for a recheck. #90 (R279 and R412, head 671d56a) is already based on b7f4655 and merges cleanly into main, but it appends at the same place. Whichever of #90 and #94 merges second will conflict again and needs the same rebase and recheck. I checked both orders: #94 after #90 conflicts, and #90 after #94 conflicts.

The entry itself is right. Once rebased, it is approvable:

  1. go run ./cmd/prove R340 with MESH_TEST_POSTGRES set prints "R340 (issue 340): PROVED - before its fix fails, on its fix passes". Before the fix, the first failure is "replay340_test.go:51: a SessionStart hook in the agent's managed settings for one machine through a verb was taken, or not refused as the terminal's: ".
  2. Fix 4d60628f37530c23c072011a697e6014de14b3f6 is the merge of mesh-controller #172, so Fix^1 (b13a0f7) is the commit before it. Package, Test and Files match #288's file.
  3. replays/merge-check.sh passes at the head (vet, compile, the register's own tests).

Non-blocking: HomeRef is #288's head 6f34f8e. It stays reachable only if #288 is merged with a merge commit (the repository's default), not squashed or rebased. Whoever merges #288 should keep that in mind, or update HomeRef here.

Gitea statuses at this head: mesh/merge-gate failure, "head 5c82e19615 merged into trunk b7f46559f0 - fail: head 5c82e19615 does not merge cleanly into trunk b7f46559f0: in conflict repl...". mesh/repo-check failure, with the same text. mesh/delivery failure, "rejected: the gate failed or could not run, or the repository's own check failed". mesh/delivery-group failure, "group fix/340-replay rejected: a member's own check failed".

Verdict: request changes at 5c82e196155b2d5b8439582b0335ce3329154ab6 Independent review. I read the diff in a fresh clone at the head, with mesh-controller cloned beside it (holding #288's head 6f34f8e), and ran the replay against a throwaway postgres 17. I removed the container afterwards. Blocking: 1. The head does not merge into the current trunk. mesh-lab main is now b7f4655, which added R166 (#92) at the end of Register. This branch is based on e5ccf48 and appends R340 at the same place, so replays/register.go conflicts. The gate says so too (see the statuses below). Please rebase onto main, keep R166 and put R340 after it, then ask for a recheck. #90 (R279 and R412, head 671d56a) is already based on b7f4655 and merges cleanly into main, but it appends at the same place. Whichever of #90 and #94 merges second will conflict again and needs the same rebase and recheck. I checked both orders: #94 after #90 conflicts, and #90 after #94 conflicts. The entry itself is right. Once rebased, it is approvable: 1. `go run ./cmd/prove R340` with MESH_TEST_POSTGRES set prints "R340 (issue 340): PROVED - before its fix fails, on its fix passes". Before the fix, the first failure is "replay340_test.go:51: a SessionStart hook in the agent's managed settings for one machine through a verb was taken, or not refused as the terminal's: <nil>". 2. Fix 4d60628f37530c23c072011a697e6014de14b3f6 is the merge of mesh-controller #172, so Fix^1 (b13a0f7) is the commit before it. Package, Test and Files match #288's file. 3. replays/merge-check.sh passes at the head (vet, compile, the register's own tests). Non-blocking: HomeRef is #288's head 6f34f8e. It stays reachable only if #288 is merged with a merge commit (the repository's default), not squashed or rebased. Whoever merges #288 should keep that in mind, or update HomeRef here. Gitea statuses at this head: mesh/merge-gate failure, "head 5c82e196155b merged into trunk b7f46559f053 - fail: head 5c82e196155b does not merge cleanly into trunk b7f46559f053: in conflict repl...". mesh/repo-check failure, with the same text. mesh/delivery failure, "rejected: the gate failed or could not run, or the repository's own check failed". mesh/delivery-group failure, "group fix/340-replay rejected: a member's own check failed".
jschoubben added 1 commit 2026-10-13 01:00:46 +00:00
Register R340: a verb set what every agent session obeys (hq issue 340)
mesh/merge-gate head ea24e7890f57 merged into trunk 51fa3a73ab3d — pass: the change touches no module of the mesh's graph
mesh/repo-check head ea24e7890f57 merged into trunk 51fa3a73ab3d — pass: its merge-check.sh passed, each part in its toolchain: merge-check.sh (typescript)…
mesh/delivery delivered
mesh/delivery-group group fix/340-replay delivered: every member is delivered
ea24e7890f
Issue 340 is a core issue and resolves with a replay; the test lives in
mesh-controller and is proved against the commit before #172.
jschoubben force-pushed fix/340-replay from 5c82e19615 to ea24e7890f 2026-10-13 01:00:46 +00:00 Compare
mesh-admin left a comment
Author
Contributor

Verdict: approve at ea24e7890f

Independent re-review against the head I reviewed before, 5c82e196 (review 143). The blocking finding there, a conflict with main, is resolved.

No blocking findings.

Range-diff: the one commit is unchanged apart from two things. Its context is now the end of Register on main 51fa3a7, so R340 follows R412, after R166 and R279. And HomeRef moves from 6f34f8ef to e44c726a38125ade30a6d70cee9873a4e2ea6ac2, the new head of mesh-controller #288, which holds replay340_test.go. The head is a descendant of main 51fa3a7, and against main it adds only the 16 lines of the R340 entry. R166, R279 and R412 are all still in the register.

Against a throwaway postgres 17 (MESH_TEST_POSTGRES set, container removed afterwards), go run ./cmd/prove R340 at this head 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: ). replays/merge-check.sh passes at this head.

Non-blocking, as before: HomeRef stays reachable only if #288 is merged with a merge commit.

Gitea statuses at this head when I posted: mesh/merge-gate pending, "building on ace since 03:01". 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 ea24e7890f5787ebe479bee45d8fc901306a982f Independent re-review against the head I reviewed before, 5c82e196 (review 143). The blocking finding there, a conflict with main, is resolved. No blocking findings. Range-diff: the one commit is unchanged apart from two things. Its context is now the end of Register on main 51fa3a7, so R340 follows R412, after R166 and R279. And HomeRef moves from 6f34f8ef to e44c726a38125ade30a6d70cee9873a4e2ea6ac2, the new head of mesh-controller #288, which holds replay340_test.go. The head is a descendant of main 51fa3a7, and against main it adds only the 16 lines of the R340 entry. R166, R279 and R412 are all still in the register. Against a throwaway postgres 17 (MESH_TEST_POSTGRES set, container removed afterwards), `go run ./cmd/prove R340` at this head 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>). replays/merge-check.sh passes at this head. Non-blocking, as before: HomeRef stays reachable only if #288 is merged with a merge commit. Gitea statuses at this head when I posted: mesh/merge-gate pending, "building on ace since 03:01". 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 6ba65a12f2 into main 2026-10-13 01:07:07 +00:00
mesh-admin deleted branch fix/340-replay 2026-10-13 01:07:08 +00:00
Sign in to join this conversation.
No Reviewers
No labels
2 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: novox/mesh-lab#94