今天是鐵人賽第十五天，不知不覺就過半了。
昨天搞定認證相關的程式碼，要繼續推進度了。

結果一開始不說推進度，差點讓進度倒退到兩天前。
今天照慣例請 AI 同事規劃進度，沒想到他直接暴衝，完全沒跟我討論就開始實作，還做了一些不太合適的調整。於是我請他先把這些變更還原。

我原本的想法只是把他剛新增的檔案和修改的程式還原就好，但因為我在說明文件中提到使用 Git 版本控制，加上這兩天主要是在手動檢查與微調、沒有提交版本，他就直接把整個專案還原到兩天前最後一次版本控制的狀態。

當下我真的是被嚇出一身冷汗，雖然這兩天改的多是非核心內容，但也動了不少細節。幸好後端容器還沒關，裡面保留了昨天最後 build 上去的後端程式碼，我立刻用 docker cp 指令把這兩天的修改拉回來，才成功恢復到最新狀態。

最後損失的，只是沒有放進後端容器的說明文件、一些腳本程式，以及 Docker 設定檔，還算在可接受範圍。
我花了一點時間將沒被還原的內容手動還原，並測試了API功能都正常執行。
確認功能正常後，我先請AI同事幫我推送一版上Github避免他又太衝動還原了。

到這時，終於可以開始推進專案進度了。
這次，我給 AI 同事的指令就比較謹慎：
除了提醒他用小顆粒度的方式去計畫，也告訴他在跟我說完整計畫之前不要開始實作。
這次 AI 同事比較聽話，先把專案管理、任務管理與時間追蹤等內容規劃完整，然後停下來徵詢我的意見。

為了提升應用的品質，我先請 AI 同事以後端工程師的角度，分析專案是否有可以優化或缺少的地方。AI 同事帶入角色後，提出了不少實用的建議。

除了從程式角度分析之外，我還請他從使用者的角度，分析所需功能。
我要求 AI 同事帶入 studio-producer 與 project-shipper 兩個角色的視角，思考如果他們要使用這套軟體來完成工作，還需要哪些功能，並指出這些功能在這個階段後端需要做哪些支援。

這次 AI 同事理解了我的需求，給出了一份「使用者角度尚需的功能」以及「後端需要增加的參數」的建議清單。除此之外，他還提出了一些 UI/UX 的需求。我想，既然都提到 UI/UX，不如請 AI 同事再辛苦一點。

我進一步請 AI 同事以前端工程師的角度，思考在設計給專案管理用的 UI/UX 功能時，後端需要提供哪些支援功能。結果，AI 同事果然給出了更具體、可能需要的功能要求清單。

到此，專案管理功能的設計已大致完成。當然，未來在實作過程中可能還會出現新的需求，這是不可避免的；但事先盡可能預見需求，可以大幅減少後續修改的次數。

工欲善其事，必先利其器，而事前的周詳計畫，就是構建軟體的最佳利器。

下一篇，就將開始請 AI 同事依據這份計畫，實際建構專案管理功能了。

以下為今天的研究流程

首先開始前的老樣子，請AI同事了解應用現況。
我給AI的指令:

@ai_context.md @README.md @軟體核心架構規劃.md @功能需求總覽.md   了解目前現況

AI同事了解完目前專案進度後，要繼續做第二階段的核心專案與任務管理的功能。
我給AI的指令：

@agents/engineering/backend-architect.md 請幫我根據近期目標，計畫如何實作專案管理功能，每項使用小顆粒度的方式去規劃。

結果可能是 Gemini CLI 今天又更新了，因為我沒先跟它確認今天的計畫，AI 同事直接從計畫 1.1 的「定義 Project 模型」開始，完全沒先跟我溝通，就自己暴衝。這算是我的小失誤，今天的 AI 同事明顯比較活潑。
由於它做了許多我意料之外的東西，我只好請它還原剛才暴衝做的內容。不過因為它引進了 Git 來做版本控制，所以會先查 git status 看有哪些變更，再進行還原。

問題來了——我這兩天都在處理認證功能，昨天還是以人工方式排查，所以沒有做 Git 提交。結果 AI 同事一個指令，直接把內容還原到兩天前最後一次提交的版本。
幸好我昨天測試的後端容器還沒關，程式碼相關的修改還在，只是一些沒包進後端的底層文件（README.md、docker-compose.yml）和python腳本的小調整沒還原。差點就嚇出一身冷汗。
這次真是再次提醒我，版本控制一定要隨進度提交，否則一不小心，幾個小時的進度就可能消失。

手動還原那些沒被還原的檔案跟說明文件後，我先請AI同事幫我把內容推送上github以免又再度發生一樣的事情。
做完版本控制後，我先重開Gemini CLI清掉舊文本，一樣請AI同事先了解專案後，請他給出今天計畫。
我給AI的指令：

好的，請依照目前現況進度幫我計畫，計畫時請用小顆粒度的方式去計劃，並且先告訴我完整計畫不要直接實作 

這次AI同事就規劃的比較詳細確實，也會先停下來問我是否實作了。
下面是計畫中有關專案管理的部分：

專案管理
目標：實作專案的建立、查詢、更新、刪除功能，並管理專案成員。

1. 資料庫模型與結構定義
   • 任務 3.1.1：在 backend/models/ 目錄下建立 project.py 檔案。
   • 任務 3.1.2：在 project.py 中定義 Project 模型，包含以下屬性：
     • id (UUID, 主鍵)
     • name (str, 專案名稱)
     • description (Optional[str], 專案描述)
     • created_by_id (UUID, 建立者使用者 ID，外鍵關聯 User 模型)
     • status (str, 專案狀態，例如 'active', 'completed', 'archived'，可考慮使用 Enum)
     • start_date (Optional[datetime], 專案開始日期)
     • end_date (Optional[datetime], 專案結束日期)
     • created_at (datetime, 建立時間)
     • updated_at (datetime, 更新時間)
   • 任務 3.1.3：在 project.py 中定義 ProjectMember 關聯模型，用於管理專案成員，包含：
     • project_id (UUID, 外鍵關聯 Project 模型)
     • user_id (UUID, 外鍵關聯 User 模型)
     • role (str, 成員在專案中的角色，例如 'owner', 'member'，可考慮使用 Enum)
     • created_at (datetime, 建立時間)
     • updated_at (datetime, 更新時間)
   • 任務 3.1.4：更新 backend/models/user.py，建立 User 與 Project 之間的多對多關係，透過 ProjectMember
     關聯模型。
2. API 端點 (路由)
   • 任務 3.2.1：在 backend/routers/ 目錄下建立 projects.py 檔案。
   • 任務 3.2.2：在 projects.py 中實作以下 API 端點：
     • POST /projects/：建立新專案。
     • GET /projects/：查詢所有專案 (支援分頁、篩選，例如按狀態、建立者)。
     • GET /projects/{project_id}：依 ID 查詢單一專案。
     • PATCH /projects/{project_id}：更新專案資訊。
     • DELETE /projects/{project_id}：刪除專案。
     • POST /projects/{project_id}/members/：添加專案成員。
     • DELETE /projects/{project_id}/members/{user_id}：移除專案成員。
   • 任務 3.2.3：為所有專案相關 API 端點添加認證與授權保護，確保只有具備相應權限的使用者才能操作。
3. 服務層邏輯
   • 任務 3.3.1：在 backend/services/ 目錄下建立 project_service.py 檔案。
   • 任務 3.3.2：在 project_service.py 中實作 ProjectService 類別，包含以下方法：
     • create_project：處理專案建立的業務邏輯，包括數據驗證、預設值設定。
     • get_project：根據 ID 獲取專案，並進行權限檢查。
     • get_all_projects：獲取所有專案，並處理分頁和篩選邏輯。
     • update_project：處理專案更新的業務邏輯。
     • delete_project：處理專案刪除的業務邏輯。
     • add_project_member：添加專案成員，並處理成員角色。
     • remove_project_member：移除專案成員。
     • check_project_permission：通用權限檢查方法。
4. 整合與測試
   • 任務 3.4.1：更新 backend/main.py，整合 backend/routers/projects.py 中的路由。
   • 任務 3.4.2：在 backend/tests/ 目錄下建立 test_projects.py 檔案。
   • 任務 3.4.3：為專案管理功能編寫全面的單元測試和整合測試，涵蓋：
     • Project 和 ProjectMember 模型的正確性。
     • 所有 API 端點的 CRUD 功能和成員管理功能。
     • 認證與授權保護的有效性。
     • ProjectService 中業務邏輯的正確性。

看起來沒什麼問題，不過為了讓計畫品質上升，我請AI同事用後端工程師的角度去review他的計畫，看有沒有需要優化的地方。
我給AI的指令：

@agents/engineering/backend-architect.md 請用你的視角，去看3.專案管理的內容有沒有需要優化或缺少的地方

AI同事給了這個計畫一些不錯的細節補充：

優化與考量點：

1. 資料模型增強 (Data Model Enhancements)
   • 專案軟刪除 (Soft Delete for Projects)：
     • 建議：在 Project 模型中添加一個 is_deleted (布林值，預設為 False) 欄位，而不是直接執行硬刪除。
     • 理由：這允許專案在未來被恢復，並保留歷史數據用於審計或報告，這在專案管理系統中通常很重要。刪除操作將變為更新 is_deleted 狀態。
   • 專案狀態管理 (Project Status Management)：
     • 建議：雖然計畫中提到了 status 欄位，但可以考慮為專案生命週期定義一個更健壯的狀態機（例如：draft、active、on_hold、completed、archived、cancelled）。
     • 理由：這有助於在服務層強制執行業務規則，確保狀態轉換的邏輯性。
   • 專案角色粒度 (Project Roles Granularity)：
     • 考量：ProjectMember 中的 role 目前是一個簡單的字串。對於更複雜的權限場景，未來可能需要將其與全局的 Role 和 Permission 系統（來自「使用者與權限管理」階段）連結，以定義專案內部的細粒度權限（例如：「可以編輯專案設定」、「可以邀請成員」）。
     • 理由：這是一個未來擴展的考量，目前使用字串是可接受的，但應意識到其潛在的限制。
   • 預設值 (Default Values)：
     • 建議：確保 created_at 和 updated_at 欄位在模型定義時有適當的預設值（例如使用 datetime.utcnow 或 SQLModel/SQLAlchemy 的 func.now()）。
2. API 設計與實作 (API Design & Implementation)
   • 過濾/排序/分頁細節 (Filtering/Sorting/Pagination Details)：
     • 建議：計畫中提到了 GET /projects/ 支援分頁和篩選，但沒有具體說明如何實現。應明確定義查詢參數（例如：?status=active&sort_by=name&page=1&size=10）。
     • 理由：清晰的 API 規範有助於前端開發和未來的維護。
   • 響應模型 (Response Models)：
     • 建議：為所有 API 端點明確定義 Pydantic 響應模型。
     • 理由：這確保了輸出結構的一致性，並能自動生成 OpenAPI 文件，提升 API 的可用性。
3. 服務層邏輯 (Service Layer Logic)
   • 事務管理 (Transaction Management)：
     • 建議：對於涉及多個資料庫寫入的操作（例如：創建專案並將創建者添加為成員），確保使用適當的事務管理來維護數據一致性。
     • 理由：這可以防止部分操作成功而部分失敗導致的數據不一致問題。
   • 事件日誌/審計 (Event Logging/Auditing)：
     • 建議：對於專案創建、刪除或成員變更等關鍵操作，考慮添加明確的日誌記錄或審計機制，以追蹤誰在何時做了什麼。
     • 理由：這與整體計畫中提到的「審計日誌」相符，對於安全和問題追蹤至關重要。
4. 性能考量 (Performance Considerations)
   • 資料庫索引 (Database Indexing)：
     • 建議：雖然計畫中沒有明確提及，但應確保為頻繁查詢的欄位創建適當的資料庫索引（例如：ProjectMember 中的 project_id 和 user_id，Project 中的 created_by_id 和 status）。
     • 理由：隨著數據量的增長，索引對於查詢性能至關重要。
   • N+1 查詢問題 (N+1 Query Problem)：
     • 建議：在獲取專案及其相關數據（如成員）時，注意 N+1 查詢問題。確保使用高效的 ORM 查詢（例如 SQLModel/SQLAlchemy 中的 selectinload 或 joinedload）來一次性獲取相關數據。
     • 理由：避免在循環中執行大量單獨的資料庫查詢，這會嚴重影響性能。

在後端方面AI同事給出了一些性能考量與安全考量的，但軟體畢竟是給使用者去用的，所以我也請AI同事以專案管理的腳色去給出應用面的建議，來調整後端資料庫需要用到哪些設計。
我給AI的指令：

@agents/project-management/project-shipper.md @agents/project-management/studio-producer.md 之前是軟體面，現在我希望你分別以這兩個角色，給出應用面的建議，並假設如果需要用到這些功能，這邊要怎麼設計

AI同事分別以 project-shipper 與 studio-producer的腳色分別給了我不少原本沒有的建議：

以 project-shipper (專案交付者) 的視角
project-shipper 關注的是確保產品或功能能夠順利發布、達到預期影響並有效傳達給目標受眾。對於專案管理，這意味著需要工具來追蹤發布準備度、管理發布時間線和協調跨團隊溝通。
應用層面建議與設計：

1. 發布準備度檢查清單 (Launch Readiness Checklist) 整合
   • 應用建議：在每個專案的儀表板或專案詳情頁面中，整合一個可自定義的「發布準備度檢查清單」。這個清單可以包含多個可配置的項目（例如：「功能開發完成並測試」、「行銷素材準備就緒」、「支援文件已更新」等）。專案經理或 project-shipper 可以逐一勾選完成，系統會自動計算並顯示專案的整體發布準備度百分比。
   • 設計實現：
     • UI/UX：在專案詳情頁面新增一個「發布」或「準備度」標籤/區塊。每個檢查項目顯示為一個帶有勾選框的列表，並顯示其狀態（例如：未完成、進行中、已完成）。頂部顯示一個進度條或百分比數字。
     • 資料模型：
       • 可以在 Project 模型中新增一個 launch_checklist 欄位，儲存為 JSONB 類型，內容為一個列表，每個元素包含 item_name (str), is_completed (bool), assigned_to_id (Optional[UUID])。
       • 或者，建立一個新的 ProjectChecklistItem 模型，包含 id (UUID), project_id (UUID, 外鍵), item_name (str), is_completed (bool), assigned_to_id (Optional[UUID]), due_date (Optional[datetime])。
     • API 端點：
       • GET /projects/{project_id}/launch_checklist：獲取專案的發布檢查清單。
       • PATCH /projects/{project_id}/launch_checklist/{item_id}：更新檢查清單項目的狀態或指派人。
       • POST /projects/{project_id}/launch_checklist：添加新的檢查清單項目。
2. 發布時間線與里程碑可視化 (Release Timeline & Milestones Visualization)
   • 應用建議：為每個專案提供一個清晰、視覺化的發布時間線，標示出關鍵的發布里程碑（例如：「功能凍結日」、「QA 完成日」、「Go/No-Go 會議」、「正式發布日」）。這將使 project-shipper 能夠快速評估即將到來的發布和潛在的瓶頸。
   • 設計實現：
     • UI/UX：在專案概覽頁面或專案詳情頁面中，提供一個類似甘特圖或簡單時間線的組件。里程碑將作為時間線上的獨立標記，並可顯示其狀態（例如：已達成、延遲）。
     • 資料模型：
       • 可以在 Project 模型中新增一個 release_milestones 欄位，儲存為 JSONB 類型，內容為一個列表，每個元素包含 milestone_name (str), due_date (datetime), is_completed (bool)。
       • 或者，建立一個新的 ProjectMilestone 模型，包含 id (UUID), project_id (UUID, 外鍵), name (str), due_date (datetime), is_completed (bool), completed_at (Optional[datetime])。
     • API 端點：
       • GET /projects/{project_id}/milestones：獲取專案的里程碑。
       • POST /projects/{project_id}/milestones：添加新的里程碑。
       • PATCH /projects/{project_id}/milestones/{milestone_id}：更新里程碑資訊。
3. 利害關係人溝通儀表板/報告 (Stakeholder Communication Dashboard/Reporting)
   • 應用建議：提供一個專門的視圖或報告，用於向利害關係人匯總關鍵的專案發布指標和狀態。這可以包括專案進度、發布檢查清單狀態以及任何已識別的發布風險。系統應能自動或半自動生成類似 project-shipper 模板中的「發布簡報」。
   • 設計實現：
     • UI/UX：在專案內部設置一個「報告」或「儀表板」區塊，提供「發布準備度報告」或「利害關係人簡報」視圖。這個視圖會從現有的專案數據中提取信息並進行匯總。
     • 資料模型：無需新增核心資料模型，主要依賴現有的 Project、Task 和上述新增的 ProjectChecklistItem、ProjectMilestone 數據。
     • API 端點：
       • GET /projects/{project_id}/launch_report：獲取專案的發布報告數據，返回結構化的 JSON。
       • 後續可考慮整合報告生成服務，將 JSON 轉換為 PDF 或 Markdown 格式。

---

以 studio-producer (工作室製作人) 的視角
studio-producer 關注的是優化團隊能力、簡化工作流程並確保衝刺的順利進行。對於專案管理，這意味著需要工具來管理專案資源、追蹤團隊工作量以及可視化跨專案的依賴關係。
應用層面建議與設計：

1. 資源分配與工作量可視化 (Resource Allocation & Workload Visualization)
   • 應用建議：提供一個中心化的「資源視圖」，顯示團隊成員在所有活躍專案中的任務分配情況。這將有助於識別過度使用或未充分利用的個人/團隊，從而使製作人能夠平衡工作量並有效分配資源。
   • 設計實現：
     • UI/UX：新增一個頂級的「資源」或「團隊工作量」頁面。這可以是一個日曆視圖，顯示每個成員在不同專案中的任務分配，或者是一個列表，顯示成員及其分配的任務/專案和預計工作量（例如：每週小時數）。
     • 資料模型：主要利用現有的 ProjectMember 模型（來自專案管理）和 Task 模型（來自任務管理，特別是 assigned_to_id 和預計工時/時間）。可能需要在 Task 模型中新增 estimated_hours 欄位。
     • API 端點：
       • GET /resources/workload：獲取所有團隊成員在各專案和任務中的工作量匯總。
       • GET /users/{user_id}/assignments：獲取特定使用者在所有專案中的任務分配。
2. 跨專案依賴關係映射 (Cross-Project Dependency Mapping)
   • 應用建議：提供一個功能，用於可視化不同專案之間的依賴關係。例如，專案 A 需要專案 B
     的某個組件才能啟動。這有助於製作人識別潛在的瓶頸並協調跨專案團隊。
   • 設計實現：
     • UI/UX：新增一個「跨專案依賴」視圖，可能是一個網絡圖或一個簡單的列表，顯示依賴的專案及其類型。
     • 資料模型：建立一個新的 ProjectDependency 模型，包含：
       • id (UUID, 主鍵)
       • source_project_id (UUID, 外鍵關聯 Project 模型，表示依賴發起方)
       • target_project_id (UUID, 外鍵關聯 Project 模型，表示被依賴方)
       • dependency_type (str, 依賴類型，例如 'blocks', 'requires_component', 'delivers_feature')
       • description (Optional[str], 依賴描述)
     • API 端點：
       • POST /project_dependencies/：建立跨專案依賴。
       • GET /project_dependencies/：獲取所有跨專案依賴。
       • GET /projects/{project_id}/dependencies：獲取特定專案的入站和出站依賴。
3. 專案健康與瓶頸檢測 (Project Health & Bottleneck Detection)
   • 應用建議：提供一個「專案健康儀表板」，匯總關鍵的專案指標（例如：逾期任務的百分比、開放阻塞任務的數量、專案的團隊速度）。這將幫助製作人快速識別遇到困難或存在瓶頸的專案。
   • 設計實現：
     • UI/UX：一個儀表板，每個專案顯示一個小部件，展示其健康指標（例如：紅/黃/綠燈、健康分數）。這將匯總來自任務、里程碑和未來時間追蹤的數據。
     • 資料模型：無需新增核心資料模型，主要依賴現有的 Project 和 Task 數據。需要在服務層實現聚合邏輯來計算這些健康指標。
     • API 端點：
       • GET /projects/{project_id}/health_metrics：獲取特定專案的健康指標。
       • GET /dashboard/project_health：獲取所有專案的健康概覽。

AI同事以專案管理使用者的角度，給了一些有建設性的意見在後端架設上，也有提供使用者可能想使用的UIUX功能，這給我一個提醒，或許前端的角度也需要後端這部分的支援，所以我請AI同事以前端的角度給我專案管理這塊地建議。
我給AI的指令：

@agents/engineering/frontend-developer.md 請提供以你的角度，除了原本建議的UIUX功能，專案管理這一塊前端在設計UIUX功能時，還會需要後端提供哪些功能給前端使用，請提供你的意見

AI同事給我的前端功能回饋：

前端開發者對後端功能的需求建議：

1. 儀表板聚合數據與統計 (Dashboard Aggregated Data & Statistics)
   • 需求原因：前端儀表板通常需要快速顯示各種統計數據（例如：「我的待辦專案數」、「今天到期的任務數」、「逾期任務數」等）。如果前端需要獲取所有數據再進行篩選和計數，會非常低效。
   • 後端功能：提供專門的 API 端點，用於返回預先計算好的聚合統計數據。
   • 建議 API：
     • GET /dashboard/summary_counts：返回使用者相關的總結計數。
     • GET /projects/{project_id}/task_summary_counts：返回特定專案的任務統計，例如：
2. 即時更新通知 (Real-time Updates via WebSockets)
   • 需求原因：對於協作工具，如任務評論、狀態變更、專案成員更新等，前端需要即時收到通知，而不是透過頻繁的
     輪詢。
   • 後端功能：提供 WebSocket 端點，用於推送特定事件的即時更新。
   • 建議 API：
     • 建立 WebSocket 連線到 /ws。
     • 後端在相關數據變更時，向前端推送訊息。
3. 使用者介面偏好設定儲存 (User-Specific UI Preferences & Settings)
   • 需求原因：前端通常會允許使用者自定義其介面顯示方式（例如：專案列表的預設排序、儀表板小部件的順序、通知偏好設定等）。這些設定需要持久化儲存。
   • 後端功能：提供 API 端點來儲存和檢索使用者特定的 UI 偏好設定。
   • 建議 API：
     • GET /users/me/preferences：獲取當前使用者的所有偏好設定。
     • PATCH /users/me/preferences：更新當前使用者的部分或全部偏好設定，例如：
4. 進階搜尋與篩選功能 (Advanced Search & Filter Enhancements)
   • 需求原因：前端需要構建複雜的搜尋介面（例如：「查找指派給我的、下週到期、帶有 'bug'
     標籤的任務」）。這要求後端能夠支援多個篩選條件的組合查詢，甚至全文檢索。
   • 後端功能：在現有的 GET 端點上增強過濾能力，支援多個查詢參數組合。如果需要跨多個模型或複雜的全文檢索，則可能需要專門的搜尋端點。
   • 建議 API：
     • GET /tasks?assigned_to=me&due_date_before=2025-08-22&tags=bug,urgent&status=in_progress&priority=high
     • 考慮一個專門的 POST /search 端點，如果查詢條件非常複雜且需要動態構建。
5. 活動日誌/審計追蹤 (Audit Trails/Activity Logs)
   • 需求原因：使用者通常希望看到專案或任務的按時間順序的變更日誌（例如：「John 將狀態從 '待辦' 變更為'進行中'」、「Mary 添加了一個新成員」）。
   • 後端功能：提供 API 端點來檢索特定實體的活動日誌。這將利用後端架構師建議的「審計日誌」功能。
   • 建議 API：
     • GET /projects/{project_id}/activity_log
     • GET /tasks/{task_id}/activity_log (這在任務管理計畫中已包含TaskHistory，但需要明確暴露給前端使用)
6. 批量操作 (Bulk Actions)
   • 需求原因：為了提高效率，使用者可能希望一次性對多個項目執行操作（例如：「將這 5
     個任務標記為完成」、「將這 3 個專案指派給新的經理」）。
   • 後端功能：提供接受 ID 陣列的 API 端點，用於批量更新或刪除。
   • 建議 API：
     • PATCH /tasks/bulk_update
     • DELETE /projects/bulk_delete：
7. 元數據/配置端點 (Metadata/Configuration Endpoints)
   • 需求原因：前端通常需要動態填充下拉選單或根據後端配置顯示選項（例如：可用的專案狀態列表、成員角色、任務優先級）。
   • 後端功能：提供 API 端點來暴露這些可配置的列表。
   • 建議 API：
     • GET /config/project_statuses：返回所有可用的專案狀態列表，例如 ["draft", "active", "on_hold", "completed"]。
     • GET /config/project_member_roles：返回所有可用的專案成員角色列表，例如 ["owner", "manager", "member", "viewer"]。
     • GET /config/task_priorities：返回所有可用的任務優先級列表，例如 ["low", "medium", "high", "urgent"]。