implement

実装

承認された成果を実装します。既知の通常の不具合は直接修正します。意図が明確な編集なら、先に計画を立てる必要はありません。実装ではソース変更と事実確認を担当します。変更したパスは Git から読み取ります（git status --porcelain、git diff --name-only <base>）。記憶を頼りにしてはいけません。 ao provenance manifest --root <repo> では、宣言したパスのみをダイジェスト化するよう、パスごとに --include <path> を指定します。このコマンドは Git を実行しません。チェック結果はコマンド出力から転記します。

結果を決めるルール

• 判定基準ではなく原因を修正します。 チェックを成功させるために、アサーション、許容誤差、ゴールデン、フィクスチャ、抑制を緩めたり、モックやプレースホルダーに置き換えたりしてはいけません。また、チェックの対象を変更してはいけません。たとえば、テストや CI で異なる動作をするコード、新たに黙殺された失敗経路、ブロック対象でなくなったチェックやスキップされたチェックが該当します。承認済みの動作に対して失敗するチェックは、製品の不具合を示しています。チェックが受け入れる内容を変更することは受け入れ条件の変更であり、呼び出し元の権限が必要です。
• 編集前に利用中の呼び出し元を見つけます。 編集する関数、型、パス、形式、メッセージについて、呼び出し元、読み取り側、スクリプト、ドキュメント、テストを検索します。それぞれについて、変更の影響を受けるか、どのチェックで確認するかを明記します。廃止または名称変更する場合、利用者にはインストール、参照、旧名称での呼び出しも含まれます。過去の来歴は保持します。置き換え対象のインターフェースがマージもリリースもされておらず、すべての利用者の更新がスコープ内に収まる場合は、同じ変更で利用者を更新して旧バージョンを削除し、エイリアスやシムは残しません。それ以外の場合は、旧バージョンの動作を維持するか、その旨を報告します。
• 差を見分けられるチェックを明記します。 動作変更では、期待される動作が欠けている状態を示す RED を維持します。つまり、編集前は失敗し、編集後は成功するチェック（テストの証明ルール）と、影響を受ける各利用者に対するチェックを明記します。
• 実行した内容だけを報告します。 正確なコマンドと結果を示します。実行しなかった、または実行できなかったチェックはすべて未実行として列挙します。未実行の作業を検証済み、修正済み、成功と表現してはいけません。コマンドの実行後すぐに出力が表示されることがあるため、コマンドを組み立てる際に秘密情報が漏れないようにします。認証情報は環境内にとどめ、トークンを含む可能性がある出力はファイルに保存し、伏せ字にした抜粋だけを表示します。

公開されている失敗経路を変更する場合は、その経路本来の失敗シグナルを維持し、復旧に関する案内がすでに行った作業と一致していることを確認します。書き込み結果が不確かな場合や無人の呼び出し元では、テストのエラー復旧手法のうち関連するチェックのみを使用します。

承認済みの範囲限定の近道、レビューのフィードバック、変更によって発生した不具合、承認済みのコミット、履歴の書き換えやマージ競合、依存関係のアップグレード、削除、ブロックされた操作、別のツールの状態から読み取った判断、自身の不確かな書き込みについては、変更安全性の手法のうち該当するもののみを使用します。これらの手法は既存の権限を維持するもので、新たな操作を許可するものではありません。

承認済みのサービス操作では、運用手法から関連する手順（信頼性、デリバリー、インシデント復旧、レジリエンス、トイル）のみを読み込みます。通常の編集で運用フェーズを実施する必要はありません。

ワークフロー

1. 最初に書き込みを行う前に、意図、受け入れ条件、スコープ、リポジトリの境界を確認し、読み込み済みの契約を再利用します。RPI が選択されている場合はRPI の境界が適用されます。呼び出し元が選択したエピソードの追跡には、セッション関連付けのリファレンスに従います。リビジョンと、すでに変更、ステージ済み、または未追跡のファイルを記録します。変更したものとして報告するのは自分の変更のみとし、他者の編集を含むファイルを編集する前に呼び出し元に確認します。
2. 受け入れ済みの動作例は変更せず、そのまま引き継ぎます。シンボルとテストには、リポジトリのドメイン名を使用します。関連するインターフェイスを通じて、観測可能な結果を確認します。編集の前後に、該当する最小限のチェックを実行します。純粋なリファクタリング、移動、またはドキュメントの変更では、ベースラインが問題なく通る場合があります。既存のテスト、または小規模で判別力のあるプローブを優先します。
3. スコープ内で最小限の変更を行います。検出やチェックを修正する際は、利用側で既存の入力選択方法を維持します。エラーパスの修正は、スキャン範囲を広げる許可にはなりません。除外が重要な場合はネガティブコントロールを使用します。広範囲に適用する前に、代表的な変更を既存の制約に照らして確認します。また、大規模な再生成の前に、作成元のソース一式を確認します。複数ファイルにわたるスクリプト編集では、各アンカーがちょうど1回一致することを事前に確認します。一致が0件または複数件の場合は何も書き込まず、改めて導出します。既知の失敗は直接修正し、チェックで正確な結果を検証します。修正を理由に別のレビューを開始することはありません。前提が誤りだと判明した場合は、スコープ内で方針を変更できます。重大な不確実性がある場合に限り、Plan を使用します。
4. 記憶から再構成するのではなく、計測機能や環境を含む、リポジトリに実際に記載されたチェック手順を確認します。広範な統合の前に、対象を絞ったテストとリンター／静的チェックを実行し、統合時には必須の全チェックを実行します。ソース、ツール、関連する環境が一致する場合に限り、完全に同一の入力に対する実行記録を再利用します。必須フックを回避したり、実行記録の名前を変えるだけのためにチェックを再実行したりしてはいけません。必須 CI ジョブの既知の失敗は、実行が終了する前に対応が必要です。スコープ内で修正し、失敗した対象の証拠を保持したうえで、影響を受けるチェックを再実行します。保留中のジョブは成功を意味しません。新しいチェック、フック、またはリンタールールは、集約コマンドまたは CI が実行し、意図的な違反で失敗する場合に有効とみなされます（Git フックにはインストール手順が必要です。.git/hooksはクローンされません）。それ以外の場合は、配線されていないものとしてgapsに記載します。ポート上で稼働中のローカルサーバーは、このチェックアウトを提供していると確実に証明できる場合に限り使用します。停止するのは自分が起動したプロセスのみです。
5. 受け入れ条件が引き続き満たされる範囲でリファクタリングします。引き継ぎの前に、変更したテスト、フィクスチャ、ゴールデンファイル、許容値、抑制設定、仕様テキストが当初の意図に沿っているか確認します。その意図は要約ではなく、元の記述を読み直して確認し、未追跡ファイルも含めて差分全体を照合します。放棄した方針の残骸、一時的なプローブ（共有マーカーを1つ使用すれば、検索1回で残っていないことを証明できます）、チェックによって生成されたファイルを削除します。説明できないパスがあれば、スコープの変更としてgapsに記載します。
6. 実際に変更されたパスとコンテンツの識別情報は、ランタイムに導出させます。統合待ちの委任済み変更では、既存の引き継ぎ情報に、正確なコミットまたはランタイムが導出したコンテンツダイジェスト、作成者のコンテキスト ID、チェックの事実を記載します。その ID は、ランタイムが公開するセッション、サブエージェント、またはスレッドの ID から取得します。呼び出し元から提供された ID は、提供されたものと明記します。それ以外は不明として報告し、決して捏造しません。統合を行う呼び出し元は、判断を下す前に、最終対象全体についてsubject-manifest.v1を導出します（AgentOps スキーマsubject-manifest.v1.schema.json、AgentOps ソースチェックアウトのみ）。独立して判断する変更には、独自のマニフェストが必要です。作業を委任したという理由だけで、両方を生成してはいけません。リポジトリで AgentOps の証拠バインディングを記録している場合は、導出された各パスに対して--changed <path>を1つ指定し、ao provenance evidence-orphans --root <repo-root>も実行します（これは参考情報です）。実際の出力を保持し、修正後にフラグが付いたバインディングを更新します。aoがない場合は、未実行としてnot runに記載します。
7. 次の引き継ぎを返し、その後は終了します。

引き継ぎ

すべてのログは元の場所に保持し、インベントリやステータス文書を複製しないでください。

changed:   <runtime-derived paths>; identity: <commit or content digests>
author:    <runtime session/subagent/thread ID, "ID (supplied)" or "unknown">; when an integrator or fresh read follows
checks:    <exact command> -> <result>, one per line; before and after for a behavioral change
not run:   <check> -> <reason>; "none" only when every relevant check ran
consumers: <file:line> -> <covering check, or "uncovered">
gaps:      <missing or truncated evidence, known failures, scope amendments needed>
cause:     <defect repairs only: trigger -> mechanism -> symptom at file:line; sites left as follow-up>

未対応の実稼働コンシューマーがあれば報告して、呼び出し元のスコープ修正を求めるとともに、独立して許可された作業を続けてください。元に戻せる実装上の選択を開示するのは、その代替案に呼び出し元が変更を望む可能性のある重大な影響がある場合に限ります。固定のワークシートは使わず、引き継ぎでは選択内容、代替案、その理由を明記してください。スコープに含まれる生成された付随物には新たな承認は不要ですが、合意済みの方針、動作、または受け入れ条件の変更には、常に呼び出し元の承認が必要です。

診断、足場づくり、委任作業

原因不明の失敗については、修正に取りかかる前に診断ループに従ってください。失敗した実行が想定したコードを実行していることを確認し、観察結果を根拠に有力な原因を特定し、その最有力の対抗仮説を挙げ、両者の予測が食い違う点を1つ検証してください。同じファイルに、競合、状態の漏洩、ハング、リグレッション、コンポーネントをまたぐ失敗に対する実験方法も記載されています。

足場づくりが依頼された変更である場合は、リポジトリの既存レイアウト（新規プロジェクトの場合はそのエコシステムの標準レイアウト）と、動作する垂直スライス1つから始めてください。プレースホルダーの成功経路や、単発処理のための新たなフレームワークは避けてください。インストーラー、エージェント向けツールサーバー、またはローカル状態を扱うRust CLIについては、エージェント向けツールの足場を参照してください。

現在のセッション内での実行を優先してください。委任が許可され、有用な場合は、Agent Nativeの説明に従って、並行する書き込みを互いに重ならないよう分離してください。共有ジェネレーターと統合作業は直列化してください。各作業レーンには、意図、受け入れ条件、スコープ、レビュー担当者を伝え、その正確な内容を統合して事実を確認してください。選択した作業波は、呼び出し元が求めた結果をもって終了します。次の作業波を勝手に追加しないでください。未判定の変更分は、統合候補に対する新たなレビュー1回で確認できます。統合担当者がそのレビューを行う場合、作業者は別のレビューを依頼せずに引き継いでください。個別に要求された作業レーンの判定は維持してください。プロセスが正常終了したことは、意味上のPASSを示すものではありません。

明示的に依頼されたワンショットアダプターは、提供された各操作を1回ずつディスパッチし、その出力またはエラーを報告して停止します。スケジューラー、リトライコントローラー、ストアは設けません。ドライランまたはフィクスチャを使って、ディスパッチ回数と失敗時の報告を示してください。ファクトリーの採用には、呼び出し元の選択が必要です。

完了

スペシャリストは助言のみを行います。既知の欠陥は、引き続き実装作業として扱ってください。実際の因果的停滞がある場合に限り、RPIの停滞ルールに従って、範囲を限定した新たなヘルパーを1人だけ認めます。再試行しても上限は更新されません。

意味上のPASSではなく、事実を返してください。実装のみの引き継ぎは、Git、トラッカー、またはデリバリーのステータス遷移を許可するものではありません。ただし、呼び出し元がすでに持つ権限は引き続き使用できます。完全な成果を求められた場合は、要求されたチェックとCIをもって完了します。Validateのトリガーに該当する場合に限り、新たに独立した判定を1回得るところまで進めます。成功とは、利用可能な証拠に支えられた動作であり、ログやプロセス成果物の量ではありません。