承認境界管理 は何をしますか？
トリガー
要求されたアクションが明示的な人間の意思決定境界を超える場合に使用します。不要な新しいチェックポイントを作成するためには使用しないでください。
手順
- 正確な提案アクション、誰が決定を所有するか、どのルールまたは承認が必要かを特定します。新しい承認と既に付与された承認を区別します。
- バージョン管理された提案と決定パケットを作成します。現在の動作、提案された差分、目的、影響を受けるリソース、リスク、元に戻せる/戻せない影響、何もしない場合の代替案、要求される正確な承認を含めます。
- 境界に名前を付けます: 実装、実験呼び出し、本番アクティベーション、公開、支出、またはデータ/セキュリティ。ある境界に対する承認は他の境界に対する承認ではありません。
- 決定を一度だけ求め、具体的なはい/いいえ、または限定された選択肢を提示します。広範な包括的同意を唯一の選択肢として提示しないでください。
- 影響を受ける作業を決定待ちでブロックとしてマークします。同じ承認を繰り返し要求したり、沈黙を解釈したり、ブロックされた操作を再試行したりしないでください。
- 独立した作業が承認されたままの場合は、そのキューを自律実行継続プロセスに引き渡します。プロジェクト全体のセキュリティインシデントはローカルなブロッカーではありません。
- 明示的な応答を受け取ったら、決定記録、スコープ、タイムスタンプ、参照を保存します。実行前に提案されたアクションがまだそれと一致することを確認します。
アンチパターン
スコアラーを静かに変更したり、ガードを解除したり、請求を変更したり、非公開ソースのアーティファクトを公開したり、エージェントツールの権限を拡大したりしないでください。技術的に妥当に見える場合でも同様です。
出力
許可された次のアクションと許可されなかったアクションを正確に示した監査可能な決定記録。承認記録を参照してください。
完了の定義
オーナーは、長いデバッグトランスクリプトを解析することなく、明確でバージョン管理された変更を承認または却下できます。