planetscale-autonomous-execution-mode

自主执行模式

目的

让明确接受风险的操作人员将整个任务交给 Agent：规划、执行、验证并汇报——全程实时更新状态，而无需逐项批准每项更改。此模式消除了逐步审批带来的阻力，但不会省略任何验证、执行顺序、回滚或停止规范。自主模式改变的只是由谁点击“开始”，绝不会降低工作的谨慎程度。

激活约定

只有当操作人员的消息同时包含以下三项内容时，自主模式才会激活：

1. 明确确认风险。 例如明确表示“我了解风险”“我接受风险”“我知道这可能影响生产环境”。较为含糊的说法——“继续吧”“听起来不错”“去做吧”——不会激活自主模式；它们仍属于变更门控技能下的逐项变更审批。
2. 明确指定范围。 以下任意一种：
   • 指定变更 ID（“VIT-1、VIT-3、WEB-1”），或
   • 指定数据库或组织，并设定变更类别上限（“storefront-demo 报告中的所有事项”），或
   • “报告中的所有建议”——仅在此模式下有效，因为报告已经列明每项变更。
3. 说明是否涉及生产环境。 说明是否包含会影响生产环境的（Class D）变更。如果操作人员没有说明，只询问一次；如果仍未说明，则以 auto-safe 运行（不包含 Class D）。

执行任何操作前，须在运行日志中逐字记录风险确认内容。

自主级别

级别	解锁内容	要求
auto-safe	范围内的 Class B + Class C	风险确认 + 范围
auto-production	在范围内新增 Class D	风险确认 + 范围 + 明确说明是否涉及生产环境
—	Class E	永不可用。任何表述都无法解锁。

在所有模式下，均拒绝 Class E 操作（删除生产数据库/表、同时禁用所有安全机制、暴露机密信息、移除仅限私有网络的安全状态）。如果请求的变更集包含 Class E 项，则执行其余项目并说明该项未执行——不要悄悄跳过，也不要要求操作人员“再明确确认一次”。

确认的有效期

• 仅适用于本次运行。新会话、新报告或数据库状态发生实质性变化时，均须重新确认。
• 仅适用于指定范围。运行期间发现新问题，不代表获准修复该问题——将其添加到报告中并继续。
• 操作人员可随时说 “停止”；在当前原子步骤完成后立即停止，并生成部分运行报告。

长期授权（计划任务自动化）

交互式确认仅适用于单次运行。计划任务 Agent（cron、Cursor Automations、由 webhook 触发的运行）则在长期授权下运行：一份书面文件，提交到 Agent 读取指令的位置（AGENTS.md 中的一个章节或专门的授权文件），其中包含：

• 自动化名称和所有者。
• 范围：组织、数据库、分支。
• 类别上限：B、C 或 D。E 类不可授权。
• 操作允许列表，以有界操作而非意图表述。 有效：“针对开放的架构建议，为增量 DDL 创建部署请求；在回退窗口内部署；仅限增量操作（ADD INDEX、ADD COLUMN NULL）”。无效：“保持架构优化”。
• 适用时的数值限制：每次运行的最大变更数、删除分支的最大分支存续时间、允许的预算模式（仅警告或强制执行）。
• 到期日期。授权过期后进入仅报告模式。建议每 90 天复审一次。

长期授权的每次运行规则：

• Agent 在每次运行开始时重新读取授权；执行范围以文件中的书面内容为准，而非对其的记忆。
• 允许列表之外的所有操作在本次运行中均为仅报告。
• 所有停止条件仍照常适用。已停止的计划任务运行不会自动恢复；它会报告并等待所有者处理。
• 状态会发送到配置的投递渠道（webhook、Slack、问题跟踪器），因为没有操作人员在交互会话中监看。未配置投递渠道的计划任务运行不得执行变更操作——没有接收者的状态不算状态。
• 每次运行的日志都会持久化保存，并在投递渠道的消息中引用。

合理执行：计划

首次变更之前，先生成并展示一份执行计划：

1. 先按依赖关系排序，再按风险排序。 先处理前置条件（例如，在启用安全迁移前停止应用启动时执行的 DDL；在删除被替代的索引前添加新索引）。相互独立的变更中，先处理风险最低的，以尽量降低早期失败的成本。
2. 逐项预检变更。 在执行变更前立即重新读取实时状态（分支标志、建议状态、webhook 配置）。如果状态已与报告中的证据不符，该变更即为过时：跳过，将其标记为 BLOCKED — state drift，然后继续处理独立的变更。
3. 安全前置条件是执行步骤，而非假设。 执行任何 D 类 DDL 前：确认备份是在保留期限内完成的；确认在引擎支持的情况下，通过安全迁移或部署请求执行；并优先使用可回退的机制（带回退窗口的部署请求；对于 Traffic Control，先使用警告模式，再使用强制模式）。
4. 一次只执行一项原子变更。 切勿将无关的变更合并到一条命令中。切勿并行执行 D 类步骤。
5. 每个步骤后都进行验证。 重新读取状态，并在继续之前确认已产生预期效果。命令以 0 退出并不意味着变更“已完成”；只有回读结果与预期状态一致，才算完成。

状态协议

操作员移交了控制权；他们得到的回报是可见性。每个阶段都要报告状态：

• 计划公告 — 列出编号步骤，每项都注明目标、确切命令／接口、预期效果、回滚机制和类别。这是执行开始前最后显示的内容。
• 每步执行前：[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），绝不静默处理。
• 运行摘要 — 来自 change-gates 技能的执行后报告：变更内容、变更时间、成功证据、警告、回滚状态、后续监控。另附确认引文和所用的自主级别。

状态行必须是纯文本，在每个步骤发生时通过 Agent 的常规输出流发出。不得依赖任何特定宿主的呈现界面（画布、HTML、TUI 控件）；这些界面可以辅助呈现，但绝不能取代文本流。对于每个 Agent，纯文本流和运行日志都是运行记录。

停止条件

强制停止规则。触发以下任一条件时，完成当前原子步骤或安全中止；如果步骤只执行了一部分，则执行预先准备的回滚，然后报告：

1. 任何 D 类步骤失败或验证结果不正确 → 停止整个运行。
2. B／C 类步骤失败 → 停止该变更的依赖链；独立变更可以继续；在状态中说明这一点。
3. 运行期间，目标数据库开始出现异常 → 暂停运行，报告异常并等待操作员指示。
4. 生产目标发生状态漂移（其他人在运行期间对其进行了更改）→ 停止运行。
5. 范围压力 — 任何所需操作超出已确认范围 → 不要执行；报告此情况。
6. 破坏性步骤出错 → 绝不自动重试。仅允许重试幂等读取，以及非破坏性调用中的瞬时网络故障。

停止后：报告每个步骤的状态（已完成／已回滚／已阻止／未开始）、当前数据库状态，以及恢复运行所需的重新确认内容。绝不使用原先的确认恢复已停止的运行。

回滚规范

• 每个步骤执行前，准备好具体的回滚方案：确切命令或机制（回滚部署请求、将预算恢复为 warn、禁用 webhook、恢复点）。
• 如果步骤只执行了一部分，且回滚本身无破坏性并已在计划中声明，则无需询问，自动回滚。
• 绝不自动执行破坏性回滚操作（例如，绝不覆盖数据进行自动恢复）；应报告并等待指示。

运行日志

为整个会话维护仅追加的运行日志：时间戳、步骤 ID、命令、结果、回读证据。将日志内容（或其路径）纳入运行摘要。日志是审计记录，可用于核查“Agent 自主完成了操作”。

与其他技能的交互

• ../planetscale-change-gates-and-approval-contract/SKILL.md — 类别定义和执行前／后检查清单仍完全适用；在范围内，有效的风险确认可替代逐项变更审批。E 类规则不变。
• ../planetscale-safe-orchestrator/SKILL.md — 当评估请求附带有效确认（“运行审计并修复发现的问题，我接受风险”）时，先完成完整评估，提供报告和执行计划，然后依据本技能直接开始执行，无需等待审批。
• ../planetscale-schema-recommendations-agent-loop/SKILL.md — 在自主模式下，循环可以根据建议一路执行分支、部署请求和部署；在切换时机很重要的情况下，使用带门控的部署。

必须遵守的拒绝行为

如果操作人员要求完全自主执行，但未包含确认要素，不要就模糊之处进行协商。回复：

"自主模式需要明确的风险确认、指定的范围，以及是否包含生产环境变更。例如：‘我接受风险——将报告中的所有建议应用于 storefront-demo，包括生产环境。’"

然后等待。