Framivra 最近最值得讲的变化，不是又多了一个视频特效，而是开始把“跑完了”和“交付可信”拆开处理。缓存为什么还能用、并行失败后留下什么、接收方拿什么复核，都有了更具体的约束。
它延续的是 video_tools 的时间线内核，不是另一套从头开始的视频工具。公开仓库沿用 vtx，负责帧精确渲染、混音和缓存；文档里的 video_tools 也明确只是仓库路径占位名。旧文已经讲过时间线为什么适合智能体操作，这次我更关心操作完成后，你能检查到哪一层。
先对齐版本
证据截止 2026-10-23。公开仓库
CongliangK/framivra默认分支是main，核对到的 HEAD 为 f71e09d，提交于当日 12:42（UTC+8）。最新发行仍是 v2.1.0；下面讲当前源码，不把后续合并自动算进发行验收。GFX 任务去重等修改所在的 PR #310 仍是草稿，也不算已交付。
缓存命中，先说清命中了什么
时间线和 HTML 没改，不代表画面一定没变。CSS、图片、字体，甚至浏览器的运行库，都可能改变输出。旧文把确定性说得很满，现在需要补上这个前提：输入和渲染环境也得被约束住。
当前实现把项目级与片段级 cache_dependencies 取并集，纳入页面身份。共享依赖变化会影响所有相关页面，片段自己的依赖变化则不必拖着无关页面重做。浏览器、字体及相关运行环境另外进入环境摘要，不能只记一个 Chrome 版本号。
最近合并的 PR #291 修得更细：记录 SVG 运行库身份时，必须把“实际读到的规范路径”和“这份文件的摘要”成对保存。否则，路径先解析一次，算摘要时再解析一次，中间若发生重定向，就可能把甲文件的名字配上乙文件的内容。
所以，不是增加一个哈希字段就够了，字段之间还必须指向同一个对象。它修复的是这处配对错误，不是对任意并发改文件的保证。
代价也很具体。全文读取和环境收集会增加冷启动成本，依赖声明需要维护。HTML 的 strict 模式只支持有限静态子集，不接受任意 JavaScript 动画；普通媒体源的运行期身份仍是 Fast 采样，不是全文件证明。把这几种保证统称为“缓存绝对可靠”，反而会掩盖边界。
可以改变开工顺序，不能改变成片顺序
证据收集变重之后，下一步不是删检查，而是让独立工作并行。PR #308 已合并：macOS 上，系统缓存、渲染器和字体信息分三路收集；系统缓存文件的摘要计算最多使用四个线程。
视频分段也做了调整，但范围很窄：原生 macOS arm64、x264、画布像素数不超过 1920×1080 等条件同时满足才走新策略。它用“段帧数 × 相交图层数”估算工作量，层数至少按一计。先提交重段，减少最后只剩一个大段拖尾的情况。
关键是结果仍按原段序号取回，再拼接。任务提交顺序可以变化，画面顺序不能跟着谁先完成谁先来。提交或取结果失败时，尚未开工的任务取消，已经运行的任务等到结束，原异常继续向上传递。否则上层刚收到失败，后台还在悄悄写文件，下一次重试就很难解释。
这会提高瞬时 CPU 和内存占用，也不意味着所有路径都加速。该 PR 特别区分了历史候选的测速与修复后的代码；后者的定向测试通过，不等于重新完成原生 Mac 性能验收。截至采样时，Mac 原生验收 #303 也仍未关闭。我没有重跑那组测速，所以不引用历史百分比替当前版本背书。
交付一包证据，但别替人宣布验收通过
成片文件只能让你观看，不能独自回答“它对应哪次构建、用了哪些输入”。项目验收包把输入副本、工具版本、构建日志、阶段回执、QC 报告和存在的媒体一起封存。文件清单记录完整 SHA-256，失败记录也保留，不补造缺失产物。
下面是当前源码的真实 CLI 形态，路径只是示例。你要把它们替换成真实的物理绝对路径，不能含 .. 路径分量，也不能经过符号链接。在 Framivra 仓库根、依赖已经满足时执行；输入项目须存在，输出包必须是项目外的全新目录，父目录须已存在且可信：
python3 -m vtx.inspection.acceptance build \
/absolute/path/video-project/timeline.json /absolute/path/review-package
# 单独留存 build 返回的 manifest_sha256，再交给复核方
python3 -m vtx.inspection.acceptance verify \
/absolute/path/review-package \
--manifest-sha256 "$EXPECTED_MANIFEST_SHA256" \
--source-root /absolute/path/video-projectEXPECTED_MANIFEST_SHA256 要填入独立留存的值。若文件和摘要都来自同一个可被替换的包，攻击者可以一起重算，包就成了自己给自己作证。--source-root 会额外检查当前原始输入；不传它，只复核包内副本。复核不会执行包里的命令。
这里最容易误接的是退出码：2 表示包可复核，但验收没有全过，不应直接当作文件损坏。当前生成器没有独立视觉判定，visual_content 固定为 unknown，所以即使结构 QC 通过，accepted 仍是 false。格式或完整性错误返回 1，所有门通过才返回 0。
我认可这种留白。哈希能帮助检查字节是否变化，不能证明生产者诚实，更不能证明字幕讲对了、镜头节奏合适。验收包也没宣称包含全部间接资源，不能拿到它就承诺跨机器完整复现。代价是要复制输入、保存日志、管理独立摘要，还得继续安排人工视听。
这次我核对了公开默认分支、合并记录和发行说明，执行了两条验收子命令的帮助检查，30 项验收包测试通过。测试中的渲染器主要是替身；我没有重渲整片，也没有做新一轮 Mac、GPU 或人工视听验收。绿 CI 不能替这些工作盖章。
从能渲染到能审查交付，并不是多放几份报告。真正的变化是：每个“通过”都得回答自己证明了什么；证明不了的部分，不被顺手涂成绿色。