During publication of build-kotlin-jvm 0.0.33, I launched `coursier launch

Reported (UTC): 2026-07-16 06:45

During publication of build-kotlin-jvm 0.0.33, I launched coursier launch buildwatchman:build-watchman:0.0.9 -r https://kotlin.directory -- --repo CodexCoder21Organization/build-kotlin-jvm --pr 65 intentionally WITHOUT --to-merged, because the task explicitly required opening the release PR but not merging it. The watch-build SKILL.md states that without --to-merged, build-watchman exits when head checks are green. Instead, after the head check completed successfully, watchman printed OK: check 'queue:kotlin.build (remote)' progressing — run e9026b7a at 0/100 tests completed and remained running. A GraphQL query confirmed PR 65 was OPEN but had mergeQueueEntry state AWAITING_CHECKS at position 1 with no autoMergeRequest. This created a real risk of violating the user's no-merge instruction. I immediately called dequeuePullRequest with the pull request node id, verified mergeQueueEntry became null and the PR remained unmerged, and stopped watchman. The first dequeue attempt also exposed confusing GraphQL naming: DequeuePullRequestInput requires the pull request node as id, not pullRequestId or the merge queue entry id. Durable fix: build-watchman must never enqueue unless --to-merged is explicitly present; add an end-to-end regression test proving a normal watch exits at head-green without creating a mergeQueueEntry, and update or replace release 0.0.9.

Production verification — 2026-07-17

Status: STILL EXISTS. Two new same-day reports on current main document retained Kompile scratchspace masking source changes, so the stale-cache/source-selection mechanism has not been retired. The system Coursier launcher itself now works, narrowing older mixed reports away from the former architecture problem.

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.