feat: idd-edit 的編輯對象應擴到 issue body，不只 comment（無 comment 的 issue 目前無路可編）

[kiki830621]

Problem

Original text（使用者，2026-09-15，/idd-issue 口述；前段是使用者引用 AI 在同一 session 的說明）:
「一件事先講清楚：idd-edit 編的是 comment，而 #10 目前一個 comment 都沒有，四個問句在 issue body 的 Clarity Surface 表裡。正確落點是兩步：用 idd-clarify --status resolved 把四列標成已回答，再把你的原話連同新想法記成一則 decision comment。我照這條走。
我覺得要開一個issue，edit的不一定是comment，而應該是針對issue」
— Source: 使用者對 AI 上一輪回覆的反應（session 內）

實際情境：使用者對一張剛建好的 issue 下 /idd-edit，想把自己對 body 內 Clarity Surface 四個問句的回答寫進去。該 issue 還沒有任何 comment，所以 idd-edit 的兩種 target 語法（comment:<id>、#N --last）都沒有東西可指。AI 只能繞路：idd-clarify --status resolved 逐列改狀態，再開一則 idd-comment --type decision，最後 idd-update 同步 Current Status。三個 skill、三次 egress，才完成使用者心裡「編輯這張 issue」這一個動作。

使用者的判斷是：idd-edit 的編輯對象應該是 issue 本身，comment 只是其中一種 target。

Type

feature

Expected

idd-edit 接受 issue body 作為 target，與 comment target 共用同一套紀律（backup、preview、confirm、audit marker、R4 scope 強制、R5 作者 gate、gh-egress 派送）。可能的形狀：

/idd-edit #N --append --reason="..." --body="..."                    # body 末尾 append（audit-block-append）
/idd-edit #N --replace --section "## Expected" --body-file=...       # 只換一個 named section
/idd-edit #N --prepend-note --reason="..."                           # body 頂部加警示

要點：

1. Target 解析：#N 不帶 --last 且 issue 無 comment 時，目前是列 comments 讓使用者選；空清單應直接落到 body target，或新增顯式語法（如 issue:N / --target-body）避免歧義。
2. Managed-zone 意識：## Current Status 歸 idd-update、### Clarity Surface 歸 idd-clarify。對這兩區的 --replace --section 應拒絕並指向對應 skill，--append 則落在這些 managed zone 之前還是之後要定案（否則 idd-update 下次重建 Current Status 時可能吃掉 append 的內容，見 idd-update: body+comments 一起餵 jq 解析失敗 → $BODY 空字串 → gh issue edit 把整個 issue body 覆蓋成只剩 Current Status #345 的 body 覆蓋事故）。
3. 原始記錄區不可動：## Problem 的 Original text blockquote 是 IC_R007 verbatim 契約，--replace --section 不得選它；只允許 --append 在其後加更正。
4. Marker：<!-- idd:edit target=issue-body mode=... date=... backup=... -->，與 comment marker 區分。
5. R5：issue body 的作者通常是 OWNER；非 OWNER 開的 issue 沿用 --override-user-content --reason 路徑。

Actual

• idd-edit SKILL.md 的 target 只有 comment:<id>、#N --last、#N（列 comments 選一個）。無 comment 的 issue 無路可走。
• 要改 body 只能：idd-issue multi-finding mode 的 edit body intent（要有 source 文件、走四 stage，對單張 issue 的一次小編輯是 overkill）、idd-update（只管 Current Status）、idd-clarify --status（只管 Clarity Surface 列狀態）、或裸 gh issue edit（沒有 backup / preview / marker，繞過 egress，正是 idd-update: body+comments 一起餵 jq 解析失敗 → $BODY 空字串 → gh issue edit 把整個 issue body 覆蓋成只剩 Current Status #345 那類事故的溫床）。
• 本 session 的繞路成本：3 個 skill、3 次 egress、使用者一句話變成三段流程。

Impact

• 使用者的心智模型是「編輯 issue」，工具的模型是「編輯 comment」；落差讓最常見的小編輯（補一段、改一段）沒有 first-class 入口。
• 沒有 first-class 入口時，人會回頭用裸 gh issue edit 或 gh api PATCH，失去 backup 與 audit trail；idd-update: body+comments 一起餵 jq 解析失敗 → $BODY 空字串 → gh issue edit 把整個 issue body 覆蓋成只剩 Current Status #345 顯示 body 覆蓋是真實發生過的資料遺失。
• 補上後，idd-comment 的 decision comment 仍有其位置（記錄「誰在何時決定了什麼」），但「把回答寫回 body」這件事不必再借道 comment。

待釐清

1. --append 到 body 時，插入點是 body 結尾，還是 managed zone（Current Status / Clarity Surface）之前？兩者對 idd-update 的重建行為影響不同。
2. 使用者回答 Clarity Surface 問句這個情境，理想流程是 idd-edit 一次完成，還是 idd-clarify --status 本身該接受「回答文字」並自動把答案寫進 row？後者可能是更窄、更準的修法。
3. 要不要同時給 idd-edit 一個 --target-body 顯式旗標，而不是靠「無 comment 就落到 body」的隱性規則？隱性規則在有 comment 的 issue 上會讓使用者以為在編 body、實際編到 comment。

Clarity Surface(idd-clarify run 2026-09-15T04:28:36Z)

Type	Source	Question for you	Status
ambiguity	"edit的不一定是comment，而應該是針對issue"	「針對 issue」是要能編 body 的任一段落（一般化的 idd-edit body target），還是只要「回答 Clarity Surface 問句並寫回 body」這一個情境能一步完成就夠？前者改 idd-edit，後者可能只改 idd-clarify。	surfaced
ambiguity	"edit的不一定是comment"	comment target 保留、body 是新增的另一種 target，還是 body 變成預設、comment 退成選項？這決定 #N 不帶旗標時指向哪裡。	surfaced

Linked-Context Siblings Filed (v2.48.0+ #529)

• bug: idd-update 的 git log --grep="#$NUMBER" 無詞界，#10 命中 #107 (sibling concern from #347) #348 — idd-update 的 commit 掃描無詞界（同 session 實測踩到，與本 issue 正交）