feat(ship): --no-cleanup flag + wire auto_cleanup Phase 3 · Closes #313

[erishforG]

무엇

parsec ship에 --no-cleanup 플래그를 추가하고, 오랫동안 호출되지 않았던 ship_cleanup() Phase 3를 ship 커맨드 핸들러에 연결합니다.

문제 1 (이슈 #313): 점진적 마이그레이션 작업(동일 ticket에 여러 번 commit + ship)을 할 때 parsec ship이 worktree를 제거해 불편함.

문제 2 (코드 갭): WorktreeManager::ship_cleanup()이 존재하지만 commands/ship.rs 핸들러에서 호출되지 않음. 리팩토링 과정에서 Phase 3 연결이 누락됨 (manager.ship()은 #[allow(dead_code)]로만 남아있었음).

왜

config.ship.auto_cleanup = true (기본값)이고 CLI help도 "removes the worktree"라고 명시하지만, 실제 ship 커맨드는 worktree를 제거하지 않는 불일치 상태였음. 이 PR이 두 문제를 동시에 해결합니다.

변경

파일	변경 내용
src/cli/mod.rs	Command::Ship에 --no-cleanup 플래그 추가, dispatch + dry-run 메시지 업데이트
src/cli/commands/ship.rs	no_cleanup: bool 파라미터 추가; Phase 3 블록: !no_cleanup이면 manager.ship_cleanup() 호출 (config.ship.auto_cleanup 여전히 존중)
src/cli/commands/stack.rs	업데이트된 시그니처에 no_cleanup = false 전달 (stack ship은 config 기본값 사용)
tests/cli_tests.rs	2개 통합 테스트: test_ship_no_cleanup_preserves_worktree, test_ship_auto_cleanup_removes_worktree

사용법

# 기존 동작 (변경 없음) — auto_cleanup=true면 worktree 제거
parsec ship CL-2428

# 새 플래그 — worktree 유지 (점진적 커밋 워크플로우)
parsec ship CL-2428 --no-cleanup   # push + PR, worktree 보존
# ... 추가 작업 후 ...
parsec ship CL-2428 --no-cleanup   # 또 push (PR 업데이트)
# ... 완료 후 ...
parsec ship CL-2428                # 마지막 ship, worktree 제거

다음 Phase 힌트

• parsec merge --no-cleanup 도 동일하게 추가 가능 (ship: add --no-cleanup flag to skip worktree removal #313 관련 UX 통일)
• stack ship 에서도 마지막 ticket만 cleanup 하고 나머지는 no-cleanup 하는 전략 가능

리스크

기존에 ship이 cleanup을 하지 않던 상태 → 이제 auto_cleanup=true 시 ship이 worktree를 제거함. 이는 원래 의도된 동작이지만, --no-cleanup escape hatch로 기존 수동 워크플로우 보호.

롤백

git revert <commit> 또는 config에서 ship.auto_cleanup = false 설정.

Test plan

• cargo build ✅
• cargo clippy -- -D warnings ✅
• cargo fmt --check ✅
• cargo test 173 tests pass ✅
• test_ship_no_cleanup_preserves_worktree: --no-cleanup 시 worktree 디렉토리 물리적으로 유지 확인
• test_ship_auto_cleanup_removes_worktree: auto_cleanup 시 worktree 제거 확인

Closes #313
@erishforG