本卡為 FR-097 母案。掃 jedi-log 這支套件——它管兩件事：把系統日誌轉送到外部伺服器、以及記錄誰對系統做了什麼操作。切兩棒共 82 個檔案，只掃不修。子卡清單在末段。

這系列在做什麼（白話）

系統每天會產生大量日誌——誰登入了、誰改了什麼、程式出了什麼錯。這支套件管兩件事：①「日誌轉送」，把這些日誌即時送到客戶指定的外部伺服器（例如客戶自己的資安監控系統）；②「操作記錄」，把每一次 API 呼叫記下來，供事後稽核查閱。

這一系列要回答的問題是：誰改得動「日誌要送去哪裡」這個設定，以及誰看得到那些操作記錄。

為什麼要做

這支套件從來沒有被掃過。而且它有一個特殊的風險形狀：日誌本身就是最敏感的資料——依跨 arc 總表已登記的第 22 項，目前使用者的登入密碼與登入憑證會原文寫進日誌。也就是說，「日誌要送去哪裡」這個設定一旦被改掉，等於把含有密碼的整包資料導向攻擊者指定的主機。

🔴 開卡前首腦實查，更正了跨 arc 總表一處錯誤：總表 §4 排名表寫「日誌轉送的目標設定裡包含帳密」——這句不成立。首腦開了建表腳本逐欄核對，那張表只有主機、埠號、通訊協定、開關這些欄位，沒有任何帳號密碼欄位。所以這支的原始排序理由有一半是錯的，但仍值得掃，理由是上一段講的「導向誰」而不是「設定裡存了什麼」。

首腦讀完後的重點

• 🔴 最大疑點：改日誌轉送目標的權限是「客戶層級」，但那張表是全系統共用一列。 首腦開發環境實查：log-forwarding.update 這個權限的平台層旗標是 false（＝客戶層級，每開一個新客戶就自動發給該客戶的管理員）；而設定表的資料只有「全域那一列」（客戶欄位是空值，建表腳本的註解明寫第一版是系統層全域一份）。這與 2026-09-15 剛在 FR-096 H1 查到的第 74 項是完全相同的形狀——客戶層級的權限寫進全系統共用的設定。要查的是：一個客戶的管理員能不能真的改到全系統的日誌轉送目標。
• 守門是好的，掃到不要誤報。 轉送那三支端點在套件裡一個裝飾器都沒掛，看起來像沒守門——那是刻意設計，守門由主專案注入。首腦已追到主專案 core/plugins/api_log.py:185-186 確實注入了「要登入＋要有對應權限」，而且讀與寫分成兩個不同權限。這正是掃描工具容易誤報的形狀（研究員看到 route 沒有裝飾器就報「無守門」），請先確認宿主注入再判斷。
• 設定表刻意不做客戶隔離，也是刻意的。 建表腳本檔頭明寫理由：這是平台層設定不是客戶資料，而且轉送功能的掛載發生在沒有網頁請求脈絡的背景執行緒，隔離機制需要的變數當下不存在，掛了只會讓背景讀取永遠是空的。存取控制靠應用層守門。掃到「這張表沒有隔離」不要當發現報——要查的是「應用層守門夠不夠」。
• 操作記錄那兩支端點的守門看起來最紮實：清單與匯出都掛了「要登入 ＋ 必須是平台管理員」（首腦已開檔確認）。要查的是有沒有別的路徑繞過它。
• 操作記錄表沒有客戶隔離、也沒有客戶欄位——首腦開發環境實查確認（分區表 api_logs_2026_05 至 08 與 default 全部沒開隔離、0 條規則、無客戶欄位）。但這件事已經登記在跨 arc 總表第 23 項，掃到請標「與第 23 項同一件事」，不要當新發現另計。

怎麼拆

• 第 1 棒 L1 日誌轉送全鏈（39 檔：37 支程式 ＋ 2 支 SQL）— 從端點一路到資料庫的完整路徑，含轉送設定的讀寫、實際送出封包的背景執行緒、以及隨套件出貨的建表與授權 SQL。風險最高，先跑。
• 第 2 棒 L2 API 操作記錄全鏈（43 檔：41 支程式 ＋ 2 支 SQL）— 操作記錄的查詢、匯出、分區表結構與選單權限綁定。

建議順序：L1 → L2，一次只派一棒，每棒獨立驗收完才派下一棒。合理停損點在 L1 之後——L1 涵蓋「誰改得動日誌去向」這個真正的風險面；L2 的守門看起來紮實、且它的主要問題已登記在第 23 項。

⚠️ 套件根層還有 6 支檔案（jedi_api_log/__init__.py 與 plugin/ 五支）兩棒都不含。那幾支定義的是「宿主必須填哪些插槽」，屬於接線層，會併進之後與 jedi-asset 合併的宿主接線棒一起掃。這是刻意的，不是漏掉。

共同設定

• 主 session 模型 Opus 5 (1M context)，不要用 Sonnet——研究員繼承主 session 的內容上限，Sonnet 跑不完會被工具的「180 秒沒動作就判當掉」砍掉重派。