摘要

  • 10 月 26 日的个人草案建议给发布声明或代理行动记录加两类带类型的摘要引用，分别指向决策记录和行动绑定附件。
  • 附件能对照批准、请求、权限复核和实际执行的规格；批准人签了名，仍须另查其被授权的职位与范围。

部署流水线像一家记账极细的工厂。它记得成品的摘要、构建过程和物料清单；SCITT 的透明服务还能登记签名声明，回执说明声明进入过日志。工厂却可能答不上另一句：谁在什么权限下，批准把这一版推给用户？

Laurent Lemonnier 提交的草案把这句话拆成可以核对的记录。这是一份个人提案，尚非 SCITT 选定方案。它把决策记录和行动绑定附件作为两种不同的文档，通过各自带类型的摘要引用挂到发布声明旁。前者写下选项与决定；后者沿着提议、审阅、批准、请求、执行前复核、尝试和结果走一遍。每一站的规格可以比对，差在哪一站就停在哪一站。

草案给的发布例子是一个版本 2.3.1 的虚构服务。批准规格点名构建、软件制品摘要、物料清单摘要、迁移和回滚。部署任务若换了制品，批准时的摘要与执行时的摘要就对不上。这比事后追问“谁改了包”更有用：它先固定获准发布的到底是哪一个包。

但摘要只能锁住字节，锁不住职权。批准人在结果阶段签名，核验者可以用自己的信任策略把签名密钥映射到一个人；附件里写的任职章程仍是出具者的说法。要确认这个人有权放行，还得查权限系统等独立记录。附件说审阅者看到了什么，也只能证明附件如此记载，不能替人回忆他读过什么。

日志同样有边界。草案中的见证检查点拿到 SCITT 回执，可以说明它在某个树大小时被登记；该版本没有用它证明登记时间，也没有完成日志一致性检查。把“字节相同”“人签了名”“职位有权限”“执行已发生”压成一个绿色勾号，省掉的正是争议发生时最需要的那条责任线。