本卡是 FR-132 的第六個子需求 A.6（母卡 CM-2510 下的子母卡），決策者 2026-10-07 傍晚手測後點名：「現在都只有後端守門、前端全部沒動」。裁示：沒權限的按鈕一律隱藏（不是停用加說明）；專案內頁一起收；這版做完，要趕在只記錄觀察期結束前。

這系列在做什麼（白話）

後端 206 項權限的判定已經接好，側欄選單也照權限遮蔽了，但進到頁面之後，新增／修改／刪除／匯出這些按鈕大多不看權限：全站 117 支有按鈕的頁面，只有 17 支做了判斷、用到 19 項權限；51 支有寫入類按鈕卻完全沒判斷。症狀就是「按鈕看得到、按下去 403」，而且今天大半權限還在只記錄不擋，所以沒人發現——等轉真擋那天會一次爆出來。這系列把「頁內按鈕照權限隱藏」補齊，專案內頁也一起改成同一套判斷。

為什麼要做

• FR-132 原設計對前端只寫「既有 hasCap 改新名」（design.md §6.6 末段），按鈕遮蔽沒有任何一張卡負責——這是範圍疏漏，不是哪棒做錯。
• 前端判斷讀的是 /user/web-menu 帶回的 permissions（utils/userUtil.js:22-43），那份只含綁在選單頁上的權限；92 項沒綁頁的（SSP、證據分類、AI 小幫手…）在 hasCap 永遠是假。useMyCapabilities 用 effective-access 補，但要每頁自己 load。
• AI 小幫手右下角浮鈕（layout/AppLayout.vue:129-140）完全不看權限，是決策者發現的第一個例子。

關鍵設計決策

• D-A6-1 隱藏，不停用：本專案已有「授權唯讀」的停用＋說明（useLicenseReadonly），那是暫時狀態要解釋；沒權限是常態，隱藏最乾淨，也不和授權提示混在一起。
• D-A6-2 單一來源：登入後一次取得「全部有效權限」（走 effective-access 同一條判定，jedi-iam effective_access_service.py:26-63），存進 store；全站 has(cap) 只讀它。不再靠 web-menu 的 permissions 推（那是給選單用的），各頁不再自己 load。
• D-A6-3 按鈕對權限的依據是「這顆按鈕打的 API 守哪項權限」（inventory/a1-capability-tree.md 附錄 A 有 557 支 route → 權限），不是憑功能名猜；一顆按鈕打多支 API 時取寫入那支。
• D-A6-4 專案內頁雙層：公司層權限（grc.job.update 這類）決定按鈕出不出現，專案成員角色（manager／auditor）維持原本的「輪到誰做」判斷，兩者都過才顯示。不把成員角色換成公司層權限——那是 FR-B 的事。
• D-A6-5 只記錄的權限照樣隱藏：前端不看 enforce_mode。否則觀察期是假的（前端放行、後端只記錄、沒有人會被擋，看不出哪些角色缺權限）。配合 CM-2556 先補權限，才不會一上線稽核人員按鈕全消失。

怎麼拆

• T-6.1 單一來源（BE＋FE 底層，1 棒）：登入後取全部有效權限進 store，統一 has()，舊 hasCap 改成讀它；AI 小幫手浮鈕順手接上。
• T-6.2 盤點（1 棒，只讀）：117 支 view ＋ 69 支 components 逐顆寫入類按鈕對 API 對權限，產出一張表，含專案內頁的雙層標記。
• T-6.3～T-6.N 實作：盤點完依模組拆（估 5～6 棒：grc 專案內頁、oscal／module_frame、detection／evidence、survey／workspace／asset、system／iam／platform）。每棒照表加 v-if，不改業務邏輯。數量與卡號在 T-6.2 交付後補開。
• T-6.Z 守衛：一支測試掃所有打寫入 API 的 service 呼叫點，對應 view 必須有 has() 判斷（或登記在豁免清單並寫理由）。

共同設定與紀律

• 依賴 CM-2556（補權限）：T-6.3 起的實作棒上 DEV 前，CM-2556 的 migration 必須已套，否則既有角色的按鈕會整片消失、誤判成 bug。