本卡屬 FR-132 A.6（子母卡 CM-2559），機制三張之三。決策者原話「做完記得要寫入開發規則內」：把三層守門寫成規範、守衛、文件，讓它活過這次。骨架現在就能寫，細節等 CM-2564／2565 定案。建議 model：opus（寫規範要組織取捨）。

這一棒在做什麼（白話）

把「前端分三層守門、權限真相只有一份」寫進開發者動手那一刻會讀到的地方，並補一份分析文件記這次為什麼這樣選。沒有這張，三個月後新頁面又是裸的。

落點與內容（首腦定）

• FE CLAUDE.md 新增「權限守門三層」段，三條硬規則：①新頁必在後端 ui_routes＋route_capabilities 登記進入權限（規則：主要動作那顆），不登記守衛紅；②頁內寫入類元素一律 v-can，禁止再寫 hasCap／can／旗標判斷；③資料層條件（專案角色、狀態）用 v-if 與 v-can 疊加，不取代。每條附守衛測試檔名。
• BE .claude/rules/security/endpoints.md 加一段「前端對應」：後端開端點必掛守門 ⇄ 前端開頁面必登記、開按鈕必掛指令；三層各擋什麼一張表。FE 沒有 .claude/rules，不另建——規則住 FE CLAUDE.md。
• docs/claude/frontend-overview.md 權限段改寫：三層架構圖（mermaid）、進入權限怎麼定的那一句、v-can 三種值的語意、新頁登記五步驟、守衛怎麼跑、豁免怎麼登記。只寫現況不寫沿革。
• design.md A.6 節補「架構」小節：三層表、真相唯一（後端表→/users/me/capabilities→store→守衛與指令）、被排除的做法（逐顆補、前端寫死權限名、內頁跟側欄頁同門檻）各一句理由。
• 分析文件 docs/analysis/2026-10-07-fr132-a6-frontend-three-layer-authz.md：首腦已先寫骨架（本卡接手補 CM-2564／2565 定案後的細節：端點形狀、指令簽名、守衛檔名）。
• ddd-compliance-reviewer 規格（docs/claude/custom-agents.md）加三條掃 FE diff 的判準：新路由無登記、寫入鈕無 v-can、新增散寫判斷。

驗收

• 一個沒看過 repo 的人照 frontend-overview.md 五步驟開一頁，守衛測試從紅變綠。
• grep -n 'CM-25\|這次\|原本\|改判' 各文件零命中（除 footer 指路句）。

紀律

• BE ~/Projects/Billows/Audit-Manager/compliance-manager-be、FE ~/Projects/Billows/Audit-Manager/compliance-manager-fe、jedi ~/Projects/Jedicogy/module/jedi-python-package/，皆 branch feature/azure-iam，不切 branch、不 push、只動 DEV（localhost:5432/guidant_ai_dev，帳密查 .env）。先讀各 repo CLAUDE.md。
• 註解只寫為什麼與陷阱；做了什麼進 commit message。檔案 800 行、函式 60 行（Vue script 40 行）上限，超標只准拆。
• 做完各 repo 顯式 git add 檔名 commit ＋ 回寫本卡（做了什麼、hash、驗證、手測清單）＋ 狀態改「修正待驗證」，不等令；push 等令。卡住也 commit 已完成部分並回寫卡在哪。

補件（首腦，2026-10-07 晚）

• 規範加一條：新功能點先進矩陣——掛 v-can 就自動進，守衛沒看到就紅；矩陣 permission-matrix.json 是設計標準與唯一來源，手冊與角色設定頁都從它出。
• 文件站（doc-site-build 機制）從矩陣產兩頁：「各頁功能點與權限」（給 PM／客戶 IT）、「出貨五角色各能做什麼」（拿 inventory/a1-shipped-roles.json 的 pattern 展開對矩陣）。只寫現況不寫沿革。