"Async"
- Fire-and-Forget Orchestration（射後不理編排）
呼叫後不等待完成的編排形態；產生「方法返回不等於流程完成」的時序落差，是 flaky test 的常見根因之一
- T.C8 fire-and-forget 編排讓測試單跑綠、合跑紅
結帳成功後的收尾動作（列印、狀態清理、資料同步）沒有被 await — 測試斷言與收尾動作賽跑，單獨執行時碰巧贏、整批執行時排程不同就輸；競態本身也揭露了產品的時序特性
- await 回來的時候、頁面已經關了 — UnmountedRefException 與 16 個不抽象的檢查點
長 async 流程的每個 await 都是一個 gap：等待期間使用者可能離開、Notifier 被 dispose、回來再寫 state 就炸 UnmountedRefException。修法是每個 gap 後檢查 ref.mounted——而且刻意不抽成 helper：明確的檢查點讓 review 看得見哪個 gap 有守。含「評估必跑、可決定不重構」的技術債處置。
- 同一個子系統膨脹兩次：異步查詢系統的過度設計震盪
過度設計會復發、且兩輪的機制不同：設計期的膨脹來自想像的需求（別層已處理的重試、用不到的優先級佇列），迭代期的膨脹來自不刪的舊版本（三個實作並存、狀態多處追蹤）。偽需求的檢驗法是問「這個能力已經有別層在做嗎」。
- 寫測試時 sync try-catch 接不到 BotToast 的 async 錯誤：fire-and-forget API 的接管設計
測試裡 sync try-catch 接不到錯誤，或 fire-and-forget API 從 async gap 後拋 `LateInitializationError`。用 runZonedGuarded 同時罩 sync 與 async 失敗路徑，含 fallback 訊息 signature 設計。