docs: issue 已 closed 但事情還要做 — 缺 documented reopen / resume-implement 路徑

[kiki830621]

Problem

使用者跳過 idd-implement 直接結案後，想回頭實作時不知道該怎麼做，IDD 也沒有 documented 的重啟路徑。maintainer 當下的回覆是「你可以問問看AI要不要重啟」— 把判斷丟回給 AI，沒有 canonical 答案。

Original text（Telegram 私訊，2026-07-08 15:05–15:08。對話對象為 IDD 早期使用者，以 K 代稱 — 見文末 Privacy note）：

15:05 K：那我前陣子有個問題跳過implement直接結案了
15:05 K：要再開啟重新implement嗎
15:05 Che：如果她覺得不需要做事情的話，可能直接跳過，但如果要修正的話就會需要implement，你可以問問看AI要不要重啟
15:05 Che：我之後多花一點時間寫說明好了

Type

docs

Expected

使用者遇到「issue 已 closed，但事情其實還沒做完 / 後來發現要做」時，有一條寫下來的路徑可循。至少要回答：

1. 該 gh issue reopen 原 issue，還是開新 issue 引用舊的？判準是什麼？
2. reopen 之後從哪一步接？重跑 idd-diagnose，還是直接 idd-implement？
3. 原本的 closing summary 怎麼處理 — 留著（audit trail）還是標記為 superseded？

Actual

• 全 plugin 文件 grep reopen → 只有 3 種無關命中：idd-implement:684 的「不要 reopen → re-close，這是 noise」（講的是 auto-close trap 的復原，不是本情境）、以及 #37 / #41 的「reopen criteria」（指那兩張 tracker issue 自己的重啟條件）
• 沒有任何一處描述 issue lifecycle 的 reopen 路徑
• idd-close 有兩層 checklist gate（Step 0 結構 + Step 1.6 語意）擋「還沒做完就關」，但那是 close 當下的防線。對於「當時判定不用做、事後發現要做」這種合法的延後改變主意，沒有對應機制
• 現況等於：每次都由當下那個 AI session 即興決定，同一個使用者兩次遇到可能拿到不同答案

Impact

• IDD 的核心價值是 audit trail。「怎麼從 closed 回到 in-progress」沒寫下來，這段轉換就不會留下一致的紀錄形狀
• 使用者傾向保守 → 開一張新 issue 但不引用舊的 → 同一件事散在兩處，三個月後看不出關聯
• 與 #200（idd-reorganize — upstream artifact 錯誤後的 re-baseline）相鄰但不同：feature: idd-reorganize — first-class re-baseline when an upstream artifact (issue/diagnosis/spec) was wrong and cascaded downstream #200 處理的是「上游 artifact 本身就錯了、需要重打地基」；本 issue 處理的是「artifact 沒錯，只是當時判定不用做事」。diagnose 時應確認兩者是否該合併處理

Suggested scope（供 diagnose 參考，非定案）

最小形式可能只是 README 或 references/usecase-routing.md 加一列：「issue 已關但事情還要做 → gh issue reopen #N → /idd-comment --type note 說明為何重啟 → 從 diagnose 或 implement 接」。不一定需要新 skill。

---

Privacy note

原始來源為第三方 Telegram 私訊。逐字內容原樣保留（IC_R007），但對話對象的真名以 K 代稱 — 本 repo 為 public，第三方真名不必要地進入公開 issue 不符 privacy-scrubbing 紀律。若 maintainer 認為應具名，可自行 edit 補回。