[bug] idd-implement PR-body template generates an auto-close trap (/idd-close #N parsed by GitHub Source 1) #173

Problem

The idd-implement Step 5.5 PR_BODY template emits:

- [x] **Verify-gated**: post-verify PASS = ready to merge → /idd-close #${NUMBER} after merge

GitHub's closingIssuesReferences (the authoritative parser the verify Step 0.8 Source 1 relies on) parses close #N out of /idd-close #N — hyphen-splitting idd-close into the keyword close. So a PR opened by idd-implement on the PR path is linked to auto-close its own issue on merge, bypassing the /idd-close checklist gate + closing summary — the exact failure class #87/#97/#11/#13 fought.

Evidence (dogfooded this session)

PR #171 (for #170) was opened with a body containing /idd-close #170 after merge. gh pr view 171 --json closingIssuesReferences returned .../issues/170 (would auto-close). After rewriting the line to run the idd-close skill manually on the issue (no close adjacent to #<digit>), closingIssuesReferences went empty. So /idd-close #170 was the trigger.

Contradicted assumption

idd-verify Step 0.8 explicitly claims: "/idd-close #N 這類 skill invocation 在 Source 1 天然零誤判（不出現在 closingIssuesReferences）". Empirically false — Source 1 (GitHub) applies no hyphen-prefix guard; only the plugin's own Source 2 regex ([^-/[:alnum:]] prefix) excludes it. The two sources genuinely disagree on idd-close, and Source 1 (the authority) flags it.

Impact

• Every idd-implement PR-path PR (and likely idd-all / idd-all-chain using the same template) silently links to auto-close on merge → /idd-close gate bypassed unless the human notices or idd-verify Step 0.8 runs + the user heeds the warning.
• This session's PR [exploration] 平行執行多個 IDD 的隔離機制 — worktree vs branch 防衝突（#164 子問題） #167 (PR feat: parallel IDD via git worktree isolation (#167) #168) likely had the same trap — it was squash-merged with a controlled message, so the body trap may or may not have fired; worth auditing.

Proposed fix (待 diagnose)

• Change the idd-implement / idd-all / idd-all-chain / pr-flow.md PR_BODY templates to avoid close/fix/resolve immediately before #<digit>. E.g. → run the idd-close skill on this issue after merge (no auto-close trailer), or use literal-letter #N.
• Update idd-verify Step 0.8's documented claim about Source 1 + idd-close (it is NOT zero-false-positive there).

Out of scope

• The verify gate (Step 0.8) already CATCHES this at verify time (it warned on PR fix: spectra-archive-post-ic linked-issue escape hatch + prose detection (#170) #171, which is how this was found) — the gate works. This is about the upstream template that creates the trap in the first place.

Source: surfaced during /idd-verify #170 --pr 171 Step 0.8 auto-close detection (the gate caught the plugin's own template on PR #171). Sister concern from #170.

Current Status

Phase: closed
Last updated: 2026-05-31 by /idd-close

Key Decisions

• Complexity = Simple; fixed 5 PR-body template instances + 2 stale idd-verify false claims + regression guard; v2.75.1
• 6-AI verify (PR fix: PR-body templates no longer emit GitHub auto-close trap (#173) #174): PASS, 0 blocking; 4 non-blocking findings (DA MEDIUM + Codex HIGH) all fixed in-PR (5596453)
• Squash-merged to main (870ce14); issue remained OPEN post-merge → auto-close did NOT fire (end-to-end proof of the fix)
• Closed via /idd-close (the manual gate this change exists to protect)

Scope Changes

• (none)

Blocking

• (none — closed)

Commits

• 870ce14 (squash on main) fix: PR-body templates no longer emit GitHub auto-close trap ([bug] idd-implement PR-body template generates an auto-close trap (/idd-close #N parsed by GitHub Source 1) #173)