v0.6.0

Wake your session on CI failures and merge conflicts — no foreground polling, no comment-channel injection.

Note

ready now arrives one poll interval later than it used to. That is the cost of the fix below, and it is deliberate. PR_SENTINEL_GREEN_POLLS=1 restores the old timing along with the bug.

Highlights

A green PR is no longer automatically a ready one. ready was decided from gh pr checks buckets alone, and those buckets only contain checks that exist. A required check whose workflow never registered — a path-filtered heavy gate on a PR that opened docs-only — produces no row, so pending_count is zero because the check is absent, not because it reported. In the window right after a push, nothing has registered yet and the whole PR reads green. ready now requires mergeStateStatus != BLOCKED and a streak of consecutive green polls, so an unregistered run turns up as pending on the second one.

A new terminal blocked event, for green PRs that aren't going anywhere. BLOCKED doesn't say which requirement is unmet, and an outstanding approval reads identically to a missing required check — so gating ready on it outright would mean a green PR in a review-gated repo burns the whole budget and wakes with timeout. The two are separated by persistence instead: after PR_SENTINEL_BLOCKED_POLLS consecutive green-but-BLOCKED polls the watcher wakes you with blocked, naming both candidate causes. The Stop hook treats it as concluded — both need a human, neither can be waited out.

A job marked continue-on-error: true no longer wakes you forever. It fails its own check row — gh pr checks reports bucket=fail, indistinguishable from a real failure — but does not fail the workflow run. The run conclusion was the only place the distinction survived, and it was never read, so an intentionally advisory job woke the session on every poll of every PR. Failing checks are now resolved to their runs and treated as passing when every one of them sits in a run GitHub concluded success. Absorption is all-or-nothing and fails safe: no Actions run behind the check, a run still in progress, or an unreadable conclusion all stay a wake.

A network blip no longer reads as revoked credentials. The watcher probed gh auth status after a gh pr view failure and treated any non-zero exit as permanent auth loss — but that probe fires in the moment most likely to break it, and gh doesn't distinguish: with the network unreachable it prints "The token in keyring is invalid." for a perfectly valid token (verified against gh 2.96). The probe is now acted on only where it is conclusive — no credentials configured at all, which gh answers from local config with no round-trip. A revoked token still gets reported, but has to fail for the whole retry horizon rather than for one instant.

Upgrading

No action required. Nothing is removed, no configuration is renamed, and the report format and additionalContext shape are unchanged.

Three changes that need no action, but will be visible.

• ready is one PR_SENTINEL_INTERVAL slower. The confirming poll is scheduled at the base interval rather than the current backoff, so the cost is bounded to one interval per genuine handoff instead of up to MAX_INTERVAL (#37).
• A new blocked / blocked_watching event can reach a session that has only ever seen ready. Any agent guidance that enumerates watcher events should learn it (#29).
• Some PRs stop waking the session that used to wake it every poll — advisory continue-on-error jobs, and gh failures during a network blip (#32, #26).

Two new knobs, both documented in Configuration:

Variable	Default	Purpose
PR_SENTINEL_GREEN_POLLS	2	consecutive green polls before ready fires; 1 decides on a single poll
PR_SENTINEL_BLOCKED_POLLS	3	consecutive green-but-BLOCKED polls before blocked fires

Everything since v0.5.0

Seven changes ship in the product; docs, test, and backlog work is left out.

New behaviour (2)

• Terminal blocked event and its blocked_watching notice, gated on PR_SENTINEL_BLOCKED_POLLS (#29)
• ready confirmed across PR_SENTINEL_GREEN_POLLS consecutive polls (#37)

Fixes (5)

• Don't wake for a failure the workflow run absorbed (#32)
• Don't call a correlated auth-probe failure permanent (#26)
• Don't nudge on a tag push, and say so when no PR number resolves (#34)
• Scope the foreground-poll deny to the harm it names: a backgrounded Bash call can't block the session, and a sleep loop around curl isn't polling CI (#36)
• Honour an inline PR_SENTINEL_OVERRIDE=1 prefix, not just an exported variable (#27)

Trust boundary unchanged

No new data source. Resolving a failing check to its workflow run reads GitHub-controlled run metadata through a link the check row already carries. There is still no comment or PR-body ingestion, no merge, and no fix outside the visible session.

Full changelog: v0.5.0...v0.6.0