編譯成功之後，還有一段路
畫面能打開、資料能留下、提示真的有感，是三件不同的事。這是 ZenDrip 開發過程中反覆遇到的一課。
看到 BUILD SUCCEEDED，很容易覺得事情終於完成了。但在 ZenDrip 的開發裡，這行字往往只是下一個問題的起點。
App 能不能安裝？安裝後能不能開啟？完成一場沖煮之後，紀錄真的有留下來嗎？這些都需要各自的證據。
看起來是同一個問題，其實不是
開發過程曾遇過：App 已經安裝到 iPhone，啟動卻失敗。當時的系統回覆指出手機處於鎖定狀態，不能把它當成 App crash。
模擬器也有另一種情況。PhoneMVP 的 UI 測試已經可以編譯，執行時卻一直等不到測試 worker 準備完成。沒有任何一個測試案例真正開始，因此結果應該是「尚未執行」，而不是通過，也不是程式的斷言失敗。
如果把這幾種狀態都寫成「不能用」，下一次排查就會從錯的地方開始。
後來，驗收被拆成四件事
- Build：程式能夠編譯，產生 App。
- Install：系統確認 App 已安裝到指定裝置。
- Launch：App 確實啟動。
- Runtime：使用者真的走過流程，得到預期結果。
對 ZenDrip 而言，最後一項包括完成沖煮、略過或填寫回顧，再重開 App 找到那筆紀錄。
聲音與觸覺還要多走一步。畫面上有開關，不代表音量舒服；程式發出觸覺指令，不代表手上一定感覺得到。這部分需要拿起真實的手機或手錶測試。
已保存的紀錄，也不是全部
這次開發檢閱又指出一個缺口：證明「保存後重開仍在」，不等於「沖煮到一半被終止也能恢復」。
目前的 iPhone 引導在結束時才保存正式紀錄。進行中的狀態如何留下檢查點、重新開啟後如何處理未知的中斷時間，已排入接下來的可靠性工作，還沒有完成。
Watch 傳輸也有類似邊界：傳送成功與 iPhone 永久保存成功不能混為一談。接收端保存確認，是另一個待補的工作。
下一次先問：這個結果究竟證明了什麼？
現在，開發紀錄會把編譯、安裝、啟動和實際操作分開寫。環境沒有變化時，也不把重跑同一個命令當成進度。
下一輪會先補 iPhone 的中斷復原與完整沖煮流程，再處理更多功能。這篇記下的不是所有問題都已解決，而是之後要用更明確的方式，知道自己走到了哪裡。