本卡為 FR-080 母案。掃 jedi-issue（129 檔）與它在主專案的宿主接線（31 檔），切六棒。只掃不修，修正卡另開、由 PM 統一安排。決策者裁：一次只派一棒，避免長跑中斷。子卡清單在末段。

這系列在做什麼（白話）

使用者在系統裡送「意見回饋」，系統會把它變成一張問題單。這張單子可以只存在本地，也可以同時拿公司的權杖去 GitLab 或 GitHub 開一張真的 issue，還會把使用者上傳的附件一起送過去。

這系列要檢查的是：使用者打的字與上傳的檔，一路流到第三方服務的過程中會不會出事——權杖會不會外洩、檔案會不會被放到不該放的地方、有沒有人能看到不該看的東西。

為什麼要做（三個發現改變了原本的評估）

① 套件檔頭自稱「58% 是死碼」，這個說法不成立。 jedi_issue/api/__init__.py:11-13 白紙黑字寫「GitLab／GitHub 整合目前產品沒有在用，約佔套件 58%」。首腦從宿主端查證：app/feedback/service/feedback_service.py 的 156／171／210／222／246／252 六處實際呼叫 create_gitlab_issue／create_github_issue／update_*／set_*_issue_closed，由 _is_gitlab_enable()／_is_github_enable() 兩個開關控制；IssueProviderCode 使用統計為 LOCAL 9 次、GITLAB 4 次、GITHUB 3 次。

🔴 這正是工具已知盲點二（會被程式碼註解說服）的教科書形狀——研究員讀到那段 docstring 就會跳過 58% 的程式碼，而那半邊恰好是風險最高的（外部連線＋憑證）。FR-075 的 S2 就是這樣八檔零發現卻漏掉真洞。每一張子卡都要帶這個警告。

② 首腦讀碼時已看到一個現成的洞，不必等掃描（未經面板驗證，作為研究員錨點）：jedi_issue/infra/github.py:22 與 jedi_issue/infra/issue/adapter/github/github_issue_adapter.py:43 兩處都是 Github(auth=auth, per_page=100, timeout=10, verify=False)——帶著存取權杖走不驗憑證的 TLS。而 token 來自 os.getenv("GITHUB_PRIVATE_TOKEN")（github.py:16）。

更該注意的是前科：CM-1573 就是「jedi-issue PAT 外洩處置」——這個模組的權杖外洩過一次。現在同一個模組還在用 verify=False 傳它。首腦初判 HIGH，交由本 arc 的面板驗證。

③ 宿主那一半藏在 feedback/ 底下，用檔名 grep issue 會漏掉。 BE 側真正的攻擊面是「使用者送意見回饋 → 系統拿公司 PAT 去第三方開 issue 並夾帶使用者上傳的檔案」，程式碼在 api/feedback/、app/feedback/、domain/feedback/、infra/feedback/。這是 FR-079 換來的教訓的直接應用（排名表只算套件本身，不含宿主接線）。

首腦讀完後的重點（未經驗證，是思考起點不是結論）

• 憑證面：GitLab／GitHub 的 PAT 都走 os.getenv fallback（gitlab.py:18-20、github.py:16）。要追：token 實際從哪裡設定進來、有沒有進 log、verify=False 的影響範圍、GitLab 那邊有沒有同樣問題（gitlab.py 目前沒有顯式 verify 參數，預設行為要查）。
• 注入面：使用者輸入的標題、內容、標籤、指派對象會被組進第三方 API 呼叫。要追有沒有可控欄位能改變請求語意（專案 ID、路徑、查詢參數）。
• 檔案面：附件走三種後端（local／gitlab／github）。local_issue_attachment.py:52 用 os.path.join("issue", issue_uid) 以 uid 組路徑；gitlab_issue_attachment.py:69 把 file.filename 直接送出。路徑穿越與任意檔案寫入的天然位置。
• 守門面：套件唯一一條對外 route /issue/get_members（api/__init__.py:84）只有 @jwt_required()——檔頭自陳「沒有能力點、沒有 platform-admin，搬遷紀律是逐字保留」。它回傳的是成員名冊。檔頭自己也寫了「缺接線要拒絕掛載不是跳過，跳過的後果是成員清單變公開端點（洩漏全站使用者名冊）」——那個 fail-closed 是否真的成立要驗。
• 失敗處置面：feedback_service.py 對第三方呼叫是 try/except 吞掉只記 warning（「失敗不阻擋本地建立」）。要看例外訊息會不會把 token 或內部位址寫進 log。

怎麼拆（六棒，按攻擊面切不按目錄大小平均切）

• I1 第三方整合與憑證（25 檔，jedi monorepo）— infra/issue/adapter/＋infra/project_member/＋gitlab.py＋github.py。風險最高，建議第一棒。
• I2 宿主接線（31 檔，BE repo）— api/app/domain/infra 的 feedback 四處＋infra/issue/＋DI。使用者輸入進入第三方呼叫的完整路徑與守門都在這。
• I3 附件上傳下載（14 檔，jedi monorepo）— infra/issue_upload_files/。三種儲存後端。