這幾天主要在把一個手機 App 推到可以送審的狀態，同時修掉它處理深夜時間的缺陷。另外也把一批還沒在真手機上試過的功能，老實標成「待驗」。
第一顆正式版已送進測試通道，還沒送審
這個 App 叫 ライブハシゴ，是幫人安排一晚跑多場現場演出的行程工具。我把它打包成 1.0.0 正式版，傳到蘋果的內測管道 TestFlight（正式上架前給自己人試用的地方）。這像是印好一本試印本寄給自己，還沒交給書店審核。
送審前會被問到的東西，這幾天一併備齊。我在作品集網站加了這個 App 的隱私權政策頁，內容只寫已經確認的事實。手機跳出的權限說明，也補上「資料會留在手機內」或「會送到蘋果地圖服務」這類去向。商店截圖輸出了一組，其中與 App 實際畫面不一致的地方，已記在文件裡，等審查回饋再調。
送審前先備齊對方一定會問的資料：資料去哪、為什麼要權限、畫面長什麼樣。這幾項在審查時才補，來回會很慢。
技術細節：版本與上傳狀態
- 版本 0.1.0 改為 1.0.0，build 登記為 1.0.0 (3)，
verify-ipa --store結果 PASS 25 項、FAIL 0 項。- 已填入
ascAppId6818411858，build 已上傳 TestFlight。- 截圖為 1320×2868、無 alpha 通道、sRGB，由
scripts/export-store-screenshots.mjs輸出並驗證。- 審查結果、上架日期：尚未驗證。
凌晨一點的演出，要算在前一天
演出常常散場到凌晨。如果程式照時鐘把 01:00 當成「今天最早」，這場就會被排在整張行程最前面，路線和出發時間也跟著全錯。
我的處理是把 0:00 到 5:59 視為前一天的延續，排在最後，畫面顯示成 25:00。使用者可以直接說「25 時」或「24 時半」，App 也看得懂。另外，查詢「下一場」時，如果今天那張行程已全部結束，就跳到下一張，不再停在已經演完的那張。
做跟時間有關的功能，要先問「一天到底在哪裡結束」。用午夜切日，對夜生活類的使用情境就會算錯。
技術細節：深夜時刻的處理方式
- 時刻照存（例如 01:00），在排序、路線、餘裕、
isPlaying、出發時刻上視為 24:00 到 29:59，不需 migration。- 終演早於開演就加 1440 分鐘；沒有終演時間，用開演加
AGENT_DEFAULT_SHOW_MINUTES（120 分鐘）。- 「次の／今度のハシゴ」由一覽頁時鐘傳入
nowHhmm，其他頁面沒傳時行為不變。
沒在真手機上試過的功能，一律標待驗
語音對話這條線有一批新功能：可以中途取消、切到背景後回來能接續對話、失敗時的提示文字改得更清楚。程式寫完不代表使用者用得順，所以任務表上這些項目全標「待驗」，沒有任何一項標完成。整理出的實機驗收清單很長，要由使用者拿手機逐項確認。
其中一段要在手機原生層寫的取消功能，寫的時候還沒編譯過。我把它做成獨立的一個提交，編譯失敗只要退掉這一筆；新程式找不到取消功能時，會自動退回舊做法。這次編譯通過了，退路沒有用到。
要冒險的改動，把新舊兩條路都留著。「寫完」和「驗過」分成兩種狀態記錄，才不會把還沒驗過的東西當成做完。
技術細節：原生取消與狀態標記
- 新增
HashigoAiCancellable.swift，HashigoAiModule.swift只在definition()內多註冊三個函式，既有實作不動。- JS 端偵測不到
cancelRequest時，退回只丟棄結果的舊流程。- build #16 的
verify-ipa結果為 PASS 24 項、FAIL 0 項，Swift 首次編譯通過。- 對話保留用
expo-sqlite/kv-store，24 小時（CHAT_RESUME_TTL_MS）後清掉。
接下來
- 使用者拿手機跑完實機驗收清單，確認各項功能。
- 確認 TestFlight 的 build 沒問題後，決定何時送審。
- 截圖與 App 畫面不一致的部分，等審查回饋再調整。
本篇由跨專案自動彙整產生，素材為 2026-09-30 之後 3 個專案的提交紀錄與 0 則知識投遞。