一句話：本卡為 FR-101 母案，重掃 jedi-issue 在 FR-099「意見回饋與標籤併入套件」大整理後有變動的 93 個檔案，三棒，只掃不修。子卡清單在末段。

這系列在做什麼（白話）

意見回饋功能（使用者在系統裡回報問題、可轉成 GitLab／GitHub 的問題單、可夾附件）原本一半在主專案、一半在套件。FR-099 把主專案那一半整組搬進套件 jedi-issue，主專案刪掉五個目錄。搬完後套件從 130 檔變 151 檔：38 支是全新的（沒有任何工具看過）、25 支既有檔有改、57 支沒動。本系列只掃有變動的 93 支，沒動的 57 支沿用 FR-081 的結論。

為什麼要做

• FR-081 當時掃的主專案側 31 檔（含唯一一條次嚴重 CM-1630 的落點）已全部刪除，那 5 條發現的新落點在套件裡——首腦開檔確認 CM-1630 搬家沒修（feedback_route.py 七條 route 仍只有匯出掛能力點，feedback_service.py:240-300 改刪仍不比對本人）。
• 新出現的守門殼（plugin/assembly.py）、route 表（api/routing.py）、10 顆能力點清單（6 顆自陳後端不守）、4 支隨包 migration（含 SET LOCAL app.is_super_admin='t' 寫入）從沒被掃過。
• 第一次有機會驗「工具對同一批檔重掃結論是否一致」（J3 那 25 支改動不大）。

首腦讀完後的重點

• 守門形狀與 FR-098 jedi-asset 同款：讀取只驗登入、寫入也只驗登入（比 asset 更寬——asset 寫入有能力點，issue 連寫入都沒有，只有匯出有）。
• 六張舊表零隔離仍在（DEV 實查 2026-09-16 14:22）：新搬進來的 feedback_issues 有 RLS，但它關聯的 issues／labels／mapping 表沒有——等於門上了鎖、牆是空的。
• GitHub 附件那支大改（刪 34 行改 15 行）：把「拋例外導致整張 issue 沒建」改成「靜默跳過附件只記 warning」——這個改法對不對是 J3 要驗的。
• verify=False 兩處仍在（CM-1632 未修）。

怎麼拆

• J1 意見回饋全鏈＋對外 route 與守門（31 檔，全新）——CM-1630 新落點、7 條 route、守門殼與宿主注入的接縫。
• J2 插件骨架＋標籤鏈＋migration＋共用（37 檔）——能力點清單、_assert_api_wiring 只驗兩項、標籤零隔離、SQL seed 提權寫入。
• J3 有改動的整合與附件層（25 檔）——回歸確認 I1／I3／I5 結論、GitHub 附件降級改法、CM-1632。

主專案接線 core/plugins/issue.py＋2 支小檔不在本案，併進之後「日誌＋資產＋議題三支套件的主專案接線」那棒（BE repo，約 21 檔），等三棒跑完再開。

共同設定

• 主 session Opus 5 (1M)、effort low；scanRoot 一律 /Users/chouraymond/Projects/Jedicogy/module/jedi-python-package/jedi-issue；一次只派一棒，J1 → J2 → J3，每棒獨立驗收完才派下一棒。
• 掃描版本：jedi 套件 repo 4c208d4（branch feature/review），三棒之間若有新 commit 動到 jedi-issue，驗收時比對。