設計文件寫著完成，審查用的截圖一張都沒有

9 月 21 日凌晨 2 點，我打開 App Store Connect，對送審清單。兩個應用內購買項目底下，審查用的截圖一張都沒有。設計文件寫著「完成，9 月 19 日」。有人把「準備送審」讀成「截圖已經上傳」。現場空著，紀錄卻敢寫日期。

---

負責改文件的 agent 把那一行改掉，說明裡寫：假的完成比缺漏更糟，它會讓人不再去看。缺漏至少還會催人補。寫成完成的那一行，會把下一次檢查停掉。我跟它說清楚：沒打開現場看過的勾選，都不算數。

同一晚快 3 點，GitHub 顯示某一包修改已經併進去，狀態全綠。它併進的是另一條還沒上主線的分支。主線上的付費畫面、審查說明要講的行為，都還是舊的。審查截圖也還沒進倉庫。若照著那盞綠燈打包送審，審查員拿到的說明會描述一個建置裡還沒有的行為。Apple 只看那一份建置，不會去讀我們的合併紀錄。

閘門改成直接讀主線上的程式，點名這次打包對應的那一筆，並用指令證明「有」和「沒有」兩種狀態都抓得到。今天的主線印得出該有的痕跡，合併前那一筆印不出來，兩頭都跑過。核對的是成品，不是成品的紀錄。

審查說明我先核准了文字。核准的是稿，不是今晚要上傳的那一份建置。稿裡的行為當時還掛在尚未進主線的修改上。閘門再加一層：送審前用正式建置把說明裡的每一步走一遍，對不上就改說明，改完我對那一份建置重簽一次。

補截圖時也差點留下另一種假完成。解鎖畫面第一次拍到的是未啟用的視窗，按鈕灰著。verify 用「三顆紅綠燈都要有顏色」判斷視窗在不在前面。設定視窗本來就沒有最小化和縮放，那兩顆永遠是灰的，這個標準在那張圖上不成立。我要的是購買按鈕跟付費牆同一種紅。改完重拍。我跟它說：你一次弄好，我就不用搞這麼晚。

同一晚 verify 清理測試，用「程序名稱叫 MarsDawn」去殺。連我從 Xcode 跑的那份也殺了。被除錯器抓住的程序不會死，只是停住，pid 還在。它回頭看，程序還活著，就回報一切正常。

凌晨我問付費牆為什麼出現兩次。我先偏向讓視窗負責邀請、遮罩只說這份文件鎖了。問清楚之後反過來：兩份文案一樣，為什麼還要按「解鎖」把同一份再叫出來。我說直接把遮罩拿掉。

那一下是我看錯。畫面上那份是「未命名」，狀態列寫著 0 個字。遮罩拿掉，後面本來就沒有字。遮罩擋的是文件內容。換成一份真的有字的文件，拿掉遮罩，鎖就沒了。

所以拿掉的是視窗，只留遮罩。代價我接受了。「稍後再說」跟著視窗消失。全新使用者要先開始試用才讀得到字，而試用要登入 App Store。沒登入的人，引導他去登入。Finder 的快速查看還是看得到，這句寫進審查說明。

清單自己也踩過腳。有一段寫「照順序做」，卻把「開始試用」排在「鎖定狀態下另存」前面。一開始試用，後面那項的前提就沒了。換帳號才有新的試用天數。已經用過試用的帳號，刪掉本機資料也換不回那 14 天。驗收的 agent 把鎖定檢查挪到試用之前，並標出要先準備第二個測試帳號。

寫了日期的「完成」，會把下一次檢查停掉。

收尾

截圖檔名進倉庫之前，我不再把「補圖」勾成完成。紙上全綠的那一晚，主線仍是舊行為。

先不說了，我得去主線上再對一次，這次打包到底帶了什麼。

這件事發生於 2026 年 9 月 21 日，文章整理於 2026 年 10 月。