[META] /idd-clarify self-audit recursion edge case (residue from #135)

[kiki830621]

Source

Residue from /idd-close #135 (Step 3.6,IC_R011 #105 checkpoint)。

#135 diagnosis comment ### Residue line 3:

Skill graph self-audit recursion:如果 /idd-clarify 自己 surface 自己 SKILL.md 的 terminology gap,應該怎麼處理?(recursive case;本 issue 接受 v3 design 已 stable 暫不處理)

Background

/idd-clarify 設計目的:catch issue body 的 terminology / ambiguity / missing-context gap。但 /idd-clarify 自身的 SKILL.md 也是 prose,也可能含這類 gap。

具體 edge case:

• User 跑 /idd-clarify <#N> 對某 issue 發現「ambiguity」row
• 該 ambiguity 其實是 /idd-clarify SKILL.md 自身 spec 描述不清楚造成(user 看不懂該怎麼用 skill)
• → user 應該 retroactive file IDD plugin issue 而不是 issue scope 內 resolve

Open questions

• /idd-clarify 是否該對自身 SKILL.md 做一次 audit?(meta-application)
• 若 ambiguity row 跟 skill behavior contract 有關,該標 ### Clarity Surface 的 Suggested canonical 是 "check IDD plugin docs" 還是其他?
• Plugin docs gap 跟 issue body gap 的 disambiguation rule?

Type

enhancement / edge case design

Priority

P3 — wait for actual self-audit recursion case to emerge in real /idd-clarify usage before designing(may never happen in practice)。

Refs #135

Current Status

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

Complexity

Simple when triggered (parking lot)

Routing

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

[kiki830621]

Diagnosis

Type

enhancement / edge case design — /idd-clarify self-audit recursion

Analysis

#135 residue 第 3 條 — meta edge case:/idd-clarify 自己 surface 自己 SKILL.md 的 terminology gap 時怎麼處理?

Concrete scenario:

1. User 跑 /idd-clarify #N 對某 issue
2. Skill 發現「ambiguity」row,suggested_canonical 寫 "see /idd-clarify SKILL.md spec X"
3. User 看 SKILL.md spec X 也不懂 → 本質是 SKILL.md 自身描述不清楚造成的 ambiguity
4. → user 應 retroactive file IDD plugin issue 而不是 issue scope 內 resolve

Issue body 已 framed 完整:3 個 open questions 涵蓋(self-audit 應用 / Suggested canonical wording / plugin-docs gap disambiguation rule)。

頻率預估:可能在 real /idd-clarify usage 永遠不出現(user 通常會直覺 file plugin issue,不會卡在 issue-scope-internal resolution)。

Strategy

DEFER until actual recursion case emerges(issue body 已明示「may never happen in practice」):

明確 trigger 條件:

• 首次 real /idd-clarify session 出現「ambiguity row 其實是 SKILL.md 自身 gap」
• 或 maintainer 主動跑 /idd-clarify $CLAUDE_PLUGIN_ROOT/.../SKILL.md 自我 audit(meta-application)發現非 trivial gap

任一 trigger → 重 diagnose,可能合 closing-summary 紀錄 mechanism 簡單處理(/idd-issue retroactive file 即可,不需新 protocol)。

Complexity

Simple when triggered(Layer 1 disqualifier:probably just "add Note to /idd-clarify SKILL.md saying 'if ambiguity row 指向 self plugin docs gap, file IDD issue' " — 純 docs update,no normative change)。

但目前 = parking lot,wait for trigger。

Risks

• R1 Pre-engineering an edge case that never triggers:rule of three 未到的 P3 issue,設計 protocol 浪費
• R2 Recursive resolution paradox:if /idd-clarify itself surface gap pointing to its SKILL.md,「fix via /idd-clarify」邏輯上循環。Mitigation:Plugin-docs gap 走 IDD-meta-issue route(本 issue 已隱含)
• R3 Maintainer self-audit edge is testable now(maintainer 可隨時跑 /idd-clarify on SKILL.md 製造 trigger 證據)— 加速 trigger 條件成立

Residue

(NSQL §4.6):「all tools have epistemic gaps」horizon — 任何 audit tool 都不能 perfectly audit 自己(Gödel/ recursion limitation)。本 issue 是這個 horizon 的具體 instantiation。Spec 是 pragmatic workaround(retroactive file),不是 root resolution。

---

Vagueness Pre-check — Final

• **V1=2\n- **V4=2
• 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.)