Add CI check that fails when `blocked` label is present on a PR

[maruiz93]

What happens

The blocked label exists in the repo and is used to mark PRs that depend on other PRs (e.g., stacked PRs waiting for a parent to merge). However, the label is purely cosmetic — there is no CI enforcement, so a PR with blocked can still pass all checks and be merged.

What should happen

A GitHub Actions workflow should run as a status check on pull requests and fail when the blocked label is present. The check should re-run when labels are added or removed (trigger on labeled and unlabeled events) so it clears automatically when the label is removed.

For this to actually prevent merging, the workflow's status check needs to be added as a required check in the repo's branch protection rules.

Context

This came up while creating a stacked PR (#981 on top of #861). GitHub's native stacked PR feature doesn't support fork-based workflows, so the blocked label + draft status is the current workaround for signaling merge dependencies. CI enforcement would make this safer.

[fullsend-ai-triage]

🤖 Finished Triage · ✅ Success · Started 8:33 AM UTC · Completed 8:36 AM UTC

Commit: 299f264 · View workflow run →

Runtime: claude · Model: opus → claude-opus-4-6 · Effort: high · Cost: $0.63

[fullsend-ai-triage]

⚠ Workflow file changes required

This issue requires creating a new GitHub Actions workflow file under .github/workflows/. The code agent cannot modify workflow files under current permissions — manual intervention is needed (a human-authored PR or maintainer action).

Implementation notes

The existing vouch-check.yml provides a good structural reference. The new workflow should:

• Trigger on pull_request (or pull_request_target) with types labeled, unlabeled, opened, reopened, synchronize
• Use actions/github-script or a simple shell check to inspect github.event.pull_request.labels for the blocked label
• Exit non-zero when the label is present

After the workflow lands, a repo admin must add the workflow's check as a required status check in branch protection rules for enforcement to take effect.

Proposed test

Scenario: blocked-label CI gate
  Given a PR without the 'blocked' label
  Then the blocked-check passes

  When the 'blocked' label is added
  Then the blocked-check re-runs and fails

  When the 'blocked' label is removed
  Then the blocked-check re-runs and passes

  Given a PR opened with the 'blocked' label already applied
  Then the blocked-check fails on the initial run

---

Labels: New CI workflow feature request matching enhancement and feature labels per repo conventions.

---

Next steps:

• /fs-code — agent creates a PR to implement this issue
• /fs-code <your instruction> — agent implements with your specific guidance

[fullsend-ai-prioritize]

RICE Priority Score: 1.8

Score breakdown

Dimension	Score	Reasoning
Reach	1	This affects all contributors who open or review PRs in the repo, particularly those using stacked PR workflows. It is an internal developer workflow improvement rather than a user-facing feature, impacting a moderate number of contributors across the project.
Impact	1	Without CI enforcement, a PR marked 'blocked' can still pass all checks and be accidentally merged, potentially breaking stacked PR dependencies. However, a manual workaround exists (checking for the label before merging), so the improvement is noticeable but not blocking core functionality.
Confidence	0.9	Very high confidence — the issue is extremely well-described with clear requirements, the triage comment outlines the exact implementation approach referencing an existing workflow as a template, and concrete test scenarios are provided. Scope is unambiguous.
Effort	0.5	Simple, well-scoped change — a single new GitHub Actions workflow file that checks for a label and exits non-zero if found. The triage comment confirms the existing vouch-check.yml provides a structural reference, and the logic is a straightforward label inspection with no architectural complexity.

Formula: (1 x 1 x 0.9) / 0.5 = 1.8