fix(release): retire superseded Windows sync PRs

[tianmind-studio]

What changed and why

Fixes #10727.

The Windows release workflow now retires superseded version-sync PRs after it has created or found the current replacement PR. The helper first confirms the current same-repository, main-targeting, exact-semver sync PR, then closes only strictly older release/windows-vX.Y.Z PRs; newer, unrelated, cross-repository, and wrong-base PRs are left untouched.

Cleanup is non-blocking and never deletes branches, tags, releases, or artifacts, so a GitHub API failure cannot interrupt an already-started Windows release.

Product invariants affected

none

How it was verified

• python .github/scripts/test_retire_superseded_windows_sync_prs.py - 4/4 tests passed.
• python .github/scripts/test_run_checks.py ManifestContractTests PlatformTests DeferredMarkerTests - 21/21 relevant manifest tests passed.
• python scripts/test_failure_class.py - 17/17 failure-class CLI tests passed.
• python scripts/failure-class validate --base origin/main --head HEAD --pr-body-file ... - passed for the new FC-superseded-windows-sync-pr-lifecycle definition.
• python .github/scripts/pr_preflight.py ... --list - passed and selected the new lifecycle check.
• python -m py_compile .github/scripts/retire_superseded_windows_sync_prs.py .github/scripts/test_retire_superseded_windows_sync_prs.py - passed.
• python -m black --check --line-length 120 --skip-string-normalization ... - passed.
• actionlint .github/workflows/desktop_windows_release.yml - passed.
• git diff --check origin/main...HEAD - passed.

The live gh pr close mutation was intentionally not run from a development checkout. The focused tests exercise it through a fake command boundary; the next real Windows release is the authoritative end-to-end execution.

Tests

.github/scripts/test_retire_superseded_windows_sync_prs.py covers:

• closing only older same-repository, main-targeting, exact-semver sync PRs;
• skipping all cleanup when the current PR cannot be confirmed;
• continuing after an individual close failure; and
• treating PR-list/API failure as non-blocking.

Failure class (fixes)

Failure-Class: new

Failure-class transition narrative (only when needed)

The new class is FC-superseded-windows-sync-pr-lifecycle. The violated contract is that Windows version-sync PRs are mutable release bookkeeping: once a replacement version PR exists, older versions must no longer remain as competing review candidates. The canonical guard is the current-PR confirmation plus strict semantic-version filtering in .github/scripts/retire_superseded_windows_sync_prs.py, backed by its focused test suite and manifest route. Evidence is #10727 and the nine accumulated open sync PRs documented there (#10419, #10513, #10525, #10533, #10653, #10684, #10716, #10718, and #10723).

New guards (only when adding a check or ratchet)

This guard would have caught the accumulation recorded in #10727. It is workflow-specific because only the Windows tag-to-main version-sync workflow owns this PR lifecycle; making it a shared primitive would broaden mutation authority without another consumer.

[Git-on-my-level]

Thanks for tightening up the Windows release sync lifecycle here. I reviewed the workflow/script diff and ran the focused helper tests locally from this head (python3 .github/scripts/test_retire_superseded_windows_sync_prs.py), which passed.

I’m not formally approving because this changes release/workflow automation with pull-requests: write, and the current GitHub checks are not green. The helper is deliberately scoped to same-repository, main-targeting release/windows-vX.Y.Z PRs and does not delete branches/tags/releases, which looks like the right safety shape. Before merge, I’d still like human maintainer sign-off on the workflow behavior and either a green rerun or maintainer confirmation that the failing Desktop Swift suite is unrelated/flaky.

One minor operational note for the maintainer review: the gh pr list --limit 200 bound means cleanup is best-effort if the open PR queue grows beyond that window, but the script fails closed by skipping cleanup unless the current sync PR is found, so I don’t see that as a release blocker.

---

by AI on behalf of David — if you need David’s attention urgently, please @Git-on-my-level and escalate with need human response.

[tianmind-studio]

Rebased onto current main, which includes the PTT input-probe liveness fix from #10742. The previously failing Desktop Swift contract now passes on head eb38c899f4, and all current checks are green. The rebase did not change the release-sync behavior in this PR.

[Git-on-my-level]

Thanks for the rebase/update. I rechecked this head (eb38c899f4) and ran the focused helper test locally:

• python3 .github/scripts/test_retire_superseded_windows_sync_prs.py — passed (4/4)
• python3 -m py_compile .github/scripts/retire_superseded_windows_sync_prs.py .github/scripts/test_retire_superseded_windows_sync_prs.py — passed

This still looks like the right safety shape for the Windows release cleanup: the helper confirms the current same-repository, main-targeting exact-semver sync PR before closing anything, only targets strictly older release/windows-vX.Y.Z PRs, uses argument arrays around gh, and does not delete branches/tags/releases. The cleanup is also non-fatal if listing/closing fails.

I’m leaving the formal sign-off to a human maintainer because this changes release/workflow automation with contents: write / pull-requests: write. The only operational caveat I see is still the bounded gh pr list --limit 200 scan, which makes cleanup best-effort on a very large open-PR queue; because the script skips cleanup unless it confirms the current PR, I don’t see that as a blocker.

---

by AI on behalf of David — if you need David’s attention urgently, please @Git-on-my-level and escalate with need human response.

[tianmind-studio]

Closing this in favor of #10960, which implements the same Windows release-sync retirement with exhaustive paginated listing and the newer same-repository and fork-safety contracts. Keeping one workflow PR should make the remaining maintainer policy review clearer.

[github-actions]

Hey @tianmind-studio 👋

Thank you so much for taking the time to contribute to Omi! We truly appreciate you putting in the effort to submit this pull request.

After careful review, we've decided not to merge this particular PR. Please don't take this personally — we genuinely try to merge as many contributions as possible, but sometimes we have to make tough calls based on:

• Project standards — Ensuring consistency across the codebase
• User needs — Making sure changes align with what our users need
• Code best practices — Maintaining code quality and maintainability
• Project direction — Keeping aligned with our product principles and locked invariants

Before your next PR, please skim:

• PRODUCT.md — product north star
• Product invariants — locked rules (shared chat, memory tiers, agent control plane, integrations, brand)

If this was declined for direction or taste, maintainers should cite an invariant ID or open a proposed one — ask if that citation is missing.

Your contribution is still valuable to us, and we'd love to see you contribute again in the future! If you'd like feedback on how to improve this PR or want to discuss alternative approaches, please don't hesitate to reach out.

Thank you for being part of the Omi community!