3 Commits

Include renames

Author	SHA1	Message	Date
jochen	74f912e1fb	Put the merge check back to pending before a recheck asks it (hq issue 305) ... A recheck asks of the head the forge already judged, and the forge keeps the newest status of each context on it. Nobody reset mesh/merge-gate or mesh/repo-check, so the old green stood and branch protection would merge on it while the fresh check ran; rechecked heads did turn red. mesh-delivery's recheck now asks the forge's holder to set the gate, and the repository check when the head holds one, to pending ("checking again: <why>") before it asks the controller; a forge that cannot be told refuses the recheck whole. The gitea holder takes pending, and only pending, on the merge check's statuses by hand: no verdict, so issue 293 still holds.	2026-10-08 10:11:26 +02:00
jochen	33857626be	Never set warning on the merge check's statuses: the forge blocks a required one ... Branch protection requires mesh/merge-gate (and mesh/repo-check on the core repositories) with no admin override, and the forge combines warning as a failure. A note is now a success that says it; a repository without a merge-check.sh is a success where repo-check is not required and a failure for a person where it is; the status tool refuses the merge check's contexts.	2026-10-07 13:55:34 +02:00
jochen	b6f0bc309b	Add mesh-delivery, the owner of deliveries and delivery groups (hq ADR 0239) ... One module answers 'did my change go out' for a commit and orders a cross-repository change: one compiled state table, its state on the bus, every transition said, noted on the commit and shown on the pull request. The forge's holder gains the note, view and status tools it asks with, and says closed pull requests and a merge's head and statuses.	2026-10-06 23:59:54 +02:00