[hussainph]

#909 has merged; this PR is no longer stacked. Against main it is the single VC-838 change (15 files). History of the earlier stack is kept below.

Stacked on #909 (which is itself stacked on #885). Merge after #909. git merge-tree reported a content conflict with #909 in packages/host-core/src/worktree/status.ts, because #909 wraps getWorktreeStatus's reads in readOnlyGitAsync. So this branch is #909's head plus one commit (fix(VC-838): …). Only that last commit belongs to this PR.

Defect

commitRemaining (packages/host-core/src/worktree/commit.ts) checked for conflicts only through the sequencer-marker probe (MERGE_HEAD, CHERRY_PICK_HEAD, REVERT_HEAD, BISECT_LOG, rebase-merge, rebase-apply). Some conflicts leave unmerged index entries without any of those markers: a conflicted git stash pop/apply, git merge --squash (no MERGE_HEAD for --squash) and git checkout -m. In that state, git add -A stages the conflict-marked file and marks it resolved, so the git commit that follows succeeds and <<<<<<</>>>>>>> markers get committed. On the "Commit & create draft PR" path the result is also pushed and opened as a PR. The Done-flow rail kept Commit and the commit-PR stack enabled because getWorktreeStatus reported nothing that would disable them.

Fix

• status.ts: new countUnmergedEntries(porcelain) counts porcelain v1 entries whose XY is one of DD AU UD UA DU AA UU. getWorktreeStatus now reports unmergedPaths: number, taken from the same git status --porcelain read it already did, so there is no extra subprocess.
• commit.ts: after the clean-tree no-op and before any staging, commitRemaining refuses with "This worktree has unresolved conflicts … Resolve them before committing." when countUnmergedEntries > 0. Nothing is staged and nothing is committed.
• worktree-done-flow-model.ts: Commit, "Commit & create draft PR" and "Commit & push updates" are disabled with "Unresolved conflicts. Resolve them in the terminal." when unmergedPaths > 0. Push-only actions and View PR stay enabled. If a sequencer op is also in progress, its reason is shown instead.
• ipc/contract.ts WorktreeStatusResult gains unmergedPaths. Fixtures that construct a status report gain unmergedPaths: 0.

How the regression test proves it

I ran the new tests against the original commit.ts/status.ts/worktree-done-flow-model.ts, then against the fix:

• commit.test.ts › "commitRemaining with real git" uses real git repos:
  • stash-pop conflict: the test first asserts its premise (the file contains <<<<<<<, porcelain shows UU file.txt, no sequencer marker). It then calls commitRemaining with includeUnstaged true and false. On main, the ok assertion fails: the call returned ok: true and committed the markers. With the fix it errs, HEAD does not move, and the path is still UU.
  • merge --squash conflict: the test asserts there is no MERGE_HEAD and the file has markers. On main the commit landed. With the fix it errs and HEAD does not move.
  • clean squash merge still commits as before (passes on both).
• commit.test.ts scripted cases: each of the 7 unmerged XY codes, plus includeUnstaged: false, refuses with no add/commit call. All failed on main.
• status.test.ts: unmergedPaths counts all 7 codes and ignores M/A /??. It is 0 on a failed status read. Failed on main.
• worktree-done-flow-model.test.ts: 4 new cases for the unmerged rule. 3 failed on main; the 4th, sequencer precedence, passes on both.

Local runs, all green: host-core commit, status, read, snapshot, ticket-move, agent-commands tests (286 tests). Desktop worktree-done-flow-model, worktree-glance-model, ticket-changes-panel, data-ipc tests (296 tests). vp check. host-core and desktop typecheck.

Decisions

• Structural detection only, no content scan for conflict markers. The ticket's proposed fix is the porcelain XY check. Grepping files for <<<<<<< would false-positive on files that contain marker strings on purpose (tests, docs) and block legitimate commits. The real-git tests do run against a conflict-marked file, which is the stash-pop/squash case. A file whose markers were already git added by hand is out of scope.
• The refusal applies to both staging modes. With includeUnstaged: false, git commit would already have refused on unmerged files. Refusing earlier gives the same outcome with a clearer message. The includeUnstaged: false staging semantics are unchanged.
• unmergedPaths is 0 when the status read fails. uncommitted already reports dirty in that case, and commitRemaining re-reads status and refuses or errs on its own, so the rail does not invent a conflict it cannot see.
• Sequencer reason first. When both a sequencer op and unmerged paths are present, the rail shows "Merge in progress…", because finishing the merge is the action that resolves both.
• No stash or rebase abort was added, as the ticket asked.

Not in this PR

• The CLI volli worktree status human renderer (packages/cli/src/render.ts) does not print unmergedPaths. The --json output now includes the field (additive).
• VC-787 (commitRemaining 1 MB maxBuffer) will stack on this PR.

CI history

• First run (fc42d0746): green except Check + Build. It failed on main's own react(purity) error (VC-853). After VC-294: compute the Updates status clock outside render (unbreaks main: react/purity) #923 fixed it, merging main gave a fully green run at 02bbb9834.
• Merging main at 6fd35e2 had one textual conflict, in agent-commands.test.ts. I kept VC-834: background Change Set/rail/venue/diff reads run read-only git (stacked on #885 — merge after it) #909's scriptedReadOnlyGit and main's removal of the git port. That run was red because main itself was red; VC-786: drop the removed git port from tests merged beside #908 (unbreaks main typecheck) #925 fixed it.
• Merging main at f794e5b raised a semantic conflict: main's new VC-802 scan tests scripted plain scriptedGit, but the stacked VC-834: background Change Set/rail/venue/diff reads run read-only git (stacked on #885 — merge after it) #909 reads lead with --no-optional-locks. Commit 9ad35395e gives those two tests scriptedReadOnlyGit, the same swap VC-834: background Change Set/rail/venue/diff reads run read-only git (stacked on #885 — merge after it) #909 made for its own fixtures. Re-create it if VC-834: background Change Set/rail/venue/diff reads run read-only git (stacked on #885 — merge after it) #909 is rebased onto main first.
• Flaky retry, disclosed: at 9ad35395e, Test (packages) timed out (5000 ms) on watch.test.ts "500 Done tickets merged in an earlier launch…" (VC-836). Nothing on this branch touches watch.ts or anything it calls. The test takes 3085 ms on main's CI and 2158 ms locally on this branch. I reran the failed jobs once (run 39133837114) and they passed. CI gate is green.
• Merged main at 61585d0 cleanly (head 76f78fa98). All 23 checks pass and CI gate is green (run 39261297540).

[coderabbitai]

Important

• 🔍 Trigger review

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

⚙️ Run configuration

• Configuration used: Organization UI
• Review profile: ASSERTIVE
• Plan: Advanced
• Run ID: 83876392-b0ea-40f5-ad96-3c450393f13e

• 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

_{Comment @coderabbitai help to get the list of available commands.}