PM-34598 - Enhance review code workflow to trigger on PR publish - Labeled

[theMickster]

🎟️ Tracking

PM-34598

📔 Objective

This is a continuation of the desired improvements for our Claude Code Review workflows.
We confirmed that the trigger of publishing a draft PR worked. Now, we are ensuring that the labeled trigger works (or not).

PR #90 is the predecessor.

[theMickster]

Brief note... While field testing #96 on my local machine, the following code review for this work was produced by Claude. Give it a read and note the interesting findings that the initial agents found and then the independent agents rejected. Claude did exactly what we want; dug deeper by locating the reusable workflow and found that the label filtering is somewhere else 😁

Code Review: PM-34598 - Enhance review code workflow to trigger on PR publish - Labeled (#97)

Date: 2026-04-24 | Reviewed by: Claude Code (model: opus)

Summary

Severity	Count
🛑 Blocker	0
⚠️ Important	0
♻️ Refactor	0
💡 Suggestion	0

A one-line change to .github/workflows/review-code.yml adding labeled to the pull_request trigger types (and alphabetizing the list). Two initial findings from the architecture and security passes were both dismissed during validation: the callee reusable workflow bitwarden/gh-actions/.github/workflows/_review-code.yml@main already performs label-name filtering internally, so broadening the caller's trigger does not cause spurious OIDC consumption or unwanted review output. The change is safe and functional; no blocking or important issues remain.

Findings

No findings found.

Reviewed and Dismissed

🔍 2 initial findings dismissed after validation

labeled trigger added without an if: gate on github.event.label.name

.github/workflows/review-code.yml:5
Original severity: ⚠️ Important
Original confidence: 85/100
Dismissed at: Step 4 validation
Dismissed because: The callee reusable workflow (bitwarden/gh-actions/.github/workflows/_review-code.yml@main) already performs label-name filtering in its validation job — it reads the PR's labels via gh pr view and sets should_review=false unless ai-review or ai-review-vnext is present. The downstream review job is gated on should_review == 'true', so adding unrelated labels like bug or documentation does not consume Azure OIDC credentials or post review output. A caller-side if: gate would save a few cheap no-op workflow runs but is a minor optimization, not a real-review blocker.

labeled trigger lacks label-name filter; runs on every label change

.github/workflows/review-code.yml:5
Original severity: ⚠️ Important
Original confidence: 85/100
Dismissed at: Step 4 validation
Dismissed because: Substantively duplicates arch-1; additionally not a security finding — the finder conceded no credential exposure (trigger is pull_request, not pull_request_target) and no P01–P06 / VD/EK/AT/SC/TC requirement is implicated. Impact would be purely operational (extra no-op workflow runs), and per the arch-1 dismissal above the callee's internal gating already minimizes that.