側邊欄選單分組 — 詳細白話需求

目前系統側邊欄選單全部攤平成一層（DB public.ui_routes 共 39 個項目，全部 pid=0），即使有些功能項目已經 enable=0 不顯示，仍然顯示在使用者眼前的選單長到「太冗長」、不容易找到對應功能。

使用者希望按照業務領域把選單分成 7 個分組，每個分組是一個可展開的父節點，下面掛上對應功能入口，讓側邊欄一眼就能看出「我要找的東西在哪一類」。

側邊欄從上到下依序變成這 7 個分組，每個分組是可展開/收合的父節點：

1. 專案與任務        ▼
2. 合規與稽核        ▼
3. 溝通與互動        ▼
4. 租戶與組織        ▼
5. 系統管理          ▼
6. 系統設定          ▼
7. AI 與分析         ▼

各分組底下包含的功能入口（按目前使用者實際看到的中文標題列示，括號內是內部對應的 ui_routes.name）：

Group 1：專案與任務（icon: pi pi-briefcase）

• 專案儀表板（project-dashboard）— ⚠ 目前 AppMenu.vue 寫死，需搬進 DB
• 待辦任務（my-tasks）— ⚠ 目前 AppMenu.vue 寫死，需搬進 DB
• 專案管理（project-list）
• 我的稽核（audit-manage）
• 專案調查結果（report-manage）

Group 2：合規與稽核（icon: pi pi-shield）

• 合規資源庫（module-frame）
• 合規框架管理（compliance-framework-manage）
• 檢測工具管理（tool-plugin-manage）
• 流程範本管理（flow-template-manage）

Group 3：溝通與互動（icon: pi pi-comments）

• 公告（bulletin-list）
• 公告管理（bulletin-manage）
• 問卷管理（survey-manage）
• 回饋（system-feedback-manage）
• 系統回饋管理（system-feedback-view）
• 回饋整合設定（issue-integrate-config）

Group 4：租戶與組織（icon: pi pi-building）

• 租戶管理（tenant-manage）
• 機關（構）單位管理（department-manage）
• 帳號管理（user-manage）
• 權限管理（role-manage）

Group 5：系統管理（icon: pi pi-cog）

• 選單管理（system-menu-manage）
• 資訊系統管理（information-system-manage）
• 設備管理（device-manage）
• 儲存設備設定（storage-config）
• 雲端空間整合（cloud-integrations）

Group 6：系統設定（icon: pi pi-sliders-h）

• 郵件伺服器設定（smtp-config）
• LDAP伺服器設定（ldap-config）
• 通知設定（notify-config）
• 操作日誌（user-log）

Group 7：AI 與分析（icon: pi pi-chart-line）

• AI動態儀表板（ai-dashboard）

3.1 權限對應規則

為什麼這樣可行：BE jedi-auth 套件 ui_route_repo_impl.py:103-107 已實作「若路由無任何 route_capabilities 關聯設定 → 視為可見」的 fallback 邏輯。所以不掛 capability 等同於「對所有人開放」，免去額外建 capability 的繁瑣。

3.2 空分組自動隱藏規則

當某個使用者的角色 / capability 配置下，某個分組底下所有葉節點都被權限過濾掉時，該分組標題也不要顯示。

例如：某個 user 沒有「租戶管理 / 機關單位管理 / 帳號管理 / 權限管理」中任何一項權限，那「4. 租戶與組織」這個分組標題就完全不出現在他的選單上（而不是顯示一個點開來什麼都沒有的空殼）。

3.3 分組順序

依上面 1~7 的編號順序，由上而下顯示。不可更動這個順序（已是使用者明確指定的最終順序）。

3.4 分組內項目順序

每個分組內的功能入口，依上面列示的順序顯示（不再依照舊版 ui_routes.sort 的全域排序，而是改成「分組內局部排序」）。

4.1 In Scope（本期要做）

• 在 public.ui_routes 新增 7 個分組節點（pid=null/0，icon 如上述）
• 把 27 個現有 ui_routes 葉節點的 pid 指向對應分組節點
• 新增 2 個 ui_routes（project-dashboard / my-tasks），對應「Group 1」底下的「專案儀表板」「待辦任務」
• 修改 FE AppMenu.vue 移除寫死的 grcItems 陣列（讓兩個項目改從 /user/web-menu API 取得）
• BE get_user_web_ui_routes（在 jedi-auth 套件內）加上「空分組自動隱藏」邏輯
• 設定每個分組節點與對應 sort 值，確保 1~7 順序固定

4.2 Out of Scope（本期不做）

• 不處理 enable=0 的「附加頁面」：DB 內已 enable=0 的 12 個項目（workflow-setup / workflow-view / textbook-* / resource-version-manage / resource-manage / cruise-project-manage / cruise-feedback-view / report-view / customer-dashboard-editor / user-guide）保持原狀不動（不設 pid、不改 enable），它們本來就被 BE 過濾掉，不會出現在新版選單上。
• 不做 3 層深的樹狀結構：所有功能入口都是分組底下「直接掛」的葉節點，不再做更深的子選單。
• 不重新評估或整併現有功能：例如「workflow-* 跟 flow-template-manage 是否功能重疊」這類議題本期不討論。
• 不改 i18n 翻譯內容：分組名稱（「專案與任務」「合規與稽核」⋯）的中文直接寫進 ui_routes.name，FE 顯示時優先用 i18n key 對照，找不到對照就直接顯示 name 原文（這部分行為視 AppMenuItem.vue 的實作而定，需在 Phase 1 確認）。

這只是初估，正式的拆解、檔案清單、影響面盤點等留到 Phase 3「實作計畫」階段再做。

1. i18n 設計選擇：分組標題的中文是 (a) 直接寫進 ui_routes.name 由 FE 原樣顯示，還是 (b) 在 ui_routes.name 寫 i18n key、FE 透過 menu.json 對照後顯示？兩種做法都可行，差別在英文版 / 簡體版怎麼處理。Phase 1 設計時決定。
2. i18n key 的命名（若採方案 b）：例如 menu.group.project-task 等。
3. BE「空分組剪枝」邏輯放哪一層：放在 jedi-auth 套件的 user_service.get_user_web_ui_routes 內（影響其他 consumer），還是主專案在 route 層 wrap？外部套件異動規範參考 CLAUDE.md。
4. DB migration 的 uid 怎產生：分組節點與兩個搬遷項的 uid 規則（既有 ui_routes 都有手動指派的 uid，需要保持一致風格）。
5. 新版 sort 值的安排：是要全部重新編號（例如分組 sort=10/20/30...，組內葉節點 sort=10/11/12...），還是只動分組節點 sort、葉節點 sort 維持現狀靠 pid 自動分組？

依專案 docs/claude/feature-development-workflow.md 流程：

• Phase 0（白話需求）：✅ 本文件已完成。
• Phase 1（brainstorm 設計）：把這份白話需求帶進 superpowers:brainstorming skill，產出 docs/features/FR-029-2605-menu-group/design.md，包含 DB schema 變動、API 行為、FE 改動、i18n 策略、邊界 case 處理等技術設計。
• Phase 2（歸檔）：本資料夾 docs/draft_requirement_spec/menu-group/ 在 Phase 1 完成後搬到 docs/features/FR-029-2605-menu-group/，原資料夾刪除。
• Phase 3（實作計畫）：產出 docs/features/FR-029-2605-menu-group/implementation-plan.md。
• Phase 4（測試計畫）：必要時產出 test-plan.md（本需求屬 UI 重組，BE 邏輯改動小，可能不需要重型 test plan，由 Phase 3 評估）。
• Phase 5（實作）：按 plan 執行。
• Phase 6（review）：跨 BE / FE / 測試 repo review。