本卡為 FR-078 母案。掃「通知怎麼送出去」這條鏈——jedi-notification 套件本體（N1）＋主專案宿主接線（N2），兩棒。子卡清單在末段。

這系列在做什麼（白話）

產品所有對外通知都經 jedi-notification 送出去：SMTP 寄信（登入 OTP、稽核流程通知、問卷指派、授權到期提醒、批次匯入結果）、Discord webhook、Telegram bot。這一系列就是把這條鏈從頭到尾檢查一遍，看有沒有資安問題。只找問題、不修問題，修正另外開卡。

為什麼掃這支

決策者 2026-09-08 裁定 FR-077（遠端 Agent）暫停、改從其他 jedi-* 套件開始掃，這是第一支。選它的理由有三：

• 它真的獨立（決策者原話）——與其他套件耦合少，套件本身只依賴 jedi-common，範圍乾淨切得開。
• 它是至今最小的一棒。attack-surface 口徑 30 檔、1,011 行，其中 16 個是空的或只有幾行的 __init__.py，真正有邏輯的只有 14 檔約 700 行。比 FR-076 L1 的 10 檔略大而已。
• 它同時是額度可行性的實驗。決策者目前是 5X token 額度，而 FR-077 R1（42 檔）的三人驗證面板全滅——105 個 verifier 全部撞 session 額度上限、21 張票 0 張投出。至今唯一一次面板完整跑完的紀錄是 L1 的 10 檔。若這一棒在 5X 也撐不完面板，代表工具在此額度下不可用，這個結論值得先用一小時拿到，而不是拿 92 檔的 jedi-common 去撞。

首腦讀完程式碼後的重點

以下都未經任何驗證，是首腦讀碼後標出的可疑點，給研究員與 runner 當思考起點。逐棒的完整清單在子卡裡。

• 傳輸層不驗憑證：SMTP adapter 的 starttls() 不帶 SSL context。與已修的 LDAP TLS（CM-1560）、Redis TLS（CM-1565）是同一類病，這是本 codebase 的累犯模式。
• 明文密碼進 log：SMTP adapter 的 except 區塊把整個設定物件（含密碼）印進 log，正常路徑的 info log 也印帳號與伺服器。
• 測試信端點可能是密碼外洩管道：宿主的 send_test_mail 在使用者沒改密碼時，會從 DB 讀既存 SMTP 密碼合併進使用者送來的設定再試寄。持有 smtp-config.update 的人送一個指向自己伺服器的 host，就能收到平台的明文密碼。LDAP 同款問題已在 CM-1564 修過，SMTP 這邊看起來沒修。
• 對外請求無 timeout：Telegram 與 Discord adapter 的 requests.post 完全沒有 timeout，外部服務不回應會吊死 worker（SMTP 那邊有設 60 秒，這兩支沒有）。
• SSRF 面：Discord webhook 網址是使用者填的任意 URL，伺服器會對它發 POST。
• 背景 thread 的租戶脈絡：十多個消費點裡多處在背景 thread 呼叫寄信，要確認無 user context 時的設定讀取是否 fail closed。這與 CM-1559（RLS fail-open）是相鄰主題。

🔴 版本落差（兩棒都要注意）

主專案 pyproject.toml pin 的是 jedi-notification==0.0.11，沒有走 poetry path override，所以 monorepo HEAD 可能領先於實際部署的版本。報告的每條發現都要註明「在 0.0.11 是否同樣存在」（pip show -f jedi-notification 找到已安裝版本的檔案位置，比對那幾行）。否則修正卡會對不上部署中的版本，修了 monorepo 但客戶跑的還是舊的。

怎麼拆

• N1 套件本體（30 檔，scanRoot＝jedi monorepo）— jedi-notification/jedi_notification/ 全部。投遞邏輯、三個 adapter、工廠、DTO、plugin 契約。