多 Agent 编排最常见的问题是：流程走完了，但没有证据。prompt-only 的团队编排可以看起来井井有条——PM 出需求、架构师出设计、QA 说测过了——但没人能证明计划真的被跟随、测试真的跑过、门真的通过。boss-skill（Boss）把「证明」做成了运行时的一部分：pipeline 状态 append 到 .boss/<feature>/.meta/events.jsonl，投影成只读执行状态；QA、部署和最终检查不是松散指令，而是不可绕过的 runtime gates。
gate 是什么：一个脚本 + 一个 stage
在 Boss 里，evaluate-gates 命令做一件事：拿到 feature 和 gateName，解析出门禁脚本，执行它，把输出解析成 check 列表。解析顺序是：先找 .boss/plugins/<gateName>/plugin.json 里的 hooks.gate，再找内置资产的 plugins/<gateName>，最后退回 legacy 的 gate.sh。
每个 gate 还有一个 stage 编号。它先从 artifact-dag.json 的 gate 定义里解析（type === 'gate' 且有 stage），再退回 plugin.json 的 stages[0]，默认是 3。stage 决定这道门在流水线的哪一段生效——不是「QA 应该测一下」这种口头约定，而是运行时查得到的一个数字。
check 列表：门禁的输出契约
gate 脚本的输出会被 parseGateChecks 解析。如果输出是 JSON 数组就直接用；否则按行拆分。每行是一个 check，最终变成 {name, passed, detail} 的结构。也就是说，门禁脚本的产出不是「exit 0 就通过」，而是一份 check 清单——每个 check 单独带 passed 标记。
这和我之前拆 codex 时看到的证据账本是一回事：passed 必须带宾语。一道门过了，是哪些 check 过了、每个 check 的证据是什么，而不是一个裸的退出码。
事件溯源：append-only 的流水线状态
Boss 的状态不是「当前 pipeline 变量」，而是事件流：init-pipeline 追加初始化事件，每次 gate 评估、每份工件产出都 appendRuntimeEvent，然后由 projector 物化成只读执行状态。.boss/<feature>/ 下的 PRD、架构文档、任务清单、QA 报告、部署报告都是可重放的工件。
事件溯源带来的一个实际好处是：中途换了 agent（或 agent 的上下文被压缩了），流水线状态不丢——重放事件流就能恢复只读视图。另一个好处是审计：谁在什么时候声称通过了哪道门，全部在 events.jsonl 里，改不了历史。
确定性 evals：不用真实 LLM 也能评分
Boss 的 eval 用 captured transcripts 评分，不需要调用真实 LLM。这意味着门禁可以在 CI 里确定性运行——同样的输入永远得到同样的结果。对「怎么证明 Agent 团队干完了」这个问题，确定性 eval 是最后一块拼图：不是「看起来不错」，而是「同一份证据，任何时间任何环境评分结果一致」。
拆完的四个判断
第一，多 Agent 编排的信任问题不是靠 prompt 解决的，是靠运行时建模解决的——门是 stage 数字，不是指令文本。第二，门禁的输出要有结构：check 列表比退出码诚实。第三，状态用事件流存，可重放、可审计，agent 换人也不丢。第四，eval 要确定性，证据要可复现——「证明干完了」的每一步都应该是机器可查的，而不是人感觉的。
源码依据：boss-skill packages/boss-cli/src/commands/runtime/evaluate-gates.ts；src/runtime/application/gates.ts（resolveGateScript/isBuiltInGate/resolveGateStage/parseGateChecks），commit 主分支。
