jschoubben
fb62b14512
The program puts the validation's run ask on node-build-go's check queue under its own asker and hears its end on step-ended; the manifest invokes seat:node-build-go.accept.check. The revision validated is the branch its merges landed on (the merged message's base, else the trunk), never the pull request's branch. take-in.pending may name a refusal or why the revision could not validate instead of the build it waits for. The whole case runs a stand-in build seat: an accepted revision is taken in as before, by one ask whose job names the indexer entry's repository, path and the revision's head and no heads; a merge whose changed manifest gains a problem stays pending, refused naming it. Builds: design 47 G §712, §713, §714, A-231, A-232, A-247, A-254 Claude-Session: https://claude.ai/code/session_01NcbgfGKaxw984XyAPfLm4h
mesh-delivery
Novox Mesh — delivery: the parts that build, check and deliver a change by watching and writing keys on the bus (ADR 0429).
Made by the mesh from the gitea module's config value repositories (novox/hq ADR 0428). Main takes no push: a change reaches it by a pull request whose mesh/repo-check (this repository's merge-check.sh) and mesh/merge-gate passed.