本卡屬 FR-101（母卡見建卡後補號），第 2 棒：plugin/ 五檔、domain/ports.py、common/、標籤三層、4 支 SQL migration、各層 __init__。37 檔，只掃不修。

這一棒在做什麼（白話）

套件怎麼被主專案「接上」（哪些守門是必填、缺了會怎樣）、它宣告了哪些權限點又真的守了幾個、回饋類型標籤這條小鏈有沒有隔離、隨套件出貨的四支資料庫腳本用什麼身分寫入、以及 GitLab／GitHub 連線設定是怎麼從主專案拿到的。

為什麼切這一塊

插件骨架是 FR-099 之後才有的形狀，任何棒沒看過。FR-098 A1 在 jedi-asset 同款骨架裡證明「守門殼吵鬧拒絕」是正面案例、「能力點宣告了卻只在前端生效」是產品決策題——本棒要對照 jedi-issue 是哪一種。標籤表與 issues 表零隔離是 FR-081 第 7 項，這次要看新搬進來的程式有沒有把這件事變得更容易被打到。

重點看什麼（工具不照清單走，掃完逐項回頭核，沒碰的自己開檔查並標「（工具未報，人工查證）」）

• ① 能力點宣告 vs 實際執法（plugin/contract.py:20-48）。10 顆：issue-integrate-config.* 四顆 is_platform=True、自陳「本套件 route 不守，由宿主系統設定端點分流守」；feedback.* 五顆＋feedback-view.read 自陳「BE 只守 export 一項，其餘前端選單在認」。要驗：宿主 core/plugins/system_core.py 的 group 對照表真的把 ISSUE_INTEGRATE_CONFIG 守到那四顆嗎（讀宿主檔可以，發現標越界）；feedback.create/read/update/delete 四顆只在前端生效——與 FR-098 第 80 項同一種產品決策題，標明。
• ② 守門殼（plugin/assembly.py:88-105 _assert_api_wiring、plugin/__init__.py:95-130 register）。只驗兩項必填；mount_api=False 時仍寫 runtime context、「最後一次 register 贏」。要問：同一 app 掛兩次的覆寫語意會不會讓後掛的弱 adapters 蓋掉前一次；IssueAdapters 全部 Optional 預設 None（contract.py:99-126）——register() 不帶 adapters 時 IssueAdapters() 空殼在 mount_api=False 下會不會靜默通過；identity／user_name_searcher／integrate_config_provider 三個選填 port 缺了各自退化成什麼。
• ③ 標籤鏈零隔離（infra/label/models/label.py Labels(Base) 無 TenantScopedMixinModel；infra/label/repository/label_repository.py:28 get_labels 無租戶條件；app/label/service/label_service.py:28-54 create／update／delete 三支存在但沒有對外 route）。要驗：標籤是全站共用字典（碼表，回全表正確）還是租戶資料——依 §5「有沒有主人」判準給結論；create_labels 等三支誰呼叫（宿主？無人？），若無人呼叫標死碼；scope 參數從 URL 來、有沒有白名單。
• ④ 隨包 migration 的寫入身分與冪等（migrations/001～004）。002 開頭 SET LOCAL app.is_super_admin = 't' 再寫 ui_routes／route_capabilities；001 直接 INSERT labels（零隔離表）；003 建 feedback_issues（照 DEV 實況、issue_uid 刻意無 FK）；004 RLS 四條 policy＋trigger＋GRANT。要驗：002 的 SET LOCAL 在套件 migration runner 的交易邊界內嗎（plugin/migrations.py）——若 runner 不是單一交易，SET LOCAL 失效但 INSERT 仍跑，症狀是什麼；004 insert policy 帶 org 維度但 003 兩欄 nullable——org 為空的使用者建回饋會被擋嗎（對照 jedi-asset 002 檔頭那段刻意不抄 org 維度的理由）；四支重跑是否真冪等。
• ⑤ 錯誤碼與工具函式（common/enum/error_code.py、common/utils/common_utils.py）。錯誤訊息有沒有把內部路徑／SQL／第三方回應原文帶出去。
• ⑥ domain/ports.py（三個 port 介面＋DTO）。IIntegrateConfigProvider.get_integrate_config() 回的 dict 含 GitLab／GitHub token——這個 dict 在套件內會不會被 log、被放進錯誤訊息、被序列化回前端（grep 全套件 integrate_config／private_token／token 的 logger 呼叫）。

已知背景（未經本輪面板驗證，只是參照）

• FR-081（2026-09-10）六棒掃過 130 檔舊版，19 條歸 6 張卡：CM-1629 DB 密碼散落／CM-1630 意見回饋六操作只有匯出守權限、改刪不驗本人／CM-1631 Google 金鑰外洩／CM-1632 GitHub verify=False 兩處／CM-1633 附件刪除檢查半套／CM-1634 Nexus 明文。撞到標「重複 CM-16xx，位置更新」不另計——CM-1630 與 CM-1632 首腦已開檔確認搬家沒修（新位置見各棒重點）。
• 跨 arc 總表 §3.1 第 7 項：jedi-issue 六張表（issues／labels／三張 mapping／members）完全沒有客戶隔離、也沒有租戶欄（首腦 2026-09-16 DEV 唯讀重查：issues、labels、issue_*_mapping 皆 RLS 關、0 規則；只有新的 feedback_issues 開 RLS、4 規則、不強制）。撞到標「第 7 項」。
• 第 70 項（送空條件回全表）、第 31 項（分頁無上限）為共用底層，撞到標重複。
• 套件 README 曾錯寫「GitHub／GitLab 未使用」，FR-099 第 1 棒已更正——整合是正式功能，宿主 RootIntegrateConfigProvider 從 ROOT 租戶讀設定；不要被任何「沒在用」的殘留註解說服。

怎麼做

第一步：驗 scope 檔數，對上 37 才啟動：

cd /Users/chouraymond/Projects/Jedicogy/module/jedi-python-package/jedi-issue && git ls-files -- jedi_issue/plugin/ jedi_issue/app/label/ jedi_issue/domain/label/ jedi_issue/infra/label/ jedi_issue/domain/ports.py jedi_issue/common/ jedi_issue/migrations/ jedi_issue/__init__.py jedi_issue/app/__init__.py jedi_issue/domain/__init__.py jedi_issue/infra/__init__.py | grep -E '\.py$|\.sql$' | wc -l   # 要回 37