FR-114.2-6 AI 儀表板查詢加權限白名單、移除「一律當管理者」後門、密碼欄位補進禁止序列化清單（SUMMARY #60／#61／#62／#114，高）

本卡屬 FR-114 資安修正（母卡 CM-2019），第 2 批「只驗登入、不檢查歸屬」卡 2-6，修 SUMMARY #60／#61／#62／#114（出自 M15-2／M15-3／M17-2／M04-12）。高。修法規格來自內化卡，計畫在 docs/features/FR-114-2609-security-fix-dispatch/batches/plan-b2.md「卡 2-6」段。🔴 本卡要等第 1 批合回主線＋套件發版後才能開工。

問題是什麼（白話）

#60：AI 儀表板繞過了系統一般的入口權限層，26 支登記在案的查詢，任何一支都沒有真的檢查呼叫者是不是有權限看這份資料。#61（同樣問題同樣位置）：儀表板專案清單還開了一個「一律視為管理者」的後門，讓一般使用者也能看到不該看的專案清單。#62（同樣問題同樣位置）：另外還有一個部門篩選參數其實從來沒被真正傳遞過去，被另一個無關的格式錯誤蓋住了，這次一起修的話這個問題會浮現，要在卡上先提醒。#114：使用者資料被序列化（轉成可傳輸格式）給前端時，密碼加密用的「鹽值」跟「是否為超級管理員」這兩個欄位沒被排除，會被一起送出去——本卡先做第一步，把這兩個欄位加進既有的禁止清單。

首腦核對：

根因很清楚：儀表板繞過了正常的入口權限層，不是漏檢查一兩處
已決定的修法：在既有 26 支查詢的登記清單（registry.py:37 DashboardApi dataclass）加一個「需要什麼權限」欄位，呼叫前在 data_api_service.py:83 call_api 檢查，沒標記的查詢一律拒絕（fail-closed），不是預設放行
兩個被排除、不要重新考慮的替代方案：讓每支查詢自己各自檢查（分散、難維護）；讓 AI 改走正常入口重新請求（架構動太大）——這兩個方案已經討論過否決了，不要在卡上重提
#61：project_service.py:212 get_projects_for_dashboard:224 目前用 is_admin=True 硬寫死，直接刪掉這個後門，改用真實身分判斷——效果是連專案管理者角色之後也只能看到自己有參與的專案，這個副作用是決策者已接受的
#62：不需要另外修——覆蓋在 #60 的 26 支查詢清單加白名單機制後，這個問題自然被涵蓋到；但同時要修正部門篩選參數從未真正被傳遞的問題，這個問題原本被另一個格式錯誤遮住，本卡修完格式錯誤後這個問題會浮現出來，要在卡上寫清楚讓下一棒知道不是新出現的迴歸
#114：這是兩步修法的第一步，本卡只做第一步——在既有的 _ORM_SKIP_KEYS 跳過清單（jedi-jedi-common/jedi_common/utils/serialization_util.py:12，被 :15 的 to_serializable 使用）加上密碼鹽值欄位與 is_superadmin 欄位。這支是跨套件共用工具，改動風險低但影響面廣，要特別注意

工作區

套件側：jedi-ai-dashboard 在 /Users/chouraymond/Projects/Jedicogy/module/jedi-python-package/.claude/worktrees/jedi-wt-fix-security/jedi-ai-dashboard（branch fix/security-b1）改；jedi-common 在同目錄下 jedi-common 子目錄改。兩者都只動自己那支套件的子目錄、只 git add 該子目錄下的檔。

跨 repo：BE 工作區 /Users/chouraymond/Projects/Billows/Audit-Manager/compliance-manager-be/.claude/worktrees/wt-fix-security（branch fix/security-b1）改 di_containers/dashboard_apis/（26 個宣告）與 app/flow_control/service/project_service.py，不要碰主 checkout，跑服務用 PORT=8001。pyproject.toml 對應 jedi-ai-dashboard 與 jedi-common 的 pin 改成 path 形式指向對應 worktree，poetry update 兩支套件名，path 改動不 commit。

在哪裡

registry.py:37   DashboardApi dataclass，新增「需要什麼權限」欄位
registry.py:71   26 支查詢登記處之一，逐一補上權限欄位
registry.py:122   同上
data_api_service.py:83   call_api，執行查詢前檢查權限欄位，未標記一律拒絕
di_containers/dashboard_apis/   BE 側 26 支查詢的 DI 宣告，逐一確認權限欄位對齊
app/flow_control/service/project_service.py:212   get_projects_for_dashboard
app/flow_control/service/project_service.py:224   is_admin=True 後門，直接刪除改用真實身分判斷
jedi_jedi-common/jedi_common/utils/serialization_util.py:12   _ORM_SKIP_KEYS 跳過清單，新增密碼鹽值欄位與 is_superadmin
jedi_jedi-common/jedi_common/utils/serialization_util.py:15   to_serializable，使用上面那份清單（跨套件共用，改動要小心）

怎麼修

① #60：registry.py:37 的 DashboardApi dataclass 新增「所需權限」欄位，:71／:122 等 26 支查詢登記處逐一補上各自需要的權限標記；data_api_service.py:83 call_api 在真正執行查詢前檢查這個欄位，沒有標記的查詢一律拒絕（fail-closed）——不要考慮「每支查詢自己檢查」或「改走正常入口」這兩個已否決方案
② #61：project_service.py:224 的 is_admin=True 直接刪除，改用呼叫者真實身分做判斷——效果是連專案管理者也只能看到自己參與的專案清單，這是決策者已接受的行為改變，不用另外請示
③ #62：不需要獨立修法，#60 的白名單機制上線後自動涵蓋；但要順手修正部門篩選參數從未真正傳遞的格式錯誤，並在回寫報告時說明這個問題原本被格式錯誤遮住、本卡修完格式錯誤後才會顯現，避免被誤判為新迴歸
④ #114 第一步：jedi_common/utils/serialization_util.py:12 的 _ORM_SKIP_KEYS 清單加上密碼鹽值欄位名與 is_superadmin 欄位名——這支工具被多個套件共用，本卡只做加清單這一步，第二步（更完整的欄位級別控制）不在本卡範圍，回寫時要標記「僅完成第一步」