A catalogue check parses every manifest as the nodes do; mesh-provisioner holds a refused manifest alone (issue 774) #567

Merged

jschoubben merged 2 commits from fix/one-bad-item-holds-one-module into main 2026-10-30 18:31:02 +00:00

Conversation 1 Commits 2 Files Changed 7

+126 -3

2 Commits

Author	SHA1	Message	Date
jschoubben	b4b22aac20	Pin mesh-provisioner to mesh-sdk 754edfae, so a manifest the mesh refuses holds that module alone in its plans (issue 774) ... PlansHeld reads the same frombus input that refused every node on 2026-10-30 at 19:13; at 754edfae it holds the module whose manifest the mesh refuses, with why, and composes every other module's plan. Quick and thorough fix are the SDK's (one rule in frombus input); this is the pin.	2026-10-30 19:27:56 +01:00
jschoubben	faaa6d3df2	Judge every manifest as the nodes read it in the catalogue's own check, so a manifest they refuse never reaches main (issue 774) ... ca8d6f33 gave power's bar item attributes its bar places by none of; ParseManifest refuses that, and at 19:13 on 2026-10-30 every node-engine refused to compose. No check of #565 parsed the manifest: that judgement was mesh-controller's `module check`, run over every manifest by the old merge gate, and since the checker moved to mesh-delivery it runs this repository's Go tests and the composition, where no test parsed a manifest whole. Quick fix: a row refusing node-bar block attributes other than bar, place and order. Thorough fix: checks/manifests parses every modules/*/module.json with mesh-sdk's ParseManifestWith against predefined.json and its templates beside it, then CatalogueProblems, IdentityProblems and DataProblems over the shelf, the functions the nodes and registration use. Chose thorough: it refuses every kind of manifest the nodes refuse, not this attribute alone. It fails at 7e905a66 naming power's item 2 and passes at 0695ae25.	2026-10-30 19:27:03 +01:00