Reference Word Format Skill
1. 目标
把用户提供的 Word 文档当作运行时格式参考模板，先分析其真实 DOCX/OOXML 结构，再用新的业务内容生成新的 Word 文档。
本 Skill 不绑定任何行业、章节、模板名称或固定文档内容。
核心原则：
> 参考 Word 决定格式；用户需求决定内容；章节结构是否继承是独立选择。
典型触发请求：
- “按照这个 Word 的格式帮我写一份 XXX。”
- “参考附件的格式生成新的报告。”
- “照这个文档版式，把下面这些内容做成 Word。”
- “保留这个模板的格式，但内容换成 XXX。”
- “按参考文档的样式生成一份新的文档。”
2. 强制前置条件：必须有参考 Word
2.1 必须执行的输入门禁
开始任何格式提取、模板复刻或新 Word 生成前，必须确认当前任务中存在至少一个可访问的参考 Word 文件：
.doc（Word 97-2003 二进制格式），或.docx，或.dotx。
2.2 没有参考 Word 时
不得：
- 从空白 Word 猜测模板；
- 根据截图或文字描述宣称“严格复刻”；
- 使用 Skill 自带的某个默认模板替代；
- 先生成一个“差不多”的 Word 再让用户补模板。
应直接要求用户上传参考 Word，例如：
> 请先提供一个作为格式参考的 Word 文件（.doc、.docx 或 .dotx）。这个任务需要从参考文档中提取真实样式、页面、页眉页脚、编号和表格等格式信息，没有参考 Word 无法严格按格式生成。
如果用户只提供 PDF/图片，可说明它可以用于视觉参考，但不满足“严格提取 Word 格式”这一 Skill 的前置条件；仍需 Word 文件。
2.3 多个 Word 文件
如果用户上传多个 Word 且没有明确哪个是格式参考：
- 优先从语义上判断哪个被称为“模板 / 参考 / 样例 / 按这个格式”；
- 若仍无法确定，只询问“哪一个作为格式参考 Word？”；
- 不要自行把多个模板混合成一个样式体系。
2.4 .doc 兼容处理（强制规则）
.doc 是 Word 97-2003 的二进制格式，不是 OOXML，不能像 .docx 一样直接读取 styles.xml、numbering.xml 等部件。Skill 必须把它作为正式支持的参考输入，但内部先标准化：
- 保留原始
.doc，不得覆盖； - 使用 LibreOffice/Word 兼容转换生成临时
.docx； - 后续格式提取、内容写入、OOXML 校验都基于该标准化
.docx； template_profile.json必须记录源格式为.doc、转换工具/版本以及转换后文件；- 严格模式下必须比较转换前
.doc与转换后.docx的渲染效果。
如果转换前后出现明显的分页、字体、表格、图片、页眉页脚、域或对象差异：
- 不得宣称已经“严格复刻”；
- 优先调整转换或生成方式；
- 若仍无法消除，应明确告诉用户 legacy
.doc转换造成了格式损失，并建议提供原始.docx版本。
因此，.doc 的支持定义为：
> 可作为必需的参考 Word 输入；通过受控转换进入 OOXML 工作流，并以视觉一致性校验约束转换损失。
3. 第二个决策：章节结构是否强制保留
“格式继承”与“章节结构继承”必须分开处理。
参考 Word 中的章节标题和目录结构属于内容结构，不等于视觉格式本身。
3.1 默认判断规则
如果用户明确说：
- “章节也保持一致”
- “按这个模板填写”
- “不要改目录结构”
- “在原章节下填内容”
则：
preserve_structure = true
如果用户明确说：
- “只参考格式”
- “内容结构按我的材料来”
- “章节可以重新组织”
- “只要版式一样”
则：
preserve_structure = false
3.2 用户没有说明时
如果章节选择会显著影响最终文档，应询问一次：
> 是否需要强制保留参考 Word 的章节/目录结构？如果不保留，我会继承它的版式和样式，但按新内容重新组织章节。
如果用户请求已经足够明确，不要重复询问。
3.3 两种模式
模式 A：严格格式 + 保留章节结构
适合固定模板、制度文件、质量体系文件、申请表、标准报告、规范性文档等。
要求：
- 保留参考文档章节层级与顺序；
- 优先在现有章节槽位中替换/填充正文；
- 原有固定章节不可随意删除或改名，除非用户要求；
- 目录由真实 Heading/TOC 机制维护，不手工伪造。
模式 B：严格格式 + 新章节结构
适合“只借用版式”的报告、方案、总结、说明书等。
要求：
- 页面、页眉页脚、字体体系、标题层级样式、正文样式、编号风格、表格视觉语言等继续继承参考 Word；
- 章节名称、数量和顺序按新内容组织；
- 新标题必须使用从参考文档识别出的对应标题样式或复制后的等价样式；
- 不把参考文档的旧章节标题当成必须保留的内容。
4. 核心方法：先提取，再生成
不得仅凭“看起来像”去复刻。
应至少分析以下层级：
4.1 文档级
提取：
- 页面宽高；
- 纵向/横向；
- 页边距；
- 装订线；
- 默认字体/语言；
- 主题字体与颜色；
- 文档默认段落/字符属性；
- 是否开启域更新；
- 兼容性/分页相关设置。
4.2 Section 级
逐节提取：
- section break 类型；
- 页面尺寸与方向；
- 页边距；
- 页眉/页脚距离；
- 首页不同；
- 奇偶页不同；
- 页眉页脚是否链接前一节；
- 分栏设置；
- 页码起始/编号方式。
4.3 页眉页脚
提取：
- 文本；
- 表格；
- 图片/Logo；
- PAGE / NUMPAGES 等域；
- Tab stop；
- 对齐；
- 边框/底纹；
- 与 section 的关系。
除非用户要求改变，生成时必须直接继承这些对象，而不是重建。
4.3.1 页眉页脚受保护部件规则（v2.4 硬规则）
页眉页脚不是普通正文 XML。它们可能同时包含 DrawingML、VML、文本框、PAGE/NUMPAGES 域、mc:AlternateContent、o:gfxdata、图片关系和旧版兼容标记。某些 XML 库对这些结构重新序列化后，即使：
- XML 语法仍然合法；
- LibreOffice 能打开；
- LibreOffice 能导出 PDF；
Microsoft Word 仍可能报“内容有问题”或直接定位到 /word/footerN.xml、/word/headerN.xml 无法解析。
因此，当用户没有明确要求修改页眉页脚时：
- 禁止解析后重新序列化
word/header*.xml、word/footer*.xml； - 禁止解析后重新序列化对应
word/_rels/header*.xml.rels、word/_rels/footer*.xml.rels； - 最终文件中这些部件必须与参考母版逐字节一致，不是“XML 语义等价”即可；
- 不允许为了“清理 XML”“格式化 XML”“统一 namespace 前缀”而重写这些部件；
- 不允许高层 Word API 在未要求修改页眉页脚的情况下保存并覆盖这些部件；
- 如果生成链路不可避免触碰了这些部件，必须在最终打包前从干净参考母版逐字节恢复它们，再重新执行全部 preflight；
sectPr中w:headerReference/w:footerReference的r:id与 type（default/first/even）必须保持参考文档语义；differentFirstPage、奇偶页不同、linked-to-previous 等 section 语义不得因正文生成而改变。
高风险页眉页脚结构：只要发现以下任一项，默认进入“禁止重序列化”保护模式：
- DrawingML：
w:drawing、wp:inline、wp:anchor； - VML：
w:pict、v:shape、v:textbox； - 文本框；
PAGE、NUMPAGES、SECTIONPAGES等字段；o:gfxdata；mc:AlternateContent；- 图片、形状、艺术字、水印或复杂 relationship。
若 Microsoft Word 报错明确定位到具体页眉/页脚部件，例如：
> /word/footer4.xml 无法解析
则必须执行以下处理：
- 将该 part 视为高优先级根因，不要先修正文；
- 如果用户没有要求修改它，从原始参考母版逐字节恢复该
footer4.xml； - 同时恢复其对应
.rels； - 禁止再让 XML 库或高层 Word API 重写该 part；
- 恢复后重新运行包完整性、结构不变量、页眉页脚字节保真和渲染 QA；
- 未全部 PASS 前禁止交付。
必须运行字节级审计：
python scripts/audit_header_footer_fidelity.py \
--reference /path/to/reference.docx \
--candidate /mnt/data/output.docx
若需要恢复受保护部件：
python scripts/restore_protected_header_footer_parts.py \
--reference /path/to/reference.docx \
--candidate /mnt/data/output.docx \
--output /mnt/data/output.restored.docx
当用户未要求修改页眉页脚时，任何受保护部件字节差异都属于 hard fail，而不仅是 warning。
4.4 样式系统
从 styles.xml 和 Word 对象模型识别：
- paragraph style；
- character style；
- table style；
- numbering style；
- basedOn 继承关系；
- next style；
- linked style；
- docDefaults；
- theme font；
- 中文/西文字体；
- 字号、粗体、斜体、颜色；
- 行距、段前段后；
- 缩进；
- keepNext / keepLines / pageBreakBefore；
- widow control；
- tab stops。
不要只读取 run.font；必须考虑有效样式（effective formatting）来自样式继承、主题和直接格式的叠加。
4.5 标题与编号
提取：
- 哪些样式承担 Heading 1/2/3… 语义；
- outline level；
numId/abstractNumId；- 各 level 的编号格式；
%1.%2等编号模式；- 起始编号；
- 缩进、悬挂、制表位；
- 标题与 TOC 的关联。
生成时不得手写 1、1.1、1.1.1 来伪造自动编号，除非参考文档本来就是纯文本编号且无法恢复编号定义。
4.6 表格
提取：
- 行列结构；
- 合并单元格；
- 固定/自动列宽；
- 行高；
- 表格对齐；
- 单元格边距；
- 边框；
- 底纹；
- 表头重复；
- 单元格垂直对齐；
- 单元格内段落样式；
- 跨页规则。
如果新内容需要同类表格，优先复制参考表格或表格结构后填值，而不是根据肉眼重新绘制。
4.7 域与自动内容
识别并尽量保留：
- TOC；
- PAGE；
- NUMPAGES；
- REF；
- SEQ；
- PAGEREF；
- 图表/题注编号；
- 书签；
- 超链接。
生成后设置 w:updateFields=true；必要时更新或物化域用于 QA。
4.8 WordprocessingML 结构不变量（硬性安全门）
仅仅满足“ZIP 能解压、XML 能解析、LibreOffice 能打开”不代表 Microsoft Word 一定能安全打开。Word 对一些跨节点成对结构和唯一性约束更敏感。
生成、删除、替换正文节点时，必须保证以下结构不变量。任何一项失败均为 hard fail，禁止交付：
w:bookmarkStart/w:bookmarkEnd：按w:id精确 1:1 成对；w:commentRangeStart/w:commentRangeEnd：存在任一端时必须成对；w:permStart/w:permEnd：按w:id成对；w:moveFromRangeStart/w:moveFromRangeEnd：按w:id成对；w:moveToRangeStart/w:moveToRangeEnd：按w:id成对；w:customXml*RangeStart/ 对应RangeEnd：按w:id成对；- 复杂字段
w:fldChar：begin → [separate] → end必须形成合法、可嵌套的字段栈；不得有孤立separate/end或未闭合begin； wp:docPr/@id：同一 story part 中不得重复，且不得缺失；w:commentReference/@w:id：必须指向存在的word/comments.xml中w:comment；- 书签名不得在同一 story 中重复，以避免 TOC/REF/PAGEREF 导航歧义；
- 任意 start/end 节点删除时，必须将其配对节点作为同一原子编辑处理，不得只删一端。
特别注意 Word 自动目录生成的 _Toc... 书签。删除、替换 TOC 附近段落时，不能只保留 _Toc... 的 bookmarkStart 或只保留 bookmarkEnd。例如只有：
<w:bookmarkStart w:id="42" w:name="_Toc11138446"/>
却没有同 w:id="42" 的 w:bookmarkEnd，即使 LibreOffice 可以容错导出，仍视为损坏候选文件，必须阻止交付。
必须运行：
python scripts/validate_ooxml_structures.py /mnt/data/output.docx
并获得 status: PASS。
4.9 直接格式与特殊对象
记录：
- 段落/Run 的 direct formatting；
- 文本框；
- Shapes；
- 图片；
- 水印；
- 内容控件（SDT）；
- 分页符；
- 分节符；
- 脚注/尾注；
- 题注。
如果这些对象影响版式，应保留或复制，而不是丢弃。
5. 格式提取产物
对每个参考 Word，应在工作目录生成一个运行时 template_profile.json，至少包含：
{
"reference_file": "reference.docx",
"format_mode": "strict",
"preserve_structure": false,
"sections": [],
"styles": {},
"semantic_style_map": {
"document_title": null,
"subtitle": null,
"heading_1": null,
"heading_2": null,
"heading_3": null,
"body": null,
"caption": null,
"quote": null,
"list": null
},
"numbering": {},
"headers_footers": {},
"tables": [],
"fields": [],
"chapter_outline": [],
"ooxml_hashes": {}
}
semantic_style_map 必须根据当前参考 Word 动态推断，不允许写死 Heading 1、正文、Normal 等名称。
如果某类语义样式在参考 Word 中不存在，应记录为 null，后续不得假装已经提取到。
6. 内容建模：AI 只描述语义，不描述视觉
AI 新内容推荐先形成结构化内容模型，例如：
{
"title": "新的文档标题",
"blocks": [
{"type": "heading", "level": 1, "text": "项目概述"},
{"type": "paragraph", "text": "……"},
{"type": "heading", "level": 2, "text": "建设目标"},
{"type": "paragraph", "text": "……"},
{
"type": "table",
"columns": ["项目", "说明"],
"rows": [["A", "……"]]
}
]
}
内容模型中原则上不要让 AI 自由指定：
- font family；
- font size；
- line height；
- margin；
- RGB color；
- table border；
- paragraph spacing。
这些属性应从参考 Word 的 template_profile / 原始样式中继承。
7. 生成策略
7.0 严格模式的技术底线：把 DOCX 当作 OOXML 包，而不是普通对象模型
.docx 是 ZIP + OOXML + Relationships + Content Types 的完整包。对于“严格按参考 Word 格式生成”的任务，不得只依赖 python-docx 读写后直接交付。高层库可能在保存时重写或丢失页眉页脚中的复杂对象、域、VML、DrawingML、文本框、关系或 section 引用，也可能产生关系不一致而导致 Word 修复提示或无法打开。
严格模式默认采用：
- 复制参考包；
- unpack 到临时目录；
- 对
word/document.xml中需要替换的业务内容做最小、局部 OOXML 编辑； - 尽量不触碰
word/header*.xml、word/footer*.xml、它们各自的.rels、相关 media，以及document.xml.rels中对应引用； - 只有确实需要新增复杂内容时，才增量修改 relationships / content types；
- 重新 pack；
- 先做包级校验，再做 Word/LibreOffice 实际打开测试，再渲染逐页检查。
如果必须使用 python-docx 写正文，可用于常规段落/表格操作，但保存后仍必须执行本节的 OOXML 完整性校验和页眉页脚保真审计。
7.1 黄金规则：复制参考 Word，再编辑
严格格式模式下：
- 复制用户提供的参考 Word 为工作文件；
- 在副本上替换或清理原有业务内容；
- 保留并复用其 styles、numbering、theme、section、header/footer 和关系；
- 页眉页脚默认按原 OOXML 部件原样保留，不重新创建；
- 插入新内容时绑定已有样式；
- 新增复杂对象时优先复制参考文档中的同类对象。
不要从 Document() 空白文档开始重建。不要先删除再“重做”页眉页脚。
7.2 当 preserve_structure=true
- 提取现有章节 outline；
- 把新内容映射到现有章节；
- 对空缺内容按用户资料处理，不擅自补知识；
- 用户没要求删除的固定章节保留；
- 原章节标题的样式、编号和顺序保持。
7.3 当 preserve_structure=false
- 可移除参考文档旧业务正文；
- 保留其格式资产；
- 依据用户新内容创建新的章节树；
- level 1/2/3… 映射到参考文档识别出的语义标题样式；
- 正文映射到参考正文样式；
- 新列表映射到最接近的参考列表样式；
- 新表格优先匹配参考文档同类表格设计。
7.4 参考文档没有对应组件时
例如用户要求插入三级标题，但参考文档只存在两级标题：
- 不要擅自声称“严格继承了三级标题格式”；
- 优先从已有层级规律推断并复制最接近的 OOXML 属性；
- 如果推断会显著影响模板一致性，应向用户说明该组件在参考文档中不存在；
- 生成后必须重点做视觉 QA。
8. 禁止事项
除非用户明确要求修改参考模板的格式，否则禁止：
- 使用固定内置行业模板替代用户参考 Word；
- 把某个历史附件的章节写进 Skill 规则；
- 从空白 DOCX 重新设计页面；
- 仅凭截图猜字体、字号、边距；
- 把标题编号写成普通文本来冒充自动编号；
- 用空格反复填充来模拟 Tab / 对齐；
- 把页眉页脚复制为正文段落；
- 无理由重建已有表格；
- 把参考文档的业务内容误认为通用模板规则；
- 为了填满章节而编造用户没有提供的事实；
- 跳过最终 DOCX 渲染检查；
- 未验证 Relationships / Content Types 就直接交付；
- 为“修复样式”而盲目覆盖
styles.xml、numbering.xml、header/footer XML，却不同时验证其依赖关系； - 用户未要求修改页眉页脚时，用高层 API 重新构造页眉页脚；
- 因 LibreOffice 能正常打开/导出而忽略书签、批注范围、权限范围、修订范围、字段栈或 Drawing ID 的结构错误；
- 删除一段正文时只删除 paired range 的 start 或 end 一端。
9. 推荐执行流程
Step 0 — 输入门禁
确认：
- 有参考 Word；
- 有用户的新文档目标或内容来源。
没有参考 Word：停止并要求上传。
Step 1 — 判断章节模式
确定：
preserve_structure=true，或preserve_structure=false。
用户未说明且选择很重要：询问一次。
Step 2 — 标准化并分析参考 Word
如果参考文件是 .doc，先生成可编辑的 OOXML 工作母版：
python scripts/normalize_reference_word.py \
/path/to/reference.doc \
--output /mnt/data/reference.normalized.docx \
--report /mnt/data/reference_normalization.json
.docx / .dotx 不需要格式转换。随后运行：
python scripts/analyze_reference_docx.py \
/path/to/reference.doc \
--output /mnt/data/template_profile.json
analyze_reference_docx.py 本身也接受 .doc，会自动标准化后再提取。结合 OOXML 与 python-docx 检查 profile，不仅依赖解析文本。
Step 3 — 渲染参考 Word 做视觉基线
对任意 .doc/.docx/.dotx 参考文件，可直接运行通用参考渲染器：
python scripts/render_reference_word.py \
/path/to/reference.doc \
--output-dir /mnt/data/reference_render
对于 .docx/.dotx，最终文档 QA 仍优先使用系统 canonical render_docx.py。
逐页查看参考 Word，理解真实版式。若源文件是 .doc，还必须分别渲染原始 .doc 与标准化 .docx：
python scripts/render_reference_word.py /path/to/reference.doc --output-dir /mnt/data/source_doc_render
python scripts/render_reference_word.py /mnt/data/reference.normalized.docx --output-dir /mnt/data/normalized_docx_render
对页面数量、分页、页眉页脚、字体、表格、图片和特殊对象进行转换前后对照；明显不一致时不得继续宣称 strict。
Step 4 — 生成内容计划
根据用户资料生成结构化内容；不要把参考文档中的示例正文自动带入新文档，除非用户要求保留。
Step 5 — 复制参考 Word 为工作副本
python scripts/clone_reference.py \
/path/to/reference.doc \
/mnt/data/output.docx
对于 .docx/.dotx，这是副本；对于 .doc，clone_reference.py 会先受控转换为 .docx 工作母版。后续只操作工作母版，不修改原始参考文件。
Step 6 — 在副本中写入新内容
严格模式优先顺序：
- OOXML 最小编辑：只修改需要变化的正文节点，保留原 run/style/section/header/footer 基础设施；
python-docx：仅用于它能安全表达的普通段落、表格、图片；- 任何高层 API 保存后，都必须重新执行包级和页眉页脚校验。
每个新增块都必须能说明它继承/复制了参考文档中的哪个格式来源。不要用“保存后再把几个 XML 文件硬覆盖回去”的方式修复包；这可能造成 relationships 与 Content Types 不一致。
Step 7 — 完整性、页眉页脚、结构/格式校验
先执行交付前硬性预检：
python scripts/preflight_word_delivery.py \
/mnt/data/output.docx \
--report /mnt/data/output_preflight.json
该预检必须同时通过两层：
- 包级完整性：ZIP CRC、必需部件、全部 XML 可解析、Relationship target 存在、rId 不重复、Content Types 映射、
python-docx可加载； - WordprocessingML 结构不变量：书签/批注范围/权限范围/移动修订范围/Custom XML 范围成对，复杂字段 begin/separate/end 栈闭合，Drawing
docPrID 唯一，commentReference 目标存在。
也可以分别运行：
python scripts/validate_ooxml_package.py /mnt/data/output.docx
python scripts/validate_ooxml_structures.py /mnt/data/output.docx
LibreOffice 成功打开或导出 PDF 只能作为兼容性与视觉 QA，不能覆盖结构不变量失败。只要结构校验为 FAIL，即使 LibreOffice 正常，也禁止交付。
如果用户未要求改变页眉页脚，强制做字节级保真审计：
python scripts/audit_header_footer_fidelity.py \
--reference /path/to/reference.docx \
--candidate /mnt/data/output.docx
然后再执行模板结构校验：
python scripts/validate_against_reference.py \
--reference /path/to/reference.doc \
--candidate /mnt/data/output.docx \
--profile /mnt/data/template_profile.json
如果要求保留章节，再加：
--preserve-structure
Step 8 — 强制视觉 QA
使用 canonical renderer：
python /home/oai/skills/docx/render_docx.py \
/mnt/data/output.docx \
--output_dir /mnt/data/output_render \
--emit_pdf
必须逐页检查：
- 字体和字号层级是否一致；
- 页眉页脚是否漂移；
- 页边距是否变化；
- 标题编号是否异常；
- 表格是否破框或错位；
- 图片是否越界；
- 目录是否异常；
- 是否出现裁切、重叠、孤行、空白页；
- 中文字体是否缺字；
- 新内容变长后分页是否合理。
发现问题后修改并重新 render → inspect → validate。
Step 9 — 交付
默认只交付最终 .docx。
除非用户要求，不交付：
- QA PNG；
- 中间 PDF；
- 临时 JSON；
- 解析缓存。
10. 严格程度
默认 strict。
strict
目标：尽可能使新文档看起来像“同一个 Word 模板生成的另一份文件”。
优先保持：
- 页面/section；
- 页眉页脚；
- style definitions；
- numbering definitions；
- theme；
- 标题体系；
- 正文体系；
- 表格视觉语言；
- 自动域机制。
允许变化：
- 新内容导致的合理分页；
- 用户明确要求的新章节；
- 数据量导致的表格增行；
- 用户要求替换的封面字段/业务字段。
11. 用户沟通规范
缺少参考 Word
只解决这个前置条件，不先讨论详细格式参数：
> 请先上传一个参考 Word（.doc / .docx / .dotx）。我需要直接读取它的样式、页面、编号、页眉页脚和表格结构，才能严格按它的格式生成新的文档。
已有参考 Word，但章节模式不明确
可问：
> 这次需要连参考文档的章节/目录结构也强制保留吗？如果不保留，我会只继承它的格式体系，并按你的新内容重新组织章节。
已经明确
不要重复确认，直接执行。
12. 验收标准
最终 Word 至少满足：
- 用户提供的 Word 是本次格式来源；
- 未偷偷切换为 Skill 内置模板；
- 已生成并检查
template_profile.json； - 页面与 section 关键参数符合参考文档；
- 页眉页脚继承正确；未要求修改时 OOXML 部件和 section 引用通过保真审计；
- DOCX ZIP CRC、XML、Relationships、Content Types 全部通过；
python-docx能加载，LibreOffice/Word 兼容打开测试通过；- 新标题使用参考文档标题体系；
- 新正文使用参考正文体系；
- 编号不是肉眼伪造；
- 表格尽量继承参考设计；
- 是否保留章节结构符合用户选择；
- 最终 DOCX 已 render 并逐页检查；
- 没有明显排版错误后才交付。
13. Microsoft Word 安全交付门（v2.4）
最终 DOCX 的交付条件是全部同时满足，而不是任意一个满足：
- OOXML ZIP/Content Types/Relationships 完整；
- XML 全部可解析；
- WordprocessingML 成对结构与字段结构全部 PASS；
- 页眉页脚字节级保真检查 PASS（用户未要求修改时；
header*.xml、footer*.xml及其.rels必须逐字节一致）； python-docx可重新加载；- LibreOffice/Word 兼容打开测试通过；
- canonical render 成功；
- 每一页 PNG 视觉检查通过。
13.1 为什么 LibreOffice PASS 仍可能不能交付
LibreOffice 对部分损坏 OOXML 有较强容错能力，会在内存中忽略、修正或重建某些结构后继续渲染。Microsoft Word 可能对同一文件显示“Word 发现无法读取的内容”、尝试修复，甚至拒绝打开。因此：
> 渲染成功是视觉证据，不是结构合法性的证明。
13.2 失败后的处理原则
发现 orphan bookmark/range、未闭合 field、重复 Drawing ID 等问题时：
- 优先回到生成步骤，找到导致结构断裂的正文替换/删除操作；
- 从干净参考 Word 副本重新执行原子编辑；
- 不建议用“随便补一个 end 标签”方式盲修，因为节点位置和语义可能错误；
- 如果确需修复，必须能确定原配对 ID、story part 和正确文档顺序，并在修复后重新跑完整 preflight + render QA。
14. 页眉页脚重序列化事故处理（v2.4）
14.1 典型故障特征
Microsoft Word 明确提示某个页眉/页脚 part 无法解析，例如：
/word/footer4.xml 无法解析
而 LibreOffice 仍可正常打开或导出。此时不得把 LibreOffice PASS 当作文件健康证明。优先怀疑生成过程中对复杂页眉页脚进行了 XML 解析后重序列化。
14.2 处理优先级
- 保留故障输出文件用于诊断；
- 从干净参考 Word 重新建立工作副本；
- 正文仅做局部最小编辑；
- 页眉页脚受保护部件不进入 DOM/XML serializer；
- 若此前已被触碰，使用
restore_protected_header_footer_parts.py从参考母版逐字节恢复； - 运行
audit_header_footer_fidelity.py，必须 PASS； - 运行
preflight_word_delivery.py --reference ...，必须 PASS； - 最后再做 LibreOffice/canonical render 视觉 QA。
14.3 最终判定原则
> 未要求修改的页眉页脚，正确目标不是“重建得看起来一样”，而是“根本不改它”。
这条规则优先级高于高层 API 的便利性。只要模板页眉页脚复杂，就应把它们视为不可重写的二进制保真资产。
