bug: idd-close Step 6.7 的 worktree GC — exit 0 同時代表「清掉了」與「沒東西可清」

[kiki830621]

Problem

idd-close Step 6.7 的 worktree GC 呼叫 scripts/idd-worktree.sh cleanup <N>，並依 exit code 判斷結果：

| Worktree 移除成功 / 本來就不存在 | `0` | ✅ 靜默（idempotent no-op 也算成功） |

這兩件事在 exit 0 裡不可區分，而它們的後續動作完全相反。 skill 自己的表格把它們寫在同一列，等於承認呼叫端拿不到足夠資訊。

實例（PsychQuant/plaud-mcp-connector#44，2026-08-17）：

$ bash idd-worktree.sh cleanup 44 --repo-root /path/to/repo
rc=0

$ git worktree list
/path/to/repo                                        ff65082 [main]
/path/to/repo/.claude/worktrees/idd-44-port8199-docs 6811d87 [worktree-idd-44-port8199-docs]   ← 還在

rc=0，skill 判定「靜默成功」，worktree 原封不動留著。

Root cause

helper 找的是 .claude/worktrees/idd-<N>/，而該 worktree 的實際目錄名是 idd-44-port8199-docs——它是 harness 的 EnterWorktree 建的，不是 idd-worktree.sh create 44 建的，命名慣例不同。名稱不匹配 → 找不到 → idempotent no-op → exit 0。

idd-implement Step 0.4 的 escalation 路徑確實呼叫 idd-worktree.sh create，所以名稱會對得上；但背景 job / harness 自身的 worktree 隔離（EnterWorktree）產生的目錄不在該慣例內，而那條路徑同樣會走到 idd-close Step 6.7。

Type

bug

Expected

cleanup 的 exit code 應區分：

情況	建議 code
找到並成功移除	0
找不到符合的 worktree（no-op）	獨立 code，或至少 stdout 印一行可判讀的訊息
dirty-refuse	5（現行，正確）

呼叫端（Step 6.7）據此在 no-op 時印一行 note: 沒有找到 idd-<N> 的 worktree（可能由其他機制建立），而不是靜默當成清理完成。

idd-verify Step 1.55 的 merge-completeness gate 已經有這個紀律的正確版本——「Skip 一律 VISIBLE：…印一行 note，不留零 output（DA-1：silent skip 與 "ran clean" 無法區分是原本的缺陷）」。同一條原則沒有套用到 Step 6.7。

Actual

exit 0 同時代表「清掉了」與「沒東西可清」，呼叫端無法分辨，orphan worktree 靜默留存。

Impact

• scripts/idd-worktree.sh（cleanup 的 exit code 契約）
• skills/idd-close/SKILL.md Step 6.7（結果判讀表）
• 使用者流程：任何 worktree 目錄名不是 idd-<N> 的情況，包括 harness EnterWorktree 建立的

補充：實務上的後果不大，但方向不對

orphan worktree 只是磁碟上的目錄，idd-worktree.sh list 隨時能 surface。真正的問題是回傳值在說謊——skill 的 log 會顯示 GC 成功，而 GC 沒有發生。下一個讀 log 的人（或 agent）沒有理由懷疑它。

Source: surfaced during /idd-close execution on PsychQuant/plaud-mcp-connector#44（2026-08-17）。當次由人手動 git worktree remove + git branch -d 完成清理（branch 已全數併入 main、工作樹無未提交變更，確認後才刪）。