用途与实际影响
这项功能怎样使用
为什么需要它
文件生成得快，不代表包括 AI 分析在内的整件工作更快；保存过程的状态库，也不代表它丢失后就能恢复。两层都要如实核验。
举个实际例子
我可以问：“这套工具现在只是测试通过，还是已经在真实工作里证明省时间？上次生成超时后要不要重来？”当前证据只证明合成材料能生成，尚未用真实工作比较时间；超时后先核对已经写出的文件和原包，再决定从哪里继续。数据库丢失也不能靠 Git 猜回真实交付包。
最后我会得到什么
得到最近可靠的来源与交付版本、失败发生在哪一步、已经留下哪些文件，以及下一步怎样继续。合成材料已验文件生成；真实工作是否省时、交付包数据库丢失后的恢复仍缺证明。
可以正式构建
本轮需要的文件与当前事实一致且各自检查完成时，只报告已证实的层级，并给出文件和可继续的位置。
需要确认
事实未确认、资料过期或制作失败时，说明停在哪一步。超时和逐份写入失败可能已经留下部分新状态或文件，要先查实际结果再接续。真实省时价值仍需与直接做法比较。
当前不可用
保存交付包事实的数据库丢失且没有备份时，明确这份真实工作包不能恢复；旧文档或源码不能反推出完整状态。
从哪里开始
问这套交付现在能否使用、节省了什么，或数据库丢失后怎样恢复。
需要准备什么
- 要评估的交付事项或具体问题
从开始到拿到结果
- 1
看这轮实际完成到哪一步
分别核对来源与事实、文件生成、文件检查和真实工作使用证据。
- 2
失败先找已有结果
超时或中断后先读回交付包和已写文件，再从可靠位置继续；没有数据库备份时如实说明恢复缺口。
- 3
交回分层结论
逐层说明能否生成、能否复核、是否在真实工作中省时及能否恢复；一层通过不替其他层作保证。
技术实现与依据
这里保留实现、关键条件、精确入口、历史记录和验证结果。
37/37、Ruff、隔离 wheel、两套合成 Office E2E（端到端验证） 通过；真实工作价值和恢复闭环为 baseline_required / not_run关键规则与设计选择
37/37 测试与 Ruff 在 2026-09-01 基线通过；本轮仅合同改动，没有重跑 Office。
隔离 wheel 脱离源码目录完成安装闭包。
两套合成 Office E2E（端到端验证） 证明三类文件、重导入、几何与公式检查。
当前实现盲自然路由 E2E（端到端验证） 在无 Skill、工具和内部路线提示时自主选择 work-delivery，覆盖 3/3 指定来源，确认 27 条事实和 39 条追溯。
5 条待确认中的 4 条阻断正式交付，quality 保持 draft，只生成 PRD.md、manifest.json、traceability.csv，Office builder 为 0；这证明路由和质量门，不是正式 Office E2E（端到端验证）。
约 12 分 12 秒可见墙钟包含 AI 分析与人工式判断，0.043 秒成功 batch 核心只表示确定性写入；两者都不能替代同模型同质量直接基线。
首次建立交付包时，用户只做三类动作：明确选择资料、处理冲突/待确认、确认生成；不得重复录入已有事实。
同模型、同 Token 量与同质量下，初次构建总墙钟不得超过直接基线的 1.25 倍；完成第一次来源变化时累计人工时间不得高于直接基线，变更轮墙钟目标不超过直接重做的 0.75 倍。
如果直接文件能力同样能处理变化和一致性，就只保留窄工作流；受控 Agent 不优于确定性流程就保留确定性流程；真实工作只稳定复用一种产物就收窄到该产物。
没有同模型同质量直接基线，时间状态必须 baseline_required。
9月1日验收未覆盖真实工作、真实来源变化、导出备份、数据库恢复或跨机器迁移；不代表这些现实对象全局不存在。
本模块用到的名词
- baseline_required（需要基线）
- 功能可用，但缺少可比的直接处理对照；不能计算或宣称相对时间收益。
- Recovery point（恢复点）
- 最近可读来源快照、事实修订、current（当前状态） build 与持久化 manifest（清单）；数据库仍须存在。
- Synthetic E2E（合成端到端）
- 完全虚构来源走完整产品链；证明流程和成品，不证明真实业务采用。
- Implementation-blind routing（实现盲路由）
- 评测只给自然工作意图和正常能力信息，不透露 Skill、工具、项目路径或预期路线；同时检查是否自主选对入口和用户可见结果。
- Time-value gate（时间价值门）
- 用同模型同质量直接处理基线比较首轮总墙钟、变更轮总墙钟和累计人工时间；不达标就收窄产品。
专业定义
一盏总绿灯会误导：0.2.0 的功能、质量、安装和合成输出已通过，但真实工作、真实变更、时间基线与数据库恢复仍未完成。
解决什么
解决把源码、测试、安装、合成输出、真实价值和恢复能力互相冒充的问题。
当前怎样实现
- acceptance.py 分开 functional、complexity、timing 和 per-scenario checks。
- 没有合法 direct baseline 时 timing 返回 baseline_required，程序仍以可区分状态退出。
- run_batch 从请求预校验开始计时，在 SQLite 状态事务提交后、core 构建后和 Office 构建后分别调用 _enforce_mechanical_budget；超过 15 秒抛 MechanicalStageTimeoutError，CLI（命令行工具） 非零退出，不补做事务或文件回滚。
- ArtifactBuild 保存 current（当前状态）/stale、semantic hash（内容指纹）、fact revision 与 output directory。
- verify 只读比较当前 SQLite 与 persisted manifest（清单），不检查每种 Office 成品的全部像素或语义。
- builder 生成阶段使用 staging，正式文件逐个替换；跨文件中断恢复仍依赖原包和实际文件核对。
- 当前没有 export/backup/restore command、后台镜像或跨机器迁移。
执行流程
- 1
读取current（当前状态） package
- 2
检查facts与quality
- 3
verify current（当前状态） build
- 4
生成请求artifacts
- 5
分别记录test/install/E2E
- 6
核对首轮1.25倍/变更轮0.75倍/累计人工时间
- 7
判断继续窄工作流、确定性流程或单产物路线
- 8
报告real work状态
- 9
交回恢复点或不可恢复结论
边界
- 测试不替代真实工作
- 机械时间不包含AI分析
- 当前盲路由 draft 不冒充正式Office E2E（端到端验证）
- 没有合法direct baseline不计算相对收益
- 任一正式时间硬门失败就收窄而非放行
- Git不备份SQLite运行数据
- 没有导出恢复或跨机器迁移
失败与恢复
- 质量门未 ready
- 保留待确认 PRD、来源和事实，列出阻断，不生成正式 Office。
- Office builder 生成阶段失败
- 清理本轮 staging，不晋升这次暂存文件；已生成核心文件和原包状态保留。若失败已在替换阶段，另核对可能存在的部分成品。
- 确定性 batch 超过 15 秒
- 时间门失败并非整次未写入：状态提交后可能只有包和事实，core 后已有核心文件，Office 后可能已有所请求成品。先核对原稳定 ID、构建和文件，再从已发生状态继续。
- 首轮、变更轮或累计人工时间不达标
- 验收失败；减少步骤、退回确定性窄工作流或只保留真实稳定复用的单一产物。
- SQLite 数据库丢失
- 明确真实 package、来源快照、决定历史和 build 记录当前无法从 Git 恢复。
真实入口
PRIVATE source · acceptance.py功能、复杂度、时间和合成场景分层
PRIVATE source · batch.py / artifacts.py15秒检查的真实时点、已提交状态与逐文件替换边界
PRIVATE tests · 37 cases源码、CLI（命令行工具）、正式入口、wheel与失败恢复
PRIVATE README · current acceptance0.2.0 当前证据、历史路由和未完成项
如何验证
- 37 项测试全部通过，Ruff 通过。
- 隔离 wheel 完成两个合成 acceptance 与三类 Office 构建。
- 两套合成场景分别完成来源变化影响。
- 当前实现盲自然路由证明 route_selected_without_hint、3/3 来源边界、draft 质量门、builder=0、current（当前状态） verify 与旧 build stale。
- 时间在无 direct baseline 时保持 baseline_required。
- 真实工作、真实来源变化和数据库恢复仍为 not_run。
与其他模块的关系
这是当前产品证据的终点：交回真实完成层、缺口、恢复点和下一决定，不把未验证层冒充成已完成。