Every module that imports mesh-sdk requires its group head; each requires the mesh-contracts seats and clients it
imports, and mesh-contracts/go through the SDK's seat list. The placeholder versions are gone.
Claude-Session: https://claude.ai/code/session_01JG73KJNrH5EgFXMKKYSrig
mesh-sdk holds neither asks nor asker, nor the vault's answer types, and mesh-delivery's
sdk/views is mesh-sdk's go/views (a1-progress.md, the rewrite map for the join): thirteen
modules switch to the operatorchannel contract and client, mesh-sdk's channel package and
meshvault, with go.mod requiring each at the group pin (nats: meshbroker too). The gate
holds the checks mesh-sdk dropped (an ask's id is its key's asking, at least one option),
with a row that fails without them; claude-code refuses a router record whose times do
not parse, as its JSON decode did, with a row.
Claude-Session: https://claude.ai/code/session_01JG73KJNrH5EgFXMKKYSrig
The running indexer holds refusals from 21:14 for the exact bytes of these manifests, which carry core-credentials again. A new digest is read afresh; the thorough fix of stale verdicts is in the indexer in this group (issue 774).
Claude-Session: https://claude.ai/code/session_01JG73KG7AfSdh6FP8VrBqCn
mesh/delivery-group group feat/l3-final rejected: composed together: the checker's verdict at the members' heads (278aa5f0ccbe): unit: mesh-provisioner-client/…
mesh/check failed (2): unit: mesh-provisioner-client/cmd/mesh-provisioner-client.TestNatsANodeComingBackFil…; and 1 more | 093967af9b2f on be24f5ac387f
mesh/check being carried to f2eb54820469 on be24f5ac387f | from e6de42630355, mesh-delivery 4154c3040cee, mesh-tools 01ee2ef39488
The running indexer's judge refuses the word, a refused manifest holds the bus's user list, and so the indexer build
that knows the word is never granted. The node-engine on main still finds these modules by its name list, and the
vault keeps no list, so no credential is lost; the word comes back once the new judge runs (issue 774).
Claude-Session: https://claude.ai/code/session_01JG73KG7AfSdh6FP8VrBqCn
A provider whose build does not offer the provision it was asked for must
not be counted as having delivered it; the provisioner reads the build's
manifest (the builds read serves only this offer check and makes no plan,
ADR 0593 section 8) before it takes the provider's have as the outcome.
mesh/check failed (60): integration: mesh-knowledge/cmd/mesh-knowledge.TestARecordThatNeedsTheOperatorIsAc…; and 59 more | 7c78fd2e0c4f on f469eb387a30
A pass runs on every change of its node, and a newly placed module stays
unpublished for the minutes its build takes, so counting passes made every
new placement unhealthy while nothing was wrong. The health now says a hold
only once a module has stayed unpublished at one build for longer than 45
minutes (the build step's bound is 30), with since when; a published module
or another build starts the clock again.
Claude-Session: https://claude.ai/code/session_01NcbgfJ9Gum47zkFKWRaovL
A node-wide hold while any module's composition was unpublished meant one
placed module whose newest build never completes blocked every retirement on
its node for good, said only as a line of the pass. The incomplete first read
is already covered by the load gate, and an unpublished module's own plan and
keys are already kept as held. So the node-wide hold goes; a removed consumer
retires beside an unpublished module, and a module held unpublished for more
than two passes in a row is said on provisioner_health with its build.
Claude-Session: https://claude.ai/code/session_01NcbgfJ9Gum47zkFKWRaovL
At 2026-11-02 22:55:58 the provisioner's first pass after a new membership read
part of the picture, took the modules missing from it as handing nothing, set
21 route keys of running web apps retiring and asked the operator to remove
them; 3 s later the next pass put every plan back. Only 3 asks reached the
router; the other 18 were refused yet counted asked. Third of its kind (937,
1332), so the kind is fixed, not the instance.
Quick fix: wait for the watched reads' first load before any pass.
Thorough fix, chosen because the kind recurred three times and its obvious
answer would cut running apps off their routes:
- no pass judges before placement, wants, haves, the indexer's modules and the
published compositions have loaded once; a read error fails the pass
instead of reading as empty;
- while a module's composition is not published at its build, no key on that
node turns retiring and no plan is removed; a placed module with no known
build is held, not counted as handing nothing;
- a key whose consumer still has a want or a have on the node and no plan read
in this pass is left as it is;
- a pass that would retire most of a node's consumers at once (more than 3, or
more than half and at least 2) retires and asks nothing and says it as a
fault through provisioner_health (runtime-health, so a condition names the
likely cause); provisioner_compose retire-many is the operator's word that
such a removal is meant;
- at most 3 asks stand open (the router's bound per asker); the rest wait and
are raised as one ends, and an ask the router holds no record of a minute on
is raised again.
Claude-Session: https://claude.ai/code/session_01NcbgfJ9Gum47zkFKWRaovL
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
The node-engine alone composes (ADR 0593 §6, §8), so the provisioner stops
composing with frombus and fromruntime and reads each module's plan from
composed-<node> (read as mesh-host.composed): at its want, or the build its
have runs, and at the indexer's newest build, so a key ahead of its want
still carries its plan entry. A refused or not yet published composition
holds the module with its last plan kept. The golden test proves the plans
and provisions are today's, captured from the composing holder before the
change. It no longer reads the builds or the resolved values.
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 reader on an older mesh-sdk refuses a provision field it does not know,
so a key a plan names carries no entry: such readers skip only a key ahead
of its consumer's want, which they could never bind (issue 1126 review 1).
Claude-Session: https://claude.ai/code/session_01NcbgfJ9Gum47zkFKWRaovL
mesh-provisioner keys provisions from a consumer's wanted and newest builds
but writes the wanted build's plan alone, so a requirement the newest build
adds was never bound. Each key now carries its plan entry, and a key ahead of
its want says in its why that no plan names it yet and its provider binds it
from the entry (issue 1126 review 1).
Claude-Session: https://claude.ai/code/session_01NcbgfJ9Gum47zkFKWRaovL
The delivery group feat/node-packages pins one mesh-sdk head in every member: pacman reads EnginePackagesRead from it, and mesh-provisioner composes a node once with it.
Claude-Session: https://claude.ai/code/session_01NcbgfJ9Gum47zkFKWRaovL
provisioner_compose took 2.6-13.6 s per node with nothing changed, CPU
bound. The node is now composed at its wanted and its newest builds over
one read (frombus.PlansHeldTwice, whose composer resolves each machine
once), its own plans, provisions and refusals and the providers' entries
are read from the watched copy, its own writes taken in at once, and a
provider's manifest once by digest: no read by key per composition is
left. The result says where the time went, phase by phase, and a slow
composition that changed nothing says it in the log.
BenchmarkComposeNode times it over a mesh captured with the read tools
(MESH_COMPOSE_CAPTURE): novox 11.7 s to 0.49 s, ace 0.49 s, g14 and
shanks 0.39 s; plans and provisions identical to before over nine
compositions of the four nodes.
Needs mesh-sdk feat/compose-once (5d26c65); go.mod still pins the old
mesh-sdk until the group pins its head.
Claude-Session: https://claude.ai/code/session_01NcbgfJ9Gum47zkFKWRaovL
mesh/delivery-group group feat/l5-l7-main rejected: composed together: the checker's verdict at the members' heads (c598e176f3b2): unit: modules/gitea.the chec…
mesh/check failed: unit: modules/gitea.the checker's owed is what this module reads, and it consumes no check.status: "Cannot read properties of undef…
ADR 0580 clause 2 as revised: the holder hears haves by watch as it hears resolved values, so a have's change recomposes
its node from the copy it already holds.
Claude-Session: https://claude.ai/code/session_01NcbgfJ9Gum47zkFKWRaovL
Composing one node read every placement, have, module and resolved key one at a time and took past 30 s with the bus
local (ADR 0580 clause 2): the holder now reads them from mesh-sdk's watched copy, its watch handlers queue the nodes a
change touches after the copy took it, and a resolved value's change recomposes its node. mesh-sdk pinned at ba8b8f2.
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
mesh/check failed: integration: mesh-vault/cmd/mesh-vault.TestTheVaultWholeMintsOnTheBusWhoeverHoldsTheLease: never: the account minted under the cont…
mesh/check failed: shanks: the check of novox/mesh-controller#487 failed: go mod download in modules/route-proxy: go: git.novox.be/novox/mesh-controll…
jschoubben