operationalize

運用化

繰り返し現れる、出典で裏付けられた専門知識を、再利用可能な成果物の提案にまとめます。

1. 専門知識には、出典で裏付けられた証拠を必須とします。実際に発生した事例、または明示的で権威ある情報源が必要です。ただし、ルールを抽象化する提案には、以下の最低3事例の条件が適用されます。
2. 発動する状況、望ましい動作、入力、出力、否定例、証拠を明示します。
3. 形を選ぶ前に、プロセス成果物の作成ゲートを適用します。提案する証明書、台帳、ダッシュボード、マトリックス、メタレポート、準備状況レビュー、推測的なチェック、スキル、ワークフローには、それを具体的に利用する人、ゲート対象となる主題またはリリース判断、その作成を正当化する観測済みの欠陥クラス、削除条件を明記する必要があります。成果物を利用することだけを目的に導入するコードやプロセスは該当しません。いずれかの回答が欠けている場合は、成果物を提案せず、呼び出し元が求めた主題に戻します。名前の付いた証拠喪失または破損のモードを防ぐために必要な場合に限り、最小限の完全性維持または復旧の状態を認めます。
4. 目的に合う最小の形を選びます。リファレンス、スキル、決定論的チェック、または呼び出し元が所有するワークフローのいずれかです。
5. 既存の機能を検索し、重複より拡張を優先します。
6. 有効化の例、保留例または否定例、所有者、ロールバックまたは削除条件を提示します。
7. 提案は、呼び出し元または作成担当のスペシャリストにインラインで返します。呼び出し元が永続的な成果物を求める場合は、まず .agents/scratch/operationalize/ に書き込み、パスを返します。いずれの場合も、提案は参考情報です。

最低3事例の条件

ルールを抽象化するには、実際に発生した事例が3件必要です。実際に発生し、引用可能な事例、つまりこのリポジトリ内で確認できるセッション、差分、判定、成果物のみを数えます。仮定上の事例や、1つの出来事を言い換えたものは数えません。事例が1件または2件の場合は、引用箇所に紐づくリファレンスノートを提案するにとどめ、ルール化はしません。明示的で権威ある情報源は、その内容を文字起こしし、それを超えて一般化しない提案に限り、事例の代わりとして使用できます。名前の付いた失敗モードは、早すぎる抽象化です。印象的な単一の事例からルールを作り、その事例固有の偶然の要素をポリシーとして定めてしまうことです。

再適用の証明

提案する各ルールには、再適用の証明を含めます。つまり、そのルールが、追加の文脈なしに、出典となった事例の少なくとも1件で正しい判断を再現することを示します。作成したルールをその出典となる時点に適用するのに、書かれていない判断が必要であれば、そのルールはまだ運用可能ではありません。再適用が成功するまで文言を明確にするか、提案をリファレンスに格下げします。提案がプロセスを作成する場合、再適用の証明には、作成ゲートが正しい作成または却下の判断を返すことも示す必要があります。再適用の証明がなければ、ルールは認められません。

引用集のアンカー

引用集を使って、各ルールをその出典となる時点に結び付けます。数える事例ごとに、短い逐語引用またはコマンド／出力の抜粋と、ローカルで解決できる参照先（リポジトリのパス、.agents/ao のダイジェスト、またはセッション成果物）を添えます。引用と出典参照ができない事例は、最低3事例の条件に数えません。アンカーがあれば、後から読む人は抽象化を鵜呑みにせず、ルールが実際に起きたことと今も一致しているかを検証できます。

境界

Operationalize は、トラッカーの作業を作成せず、ポリシーを昇格させず、ファクトリーを開始せず、自らの出力を検証せず、別の呼び出しを制御しません。提案は参考情報です。スキル、決定論的チェック、リファレンス、ワークフローへの採用は、呼び出し元が別途選択する手順であり、skill-builder、workflow-builder、または新たな RPI によって行います。ここでは実行しません。提案自体が自らを昇格させることはできず、プロセスのみの出力では機能の評価は得られません。