本卡屬 FR-080（母卡 CM-1612），第 2 棒：宿主接線（BE repo，不是 jedi monorepo）。只掃不修。與 I1 是同一條鏈的兩半，驗收時要放在一起對。

這一棒在做什麼（白話）

掃主專案裡「意見回饋」這個功能（31 檔）。使用者在系統送出意見，這裡負責把它變成問題單、並拿公司的權杖去 GitLab／GitHub 開一張真的 issue、還把使用者上傳的檔案一起送過去。要找的是這條路上會出什麼事。

為什麼切這一塊

scanRoot 只能指一個目錄，而這條鏈橫跨兩個 repo。I1 掃的是套件端「怎麼打第三方」，本棒掃的是宿主端「使用者的輸入怎麼進來、權杖從哪個設定讀出來、誰能觸發」——套件把這些全外包給宿主，答案在這 31 檔裡。

🔴 注意這一半藏在 feedback/ 底下，不叫 issue。用檔名 grep issue 會漏掉主要攻擊面。

重點看什麼

首腦讀過程式碼後認為最容易出事的地方，未經任何驗證，是思考起點不是檢查清單。

• 🔴 檔頭自陳不可信。 jedi_issue/api/__init__.py:11-13 自稱「GitLab／GitHub 整合目前產品沒有在用，約佔套件 58%」——首腦已從宿主端證偽（app/feedback/service/feedback_service.py 156／171／210／222／246／252 六處實際呼叫，IssueProviderCode 統計 LOCAL 9／GITLAB 4／GITHUB 3）。這是工具已知盲點二（會被程式碼註解說服）的教科書形狀。本套件 docstring 普遍詳盡且自我辯護，一律當待查證的宣稱。
• ① 第三方呼叫的觸發點與開關。 app/feedback/service/feedback_service.py:152-179：if self._is_gitlab_enable(): / if self._is_github_enable(): 兩個分支各自呼叫 create_gitlab_issue／create_github_issue。要追：這兩個開關由誰決定（環境變數？租戶設定？）、誰能改、開啟後任何能送意見回饋的使用者是不是都會觸發一次帶公司權杖的對外連線。
• ② 例外被吞掉只記 warning。 同檔 except Exception as e: logger.warning(f"Failed to create GitLab issue for feedback '{title}': {e}")（:165-166、:178-179 同款）。要追：{e} 展開時會不會把權杖、內部位址、完整請求寫進 log。註解寫「失敗不阻擋本地建立」是刻意設計，但吞掉的內容是什麼沒人判斷過。
• ③ 使用者輸入直達第三方。 title／content／labels／files 從 route 進來後原封不動傳給套件的 adapter。要追 api/feedback/serializers/feedback.py 有沒有驗證、長度上限、字元限制——這些字串最後會變成第三方平台上的 issue 內容與標籤。
• ④ 附件跟著送出去。 files 一路傳到第三方上傳 API。要追：檔案大小／型別/數量有沒有限制、檔名有沒有清洗（套件端 gitlab_issue_attachment.py:69 直接用 file.filename）、使用者上傳的檔案被送到公司的 GitLab 專案這件事本身的授權模型是什麼。
• ⑤ 誰能送意見回饋、誰能看。 api/feedback/routes/feedback_route.py 的每條 route 掛了什麼守門？列表／詳情會不會讓 A 使用者看到 B 使用者送的回饋（可能含截圖與內部資訊）？這是本棒的授權主題。
• ⑥ 唯一那道套件守門的接線。 infra/issue/issue_plugin_wiring.py:44 傳 auth_required=jwt_required()，檔頭自陳「本模組只有一道守門，搬遷前 /issue/get_members 就只有 @jwt_required()，沒有能力點、沒有 platform-admin」。檔頭同時寫「缺接線要拒絕掛載不是跳過，跳過的後果是成員清單變公開端點（洩漏全站使用者名冊）」——那個 fail-closed 是否真的成立要驗（與 I4 棒呼應）。
• ⑦ 權杖從哪個設定讀出來。 套件端是 os.getenv("GITLAB_PRIVATE_TOKEN")／GITHUB_PRIVATE_TOKEN fallback。要追宿主有沒有顯式傳入、值從 config/config.py 還是 .env、有沒有預設值（FR-078 的 CM-1608 就是 os.getenv(..., "<真密碼>") 這個 pattern）。報告只寫「在哪一行、什麼形狀」，不寫值。
• ⑧ AI 儀表板旁路。 di_containers/dashboard_apis/feedback.py 把 feedback 註冊給 jedi-ai-dashboard——FR-079 的 F13 就是這條形狀（不經 route 層守門、呼叫端寫死 params={} 使過濾失效、結果前三筆原文送第三方 LLM）。要照 FR-079 的結論直接查這裡有沒有同款問題，這是最有把握撈到東西的一項。
• ⑨ 資料模型與租戶隔離。 infra/feedback/model/feedback_issue.py 有沒有掛 tenant scope、feedback_issues 表的 RLS 是否 enabled（FR-079 查出 bulletin_org_units 整張表零 RLS，同類要查）。唯讀查 DEV 庫即可。

怎麼做

第一步：確認主 session 是 Opus 5 (1M context)（不是 Sonnet），並讀過首腦手冊第二節（.claude/skills/security-scan-lead/SKILL.md）。