[META][idd-edit / idd-update] should integrate /idd-clarify primitive for symmetric Terminology Surface (sister concern from #135)

[kiki830621]

Source

surfaced during /idd-diagnose #135 sister concern surfacing (Step 3.6)

#135 v3 design comment table:

'Single source of truth | clarify logic 跟 idd-issue 耦合;若未來 idd-edit / idd-update 也要 clarify,複製代碼 | 只活在 /idd-clarify SKILL.md'

#135 implementation 完成後,自然的問題:既然 /idd-clarify 是 standalone primitive,/idd-edit(若改 issue body)跟 /idd-update(若 sync Current Status)是否也應該 delegate?

Open questions

• idd-edit 改 body 後是否觸發 re-clarify?(改完可能引入新術語誤用)
• idd-update 是 metadata-only 還是 body-touching?(若 metadata-only 不必;若 body 也碰應 chain)
• idd-list / idd-show 等 read-only skills 不必整合(無 body 變更)

Type

enhancement / meta — IDD skill graph symmetry

Priority

P3 — wait until #135 v3 implementation lands + 觀察 user-reported case 再決定

Refs #135

Current Status

Phase: diagnosed
Last updated: 2026-05-25 by idd-diagnose (batch)

Complexity

Spectra when triggered (parking lot)

Routing

See diagnosis comment Strategy section for explicit WAIT trigger condition + next-step path.

[kiki830621]

Diagnosis

Type

enhancement / meta — IDD skill graph symmetry question(should /idd-edit + /idd-update integrate /idd-clarify composable primitive?)

Analysis

Sister of #135 cluster。Issue 已自我 framed 完整,3 個 open questions 都 well-formed:

1. idd-edit 改 body 後是否觸發 re-clarify?— YES likely(改完可能引入新術語誤用,跟 idd-issue 初始 invoke /idd-clarify 對稱)
2. idd-update 是 metadata-only 還是 body-touching?— 查 idd-update SKILL.md:它只改 Current Status 區塊,不碰原始 Problem/Expected/Actual。所以 idd-update 不需要 re-clarify(metadata-only by contract)
3. idd-list / idd-show 等 read-only skills 不必整合 — 正確,read-only 無 body 變更

Pre-implementation answer 已可推導大半;真正未決點是 idd-edit 整合的 UX detail(re-clarify timing — pre-edit / post-edit / both?)。

Strategy

DEFER 至 #135 v3 (canonical idd-clarify primitive) implementation 完成 + 觀察 ≥1 user-reported case「edit 後 terminology drift」後再 design。 Pre-engineering risk:現在 design idd-edit ↔ idd-clarify 整合 protocol,但 #135 v3 SKILL.md 還沒 freeze,protocol 假設可能 stale。

待 trigger 條件成立後,實際 design 應涵蓋:

• idd-edit 改 body trigger condition(append/replace/prepend-note 三種 mode 哪些觸發?)
• Re-clarify timing(pre-edit show preview 還是 post-edit annotation?)
• idd-update 確認維持 metadata-only(若以後改 body 才需 chain)

Complexity

Spectra(Layer 2 + Layer 3 if/when triggered):若實作,會修改既有 published idd-edit SKILL.md normative behavior,且新增 cross-skill protocol contract。但目前狀態 = parking lot,Spectra 不立即 trigger。

Risks

• R1 Pre-engineering:現在 design 等 [META][idd-issue] terminology trust gap — source 用錯 domain term 時 AI 繼承錯誤 #135 v3 freeze 後 spec drift,工成本浪費。Mitigation:WAIT
• R2 idd-update misdetection:若未來 /idd-update 演化成「body-touching」(e.g. 加 closing summary sync),需重新評估。Mitigation:future spec change 自然 trigger
• R3 Symmetry over-application:不是所有 skill 都該 chain — idd-list/idd-show 對稱性問題 issue 已正確排除

Residue

(NSQL §4.6 — operationalize 不到):「symmetry as design heuristic」本身 — symmetric skill graph 是 IDD 美學 (issue → diagnose → ... → close 是 symmetric pipeline),但何時 enforce symmetry vs 何時容許 asymmetric exception(close 是 SHOULD 而非 SHALL,例)是 cultural decision,不能由 spec force。本 issue 不為此 horizon 負責。

---

Vagueness Pre-check — Final

• **V1=2\n- **V4=3
• Triggered: no — both axes ≤ 3 (issue self-framed clear with explicit open questions + trigger condition)

Sister Concerns Filed (mid-diagnose, v2.47.0+ #528;v2.72.0+ default-flip #148)

(none surfaced — this issue IS itself a sister of #135 cluster (alongside #136 #137 #143 #144 #145 #146);cross-sister relationships already documented in each diagnose Strategy / Related section. Per IC_R011 §3 exemption "existing issue covers" — no net-new orphan to file.)