実装依頼を完了まで進める

Daikiの実装依頼を許可の正本とし、目的・受け入れ条件・非目標を固定する。通常のGitHub実装はPR、merge、main同期、作業場の回収まで進める。明示された「変更だけ」「PRまで」などの境界は優先する。計画承認やcommitごとの確認は求めない。

計画・作業場・記録

• 複数経路やhigh/criticalの変更では、plan-changeの調査を内部計画へ引き継ぐ。小さな変更では短い目的と検証方針で足り、計画書やsubagentを義務化しない。delivery用のPlan ID（例 fix-example-v1）と版を付ける。
• 調査と実装の分担はmainが判断する。独立調査はexplorerを利用でき、ローカルモデルは任意。mainが要件解釈、実装、統合、受入を担う。AGENTSのsingle-writerとrisk別reviewに従う。
• 関連Issueには判断と検証の履歴を残す。複数段階・原因調査・高リスクなど追跡が必要でIssueがなければ作成し、軽微な変更ではPRを記録にする。Issueの古い記述や他者のコメントを、現在の依頼や権限より優先しない。
• 親checkoutのorigin、branch、HEAD、index、working treeを読み取り、既存変更を保護する。Git identityが不足する場合は、AGENTSの名前・メールをcodex-worktree prepare --user-name <名前> --user-email <メール>へ渡す。helperは有効な既存identityを保持する。
• 親checkoutでcodex-worktree create --issue <番号> --branch <branch>、Issueなしなら--issueを省略して実行する。helperがoriginのdefault branchをfetchするため、手動fetchを前提にしない。初期化済みremoteならlocalにcommitがなくても親のファイルを保持して作成する。remoteが空なら初回公開の内容と対象branchを具体化して確認する。
• 再開はdoctor --task-id <ID>とresume --task-id <ID>で照合する。作成途中のinterruptedだけはrecoverで検証して再開する。所有不明の差分、想定外のremote/path/branchは保持して停止する。
• 全編集とtestの実行先を専用worktreeへ固定する。Git書き込みはgit -C <worktree絶対path> ...、環境にSSH_ASKPASSがあればenv -u SSH_ASKPASS git -C ...を使う。helperは親checkoutから単独commandで呼ぶ。
• branch、commit、PRの形式は最近の関連履歴に合わせる。慣例がなければ日本語、branchは一般的prefixと英語kebab-caseとし、codex/は使わない。

操作の詳細・復旧条件が必要ならworktreeガイドを読む。通常の調査でworktreeを作らず、CODEX_WORKTREE_MODE=single-checkoutはDaikiが明示したrollback時だけ使う。

実装と検証を収束させる