🔴 一頁看完

✅ 2026-09-11 arc 收口：三棒 91 檔全部掃完並經首腦驗收。jedi-common 這支「25 支套件共用的地基」至此首次有了完整、算數的掃描（先前只有一次未經面板的半途掃描）。

三棒合計 22 條（2 HIGH／9 MEDIUM／6 LOW，另 5 條查證為無問題或死碼）。依決策者裁定修正卡一律不開，全部登記進跨 arc 總表 §3，之後從那裡挑。

投報率最高的三條：① 補一行 RUN_ENV=prod（C2-5，決定密碼進 log 那幾條的影響範圍是開發機還是客戶機）／② 分頁加上限（C3-2，一行）／③ 密碼遮罩改用 JSON 解析（C3-3，動的是全站唯一那道遮罩）。

開卡時的六個疑點，三條成立三條被推翻——can_manage_orgs 無條件為真是死碼、log 操作者可偽造是死碼、信封失敗回例外訊息進不去。懷疑清單有一半會被證偽，這是健康的。

C1 掃完了。結論：只要一個請求「還沒有登入身分」，資料庫的客戶隔離就整個關掉——而這不是罕見狀況，登入端點本身、以及一個完全沒有守門的 Google Drive 通知端點，每次都處在這個狀態。

這個洞就是既有的 CM-1559，本棒的新資訊是「它比原本記錄的更好觸及」。另找到 SQL 錯誤原文直接回前端（新），以及主產品 Redis 連線不驗憑證——那是 CM-1565 在 jedi-iam 修好、但主產品這份漏網的複製品。

C2 也掃完了。結論：使用者的登入密碼與登入憑證，目前是原文寫進伺服器 log 檔與資料庫的——而產品另一條 log 路徑明明有遮罩功能，就是這條沒用上。連帶查出出貨設定漏了一個環境變數，客戶正式機實際跑的是開發用 log 設定（一行可修，但它決定前面幾條的影響範圍是開發機還是客戶機，投報率最高）。

首腦在 DEV 實查複核：存 log 的那張表完全沒有客戶隔離（沒開、0 條規則、連可用來隔離的欄位都沒有、目前 66 萬筆），而且另一張 log 表也一樣。

一個好消息：卡片原本認為「最重要」的那條（log 上的操作者可被偽造）不成立，那段程式碼從未被啟用。

C3 掃完了，三棒到此全部結束。結論：我們安裝套件走的是不加密的連線，有人插進內網那條線就能在安裝時掉包惡意程式——直接拿下開發機與打包機，而打包機產出的東西是要送到客戶手上的。這個設定25 支套件與主專案各有一份，建議開成跨 monorepo 的獨立卡。

第二件：全站唯一那道密碼遮罩，遇到含雙引號的密碼會遮一半、剩下半截原文寫進資料庫，而那張表留 90 天——越強的密碼越容易踩到。

另外查清一件卡片指定要回答的事：AI 儀表板回傳夾帶密碼鹽值（FR-083 D1 F2）是個案不是系統性問題——那支序列化工具全 monorepo 只有 jedi-ai-dashboard 2 處在用，主專案與其餘 24 支套件都是 0 處，建議修呼叫端不要動套件。

C3 的好消息同樣是卡片列為「本棒最重要」的那條（信封組裝失敗把錯誤原文回前端）不成立——那段程式進不去。

📄 C1 報告｜C2 報告｜C3 報告

C2 也掃完了。結論：使用者的登入密碼、以及每個請求的登入憑證，目前原文寫進伺服器 log 檔與資料庫——而產品另一條 log 路徑（寫 api_logs 那條）明明有遮罩功能，就在同一支檔案往下 5 行，就是這一條沒用上。這是本專案第三次同型問題（前兩次 CM-1606、FR-076 L3），差別在前兩次是個別功能寫錯，這次是每一個請求都會發生。

三件放大它的事：① system_logs 表完全沒有客戶隔離（DEV 實查：RLS 關閉、0 條規則、66 萬筆，且表裡連 tenant 欄位都沒有，想開也開不了）；② 出貨設定漏了 RUN_ENV，客戶正式機實際套用的是開發用 log 設定——而正式設定裡本來根本沒有這條寫 DB 的路徑；③ 完整錯誤堆疊也進同一張沒隔離的表。

好消息：卡片原本認定「本棒最重要」的那條（log 操作者取自 X-UserId 可偽造）不成立——那兩支程式從未被啟用，是死碼，工具三票一致擋下。這正是三人面板的價值：沒有它，會有人花時間去修一段沒在跑的程式。

📄 C2 完整報告｜C3 完整報告。

jedi-common 是所有 jedi 套件與主產品共用的底層：

• 每一次資料庫存取都經過它的 session_scope，它負責告訴資料庫「現在是誰在查、能看哪些客戶的資料」。這就是 RLS（每個客戶只能看自己資料的隔離機制）的注入點。
• 每一個錯誤回給前端的格式由它決定。
• 每一行 log 怎麼寫、寫到哪裡也是它。

它出問題等於 25 支全中。 這個 arc 要回答：資料庫隔離會不會被繞過或注入、錯誤訊息會不會把內部細節洩給前端、log 會不會把密碼或可偽造的身分寫進去、回給前端的資料會不會夾帶不該有的欄位。

• 至今沒有一次算數的掃描。 只有第一輪 medium 半途喊停、未經面板的紀錄。跨 arc 總表從 FR-081 起就列它為第一優先。
• 已知洞 CM-1559 的根就在這裡（RLS fail-open，無 user context 時預設 super admin），但那張卡只盯一個點，整支套件沒人看過。
• 宿主 662 處 import。 session.database 201、handler.exception 184、session.auth 96、utils.response_util 78，爆炸半徑是全站。

接縫：handler/handler.py（C1）與 utils/response_util.py（C3）是「例外 → 信封」的兩端，兩卡互相允許越界讀對方那支。mark_password（C3）是 C2 要追的遮罩層，C2 允許越界讀。

偵察由唯讀 subagent 做，關鍵行號首腦逐一開檔核過：

（掃完驗收後才會有。依決策者裁定，修正卡先不開，發現登記進跨 arc 總表 §3。）

• 套件：~/Projects/Jedicogy/module/jedi-python-package/jedi-common/。session/database/base_repository.py 是舊名轉發殼、真身在 session_mixin.py
• 已知前案：CM-1559（RLS fail-open，C1 基準線）、CM-1598（.env 受版控，C3 基準線）
• 首腦手冊：.claude/skills/security-scan-lead/SKILL.md
• 跨 arc 總表：security-scan-consolidated/
• 現況：FR-075/handoff/security-scan-STATE.md

以下全部由 build 掃資料夾產生，新增檔案重 build 即自動出現。標題連結指向渲染後的 HTML，md 連向源檔。

其他文件

卡片內容（決策紀錄、驗收條件）以 Notion 為準，本頁只記座標。

相關需求：

• FR-075 — jedi-package-security-audit
• FR-076 — license-chain-security-scan
• FR-077 — remote-agent-security-scan
• FR-078 — notification-security-scan
• FR-079 — bulletin-security-scan
• FR-081 — issue-tracking-security-scan
• FR-082 — ai-bot-security-scan
• FR-083 — ai-dashboard-security-scan
• FR-084 — integrity-security-scan