這幾天主要在處理兩件「我以為沒問題，結果被擋下或填錯」的事：一個 App 送去審核被退回，以及它幫人記錄的時間被填錯欄位。另外替一個抓商品資訊的工具多接了幾家商店。
App 送審被退回，原因是少寫一句話
LiveHashigo 是一個用語音登記演出場次的 App。我送去 Apple 的版本被退回，理由是沒有說明「為什麼要讀取相簿」。
但這個 App 根本不讀相簿。是裡面用的兩個現成零件，它們的程式碼裡有相簿相關的呼叫，審核系統看到就要求說明。這像是你沒進廚房，但請來的外包廚師帶了一把需要登記的刀，你照樣要填申報單。
我補上一句誠實的用途說明，重新送出後，新版本已處理完成，進入準備提交測試的階段。商店頁的截圖也多輸出了一組尺寸，因為上傳頁預設欄位只收較小的那一種。
用了別人的零件，零件要求的聲明也算在自己頭上。送審前把零件帶來的聲明清單過一遍，比被退回再補快得多。
技術細節：ITMS-90683 與截圖尺寸
build #17（1.0.0 (3)）處理失敗：缺 NSPhotoLibraryUsageDescription。 引用來源是 expo-image、expo-file-system 的原生碼，比照 NSMotionUsageDescription 寫一句說明。 build #18（1.0.0 (4)）已在 ASC 處理完成。 截圖：ASC 版本頁預設欄位是 6.5 吋，不收 1320×2868；export 腳本加 —size 6.5，輸出 1284×2778。
講「18點開始」，App 卻記成開場時間
演出有兩個時間：開場是放觀眾進場，開演是正式開始。使用者在實機上說「18時から」（18 點起），AI 把它填進開場，開演欄卻空著。沒講出演者時，它還填了「未指定」，像是真有這個名字。
這像請人代填表格，你說「六點開始」，他卻寫在「開門時間」那欄。
我分三層處理。給 AI 的指示改成：只有明講「開場」才填開場，只有一個時刻或帶「から」就是開演。程式在存檔前再檢查一次，若只有開場、原話又沒提開場，就移到開演。「未指定」也改當成空白。修正已用不經商店審核的線上更新推出，但尚未在實機驗證。
只靠叮嚀 AI 守不住規則，要在它後面再放一道程式把關。實機上聽錯的原句，也值得留作之後的測試案例。
技術細節：VOICE-40 三項修正
修正 1：logic/instructions.ts 加 SHOW_START_LINE，開場只填講了「開場」的時刻。 修正 2：sourceCheck.ts 的 promoteLoneDoorsOpen 把只有開場的情況移到開演；開場等於終演（「〜まで」）不移。 套用順序在 cleanEntry 之前，AI 對話與代勞新增路徑共用。 修正 3：「未指定」列入佔位字。 首次 OTA 已推至 build #18 的 production，VOICE-40 狀態為待驗。
專屬規則要排在通用規則前面
plurkpost 是一個抓取網路商店商品資訊的工具。這次替它加了三家商店。
其中一家原本被工具當成另一種常見的通用商店，結果去錯地方找，回了「找不到頁面」。像郵差看地址格式像某一區，就直接送錯區。我把這家的專屬規則排到通用規則前面。
另一家用的是舊式文字編碼，品名開頭還夾著出貨時間。我把出貨時間抽成獨立欄位，品名只留名稱。驗收時另外派一個獨立檢查者，比對網站上的商品件數，並抽查品名、價格與販售狀態。
通用規則該放最後當備案。順序錯了，它會搶先認錯人，而且回報的錯誤看起來像網站壞了。
技術細節：新增的三支爬蟲
維護看板 B-48、B-49、B-50：noitamina.js（カラーミーショップ，EUC-JP）、amocafe.js（EC-CUBE 3）、vvit.js（futureshop）。 amocafe.js 在註冊表排在 shopify 之前，避免被通用 shopify 誤匹配而回 404。 noitamina 品名開頭的出貨時間抽進 deliveryDate 後從品名刪除。 驗收件數為 71／20／443，註冊表與故障注入測試設定已加入三支爬蟲。
接下來
- 在實機確認語音填寫的修正有效。
- 決定如何處理「AI 功能不是所有裝置都能用」的送審風險，目前待裁決。
- 把新版本送進測試版發佈。
本篇由跨專案自動彙整產生，素材為 2026-10-02 之後 4 個專案的提交紀錄與 0 則知識投遞。