mesh/check failed: integration: mesh-vault/cmd/mesh-vault.Tes… | 1feda1f533b8 on 559939aa8ce1 | judged by the candidate's mesh-build-go at 87d30b709d68
A go.mod requirement of a forge module at v0.0.0-00010101000000-000000000000 names no commit; the fetch looked for the commit 000000000000 among the pull request heads and failed. It is now taken from the commit the ask names for the package, else from the head of its repository among the asked versions, else from the latest published version.
Claude-Session: https://claude.ai/code/session_01NcbgfFSnn24M3GcqttoU7i
mesh/delivery-group group feat/sdk1 rejected: composed together: the checker's verdict at the members' heads (6b0f5a2e9397): integration: meshbuildgo/cmd/mesh-…
mesh/check failed: integration: meshbuildgo/cmd/mesh-build-go… | 68e7a2ddbfb9 on ee75d4327ce5 | judged by the candidate's mesh-build-go at 773f299aed81
mesh/delivery-group group feat/sdk1 rejected: composed together: the checker's verdict at the members' heads (5c08034be629): integration: meshbuildgo/cmd/mesh-…
mesh/check failed: integration: meshbuildgo/cmd/mesh-build-go… | 640455999e66 on ee75d4327ce5 | judged by the candidate's mesh-build-go at 785ebb388d5a
ensureModfile copied go.mod word for word into pins/<dir>/, where `go mod verify` runs, so a replace to ./x or ../x pointed
nowhere (route-proxy's failure of 2026-11-02 13:53, met a second time with the release's sibling packages). Every relative
replace target is now made absolute under the tree the go.mod came from. mesh-build-node installs a module's own npm
packages in a scratch copy of package.json, so a file:, link: or portal: dependency on a relative path would fail the same
way; it is refused naming the package and its path, as a module without a lock is.
Quick fix: rewrite the one replace route-proxy had, in ensureModfile (minutes). Thorough fix: the kind, a go.mod or
package.json copied away from its tree, for every replace form (single, block, with a version, ./ and ../) in the one place
all copies go through (ensureModfile, which versions.go and the pins share), and the same kind in the other build module
that copies a manifest. Chosen: thorough, since it was met twice and hides a failure until the delivery (quick-or-thorough,
fix-a-bug-met-twice). Test: TestARelativeReplaceStillResolvesInTheTemporaryModfile runs real go mod verify in the pins directory.
Claude-Session: https://claude.ai/code/session_01NcbgfJ9Gum47zkFKWRaovL
The test copies the node-engine's repository from beside the check (MESH_CHECK_BESIDE, mesh-host, with mesh-sdk's Go module
beside it as one workspace when a group places it), has the module build github.com/novox/mesh-host/cmd/mesh-compose there,
and runs it; it fails loudly when the repository is not beside.
Claude-Session: https://claude.ai/code/session_01NcbgfJ9Gum47zkFKWRaovL
The module already builds whatever repository, directory and package the ask names; the tests now say so for the node-engine's
repository (a Go module at its root, the command mesh-compose) instead of mesh-sdk's composer, which leaves mesh-sdk, and the
real-bus test builds a stand-in command in its fetched tree. The README tells the runner's new home and what a build says at
its end.
Claude-Session: https://claude.ai/code/session_01NcbgfJ9Gum47zkFKWRaovL
The digest counted a module outside the tree by its version and checksum, so every mesh-sdk merge invalidated each kept
verdict of each repository. A package of the mesh's forge is now hashed by the files the tests reach, as a replacement to a
directory already was; any other outside module still counts by version and checksum. Every kept verdict is invalidated
once, by the form change.
Claude-Session: https://claude.ai/code/session_01NcbgfJ9Gum47zkFKWRaovL
ModuleTrees answers each module directory's git tree, its manifest and lock digests, and the git objects of the paths its
artifacts name; it no longer computes delivery.NamedTree or reads the mesh packages out of go.sum.
Claude-Session: https://claude.ai/code/session_01NcbgfJ9Gum47zkFKWRaovL
A build ask whose job built an artifact asks the new step build_go_imports once: `go list -deps` of each Go bundle's program,
no tests, the forge's packages outside the module's own directory (a sibling package of the same repository counts), sorted
and each once. The answer carries them as BuildAnswer.Imports. The step is also a tool, to read them by hand.
Claude-Session: https://claude.ai/code/session_01NcbgfJ9Gum47zkFKWRaovL
The runner, the toolchain guard, the fetch, the parsers, buildcpu, the conformance kit and mesh-pack move from mesh-sdk's
buildstep into modules/mesh-build-go/buildstep (own go.mod). mesh-build-go, mesh-build-node and mesh-build-image require it
by a same-repository replace; what the delivery parts read (the failure contract, the fetch request, the stale sweep, the
module tree shape, NewID, CapacitySetting) stays imported from mesh-sdk as sdkstep.
Claude-Session: https://claude.ai/code/session_01NcbgfJ9Gum47zkFKWRaovL
mesh/check checking fa6dc3a48b0c on 32c4c52261c4 | novox/mesh-catalog#594 in group feat/1126-removal
When the forge's listing of pull request heads fails, the fetch now says it
as a download failure that may be retaken, so a forge outage is asked again
and not held as a refusal (issue 1748, issue 1126 review 3).
Claude-Session: https://claude.ai/code/session_01NcbgfJ9Gum47zkFKWRaovL
The group's check has no name lookup, so go failed on the network before it
could say it knew no such revision, and the fetch, reading go's words, took
the asked head for a download failure. Whether a commit is a pull request's
head is now the forge's fact, asked whenever go cannot fetch it; go's words
only label a commit on no head (issue 1748, issue 1126 review 2).
Claude-Session: https://claude.ai/code/session_01NcbgfJ9Gum47zkFKWRaovL
mesh/delivery-group group feat/1126-removal rejected: composed together: the checker's verdict at the members' heads (a523066f1791): integration: meshbuildgo/c…
mesh/check failed: integration: meshbuildgo/cmd/mesh-build-go… | 7f8701637f9d on 32c4c52261c4 | judged by the candidate's mesh-build-go at b82f7f676986
A test that slept a fixed time and then asserted what a goroutine, process or
watcher did failed under the checker's load. Each now waits for its positive
evidence (a started baseline, a call counted, a state reached) within 30 s, and
the concurrency-limit tests meet at a barrier instead of overlapping by sleep.
Claude-Session: https://claude.ai/code/session_01NcbgfJ9Gum47zkFKWRaovL
mesh/delivery-group group feat/judge-once rejected: composed together: the checker's verdict at the members' heads (5c42ba1fb5f3): integration: artifactstoreto…
mesh/check failed: integration: artifactstoretools/cmd/artifa… | 3e08301b27ea on 4b16c193f0fb | judged by the candidate's mesh-build-go at 8dd51540f73a
ADR 0573 §2 and §4 have a build take the latest published version of
each mesh package, or a group's own head, whatever go.mod names (issue
1585, S15). The fetch writes each asked version into the directory's
temporary modfile before downloading: a trunk commit is required at its
Go version with its checksums for go mod verify, a pull request's head
is placed as a pin on a head is, a newer go.mod version is kept and
said, and the answer and the log name each.
Claude-Session: https://claude.ai/code/session_01NcbgfJ9Gum47zkFKWRaovL
The build module checks every manifest with the mesh-sdk compiled into it. At a37181261c24 that copy did not know
the removal ASSIGNMENTS, so nats's manifest was refused at 11:45 and 11:48 and the catalogue's members of the group
(the vault, the provisioner and the rest) never built. A hand pin, allowed for this group one last time; issue 1585
makes every dependent follow a published mesh-sdk.
mesh-provisioner, mesh-config, mesh-issues and mesh-healers need KeptState.Follow; mesh-build-go, -image and -node the
retry of a state write the bus delivered to no one; claude-code asks.Condition; mesh-vault the credential forms list.
Each passes go vet, go vet -tags integration and go test on this pin, built with no go.work.
The test built its module with no settings file and no Capacity; the new
buildstep.NodeCapacity answers 0 for that (no default names a node), so the
puller took no ask and the test timed out after 90 s in check 205f634c30df.
Failed first locally at origin/main af89893d (90.1 s), passes with the slot (2.5 s).
The levels a build module judges hand the tests MESH_BUILD_NODE=1; the tests that run a step in bubblewrap fail on it when bwrap is missing. Issue 1309
jschoubben
mesh-tools