FR-083.D2 掃 AI 儀表板「宿主接線與 27 支 API 名冊」（18 檔，BE repo，Opus 1M ＋ low，只掃不修）

本卡屬 FR-083（母卡 CM-1639），第 1 棒（建議先跑）：宿主接線與 27 支 API 名冊（BE repo，不是 jedi monorepo）。只掃不修。

這一棒在做什麼（白話）

掃主專案裡「AI 儀表板」的接線程式碼（18 個檔）。使用者用自然語言問問題，AI 自己決定要呼叫系統裡的哪一支查詢功能——這 18 個檔就是「有哪些查詢功能可以被 AI 呼叫、呼叫時怎麼檢查權限」的地方。

🔴 為什麼這一棒最重要：FR-079 證明了有洞，但只驗證了 27 支裡的 1 支

FR-079 的 F13（docs/features/FR-079-2609-bulletin-security-scan/scan-B2-host-wiring.md，動手前先讀那一節）查到：

AI 儀表板可以直接呼叫「取公告列表」，這條路不經過網頁那層的任何權限檢查
呼叫端寫死 params={}（ai_dashboard_app_service.py:76），使部門過濾永遠不生效
結果前三筆原文送給第三方 LLM
→ 任何登入者（不需要任何公告權限）可讀全租戶公告，含未發布的草稿

當時只追了公告那一支。首腦這次盤點發現：di_containers/dashboard_apis/ 有 14 支申報檔，合計申報 27 支 API。

participant（專案成員）  7 支
  get_project_participants / get_process_participants / get_task_assignees /
  get_user_task_queue_by_sp / get_project_control_participants /
  get_control_group_participants / get_project_group_participants

auth（認證）            4 支   ← 🔴 最高風險
  get_roles / get_users / get_tenants / get_org_units

flow_engine 3｜oscal 2｜project 2｜survey 2
bulletin 1｜feedback 1｜device 1｜system_menu 1
system_config 1｜module_frame 1｜user_auth_provider 1
                       ────
                        27 支

auth.get_users／auth.get_tenants／auth.get_org_units 是全站使用者名冊、租戶清單、組織架構。 還有 26 支從未驗證過——這一棒的核心工作就是逐支確認。

重點看什麼

這些是首腦讀過程式碼後的起點，未經驗證，以你實際讀到的為準。工具不會照這份清單走——FR-081 的 I3／I4／I6 與 FR-082 的 A1 連續兩個 arc 都是「工具在範圍內零產出、卡片重點一項沒答」，真正的發現全是人工補查的。這份清單你要自己追。

① 逐支確認那 27 支 API 的權限形狀。（本棒最重要，其餘九點都是它的細節）對每一支問三件事：(a) 它對應的 service 方法自己有沒有做權限檢查（還是全靠 route 層，而旁路不經 route）？(b) 它宣告的 required_params／optional_params 裡，哪些會被自動注入、哪些會被 **kwargs 吞掉（F13 的成因就是 org_unit_id 被吞掉而不轉成過濾條件）？(c) 回傳的資料送去給 LLM 合不合適？優先順序：auth 4 支 → participant 7 支 → 其餘。
② auth 那 4 支是最高風險。 get_users（全站使用者）／get_tenants（租戶清單）／get_org_units（組織架構）／get_roles（角色）。要追：這四支的 service 方法有沒有租戶過濾？經旁路呼叫時，A 租戶的使用者會不會拿到 B 租戶的名冊？這是跨租戶洩漏面。
③ 自動注入的參數怎麼決定。 di_containers/dashboard_apis/__init__.py（55 行）與套件的 data_api_service.py:172-191：呼叫時會自動注入 user_id／user_uid／tenant_id／org_unit_id／user，但只注入「該 API 有宣告」的那些。要追：沒宣告 tenant_id 的 API 就不會拿到租戶資訊——那 27 支裡有幾支沒宣告？沒宣告的會怎樣？
④ api/ai_dashboard/__init__.py（105 行）的守門。 儀表板自己那條 route 掛了什麼？誰能用 AI 儀表板？要查 DB capabilities 表有沒有對應能力點（FR-079 的 bulletin.read 是「有定義卻沒人檢查」，FR-081 的 get_members 是「根本沒定義」——這兩種不同，要分清）。
⑤ dashboard_registry_wiring.py（82 行）——名冊怎麼組起來的。有沒有辦法在執行期注入額外的 API？container_service() 這個 provider 解析函式會不會被外部影響？
⑥ ai_dashboard_containers.py（71 行）——DI 註冊。service 是 Singleton 還是 Factory？（CLAUDE.md 的 repo session lazy 鐵則相關；FR-082 的 RedisChatHistoryStore 就是 Singleton。）