feat: repo 地圖 + global config（~/.claude/.idd/global.json）— 讓 target resolution 知道哪些層級實際存在，上收停在當前 git repo 邊界

[kiki830621]

Problem

#301 提議在 target resolution 加入 residual clause——未列舉事項依「事務性質」歸屬。但那條判準要能執行，需要先知道哪些層級實際存在：判準說「這件事屬 project 層」時，若該 project 根本沒有自己的 tracker，往下歸就會落空。

目前 IDD 完全沒有 global 層，也沒有任何跨 repo 的階層知識。每次 target resolution 只看得到 cwd 往上第一個 config，看不到「這台機器上有哪些 repo、誰是誰的上層」。

Original text（使用者，2026-08-12 對話逐字）:

「我在想可能如果要考慮idd repo的話要考慮有沒有地方政府，如果最下層的repo已經沒了的話就不要往下，所以可能要有一個repo的地圖，是不是存在~/.idd (當idd的global setting如何？ 你可以參考其他的repo)」

「好，照你的建議好，上收其實通常會到我現在正在開起的專案的git，要跨過的話通常會需要特別指定」

「地方政府在不在」是核心比喻：階層可以缺席，事務要歸給實際存在的最近層級，而不是歸給一個不存在的層。

---

Type

feature

Priority

P1（本週）— #301 的前置基礎設施

---

現況調查

1. walk-up 其實已經會經過 $HOME/.claude/.idd/

references/config-protocol.md 的 walk-up 終止條件寫著「don't go above $HOME」，但檢查在 break 之前：

while [ "$dir" != "/" ] && [ "$dir" != "$HOME/.." ]; do
  if [ -f "$dir/.claude/.idd/local.json" ]; then ... return 0; fi   # ← 先檢查
  [ "$dir" = "$HOME" ] && break                                      # ← 才 break
  dir=$(dirname "$dir")
done

所以 $HOME/.claude/.idd/ 這個路徑已經在讀取路徑上，只是：

• 沒有 global 語意——它會被當成「$HOME 這個目錄的 local config」，而 $HOME 不是 repo
• 實測該目錄存在但為空（0 檔案），是某次在 home 執行留下的空殼

2. 沒有任何 global / registry / 階層概念

grep -niE 'global|XDG|user-level|machine-wide' 掃 config-protocol.md 只命中 walk-up 的 $HOME 邊界描述。六機制全部是單點解析（解出一個 repo），沒有一個機制看得到 repo 之間的關係。

3. 兩種 config 格式並存（掃描器必須兩種都認）

實測一台機器上的分布：

格式	數量
.claude/.idd/local.json（新，#195 規定新裝一律用此）	20+
.claude/issue-driven-dev.local.json（legacy，walk-up 仍 fallback 解析）	17

任何掃描實作若只認新格式，會漏掉近半數 repo——而漏掉的那些會被判成「該層不存在」，觸發錯誤的上收。

---

Expected

A. Global config：~/.claude/.idd/global.json

位置決定（考慮過 ~/.idd/，不採用）：

1. walk-up 已經會經過 $HOME/.claude/.idd/ — 零新增掃描邏輯，只要多認一個檔名
2. 與 project 層 .claude/.idd/local.json 完全對稱，只差 local / global
3. IDD 是 Claude Code plugin，~/.claude/ 是其生態家（settings.json / rules/ / plugins/ 皆在此）；~/.idd/ 等於在 home 再開一個 dotdir
4. 檔名用 global.json 而非 local.json 是必要的——後者會讓 $HOME 被誤讀成「一個 repo」，語意汙染既有的 repo-boundary 判定

生態先例：同一套工具鏈中，codex-pro 已採 ~/.codex-pro/profile.yaml（global）+ <project>/.codex-pro/profile.yaml（project）雙層 resolve。本案是同一模式，但寄生在 ~/.claude/ 之下而非另開 dotdir。

B. 地圖：自動推導，不手寫

手寫 registry 會 stale，而 stale 正是本問題的病因——#301 記錄的那條分散案例，成因就是某 project 中途被 extract 成獨立 repo 而沒有任何地方被更新。手寫地圖只是把同一種病從 walk-up 搬到 registry。

地圖可以完全自動推導：每個 repo 的 .claude/.idd/local.json（或 legacy）已經自我宣告了它的 tracker。掃描即得圖。因此 global.json 存的不是 repo 清單，而是掃描參數與快取控制：

{
  "scan_roots": ["~/<work-root-a>", "~/<work-root-b>"],
  "cache_ttl_seconds": 86400
}

single source of truth 仍在各 repo 自己的 config，global 只是索引 + 快取。實測規模：一個工作根 7 個 repo、另一個 30+ 個，全掃成本可接受（配 TTL 快取後更低）。

C. 缺層上收：階層可以缺席

判準與地圖必須分開——「判準說該歸哪一層」和「那一層是否存在」是兩種不同的失敗，混在一起會 debug 不出來。

• 性質判準（feat: config-protocol 加入 residual clause — 未列舉事項依「事務性質」歸屬，取代機械 cwd fallback（憲法第111條均權制度） #301）決定：這件事屬於哪一層
• 地圖決定：那一層實際上有沒有 tracker
• 不存在 → 沿階層往上找最近的存在層級

D. 上收天花板：當前 git repo boundary，跨越需明示

這是安全約束，不是最佳化。 上收預設停在 cwd 所在的 git repo 邊界；要把 issue 開到該 repo 之外的上層，必須明示（--target，或 config 中顯式宣告的上層關係）。

理由：repo 邊界即「轄區」。事務移出轄區若可以默默發生，就會出現「以為開在自己專案、其實開到上層」的靜默錯誤——而這種錯誤事後極難察覺（issue 就在別的 tracker 躺著，沒有任何訊號）。

實作上可直接沿用既有的邊界語彙，不必新造：

• walk-up 現有的 stop boundary：「a directory containing .git/ AND either config file (treat as repo boundary)」
• Mechanism 3.5 的 submodule boundary detection（feat: submodule support in IDD config — let parent config route submodule operations #162）——submodule 情境下「當前 repo」是 submodule 自己而非 superproject，此語意必須維持

E. 上收到頂仍無解 → 問，不要猜

一路上收會停在 global，但 global 不是 tracker，不能開 issue。兩條路：

1. 規定「最上層必須指定一個 catch-all general repo」（憲政類比：中央永遠存在）
2. 上收到頂仍無解 → AskUserQuestion 交使用者裁決

建議取 (2)。取 (1) 會要求使用者指定一個 catch-all，而那個 repo 在實務上會變成垃圾桶——所有判不出來的東西都往那裡倒，久了失去分類意義。(2) 也與 #301 引用的憲法第 111 條後段「遇有爭議時，由立法院解決之」一致：判不出來時交裁決，而非塞給預設。

---

Actual

• 無 global config 層（~/.claude/.idd/ 目錄存在但空）
• 無 repo 地圖、無階層知識；六機制皆為單點解析
• 缺層無偵測：判準若指向一個沒有 tracker 的層，行為未定義
• 上收無邊界概念（因為根本沒有上收機制）

Impact

• feat: config-protocol 加入 residual clause — 未列舉事項依「事務性質」歸屬，取代機械 cwd fallback（憲法第111條均權制度） #301 的 residual clause 無法執行：判準算出「屬 project 層」之後沒有下一步
• 跨 repo 總覽不可能：idd-list 等只能看單一 repo，看不到跨 repo 的工作全貌
• 靜默錯置風險：若日後實作上收卻不設天花板，issue 會默默開到上層 repo，事後無訊號可查

Out-of-scope

• 性質判準本身（feat: config-protocol 加入 residual clause — 未列舉事項依「事務性質」歸屬，取代機械 cwd fallback（憲法第111條均權制度） #301）——本案只提供「哪些層存在」的事實，不決定「該歸哪層」
• 既有已分散 issue 的回收 / 搬遷
• Mechanism 6 groups 的跨 repo cross-link（正交）

相關

• feat: config-protocol 加入 residual clause — 未列舉事項依「事務性質」歸屬，取代機械 cwd fallback（憲法第111條均權制度） #301 — residual clause（性質判準）。本案是其前置基礎設施：feat: config-protocol 加入 residual clause — 未列舉事項依「事務性質」歸屬，取代機械 cwd fallback（憲法第111條均權制度） #301 的判準需要本案的地圖才能執行
• feat: submodule support in IDD config — let parent config route submodule operations #162 — submodule boundary detection。本案的「當前 git repo boundary」必須沿用其 submodule 語意，不可退化成 superproject
• Migrate E1/E2 config write-back onto .claude/.idd/local.json (match config-protocol; E-TP already does) #195 — .claude/.idd/local.json 新路徑規定。本案的掃描器必須同時認 legacy 格式，否則近半數 repo 會被誤判為不存在

---

Current Status

• Phase: diagnosed
• Complexity: Spectra（Layer 2 necessary + Layer 3 三項全中；routing step 4 命中即停）
• Conflict class: C_shared_module_coord（具名共享資源：references/config-protocol.md、scripts/lib/resolve-submodule-route.sh）
• Next: /spectra-discuss（Spectra 預設；opt-out 走 /spectra-propose 需零 open questions —— 本案 Residue 與 R3 cache 去留尚未拍板，不符 opt-out 條件）
• Updated: 2026-08-12（diagnosed — Diagnosis + Layer V + routing audit + Sister Concerns 已 post；sister 32 個既有 repo 仍用 legacy config 路徑 — #195 只遷了 write-back 端，既有 config 無遷移路徑也無 deprecation 聲明 (sister concern from #302) #303 filed）

[kiki830621]

Diagnosis

Attachments: issue 無 attachment（process-attachments.sh exit 0，空 manifest 已寫）。

Type

feature

Root Cause / Analysis

需求拆解（5 項，全部來自 issue body 的 Expected）

#	需求	可 operationalize？
A	global config 落在 ~/.claude/.idd/global.json	是
B	地圖自動推導（掃各 repo 自宣告的 config），不手寫 registry	是
C	判準與地圖分離：判準說「哪一層」、地圖說「那層存不存在」	是
D	上收天花板 = 當前 git repo 邊界，跨越需明示	是
E	上收到頂仍無解 → AskUserQuestion，不設 catch-all	是

插入點：canonical resolution algorithm 的 step 3 與 step 5 之間

現行 resolve_target() 的關鍵三行：

matched_group = first(g in config.groups where evaluate(g.when, context))
matched_cand  = first(c in config.candidates where evaluate(c.when, context))
tentative_default = matched_group or matched_cand or config.github_repo

or config.github_repo 就是 #301 所說的「機械 fallback」——predicates 沒命中即直接用 walk-up 找到的那個 config 的預設 repo，中間沒有任何一步問「這件事的性質屬於誰」，也沒有任何一步問「那一層是否存在」。本案（#302）補的是後者，#301 補的是前者，兩者在同一個插入點接手。

三組實測數據（在一台實際使用中的機器上量）

(1) 掃描成本 — 遠低於預期，cache_ttl_seconds 可能是 premature optimization

方式	耗時	命中 config 數
天真 find（無 prune）	1.257s	63
加 prune（node_modules / .git / .build）	0.399s	63（相同）

prune 版快 3 倍且結果一致。0.4 秒的全掃，配 TTL cache 反而引入新的 stale：cache 過期前新建立的 repo 看不到——這與本 issue 自身「手寫 registry 會 stale、stale 是病因」的核心論證直接衝突，只是把 stale 從 registry 搬到 cache。詳見 Risks。

(2) 深度敏感度 — 設淺會漏近半，而漏掉的代價是「錯誤上收」

maxdepth	命中 config 數	相對 depth=10 漏掉
4	38	32（46%）
6	63	7
8	69	1
10	70	—

失敗鏈很短：掃不到某 repo 的 config → 地圖認為該層不存在 → 觸發上收 → issue 開到上層。這正是本案要防的錯誤，卻會被一個保守的 maxdepth 預設製造出來。深度必須設得夠深（≥10）或改用 prune-only 控成本；漏掉的代價遠高於多掃幾層的成本。

實務結構佐證：research line → article 的多層 submodule 巢狀，config 深度可達 8 以上。

(3) 格式分布 — legacy 佔 46%，只認新格式會誤判近半 repo 不存在

檔名	數量
.claude/issue-driven-dev.local.json（legacy）	32
.claude/.idd/local.json（新，#195）	37

設計缺陷修正：global.json 不該走 walk-up

Issue body 主張「walk-up 已經會經過 $HOME/.claude/.idd/，零新增掃描邏輯」。此論證需要修正——查 find_idd_config() 實作，它只檢查兩個檔名：

if [ -f "$dir/.claude/.idd/local.json" ]; then ... fi
if [ -f "$dir/.claude/issue-driven-dev.local.json" ]; then ... fi

global.json 檔名不同，walk-up 根本看不到它。而這反而是好事：walk-up 的語意是「找到 config 就 return 該 repo」，但 global.json 不含 github_repo（它是掃描參數，不是 target config）；若讓它進 walk-up，會使 walk-up 回傳一個沒有目標的 config。

修正後的精確說法：位置選 ~/.claude/.idd/global.json 仍然正確（同目錄、對稱命名、且刻意不污染 walk-up），但讀取方式是 resolve 開始時獨立載入一次（如 git config --global 的語意），不是 walk-up 的最後一站。「零新增路徑探索」成立，「零新增讀取邏輯」不成立。

config 與 cache 分離（既有先例）

~/.cache/idd-route/stats.jsonl 已存在於本機——IDD 生態已有 ~/.cache/idd-* 的 machine-generated 資料先例（見 references/agent-routing.md）。因此：

性質	位置	誰寫
config（人編輯、需版本語意）	~/.claude/.idd/global.json	使用者
地圖 cache（若最終決定要）（機器生成、可隨時重建）	~/.cache/idd-repo-map/	掃描器

不要把 cache 寫進 ~/.claude/.idd/——那裡是 config 的家。

Impact

影響的檔案

• references/config-protocol.md（731 行）— 新增 global config schema 段 + 地圖機制段；修改 canonical resolution algorithm（normative，step 3→5 之間插入）
• scripts/lib/ — 新增 map resolver（與既有 resolve-submodule-route.sh / resolve-plugin-candidates.sh 同類、同命名慣例）
• scripts/lib/resolve-submodule-route.sh — 需求 D 的「當前 git repo 邊界」必須沿用其 submodule 語意，可能需擴充而非新造
• 各 idd-* skill 的 Step 0.5 target resolution 段 — 消費端；若 protocol 改了而 skill 文件沒同步，會出現 spec 與實作分岔

影響的使用者流程

• 所有 idd-* 的 target resolution（issue / diagnose / implement / verify / list / close）
• 新增：跨 repo 總覽成為可能（idd-list 可消費地圖）

Strategy

• 定 global.json schema（scan_roots 必填；max_depth / prune_names / cache 是否存在為待決項）
• 決定 cache 去留（見 Risks R3；建議預設不 cache，先量再決定）
• 寫掃描器：兩種 config 格式都認、prune 控成本、深度預設夠深
• 從各 repo 的 github_repo + 檔案系統路徑推導階層（誰是誰的上層）
• 實作「該層是否存在」查詢（給 feat: config-protocol 加入 residual clause — 未列舉事項依「事務性質」歸屬，取代機械 cwd fallback（憲法第111條均權制度） #301 的判準消費）
• 實作上收：沿階層往上找最近的存在層級
• 實作天花板：停在當前 git repo 邊界，沿用 resolve-submodule-route.sh 的 submodule 語意
• 實作到頂裁決：AskUserQuestion，不設 catch-all
• config-protocol.md 寫入上述全部（normative 段落）
• 測試：深度邊界、legacy 格式、submodule 巢狀、上收天花板、到頂裁決、地圖為空
• 與 feat: config-protocol 加入 residual clause — 未列舉事項依「事務性質」歸屬，取代機械 cwd fallback（憲法第111條均權制度） #301 的介面契約（判準 → 地圖查詢 → 上收）明確定義

Conflict Class

C_shared_module_coord

共享資源具名：references/config-protocol.md（被所有 idd-* skill 引用的 protocol spec，多 issue 並行修改會撞）與 scripts/lib/resolve-submodule-route.sh（需求 D 要沿用/擴充的既有邊界解析器）。改動本身集中在單一 repo、無外部 mutable 資源（無 DB / queue / upload endpoint），但這兩個檔案是跨 skill 的共享面，須協調而非平行編輯。

Complexity

Spectra

routing 序列走到 step 4 即命中並停止（type≠meeting → Layer 1 未命中 → Layer V 未觸發 → Layer 2 + Layer 3 皆命中），故未進入 step 5 硬閘與 step 6 Layer P 評估。

Layer 2（necessary condition）— 命中
改動對外暴露 published protocol 給 future callers：config-protocol.md 本身就是 published protocol，所有 idd-* skill 是其 callers；global.json 的 schema 是需要寫成 documented contract 的新對外面。

Layer 3（confirmation signals）— 三項全中

1. 修改既有 published spec 的 normative behavior — canonical resolution algorithm 要改（step 3→5 之間插入新階段），這是 downstream maintainer 會繼承的 normative 行為
2. 影響 2+ 既有 specs 需 consistency-checking — config-protocol.md + Mechanism 3.5 submodule 語意 + 各 skill 的 Step 0.5 段落
3. Architectural decision with long-term maintenance implications — 引入 global 層是結構性決定；「repo 之間有階層」這個模型一旦寫進 protocol，後續所有 routing 行為都會建立其上

Risks

R1 — maxdepth 預設過淺會製造出本案要防的錯誤（HIGH）
實測 depth=4 漏 46%。漏掉的 config → 該層被判為不存在 → 錯誤上收。保守的深度預設在此不是安全選擇，而是危險選擇，方向與一般直覺相反。

R2 — 只認新格式會誤判近半 repo（HIGH）
legacy 32 / new 37。掃描器必須兩種都認，且新舊同時存在於同一 repo 時要定優先序（沿用 walk-up 既有規則：同層新路徑勝）。

R3 — cache TTL 引入新的 stale，與本 issue 的核心論證衝突（MEDIUM，需決策）
本 issue 主張「手寫 registry 會 stale，所以自動推導」。但 TTL cache 同樣會 stale——cache 有效期內新建的 repo 看不到，症狀完全相同。實測 0.4s 的掃描成本不足以正當化這個風險。建議預設不 cache；若日後 scan_roots 擴大到掃描明顯變慢，再以 mtime-based invalidation（而非 TTL）處理。

R4 — global.json 若誤入 walk-up，會回傳無目標的 config（MEDIUM）
見上方「設計缺陷修正」。實作時必須確保 find_idd_config() 不把 global.json 當成 target config。目前因檔名不同而天然安全，但若日後有人「順手」把 global 加進 walk-up 檢查清單，就會踩到。應在 protocol 明文寫出這條禁令與理由。

R5 — 上收天花板與 submodule 語意的交互（MEDIUM）
Mechanism 3.5 規定 submodule 情境下「當前 repo」是 submodule 自己而非 superproject。天花板若退化成 superproject，會讓 submodule 的 issue 默默上收到 superproject——正是 #162 修掉的那個 bug class 借屍還魂。必須沿用同一個解析器，不可另寫一套邊界判定。

R6 — 與 #301 的介面若未先定義，兩案會各做各的（MEDIUM）
#301 產生「該歸哪一層」、#302 回答「那層存不存在」。介面（判準如何表達層級、地圖如何回應、誰負責上收迴圈）必須在兩案之間先講定，否則會出現兩套不相容的層級表示法。

Residue

• 「地方政府」的比喻承載了一個比本案 scope 更大的直覺：repo 之間存在治理結構，而不只是路徑包含關係。完整形式（某些 repo 對另一些有委辦關係、事務可以「上訴」、層級可以被「凍結」如精省）超出本案；本案只實作「層級存在與否」這一個維度。
• 使用者原話「上收其實通常會到我現在正在開起的專案的 git」——「通常」承載了例外的存在，但例外清單目前無法列舉（尚未遇齊）。本案採「預設停在當前 repo、跨越需明示」把未知例外轉成明示動作，但這是把問題轉形而非解決：哪些情境「應該」預設跨越，仍未知。

Vagueness Pre-check

• V1 (vague WHAT): 2 — Expected 段列出 A–E 五個具名子項，每項均附具體位置（~/.claude/.idd/global.json）、具體格式（scan_roots / cache_ttl_seconds）與選擇理由（四點位置論證）。要做什麼沒有詮釋空間。
• V4 (vague ACCEPTANCE): 3 — 方向明確但無明文驗收條件：未定義「掃描器要通過哪些 case 才算正確」「上收要有哪些 test scenario」「地圖為空時的預期行為」。Diagnosis 的 Strategy 已把測試項列為 checklist item，但 issue 本身沒有 acceptance criteria。此為 3 而非 4：缺的是驗收明文化，不是驗收方向未知。
• Triggered: no — both axes ≤ 3

Complexity routing audit

• 序列走到 step 4 (Spectra) 即命中並停止：type≠meeting (step 1 不適用) → Layer 1 未命中 (step 2) → Layer V 未觸發 (step 3) → Layer 2 + Layer 3 皆命中 (step 4)。
• Hard-gate: not evaluated — routing 在 step 4 已終止，未進入 step 5 硬閘與 step 6 Layer P（Spectra 依 canonical 序列優先於硬閘 / Layer P）。此處明記以免誤讀為「硬閘未觸發」。

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

• Filed 32 個既有 repo 仍用 legacy config 路徑 — #195 只遷了 write-back 端，既有 config 無遷移路徑也無 deprecation 聲明 (sister concern from #302) #303 — legacy config 路徑無遷移路徑（實測 32/69 仍為 legacy）。觸發點：本 Diagnosis 的 Risks R2。Migrate E1/E2 config write-back onto .claude/.idd/local.json (match config-protocol; E-TP already does) #195 只遷 write-back 端，既有 config 的讀取端遷移與 deprecation 聲明皆缺。
• Skipped (a) unactionable — ~/.claude/.idd/ 為空目錄（0 檔案，疑似曾在 $HOME 執行 idd-* 留下）。空目錄無害，且本案（feat: repo 地圖 + global config（~/.claude/.idd/global.json）— 讓 target resolution 知道哪些層級實際存在，上收停在當前 git repo 邊界 #302）正要在該路徑放 global.json，屆時自然填實。不另立案。
• Not sister (既有 issue 已覆蓋) — R5 的 submodule 邊界語意屬 feat: submodule support in IDD config — let parent config route submodule operations #162 既有範圍；R6 的介面契約屬 feat: config-protocol 加入 residual clause — 未列舉事項依「事務性質」歸屬，取代機械 cwd fallback（憲法第111條均權制度） #301 與本案的協調事項，非旁支。

[kiki830621]

Closing Summary

Problem

IDD 沒有任何跨 repo 的階層知識。六個 resolution 機制全部是單點解析（解出一個 repo），沒有一個看得到 repo 之間的關係。所以 #301 提議的 residual clause（依「事務性質」歸屬）無法執行：判準說「這件事屬 project 層」時，沒有東西能回答前一個問題 —— 那一層存不存在。

使用者的比喻是核心：「地方政府在不在」。階層可以缺席；事務要歸給實際存在的最近層級，而不是歸給一個不存在的層。

Root Cause

兩個缺口：

1. 沒有 global 層。grep -niE 'global|XDG|user-level|machine-wide' 掃 config-protocol.md 只命中 walk-up 的 $HOME 邊界描述。而 walk-up 其實已經會經過 $HOME/.claude/.idd/（終止條件的檢查在 break 之前），只是沒有 global 語意 —— 它會被當成「$HOME 這個目錄的 local config」，而 $HOME 不是 repo。
2. 沒有地圖。層級不存在時，resolution 就落到 cwd 碰巧是什麼。

Solution

A. Global 層：~/.claude/.idd/global.json（考慮過 ~/.idd/，不採用，四個理由寫進 config-protocol.md）。檔名必須是 global.json 而非 local.json —— 後者會讓 $HOME 被誤讀成「一個 repo」，汙染既有的 repo-boundary 判定。

B. 地圖：scripts/idd-repo-map.sh，自動推導、永不手寫。

這一點是本張最重要的設計決定：手寫 registry 會 stale，而 stale 正是這個問題的病因本身 —— #301 記錄的那條分散案例，成因就是某 project 中途被 extract 成獨立 repo 而沒有任何地方被更新。手寫地圖只是把同一種病從 walk-up 搬到 registry。所以地圖每次從檔案系統重算，不存成 source of truth。

掃描器認兩種 config 格式（#303 的發現）。漏認一種不是「少一筆」 —— 沒被看到的 config 在語意上等於「該層不存在」，會觸發錯誤的上收。實測一台機器：current 20+、legacy 17，只認新格式會漏掉近半。

Verification

新增 idd-repo-map suite 10 條斷言，含三條針對本張特有失效方式的：兩種格式都必須被看到、node_modules 必須 prune、config 存在但沒有 github_repo 時要明確標示而非讓空字串當成命中。46/46 suites 綠。

Changes

已合併進 main（PR #314）。