planetscale-autonomous-execution-mode

自律実行モード

目的

リスクを明示的に受け入れたオペレーターが、各変更を一つずつ承認するのではなく、計画、実行、検証、報告までの作業全体をエージェントに任せられるようにします。作業中は常に状況が表示されます。このモードでは、手順ごとの承認による手間をなくします。ただし、検証、実行順序、ロールバック、停止に関する規律は一切省きません。自律性によって変わるのは「実行」をクリックする人だけであり、作業を慎重に進める方法は変わりません。

有効化の条件

オペレーターのメッセージに以下の3つすべてが含まれている場合に限り、自律モードが有効になります。

1. 明示的なリスクの了承。 「リスクを理解しています」「リスクを受け入れます」「本番環境に影響する可能性があることを理解しています」などの、明確な表明が必要です。「進めてください」「よさそうです」「実行してください」といった、曖昧な表現では自律モードは有効になりません。これらは変更ゲートスキルに基づく、変更ごとの承認として扱われます。
2. 対象範囲の指定。 次のいずれかを指定します。
   • 指定した変更 ID（「VIT-1、VIT-3、WEB-1」など）、または
   • 変更クラスの上限を添えた、指定のデータベースまたは組織（「storefront-demo のレポートにあるすべて」など）、または
   • 「レポート内のすべての推奨事項」。レポートにはすべての変更がすでに記載されているため、このモードに限り有効です。
3. 本番環境に関する明示。 本番環境に影響する変更（クラス D）を含めるかどうかを明示します。オペレーターが指定しない場合は、一度だけ確認します。それでも明示されない場合は、クラス D を除外した auto-safe で実行します。

実行を始める前に、了承の文言をそのまま実行ログに記録します。

自律性のレベル

レベル	実行できる範囲	必要な条件
auto-safe	対象範囲内のクラス B とクラス C	リスクの了承＋対象範囲
auto-production	対象範囲内のクラス D を追加	リスクの了承＋対象範囲＋本番環境に関する明示
—	クラス E	常に利用不可。どのような表現でも有効にはなりません。

本番データベースやテーブルの削除、すべての安全機構の同時無効化、シークレットの公開、プライベートネットワークのみを許可する設定の解除といったクラス E の操作は、どのモードでも拒否します。要求された変更セットにクラス E の項目が含まれている場合は、残りを実行し、除外したことを報告します。黙って飛ばしてはならず、オペレーターに「もっと強く確認」するよう求めてはなりません。

了承の有効期間

• この実行に限り有効です。新しいセッション、新しいレポート、またはデータベースの状態に実質的な変化があった場合は、再度了承が必要です。
• 指定された対象範囲に限り有効です。実行中に新しい問題が見つかっても、それを修正する許可にはなりません。レポートに追加して、作業を続けます。
• オペレーターはいつでも 「停止」 と指示できます。その場合は、現在のアトミックな手順の完了後に停止し、途中までの実行レポートを作成します。

継続的な認可（スケジュールされた自動化）

対話形式の承認は1回限りです。スケジュールされたエージェント（cron、Cursor Automations、webhook によってトリガーされる実行）は、代わりに継続的な認可に基づいて動作します。これは、エージェントが指示を読み取る場所（AGENTS.md のセクションまたは専用の認可ファイル）にコミットされた、次の内容を含む文書です。

• 自動化の名前と所有者。
• 対象範囲：組織、データベース、ブランチ。
• クラスの上限：B、C、または D。クラス E は認可できません。
• 操作の許可リスト。意図ではなく、範囲を限定した操作を記述します。 有効な例：「公開中のスキーマ推奨に基づく、追加的な DDL のデプロイリクエストを作成する。リバート期間を設けてデプロイする。追加のみ（ADD INDEX、ADD COLUMN NULL）」。無効な例：「スキーマを最適化し続ける」。
• 該当する場合は数値の上限：1回の実行あたりの変更数の上限、削除対象ブランチの最大経過期間、許可される予算モード（警告のみ、または強制）。
• 有効期限。有効期限が切れた認可は、報告のみのモードになります。推奨する見直し間隔：90日。

継続的な認可に関する実行ごとのルール：

• エージェントは毎回の実行開始時に認可を読み直します。実行は、記憶した内容ではなく、文書に記載された範囲に制限されます。
• 許可リストの範囲外にあるものは、その実行ではすべて報告のみとします。
• すべての停止条件は変更なく適用されます。停止したスケジュール実行は自動で再開せず、所有者に報告して応答を待ちます。
• 対話セッションを監視するオペレーターがいないため、ステータスは設定済みの配信チャネル（webhook、Slack、課題トラッカー）に送信します。配信チャネルのないスケジュール実行では、変更操作を実行してはいけません。読む人がいないステータスは、ステータスではありません。
• 実行ログは実行ごとに永続化し、配信チャネルのメッセージから参照できるようにします。

適切な実行：計画

最初の変更操作を行う前に、実行計画を作成して提示します。

1. 依存関係の順に並べ、その後リスク順に並べます。 まず前提条件を処理します（例：安全なマイグレーションを有効にする前に、アプリ起動時の DDL を停止する。置き換え対象のインデックスを削除する前に、新しいインデックスを追加する）。互いに独立した変更は、初期段階で失敗した場合のコストが最小になるよう、リスクの低いものから行います。
2. 変更ごとに事前確認します。 変更操作の直前に、稼働中の状態（ブランチのフラグ、推奨の状態、webhook の設定）を読み直します。状態がレポートの根拠と一致しなくなっている場合、その変更は古くなっているため、スキップし、BLOCKED — state drift としてマークしてから、独立した変更を続けます。
3. 安全のための前提条件は、仮定ではなく手順として扱います。 クラス D の DDL を行う前に、保持期間内にバックアップが完了していることを確認し、エンジンが対応している場合は、安全なマイグレーションまたはデプロイリクエストを手段として使用することを確認します。また、リバート可能な方法を優先します（リバート期間付きのデプロイリクエスト、Traffic Control では強制モードの前に警告モード）。
4. 一度に1つの独立した変更だけを行います。 無関係な変更を1つのコマンドにまとめてはいけません。クラス D の手順を並列実行してはいけません。
5. 各手順の後に検証します。 次に進む前に状態を読み戻し、期待した効果が得られていることを確認します。コマンドが終了コード 0 で終了しただけでは、変更は「完了」ではありません。読み戻した状態が期待どおりである場合に、初めて完了となります。

ステータスプロトコル

オペレーターが制御を引き渡し、その代わりに得るのが可視性です。各段階でステータスを出力してください。

• 計画の告知 — 対象、正確なコマンド／インターフェース、期待される効果、ロールバックの仕組み、クラスを含む番号付きの手順。これは実行開始前に表示される最後の内容です。
• 各手順の開始前：[step 3/7] STARTING VIT-3a — deploy request: add idx_orders_on_user_id to storefront-demo/main (Class D, revert window available)
• 各手順の完了後：[step 3/7] DONE — deploy request #4 deployed, index visible in schema read-back (took 2m 10s)
• 長時間実行される操作（デプロイリクエスト、マイグレーション、復元）：完了時だけでなく、適切な間隔で進捗を確認して報告してください。キュー内の位置／状態の遷移も含めてください。
• スキップとブロック：理由（BLOCKED — state drift、EXCLUDED — Class E、SKIPPED — prerequisite failed）を添えて、直ちに報告してください。決して黙って処理しないでください。
• 実行サマリー — change-gates スキルによる実行後のレポート：変更内容、実行時刻、成功を示す証拠、警告、ロールバックの状態、追加監視。さらに、確認の引用と使用した自律性レベルも含めてください。

ステータス行は、それだけを読むオペレーターが実行内容を再構成できるほど具体的にしてください。毎回、変更 ID、対象、使用した仕組みを明記してください。

ステータスはプレーンテキストで、各手順の実行に合わせてエージェントの通常の出力ストリームに出力してください。ホスト固有の表示領域（キャンバス、HTML、TUI ウィジェット）に依存してはいけません。これらはストリームを補足してもかまいませんが、置き換えてはいけません。プレーンテキストのストリームと実行ログが、すべてのエージェントにおける実行記録です。

停止条件

作業を停止するためのルールです。次のいずれかが発生した場合、進行中のアトミックステップを完了するか、安全に中断し、ステップの一部だけが適用されている場合は事前に準備したロールバックを実行して、報告してください。

1. Class D の手順が失敗する、または検証結果が正しくない → 実行全体を停止します。
2. Class B/C の手順が失敗する → その変更の依存関係チェーンを停止します。独立した変更は続行してかまいません。その旨をステータスで伝えてください。
3. 実行中に対象データベースで異常が発生する → 実行を一時停止して異常を報告し、オペレーターの指示を待ちます。
4. 本番環境の対象で状態のずれが発生する（別の作業者が実行中に変更した）→ 実行を停止します。
5. スコープの逸脱 — 確認済みのスコープ外に必要な作業がある → 実行せず、その旨を報告します。
6. 破壊的な手順でエラーが発生する → 自動再試行は決して行いません。再試行が許可されるのは、冪等な読み取りと、非破壊的な呼び出しでの一時的なネットワーク障害のみです。

停止した後は、すべての手順の状態（完了／ロールバック済み／ブロック済み／未開始）、現在のデータベースの状態、再開に必要な再確認事項を報告してください。元の確認を根拠に、停止した実行を再開してはいけません。

ロールバックの規律

• 各手順の前に、具体的なロールバック方法を準備してください。正確なコマンドまたは仕組み（デプロイリクエストの取り消し、予算を警告レベルに戻す、Webhook の無効化、復元ポイント）を明記します。
• 手順が一部だけ適用され、ロールバックが非破壊的で計画に事前記載されている場合は、確認を求めずに自動でロールバックします。
• 破壊的な操作を伴う自動ロールバックは決して行わないでください（例：データを上書きする自動復元は決して行わない）。報告して指示を待ちます。

実行ログ

セッション全体を通じて、追記専用の実行ログを維持してください。タイムスタンプ、手順 ID、コマンド、結果、読み戻しによる証拠を記録します。実行サマリーにログ（またはそのパス）を含めてください。このログは、「エージェントが自律的に実行した」ことを検証可能にする監査証跡です。

他のスキルとの連携

• ../planetscale-change-gates-and-approval-contract/SKILL.md — クラスの定義と実行前後のチェックリストは引き続きそのまま適用されます。有効なリスク承認があれば、適用範囲内では変更ごとの承認に代わります。クラス E のルールに変更はありません。
• ../planetscale-safe-orchestrator/SKILL.md — 有効な承認を添えて評価を依頼された場合（「監査を実行し、見つかった問題を修正してください。リスクは承知しています」）、まず評価をすべて実施し、レポートと実行計画を提示してから、承認を求めずにこのスキルに基づく実行へ直接進みます。
• ../planetscale-schema-recommendations-agent-loop/SKILL.md — 自律モードでは、切り替えのタイミングが重要な場合にゲート付きデプロイを使用し、ループで推奨事項をブランチ作成、デプロイリクエスト、デプロイまで一貫して実行できます。

必須の拒否動作

オペレーターが承認要素を示さずに完全な自律実行を求めた場合、曖昧な点の確認を繰り返してはなりません。次のように返信してください。

「自律モードには、明示的なリスク承認、対象範囲の指定、本番環境への変更を含めるかどうかの指定が必要です。例：『リスクは承知しています。storefront-demo に関するレポートの推奨事項をすべて適用してください。本番環境も対象に含めます。』」

その後、待機します。