preflight-mutations

变更前检查

在写入共享状态之前，我会核实权限、当前状态、依赖项和恢复方案，并在此生成决策记录。我绝不执行变更本身。分离这两件事正是关键。

1. 定义变更批次

我会记录一个批次，其中的项目具有相同的授权和防护条件。对于目标、负责人、环境、可逆性或确认要求不同的操作，我会分别创建卡片。

对于简单卡片，我会直接内联呈现。对于多步骤或多批次运行，我只会将其保存在用户已授权此工作流写入的现有工件中。我不会仅为了存放变更前检查而创建文件、评论、议题或其他外部工件。

### Mutation card

- **Surface / environment:** <system and local | staging | production | shared>
- **Action:** <exact mutation verb and delta; no combined "update as needed" language>
- **Targets:** <stable IDs, URLs, refs, fields, recipients, or services>
- **Ownership policy:** <governing policy and owner/assignee/author/environment boundary>
- **Authorization source:** <user request or later explicit confirmation, quoted narrowly>
- **Current guards:** <state, base/head SHA, version, field, environment, or other compare-before-write facts>
- **Dependencies / consumers:** <direct dependencies; transitive consumers when destructive or history-rewriting>
- **Preview / exclusions:** <proposed delta, blast radius, and what will not change>
- **Reversibility:** reversible | compensating-only | irreversible
- **Recovery plan:** <undo, backup, compensation, or explicit absence>
- **Invalidators:** <facts that make this preflight stale>
- **Read-back plan:** <authoritative post-write query and expected result>
- **Batch items:** <stable item ID → pending | landed | failed | skipped | reconcile-required>
- **Verdict:** ready | confirmation-required | blocked
- **Next action:** <one action permitted by the verdict>

我会准确记录操作、目标、环境和批次项目 ID，确保其他 Agent 无法通过推断选取范围更广的资源。多步骤或多批次卡片需要有经授权的持久存储位置，并且我会将此要求列为门槛。门槛。 两项均须满足：不能通过推断选取任何内容；每张多步骤卡片都必须有存储位置。

我会在 回读计划 中通过稳定 ID 点明每个目标和受保护的依赖项。我绝不会将其概括为“所有目标”“使用者”或其他指代性说法。

2. 核实权限和所有权

我会遵循目标所在界面的所有权政策。技术写入权限不会扩大用户要求的范围，也不会覆盖受指派人、作者、资源所有者或环境边界。

如果证据表明技术访问权限超出授权边界，我会在 所有权政策 中说明访问权限与授权之间的区别。

具体的用户请求只会授权在其指定操作和目标范围内执行常规的 reversible 写入。对于拆分、分组、关闭并创建后续项或调整依赖项基准等结构调整；生产数据或生产操作；服务停机；向外部接收方发送内容；超出适用所有权边界的资源；compensating-only 或 irreversible 操作；以及改写或删除已发布历史，我都要求先获得新的明确确认。

我不会将对某一操作类别的批准视为对另一类别的批准。我会在卡片中记录确切的授权来源。

门槛。 已核实所有权，且授权涵盖准确的批次；否则，结论不能是 ready。

3. 检查防护条件、依赖项和发布状态

我会在批次执行前立即从权威系统读取当前状态。

• 对于常规写入，我会检查直接依赖项和当前的写入前比对防护条件。
• 对于删除、关闭、更改基准和改写历史，我会遍历传递性使用者，例如堆叠 PR、依赖分支、关联议题、工作流、发布、汇总记录和下游服务。
• 对于 Git 历史，我会将本地引用与其上游及使用者进行比对。当某个提交或引用已发布或被使用时，我会在 预览／排除项 中列出仅追加的纠正提交或后继引用方案，并在 下一步操作 中明确呈现该选择。我至少会将改写或删除归类为 compensating-only，因为恢复引用无法撤销发布或下游使用。此类操作仍须 confirmation-required。
• 对于类似生产环境的 UI 操作或其他操作，我会核实环境和记录所有权；在可能的情况下，对受影响记录创建快照，并列出已捕获的先前值以及恢复或补偿步骤。如果恢复主要记录后，下游计费、权益、通知或审计影响仍然存在，我会将该操作归类为 compensating-only。
• 对于发送到外部系统的副本，我会核实接收方、包含的敏感材料、保留期限，以及撤销或删除途径。

我会在 当前防护条件 和 失效条件 中列出每个目标的稳定 ID，以及保护其写入操作的每项可变事实。

门槛。 必须根据当前证据列出所需的依赖项和使用者。破坏性操作存在未知依赖项时，结论为 blocked。

4. 预览影响范围并制定恢复方案

对于含糊不清的重构、大批量更改、生产环境操作、所有权扩展，以及 compensating-only 或 irreversible 操作，我会先向用户展示预览。预览包含目标、拟议变更、排除项、依赖项、影响范围和恢复路径。

我会将恢复方式归为以下三类之一。reversible 表示直接撤销即可恢复已记录的先前状态。compensating-only 表示原始事件仍然存在，但后续操作可以恢复其实际效果。irreversible 表示无法可靠恢复。

对于 reversible，我会指出已记录的先前值或准确的撤销操作。对于 compensating-only，我会在 Recovery plan 中按稳定 ID 列出所有恢复目标及其已记录的先前值，然后说明补偿操作和残留记录。对于 irreversible，我会说明永久性损失。缺少恢复证据时，结果为 blocked，不得乐观分类。

关卡。 预览和恢复证据与变更量、环境、含糊程度和可逆性类别相匹配。

5. 给出一个判定

• ready 表示确切的批次、所有权、授权、当前保护条件、依赖证据、恢复方案和回读计划均满足各项关卡要求，且不适用任何需要重新确认的类别。
• confirmation-required 表示证据和预览均完整，但此类操作需要用户重新明确决定。我会展示卡片并征求用户决定，不会执行变更。
• blocked 表示所需的目标、所有权、授权、依赖、恢复或保护条件证据缺失或不安全。我会指出所需的证据或授权，不会执行变更。

如果多步骤或多批次运行没有已有的、获授权的持久化位置，则结果为 blocked。Next action 会指出应使用的现有工作流产物，或写入该产物所需的授权。我不会仅为通过此关卡而创建持久化状态。

用户重新确认后，我会更新 Authorization source，但不会豁免任何其他关卡。更改判定为 ready 之前，我会重新读取各项失效条件。

我会将 Next action 写成一条独立完整的指令，明确指出具体操作和目标。我不会用“此操作”“上述内容”或其他指代性短语来含糊带过。

6. 移交执行并保留部分状态

我将 ready 卡片交给负责执行变更的工作流。在每次写入之前，我都会核对其保护条件。任何目标、操作、所有权、依赖项、分支头、发布状态、环境或审批发生变化，都会使 ready 失效。我会停止尚未执行的剩余项，并重新进行预检。

每个调用方都遵循相同的结果约定。只有当 Verdict 为 ready 且 Invalidators 仍然匹配时，才继续执行。若为 confirmation-required，则展示卡片并等待指定的确认。若为 blocked，则停止变更并报告 Next action。

如果存在原生的条件写入机制，执行移交必须使用该机制，例如预期版本、比较并交换令牌、精确 SHA 租约或幂等键。对于已发布的 Git 历史，恢复推送也必须使用租约保护，并以重新读取的远程分支头为准。

每次尝试处理一个项目后，我都会将其记录为 landed、failed、skipped 或 reconcile-required。如果命令结果和权威回读无法确定写入是否成功，我会使用 reconcile-required。我会停止处理该项目。在权威查询确定其状态之前，我不会重试，也不会将其归类为 failed。

若发生中断、失效或 reconcile-required，我会保留项目台账，权威地重新读取每个 landed 项目，记录观测到的部分外部状态，并创建一张新卡片：其 Targets 仅涵盖安全的 pending 剩余项，而 Batch items 则会将权威确认的 landed、failed、skipped 和未解决的 reconcile-required 历史与这些待处理项一并记录。

我会将所有 reconcile-required 项目排除在新卡片的写入目标之外。其 Next action 是解决该项目所需的确切权威查询。只有观测到的结果才能将其状态变更为 landed、failed 或 pending。

我绝不会从假定的零状态重新开始。执行工作流负责写入。verify-claims 可以验证重要的写后声明，而最终完成工作流负责给出验收界面判定。

完成。 卡片已填写，判定与各项关卡一致，并且此技能未执行任何共享状态变更。