feature: idd-reorganize — first-class re-baseline when an upstream artifact (issue/diagnosis/spec) was wrong and cascaded downstream

[kiki830621]

Problem / 動機

Original text（使用者原話）：
「idd 有一個問題就是如果前面有問題的化，會對後面造成毀滅性的影響，我覺得 idd-edit 可能還不夠，可能需要 idd-reorganize 之類的東西」
— Source: /idd-issue 互動，2026-06-29

IDD 是一條 sequential、append-only 的 pipeline：issue → diagnose → (discuss → propose → apply | plan | implement) → verify → close，每個 phase 的 artifact 都建立在前一個之上。這個結構的代價：任何上游 artifact 出錯，會沿鏈往下繼承並放大 —— issue 把問題 frame 錯、diagnosis 選錯 root cause / 寫錯 Strategy、spec 把錯誤假設凍進 proposal，下游全部繼承，越走越歪。

目前 IDD 對「上游錯了」只有兩種應對，都不夠：

1. idd-edit —— 就地改單一 issue 的文字。但問題常是結構性的：scope 切錯、artifact 之間失同步、多個 issue 糾纏需要重切/重組。改一個 issue 的字不會把修正 propagate 到已經建在它之上的 diagnosis / spec / PR。
2. idd-verify（下游） —— 靠 adversarial review 在末端抓到上游的錯。有用，但那是「鏈走到底才發現前面錯了、再回頭重做」，成本高、且仰賴 verify 抓得到。

缺的是一個 first-class 的「re-baseline / 重整」操作：當上游 artifact 被判定錯誤，能有意識地讓修正向下傳播（重 diagnose、重切 scope、invalidate 並重做依賴的下游工作、重組糾纏的 issue 群），而不是默默累積錯誤或只改一處文字。

Type

feature / enhancement（architectural / meta）

本 session 的活證據（這不是假想）

這條 #192 → #196 的 arc 反覆出現「上游 artifact 錯 → 下游 cascade」：

• stale upstream snapshot：feature: 偵測「clone 他人 repo」情境並建議非污染式 IDD setup（config 擺放 + .git/info/exclude） #192 的 ## Diagnosis > ### Strategy checklist 在走完 Spectra（非 idd-implement）後變成 stale snapshot —— 工作做完了但那 7 個 - [ ] 從沒被勾，idd-close gate 因此擋住，得補一個 superseding ## Implementation Complete 才過。上游 artifact 與下游現實失同步。
• wrong spec assumption propagated：propose 階段寫進 spec 的 byte-equivalent acceptance criterion，到 apply 才發現根本不可行，被迫 mid-flow 修 spec + design。一個上游假設錯，design/tasks 全部得跟著改。
• incomplete-upstream cascade：Migrate E1/E2 config write-back onto .claude/.idd/local.json (match config-protocol; E-TP already does) #195 第一版只遷 writer 沒遷 reader → split-brain，verify round 1 才抓到、整段重做。

每一次都是「人工發現 + 手動回頭修 + 補 audit」，沒有 first-class 的重整路徑。

idd-reorganize 可能要處理的（open，留給 discuss）

• Re-diagnose propagation：diagnosis 被判錯 → 重跑 diagnose，並標記 / invalidate 已建在舊 diagnosis 上的 spec / plan / implementation，讓它們知道要重做或 review。
• Scope re-split / re-cluster：一個 issue 其實是 N 個、或 N 個該合一 → 重切並搬移已有的 comments / commits 引用（比 umbrella-split SOP 更通用）。
• Artifact re-sync：偵測 issue body / diagnosis / spec / Implementation Complete 之間的 drift（如上面 stale Strategy snapshot），surface 並提供 re-baseline。
• Cross-spec invalidation：一個上游 spec 改了 normative 假設 → 找出 downstream 依賴的 specs / issues，標記需 consistency re-check（比現在 Layer 3 的「人工協調」更自動）。

Open questions

• idd-reorganize 是新 skill 還是 idd-edit 的擴充 mode？（IDD 反模式：「不在沒見過 N instance 之前抽 abstraction」—— 但本 session 已提供多個 instance）
• 邊界：哪些算「reorganize」（結構/傳播）vs 「edit」（就地文字）？
• 怎麼表達 / 追蹤「下游 artifact 已被上游修正 invalidate」？（GitHub 沒有原生的 artifact-dependency invalidation）
• 與既有機制的關係：umbrella-split SOP（Step 4.8）、idd-edit、idd-all-chain、Spectra 的 re-propose。

Impact

• 降低「上游小錯 → 下游毀滅性重做」的成本，把現在散落的手動補救（superseding comment、mid-flow spec amend、verify-caught rework）收斂成一條 first-class 路徑。
• 與 IDD 的 audit-trail 哲學一致：reorganize 應留下「為何重整、invalidate 了什麼、重做了什麼」的紀錄。