[renmengye]

The label-triggered review round now covers PRs from forks.

advisory-review-agent.yml runs a review session for a fork PR only when the caller passes allow_labeled_forks: true and the trigger is a label being applied. This repo's review.yml never passed it, so a fork PR got no review even after a maintainer added outerloop:review (seen on #598: the session and post jobs were skipped).

• Only the review job (the label round) opts in. The wide first round on open stays same-repo only, so a fork PR is reviewed only when a maintainer asks.
• Adding a label needs triage access, so the label is the maintainer's approval for each fork PR.
• The fork's head is never checked out; the session reads the base tree and the diff. The diff does reach the model, in a session that holds the reviewer key under a read-only job token.
• reviewer_ref stays at main, which is newer than the 0.5.1 minimum the opt-in needs.
• pull_request_target runs the base branch's workflow, so this takes effect once merged.

Verification: the full gate passes (ruff, format, mypy, pytest: 3082 passed, 7 skipped) and pre-commit is clean on the file. No test covers this workflow input; the check is #598 once it is relabeled after merge.

Compatibility: CI configuration only. No kernel state changes.

Built by Claude (Opus 5.5); reviewed by the advisory review bot.

[github-actions]

Round 1 — reviewed head ef509a21 — reviewer summarizer:hermes/gpt-5.6-terra over coverage+credentials+deployment+general+lifecycle+prose.

terra
Advisory findings from outerloop — the code owner decides. Reply to disagree; the outerloop:no-review label opts this PR out.

Verdict: 1 blocking, 0 advisory.

1 finding attached to the lines below.

Blocking: the fork-review opt-in exposes the reviewer credential to untrusted prompt data. Rejected findings: none.