Linear 功能對應分析（統整版V2）

文件定位：本文件是 Linear 工具設定的設計規格書。所有 V2 設計決策中，凡涉及 Linear 工具操作的，都在此文件中有對應的詳細說明。與統整初稿 V1 的關鍵差異：每個設計都明確標注「技術可行性」——哪些靠 Linear 原生、哪些需要外部工具、哪些靠人工紀律。

核心設計裁決摘要（V2 版）：

• Workflow States：11 個（V2：Waiting for Translation 改為 Label 組合）
• States 命名：7 個狀態改名（去除「Ready for」前綴混淆，命名更一致）
• Automation：12 條（含技術可行性標注和降級說明）
• Hotfix SOP：完整設計（V2 新增，三版共同盲點）
• QA 批次視窗：獨立設計章節（V2 新增）
• Testing Notes：三方確認機制（PO + RD + QA），PR Template 補充
• Feature Freeze 提醒：外部工具補充（非 Linear 原生）

一、核心概念映射總表（V2 版）

二、Workflow States：11 個狀態的設計決策（V2 版）

2.1 V2 完整 11 個 States 清單（含命名優化）

V1 統整初稿有 12 個 States（含 Waiting for Translation）。V2 兩個調整：

1. Waiting for Translation 從 State 改為 Label 組合（State 降為 11 個）
2. 7 個 State 命名優化（去除「Ready for」前綴的混淆問題）

V2 State 數量說明：

11 個有序狀態（Planning 到 Monitoring Complete）+ 1 個取消狀態（Dropped）= 12 個 Linear States 設定。

2.2 命名優化的設計邏輯

問題：V1 的 12 個 States 中，「Ready for」前綴出現 4 次（Ready for Test / Ready for Fix / Ready for Release Build / Ready for Release），在 State 選擇器中視覺相似，容易選錯。

V2 優化方向：動詞後置命名，明確當前狀態而非下一步動作：

命名邏輯比較：
  Ready for Test → Test Requested（功能已「發出」測試請求）
  Ready for Fix  → Fix Required（問題「需要」修復）
  Ready for Release Build → Build Requested（「請求」打版）
  Ready for Release → Release Scheduled（發布已「排程」）

Monitoring Complete（新增）：
  明確區分「已發布但還在 Phased Release 監控」和「全量發布完成」兩個狀態

已保留不改的 States：

• Planning：業界通用命名，改動溝通成本高
• In Development：業界通用
• Testing：業界通用
• QA Passed：業界通用
• Waiting for Others：M2 試行，命名清晰
• Released：業界通用（用於「初次送審通過後的 Monitoring 期間」）

2.3 Waiting for Translation 改為 Label 組合的詳細說明

V1 設計問題：

Waiting for Translation 作為 State 有一個根本問題：它只對「有翻譯需求的 Issue」有意義，大多數 Issue（後端修復、Bug Fix、效能改善）完全不需要翻譯，但這個 State 出現在所有 Issue 的狀態選擇器中，增加操作噪音。

V2 解決方案：Label Gate：

Label 設定：
  [Needs Translation]     — 此 Issue 有多國翻譯需求
  [Translation Confirmed] — 翻譯已確認完成（由 RM 手動加，代理 MKT 確認）

翻譯 Gate 觸發邏輯（V2 版 Automation 8/9）：

  有翻譯需求的路徑：
    Issue 進入 QA Passed
    + 已有 Label [Needs Translation]
    → Automation 8 觸發：
      1. Slack 通知 MKT 負責人
      2. RM 在等待期間 Issue 狀態不變（仍為 QA Passed）
    MKT 確認後 RM 手動加 [Translation Confirmed] Label
    → Automation 9 觸發：
      自動改狀態為 Build Requested

  無翻譯需求的路徑：
    Issue 進入 QA Passed
    + 沒有 [Needs Translation] Label（或有 [Translation Confirmed]）
    → Automation 9 觸發：自動改狀態為 Build Requested

RM 視圖改善：

在 Linear Project 視圖，RM 可以按 Label 篩選：

• [Needs Translation] 且無 [Translation Confirmed] → 等待翻譯確認的 Issue 清單
• 比以前的 Waiting for Translation State 更靈活，且不污染整體 State 選擇器

重要說明：

• 翻譯不是真正卡住流程的節點，而是「確認翻譯內容是否正確」的確認步驟
• 無翻譯需求的 Issue（未加 [Needs Translation] Label）直接走 Build Requested 路徑，無需任何額外操作
• 有翻譯需求的 Issue 加上 [Needs Translation] Label 後，RM 等待 MKT 確認翻譯正確，再手動加 [Translation Confirmed] 進入下一步

三、Milestone：6 個版本里程碑設計（V2 版）

重要技術說明：First ALPHA Milestone 的自動完成在 V1 設計中標注為「Android Ready for Test Automation 自動標記」，但這是技術上不可行的——Linear Automation 的 Action 清單中沒有「標記 Milestone 為完成」的選項。V2 修正為「半自動」：Automation 2 在 Android Issue 狀態改為 Test Requested 時，發送 Slack 提醒（「Android 第一個 ALPHA 已發出，請 RM 手動標記 First ALPHA Milestone 完成」），RM 手動完成標記。

四、Testing Notes 三方確認機制（V2 版）

4.1 從「雙向強制」到「三方確認機制」的原因

V1 設計的「雙向強制（PO 填 → QA 回覆確認 Comment）」名稱在兩個層面都是誤稱：

1. 工具層面：Linear 無法強制任何狀態轉移，QA 可以直接跳過 Comment 改狀態
2. 責任鏈層面：PO + QA 的兩向強制遺漏了 RD 這個中間環節（最脆弱的點）

V2 更名為「三方確認機制（PO + RD + QA）」，並明確說明：機制依賴人工紀律，非工具強制。工具（Automation）的作用是提醒，不是阻止。

4.2 四個觸發點（V2 版）

觸發點 1：Planning 階段（PO 填寫）

PO 建立 Issue 後，Issue Template 內建結構化的 Testing Notes 區塊（詳見 01-現有流程深度分析（統整版V2） 節點 1）。

技術可行性：Issue Template 是 Linear 原生功能，完全支援。填寫品質靠人工紀律。

觸發點 2：In Development 階段（RD 補充）

RD 在開發過程中發現技術邊界時，補充到 Issue Description 的 Testing Notes 欄位。

V2 新增：PR Template 確認欄位

這是 V2 最重要的新增機制，讓 RD 補充 Testing Notes 嵌入 PR Review 流程（比依賴習慣更可靠）：

## PR Template 新增欄位（需 Ezou 確認 GitHub 設定）

### Testing Notes 確認
- [ ] 已確認此 PR 的 Linear Issue Testing Notes 狀態：
  - [ ] Y — 已在 Issue Description 補充新的技術邊界或邊界條件
  - [ ] N/A — 此 PR 無新的技術邊界需要補充到 Testing Notes

### PR Impact Scope（QA 回歸測試用）
受影響的模組 / 畫面 / API：
- （請列出，供 QA 判斷是否需要回歸已通過的相關功能）

技術可行性：PR Template 修改需要 Ezou 確認 GitHub Repository 的 Pull Request Template 設定（.github/PULL_REQUEST_TEMPLATE.md）。這是 GitHub 原生功能，不依賴 Linear。

觸發點 3：Test Requested 通知（QA 讀取前）

Automation 6：Test Requested 個別確認 Comment

Trigger：Issue 狀態改為 Test Requested
Action：在 Issue 新增 Comment：
「🧪 此 Issue 已 Test Requested。

 QA 請在開始測試前確認（三方確認機制第三方）：
 ☐ Testing Notes 已閱讀（PO 初填版本 + RD 補充版本）
 ☐ 每條 Testing Notes 都有對應的 Sub-issue 測試項目
 ☐ Android：確認版本號包含 -ALPHA
 ☐ iOS：確認 TestFlight Build 可以取得（或確認 RD Comment 模板）

 ✅ 請在此 Comment 下方回覆「已確認 Testing Notes」後再開始測試。

 提醒：此 Comment 為三方確認機制的 QA 確認點，
       依賴人工紀律，非工具強制。」

技術可行性：Linear 原生，完全可行

觸發點 4：Testing 完成後的 QA 確認 Comment

QA 標準回覆格式（在 Automation 6 Comment 下方回覆）：

「✅ 已確認 Testing Notes
 閱讀時間：[日期]
 Testing Notes 版本：PO [日期] 初始版 + RD [日期] 補充版
 發現的額外測試需求：[有（說明）/ 無]
 對應 Sub-issue 已建立：[是 / 否 / 不適用]
 開始測試時間：[日期]」

說明：
  這個回覆是「三方確認」的 QA 節點記錄
  RM 每週 Review 時，查看是否有 Test Requested Issue 沒有對應的 QA 確認 Comment

4.3 技術可行性總覽

五、Hotfix SOP 完整設計（V2 全新章節）

5.1 Hotfix 的設計哲學

Hotfix 不是正常 Release 流程的「緊急版」，而是一條平行的緊急通道，有以下獨特性質：

1. 嚴格觸發條件：觸發條件為 PO 判定為 P0 Bug，不是所有緊急 Bug 都能走 Hotfix
2. 明確授權人：PO（David 或 Ezou）其一即可，不需要兩人都同意，不需要 RM 自行判斷
3. 精簡流程：跳過 PO Review，只需 RD Lead 代碼審查
4. 獨立追蹤：獨立 Cycle，不合併進正常版本 Cycle，MTTR 單獨計時

5.2 Hotfix 觸發條件

觸發條件：PO 判定為 P0 Bug

授權人：PO（David 或 Ezou，兩人其一即可，不需要兩人都同意，確保緊急時決策速度）

PO 判定 P0 Bug 時的主要參考指標：

最終是否啟動 Hotfix，由 PO（David 或 Ezou）判定。RM 負責協調後續執行流程。

Hotfix 閾值說明：99.0% 是初期閾值（略低於 Duolingo 的 99.5%），考慮到 Forest App 目前的監控成熟度，3 個月後根據實際數據調整。

5.3 Hotfix 在 Linear 中的完整操作步驟

Step 1：Firebase Alert 觸發
  → 自動推送到 Slack <span class="tag">release-monitor</span>
  → MTTR 計時開始（以 Alert 時間為準）
  → RM 確認觸發條件類型

Step 2：PO 判定並授權 Hotfix
  → PO（David 或 Ezou）確認觸發情況，判定是否為 P0 Bug
  → PO 在 Slack 發出 Hotfix 啟動通知（文字記錄，作為授權依據）
  → RM 接收通知，開始協調後續執行流程

Step 3：在 Linear 建立 Hotfix Issue
  → Linear → Team REL → New Issue
  → 標題：「[Hotfix vX.X.X] [問題簡述]」
  → Labels：[Hotfix]（必加）+ [iOS] 或 [Android]（依平台加）
  → 在 Issue Comment 記錄版本號：
「Hotfix 版本：v5.8.1
 觸發時間：[Firebase Alert 時間]（MTTR 起算點）
 觸發條件：[說明]
 PO 授權：[David / Ezou 姓名] 判定 P0 並授權於 [時間]」

Step 4：建立 Hotfix Cycle
  → Linear → Cycles → New Cycle
  → 命名：「Hotfix v5.8.1」
  → 開始時間：今天
  → 結束時間：預計 Hotfix Released 時間
  → 將 Hotfix Issue 加入此 Cycle（不加入正常版本 Cycle）

Step 5：RD 在 Hotfix 分支修復
  → 分支命名規範：hotfix/vX.X.X（從 main 分支切出）
  → GitHub PR 標題：「hotfix: [問題簡述]」
  → PR 描述包含：問題根因分析 + 修復方案 + Impact Scope

Step 6：精簡 Review
  → 不需要 PO Review（功能行為確認跳過）
  → 只需 RD Lead（Ezou）代碼審查
  → 審查重點：修復邏輯是否正確 + 是否引入新問題
  → 目標 Review 時間：< 2 小時

Step 7：QA 快速回歸測試
  → [Hotfix] Issue 自動為緊急等級，不受批次視窗限制
  → RM 通知 QA（Slack DM）：「Hotfix v5.8.1 需要立即測試，請中斷當前工作」
  → 測試範圍：
    · 修復的 Bug 場景（必測，確認修復有效）
    · 相關核心功能快速回歸（選測，參考 PR Impact Scope）
    · 不執行完整 Regression Suite

Step 8：發版
  iOS：
    → Shawn 在 App Store Connect 新增 Version → Upload → 送審
    → 在 App Review Information → Contact Information 備注緊急原因
    → 勾選 Request Expedited Review（需要在送審頁面選擇）
    → 申請說明範例：
「Emergency: Production crash rate exceeded threshold.
 Crash-free rate dropped to X% at [time].
 Fix addresses [簡述問題]. Affects all users.
 Previous version: vX.X.X. Hotfix version: vX.X.1.」

  Android：
    → Shawn 上傳 APK 到 Google Play Console → Production → Create release
    → 在 Release notes 說明 Hotfix 原因
    → 送審，同時申請 Expedited Review（Policy and appeals → Submit emergency request）

Step 9：Hotfix Released
  → Linear Issue 狀態改為 Released
  → 在 Issue Comment 記錄 MTTR：
「✅ Hotfix Released
 MTTR：X 小時 Y 分鐘
 Firebase Alert 時間：[時間]
 Hotfix Released 時間：[時間]
 Crash-free rate 恢復：待確認（Monitoring 期間）」

Step 10：Monitoring（繼續監控，確認修復有效）
  → Shawn 持續確認 Firebase Crashlytics Dashboard
  → 確認 Crash-free rate 恢復到 > 99.0%
  → 恢復後，在 Linear Hotfix Cycle Description 記錄：
「Monitoring Complete：Crash-free rate 已恢復至 [X]%（時間：[時間]）」

Step 11：Retrospective（下次 Sprint Retrospective 討論）
  在 Hotfix Cycle Description 記錄：
「根因分析：[說明問題是什麼、為什麼在測試階段沒有發現]
 學習點：[哪個測試場景需要加強覆蓋]
 後續行動：[補充 Testing Notes + 建立新的 QA Sub-issue]」

5.4 Android vs iOS Hotfix 流程差異

iOS 緊急情況的額外選項：

若 Hotfix 需要 > 48 小時才能完成，且 iOS Crash Rate 持續高：

• 評估是否暫停 App Store Phased Release（在 App Store Connect 停止推送）
• 聯繫 Apple Developer Support 說明情況（可能加快 Expedited Review）

5.5 Hotfix Label 與 Cycle 的長期管理

[Hotfix] Label 的使用規範：

[Hotfix] Label：
  使用時機：建立 Hotfix Issue 時必加
  移除時機：Issue Monitoring Complete 後可移除（保持歷史記錄亦可）
  用途：月度報告篩選（RM 定期統計 Hotfix 頻率）

Hotfix Cycle 的保留政策：
  完成後保留 Cycle（不刪除），供 DORA 指標計算
  命名規範：「Hotfix vX.X.X（日期）」
  MTTR 計算：從 Cycle 的第一個 Comment 時間（Firebase Alert）到 Released 時間

六、QA 批次視窗設計（V2 全新章節）

6.1 設計理由

統整初稿 V1 的「個別 Issue 觸發 Ready for Test」原則是正確的設計（功能開發完就可以進入測試，不等其他功能），但沒有配套 QA 的工作安排機制。

問題：Fei Chen 和 Jimmy 兩人，如果每個 Issue 進入 Test Requested 都立即觸發測試，在一個 Cycle 中可能有 6-10 次工作中斷。每次中斷包括：閱讀 Issue → 理解測試上下文 → 找到對應的測試版本 → 切換測試環境。每次約 15-20 分鐘的切換成本，乘以 6-10 次，是每個 Cycle 損失 1.5-3 小時在上下文切換上。

設計原則：

• 個別 Issue 觸發（繼承 V1）：功能完成就進入 Test Requested，進入 QA 等待池
• 批次窗口處理（V2 新增）：QA 在固定時間集中處理等待池
• 緊急例外機制：[Hotfix] 和 [Priority: Urgent] 可以打破批次限制

6.2 QA 等待池（Linear 視圖設計）

QA Dashboard 視圖設定：

Linear → Team REL → Views → New View

視圖名稱：「QA 待測 Queue」
類型：Team View（Fei Chen 和 Jimmy 都可見）

Filter 設定：
  Status：Test Requested 或 Testing
  Assignee：Fei Chen 或 Jimmy（可以設定兩個 View，各自的 Queue）

排序設定：
  Primary：Priority（高 → 低）
  Secondary：Created At（早 → 晚）

分組設定（可選）：
  按 Label 分組：[Hotfix] / [Priority: Urgent] / 其他
  讓緊急 Issue 視覺上置頂

QA 等待池的工作節奏：

平時（非批次視窗）：
  → Test Requested 通知進來，Issue 出現在等待池
  → QA 繼續當前工作，不立即切換
  → 等待下個批次視窗

批次視窗（週二下午 + 週四下午，或 QA 自行調整）：
  Step 1：打開「QA 待測 Queue」視圖
  Step 2：按 Priority 排序，從高到低依序處理
  Step 3：每個 Issue 執行三方確認機制（確認 Testing Notes）
  Step 4：執行測試，記錄結果
  Step 5：批次結束時更新所有 Issue 狀態（Testing → QA Passed / Fix Required）

緊急插單（批次視窗外）：
  條件：Issue 有 [Hotfix] 或 [Priority: Urgent] Label
  流程：RM 通知 QA（Slack DM），說明緊急原因
  QA 響應：收到通知後，中斷當前工作，優先處理緊急 Issue

6.3 批次視窗時間的靈活設計

批次視窗的具體時間由 Fei Chen 和 Jimmy 根據實際工作節奏確認，「週二下午 + 週四下午」是建議值，不是硬性規定。

調整批次視窗的觸發條件：

• 等待池中的 Issue 平均等待時間 > 3 天：考慮增加批次視窗頻率
• 等待池中的 Issue 數量 < 2：不需要固定批次視窗，改為隨時處理
• 某 Cycle 中後期大量 Issue 積累：RM 協調 QA 臨時增加批次窗口

6.4 批次視窗與 Feature Freeze 的協調

在接近 Feature Freeze 時（Freeze 前 3 天），QA 需要加快處理等待池中的 Issue：

Freeze 前 3 天（RM 責任）：
  → RM 掃描等待池中的 Issue 數量
  → 若有積壓：與 QA 協調增加批次視窗（或臨時擴大視窗時間）
  → 若有 Issue 在 Fix Required 狀態：評估掉車風險

Freeze 前 1 天：
  → 剩餘等待池 Issue 全部處理完成（或決定掉車）
  → 不應有 Issue 在 Test Requested 而未進入 Testing

七、掉車 SOP：Label 系統優化（V2 版）

7.1 Label 命名優化

V1 設計問題：

[Dropped from vX.X.X] 版本特定 Label（如 [Dropped from v5.8.0]）長期會累積大量只用一次的 Label，違背 Label 管理的可持續性。

V2 解決方案：

Label 系統（V2 版）：
  [At Risk]              — 有掉車風險，RM 正在評估中
  [Dropped]              — 已確認掉車（通用，不含版本號）
  [Post-Freeze Exception] — Freeze 後特例加入，已三方確認

版本號記錄在 Issue Comment（而非 Label 名稱）：
「掉車自 v5.8.0，預計列入 v5.9.0
 決定時間：[日期]
 決策人：RM [姓名] + PO [姓名]」

7.2 掉車 Retrospective 格式（V2 去污名化版）

Linear Cycle Description 格式（公開記錄）：

本次版本掉車 Issue 列表：
  · REL-XXX：[功能名]
    掉車原因：[說明]
    下一版規劃：預計列入 vX.X.X
    學習點：[Planning 估計、技術依賴、需求變更等哪個環節可以改善]

  · REL-YYY：[功能名]
    掉車原因：[說明]
    下一版規劃：預計列入 vX.X.X
    學習點：[說明]

Retrospective 固定議程：

本次版本的掉車 Issue 列表 + 每個的學習點
  → 這個討論是正式 Sprint Retrospective 的固定一節
  → 討論方向：流程問題（為什麼估計不準確？有沒有技術依賴事先沒有識別？）
  → 不討論：個人績效和速度
  → 結果：補充對應 Issue 的 Testing Notes + 下次 Planning 的改善措施

八、Automation 完整清單（V2 版）

8.1 設計原則

V2 版 Automation 清單在 V1 基礎上做三個升級：

1. 每條 Automation 加入「技術可行性」欄位
2. 修正技術上不可行的設計（Automation 5 / Automation 11）
3. 新增 Hotfix 相關 Automation（Automation 13）

8.2 P0（必須在第一個版本用 Linear 追蹤前完成）

Automation 1：iOS Test Requested 通知

目的：取代 iOS RD 手動在 Slack 發通知，確保通知格式一致
觸發條件：Issue 狀態改為「Test Requested」AND Label 包含「iOS」
動作：發送訊息到 Slack <span class="tag">forest_ios_testcenter</span>：
「📱 iOS 測試通知
 功能：{Issue 標題}
 版本：{Project 名稱}
 Linear：{Issue URL}
 @Fei Chen @Jimmy 請確認 Testing Notes 後開始測試（批次視窗）」
技術可行性：Linear 原生，完全可行
V2 更新：通知文字加入「批次視窗」提醒

Automation 2：Android Test Requested 通知

目的：在 Android -ALPHA 機制基礎上，補充 Linear 狀態同步
觸發條件：Issue 狀態改為「Test Requested」AND Label 包含「Android」
動作：
  1. 發送訊息到 Slack <span class="tag">forest_android_testcenter</span>：
「🤖 Android 測試通知
 功能：{Issue 標題}
 版本：{Project 名稱}（Android 請確認版本號含 -ALPHA）
 Linear：{Issue URL}
 @Fei Chen @Jimmy 請確認 Testing Notes 後開始測試（批次視窗）」
  2. 若為第一個 Android Issue 進入 Test Requested：
「第一個 Android ALPHA 已發出。@Sherridy 請手動標記 First ALPHA Milestone 完成。」
技術可行性：Linear 原生，完全可行
V2 更新：Milestone 自動完成降級為手動標記提醒（技術修正）

Automation 3：Server/Web Test Requested 通知

目的：Server/Web 平台的統一通知入口
觸發條件：Issue 狀態改為「Test Requested」AND Label 包含「Server」或「Web」
動作：發送訊息到 Slack <span class="tag">forest_serverweb_testcenter</span>
技術可行性：Linear 原生，完全可行

Automation 4：Released 時間戳記錄（半自動）

目的：自動記錄發布時間，餵給 DORA Dashboard
觸發條件：Issue 狀態改為「Released」
動作：
  1. 在 Issue 新增 Comment：「Released at {Now}（自動記錄）」
  2. 觸發 Webhook → n8n → DORA Dashboard（記錄 released_at）
技術可行性：
  · Comment 記錄：Linear 原生，完全可行
  · DORA Webhook：需 n8n 接收端（n8n 已有運作）

8.3 P1（Month 1 完成）

Automation 5：Testing Notes 無條件提醒（V2 降級版）

目的：確保 PO / RD 不遺漏測試注意事項填寫
觸發條件：Issue 狀態改為「In Development」（無條件觸發，不判斷 Description 內容）
動作：在 Issue 新增 Comment：
「PO / RD 請確認：此 Issue 的測試注意事項是否已填寫？
 若已填寫請忽略此提醒；
 若尚未填寫，請在 In Development 期間完成補充：
   · PO：Issue Description 的「重點觀測項目」欄位
   · RD：Issue Description 的「技術邊界」欄位（開發中發現時更新）
 （此提醒為無條件發送，由 Automation 5 觸發）」

技術可行性：Linear 原生，完全可行

重要說明（V2 修正）：
  V1 / V3 設計意圖是「Description 中 Testing Notes 區塊為空時才觸發」
  但 Linear Automation 無法讀取 Description 內容，技術上不可行。
  V2 修正為無條件觸發（Issue 進入 In Development 時必定觸發）。
  [Testing-Notes-Missing] Label 改為手動加（RM 在 Weekly Review 時標注）。

Automation 6：Test Requested 個別確認 Comment

目的：強制 QA 確認已閱讀最新 Testing Notes，完成三方確認機制的 QA 節點
觸發條件：Issue 狀態改為「Test Requested」
動作：在 Issue 新增 Comment：
「🧪 此 Issue 已 Test Requested。

 QA 請在開始測試前確認（三方確認機制 QA 節點）：
 ☐ Testing Notes 已閱讀（確認 RD 開發中是否有補充技術邊界）
 ☐ 每條 Testing Notes 都有對應的 Sub-issue 測試項目
 ☐ Android：確認版本號包含 -ALPHA
 ☐ iOS：確認 RD 已在 Issue 補充 Comment 模板（含 TestFlight Build 號）

 ✅ 請在此 Comment 下方回覆「已確認 Testing Notes」後再開始測試。

 提醒：機制靠人工紀律，此 Comment 不阻止狀態改變。
       RM 每週 Review 時確認是否有遺漏的確認 Comment。」

技術可行性：Linear 原生，完全可行
V2 更新：說明「三方確認機制 QA 節點」並澄清「不阻止狀態改變」

Automation 7：Fix Required 通知 RM + RD

目的：Bug 發現後立即通知相關人員
觸發條件：Issue 狀態改為「Fix Required」
動作：
  1. Slack DM 給 RM（Sherridy）
  2. 根據 Label 發送通知到對應平台 Channel
     iOS → <span class="tag">forest_ios_testcenter</span>
     Android → <span class="tag">forest_android_testcenter</span>
     Server/Web → <span class="tag">forest_serverweb_testcenter</span>
  通知格式：
「❌ {Issue 標題} 測試未通過，需要修復
 Linear Issue：{URL}（詳見 Comments 的 Bug 描述）
 @[對應 RD] 請查看並確認修復時程」
技術可行性：Linear 原生，完全可行

8.4 P2（Month 2 完成）

Automation 8：翻譯 Gate（QA Passed + 需翻譯）（V2 版）

目的：防止翻譯確認被遺漏
觸發條件：Issue 狀態改為「QA Passed」AND Label 包含「Needs Translation」
動作：
  1. 發送 Slack 通知給 MKT 負責人
  2. 同時通知 Slack <span class="tag">forest-release</span>：
「{功能名} 已通過 QA，需要多國翻譯確認。
 @MKT 請確認翻譯文案，完成後請通知 RM 加 [Translation Confirmed] Label。
 RM（Sherridy）：完成後請手動加 [Translation Confirmed] Label 給 {Issue URL}」
技術可行性：Linear 原生，完全可行
V2 更新：Trigger 邏輯從「State 改為 Waiting for Translation」改為「QA Passed + Needs Translation Label 新增」

Automation 9：翻譯 Gate（QA Passed + 翻譯完成）（V2 版）

目的：翻譯已確認的功能自動進入下一階段
觸發條件：Issue 狀態為「QA Passed」AND Label [Translation Confirmed] 新增
動作：自動改狀態為「Build Requested」
技術可行性：Linear 原生，完全可行
V2 更新：Trigger 邏輯更新（配合 Label Gate 改動）

Automation 10：Stale Issue 提醒

目的：防止 Issue 長期卡在 In Development 無人察覺
觸發條件：Issue 狀態為「In Development」且超過 7 天無 Comment 更新
動作：Slack DM 給 Assignee（RD）：
「👀 {Issue 標題} 已超過 7 天無更新，請更新開發進度。
 Linear Issue：{URL}」
技術可行性：Linear 原生，完全可行

Automation 11：Cycle 結束前警告（V2 降級版）

目的：提醒團隊確認 Cycle 內所有 Issue 的完成狀態
原始設計意圖：距 Cycle 結束 ≤ 3 天，且 Cycle 中有 Issue 狀態為「In Development」時觸發

技術可行性：不可行
  Linear Automation 沒有「距 Cycle 結束 N 天」的 Trigger，
  這是確認的技術限制。

V2 降級方案（三選一）：
  方案 A（推薦，n8n 已有）：n8n Cron Job，每天上午 9:00 查詢 Linear API 的
    Cycle 結束日期，判斷是否在 3 天內，觸發 Slack 通知。
  方案 B（輕量備選）：RM 在建立 Cycle 時，在個人 Google Calendar 設定
    「Cycle 結束前 3 天」提醒，手動發 Slack 警告。
  方案 C（最輕量）：RM 在每週一固定掃描本週 Cycle 結束日期，手動評估是否需要警告。

  同樣的問題適用於 Feature Freeze 48 小時提醒（Milestone 日期也無法作為 Trigger）。
  若選方案 A（n8n），Feature Freeze 和 Cycle 結束的提醒可以共用同一個 Cron Job。

Automation 12：回測三次以上通知（V2 優化版）

目的：三次以上回測是品質異常信號，需要 RM 介入評估
原始觸發邏輯（V1）：Issue Label 新增「Re-test-3」
  問題：依賴「移除 Re-test-3 再加回」這個邊緣行為，不夠健壯

V2 優化觸發邏輯：
  Trigger：Issue 狀態改為「Fix Required」AND Issue 已有 Label「Re-test-2」
  Logic：狀態 + Label 組合，更健壯，且在第 3 次回測開始前就觸發

動作：發送訊息到 Slack <span class="tag">forest-release</span>（PM Channel）：
「⚠️ 回測警告：{Issue 標題} 即將進行第三次回測
 Issue：{URL}
 目前已回測：2 次（再次進入 Fix Required）
 @Sherridy @Shawn 請確認是否需要特別介入或調整驗收標準」

技術可行性：Linear 原生，完全可行（狀態 + Label 組合 Trigger）
V2 更新：Trigger 邏輯優化，提前在第 3 次回測前發出警告

8.5 P3（Month 3 新增）

Automation 13：Hotfix Label 設置後通知 RM Channel

目的：確保 Hotfix Issue 建立後，RM 和相關人員立即知道
觸發條件：Issue Label [Hotfix] 新增
動作：
  1. Slack 通知 <span class="tag">forest-release</span>（RM Channel）：
「🚨 Hotfix Issue 已建立：{Issue 標題}
 Issue：{URL}
 Hotfix 版本：請在 Issue Comment 確認
 @Sherridy 請確認 Hotfix Cycle 已建立，並通知 RD 優先處理。
 MTTR 計時從 Firebase Alert 時間起算，請在 Issue Comment 記錄 Alert 時間。」
  2. Slack DM 給 David：告知 Hotfix 已啟動（同步備援通知）
技術可行性：Linear 原生，完全可行

8.6 技術可行性總覽表

九、Linear 功能限制完整清單（V2 新增）

以下限制是在三版分析中確認的 Linear 原生功能邊界。文件使用者在設計任何依賴 Linear 的機制時，應先確認相關限制。

十、流程節點完整對應總表（V2 版）

十一、已識別 Gap 彙總（V2 版）

Gap 1：QA 產能管理（V1 識別，V2 改善）

Linear 無資源容量規劃功能。V2 解決方案：QA 等待池 Linear 視圖 + 批次視窗工作節奏 + RM 協調緊急插單。不需要 Spreadsheet，靠視圖 + 工作節奏設計。

Gap 2：測試報告精美格式（V1 識別）

V2 策略不變：M3 與 QA 共同評估是否全遷移；M1-M2 繼續在 Notion 建報告，連結貼入 Linear Issue。

Gap 3：DORA Dashboard 直接整合（V1 識別）

Automation 4 的 Released Webhook → n8n → DORA 維持現有 pipeline，不需要重建。

Gap 4：多國翻譯（MKT 不在 Linear）（V1 識別）

短期由 RM 代理更新 Label（加 [Translation Confirmed]）；長期評估將 MKT 加入 Linear Workspace。

Gap 5：Issue 只能屬於一個 Project（V1 識別）

跨平台功能（iOS + Server 同步功能）拆成兩個 Issue，用 Issue Relation（Relates To）連結。

Gap 6：Testing Notes 填寫率無法自動追蹤（V3 識別，V2 更新）

V1 設計的「Automation 5 自動偵測空欄」在技術上不可行。V2 方案：[Testing-Notes-Missing] Label 手動加（RM 每週 Review 時標注未填的 Issue）；Automation 5 無條件提醒（不偵測是否已填）。長期：評估 Custom Field 追蹤填寫狀態。

Gap 7：掉車後 Issue 歸屬（V3 識別）

掉車 Issue 移到下一個版本 Project 或 Backlog，並在 Issue Comment 記錄掉車版本和原因（[Dropped] Label + Comment）。

Gap 8：iOS TestFlight 自動化通知（V2 新增識別）

M1-M2 過渡方案：RD 使用 Linear Issue Comment 標準模板（不靠 Slack，有記錄可追溯）。M3 評估：GitHub Actions + TestFlight Upload API → Linear Webhook → 狀態自動更新。

Gap 9：Hotfix MTTR 自動計算（V2 新增識別）

MTTR 目前靠人工計算（Firebase Alert 時間 - Hotfix Released 時間），記錄在 Issue Comment。M3 評估：n8n 整合 Firebase Alert Webhook + Linear Released Webhook，自動計算 MTTR 並發布到 DORA Dashboard。

十二、標準 Label 前綴管理（V2 新增）

V2 針對 Linear Workspace 中的 Label 系統建立前綴規範，確保長期可管理。

Label 管理原則：

• 避免建立版本特定 Label（如舊版的 [Dropped from v5.8.0]）
• 每個前綴分類有固定用途，不混用
• [Hotfix] 和 [At Risk] 在 Issue 完成後可移除（保持 Label 清單乾淨）

相關文件：00-導入計劃總覽（統整版V2） | 01-現有流程深度分析（統整版V2）

linear 功能對應 統整版v2 消費者App forest feature-freeze 掉車sop testing-notes hotfix-sop qa批次視窗 統整初稿-v2