本卡屬 FR-080（母卡 CM-1612），第 4 棒：對外面與插件契約（jedi monorepo）。只掃不修。
掃套件的「門面」（20 檔）：唯一一條對外 API、插件怎麼被主專案掛載、以及套件跟主專案之間的契約。要找的是這扇門有沒有守好。
套件只有一條對外 route——/issue/get_members（api/__init__.py:84），而它只有 @jwt_required()，回傳的是成員名冊。檔頭自陳「沒有能力點、沒有 platform-admin，搬遷紀律是逐字保留」。一條 route 看似很小，但它吐的是人員清單，且 plugin.py（314 行）是全套件最大單檔、決定了整個掛載與 fail-closed 行為。
首腦讀過程式碼後的起點，未經驗證。
jedi_issue/api/__init__.py:11-13 自稱「GitLab／GitHub 整合沒在用，約佔 58%」——首腦已證偽（宿主 feedback_service.py 六處實際呼叫）。工具已知盲點二（會被註解說服）的教科書形狀，FR-075 S2 即此。本套件 docstring 一律當待查證的宣稱。api/routes/issue_member_route.py ＋ api/__init__.py:57-69 的 auth_required 裝飾器（委派宿主注入的 jwt_required()）。要追：任何登入者是不是都能取得成員名冊、名冊範圍是全站還是限某專案／租戶。與 FR-079 的 ① 同型（bulletin.read 定義了卻沒人檢查）——要查 DB capabilities 表有沒有對應能力點卻沒被使用。api/__init__.py:32-33 自陳「缺接線要拒絕掛載不是跳過——跳過的後果是成員清單變公開端點（洩漏全站使用者名冊），而服務照常起得來、健康檢查照樣綠燈」。這是自我宣稱，要驗：plugin.py 的 register() 在 adapters.auth_required 為 None／缺漏時，到底是 raise 還是靜默掛上去。這一條是本棒最重要的。auth_required（:57-69）在 request 期才從 ctx().adapters.auth_required 取守門。要追：current_app.extensions[EXTENSION_KEY] 不存在時會怎樣（KeyError 500 還是繞過）、多 app／測試情境下會不會取到錯的。plugin.py（314 行，全套件最大檔）的四個插槽。 adapters／config／schema_extensions／mount_api。要追：mount_api=False 的逃生門會不會讓 route 不掛但 service 仍可經 DI 被別處呼叫（FR-079 F13 的 AI 儀表板旁路就是這個形狀）、register() 有沒有把敏感物件存進 app.extensions。ports/ 的 provider 名冊。 ports/issue_provider/issue_factory.py（89 行）與 ports/project_member_provider/member_factory.py（35 行）——工廠依 provider 代碼（LOCAL／GITLAB／GITHUB）選實作。要追：provider 代碼能不能被呼叫端指定，能的話使用者就能選擇「用哪個後端」，進而觸發帶公司權杖的對外連線（與 I1 呼應）。FROZEN_URLS 與實際掛載的一致性。 api/__init__.py:90 用集合比對防止拼錯。要確認測試真的在跑，且沒有繞過 mount_routes 的其他掛載路徑。ports/dto/（6 檔）的資料形狀。 對外契約的 DTO 會不會把不該給的欄位吐出去（內部 id、email、其他租戶的人）。第一步：確認主 session 是 Opus 5 (1M context)（不是 Sonnet），並讀過首腦手冊第二節。
第二步：驗 scope 檔數，對上 20 才啟動：
cd ~/Projects/Jedicogy/module/jedi-python-package/jedi-issue && \
git ls-files -- jedi_issue/api/ jedi_issue/plugin.py jedi_issue/ports/ jedi_issue/__init__.py | wc -l
（20 檔中有 8 個是 __init__.py；plugin.py 314 行是最大單檔。數字對上 20 即可。）