Skip to content

Worktree/project-root path split causes .planning/ file duplication and merge conflicts #47

Description

@skytect
Human Noteodd conflict happened during merge due to conflicting .planning files
Version6.0.0
Skillexecute-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

  1. /rapid:start-set (creates worktree at .rapid-worktrees/{setId}/)
  2. /rapid:execute-set (executes waves, writes completion markers)
  3. /rapid:review + /rapid:bug-hunt (bugfix agents update markers on set branch)
  4. /rapid:merge -- add/add conflicts in GAPS.md, wave-1-PLAN-DIGEST.md, DEFERRED.md

Root Cause / Suggested Fix

Full causal chain

  1. execute-set skill resolves worktree path, orchestrator cds into worktree to run executor
  2. 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
  3. Orchestrator tries git add .planning/sets/{setId}/WAVE-1-COMPLETE.md -- fails, file doesn't exist relative to worktree cwd
  4. Orchestrator tries git add with absolute project root path -- fails, path is outside worktree repo
  5. Orchestrator realizes the problem, copies files from project root into worktree, commits them to set branch
  6. Stale copies left at project root as untracked files on main's working tree
  7. Bug-hunt runs, bugfix agents update GAPS.md and wave-1-PLAN-DIGEST.md on the set branch (newer versions)
  8. 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
  9. /rapid:merge runs merge execute, which calls mergeSet()
  10. mergeSet() pre-merge cleanup detects untracked .planning/ files, commits them all to main
  11. 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

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    ai-authoredIssue was written with AI assistancebugSomething isn't working

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions