fix(ci): set up Python before pip in the bricked-PR audit, so it can run at all

[LukasWodka]

Bugbot High on the staging promotion PR #243.

The audit cannot start

bricked-prs.yml runs pip install --quiet pyyaml on ubuntu-latest with no actions/setup-python. Ubuntu 24.04 marks its system Python externally managed (PEP 668), so pip refuses, the step fails, and the audit never runs.

The dependency is real: bricked-prs.py loads caller-drift.py for the protection reader, and that module hard-fails without PyYAML by design. The install cannot just be dropped.

Why this is worse than an ordinary broken job

This audit exists to find PRs blocked by a required check that never reports — it hunts a silence. A guard that cannot start produces exactly the same silence as a clean fleet, so its failure is indistinguishable from its success, and nothing else in the org would have said otherwise.

The fix is the sibling shape, not a new idea

bricked-prs-selftest.yml already sets up Python 3.12 before the identical install. The audit and its selftest now agree — which is also why the selftest never caught this: it was testing a correctly-configured job.

Checked the class, not the instance

Swept every workflow in the repo: this was the only one with a pip install and no setup-python.

actionlint clean, YAML parses, setup-python pinned by SHA with its version comment per the action-pins gate.

---

Note

Low Risk
Workflow-only change mirroring an existing sibling job; no application, auth, or data-path changes.

Overview
The scheduled bricked PRs audit was failing on ubuntu-latest because pip install pyyaml ran against the system Python without actions/setup-python, triggering PEP 668 on Ubuntu 24.04 and aborting before bricked-prs.py ever ran.

This change inserts actions/setup-python (3.12) immediately after checkout—the same step order and pin already used in bricked-prs-selftest.yml—so PyYAML installs into a managed interpreter and the org-wide “required check that never reports” guard can actually execute.

^{Reviewed by Cursor Bugbot for commit d319338. Bugbot is set up for automated code reviews on this repo. Configure here.}

[saqlainsyed007]

Review — APPROVE

What this does: Inserts actions/setup-python@…be951 # v5.6.0 (Python 3.12) immediately after checkout in bricked-prs.yml, so the subsequent pip install --quiet pyyaml runs against a managed interpreter instead of the system Python that Ubuntu 24.04 marks externally-managed (PEP 668).

Correctness — verified:

• The root cause is real: the job did pip install pyyaml → python3 scripts/bricked-prs.py with no setup-python, and bricked-prs.py hard-fails without PyYAML (via the caller-drift.py protection reader). On ubuntu-latest (24.04) the install would abort under PEP 668 and the audit never runs.
• The fix mirrors the sibling exactly: bricked-prs-selftest.yml already uses the identical setup-python SHA pin, version comment, and step order before the same install.
• After setup-python, pip, python, and python3 all resolve to the same 3.12 interpreter, so PyYAML installed by the pip step is importable by the python3 audit step. Consistent.
• Confirmed the "only workflow" sweep: on develop, bricked-prs.yml was the sole workflow with pip install and no setup-python (the other four — bricked-prs-selftest, caller-drift, standards-sync, version-bump-gate-selftest — all already set it up).

Conventions / security: Action pinned by commit SHA with its version comment, per the action-pins gate. Workflow-only change; no auth or data-path impact.

Minimal, correct, and consistent with the established pattern. LGTM.