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.

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.”