Harness 不是让 Agent 更聪明，而是让 Agent 的工作更可信。

所以这次变更给 Boss 的整条研发流水线加一层工程化的骨架。

它要管五件事：流程怎么定义，当前跑到哪，产物以什么为准，什么时候允许继续，失败后怎么恢复。

这次最关键的变化，是加了一层 workflow-plan.json 。

过去 Boss 里已经有 pipeline pack 、artifact DAG 、runtime commands 。DAG 能表达"哪个产物依赖哪个产物"，runtime 能记录阶段和 Agent 状态。但它们之间还缺一层明确的执行定义。

现在初始化时，会把 pipeline pack 和 artifact DAG 编译成一份 workflow plan 。它描述这条流水线有哪些 phase 、哪些 agent node 、哪些 gate node ，以及这些节点之间的依赖关系。与此同时，workflowHash 、packHash 、artifactDagHash 描述的是"这条流程定义是什么"，runId 描述的是"这一次具体执行"。

这个拆分很重要。

因为流程定义和运行实例不是一回事。定义可以被审计、比较、缓存；运行实例可以暂停、恢复、失败、重试。以前这些东西混在一起，很多恢复逻辑只能靠约定。现在它们开始有了明确边界。

我现在会把 Harness 分成几层看

第一层是定义层。 它回答：这条流水线到底是什么？比如 pack 、DAG 、workflow plan 、各种 hash 。它应该稳定、可比较。

第二层是运行层。 它回答：这一次跑到哪了？这里靠的是事件流和 execution.json ，而不是聊天上下文。聊天记录不可靠，事件流才是状态真相源。

第三层是产物层。 PRD 、架构文档、任务拆解、QA 报告、部署报告，这些落盘并被 runtime 记录后，才算正式产物。Agent 说自己完成了，不等于完成了。

第四层是门禁层。 测试、Evidence Wave 、QA 、final gate ，本质上都是在问同一个问题：凭什么继续？这层是防止"看起来完成了"的关键。

第五层是恢复层。 比如 promptFingerprint 、inputDigest 、resume --from-run 。它们的目标不是炫技，而是让中断之后不用靠人脑捡现场，也不用全量重跑。

关于 SKILL.md 的瘦身

另外这次变更还把主 SKILL.md 从 474 行压到了 99 行。之前它太像一个巨型总控 prompt ，什么都写在里面。这样越复杂，越依赖模型一次性记住，最后又回到"让模型自己记流程"的老路。

现在主 Skill 只保留入口、不变量和索引。长流程、runtime 命令、Evidence Wave 、platform driver 、hooks ，都拆到 references 里按需读取。