wayfinder: step 4 reads as checks-before-conflict, so a conflicted PR is watched twice #1243

Skill

wayfinder

Harness and version

Claude Code 2.1.295, installed as a plugin (vendored mirror of mattpocock/skills at v1.3.1).

Model and effort

Opus, high effort. Context was roughly half full when it happened; it has also happened on a near-empty context, so it does not look context-dependent.

What happened

Step 4's resolution bar is read as "checks first, conflict second", because that is the order the sentences are in:

the ticket is not resolved while that request is red or conflicted: green means every check or pipeline has run and concluded successfully, conflict-free means the forge itself reports no merge conflict (GitHub: mergeStateStatus is not CONFLICTING/DIRTY; GitLab: the merge request's own merge status is not blocked by a conflict). Watch the checks or pipeline to completion, fix what fails, push the fix, and watch again. A conflict is resolved here rather than reported: merge the default branch into the branch, [...]

"Red or conflicted" is one undifferentiated condition, and the first instruction after it is to watch the checks. So on a conflicted pull request the session did this, repeatedly across several runs:

gh pr checks <n> --watch     # no checks are ever reported; ends at the timeout
gh pr view <n> --json mergeStateStatus   -> CONFLICTING
git merge origin/main ; resolve ; push
gh pr checks <n> --watch     # the real suite, waited out a second time

The first watch cannot succeed: GitHub schedules no check run at all for a pull request whose mergeStateStatus is CONFLICTING or DIRTY, so the watch is not waiting for a pending suite, it is waiting for a suite that was never queued, and it ends at whatever timeout the caller gave it. Then the conflict is resolved and the whole suite is waited out again. On a suite in the 5-6 minute range that is two waits plus a dead timeout, where one wait was enough.

What you expected

That the conflict is cleared before the checks are read, with the order stated rather than left to the reading order of the two halves of the bar. The line that says otherwise is step 4's "Watch the checks or pipeline to completion, fix what fails, push the fix, and watch again", which currently precedes "A conflict is resolved here rather than reported".

Locally this was fixed by moving the conflict half in front and naming the reason, roughly:

A conflict is resolved before the checks are watched, always: a forge schedules no check run for a conflicted request, so a watch started first waits out its own timeout on a suite that was never queued, and the real suite then has to be watched a second time once the merge commit lands. Conflict first, then one watch.

with the check-watching sentence moved after the merge is pushed, prefixed by "Only once the forge reports the request conflict-free".

Reported rather than sent as a pull request, since this repo does not take external ones.