FR-114.9-W jedi-common 正式模式日誌量：sqlalchemy.orm 的 INFO 擋不住開機 6,000 行對映紀錄、app handler 寫死 DEBUG——收集卡 #36（SUMMARY #125 實況只修一半），低

本卡屬 FR-114 資安修正（母卡 CM-2019），b4 總測回報收集卡 CM-2231 #36（V4 驗證 CM-2267 #125 抓到）。jedi-common 套件兩行設定，低，可與 CM-2269 同時派（不同套件、不同檔）。

問題是什麼（白話）

資安報告 SUMMARY #125「兩種運作紀錄的詳細程度被寫死成最詳細，紀錄量暴增吃掉磁碟（三處已改一處，還剩兩處）」標成已修，但 190 實測：正式模式開機一分鐘 sqlalchemy.orm.* 倒出約 6,000 行 INFO 對映紀錄，佔開機後一小時紀錄量九成；app.log 一天 7MB。原因是 config_prod.py 把 sqlalchemy.orm 從 DEBUG 調成 INFO，但 SQLAlchemy 的 mapper／relationship／LazyLoader 對映設定紀錄本身就是 INFO 級，INFO 擋不住，要 WARNING 才擋得住。另 handlers.app.level 寫死 DEBUG（目前靠 logger 的 LOG_LEVEL 擋著沒冒出來，但任何 logger 一調 DEBUG 就直灌容器 stdout）。

首腦已核對的證據：190 api 容器 ENV=PRD、DEBUG=false、無 LOG_LEVEL → 走 config_prod.py；V4 報告 verify/b4-verify-V4.md「#125 細節」有逐項數字（開機一小時 7,191 行、其中 sqlalchemy.orm 約 6,050、穩態十分鐘 367 行、app.log 今 5.3MB／昨 7.0MB）。

工作區

套件側：/Users/chouraymond/Projects/Jedicogy/module/jedi-python-package/.claude/worktrees/jedi-wt-fix-security/jedi-common（monorepo branch fix/security-b1，jedi-common 版本 1.3.2）。只動 jedi_common/logger/ 下的檔、只 git add 該子目錄下的檔。
BE 工作區（起服務手測用）：/Users/chouraymond/Projects/Billows/Audit-Manager/compliance-manager-be/.claude/worktrees/wt-fix-security（branch fix/security-b1）。pyproject.toml:63 pin jedi-common==1.3.2、:114 有註解掉的 path 行——改成上面工作區路徑取消註解，poetry update jedi-common；path 改動不 commit。8005 已有舊 BE 在跑，手測另起 PORT=8006，並用 ENV=PRODUCTION_AWS_BILLOWS（或任何走 config_prod 的 ENV，先 grep config/config.py 確認哪個 class 載 config_prod）起。

在哪裡

jedi_common/logger/config_prod.py:90-94   'sqlalchemy.orm': level 'INFO' → 改 'WARNING'；:88-89 那兩行註解跟著改（INFO 擋不住對映紀錄、要 WARNING）
jedi_common/logger/config_prod.py:30-34   handlers.app.level 'DEBUG' → 改 'INFO'（正式模式容器 stdout 不該收 DEBUG）
jedi_common/logger/config_prod.py:83-87   'pymongo.event_loggers' INFO——同理確認 pymongo 的 event logger 在 INFO 會不會每筆事件都印；會就一併 WARNING
jedi_common/logger/config_stg.py:85-89    sqlalchemy.orm 仍 'DEBUG'、:33 app handler 'DEBUG'——STG 是給我們自己看的，**不動**，但回寫時確認 190/189 安裝版走的是 prod 不是 stg

怎麼修

上面三處改級別。先查再寫：git grep -n "LOG_LEVEL" jedi_common/logger/ 確認 LOG_LEVEL 環境變數的預設與讀法，別讓 handler 改 INFO 後把客戶明確設 LOG_LEVEL=DEBUG 排查的路徑堵死——handler 級別可用 LOG_LEVEL 帶入（min(LOG_LEVEL, INFO) 語意），或維持寫死 INFO 並在註解寫明「要 DEBUG 進容器 stdout 得改這行」。二擇一，回寫寫理由。
不動 config_dev.py／config_stg.py。

要寫測試

設定檔兩行，不寫新測試（CLAUDE.md 測試政策）。tests/ 若有 logger 相關既有測試跑一下（cd /Users/chouraymond/Projects/Jedicogy/module/jedi-python-package/.claude/worktrees/jedi-wt-fix-security/jedi-common && PYTHONPATH=. python -m pytest tests -q -k log），沒有就寫明。

手測

BE 工作區以走 config_prod 的 ENV 起 8006，grep -c 'sqlalchemy.orm' log/app.log（或 stdout）開機後期待 0（改前用 pin 版起一次做對照，期待數千）。
打幾支 API 確認業務 INFO log（[common.jedi_iam] ... User Login Success）仍正常寫出，沒有把整個 app 靜音。
LOG_LEVEL=DEBUG 起一次，確認客戶排查路徑仍能看到 DEBUG（依你二擇一的設計）。

做完要回寫報告

docs/security-report/M04-common.md 對應 #125 那列「怎麼修」欄補一句實況（INFO 擋不住對映紀錄，已改 WARNING＋handler INFO）、SUMMARY.md #125 狀態維持已修；重 build（python scripts/deliverables/render_index.py docs/security-report/ --site-root docs/security-report/，在 BE 工作區、另一個 commit）。