[PureWeen]

Note

Are you waiting for the changes in this PR to be merged?
It would be very helpful if you could test the resulting artifacts from this PR and let us know in a comment if this change resolves your issue. Thank you!

The gap

The release-readiness skill has two report generators. The Preview lane (Get-PreviewReadiness.ps1) already surfaces open PRs carrying the p/0 label as release blockers. The SR lane (Get-ReleaseReadiness.ps1) did not: it derived blocking only from ship-checks (BLOCKED) and Tier-1 regressed-in-* issue classifications. Open PRs were listed purely informationally.

Consequence: a p/0-labelled PR targeting an SR branch was never flagged as blocking on the SR tracker issue. Concretely, PR #35970 (Revert PR #33584…, base release/10.0.1xx-sr8, label p/0) did not show as blocking on the SR8 tracker issue #35876.

What changed

• Ported Test-IsP0Pr from the Preview lane into Get-ReleaseReadiness.ps1. It is StrictMode-safe and accepts both the production gh --json PSCustomObject shape and the IDictionary/hashtable shape used by test mocks.
• Added Get-P0PrChecks, which emits a single P/0 release-branch PRs ship-check — BLOCKED (naming each offending PR, e.g. #35970) when any open p/0 PR targets the SR branch, READY otherwise.
• Merged the check into shipChecks in the main flow, reusing the already-fetched open-PR list so there is no extra gh call. Because it's a standard BLOCKED ship-check, it is automatically hoisted into the top-of-issue 🔴 Blocking summary and escalates the verdict to Not Ready — no verdict or renderer changes were needed.
• Added deterministic synthetic-fixture unit tests for both functions (no network, no wall-clock dependence).

Notes

• This is a PowerShell-only .github/skills/** change; the framework maui-pr pipeline intentionally skips for skills-only PRs.
• Discovered while working on the separate deflake PR Deflake release-readiness recency test: remove wall-clock-dependent live assertions, add deterministic fixture coverage #36004.

[github-actions]

🚀 Dogfood this PR with:

⚠️ WARNING: Do not do this without first carefully reviewing the code of this PR to satisfy yourself it is safe.

curl -fsSL https://raw.githubusercontent.com/dotnet/maui/main/eng/scripts/get-maui-pr.sh | bash -s -- 36006

Or

• Run remotely in PowerShell:

iex "& { $(irm https://raw.githubusercontent.com/dotnet/maui/main/eng/scripts/get-maui-pr.ps1) } 36006"

[PureWeen]

Live demonstration caveat (transient / self-reverting): I dispatched release-readiness.yml from this PR's branch (run 27786593708) so the SR8 tracker issue #35876 was regenerated by the new script. It now shows PR #35970 in the 🔴 Blocking table with a Not Ready verdict.

Because this was dispatched from an unmerged branch, the next scheduled run (weekday cron) checks out main — which lacks this feature — and will regenerate #35876 back to the non-blocking state until this PR merges. So the live demo is expected to self-revert; it's not a regression.

[kubaflo]

Note

🤖 This review was automatically generated by a multi-model AI review system (Claude Opus 4.8, GPT-5.5, Gemini 3.1 Pro). Three models independently reviewed the code, then cross-pollinated their findings to produce this consolidated review.

Multi-Model Review — PR #36006 Round 1

Verdict: ✅ LGTM (Unanimous)
Confidence: High

Summary

Perfect unanimous approval with one optional test-coverage suggestion. This PR correctly closes the SR/Preview parity gap by surfacing p/0-labelled PRs targeting SR branches as release blockers.

What This PR Fixes

The Gap: Preview lane already surfaces p/0 PRs as blockers. SR lane did not — it only derived blocking from ship-checks and Tier-1 regressed-in-* issues. Result: PR #35970 (p/0 label, base release/10.0.1xx-sr8) didn't show as blocking on SR8 tracker issue #35876.

The Solution:

1. Ported Test-IsP0Pr from Preview lane — StrictMode-safe, handles both PSCustomObject and IDictionary shapes
2. Added Get-P0PrChecks — emits P/0 release-branch PRs ship-check: BLOCKED (naming each PR) when any open p/0 PR targets SR branch, READY otherwise
3. Integrated into shipChecks flow — reuses already-fetched open-PR list (no extra gh call), automatically hoists to 🔴 Blocking summary, escalates verdict to Not Ready
4. Added deterministic tests — synthetic fixtures for both functions, no network/wall-clock dependence

Verification (All 3 Reviewers Agreed)

✅ Logic correct — Test-IsP0Pr port matches Preview lane behavior
✅ Integration sound — Check wired before verdict computation, surfaces in blocking summary
✅ No extra network calls — Reuses existing open-PR list
✅ Test coverage complete — 17 passing tests added, synthetic fixtures, no live dependencies
✅ Parity achieved — SR lane now matches Preview lane behavior for p/0 PRs

Optional Suggestion (Non-Blocking)

💡 Opus noted the BLOCKED fixture tests a single p/0 PR, so the multi-PR comma-join (#35970, #35971) is never exercised. Adding a two-PR fixture would lock in the naming format the release captain sees. Not blocking — the join logic is trivial and all critical paths (BLOCKED/READY/null/empty) are already well covered.

Cross-Pollination Notes

• All 3 models: Independent LGTM with high confidence
• Opus: Verified check is wired correctly, surfaces in blocking summary, no extra gh calls, 17 tests added
• GPT: Confirmed parity achieved, integration sound, test coverage complete
• Gemini: Validated StrictMode safety, shape handling, list reuse
• Zero disagreements — Perfect alignment, with Opus's optional test suggestion corroborated by Gemini

Clean, well-tested SR/Preview parity fix. Ready for merge.

[kubaflo]

💡 💡 Optional multi-P/0 fixture (Opus suggestion, corroborated by Gemini)

The BLOCKED fixture passes a single p/0 PR, so the multi-PR comma-join in Get-P0PrChecks (($p0 | ForEach-Object { "#$($_.number)" }) -join ', ' at Get-ReleaseReadiness.ps1:2311) is never exercised.

Adding a fixture with two p/0 PRs would lock in the comma-joined naming that the release captain reads in the 🔴 Blocking table:

@($srP0Pr, [PSCustomObject]@{ 
  number = 35971; 
  labels = @([PSCustomObject]@{ name = 'p/0' }) 
})

Then assert Details matches *#35970*#35971* and Count stays 1.

Not blocking — the join logic is trivial and BLOCKED/READY/null/empty paths are already well covered. This is optional test hardening for straightforward comma-join behavior.

[PureWeen]

Good call — done in 3f03101. Added a two-p/0-PR fixture (#35970, #35971) that asserts the count text (2 open P/0-labelled PR(s)) and the comma-joined #35970, #35971 naming, so the multi-PR join path is now covered. Offline suite green at 504/0.

[github-actions]

Skill Validation Results

@PureWeen — new skill validation results are available based on this last commit: 5bbcc5e.
To request a fresh validation after new comments or commits, comment /evaluate-skills.

✅ Skill Validation Results — 5bbcc5e · Surface p/0-labelled PRs targeting SR branches as release blockers (SR lane parity with Preview) · 2026-06-19T16:19:19Z

✅ Static Checks Passed

Skills: 20 | Eval specs linted: 7

Full lint output

── .github/skills/agentic-labeler/tests/eval.vally.yaml
npm warn deprecated prebuild-install@7.1.3: No longer maintained. Please contact the author of the relevant native addon; alternatives are available.
✔ .github/skills/agentic-labeler/tests/eval.vally.yaml is valid
── .github/skills/code-review/tests/eval.capability.vally.yaml
✔ .github/skills/code-review/tests/eval.capability.vally.yaml is valid
── .github/skills/code-review/tests/eval.vally.yaml
✔ .github/skills/code-review/tests/eval.vally.yaml is valid
── .github/skills/code-review/tests/hermeticity.vally.yaml
✔ .github/skills/code-review/tests/hermeticity.vally.yaml is valid
── .github/skills/evaluate-pr-tests/tests/eval.vally.yaml
✔ .github/skills/evaluate-pr-tests/tests/eval.vally.yaml is valid
── .github/skills/try-fix/tests/eval.vally.yaml
✔ .github/skills/try-fix/tests/eval.vally.yaml is valid
── .github/skills/verify-tests-fail-without-fix/tests/eval.vally.yaml
✔ .github/skills/verify-tests-fail-without-fix/tests/eval.vally.yaml is valid

⏭️ LLM Evaluation: Skipped

No changed skills with eval specs found.

🔍 Full results and investigation steps