feature: spectra-apply auto-post Implementation Complete to GitHub issue (resolve /idd-close supersession friction)

[kiki830621]

Problem

Source: surfaced during /idd-close #44 (2026-05-10) — retroactive Implementation Complete posted as workaround.

/idd-close 的 v2.41.0+ supersession 設計依賴 ## Implementation Complete > ### Checklist 全 - [x] 才 trigger,讓 Strategy / Implementation Plan 的 stale - [ ] 自動 superseded。

但 Spectra path 不會自動 post ## Implementation Complete comment 到 GitHub issue。spectra-apply 管 archive 內 tasks.md,結束後 issue body / comments 沒 canonical Implementation Complete anchor → supersession 永遠不 trigger → /idd-close 撞 stale Strategy - [ ] (從 spectra-discuss 階段 inherited 的 pre-design 提案,通常已被 propose / apply 階段重新設計)refuse close。

實際撞到的案例:#44 (/idd-all-chain 的 root issue) 走完 Spectra path,change archived,plugin v2.55.0 ship。但 Strategy section 的 bullets 是 pre-discuss 提案 (含 rejected --chain flag + chain_policy config) — 全 unchecked。/idd-close #44 走 Legacy fallback 把這些 stale - [ ] 視為阻擋,refuse close。Workaround:retroactive 合成 Implementation Complete comment(描述實際 ship 的東西,不 mapping 回 stale Strategy bullets)→ supersession trigger → close pass。

每個 Spectra-archived issue close 都會撞同樣 friction。

Type

feature (cross-skill — Spectra ↔ IDD bridge mechanism)

Expected

兩個方向都可以解(可同時):

Option A: spectra-apply 結束時 auto-post Implementation Complete to GitHub issue

spectra-apply Step 9 (final summary report) 結束後增加 Step 10:

1. Detect linked GitHub issue — 從 change directory 內 read proposal.md 或 design.md 找 Refs #N / Closes #N / 「GitHub-side tracker: #N」 mention,或從 commits 內 grep #N cross-link
2. Compose Implementation Complete comment:
   • Title: ## Implementation Complete (auto-posted by spectra-apply 2026-05-10)
   • Note: 「本 issue 走 Spectra path,實際 ship 的 mechanism 在 archive 內 tasks.md 同步,本 comment 是合成的 audit anchor 讓 /idd-close supersession 觸發」
   • Checklist: - [x] per spec capability ADDED / MODIFIED + per major commit
3. gh issue comment $N --body-file ... post comment
4. Audit trail entry in spectra apply summary 報告

Pros:解 root cause,讓所有 future Spectra-archived issues 的 close 都自動 work。
Cons:跨 skill (Spectra is third-party) — 需要 contract refinement,也許要 issue-driven-dev 那邊提 hook mechanism。

Option B: /idd-close 偵測 archived Spectra change → 自動觸發 supersession

/idd-close Step 0 supersession check 增加 fallback path:

1. Scan openspec/changes/archive/*/ 找 proposal.md 含 Refs #N / GitHub-side tracker pointer
2. 找到 → 視為「Implementation Complete equivalent exists」→ supersession active,跳過 stale Strategy / Plan scan
3. Fallback chain:
   • Implementation Complete > Checklist exists + 全 [x] → supersession (existing)
   • Archived Spectra change references this issue → supersession (NEW)
   • Otherwise → Legacy fallback strict scan

Pros:在 idd-close 內部解,不依賴 Spectra hook。
Cons:idd-close 邏輯變複雜,需要 file-system aware (scan archive directories)。

Option C (Hybrid)

A 為長期解,B 為 transitional fallback。先 ship B 解 immediate friction,再跟 Spectra-app upstream 協調 A。

Actual

每個 Spectra-archived issue close 都要手動合成 Implementation Complete comment(per /idd-close #44 retroactive workaround)。違反 IDD「automatic audit trail」紀律。

Impact

影響的工作流

• 任何走完整 spectra-discuss → spectra-propose → spectra-apply chain 的 issue
• 包含 (in-flight): feature: /idd-all-chain accept multiple root issues with DFS/BFS traversal (default DFS) #46 multi-root chain, idd-issue: 加入 multi-finding source 的 triage 機制（避免每筆 finding 手動分 create/update/comment/edit） #48 multi-finding triage(都是 Spectra tier)— 這 2 個 issue ship 後 close 都會撞同樣 friction

影響的檔案 (Option B)

• plugins/issue-driven-dev/skills/idd-close/SKILL.md Step 0 supersession check 加新 fallback
• plugins/issue-driven-dev/references/ 文件化新 supersession path

影響的檔案 (Option A)

• 跨 plugin — spectra-app upstream 增加 GitHub issue post hook(third-party,需 coordinate)
• 或:在 issue-driven-dev 加 idd-spectra-bridge skill 跑在 spectra-apply 後

Acceptance criteria

1. Spectra path issue 走完整 lifecycle 後,/idd-close #N 不需 retroactive 合成 Implementation Complete 即可通過
2. Audit trail 仍然完整(future reader 看 issue 仍能找到 "what shipped" 的 anchor)
3. Backward compat:既有 archived Spectra changes 不需 re-process

Priority

P2 — Spectra workflow 高頻使用,每次 close 都撞 friction。但有 retroactive workaround,不阻擋 individual issue close。

Sister concerns

• feature: mechanism for sync archived Spectra spec deltas with subsequent capability extensions #54 (mechanism for sync archived Spectra spec deltas with subsequent capability extensions) — 這是 archive-side 同步問題;本 issue 是 close-side audit anchor 問題。兩者 orthogonal 但 both about Spectra archive ↔ IDD lifecycle integration。

---

Current Status

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

Key Decisions

• Complexity = Spectra (Layer 2 + Layer 3a/b/c 都命中: cross-plugin contract + IDD-close normative + architectural decision)
• Layer V untriggered (V1=2 V4=3)
• 推 Option C (Hybrid): Phase 1 B 立即 ship,Phase 2 A 跟 spectra-app coordinate

Blocking

• 等 user 跑 /spectra-discuss 對齊 Option C strategy + 5 個 sub-decisions

[kiki830621]

Diagnosis

Type

feature (cross-skill bridge — Spectra ↔ IDD lifecycle integration)

Analysis

Issue body 已 explicit Option A/B/C trade-off + lean toward C (Hybrid)。本 diagnose 主要工作是確認 Spectra tier 判定 + 擴展 Option C 的 sequencing。

Why Spectra-tier confirmed

• Layer 2 命中:新 published convention between Spectra and IDD plugin — spectra-apply Step 10 hook(option A)是 Spectra plugin 的新 contract surface;/idd-close archive scan(option B)是 IDD plugin 的新 detection convention。兩者都對 future plugin authors / reviewers 是 published API
• Layer 3a 命中:Modifies idd-close skill normative behavior(supersession 邏輯) + spectra-app skill normative behavior(post-apply hook)
• Layer 3b 命中:Cross-spec — idd-close Step 0 + spectra-apply Step 9 + 可能 reference doc。需要 explicit consistency checking
• Layer 3c 命中:Architectural decision — Spectra-IDD integration model long-term implications(future hooks 都會跟著 Option A/B/C 的 mental model)

Option B vs A vs C 細考量

Option B (IDD-side fix) advantages:

• 完全 in-IDD 控制,不依賴 spectra-app 第三方 release
• Backward-compat:既有 archived Spectra changes 立即受惠(scan 找得到)
• Detection 邏輯 isolated to idd-close

Option B disadvantages:

• IDD-close 變 file-system aware(scan archive directories)— 邏輯複雜度↑
• 若 archive layout 改變需同步改 idd-close

Option A (Spectra-side hook) advantages:

• Solve root cause — Implementation Complete comment 真的存在於 issue
• Audit trail 對 future reader 最直觀

Option A disadvantages:

• 跨 plugin coordination(spectra-app 是 third-party)— ship 速度慢
• 既有 archived Spectra changes 沒 retroactive cover(只解 future)

Option C (Hybrid) = ship B 立即解 friction + 同時談 A 為長期解 → 本 diagnose 推這個。

Sequencing decision

Spectra path: /spectra-discuss 對齊以下 sub-decisions:

1. Confirm Option C strategy(B 立即 ship,A 跟 spectra-app 談)
2. B 的 archive scan algorithm(per-comment grep Refs #N vs scan proposal.md body)
3. 透過「new supersession trigger」設計 — Implementation Complete > Checklist (existing) OR Archived Spectra change references this issue (new)?
4. spectra-app 可能不 ship hook 的 fallback(B 永久作 sole solution)
5. Cross-link audit trail 怎麼寫(close summary mention archived change?)

Impact

• 影響的工作流:所有走完整 spectra-discuss → spectra-propose → spectra-apply chain 的 issue close(Spectra workflow 高頻)
• 影響的檔案(per Option C):
  • Phase 1 (B 立即):
    • plugins/issue-driven-dev/skills/idd-close/SKILL.md Step 0 supersession 加 archive-scan fallback
    • plugins/issue-driven-dev/references/ 文件化新 supersession path
  • Phase 2 (A 長期):
    • 跨 plugin — spectra-app upstream PR 加 GitHub issue post hook(third-party,需 coordinate)
• 既有 archived Spectra changes:Phase 1 (B) 立即 cover(scan 找 cross-link)
• In-flight Spectra issues feature: /idd-all-chain accept multiple root issues with DFS/BFS traversal (default DFS) #46 idd-issue: 加入 multi-finding source 的 triage 機制（避免每筆 finding 手動分 create/update/comment/edit） #48 ship 後 close 自動 work

Strategy

(Spectra path — 預期 task list:)

• /spectra-discuss 對齊 Option C strategy + 5 個 sub-decisions
• /spectra-propose 起草 proposal:Phase 1 B 機制 spec + Phase 2 A coordination plan
• design.md 含:archive scan algorithm + supersession trigger fallback chain + cross-link audit trail format
• spec deltas:idd-close-supersession (MODIFIED — add archive-scan fallback path)
• (Phase 2 deferred to follow-up issue)spectra-app coordination

Complexity

Spectra (Layer 2 + Layer 3 都命中)

理由 above。Spectra path 走 /spectra-discuss (default) 對齊,不 opt-out。

Layer V — vagueness check:

• V1: 2 — issue body 已 explicit 寫 Option A/B/C + lean C
• V4: 3 — Acceptance 隱含 (next Spectra-archived close pass without retroactive workaround) + has explicit acceptance criteria 3 條
• Triggered: no

Risks

• Spectra-app 第三方 plugin:Option A 需 coordinate,若 upstream 不接受 hook design,Phase 2 會卡住。Mitigation:Option C 把 Phase 1 B 設計成 standalone solution(不需 A 也 work);A 是 nice-to-have not blocker
• Archive scan performance:repo 的 openspec/changes/archive/ 累積到 N 個 archived changes 後,每次 close 都 scan N 個 directory。Mitigation:本 issue 是 Spectra-archived close path(本來就少),且可加 cache layer if needed
• Multi-issue archived change cross-link:1 archived change ref'd N issues,close any one issue 都該 trigger supersession?Mitigation:scan algorithm 設計為「any archived change ref this issue → supersession active」即可
• False positive:future archived change 可能 incidentally mention #N(quoted text / cross-link to other repo)— 太 lax 觸發 supersession 會 silent skip stale Strategy。Mitigation:Phase 1 設計時 explicit anchor pattern (e.g. only Refs #N / Closes #N lines, not body text)

Recommended Path

Spectra (default — discuss first) → /spectra-discuss。

理由:design 還有 5 個 sub-decisions 沒收斂;cross-plugin coordination 有 dependency risk;不該 skip discuss 直接 propose。