State in the README that accepting a review does not merge the work - #171
Merged
Merged
Conversation
Quickstart step 5 read as though accepting landed the change: a first-time user on a no-remote project accepts, checks the repo, and finds main untouched. Accept is a pure state transition and stays that way; what was missing was the sentence saying so, and naming what does land the work on each path. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01PDRHqMspvgbNVVP6vvJikF
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.
Quickstart step 5 read as success while nothing had merged: a first-time user
on a no-remote project dispatches, reviews with
o, pressesaccept → done,then finds
mainbyte-identical to before. Accepting is a pure voro-core statetransition and stays one — what was missing was the README saying so, and
naming what actually lands the work on each path.
Step 5 now carries a second paragraph, directly after the reject sentence,
stating that accepting records your verdict and completes the task but merges
nothing; that on a GitHub-reviewed project the work lands when its pull request
is merged (usually already done, with the merged diff in front of you); and
that on a project with no remote the work stays on the branch the agent
reported — recorded on the task, printed by
voro show <id>asbranch:— andlands with one command in the project checkout,
git merge <branch>.Documentation only:
README.mdis the sole file changed, in the README's ownprose voice and at the altitude of the surrounding steps. No CLI cleanup offer
is documented (the TUI/locked-worktree gaps stay with task #451), and
voro --helpis untouched. Verified withcargo test --workspace: 468 + 389 +1 tests pass, 0 failures.