本卡屬 FR-097（母卡見子卡清單），第 2 棒：API 操作記錄全鏈（jedi-log 套件）。只掃不修。在 L1 驗收完成之後才派。

這一棒在做什麼（白話）

系統會把每一次 API 呼叫記下來——誰、什麼時候、對哪支功能做了什麼，供事後稽核查閱。這一棒掃的是這個功能的完整路徑（43 個檔案）：查詢清單、匯出成檔案、資料表結構（按月分區），以及選單與權限的綁定。

要回答的核心問題：誰看得到這些操作記錄，以及匯出功能會不會被濫用。

為什麼切這一塊

與第 1 棒風險形狀完全不同：第 1 棒是「改設定會把日誌導去哪」，這一棒是「誰讀得到已經記下來的東西」。操作記錄裡有每個使用者的行為軌跡，是個資與營運資訊的集中地。

⚠️ 首腦對本棒的預期偏低，這件事要先講明：這兩支端點的守門看起來是目前掃過最紮實的（見下），而這張表的隔離問題已經登記在跨 arc 總表第 23 項。如果 L1 驗收後決策者認為投入產出不划算，本棒可以不派——卡片先開好備著。

重點看什麼

這些是首腦讀過程式碼後列的思考起點：

• ① 匯出功能的檔案處理。 ExportApiLogsRoute 會把記錄打包成 zip 檔送出（api_log_route.py 的 export_api_log_file()，實作在 app/service/api_log_service.py 與 common/utils/excel_util.py）。要追：匯出範圍受不受查詢條件限制、有沒有筆數上限（會不會一次撈走整張表）、暫存檔清不清、檔名有沒有被使用者輸入影響。
• ② 查詢條件的處理。 清單端點的條件全放在請求內容裡（ApiLogPageQueryRequest）。要追：條件欄位是不是全部非必填（送空的會不會回整張表——這屬跨 arc 總表已在追的「空條件回全表」那條線，若命中請標明歸屬、不要當獨立發現升級）、排序欄位有沒有白名單。
• ③ 分區表的結構。 資料表按月分區（api_logs_2026_05 至 08 再加一張 default）。要追：新月份的分區由誰建、建不出來時會怎樣（資料會不會全部掉進 default 或直接寫入失敗）、舊分區有沒有保存期限與清理機制。
• ④ 記錄寫入的來源。 主專案 common/middleware/app_mw.py 每個請求都會寫一筆。要追：寫進去的內容含哪些欄位——這條與跨 arc 總表第 22 項（密碼與登入憑證原文進日誌）直接相關，若發現同一件事請標「與第 22 項同一根因」。
• ⑤ 選單與權限的綁定。 migrations/004-log-ui-routes.sql 塞的是這個功能自己的選單與權限綁定。要追：綁定的權限是不是平台層（首腦實查 log.read 的平台層旗標是 true，屬正確）、以及塞入的資料會不會覆蓋客戶改過的值。

🔴 已經查證過的，掃到不要重報

• 兩支端點的守門是紮實的。 清單（ApiLogsRoute.post）與匯出（ExportApiLogsRoute.get）都掛了「要登入 ＋ 必須是平台管理員」，首腦已開檔逐行確認。這是目前所有掃過的套件裡守門最完整的一組之一，要查的是有沒有別的路徑繞過它，不是報「缺守門」。
• 操作記錄表沒有客戶隔離、也沒有客戶欄位——首腦開發環境實查確認（五張分區表全部沒開隔離、0 條規則、無客戶欄位）。但這已經登記在跨 arc 總表第 23 項，掃到請標「與第 23 項同一件事」，不要當新發現另計。

怎麼做

第一步：驗 scope 檔數，對上 43 才啟動：

cd /Users/chouraymond/Projects/Jedicogy/module/jedi-python-package/jedi-log && git ls-files -- jedi_api_log/api_log jedi_api_log/migrations/001-api-log-tables.sql jedi_api_log/migrations/004-log-ui-routes.sql | grep -vE '/tests?/' | wc -l   # 要回 43