The windows' logic was built but nothing woke it, so both windows stayed open for ever. The program now reads every
node through node_haves and the node-engine seat's manifest-reads at its start, on each delivered and on each
manifest-reads-changed, steps both windows, says their closing once on distribution.events and raises the seven-day
finding. A build module's have counts as publishing through the seats when it runs a build heard publishing (the
tools bundle records the fingerprint of each publish's proved caller), so a paused build agent running the same
build holds nothing open.
Claude-Session: https://claude.ai/code/session_01JG73KJNrH5EgFXMKKYSrig
Until now mirror only answered a copy the store already held, so mesh-build-image had nothing to call for an upstream
base (design 51: an upstream image is copied by mirror with its pinned digest). The copy takes an anonymous pull
token, checks every manifest's and blob's bytes against its digest, copies an index's every platform first, and
fetches only the blobs the store lacks. tags was already served.
Claude-Session: https://claude.ai/code/session_01JG73KJNrH5EgFXMKKYSrig
The tools bundle runs in the tool runner's account and cannot remove a file in
distribution's 0700 state directory, so its first answered publish closes the
window bootstrap-push in the state windows and the program removes the file
(design 51 On a fresh mesh).
Claude-Session: https://claude.ai/code/session_01JG73KJNrH5EgFXMKKYSrig
With go-package-registry bound, the fetch's GOPROXY is the Go seat, then proxy.golang.org, then direct (kept for
this milestone, E11: removed by the first change after mesh-sdk's and mesh-contracts' first numbered versions
are in the Go seat); no GOPRIVATE, and the checksum database off for the forge's paths (design 51 *Go packages*,
ADR 0605 §6). The module requires and binds go-package-registry, so its new build waits for the forge's build
that offers it (E2). Unbound, the fetch is as before.
Claude-Session: https://claude.ai/code/session_01JG73KJNrH5EgFXMKKYSrig
go-package-registry, mesh scope, read with no credential, is offered only by the forge module's new build, so
mesh-build-go's fetch from the Go seat waits for it (design 51, E2); its read side is the forge's Go proxy. The
npm registry's public-root stays served (ADR 0346 §6, the operator 2026-11-04). Both rows of the forge's
manifest test.
Claude-Session: https://claude.ai/code/session_01JG73KJNrH5EgFXMKKYSrig
The program serves the store's port 5000 in front of the registry container, now on the node's loopback
(127.0.0.1:5001), listed before the program so the port is free when it starts (E14). The tools bundle serves
each seat's verbs as <seat>.<verb> and registry_incoming, registry_holds, registry_old_name and
registry_direct_writes, on distribution's own account, with the caller the tool runner proved. The manifest
claims container-image-registry and oci-artifact-registry with their verbs, keeps mesh-artifact-store and
provides artifact-store until the old name closes (E15), asks its bus state in requires (incoming, transfers,
holds, windows, findings, events) and declares its health outside the program. The bootstrap's one-off
credential is discarded at the first publish answered.
Not yet: the runtime's object store helper for incoming (mesh-sdk), the windows' driver on delivered and
manifest-reads-changed, the read-side health probe calling versions per seat.
Claude-Session: https://claude.ai/code/session_01JG73KJNrH5EgFXMKKYSrig
The holder answers publish and publish-part into incoming (parts of at most 1 MiB, resumed from what is held,
hashed, only the missing layers sent, 20 GiB with its 80 % finding and a refusal at the cap, a transfer idle 24
hours dropped), asks builder_versions before it stores, and says published or refused (design 51 *Publishing*,
ADR 0605 §4, ADR 0611). versions, remove (a tagged version; untagged only for the sweep's retention, which a
hold keeps), hold and release (ADR 0617 §2: the sweep alone; the operator's session by hand; never
distribution's own account), tags and mirror. The caller list is a trusted config value checked against the
caller the tool runner proved. The store's port is the program's: reads open, writes refused but while the
direct-write window is open (never over a tag published through the seat) or with the bootstrap's one-off
credential. The old-name and direct-write windows read every node, away ones included, close once, and name a
node holding them seven days.
Claude-Session: https://claude.ai/code/session_01JG73KJNrH5EgFXMKKYSrig
mesh/check being carried to 237a534ca4d3 on 7a7db0166ad2 | from dd458cb155f5, mesh-host 4d47ff5ce743
The vault leaves a handed module's own secrets out of `own`, judged by the plan in its assignment, and nothing read
that judgement: on 2026-11-04 the circle on ace (no plan, so not handed, so refused, so no plan) could be told only by
reading the provisioner's plans beside the node-engine's refusals. own_handed answers, per module the vault keeps an
own secret of on the machine or that is placed there, handed or not and why.
Claude-Session: https://claude.ai/code/session_01JG73KJNrH5EgFXMKKYSrig
mesh/check checking 6c09be4a703e on dd458cb155f5 | novox/mesh-catalog#605 in group feat/l3-final
The test of a node coming back stops the client before the report of zsh is kept; the cancelled Put left s.applied without zsh, so leftModules never removed it (2 of 20 runs failed under -race, also at origin/main). Thorough: report() keeps under context.WithoutCancel with a 5 s bound; the same test now passes 40 of 40.
Claude-Session: https://claude.ai/code/session_01JG73KG7AfSdh6FP8VrBqCn
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
jschoubben
mesh-tools