审批准入、不确定结果与目标证据
要求选择性条件时，能够证明恒真的 UPDATE／DELETE 条件（例如 WHERE 1=1）会被拒绝。人工审批仍必须绑定精确计划与行集合证据。
自定义 challenge store 必须为单条和批量操作原子实现 TryPromoteAsync。Redis 与持久化续行使用版本化信封；不兼容的 challenge 必须重新预览与审批。参见升级指南。
dml.commit_outcome_unknown 与 dml.rollback_outcome_unknown 是不同且不可重试的结果。请保留审批和目标证据并独立核查。缺少 witness 或 Redis key 都不能证明已经回滚，不可自动重放结果不明的变更。已确认提交后，即使审计持久化失败，也不能报告变更失败。
AddHsSqlAgentTargetExecutionFence() 需要显式启用，预先准备目标表及权限，并另行证明旧 worker 已失去 DML 权限。每次受管提交都在实际连接上执行两个额外的仅回滚就绪验证事务，提交后独立读取 Admission 与 Witness 各一次。Oracle 仅在 witness 唯一键冲突诊断中使用 READ COMMITTED，其他就绪阶段使用 SERIALIZABLE。证据矛盾时返回不确定结果；这不提供整个集群的节点纳管证明，也不自动处理仍存活的 worker。
DML 比 Query 使用更严格的执行路径，因为真正 commit 时，审批内容仍必须描述同一份 Mutation Evidence。
一个 Tool，同时支持单语句与多语句
execute_dml_sql 可以接受一个或多个受支持的 UPDATE、DELETE、INSERT ... VALUES，多个 Statement 用分号分隔。
没有额外的 batch DML Tool。多语句输入会解析成一个 Batch，只审批一次，按原始顺序执行，最后在一个由服务器掌握的 Transaction 中原子提交。
Client 不能传入 BEGIN、COMMIT、ROLLBACK 等 Transaction-control SQL；事务边界由服务器掌握。
审批绑定的内容
UPDATE / DELETE 审批绑定 Preview 时观察到的精确 Primary Key Row Set。Commit Transaction 内每个 Statement 在真正修改前都会立即重新验证。
INSERT ... VALUES 审批绑定不可变的 Literal Payload 与精确编译 Command。INSERT ... SELECT 在来源 Row Set 审批语义定义完成前仍不开放。
如果前一个 Statement 改变了后一个 Statement 原本获批的 Row Set，整个 Batch 会 fail closed 并 rollback。
审批 Provider
MCP Elicitation 仍是第一方默认 Provider。Host 也可以使用官方 HsSqlAgent.Approvals.Webhook adapter，或在 HsSqlAgent.Server 实现 IDmlApprovalProvider。
审批 Provider 收到的是与传输方式无关的 Evidence，不是 SQL 执行 primitive；不会取得 Database Connection、Transaction、已验证 Plan 或 commit 权限。
Durable Pending Approval
Provider 可以为异步流程返回 Pending。存在 Admin Store 时，hs-sql-agent 会保存受保护的 Resume Intent 与 Approval Fingerprint。
之后收到完成决策时，服务器会重新加载当前授权与数据库配置、重新 Parse / Preview DML、比对审批 Evidence，再创建新的短效 Execution Challenge。授权、数据库配置、Policy、Plan、Row Set 或 affected-row Evidence 只要变化，就会被视为 stale 而不是 commit。
完成流程恢复的是执行意图，不是旧 Database Session。
Fail-closed 规则
审批被拒绝、过期、stale、Fingerprint 不匹配、权限被撤销、违反当前 Policy，或无法重现审批 Row Set 时，都不会提交 DML。