Grants compose each membership from the build that runs as well as the trunk's, so a running build keeps its reads (issue 1966, recovery) #178

Merged

mesh-tools merged 3 commits from fix/1966-membership-keeps-running-reads into main

2026-11-08 16:03:19 +00:00

Author	SHA1	Message	Date
jschoubben	5452fa92a7	Grants keep the last published membership when the running build cannot be read; holders stay as merged (issue 1966, review round 2) mesh/delivery merged: source.main moved to novox/mesh-delivery@f9cadbfdbb93 Details mesh/check failed (2): integration: mesh-delivery-assigner/cmd/mesh-delivery-assigner.TestAProposalIsAnswer…; and 1 more \| 5452fa92a731 on f9cadbfdbb93 Claude-Session: https://claude.ai/code/session_01NcbgfFfQ4Z9UE5jK32PmE5	2026-11-08 17:02:17 +01:00
jschoubben	563a624a6d	Grants read the have's build for memberships and holdings, and a failed read of it holds the pass back (issue 1966, review round 1) Claude-Session: https://claude.ai/code/session_01NcbgfFfQ4Z9UE5jK32PmE5	2026-11-08 17:00:15 +01:00
jschoubben	77862abb12	Grants compose a membership from the build each machine runs, the want's and the trunk's, so none loses a read (issue 1966) A running build older than the trunk lost reads it still uses (the vault's read of the assigner's placement), failing every node-engine pass. Memberships now come from the union of the have's build, the want's and the trunk's manifest. Claude-Session: https://claude.ai/code/session_01NcbgfFfQ4Z9UE5jK32PmE5	2026-11-08 16:57:13 +01:00