build-watchman 0.0.12 reports all-success check suites as 'completed with failures' and exits,

Reported (UTC): 2026-07-16 10:02

build-watchman 0.0.12 reports all-success check suites as 'completed with failures' and exits, making --to-merged unusable for head-check gating

What was being attempted: Shepherding CodexCoder21Organization/BuildTestEmbedded#334 and CodexCoder21Organization/kompile-core#221 to MERGED with 'coursier launch buildwatchman:build-watchman:0.0.12 -- --repo <r> --pr <n> --to-merged' (the watch-build skill's preferred path), 2026-07-16 ~09:57-10:00 UTC.

What went wrong: In both runs watchman immediately printed a false terminal PROBLEM and exited. For kompile-core#221 head 5277c660 it printed 'PROBLEM: checks ... completed with failures (check suites: 79830226196,79830245573,79830246321)' ��� but 'gh api repos/CodexCoder21Organization/kompile-core/commits/5277c660/check-suites' shows ALL THREE suites 'completed success' (kotlin-build-ci-test + 2x GitHub Actions). Same false claim for BuildTestEmbedded#334 head 18e7c1a9 suite 79832710651 (completed success, reported as failure). Additionally, when the PR was already enqueued by the operator, watchman's own enqueue attempt is rejected ('Pull request is already in the queue') and it treats that as a PROBLEM and gives up instead of proceeding to watch the existing queue entry.

Impact: --to-merged cannot be trusted to shepherd a PR whose checks are green: it exits within seconds on a healthy PR, silently leaving nothing watching (the exact 'watcher that has exited is not watching' failure the skill warns about). Operators fall back to manual queue polling.

Workaround used: Verified suite conclusions directly via the check-suites API, enqueued via GraphQL enqueuePullRequest myself, and monitored queue entries manually on a 10-minute cadence.

Suggested durable fix: In build-watchman (repo CodexCoder21Organization/build-watchman), fix the suite-conclusion aggregation for the multi-suite case ��� it appears to mis-classify success conclusions (possibly treating any non-null conclusion set containing 'success' as failure, or misreading stale suite objects) ��� and make 'already in queue' a benign CHANGE that transitions into watching the existing mergeQueueEntry rather than a terminal PROBLEM. Add a regression test with a head commit carrying 3 all-success suites.

---

Production verification — 2026-07-17

Status: STILL EXISTS. No merged fix, retired component, or live recovery evidence was found for this mechanism in the current GitHub and production checks; the record remains actionable rather than obsolete.

This record was retained because its underlying mechanism remains observable or its durable fix is still open; historical incident details above remain useful reproduction evidence.