Back to Details

planetscale-change-gates-and-approval-contract

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

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

A类：默认只读

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.
无需审批即可执行：
  • 列出数据库、分支、键空间、Webhook、备份、角色、流量预算、Schema建议、部署请求及Insights数据。
  • 查看代码仓库代码。
  • 读取Schema元数据。
  • 读取非敏感数据库元数据。
  • 生成报告及建议变更集。

Class B: state-creating proposals

B类：创建状态的提案

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.
默认允许执行；仅当操作者要求严格无变更模式时才需审批：
  • 通过API POST创建查询模式报告，即使结果是只读遥测数据。
  • 触发Webhook测试事件。
  • 创建临时本地分支或文件。
  • 在外部工具中创建PR或议题。
  • 创建数据库开发分支。
  • 对非生产开发分支应用DDL或迁移操作。
  • 针对受审查工作流保护的分支发起部署请求。
最后三项属于现有审查系统内的提案：只有在人工合并或部署后才会进入生产环境。审批关卡应设置在合并/部署操作（C/D类）上，而非提案创建阶段。若代理在发起PR前请求许可，属于分类错误。

Class C: behavior-changing

C类：变更行为

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.
始终需要明确审批：
  • 启用安全迁移。
  • 禁用安全迁移。
  • 修改部署请求审批设置。
  • 创建/更新/删除流量控制预算或规则。
  • 将流量控制预算切换至强制模式。
  • 创建/更新/删除Webhook。
  • 启用原始查询收集。
  • 启用/禁用需要重启的扩展或设置。
  • 创建/更新/删除角色。
  • 重置密码。
  • 修改pg_strict设置。
  • 修改连接池行为。
  • 修改IP限制、PrivateLink、PSC或公共访问权限。
  • 修改备份计划或保留策略。
  • 创建恢复分支。
  • 在自动备份之外创建手动备份。
  • 修改分支大小或副本拓扑结构。
  • 编辑代码仓库文件或依赖。

Class D: production data/availability impacting

D类：影响生产数据/可用性

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.
需要明确审批、目标确认、回滚计划，理想情况下还需二次人工审查：
  • 生产环境DDL操作。
  • 生产环境DML操作。
  • 将Schema建议应用到生产环境。
  • 为生产环境排队或应用Vitess部署请求。
  • 升级或恢复分支。
  • 删除分支、数据库、角色、Webhook、备份或流量规则。
  • 在生产环境强制实施流量控制。
  • 修改生产环境网络访问权限。
  • 轮换生产环境凭据。
  • 高负载期间执行紧急备份。

Class E: never autonomous

E类：禁止自主执行

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.
必须通过直接人工操作或单独审批的事故流程才能执行：
  • 删除生产数据库。
  • 禁用所有生产环境安全机制。
  • 删除生产环境表或列。
  • 移除IP限制或仅私有访问策略。
  • 在日志、议题、PR、Slack或报告中存储或暴露机密信息。
  • 自动合并由数据库遥测生成的代码。
  • 自动应用由LLM生成的DDL。

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.
有效的审批必须包含：
  • 变更ID。
  • 目标组织/数据库/分支。
  • 是否影响生产环境。
  • 执行具体操作的权限。
无效审批：
  • “遵循最佳实践。”
  • “修复所有问题。”
  • “应用建议内容。”
  • 未指定变更ID的“继续执行”。

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.
单次变更审批的唯一替代方案是
../13-autonomous-execution-mode/SKILL.md
中定义的风险确认自主模式。当操作者明确确认风险、指定范围并说明是否包含生产环境时，该确认可替代仅在指定范围内的B/C类（若包含生产环境则包括D类）操作的单次变更审批。
自主模式下仍需遵守本规则的其他要求：
  • E类操作无论任何表述都不得解锁。
  • 仍需为每个C/D类步骤生成执行前检查清单（以执行计划形式展示，而非暂停等待）。
  • 仍需提交执行后报告。
  • 超出范围的操作仍需新的审批或确认。

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.
在执行任何C类或D类操作前，需生成：
  • 精确的命令、API端点、控制台操作、SQL或代码仓库差异。
  • 目标确认。
  • 预期效果。
  • 可用性影响。
  • 数据风险。
  • 安全风险。
  • 回滚计划。
  • 验证计划。
  • 监控计划。
之后暂停等待审批。

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.”
若被要求执行宽泛或模糊的生产环境变更，需拒绝该宽泛操作，并生成更安全的明确变更方案。
使用以下表述：
“我不会根据模糊指令执行宽泛的生产环境变更。我可以生成包含风险及回滚细节的明确变更集。”