A.1 盤點：platform 平台層端點 × 三段式能力點

卡片 CM-2515（FR-132 T-1.5）。唯讀盤點，不改程式、不改 DB。

• 範圍：AI 儀表板（ai-dashboard）、AI 呼叫紀錄（ai-call-log）、AI 額度（ai-quota）、公告（bulletin、bulletin-list）、意見回饋（feedback、feedback-view）、操作紀錄（log）、支援頁（診斷包、最近錯誤）。另把卡片「怎麼做」列到的 AI 小幫手（jedi-ai-bot）一併盤。
• 主專案 route 檔 4 支、15 個 method：api/ai_quota/ 1 支（7）、api/ai_call_log/ 1 支（5）、api/support/ 2 支（2）。
• 外部套件 route 檔 6 支、20 個 method：jedi-ai-dashboard 1 支（2）、jedi-ai-bot 1 支（2）、jedi-bulletin 1 支（5）、jedi-issue 2 支（8，含標籤下拉）、jedi-log api_log 1 支（2）。讀的是 .venv/lib/python3.11/site-packages/ 內實際執行的版本（ai-dashboard 1.6.1、ai-bot 1.5.0、bulletin 1.2.1、issue 1.3.2、log 1.3.2）。jedi-log 的 forwarding（log 轉發設定）屬 T-1.4 系統設定，不列。
• 合計 10 支檔、35 個 method。
• DEV 查詢時間：2026-10-06 17:28（本機 localhost:5432/guidant_ai_dev）。範圍內舊能力點 16 個；全庫能力點 123 個，其中 is_platform = true 16 個。

1. 「16 個平台層能力點」跟本卡的資源幾乎沒有交集。 DEV 的 16 個 is_platform 能力點只有 log.read 在本卡範圍；其餘 15 個是合規框架（3）、外部議題整合設定（4）、授權（1）、通用系統設定（3）、系統選單（4），分屬 T-1.2 與 T-1.4。本卡範圍的 16 個舊能力點裡，15 個是 is_platform = false。16 這個數字對（123 − 16 − 4 ＝ 103 成立），但「平台層能力點集中在 platform 模組」這個前提不成立。逐一對照見文末「附錄：16 個 is_platform 能力點」。
2. 所以「platform（原廠）」這個模組名放錯了大半內容。 AI 儀表板、AI 額度、AI 呼叫紀錄是租戶自己用、自己管的；公告是租戶對自己部門發的；意見回饋是租戶成員自己送、租戶管理員看全部。真正只有原廠（root 租戶）能碰的，只有操作紀錄、支援頁、AI 額度的「各租戶上限」三塊。建議見「待首腦裁清單」第 1～3 條。
3. 原廠層的後端守門走的是「平台管理員」判定，不是能力點。 操作紀錄（platform_admin_required）、支援頁（service 層 require_platform_admin()）、AI 額度上限（同上）三塊，沒有一支 route 檢查能力點；log.read 只決定選單看不看得到。平台層要不要也改成能力點守門，見待裁第 4 條。
4. 公告列表有一個疑似缺口：POST /bulletins 只驗登入，「看哪些公告」由請求帶不帶 auth: true 決定。不帶、且使用者沒有所屬部門時，service 不下任何條件，等於看到本租戶全部公告（不受發送範圍限制）。見「確認要補的守門缺口」第 1 條。
5. feedback.export 不是孤兒：匯出端點 POST /feedback/export/<type> 由它守（jedi_issue/api/routes/feedback_route.py:140），DEV 有 5 個角色持有。它只是沒綁任何頁面選單；FE 匯出鈕不判權限、一律顯示，沒權限的人按了才 403。

模組歸屬依決策者 2026-10-06 的八條定案填（見文末「定案結論」）。

• 「每個資源固定四個」照規則全開（feedback-review 例外，見定案第 8 條）；今天沒有對應端點的動詞（例如 ai.call-log.create）仍要建出來。
• is_platform 欄位：只有 platform.* 三組為 true，其餘 false。

欄位：route 路徑 ｜ HTTP ｜ 程式位置 ｜ 現有守門 ｜ 新三段名 ｜ 現有能力點 ｜ is_platform（新名）｜ 對應 UI ｜ 可指派範圍層 ｜ 備註。

守門縮寫：J＝jwt_required；L(x)＝require_license("x")；C(x)＝require_capability("x") 或套件的 capability_required；PA＝平台管理員（require_platform_admin／platform_admin_required）；S: 後面是 service 層的檢查。路徑前綴一律 /api/1.0。套件路徑省略 .venv/lib/python3.11/site-packages/。

AI 儀表板（ai.dashboard）

套件守門 jedi_ai_dashboard/api/guards.py：license 與能力點都委派宿主注入（core/plugins/ai_dashboard.py:89-91），宿主沒接線一律拒絕，不放行。

AI 小幫手（ai.assistant）

AI 呼叫紀錄（ai.call-log）

基礎設施豁免：common/authz/license.py:116 把 ai-call-log 列在不受授權照管制的清單，改名時這個字串要跟著改。

AI 額度（ai.quota／platform.ai-quota-ceiling）

基礎設施豁免：common/authz/license.py:118（ai-quota）。

公告（workspace.bulletin）

套件沒有 license 軸。bulletin.read 與 bulletin-list.read 兩顆舊名，後端沒有任何 route 守，只綁選單。

意見回饋（workspace.feedback／workspace.feedback-review）

能力點名由套件 jedi_issue/plugin/contract.py:59-65 預設值決定（feedback-view.read 對應 feedback_read_all_capability）。套件沒有 license 軸。

操作紀錄（platform.api-log）

資源名建議 api-log 不沿用 log：同模組還有 log 轉發設定（T-1.4 的 log-forwarding），單一個 log 會讓人分不出是哪個。log.read 宣告在套件 jedi_api_log/plugin/contract.py:22。

支援頁（platform.support）

DEV ui_routes 把 /system/support 綁在 storage-config.read／storage-config.update，FE 路由註解也寫明「能力點擋不住（每個租戶管理員都有 storage-config），改靠 requiresPlatformAdmin」。改成 platform.support.read 後這個借用就可以拆掉，見待裁第 5 條。

沒有任何 route 用到的能力點（孤兒）

bulletin.read、bulletin-list.read、log.read，共 3 個。三個都有綁選單，孤兒不等於沒用：它們目前決定選單看不看得到。卡上懷疑的 feedback.export 不是孤兒。

角色範本要注意的

決策者已裁：feedback-view.read（新名 workspace.feedback-review.read）從一般成員範本拿掉，改由系統人員或管理員角色持有。以下為盤點原始觀察。

core/role_templates.py 給一般成員 bulletin-list.read、feedback-view.read、ai-dashboard.read、feedback.*（create／read／update／delete）。其中 feedback-view.read 給一般成員，意思是每個成員都看得到全公司的意見回饋——如果這不是本意，改名時順便從範本拿掉；如果是本意，第 8 條「拆兩個資源」就沒有實質意義，可以直接合併。請首腦一併確認。

本卡只讀，修正另開卡。第 1 條（公告列表）已併入 T-4.6（CM-2542）；第 2、3 條屬改名時順手修，由 A.2／A.5 帶走。

1. 公告列表的「管理模式」對沒有所屬部門的人不設範圍：POST /bulletins 只驗登入；請求不帶 auth: true 就走管理模式，而管理模式只有在使用者有所屬部門時才限定「自己建的」（jedi_bulletin/app/service/bulletin_service.py:246-251）。沒有部門的登入者直接打 API 不帶旗標，看得到本租戶全部公告，不受發送範圍限制（RLS 仍限在本租戶內）。可能是刻意給沒有部門的管理員看全部，但沒有能力點檢查，任何人都能用。建議：管理模式要求 workspace.bulletin.update（或 create），讀者模式要求 workspace.bulletin.read，由後端依能力點決定模式，不吃前端旗標。
2. 意見回饋匯出鈕不判權限：SystemFeedbackManage.vue:265 的匯出鈕一律顯示，沒有 feedback.export 的人按了才 403。不是安全缺口（後端有守），是「按鈕按了沒反應」型的體驗問題，改名時 FE 補一個 hasCap。
3. 支援頁選單借用 storage-config.*：見待裁第 5 條。不是安全缺口（FE 路由與後端都另驗平台管理員），但選單綁定是錯的。

• core/host_capabilities.py:66-75（AI_CALL_LOG、AI_QUOTA）
• app/ai_quota/service/ai_quota_setting_service.py 的 _READ_CAPABILITY／_UPDATE_CAPABILITY；api/ai_call_log/routes/ai_call_log_route.py:34
• common/authz/license.py:116-118（基礎設施豁免清單的 ai-call-log、ai-quota）——這是 resource_type 字串，模組改名後 license 軸怎麼對要一起定
• 套件 contract：jedi_ai_dashboard/plugin/contract.py:25-30（另 api/guards.py 的 LICENSE_RESOURCE_TYPE = "ai-dashboard" 是授權照的模組名，不是能力點，FR-062 的加值包名要不要跟著改另議）、jedi_bulletin/plugin/contract.py:30-43、jedi_issue/plugin/contract.py:48-65、jedi_api_log/plugin/contract.py:22
• core/role_templates.py:19-21、:26-29
• DEV route_capabilities：/dashboard/ai-dashboard、/system/ai-call-log、/system/ai-quota、/bulletin/bulletin-manage、/bulletin/bulletin-list、/feedback/system-feedback-manage、/feedback/system-feedback-view、/log/user-log、/system/support 九頁的綁定
• FE：SystemFeedbackManage.vue 匯出鈕補判斷；AiQuotaPage.vue 依 can_adjust 顯示（後端回的，不用改）

決策者 2026-10-06 逐條裁決，第 1～7 條照盤點建議，第 8 條決策者補了理由。

1. 開 ai 模組，收 ai.dashboard、ai.call-log、ai.quota、ai.assistant 四個資源，不放 platform。AI 儀表板是賣給租戶的加值包，硬規則要求整包落在單一模組；另外三個客戶會當「AI 相關」一組來授權，放同一模組最符合客戶的想法（模組可以比加值包大，混進不收費項目不違規）。
2. AI 額度拆兩半。 租戶自己的額度歸 ai.quota；原廠「各租戶上限」三支端點歸 platform.ai-quota-ceiling（is_platform = true）；/system/ai-quota/me 不掛能力點。理由：ai-quota.read/update 管的是本租戶自己的額度，每個租戶管理員都要能設，放 platform 會被 is_platform 擋掉；/me 是額度黃條，一般成員也要看。
3. platform 只留 api-log、support、ai-quota-ceiling 三個資源；公告與意見回饋開 workspace 模組（名字沿用 workspace）。理由：公告與意見回饋是租戶內部使用，is_platform 為 false，放原廠名下會讓人誤解。
4. 原廠層後端維持平台管理員判定，再加能力點檢查，兩道都要過。 只看平台管理員，原廠內部分不出「客服能看錯誤、不能下載診斷包」；只看能力點，is_platform 能力點被誤配給客戶角色就直接開門（診斷包含跨租戶資料），第二道是安全網。
5. 新建 platform.support.read（最近錯誤）與 platform.support.export（診斷包），/system/support 改綁 platform.support.read，拆掉借用的 storage-config.*。診斷包屬對外送出類，獨立成 export 才能分給不同人。
6. 新建 ai.assistant.*，聊天與清除紀錄要求 ai.assistant.read，出貨範本一般成員給 read（行為不變）。理由：每次聊天都花 AI 錢，客戶要做「只有某些部門能用 AI」目前沒有任何開關。
7. 公告合併成一個 workspace.bulletin。 bulletin-list.read → workspace.bulletin.read；bulletin.read 刪除，管理頁改綁 workspace.bulletin.create；後端依能力點決定管理／讀者模式，不吃前端旗標（對應缺口第 1 條，併入 T-4.6）。
8. 意見回饋分開，不合併。 feedback.* → workspace.feedback.*（建立並看自己送的回饋）；feedback-view.read → workspace.feedback-review.read（系統人員或管理員收集全公司意見用）。決策者理由：「兩個功能意義不同，一個是建立自己的回饋，一個是系統人員或管理員來收集意見」。連帶兩個決定：
   • feedback-review.read 從一般成員出貨範本拿掉（本意不是讓全員看全公司回饋）。
   • feedback-review 這種範圍型讀取權限破例只開 read，不補 create／update／delete 空殼；T-1.6 把此寫成通則。

DEV capabilities WHERE is_platform，共 16 個（查詢時間同上）。除 log.read 外都不在本卡範圍，這裡只對到守門位置與歸屬卡，逐 method 明細由該卡負責。

合計 1＋3＋4＋1＋3＋3＋1 ＝ 16。非 root 租戶 *.*.* 展開範圍 123 − 16 − 4（workflow）＝ 103 成立。

沿革見 FR-132-LOG.md 與 git log。