Problem
scripts/process-attachments.sh 不吃 --cwd，所以在 cross-repo invocation 下會從 session cwd 推導 target repo，對錯的 repo 查 issue。
實際觀測（2026-08-18，/idd-all #383 --cwd <path-to-local-clone>，session cwd 在另一個不相關的 repo）：
$ IDD_CALLER=idd-diagnose bash scripts/process-attachments.sh download 383
GraphQL: Could not resolve to an issue or pull request with the number of 383. (repository.issue)
$ IDD_CALLER=idd-close bash scripts/process-attachments.sh verify 383
✗ Cannot resolve target repo. Pass --repo owner/repo or run from inside an idd-config'd repo.
兩次都不是 #383 真的不存在，而是 helper 找錯了 repo。
Type
bug
Root cause（初判，待 diagnose 確認）
idd-diagnose / idd-implement / idd-close 三個 skill 都已支援 --cwd，且各自的文件明寫 substitution rule（見 references/cross-repo-cwd.md）：
git X → git -C "$CWD" Xgh issue/pr/repo X → gh ... X -R "$GITHUB_REPO"
但那條規則作用於 skill 內的 bash 範例，管不到被呼叫的 helper script。三個 skill 呼叫 helper 的方式都是：
IDD_CALLER=idd-diagnose bash $CLAUDE_PLUGIN_ROOT/scripts/process-attachments.sh download $NUMBER
——$CWD 沒有被傳進去。helper 於是自己走 walk-up config / git remote 偵測，落在 session cwd 上。
Expected
helper 接受 --cwd <path>（或 --repo owner/repo），三個呼叫端把已解析的 $CWD / $GITHUB_REPO 傳下去，cross-repo invocation 下能對正確的 repo 查 issue 與抓附件。
Actual
helper 對錯的 repo 查詢。三種 exit path 都受影響：
| 呼叫端 |
Step |
觀測到的後果 |
idd-diagnose |
1.5 download |
回 GraphQL not-found，寫不出正確 manifest |
idd-implement |
1.2 check |
同源，manifest 對不上 |
idd-close |
1.4 verify |
回 Cannot resolve target repo，gate 無法判讀 |
Impact — 為什麼這比它看起來嚴重
單獨看是小事（#383 本來就沒有附件，所以無實害）。但這個缺口踩到了 IDD 自己的一條鐵律：
idd-diagnose Step 1.5 明文寫著——
忽略附件 = 忽略來源，違反鐵律。
而 idd-close Step 1.4 的 verify 是用來擋「closing comment 引用了已失效的 attachment path」。在 cross-repo 情境下，這兩道都變成結構上跑不到，且失敗方式是看起來像沒附件，而不是明顯報錯。
換言之：一個有附件的 issue，用 --cwd 跑 /idd-all，會安靜地走完整條 pipeline 而完全不處理附件——沒有任何一步會說「我沒讀到你的附件」。這正是這類 helper 缺口最貴的地方。
順帶一提，#189 已經處理過 manifest 損毀時 verify 會 false-PASS exit 0 的問題；本 issue 是同一條線上的另一個 false-negative 入口。
建議修法（供 diagnose 參考）
- helper 加
--cwd / --repo 參數，優先序高於自動偵測
- 三個呼叫端把已解析值傳下去
- 順帶考慮：偵測不到 repo 時，helper 目前
download 回 exit 0（配 GraphQL 錯誤訊息），verify 回非零。兩者對「無法判定」的處理不一致——照 #189 的教訓，無法判定不該當成 PASS
Source: residue from PsychQuant/che-apple-mail-mcp#383 at /idd-close time (Step 3.6)
Problem
scripts/process-attachments.sh不吃--cwd，所以在 cross-repo invocation 下會從 session cwd 推導 target repo，對錯的 repo 查 issue。實際觀測（2026-08-18，
/idd-all #383 --cwd <path-to-local-clone>，session cwd 在另一個不相關的 repo）：兩次都不是
#383真的不存在，而是 helper 找錯了 repo。Type
bug
Root cause（初判，待 diagnose 確認）
idd-diagnose/idd-implement/idd-close三個 skill 都已支援--cwd，且各自的文件明寫 substitution rule（見references/cross-repo-cwd.md）：但那條規則作用於 skill 內的 bash 範例，管不到被呼叫的 helper script。三個 skill 呼叫 helper 的方式都是：
——
$CWD沒有被傳進去。helper 於是自己走 walk-up config / git remote 偵測，落在 session cwd 上。Expected
helper 接受
--cwd <path>（或--repo owner/repo），三個呼叫端把已解析的$CWD/$GITHUB_REPO傳下去，cross-repo invocation 下能對正確的 repo 查 issue 與抓附件。Actual
helper 對錯的 repo 查詢。三種 exit path 都受影響：
idd-diagnoseidd-implementidd-closeCannot resolve target repo，gate 無法判讀Impact — 為什麼這比它看起來嚴重
單獨看是小事（
#383本來就沒有附件，所以無實害）。但這個缺口踩到了 IDD 自己的一條鐵律：idd-diagnoseStep 1.5 明文寫著——而
idd-closeStep 1.4 的verify是用來擋「closing comment 引用了已失效的 attachment path」。在 cross-repo 情境下，這兩道都變成結構上跑不到，且失敗方式是看起來像沒附件，而不是明顯報錯。換言之：一個有附件的 issue，用
--cwd跑/idd-all，會安靜地走完整條 pipeline 而完全不處理附件——沒有任何一步會說「我沒讀到你的附件」。這正是這類 helper 缺口最貴的地方。順帶一提，
#189已經處理過 manifest 損毀時verify會 false-PASS exit 0 的問題；本 issue 是同一條線上的另一個 false-negative 入口。建議修法（供 diagnose 參考）
--cwd/--repo參數，優先序高於自動偵測download回 exit 0（配 GraphQL 錯誤訊息），verify回非零。兩者對「無法判定」的處理不一致——照#189的教訓，無法判定不該當成 PASSSource: residue from PsychQuant/che-apple-mail-mcp#383 at /idd-close time (Step 3.6)