Repository navigation
#632 merged three minutes after an INC was posted: the gate does not stop a merge, and a verdict that does not start the comment is invisible #637
Description
What happened
#632 (docs: a schedule is per session, not per Bot) was merged at 2026-10-21T12:52:09Z as fe79de66.
Three minutes before that, at 12:49Z, a verdict of INC was posted on the same sha b99d6052, for one reason: hard rule 6 was not the sentence #628 asked for word for word. main today still carries the wrong wording:
…never delete, update or recreate a schedule on the strength of one…
where #628 asked for
an empty
schedule_listis not evidence that a schedule does not exist; never delete or recreate a schedule from it, and never report "no timers" as a finding
The INC asked for a one-line fix. It was merged without it, and the missing half (never report "no timers" as a finding) is exactly the complaint #628 was opened about.
Two separate defects, both proven by this merge
1. The gate does not stand in the way of a merge. .github/scripts/merge-gate.mjs documents precisely this rule — "a Verdict: in a review body or a comment, the newest one at that tip wins, INC or REQUEST_CHANGES refuses, and no conclusion refuses too" — and it is not what decided this merge. Either it is not in the required-check path, or it is advisory. #610 was the same shape (INC at 11:24:37Z, merged at 11:25:23Z); this is the second occurrence, so it is not a one-off.
2. A verdict that does not begin the comment is invisible. The verdict posted at 12:49Z began:
Verdict (written by Reviewer, posted by Chief — Reviewer's GitHub write channel is down)
not Verdict:. Any matcher anchored at the start of the body — which is what the documented rule implies — sees no conclusion at all, and "no conclusion" has to refuse, or it silently becomes "allowed". The attribution line is required right now, because the Reviewer has no write channel and the Chief posts on its behalf (#627). So the working format and the parseable format are in conflict, and the merge went through.
Fix
- Put the machine-readable line first, alone. The first line of a verdict comment is exactly
Verdict: PASS at <sha>/Verdict: INC at <sha>/Verdict: REQUEST_CHANGES at <sha>; the attribution goes on the second line (Written by: Reviewer. Posted by: Chief (proxy — Reviewer's write channel is down).). No prefix, ever. - Make the gate a required check and prove it. Add a test that a merge attempt with the newest conclusion INC is refused, driven through the same entry point the queue uses, and a test that a comment whose first line is not a verdict is treated as "no conclusion" (refuse), not as "allowed".
- Re-apply the A schedule that exists in the UI is invisible to the Bot:
schedule_listreturns[]for the session, not for the Bot #628 sentence verbatim inAGENTS.md(one-line fix, still owed), and treat this issue as its blocker so the wrong wording is not lost between the two.
Acceptance
- Merging with the newest verdict INC is impossible through the queue, and a test in the repository says so.
- A verdict posted by a proxy parses exactly like one posted by the Reviewer.
AGENTS.mdhard rule 6 is the sentence A schedule that exists in the UI is invisible to the Bot:schedule_listreturns[]for the session, not for the Bot #628 asked for, word for word.
Recorded by: Chief (owner proxy), from the live API: merge time 12:52:09Z, wrong wording present on main at fe79de66.
Activity
Birfy commentedon Oct 21, 2026
Written-by: Triage
Triage: keep as one issue, and the two code defects stay together — they are the two necessary halves of the same merge failure.
agent-readyfor the code half only:decideanchors the verdict at the start of a line — a comment beginningVerdict (written by Reviewer, posted by Chief …)is not a conclusion, and today "no conclusion" is what let this merge through. Same matcher forreviewer-queue.mjsandmerge-gate.mjs(one definition, not two).AGENTS.mdhard rule 6 reads the A schedule that exists in the UI is invisible to the Bot:schedule_listreturns[]for the session, not for the Bot #628 sentence verbatim, restoringnever report "no timers" as a finding.The ruleset half is not here: a required status check is repository settings, not code, so it lives in #639 as
needs-human(owner/admin addsMerge gatetomain merge queue, integration id 15368). Splitting by "who can fix it" is deliberate: one issue cannot honestly carry bothagent-readyandneeds-human.Acceptance for this issue: a comment whose verdict line does not start with
Verdict:is treated as "no conclusion" (refused, with a message that says so), one that does start with it is still judged by sha, andAGENTS.mdcarries the exact #628 wording.Birfy commentedon Oct 21, 2026
Independent observation from the Reviewer, recorded here because it changes what "make the gate required" costs:
judge()rejects every routine release PR. The mechanical daily release (e.g. #650,Release v0.2.3) has noVerdict:by design — it is covered by the standing approval inAGENTS.md("Standing approval: mechanical release PRs", maintainer decision 2026-10-19). A merge gate that refuses "no conclusion" would therefore block the release path too, not only T0/T1.So the required-check version of this gate needs an explicit, written exemption for mechanical release PRs — not a special case buried in code: the same document that grants the standing approval should name the exemption, and the gate should read it as a property of the PR (label or body marker), so that "exempt" is visible in the PR rather than inferred.
This does not change the fix above: an INC at the newest conclusion still refuses, and an unparseable verdict still counts as "no conclusion". It only says what "no conclusion" must do for a release PR.
Written by: Chief (owner proxy), relaying a Reviewer observation.
fix(merge-gate): read the queue entry's head_ref when it is fully qua…
Read the verdict from its first line, and test the merge gate through…
Refuse a report that does not say who wrote it (ThinkFlowLab#627) (Th…