fix(ci): run the full suite on stacked PRs, not just PRs into main - #3372

Issues

🟡 The guard doesn't cover pull_request_target.branches (util/check_workflow_triggers.py:651)

_pull_request_trigger() only reads triggers.get("pull_request"). pull_request_target has identical base-branch semantics, and .github/workflows/claude.yml — the PR review/re-review bot — is driven entirely by it (claude.yml:9). A future branches: [ main ] there would silence PR review on stacked PRs with a green checks page, which is #2767 recurring in the workflow least likely to be missed quickly. auto-label.yml:7 is the other pull_request_target consumer. Neither carries the filter today, so this is a hole in the regression guard, not a live bug.

branches-ignore is the same key in mirror form and is also unchecked (no current uses).

Shape of the fix — parameterize the helper and loop over both events:

PR_EVENTS = ("pull_request", "pull_request_target")
FILTER_KEYS = ("branches", "branches-ignore")
def _trigger(workflow: Any, event: str) -> Dict[str, Any] | None:
 if not isinstance(workflow, dict):
 return None
 triggers = workflow.get("on", workflow.get(True))
 if not isinstance(triggers, dict):
 return None
 trigger = triggers.get(event)
 return trigger if isinstance(trigger, dict) else None
# in run_check():
for event in PR_EVENTS:
 trigger = _trigger(workflow, event)
 if trigger is None:
 continue
 for key in FILTER_KEYS:
 if key in trigger:
 errors.append(f"{path.name}: `on.{event}.{key}: {trigger[key]}` ...")

Worth adding TestRejected cases for pull_request_target + branches and for branches-ignore alongside the existing five/six.

🟢 Stale comment describes the filter this PR deleted (.github/workflows/test_eval_agent_gemma_consolidation.yml:150)

 # path below. The `types:` list follows test_email_agent_eval.yml;
 # `ready_for_review` is what runs the gate on a PR that was opened as a
 # draft (see the draft clause in the job `if:`).

🟢 Self-hosted eval queue now takes stacked-PR traffic (.github/workflows/test_eval_agent_gemma_consolidation.yml:179)

That workflow uses concurrency: group: lemonade-eval with cancel-in-progress: false on a single-slot [self-hosted, Windows, strix-halo, lemonade-eval] pool, and its paths: include hub/agents/*/python/**. Stacked PRs previously couldn't enqueue at all; now they can, and nothing cancels a superseded run. The draft == false guard at line 239 keeps most of the 42 open PRs out, and test_sd/test_npu_embedder/test_lemonade_server/build-electron-apps carry the same guard — so this is likely fine, just worth watching queue depth after merge rather than changing anything now.

Strengths

• The guard is the point, and it's wired correctly. Widening lint.yml's paths to .github/workflows/** (both push: and pull_request:) is the non-obvious half — without it the new check would be invisible on exactly the PRs that trip it. The inline comment says why, next to the check_dependabot.py/dependabot.yml precedent it mirrors.
• check_workflow_triggers() in util/lint.py:806 mirrors check_dependabot() line-for-line — same nested-import fallback, same CheckResult shape, same failure message pointing at the issue. The [N/11] → [N/12] renumber is complete across all twelve.
• Tests cover the traps that actually bite here: "on" resolving to boolean True under YAML 1.1, bare pull_request: parsing to None, push: filters deliberately left alone, and a TestRealRepository case that runs the check against the live .github/workflows/. The unparseable-file and missing-directory cases both return 1 rather than passing vacuously, which is what keeps the guard from being a no-op.
• Scope is clean. Every hunk in the 34 workflows is a one-line replacement; no paths: filter moved, no push: trigger touched, and the replacement comment carries the issue number so the next person doesn't re-add it.