這一週我在做美甲預約 App 的上架前整修，也修了一個被日本網站擋住的商品抓取工具。這些事的共同點，是畫面上看到的內容要和實際狀況一致。
修一個壞掉的按鈕，也要檢查所有長得一樣的按鈕
Nailora 是一個讓人找美甲師、線上預約的 App。我在實機上發現作品頁右上角的「⋯」被橫向拉長，像被壓扁的麵團。原本的修正只補了部分頁面，就像水管漏水只換掉一個接頭，其他同款接頭照樣會漏。
現在整個 App 頂端左右兩側的按鈕，都改用 iPhone 系統內建的按鈕。我也讓自動檢查程式逐頁、逐側核對，漏掉任何一處就會報錯。
下次修一個毛病時，順手寫一條規則去掃所有同類的地方。只修眼前那一處，同樣的問題會在別的頁面再出現。
技術細節：HF-049 導覽列按鈕全面改原生
app/ 下 29 檔的同一個 options 物件，同側並列 Android 用的 HeaderButton 與 iOS 用的
type: 'button'SF Symbol 原生項目，onPress 逐字相同。scripts/check-header-stability.ts的 H2 規則改為全檔逐側計數相等，並禁用type: 'custom'。 修前該檢查 exit 1，修後 exit 0。
資料還沒到，畫面就不該先給答案
店家頁的日期列，用符號標示每天還有沒有空位。原本資料尚未載入時，畫面會依營業時間先擺上「○」。這好比餐廳門口先掛出「有位」，裡面其實客滿。
現在資料沒到就不顯示符號，今天已過截止時間顯示「—」，剩下很少顯示「△」，抓取失敗會明確提示。搜尋結果的店家卡片也改抓真實空位，不再自己推算。
畫面要分清三種狀態：載入中、抓取失敗、確實沒有。資料沒到時留白，比放一個看似有答案的圖示誠實。
技術細節：5-10 空位日期列語義修正
lib/availability.ts的computeDayAvailabilityAny改為回傳 holiday／ended／full／few／available，並以最短菜單時長判定。lib/api/bookings.ts新增getShopDayStrip（短 TTL cache），店家頁與 ShopSearchCard 共用。lib/calendar.ts的buildNext14Days移除營業時間推算的 ○。
網站擋住伺服器時，讓操作者的瀏覽器代跑一趟
這個工具會抓日本商品資料，整理成開團貼文。animate 購物網站依 IP 封鎖台灣與雲端主機，等於社區警衛只放住戶進門，外送員一律攔下。原本畫面只顯示看不懂的「403」。
現在被封鎖時，畫面會直接說明原因。抓取改由 Chrome 擴充功能「發文工具小幫手」負責：操作者開日本 VPN，用自己的瀏覽器取回網頁，交給網站解析。
被擋時先弄清楚擋的是身分還是所在位置，再決定繞路或放棄。錯誤訊息也要說出原因，否則使用者只能猜。
技術細節：B-56 animate 小幫手
偵測封鎖頁後丟出 code
ACCESS_RESTRICTED，列表、單品、詳細三條路徑皆涵蓋。 擴充功能為 Chrome MV3，只 GET animate 兩個網域，只接受正式站與localhost:3000呼叫，ID 由 manifest key 固定。 打包用scripts/pack-helper.js。
送審前，替審查員備好一間可以逛的店
App Store 審查員不認識這個 App，也沒有我的帳號。我在線上資料庫建了審查專用的店家與顧客帳號，預先放好預約、訊息與評價，密碼存在專案之外。隱私權政策也補上店家資料的保存說明，並做好宣傳截圖。
送審時給審查員一個登入就能走完主要流程的帳號，並寫明已知限制，審查才不會卡在空白畫面。
技術細節：SUB-3 審查帳號
帳號為 appreview.shop／appreview.user@nailora.test，示範店名為「Nailora 示範美甲」。 流程與已知限制寫在
docs/release/review-accounts.md，內含 ASC Notes 底稿。
接下來
- 空位日期列與導覽列按鈕的修正，等我用實機驗收。
- 小幫手擴充功能在正式站的實際表現尚未驗證，需要開日本 VPN 實測。
本篇由跨專案自動彙整產生，素材為 2026-10-05 之後 7 個專案的提交紀錄與 0 則知識投遞。