fix(pstack): accept PRs without checks

[liush2yuxjtu]

Why

watch-pr --status-only retries forever when a mergeable pull request has no configured checks. gh pr checks reports that no checks exist, and the GraphQL rollup is empty, but resolveChecks treats every empty result as a query failure.

Scope

• Adds failing coverage for empty fast-path and GraphQL check results.
• Lets CheckRead.checks and CiBase.all represent a valid empty check set.
• Accepts empty checks only when the fast path returns valid empty JSON or gh returns its exact no-checks message, and the GraphQL rollup is also empty.
• Preserves fail-closed behavior for credential and unrelated exit-1 errors.

Tradeoffs

The no-checks detection depends on the current gh stderr message. If gh changes that text, the watcher fails closed and reports a query blocker instead of treating an error as clean CI.

Blast Radius

The change affects PRs with zero checks. PRs with passing, pending, failed, or hidden GitHub rollups keep the existing paths. No plugin prompt or workflow text changes.

Verification

Before the fix, three focused tests failed with ChecksUnavailable.

After the fix:

• bun test watch-pr passed 42 tests.
• bun run typecheck passed.
• A live watch-pr --status-only run against liush2yuxjtu/pi-debug-mode#2 returned a status table instead of RETRY before a later GitHub API TLS timeout made the external check unavailable.
• git diff --check passed.

---

Note

Medium Risk
Changes check-resolution semantics for zero-check PRs and relies on matching gh’s no-checks stderr; wrong matching could misclassify errors as clean CI or vice versa.

Overview
Fixes watch-pr treating “no CI checks on this PR” as ChecksUnavailable, which caused endless RETRY on mergeable PRs with zero configured checks.

resolveChecks now returns an empty check list when the GraphQL rollup is empty and the fast path confirms no checks—either valid empty gh pr checks JSON or exit code 1 with GitHub’s no checks reported on the … branch stderr. Unrelated exit-1 errors (e.g. integration access) still fail closed.

CheckRead.checks and CiBase.all are typed as readonly Check[] instead of NonEmpty, so an empty set is valid. Policy snapshots can classify those PRs as ci-clean instead of erroring.

Tests cover dual-confirmed empty results, unrelated fast-path failures, and ci-clean classification.

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

[cursor]

Cursor Bugbot has reviewed your changes using high effort and found 1 potential issue.

^{Bugbot Autofix is ON, but it could not run because the branch was deleted or merged before autofix could start.}

^{Reviewed by Cursor Bugbot for commit 877e9c1. Configure here.}

[cursor]

Empty checks can mark CI ready

High Severity · Logic Bug

resolveChecks now treats a currently empty fast path plus empty rollup as a settled check set. GitHub reports that same empty pair after a new HEAD is pushed, before check runs exist. readSnapshot then marks CI ci-clean, so drive mode can emit terminal READY and stop before workflows start.

Additional Locations (1)

• pstack/skills/poteto-mode/scripts/watch-pr/types.ts#L90-L118

 

^{Reviewed by Cursor Bugbot for commit 877e9c1. Configure here.}