Repository navigation
Conversation
Delete quest:merge and quest:ready. A session working on a PR holds the single quest:active label: quest iterate takes it, quest ready keeps it while marking the PR ready, and quest release hands it back. quest merge --land only enables pinned auto-merge, refusing while any session holds the PR; the auto-merge is the queue signal. quest land's ejection, fixer requeue, and fallback close no longer touch labels. Older quest versions' quest:iterate and quest:ready still hold a PR like any quest:* label, and their quest:merge is ignored, in one place in src/core/hold.ts. kix's merge job holds its PR with its own quest:kix label. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
|
Warning Review limit reachedYou've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. Next included review available in 51 minutes. View limit details
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. |
This was referenced Oct 31, 2026
Carry the PR's decision through main's new land code: the fixer's requeue no longer re-adds `quest:merge`, its handback and ejection no longer remove it, and the docs and tests stop describing the label. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
kixelated
enabled auto-merge (squash)
November 1, 2026 21:13
This was referenced Nov 1, 2026
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Change
The user decided on 2026-10-31 to delete
quest:merge, then alsoquest:ready. That leaves one hold label,quest:active, which means an agent is working on the PR.quest iterate <pr> [token]addsquest:activeand prints the hold token. Given a token, it keeps that hold.quest ready <pr> <token>marks the PR ready for review and drops its## Decisions neededsection. It keeps the hold and adds no label.--doneis gone, and so is the token-less take.quest merge <pr> --land <sha>adds no label. It only enables pinned auto-merge: aquest landpin, a merge queue, or a direct merge, the same paths as before. It refuses while any session holds the PR. It now rereads the PR right before landing and refuses if the PR was retargeted, the head moved, or someone took it. It takes no token and no longer runs without--land.quest releaseis unchanged.quest landno longer touches labels. Ejection only disables auto-merge. The fixer's requeue only re-enables pinned auto-merge. The fallback close only closes the PR and comments.quest status(through the shared reader), the CLI help, README, CONTRIBUTING, and the merge, review, and iterate skills. Also updated two quest files that described the label.Compatibility with older quest versions
All of this lives in one place,
LEGACY_IGNOREDinsrc/core/hold.ts. It can be deleted once the repos that pin quest have upgraded.quest:iterateandquest:ready. Both still count as holds, as everyquest:*label does. A refusal names them, and their token releases them. Passing such a token toquest iterateswaps the label forquest:active.quest:mergelabel still on an open PR is ignored, by the CLI, byquest status, and by kix. It doesn't count as a hold and is never removed. One case to know: an old-binary session that is still inside its ownquest mergetake no longer blocks new-binary sessions.quest:activeandquest:kixas holds, since they match on thequest:*prefix.kix
kix's merge job now holds its PR with its own label,
quest:kix(KIX_LABELincloudflare/src/github/service.ts). The label is stillquest:*, so local sessions respect it, and kix respects theirquest:active. kix drops its spent-merge-hold cleanup: the dequeue webhook and the 5-minute sweep already release its label once a landing ends unmerged. The runner prompt namesquest:kixas the job's own hold.Decisions
quest:kixinstead of keeping thequest:mergestring. Keepingquest:mergewould conflict with ignoring that label everywhere: local sessions would stop respecting kix holds. Recommendation: keepquest:kix.deliveris refused, which pauses it on a decision, and its oldquest:mergelabel is left behind, ignored. Merge jobs are short-lived. Handling it would spread legacy code into kix's hold, release, and land paths. Recommendation: accept it, and re-pick any affected job.quest mergetakes no token. A session that holds the PR releases it first./quest-reviewnow says to release before going on to/quest-merge. Recommendation: keep; the merge skill runs inline, never pushes, and needs no hold.quest readyrequires the token and drops--done. Its old token-less form was a take, whichquest iteratenow does. Recommendation: keep.Suggested follow-up
LEGACY_IGNOREDinsrc/core/hold.tsand its notes in README andquest iterate --help) once quest, moq, moq.pro, rind, and rust2 have moved past this change. At that point, decide whether hold labels should become the exact setquest:activeandquest:kixrather than anyquest:*label.Merge with main
Merged
origin/mainata27cacd(no rebase). Main's newquest landwork still wrotequest:merge. The daemon only ever wrote the label and never read it: it finds queued PRs by their pinned auto-merge. So the resolution carries this PR's decision through with no new design:quest land servehelp, the README's land section, and theland-park.tscomment, so they no longer describe the label.test/land.test.ts, the parked, ejected, and handback tests no longer assert on the label. The requeue tests now assert that the fixer adds none.Deployed host daemons need no migration: a
quest:mergeleft on a queued PR is ignored (LEGACY_IGNORED). The daemon stops removing it once the hosts upgrade, so stale labels may stay on such PRs. They hold nothing.Checks
just check: passedjust test(run withCLAUDE_CONFIG_DIRunset): passed, 765 CLI tests (2 skipped) and 426 Worker testsReview
gpt-6.1-sol, medium) viaquest review --base origin/main14c50e6(2 findings: in-flight kix merge jobs, refuted; base retarget, fixed in54c112d), round 2 at54c112d(0 findings).3f9fbb37abae5a10878f18a8c4423869d8aa7844, 1 finding:cloudflare/src/github/service.ts:1743, kix merge jobs in flight at deploy time are refused because their stored hold namesquest:merge. Refuted: this is the recorded decision "No migration for kix merge jobs in flight at deploy time" above, which the maintainer accepted by picking /quest-merge on 2026-11-01. Such a job pauses on a decision and can be re-picked.🤖 Generated with Claude Code
(Written by Claude Opus 5.5)