用途与实际影响
这项功能怎样使用
为什么需要它
如果需求文档、演示和表格各自制作，或写进别的版本目录，资料和结论很容易混用；同一版事实要先过质量门，再按需生成。
举个实际例子
我可以说：“事实已经确认，这一轮只要 PRD；评审演示和执行表以后再做。”项目只生成本轮需要的 PRD 与追溯材料，之后仍能从同一事实版本补齐其余交付物。
最后我会得到什么
完整请求会交回PRD正文、来源与事实清单、追溯表、Word需求文档、评审演示和执行跟踪表六份文件；只要PRD时交回对应子集。每一版单独保存。若制作或写入中断，会逐个说明哪些文件已成、哪些仍缺，不能把部分完成说成整套成功。
可以正式构建
这一版事实已确认，来源清单与保存状态一致时，先准备请求的文件，再逐份写入这一版目录；全部写完才交回完整文件集。
需要确认
来源清单与当前事实不一致，或文件写到别的版本目录时先停。制作或逐份写入中断后，逐个查看实际文件：可能有些已更新，有些仍是旧版。
当前不可用
制作 Word、演示或表格所需环境缺失时，保留已有 PRD、来源与追溯文件和待办，不把预览说成正式 Office 成品。
从哪里开始
确认事实后，说这轮只要 PRD，或指定还需评审演示与跟踪表。
需要准备什么
- 本轮要 PRD、Word、演示或执行表中的哪些文件
- 需要特别保留的内容或格式要求（如有）
从开始到拿到结果
- 1
先核对正式制作条件
AI 核对所选来源的当前事实版与质量状态；有关键冲突或缺证据时停在待确认草稿。
- 2
从同一版事实制作并逐份核对
所有请求格式先准备，再写入这版专属目录；有中断就逐个报告实际成品。
- 3
拿到可追溯的版本
交回本轮文件和来源追溯；某个生成器失败时说明已完成与待补格式，不能把暂存文件说成已正式交付。
技术实现与依据
这里保留实现、关键条件、精确入口、历史记录和验证结果。
0.2.0 已闭合公开 artifacts 入口、内部 canonical binding、三类 Office、跨构建不可覆盖、统一 CLI（命令行工具） 与隔离 wheel；同一构建允许重生成，完整重导入/几何/公式/视觉检查由合成验收执行关键规则与设计选择
正式输出只包括 PRD.md、manifest.json、traceability.csv、产品需求文档.docx、项目评审.pptx、执行跟踪表.xlsx。
当前没有现成项目计划、周报或汇报产物。
artifacts 公开入口只接受 database + current（当前状态） build ID。
内部 builder 要求同一进程的 canonical binding，不能作为第二公开入口。
新事实修订使用新 build 和独立目录；同一 current（当前状态） build 可重生成文件。
PRD-only 不启动 PPTX/XLSX builder。
暂存减少生成失败造成的半成品，但逐文件 os.replace 不提供跨文件回滚或整包原子性。
每次 artifacts 调用不自动执行 Office 重新导入、PPT 几何、XLSX 公式和全部页面/工作表查看；这些结论来自两套合成验收和测试。
wheel 携带两个合成场景、schema（数据结构） 和三个 builder，脱离源码目录可运行。
本模块用到的名词
- ArtifactBuild（产物构建）
- 绑定 package、事实修订、semantic hash（内容指纹）、状态、时间和唯一输出目录的一次正式构建。
- Canonical binding（规范绑定）
- 内部 builder 只接受本进程由公开入口生成的规范清单引用，用来防止误走实现脚本。
- OOXML（Office 开放文档格式）
- DOCX、PPTX 与 XLSX 的标准文件结构，可被 Microsoft Office 与 WPS 读取。
专业定义
当前正式输出严格是三类追溯文件和三类 Office 文件；不存在项目计划、周报、汇报或调用方自行追加的第七个正式文件。
解决什么
解决跨成品口径漂移、绕过质量门、其他构建目录被覆盖和安装后缺 builder 的问题；临时区避免生成失败就直接留下成品，但不提供后续逐文件替换的整组回滚。
当前怎样实现
- DeliveryCompiler 依次写 PRD.md、manifest.json 和 traceability.csv，各用同目录临时文件替换；三文件与 SQLite 状态不构成一个跨文件事务。
- artifacts.py verify persisted manifest（清单），再解析所请求 formats。
- DOCX builder 使用 python-docx；PPTX/XLSX builder 使用工作区 Node packages。
- 所请求 builder 在临时 staging 并行生成，全部返回后依次检查各文件非空并 os.replace 到所属 build 目录；没有跨文件事务或替换失败回滚。
- 两套合成 acceptance 和 tests 在构建后重新导入 Office，检查 PPT 几何、XLSX 公式和全部页面/工作表；公开 artifacts 命令本身不自动运行这整套验收。
执行流程
- 1
选择current（当前状态） build
- 2
重建并核对manifest（清单）
- 3
确认quality ready
- 4
确认输出目录属于build
- 5
生成请求格式到临时区
- 6
依次检查文件非空并单文件替换
- 7
全部替换后返回实际文件
- 8
按验收需要另行重导入/视觉检查
- 9
只读verify规范状态
边界
- 不提供任意模板商城
- 不支持现成计划/周报/汇报
- 预览QA留在正式目录外
- 每次builder不自动完成重导入/几何/公式/全页检查
- 内部环境绑定不是授权或安全证明
- 视觉合成不等于真实内容正确
失败与恢复
- 正式目录指向另一个 build
- 在写 Office 文件前拒绝，两个 build 都保持不变。
- 任一 builder 在生成阶段失败
- 不晋升本轮暂存 Office；保留核心文件与精确错误。
- 生成完成后逐文件检查或替换失败
- 之前已替换的文件不会自动撤销；核对所属 build 和各文件实际状态，再决定重生成，不能把部分输出称为完整包。
- 调用方只请求 docx
- 只构建产品需求文档.docx，不启动或等待 PPTX/XLSX。
真实入口
PRIVATE source · compiler.pycore files、quality和不可覆盖build
PRIVATE source · artifacts.py公开Office入口、staging与正式目录绑定
PRIVATE artifact buildersDOCX/PPTX/XLSX与视觉/重导入检查
如何验证
- 三种输出从同一 manifest（清单） 生成并重新导入。
- 已有 builder 失败回归证明生成阶段不晋升暂存文件，不证明逐文件替换失败能回滚。
- 跨 build 目录重定向被拒绝。
- 每个直接 builder 都要求 canonical binding。
- 隔离 wheel 携带样本、schema（数据结构） 和 builder。
与其他模块的关系
本模块形成当前正式文件；来源一旦变化，下一模块决定哪些事实和旧 build 还能继续使用。