FR-048 Phase 2a 交接 prompt（全站端點授權盤點，唯讀不改 code）

下面整段是給執行 session 的 prompt。

【接手主題】FR-048 統一授權守門 Phase 2a — 全站寫入端點盤點，產出「端點授權矩陣」（純盤點，不改任何 code）

設計（必讀）：docs/analysis/2026-07-07-unified-auth-guard-design.md，尤其 §2 軸模型、§5.0 scope 定調、§7 Phase 2a 注意事項。 追蹤表（交叉驗證用）：docs/analysis/2026-07-07-known-pits-remediation-tracker.md §SEC。

【branch】fix/v1.8.0-bugs，禁止切 branch。本波零 code 變更，只產文件。

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 【scope（user 已定調：全站，不是只有坑清單）】

1. api/ 全部寫入 method：grep -rn "def post\|def put\|def delete\|def patch" api/ --include="*.py"（2026-07-07 實查 373 支、31 模組）。
2. 敏感 GET：匯出（export）、下載（download）、報表、qrcode、token 發放類。
3. jedi- 套件註冊的 route 也要涵蓋*：查 config/app_modules.py 的 blueprint/route 註冊來源，凡是掛在本 app 上的端點都入列（jedi-auth 的 role/user/tenant CRUD 是已知裸奔區，確認 route 到底註冊在主專案還是套件、逐支入列）。

【產出】docs/features/FR-048-2607-unified-auth-guard/endpoint-authz-matrix.md

格式：按模組分節，每支端點一列：

| Route path | Method | 現況守門 | 軸別判定 | 角色要求 | Phase | 狀態 | 備註 |

• 現況守門：無 / 僅 JWT / 已有（哪支 guard） — 要追進 service 層看，route 有 @jwt_required 不代表 service 沒守門（participant/SSP 16 支已有）。
• 軸別判定：①platform ②super-admin ③project-role ④capability ⑤signed-token / owner個案 / F刻意不擋。判定依據 §2 軸模型 + common/authz/__init__.py 決策表（Phase 1 已建）。
• 角色要求（軸③才填）：manager-only / 任一參與者 — 對照 docs/specs/ 各頁權限矩陣（§權限段）。
• F 刻意不擋也要入列並寫理由（health check / OAuth callback state token / FR-039 demo…），防下次盤點重查。

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 【判定規則】

• spec 權限矩陣有寫 → 照 spec。
• spec 沒寫 / FE-BE 粒度不一致（如 planning-status#1）/ 拿不準 → 標 「需 user 定調」，全部集中到矩陣檔頭的「待定調清單」段，不要自己猜著定。
• 讀端點原則上不入列（RLS 擋租戶），但 D 族型洩漏（回他人完整資料、token 明文）順手看到就記備註。

【交叉驗證（必做）】追蹤表 §SEC 的 75 條（六族分類 + 漏網 8 條）每條都要能對映到矩陣某列；對不上的回頭補列。已定案的（SEC-001 已修 182bb2f7、A 族 2 條進 Phase 4）直接標狀態。

【建議做法】量大（373+），可派 subagent 按模組分工掃（每 agent 給明確模組清單＋回報格式），主 session 彙整判軸——判軸權在主 session，subagent 只回報「route/method/現況守門/呼叫的 service method」事實。

【commit】矩陣完成後 commit（顯式 add、不 push），一句話 status ＋ 把「待定調清單」貼給 user 等定調。不要開始修任何端點——那是 Phase 2b/3 的事。