| Human Note | odd conflict happened during merge due to conflicting .planning files |
| Version | 6.0.0 |
| Skill | execute-set, merge (also affects review, bug-hunt) |
Bug Description
When executing a set in worktree mode, .planning/ marker files end up duplicated on both main's working tree and the set branch with different content, causing add/add merge conflicts during /rapid:merge.
Steps to Reproduce
/rapid:start-set (creates worktree at .rapid-worktrees/{setId}/)
/rapid:execute-set (executes waves, writes completion markers)
/rapid:review + /rapid:bug-hunt (bugfix agents update markers on set branch)
/rapid:merge -- add/add conflicts in GAPS.md, wave-1-PLAN-DIGEST.md, DEFERRED.md
Root Cause / Suggested Fix
Full causal chain
- execute-set skill resolves worktree path, orchestrator cds into worktree to run executor
- Executor completes. Orchestrator writes marker files (WAVE-COMPLETE, PLAN-DIGEST, GAPS) to
.planning/sets/{setId}/ -- Write tool resolves this to project root absolute path because that's where .planning/ lives
- Orchestrator tries
git add .planning/sets/{setId}/WAVE-1-COMPLETE.md -- fails, file doesn't exist relative to worktree cwd
- Orchestrator tries
git add with absolute project root path -- fails, path is outside worktree repo
- Orchestrator realizes the problem, copies files from project root into worktree, commits them to set branch
- Stale copies left at project root as untracked files on main's working tree
- Bug-hunt runs, bugfix agents update GAPS.md and wave-1-PLAN-DIGEST.md on the set branch (newer versions)
- Meanwhile, review/bug-hunt/merge skills write more
.planning/ files to project root (REVIEW-SCOPE, REVIEW-BUGS, REVIEW-STATE, etc.) -- same pattern, more untracked files on main
/rapid:merge runs merge execute, which calls mergeSet()
mergeSet() pre-merge cleanup detects untracked .planning/ files, commits them all to main
git merge --no-ff rapid/{setId} -- main has stale versions (from step 2/8), branch has newer versions (from step 5/7) -- add/add conflicts
The root issue
The execute-set skill spec (lines 288, 301, 392) writes .planning/ files to a path that resolves to project root, while the orchestrator is operating in a worktree context. The git add/git commit in Step 6 (lines 535-536) then can't reach those files from the worktree. The spec doesn't account for the worktree/project-root split.
The same pattern affects other skills:
- review SKILL.md (line 324): writes REVIEW-SCOPE.md to
.planning/sets/{setId}/ from main's cwd
- bug-hunt SKILL.md (line 273): writes REVIEW-BUGS.md to
.planning/sets/{setId}/ from main's cwd
- RAPID CLI tools:
review mark-stage, review log-issue, merge update-status all write to path.join(cwd, '.planning', 'sets', setId), creating files at project root
Design question
The agent docs (rapid-executor.md line 25) say: "The .planning/ directory is at the project root (parent of .rapid-worktrees/), not inside your worktree." But execution needs these files committed to the set branch. The spec was likely written for solo mode (no worktree) and not updated when worktrees were added.
The fix depends on a design decision: should .planning/ artifacts be written into the worktree (so they commit to the set branch naturally), or should they stay at project root (and the pre-merge cleanup + Step 6 bare git add be removed)?
Evidence from conversation history
Session 57d17da1 (execute-set), lines 74-91:
- L74:
git add .planning/sets/foundation/WAVE-1-COMPLETE.md -- fails (relative path, file not in worktree)
- L76: retry -- fails again
- L83: agent says "I see, we're inside the worktree"
- L86:
git add /absolute/path/... -- fails (outside worktree repo)
- L88: agent says "The marker files were written to the main repo, not the worktree. Let me copy them."
- L89: copies from project root to worktree, commits to set branch, never cleans up project root copies
Workaround
Use -X theirs merge strategy to prefer the set branch versions when conflicts occur.
Related Issues
Co-Authored-By: Claude Opus 4.6
Bug Description
When executing a set in worktree mode,
.planning/marker files end up duplicated on both main's working tree and the set branch with different content, causing add/add merge conflicts during/rapid:merge.Steps to Reproduce
/rapid:start-set(creates worktree at.rapid-worktrees/{setId}/)/rapid:execute-set(executes waves, writes completion markers)/rapid:review+/rapid:bug-hunt(bugfix agents update markers on set branch)/rapid:merge-- add/add conflicts in GAPS.md, wave-1-PLAN-DIGEST.md, DEFERRED.mdRoot Cause / Suggested Fix
Full causal chain
.planning/sets/{setId}/-- Write tool resolves this to project root absolute path because that's where.planning/livesgit add .planning/sets/{setId}/WAVE-1-COMPLETE.md-- fails, file doesn't exist relative to worktree cwdgit addwith absolute project root path -- fails, path is outside worktree repo.planning/files to project root (REVIEW-SCOPE, REVIEW-BUGS, REVIEW-STATE, etc.) -- same pattern, more untracked files on main/rapid:mergerunsmerge execute, which callsmergeSet()mergeSet()pre-merge cleanup detects untracked.planning/files, commits them all to maingit merge --no-ff rapid/{setId}-- main has stale versions (from step 2/8), branch has newer versions (from step 5/7) -- add/add conflictsThe root issue
The execute-set skill spec (lines 288, 301, 392) writes
.planning/files to a path that resolves to project root, while the orchestrator is operating in a worktree context. Thegit add/git commitin Step 6 (lines 535-536) then can't reach those files from the worktree. The spec doesn't account for the worktree/project-root split.The same pattern affects other skills:
.planning/sets/{setId}/from main's cwd.planning/sets/{setId}/from main's cwdreview mark-stage,review log-issue,merge update-statusall write topath.join(cwd, '.planning', 'sets', setId), creating files at project rootDesign question
The agent docs (
rapid-executor.mdline 25) say: "The.planning/directory is at the project root (parent of.rapid-worktrees/), not inside your worktree." But execution needs these files committed to the set branch. The spec was likely written for solo mode (no worktree) and not updated when worktrees were added.The fix depends on a design decision: should
.planning/artifacts be written into the worktree (so they commit to the set branch naturally), or should they stay at project root (and the pre-merge cleanup + Step 6 bare git add be removed)?Evidence from conversation history
Session
57d17da1(execute-set), lines 74-91:git add .planning/sets/foundation/WAVE-1-COMPLETE.md-- fails (relative path, file not in worktree)git add /absolute/path/...-- fails (outside worktree repo)Workaround
Use
-X theirsmerge strategy to prefer the set branch versions when conflicts occur.Related Issues
Co-Authored-By: Claude Opus 4.6