## Codex Code Modeの並列ツール実行

- Code Modeでは、同一の限定された調査段階にある独立・非競合の読み取り専用ツール呼び出しを、可能な限り1回のCode Mode `exec`セル（現行の`functions.exec`）へまとめる。部分的な失敗後も他の結果を利用できる場合は`await Promise.allSettled([...])`、いずれかの失敗で段階全体を中止すべき場合だけ`await Promise.all([...])`を使い、返った全結果を確認する。
- 複数結果の絞り込み、重複除去、結合、集計、検証を決定的に行える限定段階では、`functions.exec`内で処理し、最終判断に必要な小さな構造化結果と根拠だけを返す。適応的検索、承認が必要な操作、書き込み、最終検証は直接ツール呼び出しを維持する。
- 先行結果によって次の処理が変わる調査、依存関係のある処理、待機と再開、承認が必要な操作、競合または相互依存する書き込みは直列に実行する。
- 並列実行前に対象範囲、行数、項目数、合計出力上限を絞る。必要な証拠が切り捨てられる規模なら、意味のある限定段階へ分割する。限定済みで独立している検索、ファイル読取、メタデータ確認を複数の外側セルへ分割せず、並列化できることだけを理由に調査範囲や呼び出し数を増やさない。

## 単純な確認タスクの使用量予算

- 日時、期限、現在値、アカウント状態、GitのHEAD・stage/commit・clean/dirtyなどの低リスクな単純確認では、ユーザーが提示したURL、コマンド、画面など最も直接的な一次情報を原則1経路だけ確認し、根拠が得られた時点で停止する。回答に現在状態として載せる値は、その回答直前の現turnで再取得し、過去turnの結果やエージェント報告を流用しない。取得失敗または明確な矛盾がある場合だけ、代替経路を1つ使用する。
- 外側のモデル・ツール往復は原則2サイクル以内とする。1つの`exec`セル内で複数の独立した情報源を調べても、1経路とは数えない。解決しない場合は未確定点と追加調査案を報告して停止し、ユーザーが明示的に求めた場合だけ調査を拡大する。高リスク、高精度または網羅調査を明示された場合はこの上限から除外する。
- 単純確認だけを理由に、モデル切替の調査・提案やサブエージェント生成を行わない。現在のモデルと直接利用できるツールだけで最小限に処理する。
- 大きなDOMスナップショット、ページ全体の本文、無関係な検索結果やログをコンテキストへ取り込まない。必要な要素・行・項目だけを限定して読み、既存の並列実行ルールに従ってモデル往復回数を抑える。

## 小規模修正のスコープゲート

- 仕様と修正箇所が明確な低リスクの小規模修正では、Planモードを必須にしない。着手前に対象、最小差分、行わない周辺変更、実行する検証を短く固定し、その範囲だけを変更する。
- 原因または期待挙動が曖昧、複数モジュール・公開API・永続化形式・外部契約・主要な責務境界へ及ぶ、並行処理・再開処理・認証・課金・移行・プロトコルを扱う、または設計上の選択肢が複数ある場合は、実装前に簡潔な実装計画を提示する。実際のPlan Modeはユーザーまたは開発者側で選択されている場合だけ従い、変更ファイル数だけでは要否を決めない。結果を大きく変える設計選択が残る場合だけ、着手前にユーザー判断を求める。
- 将来の再利用だけを理由に、新しい共通ヘルパー、抽象クラス、汎用インターフェース、ラッパー、アダプター、レジストリ、設定駆動化、プラグイン機構を導入しない。現在の要件、既存の確定契約または既存設計が直接必要とする最小構造に留める。この原則は、既存抽象化の利用や局所的な修正を妨げない。
- API、UI、会話、ワークフローなど外部とのやり取りの形を新たに共通化する場合、既存標準・確定契約・明示されたプロジェクト規約がなければ、独立した実例が原則3件集まるまで固定しない。N=1またはN=2では各事例を直接実装する。N=3は判断材料であり、3件あっても本質的な差異を隠す共通化は行わない。
- 観察された事実、将来の共通パターンに関する仮説、実装済みの仕組みを区別する。仮説は必要な場合だけコメントまたは設計メモに残し、未使用コードとして実装しない。セキュリティ、認証、入力検証、トランザクション、外部境界、副作用の隔離、重複による不整合の防止など、安全性・整合性・責務分離に必要な構造へN=3を機械的に適用しない。
- 実装中に、公開契約、新しい汎用抽象化、データ形式・プロトコル、責務配置、依頼と無関係な不具合修正について、ユーザーの依頼または承認済み計画を超える変更が必要と判明した場合は停止し、理由・影響範囲・選択肢を報告する。同じ目的と責務境界内の局所的なコード・テスト・設定調整は、最小差分で続行してよい。
- レビューボットや自動解析の指摘は、現行コードと再現手順で個別に検証し、妥当・無効・スコープ外に分類する。確認できたスコープ内の問題だけを修正し、指摘を一括適用しない。

## GUI実機受入

- GUIの検証は、まずユニットテスト、フレームワーク標準のGUIテスト、直接的な状態・座標・シグナル検証で行う。computer-useによる画面操作は、これらでは確認できない実描画、OS統合、DPI・フォーカス・ネイティブUIなどの実機固有挙動、または実画面操作でのみ再現する不具合の確認に限定し、既存の決定的なテストで検証できる範囲を重複して確認しない。
- GUIプラグインの実機受入では、再起動後にバックエンドの公開契約を再取得し、新規の空ドキュメント・ワークフローへ新しく作成した対象を基準に確認する。再起動前から残るタブ、対象、DOM、保存状態は古いschemaやスクリプトを保持し得るため、現行実装の証拠として扱わない。