Files
Trevin Chow 0ad8d64205 fix(ce-work): tighten worktree cleanup safety and reduce step density
Self-review surfaced four follow-ups on the worktree-isolated post-batch
flow that landed in 666c6691:

1. Step 6 was a single dense bullet covering five concerns (worktree
   removal, lock override, branch deletion, fallback path derivation,
   `--show-toplevel` rationale). Split into three sub-bullets, one
   command each.

2. `git worktree remove --force --force` and `git branch -D` together
   bypass git's "uncommitted changes" check, "is this worktree locked"
   check, and "is this branch merged" check. If a future flow change
   ever invokes cleanup before merging, the work would silently
   disappear. Switched to `git worktree unlock <path>` then plain
   `git worktree remove <path>` (overrides only the lock, not other
   safety checks), and `git branch -d <name>` (lowercase: refuses
   unmerged branches). All three commands fail loudly if state is
   wrong rather than discarding work.

3. Removed the cross-platform fallback path derivation
   (`dirname "$(git rev-parse --path-format=absolute --git-common-dir)"`).
   It only applied to a hypothetical platform that exposes worktree
   isolation but doesn't return the worktree path — no platform we
   target hits that path. Codex/Pi already use the shared-directory
   fallback, where worktrees aren't created at all.

4. Trimmed the trailing audience-enumeration sentence from Phase 2's
   "Parallel subagent mode" note. The bullet split above already
   covers commit ownership; restating "applies to inline, serial,
   worktree-isolated subagents, and shared-directory orchestrator
   commits" reads as defensive boilerplate.

Stable/beta sync: applied identically to ce-work and ce-work-beta.
2026-04-25 23:14:30 -07:00
..
2026-04-22 14:21:19 -07:00