実行中のタスクのAIモデルを変更することは、単純な設定更新ではなく、分散オペレーションです。現在のタスクの読み取り、認証情報の準備、再起動のリクエスト、結果の受信、アクティブなモデルの永続化が含まれます。複数のモデル切り替えリクエストが重複する場合、完了順序はリクエスト順序と異なる可能性があり、どのインテントが優先されるかを決定するためのルールが必要になります。MonkeyCodeシステムは、モデルIDやリクエストIDなどの詳細とともに、モデル切り替えの試みを記録します。典型的なワークフローには、切り替えレコードの作成、タスクフローへの再起動の要求、そして切り替えレコードの完了が含まれます。しかし、ソースレビューでは、重複するリクエストに関する明示的な比較交換生成やタスクごとのシリアライゼーション契約は確立されていませんでした。「最後に完了したものが勝つ」アプローチの不安定性は、ネットワークタイミングにより、後から行われた成功した完了が前の完了を上書きしてしまうシナリオによって実証されています。コンパニオンシミュレータは、この順序依存性を視覚化し、呼び出し元の最新のインテントが本質的に考慮されていないことを示しています。これを解決するために、各リクエストに一意の生成番号を割り当てるモノトニック生成が提案されています。システムは、完了の生成がタスクの現在の要求生成と一致する場合にのみ、アクティブなモデルを更新する必要があります。この生成ガードは、後から完了した場合でも、古いオペレーションが適用されないことを保証します。生成ガードは、重複リクエスト、競合リクエスト、遅延成功、再起動失敗、プロセスクラッシュ、セッションロード、認証情報バインディングの契約を定義する必要がある包括的なプロトコルの1つの部分にすぎません。タスクごとのロックなどを使用したシリアライゼーションは代替手段ですが、リース期限切れや公平性などの複雑さを導入します。単体テストでは、さまざまな段階でのオペレーションの制御されたインターリーブにより、このプロトコルを検証する必要があります。不変条件は、アクティブなモデルが常に、最も大きい非却下された生成に対する成功した結果に対応することです。モデル切り替えをプロトコルとして扱うことで、UI、監査記録、リトライ、永続化全体で一貫性を確保します。