版本迭代紀錄 V2

Linear 導入計劃的設計決策歷史

零、文件說明

本文件記錄 Forest App Linear 導入計劃從 V1 到統整初稿 V2 的完整演化歷程。

文件範圍劃分：

• V1 → V2 → V3 → 統整初稿 的詳細設計演化記錄，請見「版本迭代紀錄.md」（統整初稿資料夾）
• 本文件的核心新內容：統整初稿 → 統整初稿 V2 的演化，以及 Agent team 的辯論洞察和 V2 的設計決策理由

本文件不重複統整初稿的版本迭代記錄，而是以引用和摘要方式涵蓋 V1-統整初稿的歷史，然後展開 V2 的新內容。

一、版本地圖速覽（含統整初稿 V2）

二、三版（V1 → V2 → V3）演化摘要

詳細演化記錄請見「版本迭代紀錄.md」（統整初稿資料夾），本節為核心摘要。

V1 的奠基貢獻

V1 建立了這個導入計劃最核心的架構：13 節點流程分析框架。從 Planning → RM 版本號 → QA 展測項 → In Development → Ready for Test → Testing → 測試報告 → Ready for Fix → Ready for Release Build → Ready for Release → Release → Rolling → Released，這個框架在所有後續版本中保持不變。

V1 的另一個核心貢獻是確立「個別 Issue 觸發 QA，不等 Milestone」的設計原則，以及「RM 集中管理版本分配」的節奏機制。這兩個設計在 V2/V3/統整初稿中均完整繼承。

V1 的主要侷限：完全無業界參考；缺 Testing Notes 強制機制；缺 Feature Freeze 操作設計；缺 Hotfix SOP。

V2 的業界視野突破

V2 引入了業界研究維度，系統性對標 Google、Meta、Apple、Microsoft、Spotify 五大科技公司，並明確宣告「列車不等人」作為 Forest App 的文化方向。DORA 四指標的引入，讓設計決策有了外部評估基準。

V2 識別的核心問題：Forest App 現況是「列車等人」，版本往往等功能完成才發。但 V2 只給出了文化宣言，沒有操作手冊（掉車怎麼執行、誰決定、如何通知），這留給了 V3。

V2 的主要侷限：對標公司規模差距太大（數萬人 vs 15 人），DORA 指標的執行設計不具體，Feature Freeze 停在「命名」層面，Testing Notes 有欄位但無觸發機制。

V3 的消費者 App 轉向

V3 認識到「V2 對標的公司太大了」，將業界參考從大型科技公司轉向同類型消費者 App（Duolingo、Todoist、Headspace），確立了「消費者 App 為主要對標，大型科技為哲學方向」的雙層次策略。

V3 的三大實質貢獻：

掉車 SOP 具體化：對標 Duolingo 的 Release Cut Day，將文化宣言轉成五步驟操作手冊：識別風險 Issue → 加 [At Risk] Label → Slack DM 詢問 RD → 確認掉車後移 Project + 改 Label → 版本照常發車 + 下個 Cycle 重排。

Testing Notes 四觸發點：從「有欄位」升級到「有人填、有人看」的完整流程，四個觸發點覆蓋 PO 初始填寫（Planning）、RD 開發中補充（In Development）、QA 第一次讀取（Ready for Test）、QA 測試前確認（Testing）。

Feature Freeze 完整里程碑：從語意修正升級為六 Milestone 架構，並設計了 Freeze 前 3 天的風險掃描機制。

V3 的未解問題：缺 Hotfix SOP（「緊急超車道」設計缺失）；缺 QA 批次視窗（個別觸發後 QA 如何排程未設計）；Automation 5 的技術問題（Testing Notes 自動偵測 Description 內容在 Linear 不可行）；「雙向強制」只覆蓋 PO 和 QA，遺漏了 RD 這個最脆弱環節。

三、統整初稿 → 統整初稿 V2 的演化

3.1 Agent team 的構成與角色

統整初稿 V2 的產出過程由五個 Agent 協作完成，每個 Agent 有明確的角色分工：

各 Agent 的分析報告為獨立工作文件，存放於統整初稿 V2 資料夾的「工作文件-」前綴文件中。

3.2 Release Tracker Expert 的關鍵洞察

Release Tracker Expert 從流程有效性角度，對 13 節點進行逐一分析。以下記錄核心發現：

洞察 1：Testing Notes 責任鏈的最脆弱環節在 RD

Release Tracker Expert 的核心論點：「Testing Notes 責任鏈（PO → RD → QA）中，PO 有 Automation Comment 提醒，QA 有 Ready for Test 觸發提醒，但 RD 補充測試注意事項這一步，在 In Development 期間 Status 不改變，因此 Linear Automation 無法觸發任何提醒。這一步完全依賴習慣。」

補救方案識別：「在 RD 提交 PR 時，PR Template 加入確認欄位（『已更新 Linear Issue 的測試注意事項：Y / N / 無更新』），讓補充行為嵌入 PR Review 流程，而非獨立習慣。」

洞察 2：掉車 SOP 的文化可行性需要「第一次」的心理設計

「第一次讓功能掉車時，RD 的心理反應幾乎必然是負面的：感覺自己的工作被打回票、擔心被認為效率不好、想加班補救而不願意接受掉車。這個溝通步驟應該寫進 SOP，而不是留給 RM 自己判斷要不要做。」

洞察 3：iOS vs Android 通知可靠性差異是結構性差異

「V3 正確地選擇顯性化差異、各自最佳化。統整初稿 V2 應繼承 V3 的這個決策，並在設計上明確承認：iOS 的短期手動方案不是妥協，是面對現實的工程決策。」

洞察 4：Project 非同步完成的回歸測試問題（三版中最被低估的結構性風險）

「當 Issue A 在 ALPHA1 版本中測試通過，然後 Issue D 完成後包了 ALPHA4，Issue A 的測試結果還有效嗎？如果 Issue D 的代碼改動影響了 Issue A 的功能，Issue A 需要回歸測試。但誰來決定哪些已通過的功能需要回歸測試？這個決策目前沒有明確的責任人。」

建議補救：PR Template 新增「影響範圍（Impact Scope）」欄位，讓 QA 參考 RD 的影響範圍說明判斷是否需要回歸已測功能。

洞察 5：工具遷移的文化阻力在情感層面，不在技術層面

「真正的遷移阻力不是『不知道怎麼用 Linear』，而是『我已經知道怎麼在 Slack 找東西，但在 Linear 我還不知道』（認知成本）和『我和同事在 Slack 的工作習慣是共同的，改變 Linear 等於要求所有人同時改變』（社交成本）。需要明確的 Buffer 期設計：月 1-2 兩個工具都可以用，月 3 起 Bug 的正式記錄只在 Linear。」

3.3 Linear Expert 的關鍵洞察

Linear Expert 從工具可行性角度，識別了設計和工具實際能力之間的落差。以下記錄核心發現：

洞察 1：Automation 5 技術不可行（最高嚴重性）

「Automation 5（Testing Notes 缺失提醒）的設計意圖是：Issue 狀態從 Planning 改為 In Development，且 Description 中 Testing Notes 區塊為空時，加 Label + 發 Comment。Linear Automation 的 Trigger 中，沒有『讀取 Issue Description 內容』的能力。此 Automation 必須降級為無條件提醒，移除智慧判斷的部分。」

降級方案：Trigger 改為「Issue 狀態改為 In Development」（移除 Description 內容條件），Action 改為「無條件發 Comment 提醒 PO/RD 確認 Testing Notes 是否已填寫」。Label [Testing-Notes-Missing] 改為 RM 手動加，不能自動判斷。

洞察 2：Feature Freeze 48 小時提醒 Linear 原生不支援

「Linear Automation 沒有『距離 Milestone 日期 N 天』的 Trigger。Feature Freeze 的 48 小時提醒在 Linear 原生 Automation 中無法實現，必須改用 n8n 定時任務或降級為 RM 手動提醒。」

洞察 3：「雙向強制」是誤稱（工具能力層面）

「Linear 中無法實現真正的『強制』——沒有任何機制能阻止 QA 在沒有回覆 Comment 的情況下，直接把 Issue 狀態改為 Testing，甚至 QA Passed。這個設計本質上依賴人工紀律，而不是工具強制（Tool Enforcement）。在設計文件中，明確將『雙向強制』改稱為『雙向確認機制』，避免讓執行者誤以為工具本身會阻擋不合規的操作。」

洞察 4：12 States 命名混亂問題

「統整版中有四個狀態都以『Ready for』開頭（Ready for Test / Ready for Fix / Ready for Release Build / Ready for Release），在 State 選擇器的下拉清單中視覺上非常相似，在快速操作時容易選錯。建議優化：Ready for Release Build → Packaging，Ready for Release → Pending Release。」

「Waiting for Translation 只對有翻譯需求的功能才有意義，但出現在所有 Issue 的 State 選擇器中，增加噪音。建議改為 Label 組合：QA Passed + Label [Needs Translation]，讓 State 數量從 12 降至 11。」

洞察 5：Automation 12 的觸發邏輯脆弱

「依賴『移除 Re-test-3 Label 再加回』來重複觸發 Automation 12，是邊緣行為設計，不直觀且容易出錯。建議改為 Trigger 在『Issue 狀態改為 Ready for Fix，且 Label 包含 Re-test-2』，這樣第三次進入 Ready for Fix 時自動觸發，不需要手動操作 Label。」

洞察 6：Dropped Label 命名方式不可持續

「[Dropped from vX.X.X] 每個版本都需要建立一個新 Label，長期累積大量只用一次的 Label，違背 Label 管理的可持續性。建議改為通用 [Dropped] Label + Issue Comment 記錄版本號（不放在 Label 名稱裡）。」

3.4 Industry RM Expert 的關鍵洞察

Industry RM Expert 從消費者 App 業界實踐角度，識別了三版設計對標不到位的地方和系統性缺口。

洞察 1：Hotfix SOP 完全缺失——三版最大的系統性盲點

「V1/V2/V3 三個版本都沒有設計 Hotfix（緊急修復）流程與列車模型的互動。業界的做法：Duolingo 的 Hotfix 走 Expedited App Store Review，有嚴格的觸發條件；Todoist 的 Fastlane Hotfix Lane 可以快速打包只包含修復 commit 的版本。沒有 Hotfix SOP 的列車模型，在第一次緊急事故時必然失控——因為 Hotfix 需要打破『列車不等人』的常規，而沒有設計好的超車道，每次 Hotfix 都會變成特例討論，消耗 RM 的信任資本。」

洞察 2：QA 批次視窗的必要性——Fei Chen + Jimmy 的 Context Switching 問題

「Todoist 的個別 Issue 完成即測設計，背後有一個鮮少被引用的配套機制：三個工作天非同步 QA 回饋窗口。純粹的個別 Issue 觸發在 Fei Chen + Jimmy 兩人配置下，會造成：同時持有多個進行中狀態的測試任務、在多個版本功能間頻繁切換（錯誤率上升）、難以給出整體版本的 QA 完成預期時間。需要加入 QA 批次視窗：Issue 進入等待池，每週兩個固定窗口批次處理，緊急情況需 P0 標記和 RM 批准。」

洞察 3：Level 2 → Level 5 成熟度跳躍過陡——缺少 Level 3.5 過渡

「從 Level 3 直接跳 Level 5（完整 Feature Freeze + 掉車 SOP + Crash Gate），對組織文化的衝擊太大。Todoist 的歷史路徑：2018-2019 年先引入 String Freeze（Level 3.5），2020-2021 年才全面引入 QA 文件化和時間箱（Level 4）。Forest App 應採用同樣的過渡策略：Month 1 末先引入 String Freeze 作為 Level 3.5 試水，讓團隊習慣『截止點是死的』，再在 Month 2 引入掉車 SOP（情緒阻力更高的機制）。」

洞察 4：Feature Freeze 保守模式缺少明確退出條件

「統整初稿（V1 版）設計中，前幾次掉車需要 RM + PO 確認，之後評估是否自動化——這是模糊的『之後評估』，往往就是永遠的設計。業界的教訓是：Release Gate 一旦有例外，例外就會成為常態。需要設定明確退出條件：前 2 次保守模式，第 3 次起自動執行（Duolingo 原版模式），退出確認時間點為 Month 2 Sprint Review。」

洞察 5：四個常被忽略的系統性缺口

Industry RM Expert 識別了三版設計的四個共同盲點：

1. Phased Release 啟用確認：三版都假設已啟用，但沒有確認機制
2. Release Notes 撰寫流程：由誰負責、從哪裡取材、何時完成——三版均為空白
3. Beta 用戶群結構化設計：50-200 人 TestFlight 群從哪裡招募、誰管理、Bug 如何回報
4. Hotfix SOP（最重要）：緊急超車道的完整設計

3.5 Integration Expert 的整合裁決

Integration Expert 的角色是整合三位 Agent 的發現，識別三方之間的邏輯關係，並給出可執行的設計裁決。

三方共識直接採納（四條）：

共識一（Testing Notes 最脆弱環節在 RD）：三位 Agent 從不同角度獨立確認——Release Tracker Expert 從流程角度，Linear Expert 從工具技術角度（Automation 5 無法偵測 Description），Industry RM Expert 從責任鏈角度。整合結論：PR Template 加入確認欄位是目前唯一可以在工具層面接近強制的設計，Testing Notes 執行問題的根源在 RD 環節。

共識二（掉車 SOP 工具設計已足，文化介入需強化）：三位 Agent 均確認五步驟 SOP 在 Linear 中可執行，但均指出文化落地需要更多設計。整合結論：加入去污名化溝通設計和第一次掉車後的正向強化機制。

共識三（Feature Freeze 提醒 Linear 原生不可行）：三方均指出此問題。整合結論：採用 n8n 定時任務（方案 A）或 Calendar 手動（方案 B）替代，具體選擇根據 n8n 是否已在運作決定。

共識四（QA 切換成本在個別觸發模式下被低估）：Release Tracker Expert 建議 QA 建立待測 Queue 視圖，Industry RM Expert 建議批次視窗，Linear Expert 確認 Linear 沒有原生 QA 排程功能。整合結論：兩個建議互補，同時採用——待測 Queue 視圖（工具層面）+ 批次視窗（工作節奏層面）。

組合洞察整合裁決（四條）：

組合 A（Release Tracker + Linear）：「雙向強制」在工具和責任鏈兩個層面都是誤稱。改稱「三方確認機制（PO + RD + QA）」，明確依賴人工紀律。

組合 B（Linear + Industry RM）：Automation 5 降級（無條件提醒）+ 「主責阻止點」設計的出路是 PR Template，而非 Linear 狀態轉移阻止（後者技術不可行）。

組合 C（Release Tracker + Industry RM）：文化衝擊在 Month 2 集中（Feature Freeze + 掉車 SOP 同時引入）可能反效果，Level 3.5（String Freeze 先行）解決方案是在 Month 1 末先試水。

組合 D（三方）：Hotfix SOP 是三版共同盲點，V2 必須作為主要新增設計。Release Tracker Expert 的監控設計提供觸發可見性，Linear Expert 確認 Label 系統可延伸，Industry RM Expert 提供業界依據。

張力裁決（四條）：

張力一（Testing Notes 主責阻止點可行性）：Industry RM Expert 建議在 Ready for Test 狀態轉移時阻止 Testing Notes 空白的 Issue，Linear Expert 指出此在 Linear 技術上不可行。裁決：阻止點轉移到 PR Template（PR 合併節點），Ready for Test 狀態改變後發 Automation Comment 軟提醒，Weekly Review 時 RM 手動審計。

張力二（Feature Freeze 保守模式 vs 自動模式）：Integration Expert 採納 Industry RM Expert 的精確化建議，「第 3-5 次後評估」改為「第 3 次起自動執行」，Month 2 Sprint Review 確認。

張力三（掉車 Label 命名）：採納 Linear Expert 建議，通用 [Dropped] Label + Comment 記錄版本號，放棄版本特定 Label 命名。

張力四（QA 批次視窗固定時間 vs 彈性排程）：兩個建議互補，同時採用。待測 Queue 視圖讓工作清單可見，固定批次視窗（建議週二 + 週四下午，但可依實際調整）提供工作排程結構。緊急插單需 RM 批准。

四、統整初稿 V2 的主要設計決策

4.1 Hotfix SOP（全新加入）

決策背景：三版均未設計 Hotfix 流程，但消費者 App 必然面臨緊急修復需求。第一次緊急事故時，沒有設計好的超車道會導致每次 Hotfix 成為特例討論，消耗 RM 的信任資本。

業界依據：Duolingo 的 Expedited App Store Review 文化、Todoist 的 Fastlane Hotfix Lane、DORA MTTR < 3 天（考慮 iOS App Store 審核時間）。

設計選擇：

• 觸發條件：PO 判定為 P0 Bug（David 或 Ezou，兩人其一即可）；P0 判定參考指標包含：Firebase Crashlytics Crash-free rate < 99.0%、付費功能中斷、影響 > 10% 用戶的核心功能失效
• 授權人：PO（David 或 Ezou，兩人其一即可，不需要兩人都同意，確保緊急時決策速度）
• 執行步驟：Linear 建立 Hotfix Issue（加 [Hotfix] Label + Comment 記錄版本號）→ RD 在 hotfix/vX.X.X 分支修復 → 精簡 Review（RD Lead 審查）→ Shawn 申請 Expedited Review → 發布後記錄 MTTR → 下次 Retrospective 討論根因
• MTTR 計時起點：Firebase Alert 時間戳（不是人工發現時間）

文件分布：Hotfix SOP 寫入 05-團隊導入策略（文化層面）、06-角色視角指南（各角色操作）、04-環境建置指南（Label 設定）。

4.2 QA 批次視窗（全新加入）

決策背景：個別 Issue 觸發 QA 的原則是正確的（不等 Milestone），但沒有配套 QA 的工作安排機制，造成 Fei Chen 和 Jimmy 高頻 context switching，錯誤率上升。

業界依據：Todoist 的三個工作天非同步 QA 回饋窗口；消費者 App 兩人 QA 團隊的效率最大化策略（批次處理降低切換成本）。

設計選擇：

• 待測 Queue：Linear 建立 QA Dashboard（Filter：Status = Ready for Test），Issues 進入後自動出現
• 批次視窗：每週 2 個固定時段（建議週二 + 週四下午，可依實際調整），窗口內集中處理等待池 Issue
• 緊急插單：需 RM 在 Issue 加 [Priority: Urgent] 標記，QA 優先處理（不需等下個窗口）
• 彈性原則：窗口時間由 Fei Chen 和 Jimmy 根據實際工作節奏調整，不硬性規定

文件分布：批次視窗機制寫入 06-角色視角指南（QA 視角）、05-團隊導入策略、03-三個月導入路線圖（Month 2 啟動）。

4.3 Testing Notes「三方確認機制」（升級「雙向強制」）

決策背景：統整初稿（V1）的「雙向強制」在工具和責任鏈兩個層面都是誤稱——Linear 無法強制，且 PO + QA 兩端的設計遺漏了 RD 這個最脆弱的中間環節。

三方共識：Release Tracker Expert（流程角度）、Linear Expert（工具角度）、Industry RM Expert（責任鏈角度）均獨立確認 RD 補充環節是最脆弱點。

設計選擇：

• 名稱更正：「雙向強制」改稱「三方確認機制（PO 初始填寫 + RD 開發中補充 + QA 雙重讀取）」
• 明確說明：機制依賴人工紀律，非工具強制
• RD 環節補強：PR Template 加入確認欄位（「已更新 Linear Issue 的測試注意事項：Y / N / 無更新」），讓補充行為嵌入 PR Review 流程
• RD Impact Scope：PR Template 同時加入影響範圍欄位，幫助 QA 判斷回歸測試範圍

4.4 Automation 5 降級

決策背景：統整初稿（V1）的 Automation 5 設計意圖是在 Testing Notes 空白時智慧提醒，但 Linear Automation 技術上無法讀取 Description 內容，此設計不可行。

技術事實（Linear Expert 確認）：Linear Automation Trigger 只能判斷 Issue State / Label / Assignee / Priority / Due Date，無法讀取 Description 文字內容。

設計選擇：

• Trigger：Issue 狀態改為 In Development（移除 Description 內容條件）
• Action：無條件發 Comment 提醒（「PO / RD 請確認：此 Issue 的測試注意事項是否已填寫？若已填寫請忽略此提醒；若尚未填寫請在 Planning 完成前補充。」）
• Label [Testing-Notes-Missing]：改為 RM 在 Weekly Review 時手動標注，不能自動判斷

影響範圍：04-環境建置指南的 Automation 5 描述需更新；07-功能案例走查的演示需更新；所有文件中「Automation 5 智慧偵測」改為「Automation 5 無條件提醒」。

4.5 Feature Freeze 提醒替代方案

決策背景：統整初稿（V1）設計 Feature Freeze 前 48 小時的 Linear Automation 提醒，但此在 Linear 技術上不可行（無 Milestone 日期觸發的 Trigger）。

三選一方案：

• 方案 A（推薦）：n8n Cron Job，每天定時查詢 Linear API 的 Milestone 日期，判斷是否在 2 天內，觸發 Slack 通知。前提：n8n 已在運作，配置成本約 2-4 小時工時。
• 方案 B（輕量備選）：RM 在 Feature Freeze Milestone 建立時，同步在個人 Google Calendar 設定「Freeze 前 2 天」提醒事項，手動發送 Slack 警告。
• 方案 C（最輕量）：取消自動提醒，RM 每週一固定掃描本週 Milestone 日期，手動評估是否需要警告。

執行決定原則：若 n8n 已有運作，選方案 A；若 n8n 尚未導入，先用方案 B 作為過渡。

4.6 State 命名優化

決策背景：Linear Expert 識別「Ready for」前綴用了 4 次，在 State 選擇器中視覺相似，容易選錯。Waiting for Translation 在所有 Issue 中出現但只對部分 Issue 有意義。

設計選擇：

• Ready for Release Build → Packaging（語意清晰：正在打正式版本包）
• Ready for Release → Pending Release（語意清晰：等待送審）
• 保留 Ready for Test 和 Ready for Fix（業界通用，改動成本高）
• Waiting for Translation → 改為 Label 組合（QA Passed + Label [Needs Translation]），State 數量從 12 降至 11
• 備注：如果改名溝通成本過高，可保留原名，改用顏色和分組提高區別性

Automation 8、9 觸發邏輯更新：Trigger 從「State 改為 Waiting for Translation」改為「State = QA Passed + Label Needs Translation 新增」，Logic 不變，Trigger 調整。

4.7 成熟度路徑增加 Level 3.5（String Freeze 先行）

決策背景：Release Tracker Expert 和 Industry RM Expert 的組合洞察——文化衝擊集中在 Month 2（Feature Freeze + 掉車 SOP 同時引入）可能反效果，需要先建立「截止點是死的」的基本文化認知。

業界依據：Todoist 的歷史路徑（2018-2019 年先 String Freeze，再逐步引入 QA 文件化和時間箱）。String Freeze 的情緒阻力最低，是最適合「第一個截止點」的機制選擇。

設計選擇：

• Month 1 末（Level 3 → Level 3.5）：String Freeze 試水。版本最後 2 週，所有翻譯字串不再修改，MKT 以此日期為翻譯截止。目標是讓團隊習慣「有截止點且不可彈性延伸」，而不是翻譯本身的問題解決。
• Month 2（Level 3.5 → Level 4）：掉車 SOP 第一次演練 + 第一次真實掉車 + 掉車去污名化 Retrospective
• Month 3（Level 4 → Level 5）：完整 Feature Freeze 文化（含 Crash Gate 初步設計）+ Feature Freeze 自動化（第 3 次掉車起，無需逐次確認）

五、設計決策分類表（統整初稿 V2）

附錄：Agent team 的辯論記錄摘要

以下以表格形式記錄三位 Agent 在主要議題上的論點和整合結論。這個記錄的目的不是評判哪個 Agent 更正確，而是記錄「為什麼最終做出這個設計選擇」的辯論過程。

本文件由 Orchestrator 產出，記錄 Forest App Linear 導入計劃的完整設計演化歷史。

V1 → V2 → V3 → 統整初稿的詳細記錄請見「版本迭代紀錄.md」（統整初稿資料夾）。本文件重點為統整初稿 → 統整初稿 V2 的演化記錄。

文件日期：2026-02-19

相關文件：00-導入計劃總覽（統整版V2） | 09-業界基準研究總覽（統整版V2） | 工作文件-Integration-Expert整合決策.md

linear 導入計劃 統整版-v2 版本迭代 設計決策 agent-team Forest