rpi

RPI

認可された成果を完了まで担当します。RPI（調査、計画、実装）は固定されたフェーズではなく、ネイティブな一連の作業です。ネイティブのコーディングエージェントとシェルを使用します。 作業と引き継ぎはBDまたは依頼者のトラッカーが管理し、コンテンツと納品はGitが管理します。AgentOpsは、スケジューラーではなく、小さな指針と、誤りが大きなコストにつながる場合の新鮮な判断を一度提供します。

運用指針

1. 既に合意された成果、スコープ、実際の制約を使用します。変更内容が明確であれば、Plan、Recall、Learnのワークシートは不要です。不確実性の解消は、実装または受け入れ判断に影響する可能性がある場合に限ります。
2. 受け入れに向けて最小限の行動を取ります。計画は、意図が不足している場合や、誤りが判明したアプローチを見直す場合に役立ちます。実装者が作業でき、バリデーターが判断できる状態になったら、実装してください。計画を改善し続けてはいけません。アプローチの見直しでは、受け入れ条件と認可されたスコープを維持します。 受け入れ条件の変更には、依頼者の権限が必要です。
3. 実装し、既知の通常の不具合は直接修正します。既知のテスト失敗には、別の計画フェーズや協議会、ヘルパーではなく、修正と、問題を識別できる確認が必要です。
4. 編集中は対象を絞ったチェックを行い、完了前に必要な統合チェックをすべて実施します。入力に変更がない間だけチェック結果を再利用し、変更の影響を受けるチェックは変更後に再実行します。統合と修正のための余力を確保します。評価中は対象を変更しないでください。
5. 誤りが大きなコストにつながる場合に検証を行います。通常の変更では、チェックとCIがゲートです。完了してください。依頼者が求めた場合、公開後に容易に元に戻せない誤りがある場合（公開リリースやユーザーが従う手順、セキュリティ境界、データやトラッカーの状態の破壊、製品を保護するチェックの削除など）、または変更した動作を網羅する決定的なチェックがない場合に限り、執筆者とは異なる新たなコンテキストを1つ使って検証を行います。依頼者が追加の評価担当を選択しない限り、執筆者と同じモデルファミリーを使用します。明示的に必須とされたレビュー担当者は引き続き必須です。
6. 1ラウンドのみです。バリデーターには、合意された基準、正確な対象、開始前に書いた質問を1つ渡します。執筆者の確信度や望む判定は決して伝えず、チェックの再実行も依頼しません。合意された動作を満たさない場合、ユーザーを誤解させる場合、インストールやCLIを壊す場合、または製品の保護を取り除く場合は修正し、それ以外は任意の指摘として扱います。各修正をチェックで確認して完了します。修正を理由にレビューをもう一度始めてはいけません。また、NOT_PROVENは不足点を添えて報告し、追い続けないでください。レビューのコストは作業コストの一部にとどめます。作業コストに近づいたら停止し、未チェックの内容を報告します。
7. 受け入れ完了、キャンセル、拒否、実際の制約の使い切り、依頼者の判断待ち、または以下の支援を経ても解決しない因果的な停滞で停止します。合意された成果が依存する選択肢が既存の権限を超える場合（受け入れ条件の変更、スコープの拡大、対象外の不可逆な手順など）、それは依頼者が判断することであり、停滞ではありません。そのため、ヘルパーは適用されません。認可された独立した作業を完了してから停止し、判断を待たずに依頼者へ返します。何がきっかけだったか、何が分かったか、各選択肢とそのトレードオフ、および推奨案をすべて引き継ぎます。件数やリンクだけでは引き継ぎにならず、選択肢が未決の間、結果をdoneとしてはいけません。隣接する改善は、目標を広げる許可ではありません。役立つ場合に限り簡潔に報告し、別の作業単位にしてはいけません。

委任と引き継ぎ

委任が許可されており有用な場合は、独立した作業にはランタイムのタスク専用ディスパッチオプションを選択します。全履歴を引き継ぐフォークでは、短いプロンプトでも履歴全体が引き継がれます。また、プロンプトの文面だけでは、隔離されていることも、引き継がれるコンテキストが小さいことも証明できません。受け入れられた意図と範囲、正確な対象、関連する証拠、残りの制約、結果を利用する人、およびチェックの担当者を提示します。有用であれば、作成者に再開を依頼して直接修正してもらいます。完了時には、想定した対象と必要な結果を確認します。応答がない、または部分的なステータスは成功ではありません。委任した作業は、Implement の説明に従って統合し、不足または切り詰められた証拠があれば、既存の引き継ぎ情報に開示します。

因果関係に基づく停滞と制約

停滞は回数ではなく、観測した内容で説明します。

• 原因不明：チェックが失敗し、その出力にも差分にも、特定できる変更や前提が示されていません。
• 再発：修正後に合格したチェックが、同じ原因で再び失敗します。
• 進捗なし：前回の試行以降、失敗したチェックの出力と差分に変化がないか、委任先の作業者が最後に活動を確認して以降、確認できる活動に変化がありません。
• 目的の相違：依頼者からの訂正、または受け入れられた例のチェックにより、受け入れ条件が求めていない内容に取り組んでいることが分かります。

この4つのいずれの場合も、権限と制約の範囲内で、その事案について新たなヘルパーを1つだけ限定的に利用できます。解決しない場合は、停滞した結果に観測した事実を記載します。 失敗した前提、証拠、および原因を切り分ける質問を1つ提示します。検証可能なアプローチを変えた場合にのみ再開します。役に立たない回答が返った場合は、試行を終了します。ヘルパーを連鎖させたり、事案の名前を変えたりしてはいけません。原因が判明している失敗は直接修正します。キャンセル、拒否、またはハードタイム／コスト／クォータの超過がある場合は、支援を利用しません。

明示された修正ラウンドの上限を含め、依頼者またはネイティブ環境の実際の制限を守ります。再試行、コンパクション、ヘルパー、新しい対象によって制限が更新されることはありません。再試行回数だけでは予算を使い切ったことにはならず、プロンプトの文面だけではネイティブな強制が行われていることを証明できません。中断によって証拠が失われるおそれがある場合は、受け入れられた意図、正確な対象、チェック結果、未解決の原因、制約、およびヘルパーの利用状況を、ネイティブな引き継ぎ情報に保持します。 外部目標に関するガイダンスは任意です。

証拠と境界

バリデーターを使用する場合は、受け入れられた意図、変更されたパスの全件、正確な対象、およびチェック結果を、Validate の対象ルールに従って結び付けます。未コミットの作業については、ステータス一覧とファイルハッシュも含めます。 リポジトリで AgentOps の証拠バインディングが記録されている場合は、ao provenance evidence-orphans --root <repo> --changed <path>... を実行し、孤立していると報告された受け入れ証拠を開示します。求められた証明は、依頼者が指定する Git 外の保護されたストレージに保存します。既存の .agents/ の証拠は保持してください。Validate の判定順序に従って、要求されたバインディングの判定が決まります。作成者はその判定を出せません。

Memory、専門家、およびランタイムアダプターは必要に応じて利用します。一致するものがない場合や変更がない場合も、有効な結果です。権限、範囲、証拠、または成果物の引き渡しが問題になる場合は、境界を確認します。通常の変更を完了するために、ランタイム、隠れたマシン成果物、またはワークフローを捏造してはいけません。

クローズアウト

次の形式で報告します。計画、作業内容、レビュー、保存したページは能力の評価対象になりません。また、未チェックの項目は報告するものであり、検証を続ける理由にはなりません。rpi-report.v1 や verdict.v2 などの機械可読な証拠は、呼び出し元または宣言済みの利用者が必要としない限り任意です。機械可読な成果物が要求も必要ともされていない場合は、作成せずに結果を返します。

Result:      done | stopped: <cancelled | refused | needs decision: <choice> | bound spent | stalled: <unknown cause | recurrence | no progress | wrong objective> - <observed fact>> | NOT_PLANNED | NOT_BUILT
Subject:     <commit, branch or diff identity>
Acceptance:  <criterion> -> <evidence: check, receipt or ref>, one line each
Checked:     <checks run on the final subject, with results>
Not checked: <what was not run or not covered, and why> | none
Judgment:    none (checks and CI gate an ordinary change) | <validator context id>: PASS | FAIL | NOT_PROVEN
Limits:      <material gaps; each open decision in full; departures from the literal ask, one line with its reason each; adjacent work noticed but not done> | none

逸脱とは、権限の範囲内で行われた、呼び出し元が把握しておきたい判断です。たとえば、依頼とは異なる方法で構築すること、指摘を拒否または異議申し立てすること、実行中の指示に従うことが該当します。通常の修正は含めません。そのような判断がなければ、何も追加しません。

NOT_PLANNED（実行可能な作業単位が存在する前に停止）と NOT_BUILT（変更候補が存在する前に停止）は、進捗を表すものであり、意味上の判定ではありません。

rpi-report.v1 が要求されている場合、その status は、最終対象に対して Judgment が実行された際のバリデーターの判定です。それ以外の場合、報告されたとおりに NOT_PLANNED または NOT_BUILT とし、最終対象に対するチェックで基準の不合格が証明された場合は FAIL、それ以外のすべての Result（done を含む）は NOT_PROVEN とします。PASS は決して使用しません。checked と not_checked を記入します。ランタイムが導出しなかったフィールドと、バリデーターが実行されなかった場合の両方の判定フィールドは null とします。