[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 master. 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 master, 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-php-wordpress/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-219

[rollbar-circleci-machine]

AI Agent Review (openai, openai-astra)

Review: human-review-policy caller workflows

The PR adds two workflow files. I read both, plus the repo's only other workflow (.github/workflows/php_unit.yml). I found nothing in the changed lines that I could confirm is wrong.

What I checked:

• Trigger name matches. workflow_run.workflows: [Human review policy trigger] (.github/workflows/human-review-policy.yaml:11) matches the trigger's name: exactly (.github/workflows/human-review-policy-trigger.yaml:1).
• Trigger has no token access. It sets permissions: {} (.github/workflows/human-review-policy-trigger.yaml:14) and doesn't check out code. It still works for fork PRs and review events, where the token is read-only anyway.
• The echo step can't be injected. Its only expressions are github.event.pull_request.number (an integer, empty on merge_group) and github.event_name (.github/workflows/human-review-policy-trigger.yaml:20).
• Permissions are narrow. The caller grants them at job level on a uses: job (.github/workflows/human-review-policy.yaml:15-20), limited to contents: read, pull-requests: write and statuses: write. There is no top-level grant and nothing else runs in that workflow.
• master is the default branch. That fits the PR's base and the comments about "runs from the default branch" (README.md:360-361).

Things I couldn't verify (not findings):

• The reusable workflow itself. rollbar/human-review-policy isn't in this checkout. So I couldn't check whether it asks for more permissions than this caller grants, whether it needs secrets (the caller passes none, no secrets: inherit), how it handles concurrent workflow_run events for one PR, or how it finds fork PRs by head branch. For the fork lookup, it should match the head repo owner and head SHA, not just the branch name. The rollout dependency on that repo's first content is declared in the description but not verified here. rollbar/github-workflows#130 only covers private repos and doesn't affect this one.
• The @main ref. .github/workflows/human-review-policy.yaml:20 pins the reusable workflow to a moving branch. Anything merged to that repo's main changes this repo's required check immediately, and runs with pull-requests: write and statuses: write here. This looks deliberate, to keep the policy central, so it's a trade-off rather than a defect. Pinning to a SHA, plus Dependabot for github-actions, would make the trust boundary explicit.
• End-to-end behaviour. The description says it hasn't run end to end yet. Two things to check then: that pull_request_review events on an already-merged PR still start the trigger, since clearing the needs-post-merge-review label depends on it; and how the status behaves on PRs with merge conflicts.
• The ruleset (step 3) is declared out of scope and isn't part of this diff.

No tests cover these files, and the diff doesn't show any workflow runs.