exists: true 或“已经完成”。
以分析报告为例,执行器必须写入 reports/analysis.md,正文包含“结论”和“依据”。本页的 JSON 是应用清单片段,需要放进实际应用的 application.json;基础 Runtime 的输出 Schema 用法见 输出结构与业务验证。
声明必需文件
下面是application.json 中 artifactContracts 的配置片段。workflowId 和 stepId 必须对应实际工作流图。
产物引用不能指向
.git、安装目录、工作流控制文件等受保护资源,也不能越过项目边界。完成回报携带真实 SHA-256;没有 sha256From 时,通过 Outcome 的 artifact 证据回报摘要。
写入文件并回报摘要
下面是执行器处理函数的execute 示例。它在项目根目录写入真实文件,并从写入内容计算摘要:
write-report 的实际执行器。实际项目中按显式项目根解析文件,不依赖不确定的进程目录。Runtime 会核对磁盘内容,不接受只填路径而不生成文件的结果。
补充业务条件
通用文件检查适合判断“是否生成了指定文件、结构是否正确”。“每条结论都能对应来源”“清单覆盖了所有需求”这类条件,需要实际业务验证器。 验证器由应用作者或创作 Agent 编写并固定版本与内容。它读取真实输入、输出和产物,返回通过或失败。仅安装一份通用 Rule/Hook,不能自动证明这些业务要求已经实现。 SDK 在接受阶段结果、派发依赖动作及接收下游结果时复验相关文件。完成后偷偷修改文件会使原证据失效。修复步骤通过replaces 明确声明替代的产物证据,再执行原流程中的修复。

