AsterASTER CODE / 构建终端智能体
05 · 修改与验证
在练习项目修复失败测试，声明验证命令，并把修改摘要和完成状态显示到界面。
验证练习任务
准备一个小项目：一个函数、一个失败测试、一个固定测试命令。先手动运行一次，记下失败原因。给 Agent 的任务应是“修复这个测试并运行现有检查”，不要同时要求重构整个项目、接新服务和发布版本。
先确认第四章的批准流程可用。修改文件、执行命令仍需要对应权限；声明验证契约不会放行工具调用。
把命令声明到可信 ACL
在运行程序时显式传入的宿主 ACL 中加入验证契约：
verification_contract "tutorial-tests" {
workspace = "/absolute/path/demo-project"
command = "cargo test --locked"
covers = ["src/**", "tests/**"]
}
路径、命令和覆盖范围都要换成练习项目的实际值。covers 只填写这条命令确实能检查的文件。若使用隔离工作树，契约需要绑定实际运行工作区；不能用原仓库的测试结果代替另一份文件。
自动发现的工作区配置没有新增验证权威的权限。把同一段声明放进一个不可信仓库，不应让它自己宣布“运行这个命令就算通过”。
界面同时展示执行和验证
工具区显示实际命令、退出码和输出；最终状态区显示 End 中的 completion_terminal、verification_summary 和 forced_stop，之后再核对准确 Run 的终态。不要把全部信息压成一个绿色“完成”。
| 结果 | 界面说明 | 读者应该检查 |
|---|---|---|
| Narrative | 本轮没有需要验证的工作区修改 | 是否还有未解决的工具或后台操作 |
| Verified | 当前修改通过了声明的检查 | 命令、覆盖范围和修改摘要是否匹配 |
| Waived | 当前修改已被明确接受，仍未验证 | 接受者、理由和准确的修改摘要 |
| Incomplete | 尚有条件未满足 | 缺少测试、操作结果不明或子任务尚未收尾 |
effect_digest 标识当前这批修改。测试版本 A 后又改出版本 B，A 的报告不能继续证明 B。这个关系适合放进最终详情面板，而不是要求用户从一大段聊天里找证据。
做三次故障演练
第一次按正常流程修复测试，应能看到修改、执行测试和对应的通过结果。第二次让测试命令失败，界面保留失败输出，不显示 Verified。第三次在测试完成后再修改被覆盖的文件，观察旧报告不能直接让新修改通过。
还要试一次 cargo test --locked || true。它和声明的命令不同，不能凭最终退出码为 0 就当成原命令通过。也不要把 test -e 或文件内容一致误写成“项目测试通过”。
宿主自己运行检查时
如果测试由 IDE、CI 或专用服务执行，用 CompletionAttestor 返回针对当前摘要的报告。它是宿主回调，不是给模型一个“标记通过”的工具。无法核对原报告、对应内容或执行结果时返回 None。
内置 DiskContentAttestor 适合核对磁盘与记录一致，不能证明函数行为正确。本教程的代码修复任务仍应使用项目真实测试。