结论
finalize 是编排器，不是渲染器：runFinalize 按序调用 deliver → check → browser-check 三个子命令（validate 内嵌在 deliver 里），每道门用 sha256 与 receiptId 验收回执绑定的是本产物，第一道失败即停。旧产物只在 deliver 的提交点被替换。新 HTML 先在同目录 .archify-delivery-* 暂存区渲染并通过检查，提交时旧文件先备份、再用硬链接换上。中途失败自动回滚，连回滚都失败就保留恢复目录。
适用于Archify @ 82c47cabin/finalize.mjs + archify.mjsexplainer 默认无 browser-check 门
finalize 把一次交付拆成哪几道门？
图的结构
- commandFinalize 解析参数
cli - 快照候选·开收据
snap - .finalize.json 收据
rec - 锁+journal+暂存渲染
del - commitDeliveryPair
commit - check 严格复查
chk - browser-check Chrome
brw brw→recchk→brw· passcli→snapcommit→chk· passdel→commitsnap→del
explainer 候选先经 prepareExplainerInput 编译成冻结 bundle，每道门前后复核其依赖未变。原生图默认三道门全跑；explainer 只跑 deliver + check，加 --browser-check 才开浏览器门。
- commandFinalize 解析参数
解析质量、repo、out-dir；explainer 预编译为冻结 bundle；并行启动有界 update 检查。
- 快照候选·开收据
记录输入 sha256；两个收据路径先原子捕获再写。
- 锁+journal+暂存渲染
拿交付锁、写 pending journal，渲染与自检都在暂存区；任一门失败即停并写诊断。
- check 严格复查
provenance=current 且 sha 匹配后跑严格检查，再过浏览器门。
哪一步失败，旧产物处于什么状态？
| 失败点 | 输出路径上的旧产物 | 保护机制 |
|---|---|---|
| 参数、输入或 validate 失败 | 安全原样未动 | 渲染前不碰目标；交付锁都还没拿 |
| 暂存渲染或 deliver 内 artifact 检查失败 | 安全原样未动 | 候选只写 .archify-delivery-*；检查失败报 previous artifact was preserved |
commitDeliveryPair 中途失败 | 安全自动回滚 | 旧文件先备份成 .previous-output 与 .previous-provenance，异常时逐一 link 回目标并复核绑定 |
| 回滚失败或锁丢失 | 需手工留在恢复目录 | recoveryRequired：暂存目录不清理，recover-output.mjs 可恢复旧文件 |
| 并发另一次 deliver，或残留 lock/pending | 安全被锁挡住 | delivery/concurrent-attempt 或 lock-stale，新交付拒绝开始 |
| deliver 已提交后 check、browser-check 失败 | 边界已被新产物替换 | 新产物已过自身检查；finalize 标 fail、写诊断，不自动回退 |
一次 finalize 在磁盘上留下哪些文件？
| 文件 | 角色 |
|---|---|
<out>.delivery.json | 成功 provenance：receiptId、spec 与 artifact 的 sha256、validation 摘要 |
<out>.delivery-pending.json | 进行中 journal；提交时删除，残留即交付中断的证据 |
<out>.delivery-lock.json | 交付锁；挡住并发与 stale 交付 |
<out>.browser-check.json | 浏览器证据回执；原生图默认产出 |
<out>.finalize.json 与 -summary.json | finalize 完整与压缩回执，经临时文件加绑定原子发布 |
.archify-delivery-* 目录 | 暂存区：spec 快照、渲染候选、.previous-* 备份；正常清理，需恢复时保留 |