一句話：本卡屬 FR-099（母卡 CM-母卡號），第 3 棒：GitLab／GitHub 外部整合設定的歸屬收尾，以及主專案殘留清查。依賴第 2 棒完成。
第 2 棒把意見回饋的主體搬進套件了。這一棒處理旁邊那塊：GitLab／GitHub 外部整合的設定。管理員可以在後台填 GitLab 的網址和金鑰，開啟之後每筆意見回饋會同時往 GitLab 發一則 issue。決策者 2026-09-16 已拍板這塊保留。
這一棒要確認：設定的讀寫路徑歸屬對不對、四個相關權限點有沒有對齊、以及主專案有沒有還沒清乾淨的殘骸。
外部整合的設定不是走意見回饋自己的表，是走系統設定（system_configs 的 ISSUE_INTEGRATE_CONFIG 群組），讀寫要繞 RLS 抓 ROOT 租戶的平台層設定。這條線跨到 jedi-system-core，跟第 2 棒的主體搬遷是兩件事，混在一起做會讓那一棒太厚。
① 設定讀取路徑。infra/system_config/system_config_root_reader.py 的 read_root_config_value()——這支是主專案的東西（讀 ROOT 繞 RLS 是主專案的多租戶規則）。第 2 棒應該已經把它改成 port 由主專案答。本棒確認那個 port 的形狀合理、沒有把「讀 ROOT」這個產品規則洩進套件。
② 四個能力點。套件 plugin/contract.py:22 已宣告 issue-integrate-config.{create,read,update,delete}，皆 is_platform=True。但 DEV 庫 capabilities 表實查只有 create 與 delete 兩個（read 與 update 沒有）。⚠️ 這是首腦實查發現的落差，要查清楚是 seed 沒跟上、還是宣告多了兩個——兩種情況修法完全不同。
③ 套件 contract.py 的註解寫「本套件 route 目前不守這四項（設定頁在前端），列出來是因為前端選單與 route_capabilities 認它們」。確認這句在第 2 棒之後還成立。
④ FE 設定頁 src/views/issue-integrate-config/IssueIntegrateConfigForm.vue 走的是通用的 SYSTEM_CONFIG 端點（/system/config/ISSUE_INTEGRATE_CONFIG/GITLAB），不是 feedback 自己的端點。確認第 2 棒沒動到這條、頁面仍正常。
⑤ 主專案殘留清查：grep 確認 api/feedback、api/label、app/feedback、domain/feedback、infra/feedback、di_containers/feedback 六處已無檔案；REGISTERED_APPS 已無 feedback／label 兩列；di_containers/issue 的 label 那半已收掉沒有重複建。
⑥ 順手查有沒有第三個漏網：用「按行為 grep」的方式（不是按名字）掃主專案還有沒有其他模組實際上是在包 jedi-issue——grep -rn jedi_issue 主專案，逐處確認歸屬。首腦 2026-09-16 查到的 35 處全在 feedback／label／core-plugins 三處，但第 2 棒做完後應該剩很少，有多的就是漏網。
① FE 開後台的「議題整合設定」頁，讀出 GitLab 與 GitHub 兩組設定（DEV 現況 enable 都是 false），改一個欄位存檔再讀回，確認有存進去。
② 實際把 GitLab enable 打開做一次端到端測試——⚠️ 這需要一組可用的 GitLab 測試專案與 token。沒有就明寫「未驗，因缺測試憑證」，不要報成通過（驗收打折要當場講明，CLAUDE.md 2026-08-22 紀律）。驗完把 enable 改回 false。
③ capabilities 表落差查清楚後，把查證結果與修法寫進回寫，需要動 seed 的先回寫問決策者再動。
④ 殘留 grep 的實際輸出貼進回寫，不要只寫「清乾淨了」。
⑤ 跑 test/test_module_boundaries.py 與套件 tests/。不跑全量 pytest。