在操作者明确接受风险后，让代理端到端自主执行已批准的数据库变…

当操作者已明确接受风险并指定范围时，代理可一次性完成计划、执行、验证与汇报，而无需逐步审批。

适用场景

解决思路

1. 激活自主模式必须同时满足三项条件：1）操作者明确的风险确认（如“我理解风险”“我接受风险”“我知道这会影响生产”）；模糊措辞如“继续吧”“听起来不错”“去做”不激活自主模式，仍按逐项审批处理；2）指定范围：具名变更 ID、具名数据库/组织加变更等级上限、或“报告中所有建议”（仅本模式有效）；3）生产声明：是否包含影响生产的 Class D 变更；若未说明先问一次，仍未说明则按 auto-safe 运行（排除 Class D）。执行前将风险确认原文逐字记入运行日志。
2. 按自主等级执行：auto-safe 解锁范围内的 Class B + Class C，需风险确认 + 范围；auto-production 额外解锁范围内的 Class D，需风险确认 + 范围 + 明确的生产声明；Class E 永不可用，任何措辞都无法解锁。Class E 操作（删除生产数据库/表、同时禁用所有安全机制、暴露密钥、移除仅私有网络配置）在任何模式下都拒绝；若请求集合含 Class E 项，执行其余项并报告排除项，不静默跳过、也不要求操作者“更用力确认”。
3. 确认的有效期：仅限本次运行；新会话、新报告或数据库状态发生实质变化都需重新确认；仅限指定范围，运行中发现新问题不授权修复，应加入报告并继续；操作者可随时说“stop”，在当前原子步骤后停止并生成部分运行报告。
4. 定时自动化使用常设授权：交互式确认仅单次运行有效；定时代理（cron、Cursor Automations、webhook 触发）改为依据常设授权——写在代理读取指令处（AGENTS.md 章节或专用授权文件）的书面文件，包含：自动化名称与负责人、范围（组织、数据库、分支）、等级上限（B/C/D，Class E 不可授权）、以有界操作而非意图表述的操作白名单（有效示例：“为开放 schema 建议中的增量 DDL 开启 deploy request；带 revert 窗口部署；仅增量（ADD INDEX、ADD COLUMN NULL）”；无效示例：“保持 schema 优化”）、数值边界（每次运行最大变更数、可删除分支的最大年龄、允许的预算模式 warn only 还是 enforce）、到期日（过期授权 = 仅报告模式，建议 90 天审查一次）。
5. 常设授权的每次运行规则：代理在每次运行开始时重新读取授权，执行以书面文件为准而非记忆；白名单之外的一切在该次运行中仅报告；所有停止条件不变，被停止的定时运行不自行恢复，而是报告并等待负责人；状态推送到配置的交付渠道（webhook、Slack、issue tracker），因为无人观看交互会话；没有交付渠道的定时运行不得执行变更——无人阅读的状态不算状态；每次运行的日志持久化并在交付渠道消息中引用。
6. 首次变更前生成并展示执行计划：1）按依赖排序，再按风险排序——前置项优先（如先停止应用启动时 DDL 再启用安全迁移，先加索引再删除被替代的索引）；独立变更中风险最低者优先，使早期失败代价最小。2）对每项变更做预检——变更前立即重读实时状态（分支标志、建议状态、webhook 配置）；若状态不再匹配报告证据，该变更为 stale：跳过并标记 BLOCKED — state drift，继续独立变更。3）安全前置是步骤而非假设——任何 Class D DDL 前：确认备份在保留窗口内完成、确认在引擎支持时以安全迁移或 deploy request 为载体、优先可回滚机制（带 revert 窗口的 deploy request、Traffic Control 先 warn 模式再 enforce 模式）。4）一次一个原子变更——绝不把无关变更批处理进一条命令，绝不并行 Class D 步骤。5）每步后验证——读回状态确认预期效果再继续；命令退出码为 0 不算“完成”，读回匹配预期状态才算完成。
7. 状态协议：操作者交出了控制权，回报就是可见性，每个阶段都要发出状态——计划公告（编号步骤，每步含目标、确切命令/接口、预期效果、回滚机制、等级，这是执行开始前最后展示的内容）；每步执行前如 `[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)`；长时间操作（deploy request、迁移、恢复）按合理节奏轮询并报告进度，不只报完成，包含队列位置/状态转换；跳过与阻塞立即报告原因（`BLOCKED — state drift`、`EXCLUDED — Class E`、`SKIPPED — prerequisite failed`），绝不静默；运行摘要包含变更内容、时间、成功证据、警告、回滚状态、后续监控，以及确认原文和所用自主等级。状态行必须足够具体，使只读状态流的操作者能重建整个运行：每次都要点名变更 ID、目标和机制。状态为纯文本，随每步在代理正常输出流中发出，不得依赖任何宿主特定渲染面（canvas、HTML、TUI 组件）——那些可补充流但绝不能替代；纯文本流和运行日志是每个代理中运行的记录。
8. 停止条件（停止线规则）：触发时完成或安全中止当前原子步骤，若步骤半应用则执行预置回滚，并报告——1）任何 Class D 步骤失败或验证不正确 → 停止整个运行；2）Class B/C 步骤失败 → 停止该变更的依赖链，独立变更可继续，并在状态中说明；3）运行中目标数据库开始触发异常 → 暂停运行，报告异常，等待操作者；4）生产目标发生状态漂移（运行中他人修改）→ 停止运行；5）范围压力——需要任何已确认范围之外的东西 → 不做，报告；6）破坏性步骤出错 → 绝不自动重试；仅幂等读取和非破坏性调用的瞬时网络故障可重试。停止后：报告每一步状态（已完成/已回滚/阻塞/未开始）、当前数据库状态、以及恢复需要何种重新确认；绝不用原确认恢复已停止的运行。
9. 回滚纪律：每步前预置具体回滚——确切命令或机制（deploy request revert、预算回到 warn、禁用 webhook、恢复点）；当步骤半应用且回滚本身非破坏性并在计划中预先声明时，无需询问自动回滚；绝不用破坏性操作自动回滚（如绝不在数据上自动恢复），而是报告并等待。
10. 维护整个会话的仅追加运行日志：时间戳、步骤 ID、命令、结果、读回证据；在运行摘要中包含它（或其路径）。日志是使“代理自主执行了”可审查的审计轨迹。
11. 与其他技能配合：变更门与审批契约技能中的等级定义和执行前后检查清单仍逐字适用，有效的风险确认在范围内替代逐项审批，Class E 规则不变；安全编排技能中，当有效确认伴随评估请求（“运行审计并修复你发现的问题，我接受风险”）时，先运行完整评估，展示报告和执行计划，然后直接进入本技能的执行，不再停下等待审批；schema 建议代理循环技能中，自主模式下循环可将建议一路推进到分支、deploy request 和部署，在切换时机重要时使用门控部署。
12. 必须的拒绝行为：若操作者要求完全自主但缺少确认要素，不要协商模糊性，回复：“自主模式需要明确的风险确认、指定范围、以及是否包含生产变更。例如：‘我接受风险——将报告中的所有建议应用到 storefront-demo，包含生产。’”然后等待。

适用边界 · 注意事项

• 操作者未明确接受风险（如只说“继续吧”“听起来不错”“去做”）时，不适用自主模式，仍应按逐项审批处理。
• 请求包含 Class E 操作（删除生产数据库/表、同时禁用所有安全机制、暴露密钥、移除仅私有网络配置）时，任何模式都拒绝执行该部分。
• 定时自动化没有配置交付渠道时，不得执行变更，只能报告。
• 新会话、新报告或数据库状态发生实质变化后，原风险确认失效，需重新确认才能继续。