Skip to content

feat: /idd-reorganize —— 上游錯誤的 re-baseline 操作 - #313

Merged
kiki830621 merged 1 commit into
mainfrom
idd/reorganize-200
Aug 13, 2026
Merged

feat: /idd-reorganize —— 上游錯誤的 re-baseline 操作#313
kiki830621 merged 1 commit into
mainfrom
idd/reorganize-200

Conversation

@kiki830621

Copy link
Copy Markdown
Member

Refs #200

使用者原話:「idd 有一個問題就是如果前面有問題的化,會對後面造成毀滅性的影響,我覺得 idd-edit 可能還不夠」

IDD 是 append-only 的鏈,既有應對都不夠:idd-edit 只改一處文字(無法傳播),idd-verify末端才抓到。

新 skill 讓傳播變成有步驟、有紀錄的操作。兩個刻意的約束:still-valid 必須寫理由(「看起來沒關係」是這個操作最常見的失效方式),紀錄要有「為什麼現在才發現」欄位。

worked example 是本 repo 的 #295 —— 七輪之後才發現 root cause 根本不在分類器而在取得層,下游全部建在錯誤前提上、靠人工回頭修。

45/45 suites 綠。

IDD 是 append-only 的鏈,上游前提一錯就被下游繼承並放大。既有的兩種應對都不夠:
idd-edit 只改一處文字(無法傳播),idd-verify 在鏈的末端才抓到(成本高且不保證抓到)。

新 skill 把傳播變成明確操作:一句話指名錯的 artifact → 機械枚舉所有下游產物 →
逐一裁定 still-valid / redo / invalidate 並附理由 → post ## Re-baseline 紀錄 →
phase 退回重做起點。

兩個刻意的約束:still-valid 必須寫理由(「看起來沒關係」是這個操作最常見的失效
方式);紀錄要有「為什麼現在才發現」欄位(那是唯一會累積成「我們的上游錯誤長什麼
樣」的資料,也正是 #144 那條 MANIFESTO 規則的證據來源)。

worked example 就是本 repo 的 #295:diagnosis 把 root cause 判在 marker 比對上,
七輪之後才發現真正的原因在 gh 的取得層、根本不在分類器 —— 下游全部建在錯誤前提上,
靠人工逐一回頭修,而那正是散文分岔連四輪復發的原因。

45/45 suites 綠(含 docs-catalog-sync 對新 skill 的登錄要求)。
@kiki830621
kiki830621 merged commit f6dd6ea into main Aug 13, 2026
1 check passed
@kiki830621
kiki830621 deleted the idd/reorganize-200 branch August 13, 2026 21:48
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant