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 對「上游錯了」只有兩種應對，都不夠：
idd-edit —— 就地改單一 issue 的文字。但問題常是結構性的：scope 切錯、artifact 之間失同步、多個 issue 糾纏需要重切/重組。改一個 issue 的字不會把修正 propagate 到已經建在它之上的 diagnosis / spec / PR。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」：
每一次都是「人工發現 + 手動回頭修 + 補 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 了什麼、重做了什麼」的紀錄。
Current Status
Phase: diagnosed
Last updated: 2026-07-17 by /idd-diagnose (attended batch)
Key Decisions
- 維持 deferred（H-cluster 裁決）— Spectra when triggered（≥2 次實際 cascade）
Problem / 動機
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 對「上游錯了」只有兩種應對，都不夠：
idd-edit—— 就地改單一 issue 的文字。但問題常是結構性的：scope 切錯、artifact 之間失同步、多個 issue 糾纏需要重切/重組。改一個 issue 的字不會把修正 propagate 到已經建在它之上的 diagnosis / spec / PR。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」：
## Diagnosis > ### Strategychecklist 在走完 Spectra（非 idd-implement）後變成 stale snapshot —— 工作做完了但那 7 個- [ ]從沒被勾，idd-closegate 因此擋住，得補一個 superseding## Implementation Complete才過。上游 artifact 與下游現實失同步。byte-equivalentacceptance criterion，到 apply 才發現根本不可行，被迫 mid-flow 修 spec + design。一個上游假設錯，design/tasks 全部得跟著改。每一次都是「人工發現 + 手動回頭修 + 補 audit」，沒有 first-class 的重整路徑。
idd-reorganize 可能要處理的（open，留給 discuss）
Open questions
idd-reorganize是新 skill 還是idd-edit的擴充 mode？（IDD 反模式：「不在沒見過 N instance 之前抽 abstraction」—— 但本 session 已提供多個 instance）Impact
Current Status
Phase: diagnosed
Last updated: 2026-07-17 by /idd-diagnose (attended batch)
Key Decisions