[kixelated]

Finishes quest/m0/queue-watcher/pick.md: on a base with GitHub's merge queue, quest merge <pr> --land <sha> enqueues the pinned head into the queue. GitHub's own records of the pick are what the queue watcher reads.

Summary

• Enqueue. On a merge-queue base, land (src/cli/hold.ts) hands off to pick:
  • When required checks may still be pending (BLOCKED, UNKNOWN), it arms auto-merge bound to the head. If an UNKNOWN PR turns out ready ("clean status"), it falls back to enqueueing.
  • Otherwise it calls enqueuePullRequest with expectedHeadOid.
  • enqueuePullRequest joins the GitHub client's confirmable pull-request mutations, so a dropped response is confirmed from mergeQueueEntry instead of being repeated blindly.
• Heads behind the base. A merge-queue base no longer gets the behind/diverged comparison, because the queue builds each PR on the current base. Bases with neither a queue nor the quest land check keep it.
• Refused picks fail. If GitHub refuses to enqueue the head (for example, the base moved into a conflict after /quest-merge checked it), quest merge exits 3 with "GitHub refused to enqueue <sha> (…); fix the PR, for example with /quest-iterate, and land it again".
  • A head that moved in the meantime is refused as moved.
  • If the PR is already queued, as when a landing is repeated, it stays quiet.
  • Errors that fault the token rather than the PR (FORBIDDEN, NOT_FOUND, INSUFFICIENT_SCOPES, INTERNAL, or any HTTP failure) pass through unchanged. To tell these apart, GraphQL errors now throw GitHubGraphQLError with their types. The message is unchanged.
• No pick comment. quest posts no marker of its own (the design change below). Queue removals now reconciles picks from open PRs' AddedToMergeQueueEvent/RemovedFromMergeQueueEvent timeline items and autoMergeRequest, reading many PRs per GraphQL query. Its trust signal is the enqueuer or enabledBy, which GitHub limits to writers.
• Bad picks narrowed. Bad picks becomes [S]: the watcher enqueues a pick whose auto-merge is armed on a ready PR that GitHub never queued (community#209348), at the head enabledHead (src/cli/status.ts) says auto-merge was armed on. It drops the local driver merge and the CI-failure parking it had absorbed. Its Required is now Queue removals.
• Quest tree. pick.md is deleted. The epic README's Plan records the new decision prompt in place of "Picks GitHub refuses to enqueue". land-fixer/README.md and land-fixer/pr-signal.md no longer say Bad picks handles refused picks.
• Docs. The README landing section and quest merge --help describe the queue path and the refusal.
• Merged origin/main, including moq-dev/quest#347's merge-method selection. A queue base takes named ?? "merge" for armed auto-merge and warns only for an explicit non-merge method, as feat(merge): close quest merge --land's gaps #347 does.

Design change

Decided by the maintainer on 2026-11-02 through /quest-plan, and recorded in this comment and the epic:

• Pick record:
  • ✅ GitHub's records only. Drop the comment and pick.ts. The watcher reads queue events and auto-merge state. A pick GitHub refuses fails the command, and /quest-merge recommends /quest-iterate as it does today. bad-picks.md shrinks to enqueueing PRs with auto-merge armed that GitHub never queued (community#209348).
  • Comment only on refusal
  • Keep the comment on every pick

This supersedes the brief's 2026-11-01 "the watcher fixes refused picks", and with it this PR's earlier pick comment, its warn-and-exit-0 path, and choices 1, 4 (as a warning), and 5 from the first round.

Choices made without asking

1. The quest:merge release bullet is moot. Since moq-dev/quest#326, nothing releases a label when the queue drops a PR (dequeued is gone), so there is nothing left to change.
2. Enqueue vs. auto-merge split by mergeStateStatus. Only BLOCKED/UNKNOWN arm auto-merge. BEHIND and DIRTY go straight to enqueuePullRequest: auto-merge can't reliably be armed on a conflicting PR, and an explicit refusal now fails the command with a next step. GitHub also often fails to move auto-merge PRs into the queue (community#209348), another reason to enqueue directly when the PR is ready.
3. Which enqueue errors get the "fix the PR" refusal. Every GraphQL error does, except the token/request types listed above. GitHub's mergeability refusals are often untyped, so an allow-list of refusal types would miss them.
4. assets/skills/merge.md (two lines). I re-checked the earlier phrase edit against the command, and it is still accurate: a queue base skips the behind check. The line before it ("On an ungated base with auto-merge disabled, it refuses") was also wrong for queue bases, since feat(merge): close quest merge --land's gaps #347 checks the setting only without a queue, so both now say "without a merge queue". I also added a line for the design decision: on a queue base, a head GitHub refuses fails, so recommend /quest-iterate. AGENTS.md reserves skill edits for user requests; revert these if the design change didn't mean to cover them.
5. An armed pick whose own checks fail, or that turns conflicting, is left alone. I read the narrowed scope this way, and bad-picks.md says so: such a PR needs /quest-iterate and a new pick.

Checks

• nix develop -c just check: passed.
• nix develop -c just test: passed (880 passed, 2 skipped; Worker 432 passed).
• quest check --base origin/main: passed (85 documents ok).

Suggested follow-ups

• The kix.quest Worker's landPullRequest (cloudflare/src/github/service.ts) still lands a merge-queue base by arming auto-merge, even on a ready PR. It never calls enqueuePullRequest, so it relies on the watcher's armed-but-never-queued fallback (community#209348). Worth a quest to share quest merge's queue path.

Review

• Reviewer: Codex harness, gpt-6.1-sol, medium effort (quest review --new --base origin/main, session 01a19a1f-d346-7712-a351-bab893639c84, round 1 after the design change).
• Reviewed head: cfb2ba3d875468a3bb517e10c784e4c12701e878.
• Findings: none.

🤖 Generated with Claude Code

(Written by Claude Opus 5.5)

[coderabbitai]

Important

• Trigger review

This repository does not receive automatic reviews because it has fewer than 10 stars.

Run configuration

• Source mode: Auto
• Repository: Unavailable
• Branch: Unavailable
• File: No configuration file from this repository applied
• Commit: Unavailable
• Layers: Organization UI
• Review profile: CHILL
• Plan: Advanced
• Run ID: b5c22f0e-a0b1-4e76-acdd-4d38675a9904

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

Share

• X
• Mastodon
• Reddit
• LinkedIn

[kixelated]

Design change: picks are recorded only in GitHub's own records (maintainer, 2026-11-02, /quest-plan).

• Pick record:
  • ✅ GitHub's records only. Drop the comment and pick.ts. The watcher reads queue events and auto-merge state. A pick GitHub refuses fails the command, and /quest-merge recommends /quest-iterate as it does today. bad-picks.md shrinks to enqueueing PRs with auto-merge armed that GitHub never queued (community#209348).
  • Comment only on refusal
  • Keep the comment on every pick

Reasons:

• For queued picks, GitHub already keeps a durable, writer-authenticated record. AddedToMergeQueueEvent and RemovedFromMergeQueueEvent give the enqueuer (who must have write access), the head before removal, and the reason, and autoMergeRequest gives enabledBy/enabledAt for picks waiting on checks.
• Auto-merge can't reliably be armed on a conflicting PR, and on merge-queue bases enabling it returns HTTP 422 unless every requirement is met (community#190610, community#50327).
• /quest-merge already refuses heads with failing checks or conflicts, so a refusal only happens if the base moves between that check and the enqueue.

This replaces the 2026-11-01 epic decision "Picks GitHub refuses to enqueue: ✅ The watcher fixes them". The review session restarts with quest review --new.

(Written by Claude Opus 5.5)