Planetscale Autonomous Execution Mode

Autonomous execution mode

Purpose

Let an operator who has explicitly accepted the risk hand the whole job to the agent: plan, execute, verify, and report — with live status the entire way — instead of approving each change one by one. This mode removes the per-step approval friction. It does not remove any verification, ordering, rollback, or halt discipline. Autonomy changes who clicks "go", never how carefully the work is done.

Activation contract

Autonomous mode activates only when the operator's message contains all three:

1. Explicit risk acknowledgment. An unambiguous statement such as "I understand the risk", "I accept the risk", "I know this can affect production". Softer phrasings — "go ahead", "sounds good", "do it" — do NOT activate autonomous mode; they remain per-change approvals under the change-gates skill.
2. A named scope. One of:
   • Named change IDs ("VIT-1, VIT-3, WEB-1"), or
   • A named database or org with a change-class ceiling ("everything in the report for storefront-demo"), or
   • "All recommendations in the report" — valid in this mode only, because the report already names every change.
3. A production statement. Whether production-affecting (Class D) changes are included. If the operator does not say, ask once; if still unstated, run at auto-safe (Class D excluded).

Record the acknowledgment verbatim in the run log before executing anything.

Autonomy levels

Class E operations (dropping production databases/tables, disabling all safety mechanisms simultaneously, exposing secrets, removing private-only network posture) are refused in every mode. If a requested change set contains a Class E item, execute the rest and report the exclusion — do not silently skip and do not ask the operator to "confirm harder".

Acknowledgment lifetime

• Applies to this run only. A new session, a new report, or a materially changed database state requires re-acknowledgment.
• Applies to the named scope only. Discovering a new problem mid-run does not authorize fixing it — add it to the report and continue.
• The operator can say "stop" at any time; halt after the current atomic step and produce the partial-run report.

Standing authorization (scheduled automation)

Interactive acknowledgment is single-run. Scheduled agents (cron, Cursor Automations, webhook-triggered runs) instead operate under a standing authorization: a written artifact, committed where the agent reads its instructions (an AGENTS.md section or a dedicated authorization file), containing:

• Automation name and owner.
• Scope: organization, database, branches.
• Class ceiling: B, C, or D. Class E is not authorizable.
• Operation allowlist, stated as bounded operations, not intents. Valid: "open deploy requests for additive DDL from open schema recommendations; deploy with revert window; additive only (ADD INDEX, ADD COLUMN NULL)". Invalid: "keep the schema optimized".
• Numeric bounds where applicable: max changes per run, max branch age for deletion, budget modes permitted (warn only vs enforce).
• Expiry date. Expired authorization = report-only mode. Recommended review interval: 90 days.

Per-run rules for standing authorization:

• The agent re-reads the authorization at the start of every run; execution is bounded by the artifact as written, not by memory of it.
• Everything outside the allowlist is report-only for that run.
• All halt conditions apply unchanged. A halted scheduled run does not self-resume; it reports and waits for the owner.
• Status streams to a configured delivery channel (webhook, Slack, issue tracker) since no operator is watching an interactive session. A scheduled run with no delivery channel must not execute mutations — status with no reader is not status.
• The run log is persisted per run and referenced in the delivery channel message.

Sensible execution: the plan

Before the first mutation, produce and show an execution plan:

1. Order by dependency, then by risk. Prerequisites first (e.g. stop the app's boot-time DDL before enabling safe migrations, add an index before dropping the one it replaces). Among independent changes, lowest-risk first so early failures cost the least.
2. Pre-flight each change. Re-read the live state immediately before mutating (branch flags, recommendation state, webhook config). If the state no longer matches the report evidence, the change is stale: skip it, mark it BLOCKED — state drift, and continue with independent changes.
3. Safety prerequisites are steps, not assumptions. Before any Class D DDL: confirm a backup completed within the retention window, confirm safe migrations or a deploy request is the vehicle where the engine supports it, and prefer revertible mechanisms (deploy requests with revert window, warn-mode before enforce-mode for Traffic Control).
4. One atomic change at a time. Never batch unrelated mutations into one command. Never parallelize Class D steps.
5. Verify after each step. Read the state back and confirm the expected effect before moving on. A change is not "done" when the command exits 0; it is done when the read-back matches the expected state.