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
jschoubben
fb62b14512