You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
gate: accept MEMBER/selfReview/admin PASS when GitHub stamps CONTRIBUTOR #936
A tip-named Verifier PASS can be discarded when GitHub reports author_association: CONTRIBUTOR even for a repository admin (seen on #925). Listing the login in selfReview (#926) does not clear that stamp. Org repos do not report OWNER; MEMBER is the org bar.
Wanted
enqueue-guard / merge-gate / review-gate shared decide should accept a tip PASS when any of:
association is OWNER, MEMBER, or COLLABORATOR
login is in selfReview
collaborator permission API reports admin for that login
Still refuse a bare CONTRIBUTOR. Admin must not skip the reviewers list or the own-author rule. Permission lookup only for Tip+Verdict conclusions by a login in reviewers that association/selfReview do not already qualify; fail closed on 403/404.
Tracking
Implemented on draft #935 (tip 861b845). Out of scope: #933.
Triage: the need is real, but one of the three qualifications must not ship. Line numbers on main 7be4e9b7.
The need, confirmed
author_association is GitHub's stamp about the commenter's relationship to the repository, and it says CONTRIBUTOR for a login that plainly holds admin on this repository (seen on #925: the tip PASS was discarded, and selfReview did not clear it). Accepting OWNER/MEMBER/COLLABORATOR is right, MEMBER is the org bar, and a permission-API check for a repository admin is the only way to recover the truth GitHub did not put in the stamp. Keep that.
What must not ship: selfReview qualifying other people's pull requests
selfReview is documented in .github/agent/review-policy.json as the own-author exception — "A pull request's own author does not count unless the author is listed in selfReview". #928/#931 shipped it as exactly one narrow carve-out for that case (review-gate.mjs:166-168 on 7be4e9b7: selfOnly = selfReview.has(login(r)) && login(r) === authorLogin), with a pinned negative case. Making the same list qualify any pull request keeps the name but changes the meaning: it becomes a second reviewers list, keyed on a list the policy file defines as something else, and it makes the #931 carve-out untestable (the negative case disappears).
Note it is also not needed for this issue: hsliuustc0106 is in reviewers, and the admin-permission path is what recovers his PASS on #925 — not selfReview.
Requirements
Association qualifies on OWNER/MEMBER/COLLABORATOR (review-gate.mjs:36).
The own-author selfReview carve-out stays exactly as merged (:166-168), negative case included.
A repository admin qualifies a CONTRIBUTOR, asked once per such conclusion, only for a login already in reviewers, only for a Tip+Verdict report, fail closed on 403/404/HTML — and never called when the tier needs no PASS.
Nothing else moves: the Written-by check, the own-author rule (:183), the reviewers list (:184).
An admin who is the pull request's author and is not in selfReview → own PASS still false.
An admin who is not in reviewers → still false (the platform-admin case must not open the reviewers list).
permission: admin and permissions.admin: true both count; 403, 404, a non-JSON body and a write/triage/maintain permission do not.
adminsFor is not called when the result is exempt (T0/T1), nor for a report that names no tip or carries no verdict.
The three scripts share decide: the same behaviour is asserted in review-gate.test.mjs, merge-gate.test.mjs and enqueue-guard.test.mjs.
#935 currently implements requirement 2 the other way round (it deletes the own-PR restriction at review-gate.mjs:166-168 and rewrites the #931 test to expect true). It must drop that branch before it is judged; I noted the exact change on the pull request.
Activity
Birfy commentedon Oct 24, 2026
Triage: the need is real, but one of the three qualifications must not ship. Line numbers on
main 7be4e9b7.The need, confirmed
author_associationis GitHub's stamp about the commenter's relationship to the repository, and it saysCONTRIBUTORfor a login that plainly holds admin on this repository (seen on #925: the tip PASS was discarded, andselfReviewdid not clear it). AcceptingOWNER/MEMBER/COLLABORATORis right,MEMBERis the org bar, and a permission-API check for a repository admin is the only way to recover the truth GitHub did not put in the stamp. Keep that.What must not ship:
selfReviewqualifying other people's pull requestsselfReviewis documented in.github/agent/review-policy.jsonas the own-author exception — "A pull request's own author does not count unless the author is listed inselfReview". #928/#931 shipped it as exactly one narrow carve-out for that case (review-gate.mjs:166-168on7be4e9b7:selfOnly = selfReview.has(login(r)) && login(r) === authorLogin), with a pinned negative case. Making the same list qualify any pull request keeps the name but changes the meaning: it becomes a second reviewers list, keyed on a list the policy file defines as something else, and it makes the #931 carve-out untestable (the negative case disappears).Note it is also not needed for this issue: hsliuustc0106 is in
reviewers, and the admin-permission path is what recovers his PASS on #925 — notselfReview.Requirements
OWNER/MEMBER/COLLABORATOR(review-gate.mjs:36).selfReviewcarve-out stays exactly as merged (:166-168), negative case included.CONTRIBUTOR, asked once per such conclusion, only for a login already inreviewers, only for a Tip+Verdict report, fail closed on 403/404/HTML — and never called when the tier needs no PASS.Written-bycheck, the own-author rule (:183), thereviewerslist (:184).Acceptance
reviewerswhose association isCONTRIBUTORand whose permission isadmin→counts: true.selfReviewlogin,CONTRIBUTOR, not an admin, judging someone else's pull request →counts: false, same reason text as today. The test is not rewritten to expect the new behaviour.selfReview→ own PASS stillfalse.reviewers→ stillfalse(the platform-admin case must not open the reviewers list).permission: adminandpermissions.admin: trueboth count; 403, 404, a non-JSON body and a write/triage/maintain permission do not.adminsForis not called when the result isexempt(T0/T1), nor for a report that names no tip or carries no verdict.decide: the same behaviour is asserted inreview-gate.test.mjs,merge-gate.test.mjsandenqueue-guard.test.mjs.#935 currently implements requirement 2 the other way round (it deletes the own-PR restriction at
review-gate.mjs:166-168and rewrites the #931 test to expecttrue). It must drop that branch before it is judged; I noted the exact change on the pull request.Written-by: Triage
fix(gate): keep the selfReview carve-out own-author only, accept a re…
fix(gate): ask the permission API for a reviewer who is not the pull …
docs(gate): the permission API is not the own-author carve-out
docs(gate): say that selfReview and admin do not replace each other
fix(gate): accept MEMBER/selfReview/admin PASS under CONTRIBUTOR stamp (