環境建置指南（統整版V2）

統整說明：本文件整合 V1 基礎建置與 V3 消費者 App 特有建置項目，並在 Integration Expert 整合決策的基礎上進行技術修正。V2 的核心升級是「技術誠實性」——每個 Automation 都明確標注實際可行性，避免讀者誤以為工具本身會強制執行某些行為。

重要閱讀順序：branchPattern 設定（Step 6）必須在所有 Automation 設定之前完成，並通過驗收測試。

適用對象：RM（Sherridy）作為 Linear 管理員，依序執行各步驟。

相關文件：03-三個月導入路線圖（統整版V2） | 05-團隊導入策略（統整版V2）

技術可行性標注說明

本文件所有 Automation 和機制均使用以下標注：

• ✅ Linear 原生：可在 Linear 設定介面直接完成，無需外部工具
• ⚠️ 需外部工具：需要 n8n / Google Calendar / GitHub Action 等外部工具
• 📋 靠人工紀律：工具無法強制，依賴團隊的操作習慣
• 🔄 半自動：工具發通知提醒，人工執行最後動作

這個標注的目的：讓所有人清楚「哪些機制是工具會自動執行的，哪些是需要人去做的」。

現況快照（V2，2026-02-19）

建置前置準備

預估總時間：

• Step 1-9（基礎建置）：8-10 小時，建議分三天完成
• Step 10-16（進階建置）：5-7 小時，M1 末前完成

需要的存取權限：

• Linear 管理員帳號
• GitHub Organization 管理員權限（或請 RD 協助）
• Slack workspace 管理員權限
• Firebase 專案讀取 + Alert 設定權限（Step 13 需要）
• App Store Connect 帳號（Step 13 iOS 相關評估需要）
• Google Calendar（Step 14 Feature Freeze 提醒設定）

Step 1：Workspace 與 Team 設定（已完成）

現況：seekrlab workspace + Release Tracker Team（Identifier：REL）已建立。

確認事項：

• Team Identifier：REL（所有 Issue ID 為 REL-1, REL-2...）
• Team 名稱：Release Tracker
• 描述：Forest App Release Management

若需要修改：Settings → Teams → Release Tracker → Edit

Step 2：Workflow States（11 個，V2 精簡版）

路徑：Settings → Teams → Release Tracker → Workflow

V2 完整 11 個 States 設定清單

重要 V2 變更：Waiting for Translation 從 State 改為 Label 組合

V1 設計將 Waiting for Translation 作為獨立 State，造成兩個問題：

1. 只有有翻譯需求的功能才有意義，在全體 Issue 的選擇器中出現造成噪音
2. State 數量累積，視覺相似度高（Ready for... 前綴出現 4 次）

V2 修正：Waiting for Translation 改為 QA Passed 狀態 + [Needs Translation] Label 的組合

命名優化說明（升級版 vs 原版對照）

執行建議：如果 Orchestrator 評估改名溝通成本過高，可保留 Ready for Release Build / Ready for Release 原名，改用顏色和分組提高區別性。Packaging / Pending Release 是建議的升級方向，不是強制要求。

Waiting for Others State 設定步驟（M2 執行）

操作路徑：
  Settings → Teams → Release Tracker → Workflow → Add State

填寫：
  名稱：Waiting for Others
  類型：Started（注意：不是 Completed！）
  顏色：#A78BFA（淡紫，區別於其他 Started 狀態）
  排序：拖曳到「QA Passed」之後，「Packaging」之前

說明設定（建議填在 State Description）：
  「此功能已通過 QA 測試，等待同版本其他 Issue 完成後
   一起進入 Packaging 階段。RM 不需要做任何額外操作。」

Step 3：Labels 設定（V2 完整版，含前綴規範）

路徑：Settings → Teams → Release Tracker → Labels

Label 前綴命名規範（V2 新增）

V2 為 Labels 制定前綴命名規範，解決大量 Label 難以管理的問題：

完整 Labels 清單

平台 Labels（已建立）：

iOS                顏色：#007AFF
Android            顏色：#3DDC84
Server             顏色：#FF6B35
Web                顏色：#FF6B35
CN                 顏色：#FF0000（中國區）

狀態輔助 Labels（V2 版）：

At Risk            顏色：#F97316（橙）— 掉車風險
Dropped            顏色：#6B7280（灰）— 掉車確認（通用，V2 改為單一 Label）
Post-Freeze Exception 顏色：#DC2626（深紅）— Freeze 後特例

注意（V2 修正）：
  V1 使用 [Dropped from vX.X.X]，每個版本建一個 Label
  V2 改為通用 [Dropped] Label + Issue Comment 記錄版本號
  理由：版本特定 Label 長期累積大量單次使用 Label，難以管理

V3 追蹤 Labels（確認或新增）：

[Testing-Notes-Missing]  顏色：#EF4444（紅）— 測試注意事項未填（RM 手動加）
[ALPHA-Verified]         顏色：#10B981（綠）— Android ALPHA 驗證通過
[Crash-Gate-Hold]        顏色：#F97316（橙）— Crash Rate 觸發暫停

翻譯 Labels（V2 新增，取代 Waiting for Translation State）：

Needs Translation        顏色：#FCD34D（黃）— 功能有翻譯需求
Translation Confirmed    顏色：#22C55E（綠）— 翻譯確認完成

Hotfix Labels（V2 新增）：

[Hotfix]    顏色：#DC2626（深紅）— 緊急修復，自動觸發 Hotfix Automation

QA / 回測 Labels：

Re-test-1   顏色：#FCD34D（淡黃）
Re-test-2   顏色：#F97316（橙）
Re-test-3   顏色：#EF4444（紅）— 三次觸發 PM 通知
[E2E]       顏色：#6366F1（靛藍）— Fei Chen 主導 E2E 測試 Sub-issue
[Integration] 顏色：#3B82F6（藍）— Jimmy 主導整合測試 Sub-issue

Priority Labels：

[Priority: Urgent]  顏色：#DC2626（深紅）— 緊急插隊（Hotfix Automation 自動設定）

Step 4：Issue Templates V3

路徑：Settings → Teams → Release Tracker → Templates → New Template

Template 1：新功能規劃（PO 使用）

Template 名稱：新功能規劃 V3

---

## 功能描述
（2-3 句話說明這個功能做什麼，用戶能獲得什麼價值）

## 為什麼做（Why）
（這個功能解決什麼問題？為什麼現在做？）

## 測試注意事項（Testing Notes）
> ⚠️ PO 在 Planning 必須填寫初始版本。
> RD 在開發中補充技術細節。QA 在展測項和 Testing 時都需要讀取。
> （三方確認機制：PO 初始填寫 + RD 開發中補充 + QA 雙重讀取）

**重點觀測項目**（PO 填寫，Planning 必填）：
-
-

**技術邊界**（RD 在 In Development 補充）：
- （開發中補充）

**平台差異**（RD 在 In Development 補充）：
- iOS：
- Android：

**已知限制**（不需要當 Bug 回報的情況）：
- （如有請補充）

## 技術資訊
- 平台：[ ] iOS  [ ] Android  [ ] Server  [ ] Web
- Figma 連結：
- 埋點列表：
- API 文件：
- 相關 Issue：

## 預估工時
- RD 開發估算：
- QA 測試估算：

Template 2：QA 測項（Sub-issue 使用）

Template 名稱：QA 測項 V3

---

## 測試情境
（這個測項要驗證什麼使用情境？）

## 測試類型
- [ ] [E2E] 端對端測試（Fei Chen 主導）
- [ ] [Integration] 整合測試（Jimmy 主導）
- [ ] 手動功能驗證

## 來源
- [ ] 來自測試注意事項（請標注：「依據 Testing Notes：[引用內容]」）
- [ ] 來自 Figma 規格

## 前置條件
（測試前需要準備什麼帳號、資料或環境設定？）

## 測試步驟
1.
2.
3.

## 預期結果
（正確行為應該是什麼？）

## 測試結果
- [ ] ✅ 通過
- [ ] ❌ 失敗（請在 Comment 附上截圖和問題描述）

## 測試環境
- 平台：[ ] iOS（TestFlight Build #）  [ ] Android（版本含 -ALPHA）
- 裝置型號：
- 系統版本：

## PR Impact Scope（RD 填寫，供 QA 決定回歸範圍）
（這個 PR 影響哪些模組？哪些功能可能受影響需要回歸測試？）

Template 3：Bug 修復（Ready for Fix 時使用）

Template 名稱：Bug 修復 V3

---

## 問題描述
（Bug 是什麼？怎麼出現的？）

## 重現步驟
1.
2.
3.

## 預期行為 vs 實際行為
- 預期：
- 實際：

## 嚴重程度
- [ ] P0：Crash / 無法使用核心功能（需立即修復）
- [ ] P1：功能異常但有 Workaround
- [ ] P2：體驗問題或小 Bug

## 影響範圍
- 平台：[ ] iOS  [ ] Android  [ ] Server  [ ] Web
- 受影響用戶比例估計：

## 截圖 / 影片
（請附上）

## 回測計數
（QA 在每次回測時補充：「[回測 N] [問題描述]」）

## 根本原因（RD 修復完成後填寫）
（為什麼會發生這個 Bug？）

## 預防措施
（這個 Bug 如何防止再次發生？）

## Crash Rate 相關
- [ ] 此 Bug 有導致 Crash Rate 異常（請附 Crashlytics 截圖）
- [ ] 此 Bug 為發布後 Crash Gate 觸發的原因

Template 4：Hotfix Issue（新增，緊急情況使用）

Template 名稱：Hotfix Issue V2

---

## 觸發條件確認
- [ ] **PO（David 或 Ezou）已判定為 P0 Bug 並授權啟動 Hotfix**

PO 判定時的主要參考指標（任一可作為參考，但最終由 PO 決定）：
- Crash-free session rate 低於正常基線（Month 1-2 參考閾值 < 98.5%；Month 3+ 參考閾值 < 99.0%）
- 核心功能（計時器/種樹）完全無法使用
- 安全漏洞影響用戶數據
- App Store 差評突增（24 小時內下降超過 0.3 分）

## MTTR 計時
- Firebase Alert 時間戳：
- （此時間戳為 MTTR 計算起點）

## 問題描述
（緊急問題是什麼？受影響功能和平台？）

## 影響範圍估計
（受影響用戶比例？可能的原因？）

## 修復方案
（RD 填寫修復思路）

## 測試範圍
（QA 快速回歸測試範圍：核心功能 + Hotfix 相關功能）

## 短期緩解措施
- [ ] Server-side Kill Switch 已啟用（如有 Feature Flag）
- [ ] 暫停 Phased Release（Android / iOS）
- [ ] 無需額外緩解措施

## 發版計劃
- 版本號：（如 v5.8.1）
- 類型：[ ] Patch Release  [ ] Minor Release
- Android 預計審核時間：（通常 2-4 小時）
- iOS 預計審核時間：（通常 24-48 小時；緊急審核可能縮短至數小時）

## MTTR 記錄（發版後填寫）
- App Store 發版時間戳：
- 總 MTTR：（從 Firebase Alert 到 App Store 發版）

Step 5：Automation 完整設定（V2 版，含技術可行性標注）

路徑：Settings → Teams → Release Tracker → Automation → Add Rule

Automation 技術可行性總覽

P0 Automation（第一個版本前必須完成）

Automation 1：iOS Ready for Test 通知

可行性：✅ Linear 原生

When:  Issue status changed to "Ready for Test"
And:   Issue label includes "iOS"
Then:  Send Slack message to <span class="tag">forest_ios_testcenter</span>

訊息內容：
  📱 iOS 測試通知
  功能：{issue.title}
  版本：{issue.project.name}
  Linear：{issue.url}
  @qa-team 請確認 Testing Notes 後開始測試（下個批次視窗處理）

設定注意事項：

1. Then 選「Post a message in Slack」
2. 選擇 Channel：#forest_ios_testcenter
3. 使用 Linear Template Variables：{issue.title} / {issue.project.name} / {issue.url}

Automation 2：Android Ready for Test 通知

可行性：✅ Linear 原生

When:  Issue status changed to "Ready for Test"
And:   Issue label includes "Android"
Then:  Send Slack message to <span class="tag">forest_android_testcenter</span>

訊息內容：
  🤖 Android 測試通知
  功能：{issue.title}
  版本：{issue.project.name}
  Android 請確認版本號含 -ALPHA
  Linear：{issue.url}
  @qa-team 請確認 Testing Notes 後開始測試（下個批次視窗處理）

Automation 3：Server/Web Ready for Test 通知

可行性：✅ Linear 原生

When:  Issue status changed to "Ready for Test"
And:   Issue label includes "Server" OR "Web"
Then:  Send Slack message to <span class="tag">forest_serverweb_testcenter</span>

（訊息格式同上，平台改為 Server/Web）

Automation 4：Released 時間戳記錄

可行性：✅ Comment 原生；⚠️ DORA 部分需 n8n

When:  Issue status changed to "Released"
Then:
  Action 1: Add comment to issue
    內容：「Released at {date.now}（自動記錄，用於 DORA Dashboard）」
  Action 2: Trigger webhook（URL：n8n 的 DORA webhook endpoint）
    Payload：{issue.id, issue.title, issue.project.name, date.now}

注意：Action 2（DORA Webhook）需要 n8n 接收端設定，屬於 P2 任務。
     M1 階段先只設定 Action 1（Comment），待 n8n 設定完成後加入 Action 2。

P1 Automation（Month 1 完成）

Automation 5：Testing Notes 提醒（降級版）

可行性：✅（降級後可行）

降級原因：Linear Automation 無法讀取 Description 內容，
         因此無法判斷 Testing Notes 欄位是否為空。

V1 設計意圖：
  When: Issue 狀態改為 In Development
  And:  Description 中 Testing Notes 區塊為空（技術上不可行）
  Then: 加 Label + 發 Comment

V2 降級設計：
  When: Issue status changed to "In Development"
  And:  （無條件觸發，移除內容判斷條件）
  Then: Add comment to issue

Comment 內容：
  「⚠️ 測試注意事項確認提醒
   PO / RD：此 Issue 的測試注意事項是否已填寫？

   PO 請確認：「重點觀測項目」欄位是否已有初始版本？
   RD 請確認：開發中是否有新的技術邊界或平台差異需要補充？

   若已填寫，請忽略此提醒。
   若尚未填寫，請在本次 Planning 完成前補充。

   注意：此為無條件提醒，不代表偵測到欄位為空。」

Label 操作：
  [Testing-Notes-Missing] Label 不再由 Automation 自動加
  改為 RM（Sherridy）在 Weekly Review 時手動標注未填寫的 Issue
  （📋 靠人工紀律）

設計說明：Automation 5 的降級是技術限制下的務實選擇。無條件提醒雖然會對已填寫的 Issue 發出「假警報」，但它的作用是建立習慣意識，讓 RD/PO 在 Issue 進入 In Development 時自動想到「Testing Notes 有沒有填？」。真正的強制點是 PR Template 的確認欄位（見 Step 17）。

Automation 6：Ready for Test 個別確認 Comment

可行性：✅ Linear 原生

When:  Issue status changed to "Ready for Test"
Then:  Add comment to issue：
  「🔔 此 Issue 已 Ready for Test，進入 QA 待測 Queue。

   QA 開始測試前請確認（三方確認機制 — 讀取 Testing Notes）：
   ☐ 已閱讀 Description 中的「測試注意事項」
   ☐ 確認 RD 是否在開發中有補充新的技術細節（技術邊界）
   ☐ 每條 Testing Notes 都有對應的 Sub-issue 測試項目
   ☐ Android：確認版本號含 -ALPHA（例：5.8.0-ALPHA1）
   ☐ iOS：確認 TestFlight Build 已可下載

   ✅ 請在此 Comment 下方回覆「已確認 Testing Notes（[日期]）」後再開始測試。

   批次視窗提醒：此 Issue 將在下個 QA 批次視窗（週二或週四下午）處理。
   如需優先處理，請通知 RM 加上 [Priority: Urgent] Label。」

Automation 7：Ready for Fix 通知 RM + RD

可行性：✅ Linear 原生

When:  Issue status changed to "Ready for Fix"
Then:
  Action 1: Send Slack DM to @sherridy
    訊息：「{issue.title} 測試未通過（Issue：{issue.url}）」

  Action 2: Send Slack message（根據 Label 分流）
    條件 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.title} 測試未通過，需要修復
     詳見 Issue Comments 的 Bug 描述：{issue.url}
     @[對應 RD] 請確認修復時程」

P2 Automation（Month 2 完成）

Automation 8：翻譯 Gate（需要翻譯）

可行性：✅ Linear 原生（Trigger 邏輯調整）

V1 Trigger：Issue 狀態改為 Waiting for Translation State（已廢除）
V2 Trigger：Issue 狀態改為 QA Passed + Label Needs Translation 新增

When:  Issue status changed to "QA Passed"
And:   Issue label includes "Needs Translation"
Then:
  Action 1: Add comment to issue：
    「翻譯確認待辦：此功能已通過 QA，需要多國翻譯確認後才能進入 Packaging 流程。
     MKT 確認後，請 RM 將此 Issue 的 Label 改為 Translation Confirmed。」
  Action 2: Send Slack message to <span class="tag">mkt-translation</span>：
    「@mkt {issue.title} 已通過 QA，請確認多國翻譯文案。
     Linear Issue：{issue.url}
     RM（Sherridy）確認後會更新 Label 為 Translation Confirmed。」

注意：此 Automation 的觸發依賴 Needs Translation Label 的手動添加。
     RM 或 PO 在 Planning 時如判斷功能需要翻譯，需手動加上此 Label。

Automation 9：翻譯 Gate（翻譯已完成）

可行性：✅ Linear 原生

When:  Issue status changed to "QA Passed"
And:   Issue label includes "Translation Confirmed"
Then:  Change issue status to "Packaging"

說明：Translation Confirmed Label 由 RM 手動加，確認 MKT 已完成翻譯確認後觸發此 Automation。

Automation 10：Stale Issue 提醒

可行性：✅ Linear 原生

When:  7 days since last comment AND issue status is "In Development"
Then:  Send Slack DM to issue assignee：
  「👀 {issue.title} 已超過 7 天無更新。
   請確認開發進度是否正常，並在 Issue 新增一條進度 Comment。
   如有阻礙請通知 RM（Sherridy）。」

Automation 11：Feature Freeze / Cycle 結束前警告

可行性：⚠️ Linear 不支援「距 Milestone 日期 N 天」觸發

降級說明：Linear Automation 沒有「距 Milestone 日期 N 天」的 Trigger，
         因此 Feature Freeze 48 小時提醒無法在 Linear 原生實現。

替代方案 A（推薦，Month 3 實施）：n8n 定時查詢
  n8n Cron Job：每天 09:00 查詢 Linear API
  判斷：48 小時內即將到來的 Milestone，且 Milestone 名稱包含「Feature Freeze」
  動作：發 Slack 訊息到 <span class="tag">product-release</span>
  預估設定工時：2-4 小時（一次性）

替代方案 B（Month 1-2，推薦過渡方案）：Google Calendar 手動提醒
  RM 在建立版本 Milestone 時，同步在 Google Calendar 建立提醒事件：
  - 事件名稱：「[版本號] Feature Freeze 前 48 小時提醒」
  - 事件時間：Feature Freeze 日期前 2 天
  - 事件觸發時，RM 手動在 <span class="tag">product-release</span> 發 Freeze 通知

替代方案 C（最輕量備選）：純手動
  RM 在每週一固定掃描本週 Milestone 日期，手動評估是否需要警告

執行決定：
  Month 1-2 使用方案 B（Google Calendar）
  Month 3 評估升級至方案 A（n8n）

在文件中標注：📋 方案 B 靠人工紀律 / ⚠️ 方案 A 需 n8n 設定

Automation 12：回測三次以上通知 PM Channel

可行性：✅ Linear 原生（Trigger 邏輯優化）

V1 Trigger：Label Re-test-3 新增（依賴移除再加回的邊緣行為，不穩健）
V2 Trigger：Issue 狀態改為 Ready for Fix + 已有 Re-test-2 Label（更健壯）

When:  Issue status changed to "Ready for Fix"
And:   Issue label includes "Re-test-2"
Then:  Send Slack message to <span class="tag">forest_release</span>：
  「⚠️ 回測警告：{issue.title} 已進行第三次（或更多）回測。

   Issue：{issue.url}
   目前狀態：Ready for Fix

   @sherridy @shawn 請確認：
   ① 是否需要特別介入協助 RD 修復？
   ② 是否需要調整驗收標準或拆分功能？
   ③ 是否需要將此功能移至下一個版本（掉車）？」

說明：當 Issue 第三次進入 Ready for Fix 時，QA 需已加上 Re-test-2 Label。
     Automation 在下一次狀態改為 Ready for Fix 時觸發（即第三次回到 Ready for Fix）。

新增 Automation（V2 新增）

Automation 13：Hotfix 啟動通知

可行性：✅ Linear 原生

When:  Issue label "Hotfix" added
Then:
  Action 1: Send Slack message to <span class="tag">release-hotfix</span>：
    「🚨 Hotfix 啟動
     Issue：{issue.title}（{issue.url}）
     時間：{date.now}（MTTR 計時開始）
     @david @sherridy @ezou 請確認觸發條件並啟動 Hotfix SOP。」
  Action 2: Set issue priority to "Urgent"

說明：當 PO 判定為 P0 Bug 並授權 Hotfix 後，RM 手動在 Issue 加上 [Hotfix] Label，
     即可觸發此 Automation 同時完成兩個動作：
     1. 通知所有相關人員
     2. 自動設定最高優先級

Step 6：GitHub Integration（branchPattern 設定）

這是所有 Automation 的前提條件，必須最優先執行，並通過驗收測試後才能繼續。

路徑：Settings → Teams → Release Tracker → Automations → Pull request and commit automation

6.1 連接 GitHub

1. Settings → Integrations → GitHub → Enable
2. 選擇 GitHub Organization（Forest 的 GitHub Organization）
3. 選擇所有相關 Repositories：
   • Forest iOS App repo
   • Forest Android App repo
   • Forest Server repo
   • Forest Web repo
4. 點擊 Install

6.2 Branch Rules 設定（V2 版）

Rule 1：開發開始
  Branch pattern: feature/*
  Event: PR opened
  Action: Change issue status to "In Development"

Rule 2（關鍵）：Ready for Test
  Branch pattern: staging/*
  Event: PR merged
  Action: Change issue status to "Ready for Test"
  注意：這條規則讓 staging/* 的合併自動觸發 QA 通知流程

Rule 3：Release
  Branch pattern: main/*
  Event: PR merged
  Action: Change issue status to "Released"

Rule 4（新增，Hotfix）：Hotfix Release
  Branch pattern: hotfix/*
  Event: PR merged
  Action: Change issue status to "Released"
  說明：Hotfix 分支（hotfix/vX.X.X）合併到 main 後，自動標記為 Released

6.3 branchPattern 驗收測試（必須通過才能繼續）

驗收步驟：
  1. 建立測試 Issue（命名：「[測試] branchPattern 驗收」）
  2. 請任一 RD 建立測試 PR，標題包含 Issue ID（如 REL-XXX）
  3. 合併 PR 到 staging/test branch
  4. 確認 Linear Issue 狀態自動改為 Ready for Test

驗收標準（必須全部達到）：
  ✅ PR 合併到 staging/* → Issue 狀態自動改為 Ready for Test
  ✅ Issue URL 在 PR 中正確連結
  ✅ Automation 1/2/3 的 Slack 通知正確發出

如果驗收失敗，不繼續後續 Automation 設定，先排查問題。
常見問題排除：
  - PR 標題未包含 Issue ID → 確認 RD 的 PR 標題格式
  - branchPattern 設定不正確 → 確認「staging/*」而非「staging」
  - GitHub 未正確授權 → 重新執行 Settings → Integrations → GitHub → Reconnect

6.4 Branch 命名規範（V2 新增 Hotfix 分支）

一般功能分支：feature/REL-XXX-功能名稱（如 feature/REL-42-timer-notification）
Hotfix 分支：hotfix/vX.X.X（如 hotfix/v5.8.1）—— 從 main 分支切出
Staging 分支：staging/android-[版本號] / staging/ios-[版本號]

6.5 各 RD 連接個人 GitHub

每位 RD 需要：

1. 前往 Linear 個人設定 → Connected accounts
2. 連接個人 GitHub 帳號
3. 測試：建一個 Test PR，確認 Linear Issue 自動連結

Step 7：Slack Channel Mapping（V2 版，含 release-hotfix）

路徑：Settings → Integrations → Slack

需要加入 Linear Bot 的 Channels

在每個 Channel 中輸入：/invite @linear

P0 必要 Channel：
  <span class="tag">forest_ios_testcenter</span>       — iOS 測試通知（Automation 1）
  <span class="tag">forest_android_testcenter</span>   — Android 測試通知（Automation 2）
  <span class="tag">forest_serverweb_testcenter</span> — Server/Web 測試通知（Automation 3）

P1 重要 Channel：
  <span class="tag">forest_release</span>              — 版本進度 / 掉車通知 / PM 警告
  <span class="tag">forest_log</span>                  — 正式發布通知

V2 新增（P1）：
  <span class="tag">release-hotfix</span>              — Hotfix 啟動通知（Automation 13）
                                 成員：David、Sherridy、Ezou、RD Lead、Shawn

P2 進階 Channel：
  <span class="tag">mkt-translation</span>             — 翻譯確認通知（Automation 8）
  <span class="tag">product-release</span>             — Feature Freeze 通知（Google Calendar 手動 / n8n 自動）

release-hotfix Channel 建立步驟

1. 在 Slack 建立新 Channel：#release-hotfix
2. 設定 Channel 描述：「Hotfix 啟動通知頻道。
   只有確認符合觸發條件的緊急修復才在此發通知。
   使用頻率高（月 > 2 次）是需要改善測試流程的信號。」
3. 邀請成員：David、Sherridy、Ezou、RD Lead、Shawn
4. 在 Channel 中執行 /invite @linear
5. 確認 Automation 13 的 Channel 名稱設定正確

Step 8：Project 建立（V2 版，含 String Freeze Milestone）

路徑：左側欄 → Projects → New Project

每個版本 Project 的標準設定

基本資訊：
  Project 名稱：Forest v[版本號] Release
  描述：[版本主要功能列表]
  Lead：RM（Sherridy）
  Target Date：預計發布日期
  Status：In Progress

7 個 Milestone 的完整設定步驟（V2 版）

進入 Project → Milestones 頁籤 → Add Milestone

Milestone 1：Sprint Planning 完成
  日期：Cycle 開始當天
  描述：所有 Issue 已加入 Project，每個 Issue 都有
        Testing Notes 初始版本

Milestone 2（V2 新增）：String Freeze
  日期：Feature Freeze 前 7-10 天（由 RM 決定）
  描述：此日期後所有 UI 文字和 Copy 不再接受修改。
       MKT 的翻譯工作以此日期版本的文字為基礎。
       Exception 申請需 RM 確認。

Milestone 3：Feature Freeze
  日期：Cycle 結束前 7 天（由 RM 決定）
  描述：此日期後不再接受新 Issue 加入此版本。
       如有緊急需求，需要 RM + PO + 受影響 RD 三方確認。
       掉車的 Issue 請移至下一個 Project 並加上 [Dropped] Label。

Milestone 4：First ALPHA 發出
  日期：Feature Freeze 後 2-3 天（預估，可後續更新）
  描述：第一個 Android ALPHA 版本包發給 QA。
       iOS TestFlight 第一個測試版本就緒。
       QA 測試正式開始（批次視窗機制啟動）。

Milestone 5：All QA Passed
  日期：QA 完成時更新（建立時先留空）
  描述：所有 Issue 都達到 QA Passed 或 Waiting for Others 狀態。
       可以開始進行正式版包版（Packaging）作業。

Milestone 6：Release Candidate
  日期：QA 通過後 1-2 天（預估）
  描述：iOS TestFlight + Android 正式 APK 均已就緒。
       等待 Shawn 送審。

Milestone 7：Released
  日期：上架當天更新
  描述：iOS App Store + Android Google Play 均已正式上架。
       Phased Release / Staged Rollout 開始計時（Shawn 7 天監控）。

First ALPHA Milestone 完成說明（半自動機制）

Linear Automation 技術限制：
  Automation 的 Action 清單中沒有「標記 Milestone 為完成」。

半自動方案（✅ Comment 原生 + 📋 RM 手動確認）：

在 Automation 2（Android Ready for Test 通知）中加入 Action：
  當第一個 Android Issue 狀態改為 Ready for Test 時，
  額外發 Slack 訊息到 <span class="tag">forest_release</span>：
  「Android 第一個 ALPHA 已發出，請 RM（Sherridy）
   手動標記 First ALPHA Milestone 完成。」

RM 收到通知後，前往 Project → Milestones → 點擊「First ALPHA 發出」→ Mark as Complete

Step 9：成員邀請

路徑：Settings → Members → Invite members

分階段邀請計劃

M1（立即邀請）：

• RM（Sherridy）— 管理員角色
• iOS RD：Richard、Eric — Member 角色
• Android RD：Tolyn、Kenneth — Member 角色

M1 後半段：

• Server RD：Xiang、Keith、Tommy — Member 角色
• Web RD：Matt — Member 角色
• CTO（RD Lead）：Ezou — Member 角色

M2：

• QA：Fei Chen、Jimmy — Member 角色

M3：

• PO：Shawn — Member 角色
• PD（Tiffany、Zi）— Viewer 角色（僅閱讀，不操作）

Step 10：DORA Webhook 設定（P2）

可行性：⚠️ 需要 n8n 接收端

設定位置：Settings → API → Create API Webhook

Webhook URL：[n8n 的 DORA Webhook endpoint]

監聽事件：Issue state update（當 Issue 狀態改變時觸發）

n8n Filter（在 n8n 中設定）：
  只處理 state = "Released" 的事件
  Payload 映射：
    issue.id → dora.issue_id
    issue.title → dora.feature_name
    issue.project.name → dora.version
    timestamp → dora.released_at

Step 11：Branch 壽命 GitHub Action（P2）

可行性：⚠️ 需要 GitHub Action 設定

新增 GitHub Action（.github/workflows/stale-branch-check.yml）：

  觸發：每天 UTC 09:00（台北時間 17:00）

  邏輯：
    掃描所有 feature/* 分支
    找出最後一次 commit 超過 3 天的 PR
    在 PR 加上 Comment：
    「⏰ 此 PR 已超過 3 天未合併。
     請更新開發進度或說明阻礙。
     若已不需要，請關閉此 PR。
     @[PR Author]」

Step 12：Android ALPHA 驗證（含 QA 驗收流程）

這是 V3 繼承的獨立驗證步驟，必須連續 2 次成功才算通過。

驗證目的

確認以下三個機制同時正確運作：

1. Android CI/CD 在合併到 staging/android-* 時，版本號自動加上 -ALPHA 後綴
2. Linear branchPattern 正確觸發 Issue 狀態改為 Ready for Test
3. Automation 2 正確發送含 -ALPHA 版本號的 Slack 通知

第一次驗證步驟

準備：
  1. 確認 Step 6 的 branchPattern 已設定並通過驗收測試
  2. 確認 Automation 2 已設定
  3. 確認 <span class="tag">forest_android_testcenter</span> 已加入 Linear Bot

執行：
  1. 建立測試 Issue：「[測試] Android ALPHA 機制驗證 Round 1」
     加上 Label：Android
  2. 請 Tolyn 或 Kenneth 建立測試 PR，標題包含 Issue ID（如 REL-XXX）
  3. 合併 PR 到 staging/android-[任意版本] branch

驗收三個關鍵點（缺一不可）：
  ✅ CI/CD 產生的 build 版本號含 -ALPHA（例：5.8.0-ALPHA1）
  ✅ Linear Issue REL-XXX 狀態自動變為 Ready for Test
  ✅ <span class="tag">forest_android_testcenter</span> Slack Channel 收到通知（含 -ALPHA 版本號）

記錄：在測試 Issue Comment 記錄驗收結果

第二次驗證步驟（間隔 2-3 天後執行）

重複第一次驗證步驟，使用新的測試 Issue

第二次額外驗證重點：
  ✅ 版本號後綴序號正確遞增（-ALPHA2 而非重複 -ALPHA1）
  ✅ QA（Fei Chen 或 Jimmy）實際確認可以收到通知並下載 Build
  ✅ Automation 6（Ready for Test 個別確認 Comment）正常觸發

結論記錄：「Android ALPHA 機制驗收通過，加上 Label [ALPHA-Verified]」

Step 13：Firebase Crashlytics Alert（V2 版，前移至 M1 末）

重要變更：V1 將此設定放在 Month 3，V2 前移至 Month 1 末。

理由：Firebase Crashlytics Alert 設定成本低（1-2 小時），但提供的發布安全保護從 Month 1 末就開始，不必等到 Month 3 才有 Crash 監控。

閾值設定說明

Forest App 使用分層閾值策略：

注意：00-導入計劃總覽 中 Hotfix P0 Bug 的「Crash-free rate < 99.0%」為成熟期目標閾值，非 Month 1 的 Alert 設定值。Month 1 Alert 使用 98.5% 是刻意保守的設計，避免在基線未知時產生大量假警報。

方案 A（推薦，n8n 已有）— 自動化程度最高

可行性：⚠️ 需要 n8n

流程：
  Firebase Crashlytics Alert → Firebase Webhook → n8n → Slack <span class="tag">forest-release</span>

設定步驟：
  1. Firebase Console → Crashlytics → Alerts → Create Alert
     條件：Crash-free users rate < 98.5%（iOS + Android 分別設定）
     觸發方式：Webhook
     Webhook URL：[n8n endpoint]

  2. n8n Workflow：
     Input：Crashlytics Webhook Payload
     Filter：rate < 98.5%（避免假警報）
     Output：Slack Webhook 到 <span class="tag">forest-release</span>

  3. Slack 訊息格式：
     「🚨 Crash Rate 異常警告
      App：Forest [iOS / Android]
      版本：{版本號}（Phased Release 中）
      Crash-free session rate：{rate}%（目標 > 98.5%）
      Alert 觸發時間：{timestamp}（MTTR 計時起點）

      建議行動：
      1. 查看 Crashlytics Dashboard 確認 Crash 來源
      2. 考慮暫停 Phased Release
      3. 評估是否啟動 Hotfix SOP

      @shawn @david @sherridy 請確認

      [點此查看 Crashlytics Dashboard]（連結）」

預估設定時間：3-4 小時

方案 B（輕量備選）— Email + Zapier

可行性：⚠️ 需要 Zapier

流程：Firebase Email Alert → Zapier → Slack

優點：設定較簡單
缺點：Zapier 有 polling 延遲（最快 1-5 分鐘）、費用問題

預估設定時間：1-2 小時

方案 C（過渡方案）— 手動監控

可行性：📋 靠人工紀律

操作規範：
  Shawn 在每次發布後的 7 天內，每天查看 Firebase Crashlytics Dashboard
  每日查看項目：
    ✅ iOS Crash-free session rate > 98.5%
    ✅ Android Crash-free session rate > 98.5%
    ✅ Android ANR rate < 0.2%
    快速看 App Store / Google Play 評論趨勢（2 分鐘）

  若正常：在 Linear Project Comment 記錄：
  「✅ Day [N] Phased Release 監控
   iOS Crash-free: 99.X%，Android Crash-free: 99.X%
   評論趨勢：正常，決定：繼續 Phased Release」

  若異常：
  「⚠️ Day [N] Crash Rate 異常
   Crash-free rate: XX%（目標 > 98.5%）
   已通知 @david @sherridy
   建議：暫停 Phased Release，評估是否啟動 Hotfix SOP」

MTTR 計算起點：Shawn 在 Slack 發出異常通知的時間戳

建議實作路徑

Month 1 末：方案 C（手動），同時嘗試設定方案 A
Month 2：持續方案 C，若方案 A 已設定則升級
Month 3+：方案 A（Firebase + n8n），依基線數據調整閾值

Step 14：Feature Freeze 提醒（⚠️ Linear 不支援，需替代方案）

技術限制聲明：Linear Automation 沒有「距 Milestone 日期 N 天」的 Trigger，因此無法在 Linear 原生實現 Feature Freeze 48 小時提醒。

替代方案 B（Month 1-2 推薦）：Google Calendar 手動提醒

可行性：📋 靠人工紀律（RM 記得設定 Calendar）

操作步驟（RM 在建立每個版本 Milestone 時執行）：

1. 在 Linear 建立 Feature Freeze Milestone（加入日期）

2. 同步在 Google Calendar 建立提醒事件：
   事件名稱：「[版本號] Feature Freeze 前 48 小時提醒 — 手動發 Freeze 通知」
   事件時間：Feature Freeze 日期前 2 天的上午 09:00
   提醒：事件開始時提醒（Email + 通知）

3. Google Calendar 事件觸發時，RM 執行：
   在 <span class="tag">product-release</span> 手動發 Slack 通知：
   「📌 Feature Freeze 提前警告
    Project：[版本名]
    Feature Freeze 日期：[日期]（還有 2 天）

    以下 Issue 尚未 Ready for Test：[手動列出清單]

    請 @sherridy + @shawn 共同評估：
    ① 這些功能預計在 Freeze 前完成？
    ② 或需要啟動掉車 SOP？」

注意事項：
  - RM 必須在每個版本建立 Milestone 時立即設定 Calendar 提醒
  - 若 RM 忘記設定，此機制失效（無備援）
  - 建議在 RM 的 M1 培訓中加入 Calendar 設定練習

替代方案 A（Month 3 升級）：n8n 定時查詢

可行性：⚠️ 需要 n8n 設定（一次性 2-4 小時工時）

n8n Cron Job 設定：
  執行頻率：每天 09:00（台北時間）
  查詢：Linear API → Projects → Milestones
  判斷：Milestone 名稱包含「Feature Freeze」且日期在 48 小時內
  動作：發 Slack 訊息到 <span class="tag">product-release</span>

自動訊息格式（同方案 B，但 Issue 清單由 API 自動抓取）：
  n8n 同時查詢該 Project 中 Status = In Development 或 Planning 的 Issue
  自動列入通知，RM 無需手動整理清單

優點：無需 RM 手動操作，完全自動化
升級時機：Month 3，待 n8n DORA Webhook 穩定後一起設定

Step 15：Hotfix 環境設置（V2 新增）

這是 V2 最重要的新增設置章節，為 Month 3 正式啟用 Hotfix SOP 做環境準備。

15.1 Hotfix Label 建立

操作路徑：Settings → Teams → Release Tracker → Labels → Add Label

設定：
  名稱：Hotfix
  顏色：#DC2626（深紅，與 Ready for Fix 的紅色區別，使用更深的紅）
  說明：緊急修復 Issue。加上此 Label 後，Automation 13 會自動通知
       <span class="tag">release-hotfix</span> 並設定 Priority 為 Urgent。
       使用頻率高（月 > 2 次）是需要改善測試流程的信號。

15.2 Hotfix Cycle 命名規範

Hotfix 不加入正常 Cycle，建立獨立 Hotfix Cycle：

命名格式：「Hotfix-[版本號]-[日期]」
範例：「Hotfix-v5.8.1-2026-03-15」

建立步驟：
  Cycles → New Cycle
  名稱：Hotfix-vX.X.X-YYYY-MM-DD
  開始日期：觸發當天
  結束日期：預計發版日期

Hotfix Issue 加入 Hotfix Cycle（不加入正常 Cycle）：
  Issue → Cycle → 選擇對應 Hotfix Cycle

15.3 Firebase Crashlytics → Slack release-hotfix 整合確認

確認清單：
  ✅ Firebase Crashlytics Alert 已設定（Step 13）
  ✅ Alert 通知已包含 <span class="tag">forest-release</span> Channel
  ✅ <span class="tag">release-hotfix</span> Channel 成員可以接收 Automation 13 的通知
  ✅ David + Sherridy + Ezou 的 Slack 通知設定不會遺漏 <span class="tag">release-hotfix</span> 訊息

Hotfix MTTR 計算說明：
  計時起點：Firebase Crashlytics Alert 的時間戳（或 <span class="tag">release-hotfix</span> 啟動通知的時間戳）
  計時終點：App Store / Google Play 發版的時間戳
  記錄位置：Hotfix Issue Comment

15.4 Android vs iOS Hotfix 流程差異說明

Android Hotfix：
  優勢：Google Play 分級發布，通常 2-4 小時審核通過
  操作：Google Play Console → 版本 → 分級發布 → 選擇新版本
  注意：可以從 1% 用戶開始分級，快速監控新 Hotfix 是否有效

iOS Hotfix：
  正常流程：App Store 審核通常 24-48 小時
  緊急流程：申請 Expedited Review
    操作路徑：App Store Connect → 送審版本 → 「申請加急審核」
    說明範本：「此版本修復了影響 XX% 用戶的 [功能名稱] 崩潰問題，
             Crash-free rate 已降至 XX%，請加急審核。」
    效果：可能縮短至數小時，但不保證

短期緩解措施（Hotfix 審核期間）：
  若有 Feature Flag / Server-side Kill Switch：
    可以暫時關閉有問題的功能，緩解 Crash Rate
  若無 Feature Flag：
    考慮暫停 Phased Release（Android Staged Rollout 暫停 / iOS Phased Release 暫停）
    等 Hotfix 審核通過後繼續

Step 16：QA 待測 Queue 視圖設定（V2 新增，M2 執行）

背景：QA 批次視窗機制需要一個可見的「待測 Queue」，讓 Fei Chen + Jimmy 在批次時段開始時知道要處理哪些 Issue。

視圖設定步驟

操作路徑：
  左側欄 → Views → New View → Team View（Release Tracker）

視圖名稱：QA 待測 Queue

Filter 設定：
  Filter 1：Status = "Ready for Test" OR "Testing"
  Filter 2：（可選）Assignee = Fei Chen OR Jimmy
             （如 QA 的 Issue 未 Assign 到個人，移除此 Filter）
  Filter 3：（可選）Team = Release Tracker

Sort 設定：
  Primary Sort：Priority（高到低，Urgent > High > Medium > Low）
  Secondary Sort：Due Date（近到遠）

顯示欄位：
  Title, Status, Priority, Assignee, Labels, Due Date, Project

分享設定：
  View 設定為 Team View（Fei Chen 和 Jimmy 都能看到）
  不設定為個人 View（避免兩人視角不一致）

QA Dashboard 額外視圖（可選）

視圖名稱：QA Dashboard（進行中）

Filter：
  Status = "Testing" AND Assignee = Fei Chen OR Jimmy

用途：在批次時段進行中，快速看自己正在測的 Issue

向 QA 說明視圖使用方式

批次視窗開始時的操作流程：
  1. 打開「QA 待測 Queue」視圖
  2. 確認 Queue 中的 Issue 清單
  3. 從 Priority 最高的 Issue 開始測試
  4. 如有 [Priority: Urgent] Issue，優先處理
  5. 批次時段結束時，記錄已完成和待處理的 Issue

批次時段外的規範：
  - 收到 Ready for Test 通知：確認 Issue 已進入 Queue，暫不處理
  - 例外：Issue 有 [Priority: Urgent] Label → 可即時處理
  - 緊急插隊申請：通知 RM（Sherridy），由 RM 手動加 Urgent Label

Step 17：PR Template 設定（V2 新增）

背景：Testing Notes 的最脆弱環節是 RD 補充這一步。PR Template 是目前最接近「工具強制」的介入點。

可行性：⚠️ 需要 GitHub PR Template 設定（Ezou 確認可行性）

在 GitHub Repo 新增 PR Template（.github/pull_request_template.md）：

---

## 變更說明
（這個 PR 做了什麼？）

## 相關 Issue
Linear Issue：REL-XXX（請填寫對應 Issue ID）

## 測試注意事項確認（三方確認機制 — RD 環節）

已更新 Linear Issue 的測試注意事項（如有新的技術邊界）：
- [ ] Y（已更新）
- [ ] N（未更新，原因：___）
- [ ] 無更新（此 PR 沒有新的技術邊界或平台差異）

## Impact Scope（QA 回歸範圍參考）
此 PR 影響的模組 / 功能：
（QA 評估回歸測試範圍時參考此欄位）

## Reviewer Checklist
- [ ] 測試注意事項已更新（或確認無需更新）
- [ ] 無引入新的已知 Bug

---

設定後的效果：

• RD 在每個 PR 中都必須明確確認 Testing Notes 的更新狀態
• 這不是工具強制（Review 者可以 Approve 即使 Checkbox 未勾），但它建立了「每次 PR 都要想到 Testing Notes」的習慣
• Ezou（RD Lead）負責在 Code Review 時確認此欄位有填寫

驗收清單（V2 版）

P0（第一個版本用 Linear 前必須完成）

• Step 6 branchPattern 設定完成並通過驗收測試（最優先）
• Step 9 全員受邀加入 Release Tracker Team
• Step 8 第一個 Project 建立（含 7 個 V2 Milestones，包括 String Freeze）
• Step 4 Issue Templates V3 上線（3 個 Template 含 Testing Notes 欄位）
• Step 5 P0 Automation 啟用（Automation 1/2/3/4）
• Step 7 Slack Channel 已加入 Linear Bot（ios/android/serverweb testcenter + release + release-hotfix）
• Step 3 [Hotfix] Label 建立（顏色：#DC2626 深紅）
• Step 15.1 release-hotfix Slack Channel 建立並邀請相關人員

P1（Month 1 完成）

• Step 5 P1 Automation 啟用（Automation 5/6/7/13）
• Step 12 Android ALPHA 驗證通過（連續 2 次，加 [ALPHA-Verified] Label）
• Step 13 Firebase Crashlytics Alert 設定完成（至少方案 C 手動或方案 A/B 自動）
• Step 14 Feature Freeze 48h 提醒：RM 已熟悉 Google Calendar 手動提醒流程
• Step 2 Workflow States 命名評估（Packaging / Pending Release 是否採用）
• DORA 基線數據記錄完成（7 個指標）
• Step 15 Hotfix Cycle 命名規範確認

P2（Month 2 完成）

• Step 16 QA 待測 Queue 視圖設定完成（Fei Chen + Jimmy 確認使用）
• Step 3 回測 Labels（Re-test-1/2/3）加入
• Step 5 P2 Automation 啟用（Automation 8/9/10/11/12）
• Step 2 Waiting for Others State 試行設定
• Step 10 DORA Webhook 設定完成
• Step 11 Branch 壽命 GitHub Action 上線
• Step 17 PR Template 設定（Ezou 確認後實施）

P3（Month 3 完成）

• Step 14 方案 A（n8n）評估並決定是否升級
• Step 13 Firebase Alert 升級（若選擇方案 A）
• 所有 Automation Rules 已測試並文件化
• David + Sherridy 共同進行全環境驗收
• iOS TestFlight Webhook 可行性評估

設定項目彙總（V2 完整清單）

Linear 設定（在 Settings 完成）：
  ├── Workflow States：11 個（含 M2 的 Waiting for Others + 命名升級評估）
  ├── Labels：40+ 個（平台 + 狀態 + QA + Translation + Hotfix + Priority）
  ├── Issue Templates：4 個（功能 / QA 測項 / Bug Fix / Hotfix Issue）
  └── Automation Rules：13 條（含新增 Hotfix Automation）

GitHub 設定：
  ├── branchPattern（feature/* + staging/* + main/* + hotfix/*）
  ├── Stale Branch GitHub Action（Month 2）
  └── PR Template（含 Testing Notes 確認欄位）

Slack 設定：
  ├── <span class="tag">forest_ios_testcenter</span> 加入 Linear Bot
  ├── <span class="tag">forest_android_testcenter</span> 加入 Linear Bot
  ├── <span class="tag">forest_serverweb_testcenter</span> 加入 Linear Bot
  ├── <span class="tag">forest_release</span> 加入 Linear Bot
  ├── <span class="tag">forest_log</span> 加入 Linear Bot
  ├── <span class="tag">release-hotfix</span> 建立 + 加入 Linear Bot（V2 新增）
  └── <span class="tag">mkt-translation</span> 加入 Linear Bot（M2）

Firebase 設定（M1 末）：
  └── Crashlytics Alert → Slack（方案 C 手動起步，方案 A n8n 為 M3 目標）

Google Calendar 設定：
  └── RM 每個版本設定 Feature Freeze 前 48 小時提醒（方案 B，M1-2 過渡）

每個版本 Project 重複設定：
  ├── Milestone 1：Sprint Planning 完成
  ├── Milestone 2：String Freeze（V2 新增）
  ├── Milestone 3：Feature Freeze
  ├── Milestone 4：First ALPHA 發出
  ├── Milestone 5：All QA Passed
  ├── Milestone 6：Release Candidate
  └── Milestone 7：Released

QA 視圖設定（M2）：
  ├── QA 待測 Queue（Team View）
  └── QA Dashboard 進行中（可選）

常見問題排除

Q：GitHub PR 沒有自動連結 Linear Issue

1. 確認 PR 標題或描述包含 Issue ID（如 REL-42）
2. 確認 RD 的個人 GitHub 已連接 Linear（Settings → Connected accounts）
3. 確認 GitHub Organization 已授權 Linear App
4. 仍無效：Settings → Integrations → GitHub → Disconnect → Reconnect

Q：Slack 通知沒有送出

1. 確認 Channel 已 /invite @linear
2. 確認 Automation 規則中 Channel 名稱拼寫正確（含 # 前綴）
3. 查看 Automation 日誌：Settings → Automation → View logs
4. 確認 Automation 的 And 條件沒有過度限縮

Q：Android ALPHA 版本號沒有 -ALPHA 後綴

1. 找 Tolyn / Kenneth 確認 CI/CD 的 versionName / versionCode 設定
2. 確認 Gradle 的版本號生成規則是否與 staging/android-* branch 綁定

Q：Feature Freeze Automation 沒有觸發（Automation 11）

• 這是已知限制：Linear 不支援 Milestone 日期觸發
• 確認 RM 是否已設定 Google Calendar 提醒（方案 B）
• Month 3 升級到 n8n 方案（方案 A）後才有自動觸發

Q：[Hotfix] Label 加上後 Automation 13 沒有觸發

1. 確認 Automation 13 的 Trigger 設定為「Issue label added = Hotfix」
2. 確認 release-hotfix Channel 已加入 Linear Bot
3. 確認 Automation 13 的 Priority 設定 Action 格式正確

Q：QA 待測 Queue 視圖顯示不正確

1. 確認 Filter 設定：Status = "Ready for Test" OR "Testing"
2. 確認視圖是 Team View 而非個人 View
3. 若 Issue 未 Assign 到 QA，移除 Assignee Filter

相關文件：03-三個月導入路線圖（統整版V2） | 05-團隊導入策略（統整版V2）

linear 環境建置 統整版V2 automation github crashlytics feature-freeze alpha驗證 hotfix qa批次視窗 string-freeze