issue 內容有錯時應以 /idd-edit 就地更正，而非只追加 comment（錯誤會被當記憶繼承）

[kiki830621]

Problem

Original text:
「老師反應如果出錯的話，因為會看到記憶裡面錯誤的東西之後還會錯誤，所以如果issue裡面有任何錯誤的東西，應該要揩起/idd-edit來把他改成正確的。」
— Source: 使用者轉述老師回饋，/idd-issue，2026-09-24

Issue 是下游 skill 與日後 session 的「記憶」。錯誤的內容留在 issue 裡（即使後面有 comment 更正），之後讀它的人或 agent 仍會照錯的做。所以發現錯誤時，應該用 /idd-edit 把原處改正，不能只在後面補一則 comment。

Type

feature

Expected

• 任何 IDD skill 發現 issue（body 或 comment）裡有錯，主動提議 /idd-edit 就地更正，更正時留下 audit marker
• 至少要定義：由哪些 skill 偵測、何時觸發、是 confirm 後才改還是自動改

已定案（使用者，2026-09-24）

• 範圍：「記憶」指 issue 本身，包括正文和所有 comment
• 確定是錯的就直接換掉，不留刪除線或折疊
• Original text 引用區不改：它記錄當時實際說了什麼，要換掉的只有解讀、診斷和結論
• 備份存在 .claude/.idd/ 底下，並預設 AI 不能讀，否則錯誤內容又會污染後續判斷
• 錯誤的範圍：打錯字、事實錯誤、後來被推翻的結論，全部都算
• 備份永久保留，視為歸檔紀錄（因此進 git，不加進 .gitignore）
• issue 裡的 marker 只留備份 ID，不寫路徑
• 用 PreToolUse hook 擋讀取：AI 用 Read／Grep 讀備份路徑時直接拒絕（比照 archive-first）。實作時注意 Bash（cat、grep、git log -p／git show）也是讀取管道
• 誰判定錯誤：AI 提議，使用者確認後才取代（diagnose 時定案）
• 協作者寫的 comment 不改：那是第三方原話，只提議，保留 R5 拒絕編輯
• GitHub 自帶的編輯紀錄不擋：hook 只擋本機歸檔

Actual

目前的做法是追加 comment 或 errata，錯誤原文留在原處，讀者要自己拼湊出哪個版本才對。

Related

• feat: idd-edit 的編輯對象應擴到 issue body，不只 comment（無 comment 的 issue 目前無路可編） #347 — idd-edit 目前只能編 comment，不能編 body（前置條件）
• feature: idd-reorganize — first-class re-baseline when an upstream artifact (issue/diagnosis/spec) was wrong and cascaded downstream #200 — idd-reorganize：錯誤已經擴散到下游時怎麼處理
• 同批回饋：issue 內容太囉唆→ issue／comment 內容太囉唆，需討論精簡方法 #352

Clarity Surface(idd-clarify run 2026-09-24T00:06:03Z)

Type	Source	Question for you	Status
ambiguity	"會看到記憶裡面錯誤的東西"	老師說的「記憶」是指 issue 本身（下游 skill 會重讀），還是 Claude 的長期記憶（memory／ltm）？	resolved @ 2026-09-24T00:18:58Z (reason: 指 issue 本身及其全部內容（body＋所有 comment），不是 Claude 的長期記憶)
ambiguity	"issue裡面有任何錯誤的東西"	「錯誤」包括哪些：打錯字、事實錯誤、後來被推翻的診斷結論，還是全部都算？	resolved @ 2026-09-24T00:24:12Z (reason: 全部都算：打錯字、事實錯誤、被推翻的結論)
ambiguity	"把他改成正確的"	就地更正時，錯誤原文要保留成刪除線或折疊，還是直接取代？	resolved @ 2026-09-24T00:18:58Z (reason: 確定是錯的就直接取代，不保留刪除線或折疊)

---

Current Status

Phase: diagnosed
Last updated: 2026-09-24 by idd-diagnose

Key Decisions

• Complexity = Spectra：須修改 append-vs-modify 規則（comment 為 append-only、正文為 verbatim-preserve）
• 確定錯誤由 AI 提議、使用者確認後就地取代；協作者 comment 不改；GitHub 編輯紀錄不擋
• 下一步走 /spectra-discuss

Scope Changes

• 吸收 feat: idd-edit 的編輯對象應擴到 issue body，不只 comment（無 comment 的 issue 目前無路可編） #347（idd-edit 支援正文）與 idd-comment --type errata 流程改寫

Blocking

• (none)

Commits

• (none)

[kiki830621]

Diagnosis

Type

feature

Root Cause / Analysis

現行規則明文禁止 #351 要做的事，所以這張 issue 不只是新增功能，也要修改規則。

• rules/append-vs-modify.md（spec append-vs-modify-discipline）有三處衝突：
  • 已發佈的 comment 屬於 append-only，不能改
  • issue 正文 --- 以上（Problem／Expected／Actual…）屬於 verbatim-preserve，「絕對不可改」
  • 錯誤只能靠追加來更正
• 現有的更正流程正是 issue 內容有錯時應以 /idd-edit 就地更正，而非只追加 comment（錯誤會被當記憶繼承） #351 反對的形狀：idd-comment --type errata 會另貼一則 errata，再用 idd-edit --prepend-note 在原 comment 頂端加「⚠️ See errata below」，錯的內容仍留在原處。
• idd-edit 備份放在 /tmp/idd-edit-backup/，只保留 7 天，而且 marker 寫出路徑（backup=<path>）。
• idd-edit 只能編 comment，編不了正文（feat: idd-edit 的編輯對象應擴到 issue body，不只 comment（無 comment 的 issue 目前無路可編） #347）。
• IDD plugin 目前只有 SessionStart hook，沒有任何 PreToolUse hook。

Impact

• 規則／spec：rules/append-vs-modify.md、openspec/specs/append-vs-modify-discipline/spec.md
• Skill：idd-edit（目標、備份、marker）、idd-comment（errata type）、會發現錯誤的 skill（idd-verify、idd-diagnose、idd-reorganize）
• 新增：plugin 的 PreToolUse hook（hooks/hooks.json）
• 所有 IDD 使用者：hook 隨 plugin 安裝

Strategy

• 改規則：新增「更正錯誤」類別。確定錯誤的內容可以就地取代，但必須先歸檔備份。verbatim-preserve 縮小到 Original text 引用區（以及第三方的原話）
• idd-edit：支援正文作為編輯目標（吸收 feat: idd-edit 的編輯對象應擴到 issue body，不只 comment（無 comment 的 issue 目前無路可編） #347）。備份存到 .claude/.idd/archive/edits/<id>.md，進 git、永久保留。marker 改成只寫 backup-id=<id>
• idd-comment --type errata：從「追加 errata＋頂端警告」改成「就地取代＋歸檔」
• PreToolUse hook：擋 Read、Grep、Glob 讀歸檔路徑，也擋 Bash 裡的 cat、grep、git show、git log -p 等讀取指令。提供解鎖開關（比照 archive-first 的 disabled flag）
• 讓 idd-verify、idd-diagnose、idd-reorganize 發現既有內容有錯時，提議改用 /idd-edit 更正，不再追加 comment
• 測試：hook 的擋讀案例（含 Bash 繞道）、備份檔寫入、marker 格式、verbatim-preserve 邊界

Conflict Class

C_shared_module_coord — 共享資源：rules/append-vs-modify.md（多個 skill 引用的紀律規則）與 scripts/idd-edit-helper.py

Complexity

Spectra

• Layer 2：改的是 plugin 對外的行為契約（規則、skill 介面、新 hook），會被所有 IDD 使用者與後續 skill 繼承
• Layer 3：修改既有 spec 的 normative 條文（append-vs-modify-discipline 的 MUST／SHALL），並影響 2 個以上 skill 的契約

Hard-gate: triggered — 同一概念（更正即取代＋歸檔）散佈到 ≥5 檔（rule、spec、idd-edit、idd-comment、hooks.json、verify／diagnose），且動到共享的 append-vs-modify.md

Risks

• GitHub 本身保留編輯紀錄：body 和 comment 的「edited」下拉選單（GraphQL userContentEdits）仍然讀得到舊版。hook 攔不到 gh api，這條管道要決定是否也擋
• Bash 擋讀只能靠比對：用 regex 攔 Bash 指令，一定有繞道（例如用變數組出路徑）
• R5 作者檢查：協作者寫的 comment，現行規則會拒絕編輯。建議保留：那是第三方的原話，性質跟 Original text 相同，只提議、不改
• 判定「確定是錯的」：誰說了算。建議 AI 只提議、使用者確認後才取代

Residue

(none)

Vagueness Pre-check

• V1: 2 — 正文「已定案」八條明確列出範圍、取代方式、備份位置與擋讀機制
• V4: 3 — 沒有寫明驗收條件，但每條決定都可以直接轉成測試（hook 擋讀、marker 格式、備份檔存在）
• Triggered: no — both axes ≤ 3

Sister Concerns Filed (mid-diagnose, v2.47.0+ #528)

(none filed) — idd-comment errata 流程與 #347 已納入本 issue Strategy；#352（分成給人看與給 AI 看兩份）已互相連結