Phase Readiness Blocker Classification¶
概念概覽
判斷框架¶
核心知識¶
判斷框架¶
就緒性審查最常見的錯誤是把「Phase N 本身要做的事」誤列為「進入 Phase N 的前置條件」，造成 Phase 永遠無法開始。
pre-phase blocker 的判斷標準： - 會直接破壞 build（go build fail） - 讓現有功能處於半殘狀態（stub 阻斷核心路徑） - 若不修復，phase 的接線工作本身無法驗證正確性
屬於 phase 本身工作（不是 blocker）：
- cmd/twirpserver/main.go 未接線 activity/sticker 服務 → 這就是 Phase 3 要做的事
- 新功能的端對端整合 → phase 啟動後才進行
三類 Blocker 嚴重度分層¶
| 層級 | 範例 | 影響 |
|---|---|---|
| pre-phase 必修 | GetPlayerProgress 型別不符、ResolveContentClosure 是 stub | build fail 或核心路徑空殼 |
| 擋上線但不擋 phase 開始 | ScheduleConfigLoader 只有 mock 無 production 實作 | phase 期間可用 mock 推進，上線前補 |
| 高風險缺口 | reward type 6/7 未支援 | runtime 靜默失敗，難定位 |
經驗教訓¶
-
「Phase N 前必修」vs「Phase N 本身的工作」的邊界不清楚時，Phase 會陷入無法啟動的困境
-
go build fail 是最明確的 pre-phase blocker，不需要額外判斷
-
stub 造成的「核心路徑空殼」也是 pre-phase blocker，因為接線後仍然無法驗證正確性
常見陷阱¶
-
把接線工作（main.go 註冊服務）誤列為 blocker，導致「phase 永遠未開始」
-
readiness register 的 OPEN/Closed 狀態若不同步更新，下次審查會重複誤判
相關概念¶
- Bug Fix vs Capability Expansion Phase Splitting
- Go Interface Contract Build Enforcement
- Stub-to-Production Gap Risk
相關視角¶
以下頁面與本概念共享主題，但從不同角度切入。保留獨立視角同時提供交叉參考：
- Activity Framework Settlement Idempotency — 共享：
activity-framework/ 獨特：idempotency,settlement
來源 Sessions¶
| 日期 | Session | 貢獻摘要 |
|---|---|---|
| 2026-04-02 | 431f3410-f7d5-461d-8a0b-e1ea3f999e73 | 建立「pre-phase 必修 blocker」vs「phase 本身的工作」的判斷框架，避免審查時將 in-phase 工作誤列為 blocker 導致 phase 永遠無法啟動 |