planetscale-change-gates-and-approval-contract

---
name: planetscale-change-gates-and-approval-contract
description: Enforce explicit approval gates for any PlanetScale, database, repository, credential, network, or automation mutation.
license: MIT
---

# Change gates and approval contract

## Purpose

Prevent accidental or autonomous changes that can affect availability, safety, security, data, or developer workflows.

## Operation classes

### Class A: read-only by default

Allowed without approval:

- List databases, branches, keyspaces, webhooks, backups, roles, traffic budgets, schema recommendations, deploy requests, and Insights data.
- Inspect repository code.
- Read schema metadata.
- Read non-sensitive database metadata.
- Produce reports and proposed change sets.

### Class B: state-creating proposals

Allowed by default; requires approval only when the operator has demanded strict no-mutation mode:

- Creating a query-pattern report through an API POST, even if the result is read-only telemetry.
- Triggering a webhook test event.
- Creating temporary local branches or files.
- Opening PRs or issues in external tools.
- Creating database development branches.
- Applying DDL or migrations to non-production development branches.
- Opening deploy requests targeting a branch protected by a review workflow.

The last three are proposals inside an existing review system: nothing
reaches production until a human merges or deploys. The gate belongs on
the merge/deploy action (Class C/D), not on proposal creation. An agent
that stops to ask permission to open a PR is misclassifying.

### Class C: behavior-changing

Always requires explicit approval:

- Enable safe migrations.
- Disable safe migrations.
- Change deploy request approval settings.
- Create/update/delete Traffic Control budget or rule.
- Move Traffic Control budget to enforce mode.
- Create/update/delete webhook.
- Enable raw query collection.
- Enable/disable extensions or settings that require restart.
- Create/update/delete role.
- Reset passwords.
- Change pg_strict settings.
- Change connection pooling behavior.
- Change IP restrictions, PrivateLink, PSC, or public access.
- Change backup schedule or retention.
- Create restore branch.
- Create backup beyond automatic backups.
- Change branch size or replica topology.
- Edit repository files or dependencies.

### Class D: production data/availability impacting

Requires explicit approval, named target confirmation, rollback plan, and ideally a second human review:

- Production DDL.
- Production DML.
- Applying schema recommendation to production.
- Queueing or applying Vitess deploy request to production.
- Promoting or restoring branches.
- Deleting branches, databases, roles, webhooks, backups, or traffic rules.
- Enforcing Traffic Control on production.
- Changing production network access.
- Rotating production credentials.
- Emergency backup during high load.

### Class E: never autonomous

Never do without direct human operation or separately approved incident procedure:

- Delete a production database.
- Disable all production safety mechanisms.
- Drop production tables or columns.
- Remove IP restrictions or private-only posture.
- Store or expose secrets in logs, issues, PRs, Slack, or reports.
- Auto-merge code generated from database telemetry.
- Auto-apply DDL generated by an LLM.

## Approval requirements

A valid approval must include:

- Change ID.
- Target organization/database/branch.
- Whether production is affected.
- Permission to execute the exact action.

Invalid approvals:

- “Do the best practices.”
- “Fix everything.”
- “Apply recommendations.”
- “Go ahead” without named change IDs.

## Autonomous execution exception

There is exactly one alternative to per-change approval: the risk-acknowledged
autonomous mode defined in `../13-autonomous-execution-mode/SKILL.md`. When the
operator explicitly acknowledges the risk, names a scope, and states whether
production is included, that acknowledgment substitutes for per-change approval
of Class B/C (and Class D when production is included) actions **within the
named scope only**.

Everything else in this skill still applies in autonomous mode:

- Class E is never unlocked by any phrasing.
- The pre-execution checklist must still be produced for every Class C/D step
  (shown as the execution plan, not as a stop-and-wait).
- The post-execution report is still required.
- Out-of-scope work still requires new approval or new acknowledgment.

## Required pre-execution checklist

Before any Class C or D action, produce:

- Exact command, API endpoint, dashboard action, SQL, or repository diff.
- Target confirmation.
- Expected effect.
- Availability impact.
- Data risk.
- Security risk.
- Rollback plan.
- Validation plan.
- Monitoring plan.

Then stop for approval.

## Required post-execution report

If an approved change is later executed, report:

- What changed.
- When it changed.
- Who approved.
- Interface used.
- Evidence of success.
- Any warnings.
- Rollback state.
- Follow-up monitoring.

## Required refusal behavior

If asked to apply broad or ambiguous production changes, refuse the broad action and produce a safer named change plan.

Use this sentence:

“I will not apply broad production changes from an ambiguous instruction. I can produce a named change set with risk and rollback details.”