[devtools-agent]

Linear: PLA-2303

What changed

Adds the two caller workflows for the shared human-review-policy check from rollbar/human-review-policy. That repo is public so SDK repos can use it; the private repos use the same code through rollbar/github-workflows#130.

• .github/workflows/human-review-policy-trigger.yaml: a no-op that runs on PR events (opened, reopened, synchronize, ready_for_review, edited, closed) and review events (submitted, edited, dismissed).
• .github/workflows/human-review-policy.yaml: runs on workflow_run of the trigger and calls the reusable workflow, which posts a human-review-policy commit status on the PR's head commit.

The status passes with 1 human approval besides the author on a human-authored PR and 2 distinct human approvals on a bot-authored one (e.g. devtools-agent[bot]). That way every production PR has two distinct humans on it. Approvals from bots and rollbar-circleci-machine don't count. Pushing commits to a PR doesn't stop someone from approving it.

Post-merge tracking: if a PR is merged without meeting the policy, e.g. through an admin break-glass bypass, it gets the needs-post-merge-review label and a comment saying how many approvals it still needs. Reviewers can still approve a merged PR. Once the policy is met, the label is removed and a closing comment is posted. To list what's still owed: is:pr is:merged label:needs-post-merge-review org:rollbar.

Why two files

pull_request workflows run the YAML from the PR's own branch, so a PR could rewrite the check that judges it. workflow_run workflows always run the copy on main. If a PR breaks the trigger, the status is never updated and the PR stays blocked.

Rollout order

1. The first content of rollbar/human-review-policy has to be merged first. Until then the Human review policy runs here fail with "workflow not found". That's harmless, but noisy.
2. Merge this PR. The status only starts appearing once human-review-policy.yaml is on main, because workflow_run only fires for workflows that are on the default branch.
3. A repo admin then makes it required with the ruleset in ruleset.json: gh api -X POST repos/rollbar/rollbar-react/rulesets --input ruleset.json. Org and repo admins can bypass it through a PR for incidents (break glass); post-merge review is required in those cases.

Not part of this PR: the ruleset itself (step 3).

Pull requests from forks

These work. The trigger runs on the fork PR, and the evaluation runs in this repo with this repo's token, finding the PR by its head branch. If first-time contributors need approval before their workflows run, the status appears once a maintainer approves the trigger run.

Merge queues

The trigger also runs on merge_group, so in repos with a merge queue the status is written on each merge group's commit as well, and the queue isn't left waiting for it.

Validation

• The workflow YAML parses. The shared logic has 41 unit tests and a read-only dry run against real rollbar/mox PRs.
• Not yet run end to end here; that happens after steps 1 and 2.

🤖 Generated with Claude Code

[linear-code]

PLA-2303

CR-190

[rollbar-circleci-machine]

AI Agent Review LGTM (openai, openai-astra)

LGTM. No blocking findings were found.

No findings. I read both new workflows in full, along with the repo's existing workflows (.github/workflows/ci.yaml, .github/workflows/publish.yml) and the PR description.

What I checked:

• The two files are linked correctly. workflows: [Human review policy trigger] (.github/workflows/human-review-policy.yaml:11) exactly matches the trigger's name: (.github/workflows/human-review-policy-trigger.yaml:1).
• The trigger can't do anything. It has permissions: {} (human-review-policy-trigger.yaml:14) and runs a single echo. That echo only expands github.event.pull_request.number (an integer, empty on merge_group) and github.event_name (human-review-policy-trigger.yaml:20), so no user-controlled text reaches the shell.
• Permissions sit on the right job. They are set on the job that calls the reusable workflow (human-review-policy.yaml:16-19): contents: read, pull-requests: write, statuses: write. This matches what the description says the shared workflow does: write a commit status, add a label, post a comment.
• Events covered. The trigger fires on the PR events (human-review-policy-trigger.yaml:6-7), including closed for post-merge tracking, on review submit/edit/dismiss (:8-9), and on merge_group (:11-12). A PR that breaks or deletes its own copy of the trigger only blocks itself, so tampering fails closed.
• Matches repo convention. Referencing @main rather than a commit SHA is consistent with this repo, which pins actions to tags such as actions/checkout@v4 (ci.yaml:32).

Not verified (code not in this checkout):

• rollbar/human-review-policy/.github/workflows/human-review-policy.yaml@main is not here. I couldn't confirm:
  • whether it needs with: inputs or secrets: (the caller passes neither);
  • whether it needs permissions beyond the three granted, such as issues: write or actions: read;
  • whether it sets a concurrency group, so overlapping runs can't overwrite each other's status;
  • that it never checks out or runs PR code, and never puts github.event.workflow_run.head_branch (chosen by whoever opens a fork PR) into a run: script. A workflow_run job gets a write token even for fork PRs, so these two points are the main thing to check in that repo.
• The rollout dependency (step 1: the shared repo must have content before this runs) isn't tied to a specific PR, so I couldn't check it. rollbar/github-workflows#130 covers the private repos only and isn't checked out.

Notes:

• Because the job calls @main, anyone who can push to rollbar/human-review-policy main controls whether this required check passes. That repo needs branch protection at least as strict as the repos it gates.
• Open PRs won't get the status until a new event fires after merge, such as a push, a review, or a title/body edit (edited is in the trigger's event list).

I didn't run anything, and the diff doesn't show that anything was run.

[brianr]

Closing without merging. The human-review-policy check is moving from GitHub Actions into Caliper, as the approvals check in phase 4 of rollbar/business eng/caliper/DESIGN.md. Caliper already works out each PR's review stage, so the policy, and the lower tiers for low-risk PRs that come after it, will be defined in one place.

Caliper will post the status from its GitHub App, so this repo doesn't need any workflow files. It starts as an optional check. Tracking: PLA-2303.