feature: /idd-close should chain to plugin-update / mcp-update / cli-update for distribution-aware close

[kiki830621]

Problem

/idd-close 是 IDD lifecycle 的終點:寫 closing summary + close issue + auto-update phase=closed。但對於 distributed-via-plugin / MCP / CLI binary 的 issue,closing 後仍有最後一哩 — 把 fix 同步到 user-facing distribution channel(plugin marketplace / MCP wrapper / CLI release)。

目前流程:

/idd-close #N        ← end of lifecycle from IDD's POV
   ↓ (gap — user 容易忘)
/plugin-update X     ← 才讓使用者實際拿到新版

如果忘了第二步,fix 已合進 main 但 marketplace 仍指向舊版 → 使用者跑 /plugin update 拉不到新東西,看似「修了卻沒修」。歷史上已經多次踩過這坑(Global rule common-release-flow.md 就是為了這個 mandate marketplace-sync,但 trigger 是「release 後」,不是「issue close 後」 — 兩者不總一致)。

Type

feature

Expected

/idd-close #N 在 close 成功後(Step 6 auto-update 之後、Step 7 final report 之前),做 distribution-aware chain detection:

1. Detect issue + repo 是不是 distributed via:

   • Claude Code plugin marketplace (.claude-plugin/marketplace.json 含此 repo)
   • MCP binary (repo 有 bin/*-wrapper.sh 引用 GitHub Release)
   • CLI binary (相似 wrapper / ~/bin reference)

2. AskUserQuestion 3-option(per IC_R011 canonical pattern):

   • chain to plugin-update / mcp-update / cli-update now — 直接 invoke 對應 skill
   • skip — I'll sync manually later — 不 chain,但寫進 closing comment audit trail(### Distribution Sync Pending)讓三個月後考古能找到 dropped step
   • not applicable — this issue doesn't ship — confirm + 不再問(內部 refactor、docs、test 等)

3. Audit trail(任一選擇都寫):

   • PATCH closing comment append ### Distribution Sync section
   • "chained" → record skill + outcome
   • "skip" → record reason + provide command for later use
   • "n/a" → record + close

Actual

目前 /idd-close 結束就是結束。Distribution sync 完全靠使用者記得,沒有任何 mechanical checkpoint。

歷史踩坑(從 che-claude-config/rules/common-release-flow.md 摘):

跳過這步驟讓 marketplace.json 過時。使用者跑 /plugin update 看到舊版本,拿不到新 binary — 即使 GitHub release 存在。Release 只有半成 unless marketplace sync lands.

但 common-release-flow.md 是 release-side trigger,假設 release 跟 issue close 順序一致。實務上很多 issue 是 fix-via-PR,merge 後 close issue 但還沒 cut release;或者 cut release 後忘了 close issue。idd-close 是更早 + 更可靠的 chain anchor(因為 close 是 lifecycle 必經點)。

Impact

影響的工作流

• 任何 idd-close 收尾的 issue,若 repo 是 plugin / MCP / CLI distribution
• 對純內部 refactor / docs / spec 改動 → 不影響(Step 1 detection 過濾掉)

影響的檔案(實作面)

• Sources/.../skills/idd-close/SKILL.md — 加 Step 6.5 (Distribution Sync chain)
• 可能新增 references/distribution-detection.md — detect 邏輯抽出來給其他 skill reuse(idd-implement 在 implement 完成時也該有類似 prompt?)

跨 skill 影響

• plugin-tools/skills/plugin-update — 改成可以接收 --source-issue #N flag,把 issue ref 寫進 commit message
• mcp-tools/skills/mcp-deploy — 同上
• cli-tools/skills/cli-deploy — 同上(若存在)

推測 detection 邏輯

# Heuristic: this repo is distributed if any of:
is_plugin_marketplace_member() {
  # Walk-up parent dirs for .claude-plugin/marketplace.json that lists this repo
  # Or check if cwd is direct subdir of a known marketplace repo
  ...
}

has_binary_wrapper() {
  # Look for bin/*.sh that curls from GitHub Release
  ls "$REPO_ROOT/bin" 2>/dev/null | xargs grep -l "gh release download\|curl.*github.com.*releases" 2>/dev/null
}

DISTRIBUTION_TYPE=""
if is_plugin_marketplace_member "$REPO"; then DISTRIBUTION_TYPE="plugin"; fi
if has_binary_wrapper "$REPO_ROOT"; then DISTRIBUTION_TYPE="${DISTRIBUTION_TYPE:+$DISTRIBUTION_TYPE+}mcp_or_cli"; fi

False-positive case:repo 在 marketplace 但本次 issue 沒影響 user-facing surface(內部 test infra fix)— 由 not applicable option cover。

推測 Step 6.5 placement

Step 4: gh issue close ✓
Step 5: report
Step 6: auto-update body phase=closed ✓
Step 6.5: ★ NEW — Distribution Sync detection + AskUserQuestion + chain
Step 7: batch close special rules

放在 phase=closed 之後是因為:closing summary 是 audit trail,distribution sync 是 follow-up action。Phase 應該在 audit 完成那刻就 lock,不該 hold 著等 sync 才 close。

Acceptance criteria

• /idd-close #N 對 plugin/MCP/CLI repo 觸發 detection + AskUserQuestion
• 三選項都有對應 audit trail entry 寫進 closing comment
• 對純內部 refactor / docs issue → silent skip(detection returns "n/a")
• Backward compat:既有 idd-close 用法不受影響(detection 找不到 distribution type 就 silent)
• 寫入 references/distribution-detection.md(若抽 helper)+ test fixture

Out-of-scope (本 issue 不處理)

• ✗ idd-implement 在 implement 完成時也提示(可能是 follow-up:在 fix 還沒 ship 前先 surface 一次)
• ✗ Auto-detect issue 影響 user-facing surface vs 純內部(留 user 用 not applicable 表態)
• ✗ Release tag 自動 cut(那是 release flow 的職責,不是 close 的職責)

Relation to existing rules

• che-claude-config/rules/common-release-flow.md — release-tier trigger;本 proposal 是 close-tier trigger,互補不衝突(一個 release 對多個 close,一個 close 對 0-1 個 release)
• IC_R011 canonical pattern — Distribution Sync prompt 沿用 3-option AskUserQuestion + audit trail 結構

Trigger context

提此 proposal 的當下 session 剛 close che-apple-mail-mcp#72(get_email base64 bug fix),PR #75 merged 為 commit 5fda74d。但 marketplace.json 還沒 bump,使用者 /plugin update che-apple-mail-mcp 拉到的是舊 v2.16.0 binary,不會包含 fix。User 觀察到此 gap,提出建議。

---

Current Status

Phase: closed
Last updated: 2026-05-10 by idd-close (#67 merged 566741c)

Key Decisions

• Complexity = Plan (Layer P 命中: ordered Strategy 6 steps, decision-heavy detection heuristics, risk-sensitive — close-tier surface)
• Layer V untriggered (V1=2, V4=3) — both axes ≤ 3
• Step 6.5 placement: between current Step 6 (auto-update phase=closed) and Step 7 (batch close special rules) — explicit per issue body
• Cross-repo callers (plugin-update / mcp-deploy / cli-deploy) --source-issue flag deferred to sister issue in psychquant-claude-plugins
• Per Step 4.7 scope clarification: this change limited to idd-close SKILL.md + references/distribution-detection.md in this repo

Scope Changes

• 2026-05-10: scope narrowed by user pre-emptively (Step 4.7 comment) — single repo only

Blocking

• 等 user 確認 diagnosis 後跑 /idd-plan #45 進 EnterPlanMode approval gate

Sister Concerns

• (none surfaced; Strategy 已 explicit 把 cross-repo work 列為 Step 6 sister issue,不另外 file)

[kiki830621]

Scope Clarification (2026-05-10, pre-chain)

Note for /idd-all-chain run: 本次 chain 限縮 scope 在 本 repo (PsychQuant/issue-driven-development) 的 idd-close 改動。

In scope (this chain)

• plugins/issue-driven-dev/skills/idd-close/SKILL.md 加 Step 6.5 — Distribution Sync chain detection
• plugins/issue-driven-dev/references/distribution-detection.md (NEW) — detection 邏輯 canonical contract
• idd-close Step 0 Bootstrap Task List 加 distribution_sync_chain_detection TaskCreate entry
• audit trail 寫進 closing comment 的 ### Distribution Sync section
• AskUserQuestion 3-option per IC_R011 canonical pattern

Out of scope (deferred to sister issue in PsychQuant/psychquant-claude-plugins)

• plugin-tools/skills/plugin-update 加 --source-issue #N flag
• mcp-tools/skills/mcp-deploy 加 --source-issue #N flag
• cli-tools/skills/cli-deploy 加 --source-issue #N flag(若該 skill 存在)

理由:/idd-all-chain 設計上單 repo 操作(cluster branch + PR 在當前 repo)。Cross-repo caller 改動需要在 psychquant-claude-plugins repo 開另一個 PR — 那個 issue 由本 issue close 後另開。

Implementation strategy under scope

• idd-close 跑 distribution detection 後,caller skill 即使尚未支援 --source-issue flag 也不應 abort — --source-issue 是被呼叫端的 nice-to-have(audit trail enhancement);本次 chain 只 invoke /plugin-tools:plugin-update X 等而不帶 --source-issue flag,等對方 repo 的 sister issue 落地後再切換 invocation 帶 flag

Acceptance criteria (this scope)

1. /idd-close #N 在 distribution-detected repo 跑時,Step 6.5 fire AskUserQuestion 3-option
2. "chain to..." → 實際 invoke 對應 plugin-update / mcp-deploy / cli-deploy skill,記 outcome 到 audit trail
3. "skip" → 寫 ### Distribution Sync Pending 到 closing comment + 提供 manual command
4. "n/a" → 寫 ### Distribution Sync — Not Applicable + close
5. 非 distribution repo(無 .claude-plugin/marketplace.json member、無 bin/*-wrapper.sh)→ Step 6.5 silent skip(detect 過濾)

Marker for chain run: this comment marks the canonical scope. Diagnosis / implementation should treat the body's full scope as informational but execute only this in-scope subset.

[kiki830621]

Diagnosis

Type

feature (orchestrator extension to idd-close — distribution-aware chain detection at close time)

Analysis

需求拆解

issue body Expected 段落清楚表達了三件事:

1. Detection:close 時偵測本 repo 是否屬於 distribution channel(plugin marketplace member / MCP wrapper / CLI binary)
2. Prompt:命中時 fire AskUserQuestion 3-option (chain / skip / n/a)
3. Audit trail:不論選哪個都寫進 closing comment 的 ### Distribution Sync section

Trigger context 提供具體的歷史痛點(che-apple-mail-mcp#72 PR #75 merge 後 marketplace.json 沒 bump,user 拉到舊 binary)— 跟 IDD「修了卻沒修」反 pattern 直接對應。

影響的 skill / 檔案盤點

按 Step 4.7 scope clarification comment,本 change 限縮在本 repo (PsychQuant/issue-driven-development):

範疇	動作	Out of scope (將開 sister issue)
plugins/issue-driven-dev/skills/idd-close/SKILL.md	加 Step 6.5 (Distribution Sync chain)	—
plugins/issue-driven-dev/references/distribution-detection.md (NEW)	detection 邏輯 canonical contract	—
idd-close Step 0 Bootstrap Task List	加 distribution_sync_chain_detection TaskCreate entry	—
plugin-tools/skills/plugin-update、mcp-tools/skills/mcp-deploy、cli-tools/skills/cli-deploy	加 --source-issue #N flag	✓ defer to psychquant-claude-plugins repo sister issue

invocation 部分:本次 chain 用既有 /plugin-tools:plugin-update 等 skill name,不帶 --source-issue flag(被呼叫端尚未支援 — graceful)。等對方 repo sister issue 落地後切換。

Detection logic 評估

issue body 提供 pseudocode shell:

is_plugin_marketplace_member()  # walk-up parents for .claude-plugin/marketplace.json
has_binary_wrapper()            # bin/*.sh curls from GitHub Release

實作層面,有 3 個值得釐清的點:

1. Walk-up 範圍:從 cwd 往上找 marketplace.json — stop at $HOME 還是 /?(同 find_idd_config pattern)
2. Binary wrapper detection 的關鍵字:gh release download / curl.*github.com/.*/releases — 還有別的 distribution pattern 嗎?(homebrew?npm?)— 但 issue 限縮 GitHub-native,先窄
3. Mixed type:DISTRIBUTION_TYPE="plugin+mcp_or_cli" (e.g. che-zotero-mcp 同時是 plugin 和 MCP binary) — Step 6.5 該 chain 哪一個?推測 chain plugin-update(plugin-update 內部會偵測 binary 依賴,所以 plugin-update 是 superset)

Step 6.5 placement 已 explicit 寫在 issue

issue 自己定錨了 placement:在 Step 6 auto-update body phase=closed 之後、Step 7 batch close special rules 之前。理由(audit lock vs follow-up action)合理。

與 common-release-flow.md 互補

Issue 已說明:common-release-flow.md 是 release-tier trigger(post-release 同步 marketplace),本 proposal 是 close-tier trigger(close 時 surface user)。互補不衝突 — 一個 release 對多 close,反之亦然。實務上 close-tier 更可靠(因為 close 是 lifecycle 必經點,但不是每個 close 都有 release;而 release 不一定對應 close)。

Impact

• 影響的檔案(In scope):
  • plugins/issue-driven-dev/skills/idd-close/SKILL.md (+ Step 6.5)
  • plugins/issue-driven-dev/references/distribution-detection.md (NEW)
• 影響的使用者流程:任何 plugin/MCP/CLI repo 的 close 動作多一個 prompt(non-blocking,user 可選 skip)
• Backward compat:純內部 refactor / docs / spec issue 在非 distribution repo → silent pass,既有用法零影響

Strategy

• 設計 detection helper(is_plugin_marketplace_member / has_binary_wrapper / infer_distribution_type)寫進 references/distribution-detection.md
• 在 idd-close/SKILL.md Step 6 之後 Step 7 之前插入 Step 6.5 (Distribution Sync chain)
• Step 6.5 內含:
  • Detection invocation
  • 命中時 AskUserQuestion 3-option (chain / skip / n/a)
  • 三選項對應 invocation + audit trail PATCH
  • 沒命中時 silent pass (audit trail 寫 (detection: not a distribution repo) 或不寫)
• Step 0 Bootstrap Task List 加 distribution_sync_chain_detection TaskCreate entry
• 寫 acceptance criteria 對應的 4-case smoke test:plugin / MCP / CLI / non-distribution
• sister issue file 到 psychquant-claude-plugins repo 追 cross-repo --source-issue flag

Complexity

Plan (Layer P 命中)

理由:

• 觸及 IDD lifecycle 核心(close 是必經點),改動的對外 contract 是 user-facing prompt → 風險中等,動手前該 explicit Implementation Plan
• Strategy 已列出 6 個 ordered steps(detection 設計 → SKILL.md 插入 → 三選項實作 → bootstrap 加 entry → smoke test → sister issue file)
• 多個 detection heuristic decision(walk-up 範圍、wrapper keyword、mixed type 處理)— decision-heavy with multiple valid approaches
• 不符合 Spectra:沒有對外暴露新的 published API / protocol(detection helper 是 internal reuse,不是 future caller 的 contract surface);MODIFIED idd-close SKILL.md 的 normative 改動 limited to 1 step 插入,不算 cross-spec ripple
• 不符合 Layer 1 disqualifier(deliverable 是 skill 行為改動,不是 narrative)

Layer V 未 trigger(V1 estimated 2 — clear "Detect → Prompt → Audit trail" 三段式;V4 estimated 3 — acceptance criteria 5 條 explicit listed)— 詳見 audit trail。

Risks

• False-positive detection:repo 在 marketplace 但本次 issue 沒影響 user-facing surface(test infra fix)→ user 用 not applicable 表態 cover
• False-negative detection:wrapper script 用 unusual keyword(e.g. wget instead of curl)→ silent miss,fix 沒 surface to user。Mitigation:reference doc 列 keyword 並建議 user 看到 false-negative 補 PR
• Mixed-type handling:plugin+mcp_or_cli chain plugin-update vs mcp-deploy 哪個?推測 plugin-update 是 superset(會 cascade 到 mcp-deploy)— Plan 階段需驗證
• Cross-repo coordination:被 chain 的 skill (plugin-update / mcp-deploy) 還沒支援 --source-issue,本 change 先 graceful invoke 不帶 flag,等 sister issue 落地後 follow-up

Recommended Path

Plan → /idd-plan #45 進 EnterPlanMode 把 Implementation Plan 呈現給 user approve,再 chain to /idd-implement。

避免直接走 Spectra:沒到 frozen contract 程度;detection helper 是 internal reuse function,不該被 over-formalized 成 spec contract。

Vagueness Pre-check

• V1: 2 — Expected 段三段式(Detect → Prompt → Audit trail)+ Step 6.5 placement explicit;clear what to do
• V4: 3 — Acceptance criteria 5 條 explicit listed;mostly clear with minor 'silent skip' edge-case ambiguity
• Triggered: no — both axes ≤ 3

Sister Concerns Filed (mid-diagnose, v2.47.0+ #528)

(none — Strategy 已 explicit 把 cross-repo flag 列為 Step 6 sister issue,不另外 file;wrapper keyword false-negative 是 reference doc 內部紀錄不需 issue;mixed-type 在 Plan 階段驗證)

[kiki830621]

Implementation Plan (Plan tier)

Tier: Plan (Layer P 命中 per diagnosis) — single repo scope per Step 4.7 clarification (cross-repo --source-issue flag deferred to sister issue in psychquant-claude-plugins).

Files & Changes

• plugins/issue-driven-dev/references/distribution-detection.md (NEW) — canonical contract for detection helpers (is_plugin_marketplace_member / has_binary_wrapper / infer_distribution_type),walk-up algorithm, keyword hooks, mixed-type resolution rule。Reusable by future skills (e.g. idd-implement Step 5.7 for early surface — out of scope here)。
• plugins/issue-driven-dev/skills/idd-close/SKILL.md — insert Step 6.5 between current Step 6 (auto-update body phase=closed) and Step 7 (batch close special rules);update Step 0.5 Bootstrap Task List to add distribution_sync_chain_detection TaskCreate entry。

Sequencing & Dependencies

1. First: write references/distribution-detection.md with detection algorithm + canonical contract — Step 6.5 implementation will reference this doc rather than inlining algorithm
2. Second: insert Step 6.5 in idd-close/SKILL.md (depends on reference doc existing for cross-link)
3. Third: update Step 0.5 Bootstrap Task List entry (depends on Step 6.5 having concrete description)
4. Fourth: smoke-test the 4 cases manually (no automated test infra per [docs] Add chain-vs-bulk note in usecase-routing.md decision tree section (verify follow-up from #49) #62 follow-up; document in Implementation Complete)

Files are file-disjoint (NEW reference + EDIT skill) — both can land in same commit。

Decision Points

D1 — Walk-up scope for is_plugin_marketplace_member (per diagnosis question 1):

• Decision: walk-up parents from $REPO_ROOT looking for .claude-plugin/marketplace.json,stop at $HOME (same as find_idd_config pattern in config-protocol.md)
• Rationale: marketplace repos are typically kept under $HOME/Developer/,never under /;stopping at $HOME avoids spurious filesystem traversal;same convention as existing IDD config walk-up = consistency
• Alternative considered: walk to / — rejected (no real-world marketplace setup needs root scan, performance cost trivial but principle of least surprise wins)
• Member check: parse marketplace.json JSON,look for any plugins[].source.git field matching current $REPO_ROOT's git remote URL (normalize trailing .git)

D2 — Binary wrapper detection keywords (per diagnosis question 2):

• Decision: scan $REPO_ROOT/bin/*.sh (literal pattern,not recursive) for either of:
  • gh release download
  • curl.*github.com.*releases (extended regex)
• Rationale: issue body explicitly limits scope to GitHub-native distribution;these are the two patterns observed in dogfood (che-msg/bin/, che-zotero-mcp/bin/)
• Alternative considered: include wget,brew install from URL,npm install — rejected (out of scope per issue body GitHub-native limit;adds false-positive surface for unrelated bash scripts)
• Extension hook: references/distribution-detection.md documents how to add additional patterns if user's wrapper uses different keyword (just a regex append),without requiring SKILL.md edit
• Path: $REPO_ROOT/bin/*.sh only — NOT Sources//scripts//etc. (those are typically build/dev scripts not user-facing distribution wrappers)

D3 — Mixed-type handling (per diagnosis question 3):

• Decision: when both plugin and mcp_or_cli detected → chain plugin-update only (single chain target)
• Rationale: plugin-tools:plugin-update v1.11+ is dependency-aware orchestrator (per che-claude-config/rules/common-plugins.md);Phase 1.5 detects binary dependencies + AskUserQuestion offers "順便更新" cascade。Calling plugin-update is the superset action that handles both shells。Calling mcp-deploy separately would either duplicate work or skip the plugin shell sync。
• Alternative considered: chain both plugin-update and mcp-deploy sequentially — rejected (double-prompts user,double commits,risk of inconsistency mid-chain)
• Pure-MCP case (no marketplace member,only binary wrapper) → chain mcp-deploy only;Pure-CLI case → chain cli-deploy only (presence detected via wrapper keyword identical to MCP — disambiguate via wrapper script name heuristic: *-mcp-wrapper.sh → MCP, else CLI;documented in reference doc)

D4 — Caller skill --source-issue flag:

• Decision: Step 6.5 invokes target skill without --source-issue flag in v1 (caller skill in psychquant-claude-plugins repo doesn't support it yet per Step 4.7 sister issue defer)
• Rationale: graceful degradation — plugin-update ignores unknown flags gracefully (current behavior),so adding flag prematurely is safe but non-functional;wait for sister issue to land flag-side support, then v2 of feature: /idd-close should chain to plugin-update / mcp-update / cli-update for distribution-aware close #45 can add the flag pass-through
• Audit trail still complete: Step 6.5 writes ### Distribution Sync section to closing comment with skill invoked + outcome — issue ↔ release sync traceability achieved without flag

D5 — Escape hatch / rollback:

• Decision: env var IDD_DISTRIBUTION_SYNC_PROMPT=false silently skips Step 6.5 entire block (still writes 1-line audit Distribution sync prompt skipped (IDD_DISTRIBUTION_SYNC_PROMPT=false) to closing comment for traceability)
• Rationale: pattern-symmetric with IC_R011 AI_LOW_BAR_ISSUE_FILING=false rollback;CI / batch runs can disable to avoid AskUserQuestion blocking
• Detection-based silent skip (non-distribution repo) is always-on;env var only suppresses the prompt for distribution-detected repos

Risks & Mitigations

Risk	Probability	Mitigation
R1 — False-negative detection: wrapper uses wget or other non-listed keyword → Step 6.5 silent miss → user doesn't get sync prompt	Low	Reference doc lists tested keywords + extension protocol;user spotting silent miss = follow-up issue for keyword expansion
R2 — False-positive detection: bin/*.sh exists with curl.*github.com.*releases for unrelated reason (e.g. test helper)	Very low	not applicable AskUserQuestion option lets user table this case + audit trail records "n/a"
R3 — Mixed-type chain confusion: plugin-update doesn't cascade to mcp-deploy as expected → binary not synced	Medium	Pre-implementation: empirical check on che-zotero-mcp (mixed plugin+mcp) — confirm plugin-update Phase 1.5 cascade prompt works correctly。If not, fall back to chain both with explicit ordering
R4 — Cross-repo race: caller skill --source-issue lands in sister repo before v1 of #45 ships → opportunity to use flag missed	Low	v1 explicit doesn't pass flag (graceful);sister issue tracks flag landing,then a small follow-up edit adds flag pass-through
R5 — Step 6.5 placement causes audit lock confusion: Phase=closed already set in Step 6, but Distribution Sync section appended after → user wonders "is the issue really closed?"	Low	Skill prose explicit: "Phase=closed locks audit at Step 6;Step 6.5 is follow-up action,not lifecycle gate";closing comment has clear ### Distribution Sync section heading separating from main summary

Test Plan

(Markdown skill changes — no automated test framework per #62 follow-up;manual smoke matrix:)

#	Repo type	Setup	Expected Step 6.5 behavior
1	Pure plugin (marketplace member, no binary)	psychquant-claude-plugins/plugins/issue-driven-dev	Detect type=plugin → AskUserQuestion 3-opt;chain /plugin-tools:plugin-update issue-driven-dev
2	Pure MCP (binary wrapper, not marketplace member)	hypothetical clone	Detect type=mcp → AskUserQuestion 3-opt;chain /mcp-tools:mcp-deploy
3	Mixed plugin+MCP (e.g. che-zotero-mcp)	che-zotero-mcp checkout	Detect type=plugin+mcp → AskUserQuestion 3-opt;chain plugin-update (D3 superset rule)
4	Non-distribution (e.g. issue-driven-development itself)	current repo	Detect returns n/a → silent skip Step 6.5 (no AskUserQuestion);1-line audit (detection: not a distribution repo)
5	Skip path (env var)	IDD_DISTRIBUTION_SYNC_PROMPT=false /idd-close #N on plugin repo	Detection runs, but AskUserQuestion suppressed;audit line Distribution sync prompt skipped (IDD_DISTRIBUTION_SYNC_PROMPT=false)
6	User picks "skip"	Plugin repo, user picks skip — manual later	Audit ### Distribution Sync Pending + provide manual command
7	User picks "n/a"	Plugin repo, fix is internal-only (test infra), user picks not applicable	Audit ### Distribution Sync — Not Applicable
8	Backward compat	Existing /idd-close invocation on non-distribution repo	Step 6.5 silent (no behavior change observed by user)

Empty 6-AI verify will catch logic errors;these smoke tests document expected behavior for sister-issue / future test-infra work。

Out-of-scope (will NOT be touched)

• ✗ Cross-repo --source-issue flag added to plugin-tools:plugin-update / mcp-tools:mcp-deploy / cli-tools:cli-deploy — sister issue in psychquant-claude-plugins repo (per Step 4.7 explicit scope clarification)
• ✗ idd-implement Step 5.x early-surface distribution prompt — separate follow-up if value confirmed (could share references/distribution-detection.md)
• ✗ Auto-detect "issue affects user-facing surface vs internal" — relies on user not applicable opt-out instead (per acceptance criteria simplicity)
• ✗ Release tag auto-cut — release-tier responsibility (per common-release-flow.md),not close-tier
• ✗ Test infra to validate detection logic — covered by [docs] Add chain-vs-bulk note in usecase-routing.md decision tree section (verify follow-up from #49) #62 follow-up (no test harness exists in repo today)
• ✗ Extending wrapper keyword list beyond gh release download and curl.*github.com.*releases — out per D2;extension hook documented in reference doc

Tangential Observations (filed mid-plan, v2.42.0+ #524)

Tangential Observations: filed #66 (D3 dependency verification — common-plugins.md plugin-update Phase 1.5 cascade claim)

[kiki830621]

Implementation Complete

Checklist (synced from TaskList)

• plugins/issue-driven-dev/references/distribution-detection.md (NEW) — canonical contract: 3 detection helpers + walk-up algorithm + D3 superset rule + extension protocol + smoke matrix → commit 0c7431a
• plugins/issue-driven-dev/skills/idd-close/SKILL.md — insert Step 6.5 (Distribution Sync chain) between Step 6 and Step 7, with detection delegation + 3-option AskUserQuestion as prose + audit trail PATCH + failure-mode summary → commit 4765092
• plugins/issue-driven-dev/skills/idd-close/SKILL.md — Step 0.5 Bootstrap Task List add distribution_sync_chain_detection entry between auto_update_body and report_result → commit 4765092 (same)

Legend: - [x] done · - [~] skipped · - [-] won't fix
idd-close will refuse close if any - [ ] remains.

Changes

• 0c7431a docs(distribution-detection): add canonical contract for distribution detection (Refs feature: /idd-close should chain to plugin-update / mcp-update / cli-update for distribution-aware close #45)
• 4765092 feat(idd-close): add Step 6.5 distribution sync chain detection (Refs feature: /idd-close should chain to plugin-update / mcp-update / cli-update for distribution-aware close #45)

Files Changed

 plugins/issue-driven-dev/references/distribution-detection.md | 189 +++++++++++
 plugins/issue-driven-dev/skills/idd-close/SKILL.md            | 128 ++++++++
 2 files changed, 317 insertions(+)

Smoke Tests (manual — pending real-world fire)

(No automated test framework per #62 follow-up. The 8-case smoke matrix in Implementation Plan / references/distribution-detection.md will be exercised next time /idd-close runs against a plugin/MCP/CLI repo. Current repo issue-driven-development itself returns n/a so cases 1/4/8 will validate silent skip when this PR is closed.)

Decision Points (resolved per Plan)

• D1 walk-up: $REPO_ROOT → $HOME (find_idd_config convention)
• D2 keywords: gh release download + curl.*github.com.*releases (extension hook in ref doc)
• D3 mixed-type: chain plugin-update only — superset cascade per common-plugins.md (filed [bug] Verify common-plugins.md plugin-update Phase 1.5 cascade claim (mid-plan tangential from #45) #66 to audit claim)
• D4 v1 caller flag: no --source-issue flag (sister issue tracks caller-side)
• D5 escape hatch: env var IDD_DISTRIBUTION_SYNC_PROMPT=false

Sister Bugs Filed (mid-impl, v2.44.0+ #526)

(none surfaced — all changes were narrative/docs to skill markdown and a NEW reference doc;no adjacent files touched, no grep paths revealed sister patterns. The mid-plan tangential #66 was already filed in /idd-plan Step 2.5 and is referenced in D3 audit dependency.)

Scope Compliance

✅ All changes within #45 scope (per Step 4.7 user clarification: single repo PsychQuant/issue-driven-development, deferred cross-repo --source-issue flag to sister issue in psychquant-claude-plugins).

• 2 files,2 commits,each Refs #45 only
• No accidental edits to other skills
• No drift between idd-close/SKILL.md Step 6.5 prose and references/distribution-detection.md canonical contract (both ship in same PR)

Cluster Note

Single-issue PR (not cluster-PR). Sister issue (caller-side --source-issue flag) explicitly deferred per scope clarification.

Next: verification pending

/idd-verify --pr <N> once PR opens (Phase 5.5).

Sister Bugs Filed (mid-impl, v2.44.0+ #526) — UPDATE

• In-scope fix surfaced + applied:Step 4 公佈了 $CLOSING_COMMENT_ID 但既有 Step 4 沒 capture URL → numeric ID → Step 6.5 PATCH 會 fail。Fixed in same PR per IC_R011 3-option (filed = "fix in-scope" rather than separate issue) → commit 023748c fix(idd-close): Step 4 capture closing comment ID for Step 6.5 PATCH

無其他 sister bug surfaced — pure markdown skill changes,no adjacent code touched。

[kiki830621]

Verify (via PR #67) — Round 1

Result: FAIL — 5 P1 blocking + 4 P3 follow-up
Full report: #67 (comment)

This issue's findings: see "#45" content in the linked report.

Critical convergent finding (3 independent reviewers): jq schema mismatch — is_plugin_marketplace_member queries .source.git (object), real marketplace.json uses "source": "./plugins/X" (string). Detection silently dead-on-arrival for 100% of real plugin repos.

Engine note: 3 of 5 Claude reviewers hit Anthropic API usage limit (resets 7:20pm Taipei). Report uses Codex + regression + devil's advocate (3 independent sources;converge strongly). Re-verify with full 6-AI after fixes ship.

Iterating fix in-scope on same branch + re-running verify next.