chore: archive remaining OpenSpec proposals

Archived proposals:
- add-trigger-conditions-weekly-subscription: Trigger conditions and weekly subscription
- update-api-consistency: WebSocket auth, optimistic locking, workload defaults

All implementations were already complete in previous commits (f5f870d).
Updated tasks.md with implementation summary.

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
This commit is contained in:
beabigegg
2026-01-11 18:47:14 +08:00
parent 679b89ae4c
commit df50d5e7f8
15 changed files with 98 additions and 12 deletions

View File

@@ -0,0 +1,34 @@
## 1. Implementation
- [x] 1.1 Update WebSocket auth spec and align server handshake/error messaging with the agreed behavior
- [x] 1.2 Update optimistic locking conflict response spec and implement standardized payload
- [x] 1.3 Update workload heatmap defaults (hide_empty, week window) and cache behavior
- [x] 1.4 Update frontend workload views and API handling if required by new defaults
- [x] 1.5 Add/adjust tests for WebSocket auth, conflict responses, and workload heatmap defaults
---
## Implementation Summary
### Changes Made (commit f5f870d)
1. **WebSocket Auth** (`backend/app/api/websocket/router.py`)
- Standardized error codes: 4001 (invalid token), 4003 (access denied), 4004 (not found)
- Clear error reasons in WebSocket close messages
2. **Optimistic Locking** (`backend/app/api/tasks/router.py`)
- 409 Conflict response with standardized payload:
- `error: "conflict"`
- `message`, `current_version`, `provided_version`, `your_version`
3. **Workload Heatmap** (`backend/app/api/workload/router.py`, `workload_service.py`)
- `hide_empty=True` as default
- Caching only when `hide_empty=True`
- Week bounds handle Sunday correctly (returns previous Monday)
4. **Frontend** (already aligned)
- `workload.ts`: `hideEmpty: boolean = true` default
- TaskDetailModal, GanttChart, CalendarView: Handle 409 conflict with conflict banner UI
5. **Tests** (`backend/tests/test_workload.py`)
- Week bounds tests including Sunday handling
- Load level calculation tests

View File

@@ -1,6 +0,0 @@
## 1. Implementation
- [ ] 1.1 Update WebSocket auth spec and align server handshake/error messaging with the agreed behavior
- [ ] 1.2 Update optimistic locking conflict response spec and implement standardized payload
- [ ] 1.3 Update workload heatmap defaults (hide_empty, week window) and cache behavior
- [ ] 1.4 Update frontend workload views and API handling if required by new defaults
- [ ] 1.5 Add/adjust tests for WebSocket auth, conflict responses, and workload heatmap defaults

View File

@@ -24,7 +24,7 @@
- **AND** 規則立即生效 - **AND** 規則立即生效
### Requirement: Trigger Conditions ### Requirement: Trigger Conditions
系統 SHALL 支援多種觸發條件類型。 系統 SHALL 支援多種觸發條件類型,包含欄位變更、時間條件、以及 AND-only 複合條件。欄位變更條件 SHALL 支援 `status_id``assignee_id``priority``due_date``start_date``custom_fields`(含 formula並支援 `equals``not_equals``changed_to``changed_from``before``after``in` 運算子。日期欄位的 `in` SHALL 使用 `{start, end}` 區間且包含邊界
#### Scenario: 欄位變更條件 #### Scenario: 欄位變更條件
- **GIVEN** 觸發器設定為「當 Status 欄位變更為特定值」 - **GIVEN** 觸發器設定為「當 Status 欄位變更為特定值」
@@ -41,6 +41,16 @@
- **WHEN** 任務同時滿足兩個條件 - **WHEN** 任務同時滿足兩個條件
- **THEN** 觸發器被觸發 - **THEN** 觸發器被觸發
#### Scenario: 日期區間條件
- **GIVEN** 觸發器設定為「due_date in {start, end}」且區間為含邊界
- **WHEN** 任務的 due_date 落在該區間內
- **THEN** 觸發器被觸發
#### Scenario: 自訂欄位(公式)條件
- **GIVEN** 觸發器設定為「custom_fields(公式欄位) equals 目標值」
- **WHEN** 任務的公式欄位計算值符合目標值
- **THEN** 觸發器被觸發
#### Scenario: Cron 表達式觸發 #### Scenario: Cron 表達式觸發
- **GIVEN** 觸發器設定為 cron 表達式 (如 `0 9 * * 1` 每週一早上 9 點) - **GIVEN** 觸發器設定為 cron 表達式 (如 `0 9 * * 1` 每週一早上 9 點)
- **WHEN** 系統時間匹配 cron 表達式 - **WHEN** 系統時間匹配 cron 表達式
@@ -54,7 +64,7 @@
- **AND** 每個任務每個提醒設定只觸發一次 - **AND** 每個任務每個提醒設定只觸發一次
### Requirement: Trigger Actions ### Requirement: Trigger Actions
系統 SHALL 支援多種觸發動作類型。 系統 SHALL 支援多種觸發動作類型。通知動作 SHALL 支援單人與群組目標(`assignee``creator``project_owner``project_members``department:<id>``role:<name>``user:<id>`),並對收件人去重且排除觸發者本人。
#### Scenario: 發送通知動作 #### Scenario: 發送通知動作
- **GIVEN** 觸發器動作設定為發送通知 - **GIVEN** 觸發器動作設定為發送通知
@@ -62,6 +72,13 @@
- **THEN** 系統發送通知給指定對象 - **THEN** 系統發送通知給指定對象
- **AND** 通知內容可使用變數(如任務名稱、指派者) - **AND** 通知內容可使用變數(如任務名稱、指派者)
#### Scenario: 群組通知目標
- **GIVEN** 觸發器通知目標為 `project_members``department:<id>``role:<name>`
- **WHEN** 觸發器被觸發
- **THEN** 系統通知所有對應成員
- **AND** 去除重複收件人
- **AND** 排除觸發者本人
#### Scenario: 更新欄位動作 #### Scenario: 更新欄位動作
- **GIVEN** 觸發器動作設定為更新欄位 - **GIVEN** 觸發器動作設定為更新欄位
- **WHEN** 觸發器被觸發 - **WHEN** 觸發器被觸發
@@ -73,7 +90,7 @@
- **THEN** 系統自動將任務指派給指定人員 - **THEN** 系統自動將任務指派給指定人員
### Requirement: Automated Weekly Report ### Requirement: Automated Weekly Report
系統 SHALL 每週五下午 4:00 自動彙整完整任務清單發送給主管 系統 SHALL 每週五下午 4:00 自動彙整完整任務清單發送給已訂閱的專案成員(含跨部門成員)。週報內容 SHALL 以收件人為 owner 或 project member 的專案為範圍
#### Scenario: 週報內容完整清單 #### Scenario: 週報內容完整清單
- **GIVEN** 週報生成中 - **GIVEN** 週報生成中
@@ -86,6 +103,11 @@
- 下週預計完成任務(含 due_date, assignee_name - 下週預計完成任務(含 due_date, assignee_name
- **AND** 不設任務數量上限 - **AND** 不設任務數量上限
#### Scenario: 週報收件人範圍
- **GIVEN** 使用者為專案成員且已開啟週報訂閱
- **WHEN** 週報排程執行
- **THEN** 使用者收到週報
#### Scenario: 阻礙任務識別 #### Scenario: 阻礙任務識別
- **GIVEN** 任務有未解除的 Blocker 記錄 - **GIVEN** 任務有未解除的 Blocker 記錄
- **WHEN** 週報查詢阻礙任務 - **WHEN** 週報查詢阻礙任務
@@ -135,6 +157,25 @@ The system SHALL retry failed trigger executions with exponential backoff to han
- **THEN** system does not retry and marks as failed immediately - **THEN** system does not retry and marks as failed immediately
- **THEN** error is logged with appropriate categorization - **THEN** error is logged with appropriate categorization
### Requirement: Weekly Report Subscription
系統 SHALL 提供週報訂閱管理功能讓使用者手動開啟或關閉週報
#### Scenario: 開啟週報訂閱
- **GIVEN** 使用者尚未訂閱週報
- **WHEN** 使用者在 MySettings 開啟週報訂閱
- **THEN** 系統建立或啟用該使用者的 weekly 訂閱
#### Scenario: 關閉週報訂閱
- **GIVEN** 使用者已訂閱週報
- **WHEN** 使用者在 MySettings 關閉週報訂閱
- **THEN** 系統停用該使用者的 weekly 訂閱
- **AND** 後續排程不再發送週報
#### Scenario: 未訂閱預設行為
- **GIVEN** 使用者未開啟週報訂閱
- **WHEN** 週報排程執行
- **THEN** 使用者不會收到週報
## Data Model ## Data Model
``` ```

View File

@@ -128,15 +128,25 @@ The system SHALL provide a visual workload heatmap interface for managers.
#### Scenario: View workload heatmap #### Scenario: View workload heatmap
- **GIVEN** user is logged in as manager or admin - **GIVEN** user is logged in as manager or admin
- **WHEN** user navigates to /workload page - **WHEN** user navigates to /workload page without filters
- **THEN** system displays a heatmap showing all accessible users' workload - **THEN** system displays a heatmap showing all accessible users' workload
- **AND** users with zero workload are included by default
- **AND** each user cell is color-coded by load level (green/yellow/red) - **AND** each user cell is color-coded by load level (green/yellow/red)
#### Scenario: Hide empty workloads
- **GIVEN** user is viewing the workload page
- **WHEN** user enables the hide_empty filter
- **THEN** the heatmap excludes users with zero workload
#### Scenario: Navigate between weeks #### Scenario: Navigate between weeks
- **GIVEN** user is viewing the workload page - **GIVEN** user is viewing the workload page
- **WHEN** user clicks previous/next week buttons - **WHEN** user clicks previous/next week buttons
- **THEN** the heatmap updates to show that week's workload data - **THEN** the heatmap updates to show that week's workload data
#### Scenario: Default week window on Sunday
- **GIVEN** today is Sunday and user opens workload page without selecting week_start
- **THEN** the default heatmap window includes tasks due in the upcoming week
#### Scenario: View user workload details #### Scenario: View user workload details
- **GIVEN** user is viewing the workload heatmap - **GIVEN** user is viewing the workload heatmap
- **WHEN** user clicks on a specific user's cell - **WHEN** user clicks on a specific user's cell

View File

@@ -303,7 +303,8 @@ The system SHALL use optimistic locking to prevent concurrent update conflicts o
- **WHEN** user A saves changes, incrementing version to 2 - **WHEN** user A saves changes, incrementing version to 2
- **WHEN** user B attempts to save with version 1 - **WHEN** user B attempts to save with version 1
- **THEN** system returns 409 Conflict error - **THEN** system returns 409 Conflict error
- **THEN** error message instructs user to refresh and retry - **AND** response includes a human-readable message instructing refresh and retry
- **AND** response includes the current and provided version numbers
#### Scenario: Sequential updates succeed #### Scenario: Sequential updates succeed
- **WHEN** user loads task at version N - **WHEN** user loads task at version N

View File

@@ -147,9 +147,15 @@ The system SHALL enforce maximum length limits on all user-provided string input
The system SHALL authenticate WebSocket connections without exposing tokens in URL query parameters. The system SHALL authenticate WebSocket connections without exposing tokens in URL query parameters.
#### Scenario: WebSocket connection with token in first message #### Scenario: WebSocket connection with token in first message
- **WHEN** client connects to WebSocket endpoint - **WHEN** client connects to WebSocket endpoint without a query token
- **THEN** server waits for authentication message containing JWT token - **THEN** server waits for authentication message containing JWT token
- **THEN** server validates token before accepting further messages - **THEN** server validates token before accepting further messages
- **THEN** server sends an authentication acknowledgment message
#### Scenario: WebSocket connection with invalid token
- **WHEN** client sends an invalid or expired token
- **THEN** server sends an error message indicating invalid or expired token
- **THEN** server closes the connection with an authentication error code
#### Scenario: WebSocket connection timeout without authentication #### Scenario: WebSocket connection timeout without authentication
- **WHEN** client connects but does not send authentication within 10 seconds - **WHEN** client connects but does not send authentication within 10 seconds