feature: /idd-find — semantic search for IDD-aware related issues across open+closed corpus

[kiki830621]

Problem

Original text (User report,2026-05-22):
「我在想要不要有一個 /idd-find 來找跟某個東西有關的issue」
— Source: /idd-issue invocation

User 想要 semantic search for related issues capability — 給一個 topic / keyword / concept,找出 IDD 既有 corpus 中所有 touching 該 topic 的 issues (open + closed)。目前 IDD plugin 有 /idd-list 做結構性 triage (state / label / phase) + 各 GitHub native gh issue list --search ad-hoc query,但缺一個語意性、IDD-aware 的查找入口。

實際 use case 推論:

• 「之前討論過 chain max-issues 的設計嗎?」→ 想找 /idd-all-chain 設計缺陷: hard-coded cap=10 / 無 multi-root vs ripple-chain pre-flight / cap 超過時 silent truncate #119 + [IDD][design] Enforce strict separation: idd-issue → idd-diagnose → idd-all / idd-all-chain (no auto-swallow diagnose) #122 + 相關 follow-ups
• 「IC_R011 在哪些 skill 已 land?」→ 想找 mid-impl / mid-plan / mid-diagnose / close-time 各 sister 系列
• 「跟 unattended mode 行為有關的 issue」→ 想找 [bug] Layer V Vagueness Pre-check 在 /idd-all unattended mode 下 silent skip — 跳過人工裁決窗 (sister concern from #119) #120 + [IDD][design] Enforce strict separation: idd-issue → idd-diagnose → idd-all / idd-all-chain (no auto-swallow diagnose) #122 + feature: /idd-close should chain to plugin-update / mcp-update / cli-update for distribution-aware close #45 (Step 6.5 unattended fallback)

每次都要手動 gh issue list --search + 人工掃 title/body — 高 cognitive friction,且常漏掉相關 closed issue。

Type

feature (含 design exploration — 設計分岔 open question 1 未定)

Expected

提供 IDD-aware semantic find primitive 讓 user 一句話查到所有 topic-related issues:

/idd-find "chain max-issues design"
# → 列出 open + closed issue 含 keyword/相似 topic,按 relevance 排序
# → 每筆顯示 #N + title + state + phase + last-touched date + 1-line excerpt 含 matched keyword

理想行為:

1. Search scope: title + body + comments (open + closed)
2. IDD context display: 每筆 issue 顯示 phase (diagnosed / implemented / verified / closed) — 非 raw GitHub state
3. Cross-link awareness: 認得 sibling / parent / cluster-PR 關係,輸出時群組顯示
4. Lightweight: read-only,不 mutate state,可隨時 invoke (mirror /idd-list / /idd-clarify family)

Actual

無 semantic find primitive。Workaround 有兩個 path:

• gh issue list --search "<query>":GitHub native search,但無 IDD context (看不到 phase),且 --state all 跟 IDD-aware filter 不能組合
• /idd-list:只看 open issue 的 structural filter (state / label / phase),不接受 semantic query

兩者都需 user 額外人工 stitch (cross-reference issue body / commits / cluster relations)。

Open question(待 diagnose 階段釐清)

Open question 1: new skill vs extension to /idd-list?

Option A — new /idd-find skill (semantic search axis):

• 跟 /idd-list (結構: state/label/phase) 語意正交
• 跟 [META][idd-issue] terminology trust gap — source 用錯 domain term 時 AI 繼承錯誤 #135 /idd-clarify 同為 surfacing-only primitive family (read-only, augments pipeline)
• Skill 數量 +1,但 cognitive cost 低 (single-purpose)

Option B — extend /idd-list with --search "<query>" flag:

• 最 minimal,重用既有 skill
• 但 /idd-list 預設 open-only,加 search 後 --state all + structural filter + semantic query 三軸混合,UX 可能變繁雜
• 風險:把「我要 triage」跟「我要找東西」兩個不同心智模型塞進同 skill

Option C — small subset of /idd-find + extend /idd-list: hybrid? 待 diagnose 細評

Open question 2: search 範圍

• 只 same repo (PsychQuant/issue-driven-development)?
• 或 cross-repo (e.g. monorepo 中相關 sub-project)?
• 包含 PR body 嗎? (PR 也常含「我們之前在 #N 討論過...」cross-reference)

Open question 3: ranking algorithm

• Pure keyword overlap (multi-finding mode Stage 2 已有 score 公式)?
• 加 phase / state / recency weighting?
• 是否需要 LLM-aided semantic similarity (重量級,可能 deferred)?

Impact

• Adoption + discoverability:user 要做 task 前能快速判斷「這之前討論過嗎」,避免 reopen 已解 / 重複討論
• Cross-session continuity:回到 repo 後想知道「上次卡哪」— phase + cross-link group 比 raw search 更有用
• /idd-all-chain 設計缺陷: hard-coded cap=10 / 無 multi-root vs ripple-chain pre-flight / cap 超過時 silent truncate #119/[IDD][design] Enforce strict separation: idd-issue → idd-diagnose → idd-all / idd-all-chain (no auto-swallow diagnose) #122/[bug] Layer V Vagueness Pre-check 在 /idd-all unattended mode 下 silent skip — 跳過人工裁決窗 (sister concern from #119) #120 cluster 重訪:這次 session 跨 5+ issues,若有 /idd-find "ripple-chain semantic" 一鍵列出 /idd-all-chain 設計缺陷: hard-coded cap=10 / 無 multi-root vs ripple-chain pre-flight / cap 超過時 silent truncate #119+[bug] Layer V Vagueness Pre-check 在 /idd-all unattended mode 下 silent skip — 跳過人工裁決窗 (sister concern from #119) #120+[refactor] /idd-all-chain cluster branch squash merge 對 multi-root 不友善 — 失去 Refs #N 軌跡與 bisect 精準度 (sister concern from #119) #121+[IDD][design] Enforce strict separation: idd-issue → idd-diagnose → idd-all / idd-all-chain (no auto-swallow diagnose) #122,follow-up 不需要 reconstruct cluster

Priority

P1 — 本週(user 預期未來工作要用上)

Related context

• [META][idd-issue] terminology trust gap — source 用錯 domain term 時 AI 繼承錯誤 #135 /idd-clarify (v2.72.0+) — surfacing-only primitive family,/idd-find 若採 Option A 屬同 family
• /idd-list (v2.51.0+) — structural list with PR cluster awareness (本提案的 sibling)
• Multi-finding mode Stage 2 score 公式 (title×2 + body×1, normalize by max_possible) — 若 Option C semantic find 重用此邏輯成本低

Vagueness assessment

• V1 (vague WHAT) = 3 — 方向明確(semantic find for issues),但 surface 範圍 (open question 2) + skill boundary (open question 1) 未定
• V4 (vague ACCEPTANCE) = 4 — done criteria 須等 diagnose 決定 Option A/B/C + 最小 MVP scope 才能 testable

---

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

Filed sibling issues: #140

• [design] Document 'surfacing-only primitive' skill family pattern (idd-list / idd-clarify / future idd-find?) (sibling concern from #139) #140 — Document 'surfacing-only primitive' skill family pattern (deferred — pattern abstraction premature until feature: /idd-find — semantic search for IDD-aware related issues across open+closed corpus #139 Option A vs C decided in diagnose)