Integration Expert 整合決策報告

2026-02-23
工作文件integration整合決策統整初稿-v2orchestrator-input

Integration Expert 整合決策報告

統整初稿 V2 設計依據

文件定位：本報告整合三位 Agent（Release Tracker Expert、Linear Expert、Industry RM Expert）的分析發現，產出可指導 Orchestrator 撰寫 11 個最終文件的整合決策依據。本報告不只是三份分析報告的摘要——它識別三方發現之間的邏輯關係、解決張力、並給出可執行的設計裁決。

閱讀對象：Orchestrator。每一節的最終結論都以「Orchestrator 執行指令」形式呈現，確保可直接轉化為文件撰寫動作。

一、三位 Agent 發現的交叉驗證

1.1 一致確認的問題（三方共識）

以下問題在三份分析報告中均有獨立觀察，相互佐證，整合者視為確定事實，不需要進一步裁決，直接採納。

共識一：Testing Notes 責任鏈的最脆弱環節在 RD 補充這一步

三方共識：Testing Notes 的執行問題不是出在 PO（有 Automation 提醒），也不是出在 QA（有兩次讀取觸發），而是出在 RD——開發中對 Issue 補充技術邊界這個動作，沒有工具觸發，也沒有流程強制點。統整初稿 V1 的「雙向強制」設計實際上覆蓋了 PO 和 QA 兩端，遺漏了 RD 這個最脆弱的環節。

共識二：掉車 SOP 的設計對了，但缺少文化落地的心理設計

三方共識：掉車 SOP 的工具設計已足夠（統整初稿 V1 的設計可行），需要強化的是文化介入設計——特別是退出「保守模式」的明確條件，以及第一次掉車後的正向強化機制。

共識三：Feature Freeze 提醒機制在 Linear 原生無法實現，需要替代方案

三方共識：Feature Freeze 提醒需要 n8n 定時任務或 Calendar Alert，不能依賴 Linear 原生 Automation。同時，Feature Freeze 的執行模式需要明確的「從保守模式到自動模式」的升級路徑。

共識四：QA 切換成本在個別 Issue 觸發模式下被低估

三方共識：統整初稿 V1 採用個別 Issue 觸發原則是正確的（不等 Milestone），但沒有配套 QA 的工作安排機制。V2 需要補充「QA 批次窗口」設計。

1.2 互相補強的發現（A+B 或 B+C 的組合洞察）

以下發現由兩位 Agent 的分析組合而成，單一視角無法看到的洞察。

組合洞察 A（Release Tracker + Linear）：Testing Notes 的「雙向強制」必須改名

Release Tracker Expert 指出「RD 補充是最脆弱的環節」，Linear Expert 指出「Linear 沒有條件式狀態轉換，QA 可以跳過 Comment 直接改狀態」。

兩者組合的洞察：「雙向強制」這個名稱在兩個層面都是誤稱——工具層面（Linear 無法強制），以及責任鏈層面（PO + QA 的兩向強制遺漏了 RD 這個中間環節）。正確的描述是「三方確認軟機制，靠人工紀律支撐，最脆弱點在 RD 中間環節」。

整合裁決：統整初稿 V2 中，所有提到「雙向強制」的地方，改稱「三方確認機制（PO 初始填寫 + RD 開發中補充 + QA 雙重讀取）」，並明確說明「機制依賴人工紀律，非工具強制」。PR Template 加入確認欄位是目前唯一可以在工具層面接近強制的設計。

組合洞察 B（Linear + Industry RM）：Automation 5 降級 + 主責阻止點設計的互補

Linear Expert 指出 Automation 5 必須降級為無條件提醒（不能判斷 Description 是否為空），Industry RM Expert 指出需要一個「主責阻止點」在 Ready for Test 狀態轉移時。

兩者組合的洞察：Automation 5 降級（無條件提醒）解決了「提醒但無法阻止」的問題，而 Industry RM Expert 提出的「阻止點」在 Linear 工具層面同樣無法實現（Linear 沒有條件式狀態轉換）。真正的出路是：Automation 5 降級為無條件提醒（改習慣），PR Template 加入確認欄位（在 PR 合併這個唯一有工具強制的節點插入），而非試圖在 Linear Issue 狀態轉移時阻止。

整合裁決：Automation 5 降級方案採納（無條件提醒），「主責阻止點」轉移到 PR Template 的確認欄位，而非在 Linear 狀態轉移時阻止。Industry RM Expert 的「阻止 Ready for Test 狀態轉移」建議在 Linear 工具限制下不可行，以 PR 節點替代。

組合洞察 C（Release Tracker + Industry RM）：成熟度路徑需要 Level 3.5 過渡

Release Tracker Expert 觀察到工具遷移的文化阻力在情感層面而非技術層面，Industry RM Expert 指出業界案例顯示 Level 3 到 Level 5 之間有必要的過渡步驟，建議以 String Freeze 先行作為 Level 3.5。

兩者組合的洞察：統整初稿 V1 宣告的月 1-3 路線圖，實際上跳過了一個關鍵的文化試水期——先建立「截止點是死的」這個最基本的文化認知（用 String Freeze 這個低衝突的機制），再引入掉車 SOP（中等衝突），最後進入完整 Feature Freeze（高衝突）。統整初稿 V1 的三個月規劃中，Month 2 同時引入 Feature Freeze 設定和掉車 SOP，文化衝擊集中，可能反效果。

整合裁決：Month 1 末（非 Month 2 初）先引入 String Freeze 作為 Level 3.5 試水，讓團隊習慣一個截止點。Month 2 再進入掉車 SOP 演練。Month 3 才是完整 Feature Freeze 文化。這比統整初稿 V1 的時序更有彈性，但不拖延最終目標。

組合洞察 D（三方）：Hotfix SOP 缺失是最大的未識別風險

Industry RM Expert 明確指出三版均缺少 Hotfix SOP。Release Tracker Expert 的監控設計（Released → Monitoring → Monitoring Complete）提供了觸發 Hotfix 的可見性前提。Linear Expert 指出 Label 系統已有 [At Risk] 等標記機制，可以延伸支援 Hotfix 流程。

三方組合的洞察：沒有 Hotfix SOP 的 Release Train 系統，在第一次緊急事故時必然失控——因為 Hotfix 需要打破「列車不等人」的常規，而沒有設計好的超車道，每次 Hotfix 都會變成特例討論，消耗 RM 的信任資本。Hotfix SOP 是讓 Release Train 文化在緊急情況下仍能有序運作的安全閥。

整合裁決：統整初稿 V2 必須新增 Hotfix SOP 作為獨立設計。這是三個版本的共同盲點，V2 的主要差異性之一。

1.3 存在張力的地方（需要整合者裁決）

以下幾個地方三位 Agent 的建議存在方向上的張力，需要整合者給出裁決。

張力一：QA Testing Notes 的「主責阻止點」可行性

整合裁決：Industry RM Expert 的設計意圖正確（需要一個強制點），但在 Linear 工具限制下不可行。妥協方案是：在 Ready for Test 狀態改變「後」立即發出 Automation Comment（「⚠️ 請確認 Testing Notes 已完整，不完整時請通知 RM 退回」），並在 Weekly Review 時 RM 手動審計。這是「軟機制，靠人工紀律」的最佳實踐。PR Template 的確認欄位是更靠近強制的設計，但作用在 PR 合併節點，而非 Issue 狀態轉移節點。

張力二：Feature Freeze 的執行模式——「保守化討論型」vs「Duolingo 自動型」

整合裁決：採納 Industry RM Expert 的精確化建議，設定「第 3 次掉車起自動執行」為退出條件，並在 Month 2 Sprint Review 確認前 2 次掉車執行後團隊是否已接受這個文化，作為退出確認點。統整初稿 V1 的「第 3-5 次後評估」改為「第 3 次起自動執行，除非 Month 2 Sprint Review 中明確決定延長保守期」。

張力三：掉車 Label 的命名方式

整合裁決：採納 Linear Expert 的建議。[Dropped from vX.X.X] 的 Label 命名方式長期會累積大量只用一次的 Label，違背 Label 管理的可持續性。改為通用 [Dropped] Label + Issue Comment 記錄（「掉車自 v5.8.0，預計列入 v5.9.0」）。

張力四：QA 批次窗口的固定時間 vs 彈性排程

整合裁決：這兩個建議是互補的而非衝突的。「待測 Queue」視圖（Linear 技術層面）讓 QA 有可見的工作清單；「固定批次窗口」（工作節奏層面）提供 QA 安排工作的結構。統整初稿 V2 同時採用兩者：QA 建立 Linear 視圖（Issues 狀態為 Ready for Test 的 Queue），在固定窗口（週二 + 週四下午）集中處理，緊急情況需 RM 批准優先插入。窗口時間可由 Fei Chen 和 Jimmy 根據實際工作節奏調整，不硬性規定週二週四。

二、V2 vs 統整初稿（V1 版）的主要升級點

2.1 機制修正（技術可行性修復）

這些是統整初稿 V1 中存在技術不可行問題的機制，V2 必須修正。

修正一：Automation 5 降級方案

修正二：Feature Freeze 48 小時提醒替代方案

修正三：States 命名優化

修正四：Waiting for Translation 的 State 定位

修正五：Milestone 自動完成降級

2.2 新增機制（三版都沒有的）

這些是三個版本的共同盲點，V2 作為主要新增內容。

新增一：Hotfix SOP 完整設計

三個版本均缺少 Hotfix 流程。V2 必須新增，設計要點：

新增二：QA 批次窗口機制

個別 Issue 觸發（繼承 V1）+ 批次窗口處理（V2 新增），具體設計：

新增三：Hotfix 後的 Monitoring 狀態設計

Issue 發布後的監控期在 V1 提及但未設計，V2 補充：

新增四：成熟度中間步驟（Level 3.5 過渡）

在月度路線圖中明確加入：

新增五：Release Notes 撰寫 SOP

三個版本均未設計 Release Notes 流程，V2 補充：

新增六：Beta 用戶群結構

三個版本均提及 50-200 人 TestFlight Beta 群但未設計，V2 補充框架：

2.3 既有機制的強化

這些機制在統整初稿 V1 已有，但需要在 V2 中加入更精確的設計。

強化一：掉車 SOP 的退出保守模式條件

強化二：Testing Notes 四觸發點的執行保障

強化三：監控責任分層

強化四：Phased Release 啟用確認

三、各文件（00-11 + 版本迭代紀錄）的整合指引

00-導入計劃總覽

V2 版應新增的內容：

  1. 在「主要風險表」中新增：Hotfix 流程缺失（可能性：低；影響：高；因應策略：見 Hotfix SOP，月 1 完成設計）
  2. 在「3 個月時程快覽」中調整 Month 1 末加入 String Freeze 試水（Level 3.5 轉型標記）
  3. 在「8 大導入原則」中，原則六「列車不等人」下方補充：「緊急情況下有 Hotfix 超車道，但觸發條件嚴格。Hotfix 不是繞過流程，而是有設計的例外通道。」
  4. 成熟度定位表格新增一行：「Level 3.5 ｜String Freeze 試行 ｜ Month 1 末目標」

應修改的內容：

  1. 「雙向強制」改為「三方確認機制（PO + RD + QA）」
  2. Feature Freeze 機制的描述，補充退出保守模式的明確條件（第 3 次起自動執行）
  3. 刪除「Automation 5 智慧偵測」的描述，改為「Automation 5 無條件提醒」

刪除或降級的內容：

01-現有流程深度分析

V2 版應新增的內容：

  1. Hotfix 節點（節點 14）：在 13 個節點流程後，新增 Hotfix 作為「緊急超車道」的描述——觸發條件、執行步驟、與正常流程的互動關係（Hotfix 不打斷正常 Cycle，而是在正常 Cycle 外獨立執行）
  2. QA 批次窗口節點設計：在節點 6（Testing）中補充「QA 等待池 + 批次窗口」的流程設計
  3. 回歸測試責任設計：補充「新 ALPHA 版本發出時，QA 判斷是否需要對已通過的 Issue 進行回歸測試」的決策流程（參考 PR Impact Scope 欄位）

應修改的內容：

  1. 節點 5（Ready for Test）：補充 QA 等待池設計，說明「個別觸發進入等待池，批次窗口集中處理」
  2. 節點 8（Ready for Fix）：回測計數機制改為「QA 標準化 Comment 格式（[回測 N] 問題描述）」，而非依賴 David 手動統計
  3. 節點 9（Ready for Release Build）：AND Gate 觸發條件改為「QA Passed + Translation Confirmed Label（而非 Waiting for Translation State）同時存在」

關鍵設計決定：

02-Linear 功能對應分析

V2 版應新增的內容：

  1. Linear 功能限制完整清單（基於 Linear Expert 的分析）：
    • Automation 無法讀取 Description 內容
    • Automation 無法基於 Milestone 日期觸發
    • Automation 的 Action 無法完成 Milestone
    • 沒有條件式 Status 轉換（類似 Jira Workflow）
    • Issue 只能屬於一個 Project
    • 沒有原生 QA 產能管理功能
    • TestFlight 無原生 Webhook 推送
  2. Automation 降級清單：明確標注哪些 Automation 有設計意圖和實際實現的差異

應修改的內容：

  1. Automation 5 描述：從「智慧偵測 Description 內容」改為「無條件提醒，PO / RD 自行確認」
  2. Feature Freeze 提醒：從「Linear Automation 觸發」改為「n8n 定時任務 / 方案 A-C 說明」
  3. First ALPHA Milestone：從「Automation 自動完成」改為「Automation 發 Slack 提醒 + RM 手動點完成」
  4. 「雙向強制」描述：改為「三方確認軟機制」，明確說明工具層面無法強制
  5. State 命名：評估並採納 States 優化建議（Ready for Release Build → Packaging）
  6. Re-test Label Automation：觸發邏輯改為「Issue 狀態改為 Ready for Fix + 已有 Re-test-2 Label」

刪除的內容：

03-三個月導入路線圖

這是 V2 改動最大的文件，月度計劃需要調整以反映新增機制和成熟度路徑。

Month 1（調整）：

Month 2（調整）：

Month 3（調整）：

新增子計劃：

04-環境建置指南

V2 版應新增的內容：

  1. Hotfix SOP 的 Label 設定：[Hotfix] Label（如未存在）、確認 [Priority: Urgent] Label 設定
  2. branchPattern 驗收測試：明確標注為「所有 Automation 的前提條件」，設定後立即執行驗收測試（測試 PR → staging/* → 確認 Issue 狀態自動改變），這個測試必須通過才能繼續後續設定
  3. Label 前綴命名規範（43 個 Label 的管理方案）：
    • [Platform]：iOS / Android / Server / Web / CN
    • [Status]：At Risk / Dropped / Hotfix
    • [QA]：E2E / Integration / Re-test-1/2/3
    • [Translation]：Needs Translation / Translation Confirmed
    • [Priority]：Urgent
  4. QA Dashboard 視圖設定：Team 層級 View 設定步驟，Filter 條件說明

應修改的內容：

  1. Waiting for Translation State 設定 → 改為 Needs Translation Label 設定
  2. Automation 5 的設定步驟：移除「Description 內容判斷」的說明，改為「無條件提醒」設定
  3. Re-test Automation 觸發邏輯更新（改為 Ready for Fix + Re-test-2 Label 觸發）
  4. Dropped Label 命名：從版本特定改為通用 [Dropped] Label

執行順序重要提示（給 Orchestrator）：

05-團隊導入策略

V2 版應新增的內容：

  1. Hotfix SOP 文化說明：Hotfix 是例外通道，不是常規流程。使用頻率過高（月 > 2 次）是需要改善測試流程的信號，而非調整 Hotfix SOP。
  2. QA 批次窗口的文化設計：
    • 說明窗口設計的目的（保護 QA 的認知資源，而非限制工作彈性）
    • 如何向 RD 說明「我的功能 Ready for Test 後為什麼不立刻被測試」（培訓素材）
  3. String Freeze 文化說明：String Freeze 的違反成本說明（翻譯品質下降 + MKT 準備時間縮短），以及如何在第一次 String Freeze 時建立「截止點是認真的」的文化印象
  4. 測試工具遷移的 Buffer 期設計：
    • Month 1-2：Slack 和 Linear 都可以討論 Bug
    • Month 3 起：所有 Bug 的正式記錄只在 Linear Issue Comment（Slack 仍可討論，但結論必須歸檔到 Linear）
    • 這個清晰的「截止點」讓團隊有心理準備

應修改的內容：

  1. 掉車 SOP 文化設計：加入「第一次掉車後的 Retrospective 議程設計」（讓掉車成為品質文化的成功案例而非負面事件）
  2. Testing Notes 的「雙向強制」描述改為「三方確認機制」，明確說明依賴人工紀律
  3. 工具遷移的阻力分析：加入「情感層面的阻力（我已經知道怎麼在 Slack 找東西，但在 Linear 我還不知道）比技術層面的阻力更難克服」的說明

06-角色視角指南

V2 版應新增的內容：

RM（Sherridy）視角新增：

QA（Fei Chen + Jimmy）視角新增：

RD 視角新增：

Shawn 視角新增：

07-功能案例走查

V2 版應新增的內容：

  1. 在既有案例（任務提醒通知設定）中，加入一個「Hotfix 觸發場景」的延伸案例：假設該功能發布後 Firebase Alert 觸發，走 Hotfix 超車道的完整操作流程
  2. QA 批次窗口的視覺化說明：在 Ready for Test 節點的操作演示中，加入「Issue 進入 QA 等待池 → 下個批次窗口集中處理」的說明
  3. 「掉車」場景在案例中的演示：功能開發途中進度落後，RM 觸發掉車 SOP 的完整操作流程

應修改的內容：

08-現況評估與下一步

V2 版應新增的內容：

  1. Hotfix 缺口評估：目前缺少 Hotfix SOP，風險等級：高。下一步：Month 1 完成設計。
  2. Firebase Crashlytics Alert 設定狀態：確認是否已設定 Alert 規則，若未設定，Month 1 末前完成。
  3. Phased Release 啟用狀態確認：記錄 iOS Phased Release 和 Android Staged Rollout 的實際啟用狀態。

應修改的內容：

09-業界基準研究總覽

V2 版應新增的內容：

  1. Hotfix 業界對標：
    • Duolingo：App Store Expedited Review + 嚴格觸發條件
    • Todoist：Fastlane Hotfix Lane
    • Headspace：CodePush（React Native，Forest App 不適用）
  2. QA 批次窗口業界對標：Todoist 的三個工作天非同步 QA 回饋窗口的具體設計
  3. Beta 用戶群業界對標：Duolingo 的應用程式內招募、Todoist 的重度用戶 TestFlight 群
  4. Release Notes 業界對標：Duolingo 和 Headspace 的 Release Notes 策略（作為品質信號的角色）

應修改的內容：

版本迭代紀錄 V2

應記錄的新增演化歷程：

統整初稿 → 統整初稿 V2 的核心升級，記錄以下主題：

  1. Automation 技術可行性修正：三條 Automation 降級（Automation 5 無條件提醒、Feature Freeze 提醒改 n8n、Milestone 完成半自動化）
  2. Hotfix SOP 補完：三版共同盲點，V2 首次完整設計
  3. QA 批次窗口機制：個別觸發原則 + 批次處理節奏，解決 Fei Chen + Jimmy 切換成本問題
  4. 成熟度中間步驟：Level 3.5（String Freeze 先行）插入 Month 1 末
  5. Release Notes 流程明確化：首次設計撰寫 SOP 和責任人
  6. 掉車退出保守模式條件明確化：「第 3 次起自動執行」取代「第 3-5 次後評估」
  7. 「雙向強制」改稱「三方確認機制」：工具現實的誠實描述
  8. States 精簡：Waiting for Translation 從 State 改為 Label
  9. Label 前綴規範化：43 個 Label 的可持續管理方案

四、統整初稿 V2 的核心設計原則（給 Orchestrator）

以下原則是在整合三位 Agent 發現後，整合者認為 V2 應遵循的設計哲學。每個文件撰寫時應以這些原則作為取捨依據。

原則一：工具能力的誠實呈現

V2 在所有描述 Automation 和工具機制的地方，必須清楚區分「設計意圖」和「實際實現方式」。不能讓讀者誤以為工具本身會阻擋不合規的操作。每個「強制」機制都要標注它實際上依賴什麼（工具強制 vs 人工紀律 vs 兩者結合）。

應用：「雙向強制」改稱「三方確認機制（軟機制，靠人工紀律）」；Automation 5 標注為「無條件提醒，非智慧偵測」；Feature Freeze 提醒標注為「需 n8n 或 Calendar Alert」。

原則二：覆蓋緊急情況的設計完整性

V2 必須設計 Hotfix 超車道。一個只有正常流程、沒有緊急通道的系統，在第一次真實緊急情況下必然失控。Hotfix SOP 不是可選項，是 Release Train 文化的必要安全閥。

應用：Hotfix SOP 寫入多個文件（05、06、03），觸發條件和授權人明確定義。

原則三：人的認知資源是設計約束

設計機制時，必須考慮「這個機制的執行者在高壓時期的認知資源是否能支撐？」。QA 的切換成本、RD 的 Testing Notes 補充習慣、RM 的掃描工作量——這些人的限制都需要在設計中有應對方案，而非假設人的行為是理想化的。

應用：QA 批次窗口機制（降低切換成本）；PR Template 確認欄位（降低 RD 記憶負擔）；Feature Freeze 提醒自動化（降低 RM 手動追蹤）。

原則四：業界實踐的代價誠實說明

每次引用業界做法，必須同時說明「代價」和「Forest App 版的代價降低設計」。Duolingo 的 Feature Freeze 在第一次執行時引發了文化衝突；Todoist 的強制文件化是遠端文化的前提。這些代價不是缺點，而是讓讀者知道「這不是免費的，我們已經設計了降低代價的方式」。

應用：String Freeze 作為 Level 3.5（代價最小的文化試水）；掉車去污名化 Retrospective（降低掉車的情緒成本）。

原則五：機制的退出條件必須明確

任何設計為「過渡期」的機制，都必須有明確的退出條件，而非模糊的「之後評估」。沒有退出條件的過渡期設計往往成為永久設計。

應用：保守模式掉車→「第 3 次起自動執行，Month 2 Sprint Review 確認」；Buffer 期工具遷移→「Month 3 起 Bug 正式記錄只在 Linear」。

原則六：分層設計，各層責任清晰

當一個機制需要多個層次（自動化 + 人工確認 + 人工備援），每層的責任人和觸發條件必須明確，不能有「誰都可以做」或「誰都不確定自己要做」的模糊地帶。

應用：Crash Rate 監控三層設計（Firebase Alert 自動 → Shawn 主責 → David 備援）；掉車 SOP（RM 識別 → RM + PO 確認 → RM 執行 → RM 公告）。

五、Orchestrator 的執行優先順序

第一優先：影響架構的決策（必須先確定，其他文件基於此）

  1. State 精簡決定：Waiting for Translation 改為 Label（影響 02、04、所有提到 State 的文件）。在開始撰寫任何文件前，確認這個決定，並在 02-Linear 功能對應分析中先確認完整 State 清單。

  2. Automation 5 降級決定：無條件提醒（影響 01、02、04、06、07 所有提到 Automation 5 的描述）。確認這個決定後，全文件統一描述。

  3. Hotfix SOP 設計決定：在 05-團隊導入策略和 06-角色視角指南撰寫前，先確定 Hotfix SOP 的觸發條件、授權人、執行步驟（可以寫在附錄或在 Orchestrator 的設計草稿中確認）。

  4. Feature Freeze 提醒替代方案選擇：確認使用方案 A（n8n）/ B（Calendar）/ C（手動），影響 03、04 的描述。

第二優先：各文件的特殊指引

  1. 03-三個月導入路線圖：這個文件需要反映最多 V2 新增內容（QA 批次窗口、Hotfix SOP、String Freeze Level 3.5、Firebase Alert 前移），建議在架構決定（優先順序 1-4）確認後再撰寫。

  2. 06-角色視角指南：這個文件的 QA、RD、Shawn 三個視角都有 V2 新增內容，且 QA 視角的批次窗口設計需要與 03 的路線圖一致。建議在 03 完成後撰寫。

  3. 09-業界基準研究總覽：這個文件主要是資訊補充（Hotfix 業界對標、Beta 用戶群對標），但要注意「業界實踐代價」的誠實說明（V2 核心原則四）。

  4. 版本迭代紀錄 V2：這個文件在所有其他文件完成後再撰寫，確保記錄的是最終版本的演化歷程，而非草稿版本的。

第三優先：跨文件的一致性要求

  1. 術語統一：全文件中「雙向強制」改為「三方確認機制」。建議在 Orchestrator 完成所有文件草稿後，做一次全文搜尋確認。

  2. Automation 編號一致：統整初稿 V1 的 12 條 Automation 在 V2 中編號和描述要保持一致（除了 Automation 5 的降級說明）。如果 State 精簡導致 Automation 8、9 的觸發邏輯改變，在 02 和 04 中同步更新。

  3. 月度時程一致性：三個文件（00、03、08）都有月度時程的描述，V2 中這三個地方必須完全一致（包括 String Freeze Level 3.5 的 Month 1 末標記、Firebase Alert 前移至 Month 1 末）。

  4. 成熟度路徑一致性：Level 3.5 的加入影響 00（成熟度定位表格）和 09（業界基準研究）的描述，兩個文件的成熟度路徑說明必須一致。

附錄：整合後的完整 Automation 清單（修正版）

以下是統整初稿 V1 的 12 條 Automation，加入 V2 的技術可行性標注和修正說明。

#Automation 名稱TriggerAction技術可行性V2 修正
1iOS Ready for Test 通知Issue 狀態改為 Ready for Test + Label iOSSlack 訊息完全可行無修正
2Android Ready for Test 通知Issue 狀態改為 Ready for Test + Label AndroidSlack 訊息完全可行無修正
3Server/Web Ready for Test 通知Issue 狀態改為 Ready for Test + Label Server/WebSlack 訊息完全可行無修正
4Released 時間戳 + DORA 記錄Issue 狀態改為 ReleasedComment + Webhook部分可行：Comment 原生可行；DORA Webhook 需 n8n 接收端在文件中明確說明 DORA 部分需 n8n
5Testing Notes 缺失提醒Issue 狀態改為 In DevelopmentComment 提醒降級：無法判斷 Description 是否為空改為無條件提醒；Label [Testing-Notes-Missing] 改為手動加
6Ready for Test 個別確認 CommentIssue 狀態改為 Ready for TestComment（@QA）提醒讀取 Testing Notes完全可行無修正
7Ready for Fix 通知 RM + RDIssue 狀態改為 Ready for FixSlack 訊息完全可行無修正
8翻譯 Gate（需翻譯）狀態改為 QA Passed + Label Needs Translation（原：Waiting for Translation State）改狀態（加翻譯等待標記）+ Slack完全可行（Trigger 邏輯調整）Trigger 從「State 改為 Waiting for Translation」改為「State = QA Passed + Label Needs Translation 新增」
9翻譯 Gate（翻譯完成）狀態改為 QA Passed + Label Translation Confirmed改狀態（進入 Ready for Release Build 流程）完全可行無修正
10Stale Issue 提醒In Development 超過 7 天無 CommentSlack DM完全可行無修正
11Cycle 結束前警告距 Cycle 結束 N 天Slack 警告不可行：無此 Trigger降級：n8n 定時任務（方案 A）或 RM 手動掃描（方案 C）
12回測三次通知Label 新增 Re-test-2 + Issue 狀態改為 Ready for FixSlack 訊息完全可行（Trigger 邏輯優化）Trigger 從「Label Re-test-3 新增（依賴移除再加回）」改為「狀態改為 Ready for Fix + 已有 Re-test-2 Label」，更健壯

附加說明（非 12 條清單內，但需要在文件中說明的自動化設計）：

項目說明可行性替代方案
Feature Freeze 48 小時提醒距 Milestone 日期 2 天觸發 Slack 警告不可行（無 Milestone 日期 Trigger）n8n Cron Job（方案 A）/ Calendar + 手動（方案 B）/ 純手動（方案 C）
First ALPHA Milestone 自動完成Android Ready for Test 時自動標記 Milestone 完成不可行（Automation Action 不包含 Milestone 完成）Automation 發 Slack 提醒 + RM 手動點完成（半自動）
GitHub branchPattern 設定staging/* → Ready for Test，main/* → Release需要 GitHub Integration 設定在環境建置指南中列為 P0 必備，驗收測試必須通過後再繼續
TestFlight iOS WebhookTestFlight 上傳成功 → Linear 狀態更新部分可行（依 CI/CD 基礎設施）Month 3 評估：若 iOS 有 Fastlane / GitHub Actions → CI 完成後發 Webhook；若手動上傳 → 不可行，改用方案 B（API 輪詢）

附錄二：V2 與統整初稿 V1 的主要差異對照表

面向統整初稿 V1統整初稿 V2
Hotfix 流程無新增完整 Hotfix SOP（觸發條件、授權人、執行步驟）
QA 工作節奏個別 Issue 觸發，無批次設計個別觸發 + QA 等待池 + 批次窗口機制
成熟度路徑Level 3 → Level 5（直接）Level 3 → Level 3.5（String Freeze）→ Level 4 → Level 5
Testing Notes 機制雙向強制（PO + QA）三方確認機制（PO + RD + QA），PR Template 加入確認欄位
Feature Freeze 保守模式第 3-5 次後評估自動化（模糊）第 3 次起自動執行（明確），Month 2 Sprint Review 確認
Automation 5智慧偵測 Description 是否為空無條件提醒（技術降級）
Feature Freeze 提醒Linear Automation 觸發（不可行）n8n 定時任務 / Calendar / 手動（三選一）
States 數量12 個（含 Waiting for Translation）11 個（Waiting for Translation 改為 Label）
Dropped Label[Dropped from vX.X.X]（版本特定）[Dropped] 通用 + Comment 記錄版本（可持續管理）
Re-test AutomationLabel Re-test-3 移除再加回（邊緣行為）狀態 Ready for Fix + Label Re-test-2（更健壯）
Release Notes無設計新增撰寫 SOP（Shawn + PD，Feature Freeze 後完成）
Beta 用戶群提及但無設計新增結構化設計（招募、管理、回報、輪換）
Phased Release 確認假設已啟用Month 1 Week 1 確認清單項目
Firebase AlertMonth 3 引入前移至 Month 1 末（配置成本低，保護價值高）
機制誠實描述部分機制描述未區分意圖和實現每個機制明確標注：工具強制 vs 人工紀律

本文件由 Integration Expert（Sub-Agent 3）產出，供 Orchestrator 在撰寫統整初稿 V2 的 11 個文件時使用。 輸入依據：Release Tracker Expert 分析 + Linear Expert 分析 + Industry RM Expert 分析 + 統整初稿 V1 全文件 文件日期：2026-02-19

工作文件 integration-expert 整合決策 統整初稿-v2 orchestrator-input