Repository navigation
ci(governance): let agents clear high-risk changes - #93
Conversation
The gate already accepts agent-approved. Make the rule say so: an agent clears high-risk changes itself once the current head has a clean Codex receipt and green contexts, and records the label in the ledger. No change waits on a human label.
|
@codex review |
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 41e6e95e6b
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
…abot contract A label added before a later push cleared the new head. The label event time is now compared with the head commit date, so only a label added after that commit counts. The Dependabot fast path requires the committer to be the bot account, matching the regression test that the previous web-flow predicate broke.
A high-risk PR without a clearing label fails risk-gate by design, so requiring every required context to be green before the label was a circular prerequisite. The other contexts gate the label; risk-gate is checked after it.
|
@codex review |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 09e42900a8
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
…tity A label lives on the pull request, so a later push left it looking current. The run for the labelled event now records the head from its payload as a commit status, and later evaluations credit the label only when the current head carries that record. Dependabot's real commits are authored by dependabot[bot] and committed by web-flow from noreply@github.com, the same identity the auto-merge gate checks, so the fast path stays reachable.
|
@codex review |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 89b171964a
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
…e evaluation A commit status can be shared by two pull requests, so the record now names the PR. The record is written by its own job with no concurrency group, because a superseded evaluation would otherwise lose the only copy of which head the label was added to. Each label is validated against the head before owner precedence applies.
|
@codex review |
|
Codex Review: Didn't find any major issues. What shall we delve into next? Reviewed commit: ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
If Codex has suggestions, it will comment; otherwise it will react with 👍. Codex can also answer questions or update the PR. Try commenting "@codex address that feedback". |
A label can be removed and added again later. Without the event id, moving the head back to an earlier commit would revive the removed approval, because the stored record and the live event would be two different approvals. The recorder stores the event it handled and the evaluation requires that exact id.
|
@codex review |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: b56e6a0b8d
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
A run queued for head A can start after the label was removed and added again on head B. Looking up the newest event at execution time then stamped B's addition onto A. The record now matches the addition whose time equals the pull request snapshot that carried the head, and writes nothing when that time matches no addition or more than one.
|
@codex review |
|
Codex Review: Didn't find any major issues. Swish! Reviewed commit: ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
If Codex has suggestions, it will comment; otherwise it will react with 👍. Codex can also answer questions or update the PR. Try commenting "@codex address that feedback". |
AI assistance
Qoder (AI agent) wrote this change from the owner's instruction; Codex reviewed the final head.
What changed
AGENTS.md: no change waits on a human label. A high-risk change needs one clearing label, and an agent may addagent-approveditself once the Codex receipt on the current head is completed with no unresolved findings and every other required context is green, then waits forrisk-gateto re-evaluate.owner-approvedremains for the owner's own confirmation, and agents never add or remove it..github/workflows/risk-gate.yml:record_labeljob writes the head from alabeledevent to an immutableclearing-labelcommit status, so a label added before a later push cannot clear the new head;pull_request.updated_atsnapshot that arrived with the head, so a delayed run cannot stamp a newer label on another head onto an older one; when the time matches no addition or more than one, it records nothing;dependabot[bot]authored,web-flowcommitter fromnoreply@github.com, verified), matchingscripts/dependabot_auto_merge_gate.py.RISK_GATE_OWNERis set and theagent-approvedlabel exists, so the clearing path no longer names nobody.How verified
node --check.completedwith no unresolved findings.Why
The gate accepted an agent's clearing label, but an unset approver variable and a record that could name the wrong label event meant the path either accepted nobody or could credit an approval the owner had revoked. The rule and the gate now agree, and no change waits on a manual owner label.
Risk
Risk tier T2: governance text and one workflow. The blast radius is this repository's pull-request status publication. Reverting this pull request restores the previous clause and gate.