本卡屬 FR-097（母卡見子卡清單），第 1 棒：日誌轉送全鏈（jedi-log 套件）。只掃不修。
系統可以把自己產生的日誌即時送到外部伺服器（客戶自己的資安監控系統）。這一棒掃的就是這個功能的完整路徑（39 個檔案）：從「設定頁的三支 API」一路到「實際送出網路封包的背景程式」，再到「隨套件出貨的兩支資料庫腳本」。
要回答的核心問題只有一個：誰改得動「日誌要送去哪裡」？
因為日誌本身就是最敏感的資料。依跨 arc 總表已登記的第 22 項，目前使用者的登入密碼與登入憑證會原文寫進日誌。所以「日誌送去哪裡」這個設定一旦被改掉，等於把含有密碼的整包資料導向攻擊者的機器——而且是持續性的、悄無聲息的。
這一棒與第 2 棒分開，是因為兩者風險形狀完全不同：這一棒是「改設定會怎樣」，第 2 棒是「誰看得到記錄」。
這些是首腦讀過程式碼後認為最容易出事的地方，是思考起點不是檢查清單。不是要你重新確認，是要你從這裡往外追：
log-forwarding.update 這個權限的平台層旗標是 false——代表它是客戶層級權限，而依租戶開通的邏輯（jedi_iam/app/service/tenant_provisioning_service.py:120-131「把權限全集扣掉平台層的，其餘全部發給該客戶的預設管理員角色」），每開一個新客戶就自動發給那家的管理員。但設定表的資料只有全域那一列（客戶欄位是空值，建表腳本檔頭明寫「第一版是系統層全域一份」）。要追：一個客戶的管理員送出更新請求，實際會不會改到全系統那一列？ 這與 2026-09-15 在 FR-096 H1 查到的第 74 項（客戶管理員可改全公司登入規則）是完全相同的形狀，該案已證實成立。POST <prefix>/log-forwarding/test 會依目前設定實際發一條測試訊息出去。檔頭自陳「它掛在寫那一欄而非讀，因為它會實際對外送出網路封包，是副作用而非查詢」。要追：能不能用它探測內部網路（送到任意主機／埠號），以及**「先改設定再打測試」這條組合路徑**。forwarding/common/forwarder.py 的說明寫明「真正的網路輸出全部發生在背景執行緒」。要追：背景執行緒讀設定時，用的是誰的身分（沒有請求脈絡代表沒有使用者身分，這正是總表 CM-1559「沒有身分時預設給最高權限」那條的典型觸發場景），以及設定變更後的重新掛載時機（settings_reader.py 的 get_effective_settings）。migrations/002-log-forwarding-settings.sql（建表）與 003-log-forwarding-grants.sql（授權）。首腦已讀過：002 建表沒有任何帳密欄位（只有主機、埠號、通訊協定、開關），003 只對應用帳號授予增刪改查。要追：授權範圍會不會過寬、以及 002 那個「啟用時主機與埠號必填」的資料庫約束擋不擋得住繞過。masking_enabled 欄位，註解寫「預留，第一版無行為」——代表目前送出去的日誌沒有做任何遮蔽。要追：轉送的兩條資料流（應用日誌、稽核事件）實際會帶出哪些內容，以及與第 22 項（密碼原文進日誌）疊加後的實際外洩面。這三件首腦在開卡前已經開檔核對過，掃到請直接標「已知、非本棒新發現」，不要當漏洞報：
core/plugins/api_log.py:185-186 確實注入了「要登入 ＋ 要有對應權限」，而且讀與寫分成兩個不同權限。研究員若只看套件會誤報成「無守門」，這是本棒最可能的誤報來源。