watchpr: only alert on mergeability lost after the baseline

Track mergeability across the whole run and decode it as a tri-state, so a PR already conflicted when watching starts is polled on instead of reported.
2026-09-26 18:45:48 +10:00
parent 0cf41409f1
commit 6988be9ff3
6 changed files with 298 additions and 51 deletions
@@ -220,6 +220,12 @@ wrapped per stage (login / read denied / write denied) via `ErrVaultDenied`.
  half-finished (`rebase-merge`, `MERGE_HEAD`, `CHERRY_PICK_HEAD`, …). A directory
  whose backing repo is gone is deleted outright, but only ever inside the
  worktree root.
+- `watchpr` alerts on changes, not on conditions: the baseline snapshot is a real
+  read, so a PR that is already conflicted or already CI-failing when watching
+  starts is polled on rather than reported. Mergeability is the one rule needing
+  a run of observations (`prWatch`), because a conflict must both persist for two
+  polls and follow a mergeable one; Gitea's `mergeable` is tri-state (absent/null
+  = not yet computed) and unknown counts as neither answer.
 - CI "combined status" comes from `/commits/{sha}/status`; an empty head SHA
  yields an empty state without an API call.
 - Gitea backs every PR with an issue of the same number and serves comments from