[META] terminology-canonical.md plugin-level extension architecture (closing follow-up from #135)

[kiki830621]

Source

Surfaced during /idd-close #135 closing summary scan (Step 3.5,IC_R011 #527 checkpoint)。

#135 design.md Open Question Q2 留 deferred:

Q2: Library file naming convention for plugin-level extension
Resolution:本 PR 範圍不解 — initial seed 只放 IDD plugin own。Future plugin extension 等實際有 medical / legal plugin 才 design,鬆綁 over-engineering。

closing summary mention:

「future plugin-level extension(待實際需求出現後 design)」

Open questions

• Naming convention:references/terminology-canonical-{domain}.md 或 plugin-specific references/terminology-canonical.md chain-merged?
• Chain-merge ordering:plugin-specific override base 還是 supplement?
• IDD + spectra plugin 共享同一 library(若 spectra-discuss 之類 skill 也需 terminology check)?
• 觸發條件:domain plugin manifest 加 terminology_library: true flag?

Type

enhancement / future architectural design

Priority

P3 — wait for ≥1 real domain-specific plugin requesting terminology extension before designing。Don't pre-engineer(rule-of-three 慣例)。

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 / future architectural design

Analysis

#135 design Q2 explicit deferred 的 follow-up,issue 自我 framed 完整。4 個 open questions(naming convention / chain-merge ordering / cross-plugin sharing / trigger mechanism)是 standard plugin-architecture decisions,但目前無實際 use case 拉。

terminology-canonical.md 目前只在 IDD plugin own use(初版 seed 6 rows from #135 body + #804 incident)。Plugin-level extension protocol 是 hypothesis — 待 medical / legal / 其他 domain plugin 真出現需求才 design。

Strategy

DEFER per rule-of-three(issue body 已明示)。明確 trigger 條件:

• ≥1 real domain-specific plugin(e.g. medical-mcp / legal-mcp / 其他 specialty)請求 terminology library 整合
• 或 ≥1 spectra plugin skill 需要 cross-IDD terminology check
• 或 IDD terminology-canonical.md row count 超過 ~30(規模 trigger,需 multi-domain partition)

任一 trigger 出現 → 重新 diagnose 並進 Spectra discuss(因 plugin extension protocol 是 published contract for future callers)。

Complexity

Spectra when triggered(Layer 2:plugin-level extension protocol = published API for future callers;Layer 3:architectural decision with long-term maintenance implications)。但目前 = parking lot,wait for trigger。

Risks

• R1 Pre-engineering if designed now without real demand:架構假設可能不符 actual domain plugin 需求(e.g. medical 可能需 ICD-10 code 整合,legal 可能需 jurisdiction-specific term scoping — 不同 domain 結構不同)
• R2 Rule-of-three violation — IDD MANIFESTO 多次提及避免 abstraction before 3 instances 出現
• R3 Cross-plugin coupling if shared library badly designed → harder to refactor than per-plugin local

Residue

(NSQL §4.6):「terminology governance is multi-stakeholder process,not single-PR engineering」這個 horizon。即使本 issue 將來 trigger 並 implement,governance(誰裁決、versioning、deprecation)是 ongoing process,spec 是 mechanism 不是 governance。本 issue 不為 governance horizon 負責(這正是 #145 的 scope)。

---

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.)