Linear Expert 工具可行性分析報告

文件目的：從 Linear 功能的實際限制和最佳實踐角度，對 V1/V2/V3 三個版本的設計進行工具層面的可行性評估。識別哪些機制在工具層面有問題，哪些可以更好地利用 Linear 功能，並為 Integration Expert 提供具體的修正建議。

評分說明：各模組給出可行性評分（1-5 分），5 分代表完全可在 Linear 原生實現，1 分代表幾乎不可行或嚴重依賴外部工具。

模組一：Workflow States 設計評估

1.1 12 個 States 的 UX 問題分析

統整版裁決了 12 個 Workflow States（含 Waiting for Others），這個數量在 Linear 的實際操作中存在明顯的認知負擔問題。

Linear 的 State 選擇器行為：

Linear 的 State 選擇器是一個下拉清單，在任何 Issue 上按 S 鍵開啟。清單中的所有 State 都會同時顯示，不會依照當前 State 篩選出「合理的下一步」。這意味著：

• RD 要把 Issue 從 In Development 改成 Ready for Test 時，他需要在 12 個選項中找到正確的那一個
• QA 要把 Issue 從 Testing 改成 Ready for Fix 時，同樣面對 12 個選項
• 特別危險的情況：QA Passed、Waiting for Others、Ready for Release Build 這三個狀態語意上很接近，容易選錯

具體的 UX 問題清單：

問題 1：語意相近的狀態叢集 以下三個狀態語意容易混淆：

• QA Passed：測試通過，等待翻譯或版本整合
• Waiting for Others：測試通過，等待其他 Issue 完成
• Ready for Release Build：所有條件滿足，授權包正式版

一個剛加入團隊的 RD 或 QA 很難在 0.5 秒內判斷這三個有什麼差異，尤其是在快速操作時。

問題 2：「Ready for」前綴的過度使用 統整版中有四個狀態都以「Ready for」開頭：

• Ready for Test
• Ready for Fix
• Ready for Release Build
• Ready for Release

在 State 選擇器的下拉清單中，這四個會排列在一起，視覺上非常相似，在快速操作時容易選錯。特別是 Ready for Release Build 和 Ready for Release 的差異對非核心成員非常不直觀。

問題 3：Waiting for Translation 的必要性 Waiting for Translation 是一個只對有翻譯需求的功能才有意義的狀態。對於沒有翻譯需求的功能（例如純技術改善），這個狀態永遠不會用到，但它依然出現在所有 Issue 的 State 選擇器中，增加了噪音。

問題 4：狀態類型設定 Linear 的 State 分為幾種類型：Backlog、Unstarted、Started、Completed、Canceled。統整版中幾乎所有的 Started 狀態（共 9 個）都歸類為同一類型，這讓 Linear 的 Filter 和 Reporting 功能無法有效區分這些狀態之間的差異。

1.2 可行性評分與建議

可行性評分：3/5

12 個 State 在 Linear 技術上完全可以建立，但 UX 體驗會造成操作錯誤率上升，需要強制培訓和規範才能維持。

給 Integration Expert 的 States 精簡建議：

建議考慮將 Waiting for Translation 改為 Label 而非獨立 State，讓整體 State 數量降至 11 個（含 Waiting for Others）。理由：翻譯等待狀態可以用 QA Passed + Label [Needs Translation] 的組合表達，不需要單獨佔用一個 State 槽位。這個做法在業界更常見（用 Label 表達「附加屬性」，用 State 表達「工作階段」）。

模組二：Milestone 設計評估

2.1 6 個 Milestone 在 Linear 中的實現能力

V3 / 統整版的 6 個 Milestone 設計如下：

1. Sprint Planning 完成
2. Feature Freeze
3. First ALPHA 發出
4. All QA Passed
5. Release Candidate
6. Released

Linear Milestone 功能的實際行為：

Linear 的 Milestone 功能本質上是「Project 內的進度標記點」，具有以下特性：

• Milestone 本身只是一個名稱 + 日期 + 描述的組合，不會自動追蹤 Issue 數量
• Milestone 的「完成」是手動標記的，沒有自動從 Issue 狀態推算 Milestone 進度的功能（這是關鍵限制）
• 每個 Project 可以有多個 Milestone，沒有數量限制

6 個 Milestone 的逐一可行性分析：

2.2 Feature Freeze 的 48 小時提醒機制分析

設計要求：「距 Feature Freeze Milestone 日期 ≤ 2 天時，Automation 觸發 Slack 警告」

Linear Automation 的實際觸發器（Triggers）清單：

Linear Automation 目前支援的 Trigger 類型包括：

• Issue 狀態改變
• Issue 被建立
• Issue 被分配
• Issue Label 新增/移除
• Comment 被新增
• Issue 被加入/移除 Project
• Issue Due Date 達到

關鍵問題：Linear Automation 沒有「距離 Milestone 日期 N 天」這種基於 Milestone 日期的 Trigger。

這意味著「Feature Freeze 前 48 小時自動提醒」這個功能，在 Linear 原生 Automation 中無法實現。

替代方案：

1. 方案 A（手動）：RM 在 Milestone 建立時，同時在 Linear 的 Issue 上設定一個 Due Date 提醒，指向 Freeze 前 2 天。當那個 Issue 的 Due Date 到期，Automation 可以觸發通知。這個方案需要 RM 每次建立版本時額外操作一個步驟。
2. 方案 B（n8n）：透過 n8n 定時任務（Cron Job），每天檢查 Linear API 的 Project Milestone 日期，判斷是否距離 2 天內，再觸發 Slack 通知。這個方案需要 n8n 配合。
3. 方案 C（放棄時間觸發，改用手動）：移除「48 小時自動提醒」這個設計，改為 RM 每週一固定掃描 Milestone 日期，手動評估是否需要發警告。

2.3 First ALPHA 發出 Milestone 的自動化問題

設計要求：「Android Ready for Test Automation 自動標記 First ALPHA 發出 Milestone」

問題：Linear Automation 的 Action 清單中，沒有「標記 Milestone 為完成」這個 Action。Linear Automation 可以做到：

• 改變 Issue 狀態
• 新增/移除 Label
• 發送 Slack 通知
• 新增 Comment

但「完成一個 Milestone」不在 Automation 的 Action 中。Milestone 的完成必須由人工在 Linear UI 中手動操作。

實際可行的替代設計：當第一個 Android Issue 狀態改為 Ready for Test 時，Automation 可以自動發一條 Slack 通知（「Android 第一個 ALPHA 已發出，請 RM 手動標記 First ALPHA Milestone」），再由 RM 手動完成 Milestone 標記。這將一個「全自動」降級為「半自動 + 一步手動確認」。

2.4 可行性評分

可行性評分：3/5

6 個 Milestone 本身在 Linear 可以完整建立。但 Feature Freeze 的 48 小時自動提醒和 First ALPHA 的自動 Milestone 完成，都無法在 Linear 原生 Automation 中實現，需要外部工具（n8n）或降級為半自動操作。

模組三：Automation 12 條的工具層面分析

3.1 逐條可行性分類

以下對統整版的 12 條 Automation 進行工具層面的分類，分為三個類別：

類別 A：Linear 原生完全可以實現

類別 B：需要 GitHub App 配合

類別 C：需要 n8n 或第三方工具

類別 D：需要降級設計的 Automation

3.2 Automation 5 的關鍵限制說明

Automation 5「Testing Notes 缺失提醒」的設計意圖是：

「Issue 狀態從 Planning 改為 In Development，且 Description 中『測試注意事項』區塊為空時，加上 Label + 發 Comment」

問題所在：Linear Automation 的 Trigger 中，沒有「讀取 Issue Description 內容」的能力。Automation 只能對以下條件做判斷：

• Issue 的 State（狀態）
• Issue 的 Label（標籤）
• Issue 的 Assignee（指派人）
• Issue 的 Priority（優先級）
• Issue 的 Due Date（截止日期）
• Issue 所在的 Team / Project / Cycle

它無法讀取 Description 的文字內容，更無法判斷特定區塊是否為空。

實際可行的降級設計：

• Trigger：Issue 狀態改為 In Development（移除「且 Description 為空」的條件）
• Action：無條件發 Comment 提醒 PO/RD 確認 Testing Notes 是否已填寫
• 副作用：即使 Testing Notes 已填寫的 Issue 也會收到提醒，但這個誤報是可接受的（寧可多提醒，不要漏掉）
• Label [Testing-Notes-Missing] 改為手動加，不能自動判斷

3.3 P0-P3 分批的合理性評估

統整版的 P0-P3 分批基本合理，但有一個結構性問題：

P0 項目中，branchPattern 設定的依賴關係

P0 包含：

1. branchPattern 設定（GitHub Integration）
2. 邀請全員加入
3. 第一個 Project + Feature Freeze Milestone
4. Issue Templates V3

其中，Automation 1、2、3（Ready for Test 通知）依賴 branchPattern 設定完成。如果 branchPattern 未設定，PR 合併到 staging 時 Issue 狀態不會自動改變，Automation 就永遠不會觸發。這個依賴關係在文件中已有說明，但執行上必須嚴格按順序。

建議：Integration Expert 在建置指南中，將 branchPattern 設定明確標為「所有 Automation 的前提條件」，放在 P0 清單的最頂部，並加入驗收測試步驟（用一個測試 PR 驗證 staging/* → Ready for Test 的觸發是否正常）。

3.4 可行性評分

可行性評分：4/5

12 條 Automation 中有 10 條可以在 Linear 原生完整實現，1 條需要降級設計（Automation 5），1 條需要 n8n 配合（Automation 4 的 DORA 部分）。branchPattern 是所有 Automation 的基礎前提，必須最先完成。分批設計（P0-P3）邏輯合理。

模組四：Testing Notes 雙向強制機制評估

4.1 「QA 必須回覆確認 Comment」的工具支援現實

統整版設計了一個「雙向強制」機制：

• PO 填寫 Testing Notes → 回覆 Automation Comment「已填寫」
• QA 讀取 Testing Notes → 回覆 Automation Comment「已確認」

Linear 在這個設計中的能力邊界：

Linear 可以做到：

• Automation 在 Issue 進入特定狀態時，自動發一條 Comment（這是 Automation 6 的設計）
• 任何人都可以在這個 Comment 下方回覆（Linear 支援 Comment 的子回覆）

Linear 無法做到：

• 檢測 Comment 是否被回覆（Automation 沒有「Comment 被回覆」的 Trigger 變體，只有「Comment 被新增」）
• 強制要求 QA 必須回覆才能繼續操作（Linear 沒有 Workflow 審核機制，無法設定「必填步驟」）
• 自動驗證回覆內容是否符合格式（無法判斷回覆是「已確認 Testing Notes」還是「好的」）

本質評估：

「雙向強制」這個名稱在工具層面是誤導性的。Linear 中無法實現真正的「強制」——沒有任何機制能阻止 QA 在沒有回覆 Comment 的情況下，直接把 Issue 狀態改為 Testing，甚至 QA Passed。

這個設計本質上依賴的是人工紀律（Team Discipline），而不是工具強制（Tool Enforcement）。

4.2 類比分析：業界如何處理這個問題

業界通常有三種方式強制執行 Checklist 類的步驟：

1. PR Review 必須批准才能合併：GitHub 的 Required Reviewers 是真正的工具強制。在 Linear 中沒有等效功能。

2. Status Change 需要條件：Jira 的 Workflow Transition 可以設定「只有當某個自訂欄位被填寫才能移動到下一個 Status」。Linear 不支援這種條件式 Status 轉換。

3. 人工審計 + 後果：定期審計哪些 Issue 沒有按流程走，並讓流程違規有後果（例如 RM 退回 Issue，要求補填）。這是 Linear 環境下唯一實際可行的強制機制。

4.3 可行性評分與建議

可行性評分：2/5（工具強制層面）/ 4/5（人工紀律 + Automation 提醒層面）

Automation 6 的「提醒 Comment」可以完整實現，但「強制確認」只能依賴人工紀律。給 Integration Expert 的建議：

在設計文件中，明確將「雙向強制」改稱為「雙向確認機制」，避免讓執行者誤以為工具本身會阻擋不合規的操作。同時建議 RM 在 Weekly Review 時，用 Linear Filter（Issue 狀態為 Testing 或 QA Passed，但缺少特定 Comment）手動抽查合規率。

模組五：掉車 SOP 的工具支援評估

5.1 Label [At Risk] + Project 異動的操作順暢度

掉車 SOP 的 5 個步驟在 Linear 的操作路徑分析：

Step 1：加 [At Risk] Label

操作路徑：在 Issue 上按 L → 選擇 [At Risk] Label

這個操作完全流暢。Linear 的 Label 選擇器支援快速搜尋，輸入「at」即可找到 [At Risk]。

Step 2：Slack DM 通知 RD

這一步在設計中是手動操作（RM 直接發 DM），不依賴 Linear Automation。操作路徑不在 Linear 內，無問題。

Step 3：確認掉車後的 Issue 異動

這一步包含以下 Linear 操作：

• 移除 [At Risk] Label → 加 [Dropped from vX.X.X] Label
• 把 Issue 從當前版本 Project 移到下一個版本 Project（或 Backlog）
• 把 Issue 狀態改為 Planning

Issue 在 Project 間移動的操作路徑：

Issue 詳情頁 → 右側欄 Project 欄位 → 點擊 → 選擇新 Project

這個操作在 Linear 中可以完成，但有一個注意事項：當 Issue 被移到新 Project 時，它在舊 Project 中的 Milestone 歸屬會消失。如果這個 Issue 已被標記在某個 Milestone 下（例如「Sprint Planning 完成」），移動後這個 Milestone 連結會斷開。這不是問題，但執行者需要知道這個行為。

Step 4：在 forest-release 發送公告

這一步是手動發 Slack 訊息，可以考慮用 Automation 輔助（當 Label [Dropped from vX.X.X] 被加上時，自動發 Slack 通知），但設計文件目前是手動操作，這個選擇是合理的（掉車通知需要人工確認措辭）。

Step 5：Retrospective 記錄在 Cycle Description

Linear 的 Cycle 有一個 Description 欄位，可以放 Markdown 格式的文字。這個操作可行。

5.2 是否有更好的 Linear 功能組合

改善建議 1：使用 Linear 的 Issue Relation 功能

掉車的 Issue 移到下一個版本後，可以在新版本的 Issue 和舊版本的「版本說明 Issue」之間建立 Relation（Relates To），讓下一版本的 RM 能快速查到這個功能原本是哪個版本掉下來的。

改善建議 2：Dropped Label 的命名簡化

[Dropped from v5.8.0] 這種包含版本號的 Label 命名方式，每個版本都需要建立一個新 Label，長期下來會累積大量只用一次的 Label。建議改為：

• Label [Dropped]（通用）
• 在 Issue Comment 中記錄掉車版本（不放在 Label 名稱裡）
• 這樣只需要維護一個 Label，且 Comment 可以搜尋

改善建議 3：Backlog 的使用

當下一個版本 Project 尚未建立時，文件建議暫移至 Backlog。Linear 的 Backlog 在 Team 層級，不在 Project 層級。這是可行的，但要確保 Backlog 有定期清理機制，否則它會變成「失聯 Issue 的墳場」。

5.3 可行性評分

可行性評分：4/5

掉車 SOP 的所有步驟在 Linear 中都可以操作，整體流程順暢。主要建議是簡化 Dropped Label 的命名方式，避免 Label 數量失控。

模組六：Re-test Label 追蹤系統評估

6.1 Re-test-1/2/3 在 Linear Label 系統中的可行性

設計方案：

• Label Re-test-1：第一次回測
• Label Re-test-2：第二次回測
• Label Re-test-3：第三次回測（觸發 Automation 12 通知）

技術可行性：三個 Label 在 Linear 中完全可以建立，Automation 12（Label 新增 Re-test-3 時觸發 Slack 通知）也是標準的 Automation 設計，完全可以實現。

6.2 Label 管理的潛在混亂問題

問題 1：Label 的累積行為

Re-test Label 的設計沒有說明舊 Label 是否要移除。如果每次回測只加新 Label 而不移除舊的，一個回測 3 次的 Issue 最終會同時有 Re-test-1 + Re-test-2 + Re-test-3 三個 Label。這在視覺上雖然清楚（可以看到完整歷史），但三個紅色標籤同時出現在 Issue 上，視覺噪音較大。

建議：明確規範「加 Re-test-N 時，同時移除 Re-test-(N-1)」，保持 Issue 上只有一個當前的 Re-test Label。

問題 2：Automation 12 的重複觸發問題

設計中提到：「Re-test-3 以上：移除 Re-test-3，加上 Re-test-3（不需要建 Re-test-4、5...）」

這個設計的問題是：如果 Issue 回測到第 4 次，RM 需要手動移除 Re-test-3，再重新加上 Re-test-3，才能讓 Automation 12 再次觸發。Linear 的 Label 新增 Trigger 只在 Label「從無到有」時觸發，如果 Label 一直在，移除再加回來確實能重新觸發，但這是一個「依賴邊緣行為」的設計，不夠直觀。

建議：Automation 12 的設計改為 Trigger 在「Issue 狀態改為 Ready for Fix，且 Label 包含 Re-test-2」。這樣第三次進入 Ready for Fix（此時已有 Re-test-2），就自動觸發通知，不需要手動操作 Label 的移除再加回。

問題 3：整體 Label 數量

統整版的 Label 總數：31（原有）+ 3（測試金字塔）+ 3（V3 新增評估）+ 3（Re-test）+ 3（掉車 SOP）= 大約 43 個 Label。

43 個 Label 在 Linear 的 Label 選擇器中，需要明確的命名規範才能快速找到目標 Label。建議所有 Label 按照前綴分組：

• [Platform]：iOS / Android / Server / Web / CN
• [Status]：At Risk / Dropped / Testing-Notes-Missing
• [QA]：E2E / Integration / Re-test-1/2/3
• [Translation]：Needs Translation / Translation Confirmed

這樣在 Label 選擇器中輸入前綴即可快速過濾。

6.3 可行性評分

可行性評分：4/5

Re-test Label 系統技術上完全可行，但需要補充「舊 Label 移除」的操作規範，以及修正 Automation 12 的觸發邏輯，避免依賴「移除再加回」的邊緣行為。Label 數量管理建議採用前綴分組命名。

模組七：iOS TestFlight Webhook 可行性評估

7.1 技術可行性分析

統整版在 M3 評估項目中提到：「TestFlight 上傳成功後，透過 App Store Connect API 觸發 Webhook → n8n 接收 → 自動通知 Linear Issue 狀態更新」

技術現實：

App Store Connect API 的實際能力： Apple 的 App Store Connect API 是一個 REST API，可以查詢 TestFlight builds 的狀態，但它是**拉取式（Pull）的，不是推送式（Push）**的。Apple 沒有提供原生的 Webhook 功能——也就是說，無法在 TestFlight build 上傳成功後「主動推送」事件到外部系統。

現有的技術方案：

要實現「TestFlight 上傳成功 → 自動通知」，業界通常有兩種方案：

方案 A：CI/CD Pipeline 觸發（推薦） iOS 的 TestFlight 上傳通常由 CI/CD 工具（如 fastlane、Xcode Cloud、GitHub Actions）自動化。在上傳成功後，CI/CD Pipeline 可以發送一個 HTTP 請求到 n8n 的 Webhook URL。這不是「Apple 推送 Webhook」，而是「CI/CD Pipeline 完成後自己發通知」。

這個方案的前提：

• iOS 的 TestFlight 上傳流程必須有 CI/CD 工具管理（手動上傳的話無法自動化）
• 需要確認 iOS RD（Richard / Eric）目前是否使用 fastlane 或其他 CI/CD 工具管理 TestFlight 上傳

方案 B：定時輪詢 App Store Connect API n8n 定時（例如每 5 分鐘）呼叫 App Store Connect API，查詢最新的 TestFlight build 狀態。如果發現有新的 build 進入「Testing」狀態，觸發 Slack 通知。

這個方案的缺點：有 5 分鐘的延遲，且需要 API Key 管理（App Store Connect API JWT 認證）。

7.2 實際建議

在 M3 評估這個功能時，第一件事是確認 iOS RD 的 TestFlight 上傳流程：

• 如果已有 fastlane 或 GitHub Actions：方案 A 可以在 1-2 天內完成
• 如果是手動上傳（Xcode 手動打包上傳）：方案 A 無法實現，方案 B 是替代選項
• 如果使用 Xcode Cloud：Xcode Cloud 有 Webhook 功能，可以直接推送

7.3 可行性評分

可行性評分：3/5（技術可行，但依賴 CI/CD 基礎設施的完整程度）

TestFlight Webhook 不是 Apple 原生功能，需要透過 CI/CD Pipeline 或 API 輪詢實現。M3 評估時，首先確認 iOS 的自動化打包現況。

模組八：整體架構評估

8.1 三版設計的演進邏輯評分

8.2 最關鍵的工具層面問題彙總

以下是三版設計中，在 Linear 工具層面最需要修正的 5 個問題：

問題 1（嚴重）：Automation 無法偵測 Description 內容

Automation 5（Testing Notes 缺失提醒）的核心邏輯「若 Description 為空則觸發」在 Linear 中不可能實現。這個 Automation 必須降級為「無條件提醒」，移除智慧判斷的部分。

問題 2（嚴重）：Feature Freeze 48 小時提醒無法用 Linear 原生 Automation 實現

Milestone 日期觸發的 Automation 不存在於 Linear。必須改用 n8n 定時任務或降級為手動提醒。

問題 3（中等）：Milestone 完成無法自動化

First ALPHA 發出 Milestone 設計為「Automation 自動標記」，但 Linear Automation 無法觸發 Milestone 完成。需要改為 Automation 發 Slack 提醒 + RM 手動點完成。

問題 4（中等）：Testing Notes 雙向強制依賴人工紀律

「QA 必須回覆確認 Comment」在 Linear 中沒有工具強制機制，必須明確定位為「人工紀律 + 定期審計」，而非「工具強制」。

問題 5（輕微）：Re-test Automation 的觸發邏輯可以更健壯

依賴「移除 Label 再加回」的方式觸發 Re-test Automation 是脆弱設計，建議改為基於 Ready for Fix 狀態 + Re-test-2 Label 的觸發邏輯。

給 Integration Expert 的建議

建議一：Automation 降級清單

在統整版的建置指南中，明確列出以下 Automation 的降級設計，讓執行者知道「設計意圖」和「實際實現方式」之間的差異：

建議二：States 精簡方向

建議在 Integration Expert 的統整版中評估：將 Waiting for Translation 從 State 移除，改用 QA Passed + Label [Needs Translation] 的組合，讓整體 State 從 12 個降至 11 個，降低選擇器的認知負擔。

建議三：branchPattern 的驗收測試必須放在 P0

branchPattern 是所有 GitHub Automation 的基礎。在建置指南中，branchPattern 設定後必須立即執行驗收測試（建立測試 PR → 合併到 staging/* → 確認 Issue 狀態自動改變），確保整個 Automation 鏈條正常運作，然後再進行後續設定。

建議四：TestFlight Webhook 的評估前置工作

M3 開始評估 TestFlight Webhook 之前，先確認 iOS RD 的打包流程是否有 CI/CD 工具（fastlane / GitHub Actions / Xcode Cloud），這決定了實現方案的難度。如果是手動打包，TestFlight Webhook 的自動化成本遠高於效益，應延後或放棄。

建議五：Label 命名前綴規範

在環境建置的第一步，就建立 Label 命名前綴規範（[Platform]、[Status]、[QA]、[Translation] 等），讓未來 43 個 Label 的管理不會失控。Linear 的 Label 選擇器支援文字搜尋，前綴規範讓使用者輸入前綴即可快速定位目標 Label。

建議六：Testing Notes 的現實期望管理

在 Onboarding 文件和 RM 的執行指南中，明確說明：

• Testing Notes 的「雙向確認」是依賴人工紀律的軟性機制，不是工具強制
• RM 每週 Review 時，抽查 5 個 Issue 是否有按流程走，這是唯一的合規追蹤方式
• 第一個月的目標是讓大家習慣這個流程，不要以「100% 合規」為第一個月的 KPI

附錄：Linear 功能限制完整清單（本次分析識別）

本文件由 Linear Expert（Sub-Agent 2）產出，交接給 Integration Expert（Sub-Agent 3）作為統整版 V2 的修正依據。

linear expert-analysis 工具可行性 automation milestone states