fix(workflows): allow fork PRs in pr-review-panel

[danielmeppiel]

Problem

PR #815 (from edenfunf/apm fork) had the panel-review label applied but every job skipped: https://github.com/microsoft/apm/actions/runs/24751987642

Root cause: gh-aw's default fork policy on pull_request injects a fork-blocking gate (github.event.pull_request.head.repo.id == github.repository_id) on every job, so fork-originated runs skip entirely.

Fix

Add forks: ["*"] to the pull_request trigger in .github/workflows/pr-review-panel.md. Recompiled with gh aw compile --strict.

Trust model

The panel-review label is the trust gate: only write-access maintainers can apply labels, so a malicious fork PR cannot self-trigger the workflow. gh-aw's safe-outputs isolation handles the fork-token problem -- the write-scoped publisher job runs in base-repo context, separate from the read-only agent job.

Test plan

After merge, re-apply (or remove + re-apply) panel-review to PR #815 and confirm the panel runs and posts a verdict comment.

Co-authored-by: Copilot 223556219+Copilot@users.noreply.github.com

[Copilot]

Pull request overview

Enables the pr-review-panel agentic workflow to run for fork-originated pull requests by explicitly allowing forks in the gh-aw source workflow, and recompiling the locked workflow output accordingly.

Changes:

• Add forks: ["*"] to the pull_request trigger in .github/workflows/pr-review-panel.md.
• Recompile and update .github/workflows/pr-review-panel.lock.yml, removing the default same-repo fork gate from job if: conditions.

Show a summary per file

File	Description
.github/workflows/pr-review-panel.md	Allows fork PRs to trigger the review-panel workflow via gh-aw frontmatter.
.github/workflows/pr-review-panel.lock.yml	Updates compiled workflow to reflect fork allowance and associated condition changes.

Copilot's findings

• Files reviewed: 2/2 changed files
• Comments generated: 2

[Copilot]

pre_activation runs on every pull_request synchronize event (because the if only filters labeled events). With forks: ["*"], any fork PR push will now trigger at least this job, which undermines the stated cost gate and increases risk of abuse/CI noise. Consider adding a label-present check for synchronize (e.g., guard on the PR labels array) so the workflow only proceeds when panel-review is already applied, and keep labeled as the activation path.

Suggested change

	if: github.event_name != 'pull_request' || github.event.action != 'labeled' || github.event.label.name == 'panel-review'
	if: >
	github.event_name != 'pull_request' ||
	(github.event.action == 'labeled' && github.event.label.name == 'panel-review') ||
	(github.event.action == 'synchronize' && contains(toJson(github.event.pull_request.labels.*.name), '"panel-review"'))

[Copilot]

The header comment says the workflow "only runs when a maintainer applies panel-review", but the trigger includes pull_request.synchronize. In the compiled workflow, synchronize currently runs at least the pre_activation job even when the PR is not labeled. Either tighten the synchronize path to require the label (recommended, especially now that forks are allowed) or update the comment to match the actual behavior.

See below for a potential fix:

# public repos). A maintainer applying `panel-review` is the intent gate for
# the actual panel review, but the workflow also listens to `synchronize`.
# That means new pushes can start the workflow even before the label is
# present. `forks: ["*"]` allows fork PRs to be reviewed; the trust gate for
# the review itself remains the label, which only write-access maintainers can
# apply.