Conversation
This is the check the branch ruleset requires before anything merges to main. It does two things and never merges: an isolated Claude reviewer writes a verdict on each new head, and a deterministic evaluator publishes the maintainer-gate check run stating which rules the pull request meets. The workflow is a copy of omni-maintainer workflows/maintainer-gate.yml with the evaluator pin filled in. Below its header comment it is byte-identical to that file at the pinned commit, so the two can be compared directly. Moving the pin is a human edit here, in its own pull request, after the omni-maintainer change has merged, so what is enforced cannot change from another repository. Why the shape is what it is: - pull_request_target, never pull_request. The base branch copy of this file runs, so a head branch cannot substitute its own workflow, and the job can reach the gate environment whose deployment-branch policy allows main only. That environment holds the App key, which is what makes a verdict evidence of anything. - Nothing checks out pull-request code. The diff and the touched files are read through the API into review-input/. The one clone is this repository own bare objects for revert verification, with no working tree. - The reviewer gets the read-only default token, no shell and no network, and may read only review-input/ and write only verdicts/. A reviewer holding the App token could post its own approval. - Its first line is parsed against exactly two verdicts and posted separately with the App identity. A file list that may be truncated at the compare API 300-file page produces a forced REVISE from outside the reviewer writable path, which wins over anything it wrote. So does a file that could not be read at the head; files the pull request deletes are excluded by their compare status rather than by tolerating errors. - A pending check is published on every selected head before anything that can fail. This workflow also runs on events that do not move the head, where the head may already carry a success from an earlier evaluation; without the pending run, a crash would leave that success standing as the newest run. The heads arrive with one listing, and an event carrying its own head needs no request at all, so a transient failure cannot abort the sweep partway and leave later heads untouched. - A failing bar is a failing check, not a failing job. Only a crash of the evaluator fails the job, and then the check is missing and the ruleset blocks the merge either way. - The verdict binds to the head and to a digest of the title and description, because the reviewer is shown those and told to judge them, and either can be edited without moving the head. An edit re-runs the gate and reads as no verdict until it is reviewed again. - The sweep asks for every open pull request. The default listing stops at thirty, and the ones past it would keep whatever check they already had. test/test_maintainer_gate_workflow.py pins each of those. They are the ways this file could be quietly turned into something that proves nothing: an unpinned evaluator, an action on a movable tag, a pull_request trigger, a checkout of the head, the App token reaching the reviewer, a widened tool scope, a truncated or incomplete diff approving, a per-pull-request head lookup that aborts the sweep, an invalidation loop that stops at its first failure, a verdict that survives an edited description, a listing that stops at thirty, or a cancelling concurrency group that leaves the pending check as the newest run. No source module changes, so no SPEC page moves.
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This is the check the branch ruleset requires before anything merges to
main. It does two things and never merges: an isolated Claude reviewer writes a verdict on each new head, and a deterministic evaluator publishes themaintainer-gatecheck run stating which rules the pull request meets.The file is a copy of
workflows/maintainer-gate.ymlin JiusiServe/omni-maintainer with the evaluator pin filled in. Below its header comment it is byte-identical to that file at commit120da53, so the two can be compared directly. Moving the pin is a human edit here, in its own pull request, after the omni-maintainer change has merged, so what is enforced cannot change from another repository.Why the shape is what it is
pull_request_target, neverpull_request. The base branch copy runs, so a head branch cannot substitute its own workflow, and the job can reach thegateenvironment whose deployment-branch policy allowsmainonly. That environment holds the App key, which is what makes a verdict evidence of anything.review-input/and write onlyverdicts/. A reviewer holding the App token could post its own approval.test/test_maintainer_gate_workflow.pypins each of those. They are the ways this file could be quietly turned into something that proves nothing.No source module changes, so no SPEC page moves.
Prerequisite: this workflow needs the
gateenvironment and its secrets, and the gate App itself. Both are Phase 0 owner steps documented indocs/phase-0.mdin omni-maintainer. Until they exist the workflow fails at its first step, so merge it after that setup or expect a red run until then.🤖 Generated with Claude Code
https://claude.ai/code/session_01A68Up9sTC1FZ9KLCoac4NN