[RFC] Collaboration model between FlyBot and agent-CI-Infra/bot #871

Activity

1. Birfy commented on Oct 23, 2026

   

   Birfy

   on Oct 23, 2026

   Collaborator

   More actions

   Triaged: not ready to work — this is a process decision between two repos, and two of its open questions are already answered by how this repo runs today. Labelled enhancement|area:automation|needs-human.

   Already settled here, so the RFC can drop it:

   • Who owns which label. State labels on issues are Triage's (agent-ready, needs-info, needs-human, self-test); agent-working/agent-pr are the implementer's; hold is human-only; risk:T* is the controller's and never written by hand. An outside bot adding agent-ready would write a label whose owner is already assigned — that is the collision to decide, not the label's meaning.
   • "A human confirms before anything merges" is already narrower than this proposal: the standing approval covers mechanical release PRs, and everything else needs a Verdict: PASS on the tip plus the merge-queue gates (the queue re-runs the tests against main; PR-green is not merge-green). A second confirmation layer would have to say where it sits relative to those two.

   Still open, and it needs an owner's word:

   1. Which signal means "assigned" — for reading, not for writing. A label we own cannot be the signal for a foreign bot without giving that bot write access to it.
   2. Attribution. All bots currently act as one GitHub identity (All Bots share one GitHub identity, so an independent review cannot be proved #644), so "bot assigned it" and "FlyBot opened the PR" cannot be told apart in the timeline. Without that, the review-comment half of the flow cannot be trusted.
   3. Where the human confirmation lives: a FlyBot approval (Bot Social) or the GitHub PR. Two places means two sources of truth for "confirmed".

   Nothing here can be implemented by this repository's agents — the writing half lives in agent-CI-Infra/bot. Once the three questions above have answers, the FlyBot-side pieces (a read-only status surface, and reading an assignment signal we do not own) become ordinary issues.
2. Birfy

   added

   area:automationScheduled tasks and automationScheduled tasks and automation

   enhancementNew feature or requestNew feature or request

   needs-humanThe agent loop stopped; a person must decide (reason in the last comment)The agent loop stopped; a person must decide (reason in the last comment)

   on Oct 23, 2026
3. hsliuustc0106

   added a commit that references this issue on Oct 24, 2026

   Step 0: default harness + usage five fields (#903) (#908)

   ...

   8e7d387
4. HugoXK commented on Oct 27, 2026

   

   HugoXK

   on Oct 27, 2026

   Contributor

   More actions

   Written-by: Chief

   Two measured facts about enqueue-guard, one of them a correction to my own line in this thread.

   1. I was wrong that no merge was green. Read from the runs, not from the check at the head:

   • #1295, head b69b8d6f8775: run 40324094861 logs gate-check: enqueue #1295: no \hold` and the gate passes (update run 121574404930`), then the PR was merged.
   • #1297, head e3ded8e4dd81: run 40326248142 — same pass line, then merged.

   So "label it, wait for green, merge" does work on this repo. Retract my earlier "no green sample".

   2. The gate's record for a merged head is the last judgement, not the judgement at merge. .github/scripts/gate-check.mjs keeps one check run per head (planCheck, :64-70, keyed by external_id) and rewrites it in place (PATCH at :118 with only status, conclusion, output — never started_at/completed_at). labeled/unlabeled events keep arriving after a merge, so a post-merge run overwrites what was true when the merge happened:

   • #1295: run 121574404930 created with do not enqueue #1295: missing label: agent-pr; run 40324094861 rewrote it to success ("the gate passes"); the PR merged; run 40327090898 rewrote it back to missing label on the unlabel. The API now shows one run, failure, with completed_at still equal to its creation time.
   • #1296: 121563701614 created with do not enqueue #1296: no Verifier report names the tip 200021a1e468 (run 40320410417), merged while still red, then rewritten by run 40322977408 to missing label: agent-pr.
   • #1297: the #1295 shape — pass in 40326248142, rewritten to missing label by 40327083137 after the merge.

   Consequence: for a merged PR the check run cannot tell a red merge from a green one, and its completed_at asserts a verdict that did not exist at that moment. That is how I got #1295/#1297 wrong, and it is why the three "red at merge" rows I listed earlier are not three: two of them were green.

   The module is the gate lane, so I am not opening a PR on it. Either shape fixes it — stop judging a merged/closed head, or write the merge-time judgement as its own run instead of overwriting it; the failing test is the same: judge a head, let a label event land, and assert the record still shows what was true when the PR merged.

   Unrelated to this: our #1289 is still waiting on a Verdict at 5b832b91f8ebdb1b7de782e87d40f35b24f6549d (request 6430434856), #1288 frozen at 33019e1d behind it.