Back to Details

planetscale-autonomous-execution-mode

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

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.
让已明确接受风险的操作人员将整个任务交由Agent处理：规划、执行、验证和报告——全程提供实时状态——而非逐一审批每项变更。此模式消除了逐步骤审批的繁琐，但并未移除任何验证、排序、回滚或暂停规范。自主执行仅改变了“谁点击执行”的主体，绝不会降低工作的严谨性。

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.
仅当操作人员的消息同时包含以下三项内容时，自主模式才会激活：
  1. 明确的风险确认：需包含清晰无歧义的表述，例如“我了解风险”、“我接受风险”、“我知晓这会影响生产环境”。较为模糊的表述——如“继续”、“听起来不错”、“执行吧”——不会激活自主模式；此类请求仍需遵循变更门限skill的逐变更审批流程。
  2. 指定范围：需为以下其中一种：
    • 指定的变更ID（如“VIT-1, VIT-3, WEB-1”），或
    • 指定的数据库/组织及变更类别上限（如“storefront-demo报告中的所有内容”），或
    • “报告中的所有建议”——仅在此模式下有效，因为报告已列出所有变更项。
  3. 生产环境说明：需明确是否包含影响生产环境的（Class D）变更。若操作人员未说明，需询问一次；若仍未明确，则以
    auto-safe
    模式运行（排除Class D变更）。
在执行任何操作前，需将风险确认内容原封不动记录到运行日志中。

Autonomy levels

自主执行级别

LevelUnlocksRequires
auto-safe
Class B + Class C within scopeRisk acknowledgment + scope
auto-production
Adds Class D within scopeRisk acknowledgment + scope + explicit production statement
—Class ENever available. No phrasing unlocks it.
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".
级别可执行操作所需条件
auto-safe
范围内的Class B + Class C变更风险确认 + 指定范围
auto-production
新增范围内的Class D变更风险确认 + 指定范围 + 明确的生产环境说明
—Class E永远不可用。任何表述都无法解锁此级别。
Class E操作（删除生产数据库/表、同时禁用所有安全机制、泄露机密、移除私有网络配置）在任何模式下均会被拒绝。若请求的变更集中包含Class E项，需执行其余变更并报告该排除项——不得静默跳过，也不得要求操作人员“再次确认”。

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.
交互式确认仅单次运行有效。定时Agent（cron、Cursor Automations、Webhook触发的运行）则遵循长期授权：需有书面文件，提交至Agent读取指令的位置（如
AGENTS.md
的某章节或专用授权文件），文件需包含：
  • 自动化名称及所有者。
  • 范围：组织、数据库、分支。
  • 类别上限：B、C或D。Class E不可授权。
  • 操作允许列表：需明确限定操作范围，而非仅说明意图。 有效示例：“针对开放架构建议中的增量DDL创建部署请求；部署时设置回滚窗口；仅允许增量操作（ADD INDEX、ADD COLUMN NULL）”。无效示例：“保持架构优化”。
  • 适用的数值限制：每次运行的最大变更数、可删除分支的最大存在时长、允许的预算模式（仅警告 vs 强制）。
  • 到期日期。授权到期后仅运行报告模式。建议审核周期：90天。
长期授权的单次运行规则：
  • Agent在每次运行开始时重新读取授权文件；执行范围以文件书面内容为准，而非记忆内容。
  • 所有超出允许列表的操作在本次运行中仅生成报告。
  • 所有暂停条件保持不变。暂停的定时运行不会自动恢复；需生成报告并等待所有者处理。
  • 状态需推送至配置的交付渠道（Webhook、Slack、问题追踪器），因为没有操作人员监控交互式会话。若定时运行未配置交付渠道，则不得执行变更操作——无人查看的状态毫无意义。
  • 每次运行的日志需持久化存储，并在交付渠道的消息中提供引用。

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.
在首次变更操作前，需生成并展示执行计划：
  1. 按依赖关系排序，再按风险排序。先执行前置条件（例如，在启用安全迁移前停止应用启动时的DDL操作，在删除旧索引前先添加新索引）。对于独立变更，先执行风险最低的操作，这样早期失败的损失最小。
  2. 预检查每项变更。在执行变更前立即重新读取实时状态（分支标记、建议状态、Webhook配置）。若状态与报告中的证据不再匹配，则该变更为过期：跳过该项，标记为
    BLOCKED — state drift
    ，继续执行独立变更。
  3. 安全前置条件是执行步骤，而非假设。在执行任何Class D DDL前：确认备份在保留期内完成，确认使用安全迁移或部署请求作为执行载体（若引擎支持），优先选择可回滚的机制（设置回滚窗口的部署请求、流量控制先启用警告模式再切换为强制模式）。
  4. 每次执行一个原子变更。不得将无关变更批量合并为一个命令。不得并行执行Class D步骤。
  5. 每步执行后验证。重新读取状态并确认达到预期效果后再进行下一步。变更并非“命令执行成功（退出码0）”即完成，而是需在读取状态与预期状态匹配时才算完成。

Status protocol

状态协议

The operator handed over control; visibility is what they get in return. Emit status at every stage:
  • Plan announcement — numbered steps, each with target, exact command/interface, expected effect, rollback mechanism, and class. This is the last thing shown before execution begins.
  • Per-step, before: 
    [step 3/7] STARTING VIT-3a — deploy request: add idx_orders_on_user_id to storefront-demo/main (Class D, revert window available)
  • Per-step, after: 
    [step 3/7] DONE — deploy request #4 deployed, index visible in schema read-back (took 2m 10s)
  • Long-running operations (deploy requests, migrations, restores): poll and report progress at a sensible cadence, not just at completion. Include queue position/state transitions.
  • Skips and blocks: report immediately with the reason (
    BLOCKED — state drift
    , 
    EXCLUDED — Class E
    , 
    SKIPPED — prerequisite failed
    ), never silently.
  • Run summary — the post-execution report from the change-gates skill: what changed, when, evidence of success, warnings, rollback state, follow-up monitoring. Plus the acknowledgment quote and the autonomy level used.
Status lines must be specific enough that an operator reading only the status stream could reconstruct the run: name the change ID, the target, and the mechanism every time.
Status is plain text, emitted in the agent's normal output stream as each step happens. It must not depend on any host-specific rendering surface (canvas, HTML, TUI widgets) — those may supplement the stream, never replace it. The plain-text stream and the run log are the record of the run in every agent.
操作人员移交了控制权，可见性是他们获得的回报。需在每个阶段发布状态：
  • 计划公告——编号步骤，每个步骤包含目标、确切命令/接口、预期效果、回滚机制及变更类别。这是执行开始前展示的最后内容。
  • 每步执行前：
    [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
    ），不得静默处理。
  • 运行总结——来自变更门限skill的执行后报告：变更内容、时间、成功证据、警告、回滚状态、后续监控建议。此外还需包含风险确认引用内容及使用的自主执行级别。
状态行需足够具体，仅阅读状态流的操作人员即可重构整个运行过程：每次需提及变更ID、目标及执行机制。
状态为纯文本，在每个步骤发生时输出至Agent的常规输出流。不得依赖任何主机特定的渲染界面（画布、HTML、TUI组件）——这些可作为状态流的补充，但绝不能替代它。纯文本状态流和运行日志是所有Agent的运行记录。

Halt conditions

暂停条件

Stop-the-line rules. When any of these fires, finish or safely abort the current atomic step, execute the pre-staged rollback if the step half-applied, and report:
  1. Any Class D step fails or verifies incorrectly → halt the entire run.
  2. A Class B/C step fails → halt that change's dependency chain; independent changes may continue; say so in status.
  3. An anomaly begins firing on a target database mid-run → pause the run, report the anomaly, wait for the operator.
  4. State drift on a production target (someone else changed it mid-run) → halt the run.
  5. Scope pressure — anything needed that is outside the acknowledged scope → do not do it; report it.
  6. Error on a destructive step → never auto-retry. Retries are permitted only for idempotent reads and transient network failures on non-destructive calls.
After a halt: report state of every step (done / rolled back / blocked / not started), current database state, and what re-acknowledgment would be needed to resume. Never resume a halted run on the original acknowledgment.
全线停止规则。当触发以下任一条件时，完成或安全中止当前原子步骤，若步骤已部分执行则执行预准备的回滚操作，然后生成报告：
  1. 任何Class D步骤失败或验证未通过 → 暂停整个运行。
  2. Class B/C步骤失败 → 暂停该变更的依赖链；独立变更可继续执行；需在状态中说明。
  3. 运行过程中目标数据库出现异常 → 暂停运行，报告异常，等待操作人员处理。
  4. 生产目标发生状态漂移（运行过程中他人修改了数据库）→ 暂停运行。
  5. 范围超出——所需操作超出已确认的范围 → 不得执行；需报告。
  6. 破坏性步骤出错 → 绝不自动重试。仅允许对幂等读取操作和非破坏性调用中的临时网络故障进行重试。
暂停后：报告每个步骤的状态（已完成 / 已回滚 / 已阻塞 / 未启动）、当前数据库状态，以及恢复运行所需的重新确认内容。不得基于原确认内容恢复暂停的运行。

Rollback discipline

回滚规范

  • Before each step, stage the concrete rollback: the exact command or mechanism (deploy request revert, budget back to warn, webhook disable, restore point).
  • Auto-rollback without asking when a step half-applies and the rollback is itself non-destructive and pre-declared in the plan.
  • Never auto-rollback with a destructive operation (e.g. never auto-restore over data); report and wait instead.
  • 每步执行前，准备好具体的回滚方案：确切的命令或机制（部署请求回滚、预算恢复为警告模式、禁用Webhook、恢复点）。
  • 当步骤部分执行且回滚操作本身无破坏性、并已在计划中预先声明时，无需询问即可自动回滚。
  • 绝不要通过破坏性操作自动回滚（例如，绝不要自动恢复覆盖数据）；需报告并等待操作人员处理。

Run log

运行日志

Maintain an append-only run log for the whole session: timestamp, step ID, command, result, read-back evidence. Include it (or its path) in the run summary. The log is the audit trail that makes "the agent did it autonomously" reviewable.
为整个会话维护一个仅追加的运行日志：时间戳、步骤ID、命令、结果、读取状态的证据。需在运行总结中包含日志（或其路径）。该日志是审核依据，可用于追溯“Agent自主执行”的全过程。

Interaction with other skills

与其他skill的交互

  • ../11-change-gates-and-approval-contract/SKILL.md
    — the class definitions and pre/post-execution checklists still apply verbatim; a valid risk acknowledgment substitutes for per-change approval within scope. Class E rules are unchanged.
  • ../00-safe-orchestrator/SKILL.md
    — when a valid acknowledgment accompanies the assessment request ("run the audit and fix what you find, I accept the risk"), run the full assessment first, present the report and execution plan, then proceed directly into execution under this skill without stopping for approval.
  • ../07-schema-recommendations-agent-loop/SKILL.md
    — in autonomous mode the loop may carry recommendations all the way through branch, deploy request, and deploy, using gated deployments where cutover timing matters.
  • ../11-change-gates-and-approval-contract/SKILL.md
    ——类别定义及执行前后检查清单仍完全适用；有效的风险确认可替代范围内的逐变更审批。Class E规则保持不变。
  • ../00-safe-orchestrator/SKILL.md
    ——当评估请求附带有效的风险确认时（如“执行审核并修复问题，我接受风险”），需先完成完整评估，展示报告和执行计划，然后直接按本skill的规则执行，无需暂停等待审批。
  • ../07-schema-recommendations-agent-loop/SKILL.md
    ——在自主模式下，该循环可将建议全程推进至分支创建、部署请求及部署环节，在切换时机重要的场景下使用 gated deployments。

Required refusal behavior

强制拒绝行为

If the operator asks for full autonomy without the acknowledgment elements, do not negotiate ambiguity. Reply:
"Autonomous mode needs an explicit risk acknowledgment, a named scope, and whether production changes are included. For example: 'I accept the risk — apply all report recommendations to storefront-demo, production included.'"
Then wait.
若操作人员要求完全自主执行但未提供确认要素，不得模糊处理。需回复：
“自主模式需要明确的风险确认、指定范围，以及是否包含生产环境变更。示例表述：‘我接受风险——将报告中的所有建议应用至storefront-demo，包含生产环境变更。’”
然后等待操作人员回复。