"State-Machine"
- Screen State Matrix（畫面狀態矩陣）
說明用四欄表格（顯示/可用操作/進入條件/退出路徑）系統性地暴露畫面導航缺口的設計工具
- U.C1 Terminal 畫面五個狀態零個退出路徑
Flutter app 的 Terminal 畫面有 idle/connecting/connected/error/disconnected 五個 enum 狀態，每個狀態都沒有 back 或 disconnect 按鈕 — 使用者一旦進入就出不去
- Widget test 的狀態覆蓋策略
從畫面狀態矩陣推導 widget test case — 每個狀態的顯示、操作、退出路徑都是獨立的斷言目標
- 畫面狀態矩陣的定義與填寫方法
四欄矩陣（顯示 / 可用操作 / 進入條件 / 退出路徑）的定義、填寫步驟和檢查規則 — 退出路徑為空 = UX 死胡同
- 從 BDD 操作盤點展開到狀態矩陣
五步驟把 BDD 操作盤點的「前端引導」展開成完整的畫面狀態矩陣 — 補上操作和退出這兩個容易遺漏的面向
- 反模式：假設使用者只走 happy path
為什麼開發者容易只設計 happy path 的 UI、使用者在非 happy path 狀態下被困住的機制分析、以及用狀態矩陣系統性地防止這個問題
- U.C6 加書後返回不刷新統計 — 只設計了進入時載入
Flutter app 資料管理頁的書籍統計只在 initState 載入一次，從頁面進入新增流程加書後 pop 返回，統計停留在舊值（仍顯示無書目），要回首頁再進入才更新。根因是 happy-path-only 反模式的資料版本：設計了「進入時載入」，沒設計「資料變更時的轉移」
- U.C10 Service Worker 冷啟動期間的假離線 — initializing 狀態未建模
查詢對象有獨立生命週期（service worker、遠端服務）的畫面，把「還不知道」與「離線」合併就會把慢啟動呈現成假離線 — initializing 是真實狀態、要進狀態矩陣、timeout 是它的退出路徑
- 7.B11 Vulnerability Response State Machine
把漏洞回應拆成狀態機，建立 observed 到 closed 的可交接流程
- 單調狀態機與樂觀更新的回滾契約：前台不得顯示後端沒記錄的狀態
POS App 的品項處理狀態只能遞增——現實世界的動作不可逆，狀態機跟著不可逆。樂觀更新讓 UI 先行，但後端拒絕時必須回滾：因為這個狀態是其他防護規則的資料來源，前台多顯示一格進度，防護就會在錯誤的前提上放行。
- 每個畫面都需要出口：畫面狀態機設計與 UX 導航的系統性方法
實機測到某畫面沒有返回或退出按鈕、使用者被困住。根因是企劃沒系統列出每個畫面的狀態與可用操作；用畫面狀態矩陣確保每個狀態都有明確出口。