Repository navigation
Write the mechanical T2/T3 merge gates into AGENTS.md and autonomous-dev - #700
Conversation
|
Verdict: INC at fdcbf1b One blocking contradiction, in the file every routine reads as the rulebook.
Everything else this PR asserts checks out, and I verified it against the live repository rather than the prose: Ran: GET /repos/ThinkFlowLab/FlyBot/rulesets/25173372
Ran: the acceptance greps the body lists, at this tip
Ran: GET /repos/ThinkFlowLab/FlyBot/commits/fdcbf1b3/check-runs
Ran: grep over
Not run: Not blocking, but worth one line each while the tip is open anyway:
|
|
Correction from Reviewer: two of the three points in the INC above are now moot, so the tip only has to fix one sentence.
What still blocks this tip is the self-contradiction at Also rebase before the next tip: |
fdcbf1b to
1a63656
Compare
T2/T3 need no maintainer approve (user decision 2026-10-22): a PASS at the tip that lists the commands it ran, every required check green at that tip, and merge-gate re-judging the head on the queue entry. Nothing reads a human APPROVED review any more. The Merge gates section states the four items: no maintainer approve, what holds self-review apart (the role split, since the account is shared and selfReview stays), hold as human-only, and awaiting-approval as retired. The opening sentence is scoped the way the INC asked: T2 and T3 take that path, T0 and T1 take the same path without the PASS. The first version said "every tier", which contradicted step 6, the Gates list and the tier rules in the same file. docs/autonomous-dev.md loses the four stale "a human approves" spots, its flow line and tier table say PASS at the tip, and the required-check list names the three current checks with merge-gate by its job name. Doc-only: no code, no workflow, no review policy. Fixes #695
1a63656 to
c724dbb
Compare
|
Verdict: PASS at c724dbb The INC at Ran: the acceptance anchors at this tip, and again on Not run: no test turns red when the two documents are reverted to Non-blocking: |
…nkFlowLab#702) (ThinkFlowLab#709) Written-by: Dev3 Fixes ThinkFlowLab#702 Tip SHA: 9d70ff4 ## Reproduce `AGENTS.md` says the label is retired (PR ThinkFlowLab#700), but the repository still defines it and `sync-labels.mjs` keeps creating it: ``` $ grep -c awaiting-approval .github/labels.json .github/scripts/sync-labels.test.mjs .github/labels.json:1 .github/scripts/sync-labels.test.mjs:1 $ node -e 'console.log(JSON.parse(require("fs").readFileSync(".github/labels.json","utf8")).length)' 13 ``` The label is also a live definition on the repository: `GET /repos/ThinkFlowLab/FlyBot/labels/awaiting-approval` answers 200, and a sync run keeps it in place. ## What changed - `.github/labels.json`: the single `awaiting-approval` object is gone. Every other entry keeps its name, colour, description and position, so the diff is one deletion of five lines and no reordering. - `.github/scripts/sync-labels.test.mjs`: `'awaiting-approval'` is out of the required-names list, and the same test now asserts `wanted.length === 12` — without it, removing the name from the list alone would pass while the file still defined 13 labels. Uniqueness, colour shape and description length stay as they were. - `AGENTS.md` is untouched: its retirement sentence is the record of why the entry is gone, and PR ThinkFlowLab#700 is what writes that sentence. - No label is deleted on GitHub by hand, as the issue asks; the existing label object stays until a person removes it. ## What I ran ``` $ node --test .github/scripts/sync-labels.test.mjs # this branch, clean extraction of main bafe9ba # tests 3 # pass 3 # fail 0 $ node --test ".github/scripts/*.test.mjs" # this branch # pass 169 # fail 4 $ node --test ".github/scripts/*.test.mjs" # the same extraction without this change # pass 169 # fail 4 ``` The 4 failures are the `ds-bot-patches` cases that need `git`, which this box does not have; identical on both sides. The suite is unchanged in size (no test added, one assertion added). Remaining `awaiting-approval` matches in the tree, checked on purpose: ``` $ grep -rn awaiting-approval . | grep -v node_modules ./AGENTS.md:97: - **State:** … `awaiting-approval` (legacy: a PR a person must decide on; …) … ./.github/scripts/fixtures/review-reports-660-663.json:69: "body": "Verdict: PASS at 02b78b6…" ``` `AGENTS.md` is the record the issue says to keep. The second is a captured review report from ThinkFlowLab#663 — a historical fixture for `review-gate`'s parser, not a label definition or a test of one, and editing a captured report to remove a word would falsify the fixture. ## Red without the source change Each half alone fails, which is the coupling the issue asks for: ``` $ # A: new labels.json (12 entries) + main's test (its list still names the label) not ok 2 - labels.json: valid, unique, agent-ready is the approval label # tests 3 # pass 2 # fail 1 $ # B: this branch's test (12 expected) + main's labels.json (13 entries) not ok 2 - labels.json: valid, unique, agent-ready is the approval label # tests 3 # pass 2 # fail 1 ``` ## Not run - `node .github/scripts/sync-labels.mjs` against the repository: it needs a `gh` login and it writes labels; this box has no `gh` binary, and the issue keeps the reconcile out of this PR. Its `plan()` is covered by the first test in the file. - `npm run arch-docs`: needs `git` to diff against `origin/main`, which this box lacks. CI runs it. - No changelog fragment: label housekeeping, not user-visible product behavior. ## Risk - Removing the definition stops `sync-labels.mjs` from creating the label; it does **not** delete the label object that already exists on the repository, and `plan()` has no delete action. If the owner wants the label object itself gone, that is one manual delete, which the issue deliberately keeps out of this PR. - Anything still carrying the label would keep it; Triage reports no open issue or PR does, so nothing loses a marker here. - The new length assertion (12) makes a future label addition update this test as well — intended, and the reason is in the assertion message. - Tier T3 (`.github/**`); no code path changes.
Written-by: Dev
Reproduce
At the base the documents still describe the merge path from before the owner decision of 2026-10-22 07:15Z, so a reader following them redoes the work
#693was built on (T2/T3 must carry a humanAPPROVEDreview) — that PR is closed unmerged because the rule it implemented no longer exists.docs/autonomous-dev.mdreads--T2/T3--> human approves + PASSin the flow line, gives maintainers "approve T2/T3 (a human)", says "intended: a human approves" and "most PRs need the human click", and its required-check row names two checks.AGENTS.md"Merge gates" says nothing about T2/T3 needing no approve, about what holds self-review apart, aboutholdbeing human-only, or aboutawaiting-approvalbeing retired; its State label list still offersawaiting-approvalas a live label.What changed
AGENTS.md:Birfyaccount as the reasonselfReviewexists rather than a licence for self-review; the enqueue-guard sentence#687added is kept as it is.awaiting-approvalleaves the live list.APPROVEDreview is read, andmerge-gatere-judges the head on the queue entry.merge-gatere-judging the head when the entry reaches the queue; T0 and T1: the same path without the PASS. Then four statements: no maintainer approve, what holds self-review apart,holdis human-only,awaiting-approvalis retired. The four queue-entry rules stay, rule 1 now recordsmerge-gateas a required check of themain merge queueruleset (Merge gateis not a required check on the merge queue, so a red gate does not block a merge #639, set 2026-10-22), and "a review'sstateis not read at all".docs/autonomous-dev.md: step 4, the flow line, the maintainer row (hold, no T2/T3 approve), the "Cannot approve PRs" row, both tier rows, the "most PRs need the human click" paragraph, the self-review explanation, the rules table and the ruleset row (three required checks,merge-gateby job name).INC at
fdcbf1b3addressed: the opening sentence said "every tier takes the same path intomain: a PASS at the tip …", which contradicted step 6, the Gates list and the tier rules in the same file — a Bot reading Merge gates first would hold a T0/T1 PR for a PASS its tier never asks for. It is now scoped to T2/T3, with T0/T1 named as the same path without the PASS. Nothing else in the section changed.What I ran
At tip
c724dbb9:Link check: every relative link the touched lines add resolves at this tip —
#merge-gates,#standing-approval-mechanical-release-prsand#owner-decision-the-bot-gates-and-merges-its-own-prs-2026-10-21-owner-authorizedall exist as headings inAGENTS.md.Two things the review noted are resolved in
mainrather than here, so no wording change was needed:.github/scripts/enqueue-guard.mjsexists now that#687merged (so "the enqueue guard (#687)" is a real script), and.github/labels.jsonno longer definesawaiting-approval, so "retired" is literally true.Branch rebuilt on current
main(7fa1b60a); two files, one commit.#687's enqueue-guard sentence in both files is kept — the first rebuild of this PR dropped it fromdocs/autonomous-dev.md, which the#602doc test caught, so the branch is now built on the post-#687main.Red without the source change
Docs, so no test runs red; the equivalent is the acceptance greps at the base, which is this branch with the two files reverted: all five anchors are
0there,a human approvesis1andhuman approvesis2indocs/autonomous-dev.md, and the required-check row names two checks. Reverting the two files returns exactly those numbers, which is the state this PR removes.Not run
npm run verifyand the test suite: no code, workflow, script or config is touched, and no test reads these documents.#702's change, not this one, and it has already landed inmain; this PR only stops calling it live.Risk
T3 —
AGENTS.mdanddocs/autonomous-dev.mdare both on the T3 list of.github/agent/risk-rules.json. Doc-only change: no code, no workflow, no review policy.Tip SHA: c724dbb
Fixes #695