流程文档流水线（process-doc-pipeline）

一条流水线覆盖流程文档的两类生产任务：从 .epros 流程图生成《流程发布文档》，或把既有文档按规范/模板对齐格式。两者共用同一套 DLP 通道层、备份快照、终验与留痕机制。

0. 先分诊：走哪条链

模式由 task.mode 控制：auto | generate | align | review | both。auto 时按 paths 与意图判定。
复核链与另两条共用同一底座（备份快照 / 终验 / 交付留痕），区别是：产物不是新文档，而是「改回 .epros + 出问题清单」，且必须先出清单、再执行整改（先诊断后动手，§10D D3）。

1. 架构：两条链 + 共享底座

                    ┌──────────────── 共享底座 ────────────────┐
                    │ DLP 通道层(dlp_channel) │ 备份+MDS 快照   │
                    │ 参数配置块(唯一覆写入口) │ 终验 + 交付留痕 │
                    └──────────────────────────────────────────┘
                                     │
        ┌────────────────────────────┴────────────────────────────┐
        │                                                          │
   【生成链 generate】                                      【对齐链 align】
   Phase A  解析 .epros（探针 + 泳道 + 连线）                Phase B  基准萃取（规范 + 模板实测）
   Phase C-G 按模板生成 docx                                Phase C-A 逐维度对齐格式
        │                                                          │
        └──────────────────────► Phase D 统一终验 ◄────────────────┘
                                       │
                              Phase E 交付与留痕

核心区别：

2. 参数配置块（唯一覆写入口）

所有具体值集中在 config.template.yaml，正文只引用变量名，禁止散落硬编码。

cp config.template.yaml config.yaml     # 复制后填写
python scripts/check_config.py config.yaml --strict

关键键组：

回填纪律：epros.values 与 spec_values 必须由实测回填，禁止推导或凭记忆填写；未回填即中止。

2A. 能力矩阵（索引 · 2026-11-05）

> 权威表见 references/capability-matrix.md（5 域 27 项，含定义 / 覆盖范围 / 对应流程环节 / 填写规范 / 开源对照）。本节只放索引，避免双事实源。

一句话口径：A 域管"图像不像、通不通"，B 域管"版式正不正、章齐不齐"，C 域管"表填不填得下"，D 域管"三件对不对得上"，E 域管"改得安不安全"。

开源对照采纳纪律（详见 capability-matrix §八）：bpmnlint（规则可插拔+严重级）、bpmn-moddle（未知属性透传→不重序列化）、bpmn-auto-layout（缺 DI 自动补布局）为机制借鉴；pm4py（AGPL-3.0）、drawio（GPL-3.0）一票否决不集成，只读方法。

待补 3 项（capability-matrix §九）：判据「严重级 + 阻断开关」未成列；折线重算未独立成 CLI 子命令；三方对齐表（图/文/表同轴）无固定模板。

3. 执行流程

> 每步格式：输入 → 操作 → 输出 → 门禁。任一步门禁不通过则中止并回报，不得跳步。

Phase 0 · 环境与通道预检（两链共用）

文件头判据见 references/docx-com-recipes.md §1.1。

生成链

Phase A · 解析 .epros

解析约定（FigureType 分布、泳道空带陷阱、DottedRect 双重语义）见 references/epros-format.md。

EPROS 客户端打开兼容性（2026-10-13 实测排障，「打开异常」根因库）——生成/改写 .epros 后客户端报「打开异常」时逐项排查：

排障方法：读 D:\EPROS-M\epros_log\epros_log.txt 取真实堆栈（比试错快）；用最小探针二分定位（标题+泳道+1角色+1活动+1连线 能开 → 逐项加特征）。

序号呈现规范（2026-10-14 实测，用户定稿）——EPROS 客户端活动框为双层结构：顶栏渲染 ActivityId、正文渲染 FigureText。流程序号（010/020/…，源文档活动表编号）必须放在顶栏：

• 勿把序号写进 FigureText 前缀（如 "010 调研任务接收…"）——会与顶栏并存形成双序号冲突；序号只进 ActivityId。
• 协作框双副本顶栏同号（如两个 050）：主责/参与副本共用同一逻辑序号。
• 序号取源：源文档（V1.1 活动表「编号」列）为准，间隔 10（010/020/…）；先核对源文档编号再改，不得自造编号体系。
• 渲染器同步：PNG 渲染顶栏序号读 ActivityId（而非 FigureText 前缀），正文读 FigureText。

Phase C-G · 按模板生成 docx

版面与字体规范、四个 COM 必踩坑、保存策略见 references/docx-com-recipes.md。

模板基准（V1.1 现行 / 9.25 历史，2026-10-16 更新）

> 现行基准（2026-10-16 用户改指定，取代 9.25）：产品市场信息调研分析流程-V1.1.docx + 竞争对手产品分析流程-V1.1.docx（两份实测格式 100% 同构）。
> 历史基准：流程打样/9.25/2.1.1…docx + 2.1.2…docx（仅版本溯源用，版式口径已作废）。
> 编制要求（《恒泰-EPROS操作标准化-V1.0》「基本属性设计」15 字段）按映射归入下表章节，不另起结构。
> ⚠️ 本节是「生成链」的骨架与版式基准；「对齐链」的参考基准由当批用户指定，两者不是同一套、不得互相覆盖（2026-10-19 对齐批用 2.1.1…9.17日-2 / 2.1.2…9.17-1，数值与本节不同）。对照表见 §10C C8 基准登记。

章节骨架（12 章 + 2 子节，序号+顿号编号）：

1、流程档案  2、定义  3、目的  4、适用范围  5、术语和定义  6、角色与职责
7、流程图    8、流程说明  9、裁剪指南  10、流程绩效指标  11、支持文件
12、文控信息 → 1. 文件拟制/修订记录  2. 附则

表格口径（10 表，列头逐字锁定）：

编制要求（PPT 15 字段）→ 章节映射：概述→章1档案「流程概述」行｜目的→章3｜适用范围→章4｜术语定义→章5｜流程驱动规则→章1档案「流程驱动规则」行｜输入/输出→章1档案 + 表5 列｜角色/职责→章6｜流程图→章7｜活动说明→表5（含 KCP/风险控制措施写入「活动内容」列）｜相关制度/相关标准→表5「相关规则/标准」列 + 章11｜支持文件→章11｜相关风险→表5「活动内容」列注 + 章3/10｜绩效指标→章10。

连接关系表定位：「流程节点连接关系表」（编号|节点名称|节点类型|所在泳道|前置节点|后置节点）模板中无此独立表。当客户要求交付「图+节点表」时按表 3 位次插入第 7 章（2026-10-16 实例：2.2.2/2.2.5 均已随图交付），否则仅作内部图文对照用。

V1.1 版式口径（实测锁定，逐项可脚本校验）

表格列宽铁律（2026-10-16 三轮实测，最易踩坑）

1. 先按「所在节可用页宽」定上限：节1 封面 9638｜节2/4 纵向 9426｜节3 横向 14358（twips）。不可直接照搬基准 gridCol 值 — 基准表无 tblW 靠 AutoFit 自动压缩，其值本身常超页宽（活动表 14850 vs 纵向 9426），一旦 AllowAutoFit=False 固定列宽即溢出。
2. 再按内容适配（而非等比缩放）：逐列测算最长内容所需宽度，重点保证标签列（如档案表 C1 需容纳「流程负责人（岗位）Process Owner」→ ≥2300 twips）与长值列；短值列（L1/L2/L3/L4 → 1200 twips）可压窄。
3. 档案表参考分配（9426）：[2300, 1200, 2360, 1900, 1666] ＝ 主标签 115pt / 层级 60pt / 主值 118pt / 次标签 95pt / 次值 83pt（R7-R10 合并值区 356pt）。
4. 生成后必验：脚本逐表核对 Σ列宽 ≤ 节可用宽 + 表格数量/行数（_verify_layout.py）。

连接关系表定位补充：交付含节点表时，第 7 章结构为「业务流程图（图题 14 磅居中 li=36/fi=17.85）」→ 图片 → 「表 N 流程节点连接关系表」→ 表 → 注释段。

生成链内容纪律

1. 每个 figures 中有文字的节点（排除 MapNameText/RoleFigure/空文本 DottedRect）必须在「活动说明表」（表5，9 列）占一行，编号取 ActivityId（流程序号 010/020/…）。
2. 因 DottedRect 协同而合并的重复节点：文档行数 = 节点数 − 合并数，并在「活动内容」列写明协同关系（双责任活动合并为一行，角色列写「主责；参与」）。
3. 「流程节点连接关系表」仅内部图文对照用，不入正式文档正文（模板无此表）；留存放「附则」附件或交付留痕。
4. 流程绩效指标（章10，每个指标独立一表）与流程档案字段（L1/L2/L3/L4、输入/输出、流程驱动规则、负责人/PC）优先引用企业架构卡/源文档；确无来源的字段填「待补充」等占位并明确标注。
5. 不臆造数据；缺口写「待补充」并注来源时效。KCP/风险控制措施写入表5「活动内容」列（PPT「活动说明」第 3 条）。

Word COM 生成 · 运行时陷阱与收口（2026-10-16 实测，逐条踩过再修好）

> 本节是「按模板生成 docx」的必备避坑集。全部坑均在真机上复现过，修法已验证；新增生成逻辑时逐条对照，勿凭直觉回退。

A. 结构性七坑（会导致内容丢失/错位）

B. 运行时格式五陷阱（会导致「逐章不一致」的观感问题，最易被漏检）

C. 三道收口（缺一不可，按序执行）

内容构建 → ① 按章标题 Sections.Add 分节
         → ② 分节符段格式化（判据：紧随「标题 1」的空段，或前后节号有差异）
         → ③ 表格/图片/目录域插入
         → ④ 分节符段「复检」（防被 TOC 域范围波及）
         → ⑤ 兜底回落：空段＋标题样式 → 正文（并补字体/段格式）
         → ⑥ 保存：SaveAs2(同目录单扩展名临时名, 16) → Close(False) → os.replace 重试

> ⚠️ 判据踩坑记录：勿用 p.Range.End >= Sections(sec).Range.End - 2 收紧「真分节符段」判据 —— 实测会漏处理 1 个分节符段并导致章节骨架校验失败。用「紧随标题1」＋「兜底回落」组合最稳。

D. 校验闭环（生成后必跑，全部只读）

E. 保存与落盘（DLP 环境）

• SaveAs2(临时名, 16) → Close(False) → os.replace 重试；临时名必须单扩展名（*.docx.tmp.docx 会致 SaveAs2 无限挂起）。
• 落盘后验证文件头 00 00 5b 00（亿赛通加密态）。

多角色活动 · 协作框规范（亦称「协助框」；2026-10-13 立，2026-10-16 补强）

• 判据：活动标注多责任人（分号分隔，如「营销部长；产品经理」）时，不再以「单框落于单一泳道」近似，改用协作框：每个责任角色的泳道各放一个同文本活动副本，副本外裹橙色虚线协作框（DottedRect，空文本，BodyColor 橙 235,97,27）。
• 组内关系：副本相互并行且同进同出——共享同一上游活动与同一下游活动；协作框须在连线/节点之前绘制。
• 连线接法：协同分主次（标注首位=主责）时，进出连线只接主责副本，次责副本不接线；不分主次时，连线接协作框边缘（箭头落在框边）。
• 双通道判据（2026-10-16 用户拍板 · 强制规范）：同一项活动涉及多个人员时，必须择一表达——① 添加协作框（首选；橙色虚线外裹副本组）；② 依据逻辑关系添加连线（副本与上下游逻辑相连、同进同出）。二者并存更佳；禁止多人员副本既无框、又无线、孤立悬挂于泳道。
• 生成器默认行为（2026-10-16 实测沉淀）：跨泳道副本组自动外裹协作框——左右各余 17px、上下各余 23px、橙色 235,97,27、先于节点与连线绘制（OrderIndex 靠前）；实测 2.2.7「140 签字确认」4 副本 → 协作框 134×706，校验无新增告警。连线仍接主责副本（表序首位泳道），次责副本由协作框表达组关系。
• 布线纪律（重排/协作框改造类任务）：
  1. 左进右出，复杂场景可左、上进（同《恒泰-EPROS操作标准化-V1.0》活动连接规范）；
  2. 同排相邻节点直连，不为对称而强加拐弯；
  3. 改前逐项断言原坐标/原折线，改后拓扑守恒（起讫节点三元组 + 判据标签不变）；
  4. 干线走廊预留：拐头竖线、协作框边、既有折线相互保持 ≥10 坐标单位间距；
  5. 绕行分层：需跨越带状障碍（并行框/节点列）时优先走带外走廊（空泳道带如「客户」带、画布底部空带），其次同带内插空，禁止横穿协作框内部；
  6. 目标：不同连线横向交叉数 = 0（不同边线段严格内点相交计 1 次，共线共享干道/端点汇入不计）；源图固有交叉如实留痕，重排机会成熟时一并消除。
  7. 竖向分叉点对齐（2026-10-16 用户拍板 · 强制规范）：横向存在多条连线时，各条连线的竖向分叉点必须对齐在同一位置。含义与实现：
  • 同源出线：同一节点出发的多条分支，其竖向转折杆共用同一 x（分叉点对齐）；
  • 同目标入线：汇入同一节点的多条分支，其竖向汇合杆共用同一 x（汇合点对齐）；
  • 禁止：各分支各自选位、形成高低参差的分叉/汇合位置（视觉上"三岔口"不齐）；
  • 实现：① 按「源节点 或 目标节点 ＋ 方向」对连线分组；② 组内取统一横向槽位（节点级共享槽位，生成器默认行为）；③ 库内优先用「同源侧/同目标侧共享竖杆 ＋ 3 段 Z 形」而非多条独立折线；
  • 校验：抽取各连线转折点坐标，按组断言 x（纵向分支）或 y（横向分支）取值唯一；不唯一即判不通过；
  • 实证（2026-10-16）：2.2.7 合同签订流程全图 8 组共杆全部达标——审核双出 x=1072、评审汇入 x=1312×4、四级评定双出 1642/1832/2022/2212、起草汇入 x=2848×3、审批双出 x=3162；单线组零冗余偏移（坐标分组统计脚本一键复核）。

元素定义与职责（2026-11-02 用户裁决 · 菱形与 XOR 严格分家）

> 完整版：<工作区>/_out10/EPROS元素定义与职责说明-V1.0.md（53 份样本 / 1629 图元实测）。

两条分界（最易混淆处，务必先立住）：

1. 菱形 Rhombus = 判断框，只表达条件分支（这件事做不做 / 过不过），它不是网关，不承担并行、汇合、分流的路由职责。
2. XORFigure / ORFigure / AndFigure 是三个独立的圆形网关元素，表达"多路如何路由"。二者是并列关系，不是包含关系，不得合并描述、不得互相映射。

五维区分（判断"该用哪个"）：

一句话：要"判"用菱形，要"分"用网关——判定产生结论，网关消费结论。判据已由上游活动产出、此处只需按结果选路 → XOR；需要在本节点当场作出决定 → 菱形。

映射铁律（生成器 map_node_type，2026-11-02 起取代 2026-09-24「决策关键词优先」旧规）：名称带 XOR / AND / OR 前缀 一律映射为对应圆形网关，不得因名称含「评审/审批」而改画菱形（旧规正是这样把 XOR 语义吞进菱形）；无类型前缀、且为判定语（审核/评审/审批/判定/是否通过…）才映射为菱形。判不准 → 留空报「请裁决」，不猜。

连接点（锚点）规范（2026-10-14，实测驱动）

EPROS 元素边框上的固定吸附位置称「连接点」，连线端点必须精确落在其上（差几单位即红 ✕ 报「未连接到连接点」）。

• 连接点位置：
• 矩形活动框（RoundRectWithLine）：四边中点各 1 个（共 4）；
• 菱形判断框（Rhombus）：四个顶点各 1 个（共 4）——落斜边（哪怕居中）即红 ✕，必须落角尖。
• 同方向单锚点：每个元素每个方向（上/下/左/右）只有 1 个连接点；多条线汇入同一方向时共用同一锚点（如 120 左缘的 e208+e217 共用一点），不得同方向挂 2~3 个不同点。
• 菱形出边顶点分工（硬规则；2026-10-14 立，2026-10-17 用户重申并落地生成器）：审核通过 → 右侧顶点；不通过（退回）→ 底部顶点；两者不得共用同一顶点。⚠️ 按元素定义（2026-11-02）：菱形是判断框，出度以 2 为常态（是/否）、最多 3（如"通过／有条件通过／不通过"）；若出现 ≥3 条并行向前分支，说明此处是并行路由而非判定，应改用 AND/OR 网关，不得用菱形承载并行语义。同一审批框扇出的多条通过类分支全部从右侧顶点引出后分叉（属同锚点多边，仅限 ≤3 且互斥）。入边仍恒走左侧顶点（左进右出总纲不变）。
• 生成器默认行为（2026-10-17 实测沉淀）：菱形双分支由生成器自动分工——正向（通过）边走右侧顶点；回边（退回）自底部顶点直下图底回流区（→ 回流区横线按目标节点分层，多条回边互不交叉 → 目标列隔离带竖线上行 → 目标左缘；4 段折线）；底部直通路径有障碍（同列下方存在节点盒）时，短降 18px 横移至源侧隔离带再下行，不压节点盒。分支标签贴连线起点旁（首段为长段时不再取中点，避免标签漂离源节点）。实证 2.1.3：040 审核退回自底部顶点 (1010,315) 直下至回流层 y=990、050 审批退回自 (1200,615) 直下至 y=1006，两线共用目标侧竖杆 x=568 汇入 020，横向交叉 0；verify_epros --pair FAIL=0。
• 精确吸附：端点坐标 = 连接点坐标（偏差须 <0.01）；EPROS 客户端拖动节点会自动吸附，但新增/手改连线后必须复核落点（审计脚本：逐边逐端点算到最近连接点距离）。

EPROS 客户端行为特性（避坑）

连线修改经验（平移/退回/拐点）

1. 节点平移 → 连线折点同步平移 Δ：起讫点、中间拐点全部跟随；漏调拐点会导致折线斜穿或绕远。
2. 退回线贴紧：退回线水平段 y 只需避开沿途节点（间距 30~50 即可），不留过大下方空白走廊；回路越紧图面越干净。
3. 拐头竖线按走廊重算：拐头位置取决于左右两侧元素间距（≥10），不是简单跟随节点平移；节点移动后逐条复检拐头与相邻元素/连线间距。
4. 大幅重排后必查画布：WorkflowWidth/Height ≥ 最右/最下元素坐标；最后一条泳道分隔线 y < 画布高度（否则泳道带高度为负）。

修改后自检清单（6 步，逐次过）

1. 锚点吸附：所有连线端点精确落在连接点（矩形=边中点、菱形=顶点）；
2. 同方向单锚点：每元素每方向 1 个连接点（多边可共用）；
3. 顶点分工：菱形通过=右侧顶点、不通过=底部顶点、不共用；
4. 方向合规：出=右侧/底部、入=左侧/上部；
5. 交叉=0 / 穿体=0；
6. 画布覆盖：WorkflowWidth/Height ≥ 内容范围，泳道带高度全为正。

手工修改比对与版本快照（2026-10-15 实测，三轮手工改版驱动）

用户在 EPROS 客户端手工改图是常态（对齐分支、加分组框、改挂载副本）。每一轮改版都要能回答「改了什么」，否则图文对照失据。

① 先留快照，再谈比对（最高频疏漏）

② 语义比对，禁止文本 diff

EPROS 保存会重写 UUID 与属性顺序，逐字节 diff 全是噪声。按下列键匹配后逐项比几何：

③ 双副本挂载副本轮换 ≠ 缺陷

跨泳道同名副本（同 ActivityId）只有一份接连线，另一份孤立。用户可能把挂载从主责副本切到审批/后置方泳道副本（实测 2.2.5「销售价格确定与审批」由营销部长泳道切到事业部经理泳道，四条线随之重走，孤立副本同步轮换）。

• 判据：节点集合、类型、文本、泳道、分支标签、连线总数不变 → 属画法选择，不判缺陷；
• 与「多角色活动·协作框规范」（只接主责副本）冲突时，回报客户确认主责口径（同步 ch7 泳道列与角色职责表），勿自行改回。

④ 分组框（DottedRect）避让与穿越豁免

⑤ 批次固有告警判读（不拦交付）

跨泳道双副本必然触发三类告警，只核数量与标签，不看编号：孤立业务节点 / ActivityId 重复 / 节点表行数 vs 产物节点数差 1（差＝副本数）。出现 FAIL 才拦；这三类维持 WARN 即可交付，并在报告中注明成因。

⑥ 类型词与校验器词汇同步

规格侧新增节点类型词（如「起始」「结束」）时，同步补校验器的类型词映射表，否则生成侧接受、校验侧报假 WARN（曾误报 C6）。

⑦ 编号口径先核对再动手

同名 .epros 可能同号不同名（如 2.2.4报价流程 与 2.2.4关键角色攻关流程）。取号一律以架构卡/流程清单为准，并核对目标目录下既有文件是否已占用该编号；改号时同步生成器缩写映射表（ABBR），勿只改文件名。

比对后自检（4 项）

1. 快照已存：本轮与上一轮 .epros 均有独立副本，未原地覆盖；
2. 语义零漂移：节点集/连线集/标签/根元数据与规格 md 的节点连接关系表逐行对应；
3. 几何无新伤：走线穿越检查 0 处（分组框必需穿越已豁免）、画布仍覆盖内容；
4. 告警未升级：WARN 项数量与成因同上一轮，无新增 FAIL。

流程图高保真重建（EPROS XML → PNG，生成链可选步）

python scripts/gen_flowchart.py -i "流程图目录" -o "流程发布文档" --dpi 150
python scripts/verify_flowchart.py "流程.epros" --png out/flow_x.png --strict

保真原则（核心，勿改）

EPROS 源文件已给出权威布局，渲染器绝不重新排版：

> ⚠️ 不引入 Graphviz / ELK / dagre / pyorthogonalrouting 等布局布线库：
> 它们会重新计算布局，反而破坏与原图的一致性 —— 与「提升准确性」背道而驰。
> 仅当某条边缺 lineSegments 时用内置 L 形正交兜底（实测语料 0 例）。

已修复的两个保真缺陷（勿回退）

渲染细节

• 角色列：VerticalLines.PoLongx（恒 160）画竖分隔线；RoleFigure 按其原始坐标画淡黄圆角框（x≈23~32, w=100, h=60），不要用「贴左浮动文字」近似。
• 图名：MapNameText 居中作标题；责任标记 Right/ReverseArrowhead 画三角 + 文本（R1/R2）。
• 分组盒 / 协作框：空文本 DottedRect 画虚线框，须在连线/节点之前绘制；多角色协作框按《恒泰-EPROS操作标准化-V1.0》用橙色虚线（BodyColor 橙 235,97,27），源文件自带红色的普通分组盒照源色。
• CJK 字体：按 simhei.ttf → msyh.ttc → simsun.ttc 探测并 fontManager.addfont。
• 输出映射：不用 bbox_inches='tight'（会让数据→像素映射不可算）；改用轴铺满整图 + 显式 xlim/ylim，同时写出 flow_<key>.meta.json 侧车供像素校验。

重建结果的验证（14 项）

> 实测 30 份语料 0 FAIL、穿体率 0%。
> P-3 若报重叠，多为源文件自身的布局问题（实测 1.2.2 有 2 对节点重叠），
> 属如实转述而非渲染缺陷 —— 应回报原作者修正。

对齐链

Phase B · 基准萃取

四个关键（详见 references/alignment-rules.md §4.2）：

• 必须区分「样式定义值」与「实际生效值」 —— 探针应读 Paragraph.Range.Font 而非 Styles(nm).Font。
• 页边距按节分组实测 —— 封面节/正文节/横向节常为三组不同值，不得只取节 1。
• 加粗口径按表实测 —— 逐表登记到 bold_policy_per_table。
• 样式名不可作为分类依据 —— 实测同一批文档里，有的全篇只有一个「正文」样式（无标题样式、无目录域、章标题靠 15 磅加粗＋文本判定），有的用自造样式名（表格内容/段/table++）。基准画像与套用规则一律按文本角色归集，样式名只作辅助线索。

Phase C-A · 对齐执行

执行前必须先完成备份 + 基线快照（含 MD5 清单与全文文本 dump），否则不得进入本阶段。

批量批次（≥3 份文档）的三条附加纪律（详见 §10C）：

1. 写后必「全量复审」：套用脚本自带的自检不算数，必须用独立只读审计逐条复核（同一进程内的回读会掩盖未生效的赋值，实测 4/10 份标题段距「设了但没落地」只有在独立复审时才暴露）；
2. 定点修复后必须再全量复审一次：定点脚本只碰目标属性，易与其他层相互覆盖；
3. 每份文件的 before/after 画像必须落盘（_profile 输出 JSON），交付报告的证据从这里生成，不得事后手工回忆填写。

Phase D · 统一终验（两链共用）

G 系列（生成链）：G-01 活动行数守恒 / G-02 泳道名一致 / G-04 无文本节点已声明 / G-05 悬空边已提示 / G-06 横向节生效 / G-07 表头灰底加粗 / G-08 中文字体 / G-09 章节骨架=模板基准（12 章+2 子节，序号+顿号） / G-10 表格列头=模板基准（10 表逐字，表5=9 列）。

V 系列（对齐链）：V-01 文字零改动 / V-02 字体字号 / V-03 行距 / V-04 边框加粗 / V-05 页边距按节 / V-06 字段命名顺序 / V-07 页眉页脚 / V-08 颜色 / V-09 结构完整性 / V-10 编码态 / V-11 段距单位与取值（行单位已清零、回读磅值＝目标值） / V-12 表格字号分档（按表型：审批栏/活动说明表/普通表）。判据详见 references/alignment-rules.md §3。

V-01 的判据修正（2026-10-19 批量实测）：Word 自动目录域在版式重排后页码必然变化，这不属于正文改动。判据须做差异归因：

逐字符校验刚性要求：
- 表头加粗必须 sum(1 for ch in cell.Range.Characters if ch.Font.Bold) > 0，只读 Range.Font.Bold 查不出丢失；
- 有纵向合并的表必须遍历 Range.Cells，for row in tb.Rows 会抛异常；
- 颜色判据取 OOXML styles.xml/document.xml，不取 COM。

三项易误判的判据（已按实测校正）：

Phase E · 交付与留痕

4. 硬约束

4.1 执行时守卫（把事故变成断言）

> 动机（2026-10-12）：一日内发生两起事故（分节符误删致节数 4→3、COM 哨兵误判边框致 181 格单元格边框被抹），
> 都在复验阶段才被发现。结论：缺的不是「教训」，而是执行时就跑得起来的断言。

from verify_common import bootstrap; bootstrap(__file__)
from docx_guard import Guard, safe_delete_paragraphs, refresh_toc_then_restore, save_dlp
from docx_probe import structure_fingerprint, find_blank_runs

before = structure_fingerprint(doc)          # ① 先取指纹

with Guard(doc, "删空行"):                   # ② 编辑包在守卫里
    safe_delete_paragraphs(doc, [167, 168])  #    内置分节符保护 + 从后往前删

refresh_toc_then_restore(doc)                # ③ 先刷域 → 再重建制表位（顺序固定）
save_dlp(doc, path)                          # ④ SaveAs2 + 重试 + 落盘

四道闸门：

第五类断言（2026-10-19 增）· 段距写入后回读校验 —— 上述四门管「结构不变量」，不管「格式是否真的落地」。
批量套用时务必加这一条（纯 COM，无模块依赖）：

def assert_space(p, before, after, tol=0.1):
    pf = p.Format
    for got, exp, unit in ((pf.SpaceBefore, before, pf.LineUnitBefore),
                           (pf.SpaceAfter,  after,  pf.LineUnitAfter)):
        unit = unit or 0.0                      # COM 可能返回 None
        if abs(got - exp) > tol or unit > 0.01:
            raise AssertionError("段距未落地: got=%.2f exp=%.2f lineUnit=%.2f"
                                 % (got, exp, unit))

• 必须在另起的只读进程里回读（同一会话回读到的是刚设的值，恒过）；
• 逐段跑成本可接受（500 段 × 2 属性 ≈ 1~2s），但批量时改为「抽样 + 全量签名比对」：抽样校验取值，全量校验角色分布。

5. 冲突裁决

6. 输出规格

6.1 交付门（2026-11-05 起 · 与 §10D D1 的等级列联动）

一句话：P0 不清零不出门，P1 不登记算漏检，P2 可归并，三件不对齐不算完。

7. 依赖与版本约束

> 唯一事实源：pyproject.toml 的 [project.dependencies]（本表须与之同步）。
> 装了但用不到的可选件一律优雅降级，不阻断主流程。
> extras 三档（选型报告 P0，对标 docling 分层）：minimal 仅解析校验（无需 Windows/COM）｜
> office 完整作业运行时（COM 通道 + 重建 + 配置 + 明文 xlsx）｜test 全量回归。

锁定理由（选型报告 P0）：defusedxml==0.7.1 —— API 已冻结、XXE 加固不可替代，仅作加固层不承载业务逻辑；
openpyxl==3.1.5 —— 官方仓库在 Heptapod（非 GitHub）、发布节奏慢，锁版本防 API 漂移外溢。
python-docx 不入运行时依赖：维护模式（近 6 月默认分支 0 提交），仅作 OOXML 对象模型命名语义的参考实现；DLP 加密下读不了，走 COM。

# 完整作业运行时（office 档）
pip install "pywin32>=306,<313" "defusedxml==0.7.1" "lxml>=6,<7" "comtypes>=1.4,<2" "matplotlib>=3.8,<4" "pillow>=10" "pyyaml>=6.0" "openpyxl==3.1.5"
pip install pytest          # 仅开发/回归需要（test 档）

7.1 评估依据（周下载量 / 生产案例 / 维护活跃度，数据实测于 2026-10-12~13）

采用

剔除（附理由）

核心取舍结论（两条）：

1. 不引入任何布局/布线库——EPROS 已提供 100% 精确且正交的连线几何，
   重算布局会降低而非提升与原图的一致性。最准确的重建方式就是照搬源几何。
2. 不引入结构化日志库——批处理脚本用轻量 info()/warn() 已足；
   若将来接入 CI 日志采集再评估。

8. 脚本清单

分层口径：docx_probe 只读、docx_guard 只写、verify_* 只验 —— 三者不交叉。
一次性诊断脚本不再落盘，改用 docx_probe.py CLI；确需临时脚本时，先确认原语模块是否已覆盖。

工程约定（改脚本前必读）见 references/engineering-conventions.md。
事故档案与症状→处置对照见 references/docx-com-recipes.md §九。
交付说明统一模板见 references/delivery-note-template.md（Phase E 依据，≤5 节）。

9. 自检命令

# ★ 改动后先跑这个：全链路自检（含 pytest 全量）
python scripts/selfcheck.py
python scripts/selfcheck.py --epros "路径/流程.epros"    # 追加真实语料回归

# 0) 配置校验
python scripts/check_config.py config.yaml --strict

# 1) 通道预检（DLP / COM 可用性）
python scripts/dlp_channel.py <参与文件...>

# 2) 生成链：解析 .epros
python scripts/epros_probe.py "路径/流程.epros" --json probe.json

# 3) 生成链：高保真重建流程图 + 几何保真度校验
python scripts/gen_flowchart.py -i "流程图目录" -o "输出目录" --dpi 150 --strict
python scripts/verify_flowchart.py "路径/流程.epros" --png out/flow_x.png --strict

# 4) 终验
python scripts/verify_docx.py 'D:\path\输出.docx' --chain generate --probe-json probe.json
python scripts/verify_docx.py 'D:\path\输出.docx' --chain align --backup 'D:\bak\原稿.docx'

# 4b) 结构指纹留痕与跨轮比对（N-04：每轮作业存一份，漂移退出码 1）
python scripts/docx_probe.py 'D:\path\文档.docx' --fingerprint fp_本轮.json
python scripts/docx_probe.py --fp-compare fp_上一轮.json fp_本轮.json

# 5) 单元测试
python -m pytest tests/ -q

# 6) 基准跑批（可选；改动后与基线比对，>3× 判漂移）
python benchmark/run_bench.py --json benchmark/baseline_20261013.json

退出码约定

所有脚本统一遵守；--strict 会把 WARN 也升格为失败。
结果走 stdout，诊断走 stderr —— prog > report.txt 只拿结果。

10. 最小执行清单

生成链
- [ ] Phase 0 路径校验 + DLP 探测 + 单通道确定
- [ ] Phase A 解析 .epros → expected_rows 与待确认清单
- [ ] Phase C-G 按模板生成（分节版式 → 逐章写入 → 插图 → 域刷新）
- [ ] Phase D G 系列终验（节点守恒/泳道一致/字体/横向节）
- [ ] Phase E 交付说明 + 待确认项 + 呈现文件

对齐链
- [ ] Phase 0 路径校验 + DLP 探测 + 单通道确定
- [ ] Phase B 规范条款抽取 + 模板参数实测回填
- [ ] 备份（含 MD5）+ 文本基线 dump
- [ ] 待改项清单（格式类 / 内容类分离）
- [ ] Phase C-A 分维度小事务执行（每批 ≤10、批后即验）
- [ ] Phase D V 系列终验（文字 diff / 格式抽验 / 结构 + 编码态）
- [ ] Phase E 交付说明 + 待确认项 + 呈现文件

10A. 流程梳理全案经验 · 应包含的要点 / 覆盖范围 / 预期效果（2026-10-16 系统归纳）

> 本节为单日五轮迭代（业务流程图梳理 → 流程文件编制 → 多源标准融合 → 走线规范 → 协作框标注）的系统归纳：
> 把当日发现的问题与难点提炼为可复用经验要点，明确本技能「应包含的要点 / 覆盖范围 / 预期效果」，供后续同类任务直接对照执行。

10A.1 应包含的要点（11 条 · 逐条可执行）

10A.2 覆盖范围

• 输入侧：DLP 透明加密环境下的参考标准（xlsx / docx / pptx，含 sheet 内嵌流程图）、存量流程文件（.epros / md / docx）、用户口述绘图规范；
• 处理侧：.epros 生成 / 校验 / 渲染 / 目检全链；多源标准融合与对齐声明；节点—顺序—逻辑—角色—编号全链梳理；走线规范（竖向分叉点对齐、菱形顶点分工、协作框 / 连线标注、回退线走图底回流区）；流程文件 12 章编制、版式对齐与 Word 发布文档生成；
• 输出侧：.epros 工程文件 ＋ 高保真预览 PNG ＋《流程图交付文件》（12 章）＋《流程标准》（绒布体例）＋ 交付说明与留痕（版本备份 / 校验报告）。

10A.3 预期效果

1. 不重复踩坑：编号错乱、顺序错位、角色映射不一致、走线歪斜、多人员副本孤立悬挂、菱形双分支共挤同一顶点、版本覆盖丢改动——七类已知问题均已有前置判据与校验断言（要点 2/4/5/6/7/9/11）；
2. 一次做对：三条绘图规范与协作框均已沉淀为生成器默认行为，正常生成即符合规范，无需事后手工修补；
3. 全链可核对：节点对应关系表 ＋ 差异说明 ＋ 走线坐标断言 ＋ 交叉校验报告 ＋ 版本快照，每个结论可溯源、可复核。

10B. 2.2.7 十轮迭代工程经验 · 布线判据链 / 双源校验 / 手动版比对 / 10 列升级 / 模板收敛（2026-10-16 深夜~10-17 系统归纳）

> 承接 §10A（单日五轮），本节归纳 2.2.7 合同签订流程 V6.0→V10.0 十轮迭代（含手动调图比对、授权额度分级审批、
> 双分段图、闭环补全＋全面泛化、第 8 章 10 列升级、按模板形态收敛）中新增且可复用的判据与 SOP。
> 项目脚本锚点：<工作区>/_out10/_scripts/（_audit_227_v7.py 参数化版 / _audit_cross_AB.py / _cmp_227_user_0813.py /
> _gen_split227*.py / _generalize_227.py / _upgrade_227_v10.py / _tplclean_227_v10.py / _dump_template_struct.py）。

B1 布线对齐判据链（补全 §10A 要点 6）

B2 md 解析三坑（解析器加固）

B3 校验链四件套与豁免规则（补全 §10A 要点 8）

豁免规则：用户手动布局下（EPROS 打开保存过），规则 1 折点对齐 FAIL 属预期豁免——以手动版为准，如实披露 FAIL 项数与原因，不得回改用户图。

B4 手动版比对 SOP（补全 §10A 要点 9 / v1.3.7①）

1. 先快照：cp 到 _user_snapshots/<名>_用户手动版_<日期>_<时分>.epros；
2. 内存重建基线：G.build_flow(md, no, name) + G.serialize（不落盘），parse 后与用户版做语义 diff 五级：节点（键 FigureType+FigureText+roleName）/ 连线（键 src+tgt+label）/ 协作框（按中心点包覆集合）/ 泳道 / 画布；坐标差 ≤8 视为容差；
3. 判读口径：节点/连线 0 增删＋标签不变＋协作框不变 ⇒ 逻辑零变更、纯布局优化——文件层只需改图占位说明，不改逻辑内容；布局变化按梯队归纳（如「评审区右移~85 / 审批区右移~180」）；段数变化（5→4 段等）＝EPROS 重排走线，拓扑不变，如实记录；
4. 报告落盘 _cmp_*_报告.md（五级变更表＋影响说明）。

B5 分段双图管线（总图 → 图A/图B）

• 链路：_gen_split227.py（抽总图第 1/2/3/4/6 章骨架＋硬编码替换第 7 章表 → _split227/ 子目录，避开 all_flows 顶层扫描防同编号覆盖总图）→ _gen_split227_epros.py（注入 G.ABBR["2.2.7-A"]="HTPS" 等后调 build_flow+serialize）；
• 编号沿用总图体系不按段重编（分段图跳号属正常形态）；跨图衔接用「子流程调用」节点（ImplFigure），EPROS 单文件内无法跨图连线；
• ⚠️ SRC 与第 7 章表硬编码——总图升版后须同步，否则重跑分段图会回退到旧逻辑。

B6 第 8 章 10 列升级与 Word 适配

• 列结构：9 列→10 列：在「输出」后新增「异常处理」列，「角色」更名「责任人」；
• 列宽：COLW["activity10"] = [700,1200,4900,1200,1100,1000,1500,860,700,740]（合计 14200 ≤ 横向节 14358 twips），按首表行列数==10 动态切换；
• 附章节解析：## 附：… 作为独立章解析（no="附N"）；--- 水平线跳过、> 引言转 note；附章节表格动态等分列宽（首列 500，纵向节 9426）；附章节小节不套「标题 2」（见 §4 硬约束）；
• 校验器适配：TBL_HEADERS_10（10 列基准头）＋G-09 骨架允许「附：」章（标题1≥12 且第 13+ 个以「附：」开头）＋jobs 按实际行数登记；
• 收敛（正式交付）：按模板形态删除附章节后，_gen_flow_doc.py 的附章节解析仍保留（审阅稿形态仍可用）。

B7 模板形态收敛 SOP（「参照模板删除多余的内容」）

1. 定标尺（dump 实物，勿凭记忆）：_dump_template_struct.py 只读 dump 基准 docx——章节骨架 / 注文数 / 各表行列与表头 / 修订记录行数；再用已验收先例（如同批另一份已对齐 PASS 的成品）校准出「模板形态 ± 先例容差」（如基准注文 0 条，先例 6 条＝同型注文可保留）；
2. 出删除清单（三类）：①模板无的整章（附章节）；②过程性注文（编制沿革、参考标准声明、列级口径说明——信息须有正文/其他注承接后才能删）；③修订表历史行（收敛为「V1.0 新建＋当前版全量摘要」）；
3. 待确认项转移：删除项中的〔待客户确认：…〕汇总到当前版修订行或相关正文，一个都不丢；
4. 保留项白名单：正文/术语中的待确认标记、业务口径注（如五大类指标定义）、先例同型注文；
5. 备份 → 收敛 → 重生成 → 终验（骨架计数回到基准形态）→ 交付说明列删除清单与回退路径。

B8 泛化口径与残留扫描（长期口径，见 §10A 与项目 MEMORY）

• 泛化词典脚本（保护 | Vx.x | 修订行）跑完后，必须再做数值型残留专项扫描：\d+ 分钟、\d+ 万元、\d+ 元、\d+ 日前 等——多轮泛化后仍有漏网（实测 150 行「60/240 分钟」残留至 V10.0 才清出）；
• 审批分级按「授权额度内／超授权额度」命名，阈值一律指向公司《合同审批授权表》；
• md「字符数」≠「字节数」（UTF-8 中文 3 字节），脚本自检打印与 ls 差 ~2.5 倍属正常。

10C. 批次格式统一工程经验 · 基线分族 / 角色法分类 / 段距行单位 / 明文审计通道（2026-10-19，10 份流程文档实测）

> 承接 §10A（单流程梳理）与 §10B（单文档十轮迭代），本节归纳一次批量统一 10 份流程文档（Letter→A4、三种基线族、
> 约 4750 段落 / 94 表格、文字零改动硬约束）的全链经验。项目锚点：<工作区>/流程10.18/_tools/
> （_apply_fmt.py 套用 / _audit.py 只读审计 / _text_diff.py 差异归因 / _profile.py 前后画像 / _report_html.py + _html2docx.py 出报告）。
> 实测结论：10 份 0 格式不符合项；正文与表格文字逐段一致；耗时 套用 6~7 min ＋ 审计 4~5 min（两轮）。

C1 基线先分族，规则再落地

同一批文档常来自不同模板代际，逐份定制既慢又不可复现。先按「页型 + 节数 + 样式体系 + 表格样式」四维聚类，
同族共用一套规则；族间差异只落在「是否需补样式／是否需改页型」这一层。

做法：先用 _profile.py 出四行画像（页型/节数/样式 Top5/表格边框与字号分布）再分组，不要打开文档逐份目测。

C2 角色法分类（样式名不可靠）

把每个非表格段落归入下列角色，规则按优先级自上而下命中即停。归一化：去 \r \x07 \x0c \t、去前导 N、/N.，并加「短文本」约束（章名 ≤14 字、节名 ≤22 字）防正文句子误命中。

目录区间定位（必须做，否则 12 个章标题会被误判成目录条目）：

1. 目录标题索引 = 首个「文本 ∈ 目录集」的非表格段；
2. 目录终点 = 该段之后首个含 \x0c（分页/分节符）的段落；找不到则退化为「目录标题 +18 段」；
3. 只有 目录标题索引 < i < 目录终点 的短文本才按章名/节名归入 TOC1/TOC2。

> 实测首轮未设边界时 h1 计数 24（12 真章标题 ＋ 12 目录条目），设边界后回到 12。

C3 段距「行」单位坑（本批最高频，4/10 份中招）

C4 表格排版分档（一表一判，勿全表同参）

• 边框六向全设：1 / -1 / -2 / -3 / -4 / -5，LineStyle=1、LineWidth=4（wdLineWidth 枚举 4＝0.5 磅）；单元格级 -5/-6 不支持，勿在 cell 上设内线。
• 加粗一律不动：表头与指标卡标签的加粗是语义层次，统一去粗会削弱可读性。
• 单元格段前后 0、首行/左右缩进 0、顶端对齐；表格整体左对齐；列宽不重分配（见 §4 硬约束）。
• 复核口径：COM 读回 1/4 即正确；Word 导出的 HTML 显示 1.0pt 属导出上取整，与基线表现一致就是正常，勿按 HTML 判缺陷。

C5 目录域重算的差异归因

见 Phase D 的「V-01 判据修正」表。要点：页码变化不算正文改动，整行消失必须回备份核实后显式披露。本批 8 份含目录域（7~14 行页码重算），其中 2 份各有 1 条指向「9、裁剪指南」的失效条目（该章在正文中不存在）随重算消失，正文段数变化 556→555，已在报告中单列说明。

C6 DLP 下的明文审计通道（本批关键突破）

主题色处理：Font.Color 为 0xD400BFFF 这类值（TextColor.ObjectThemeColor ≠ 0）时，不要把这个长整型照抄到目标文档——目标主题不同即变色。用 HTML 解析出真实 RGB（本例 #0F4761），按 R + G<<8 + B<<16 设为直接色最稳。

批量变更报告结构（5 段，本批成品可直接复用）：

1. 任务概述表（基准/对象/方式/校验/备份位置）；2. 参考规范表（逐项实测值，注明「非目测」）；
2. 文件清单（序号/文件名/所在文件夹/段落数/表格数/文字校验/审计结论）；
3. 逐份 before→after 表（只列发生变化项，未变化标「（未变更）」）＋ 主要变更项一行；
4. 校验结论 + 说明事项（编号属文字未改、目录页码重算、列宽未动、加粗保留）。

生成方式走 HTML → docx（SaveAs2(...,16)），比 COM 逐段建表稳（天然避开本文「Word COM 生成 · 结构性七坑」）。

C7 批量执行节奏与留痕

C8 基准登记（防止「基准串台」）

同一项目内并存多套基准，且「生成链基准」与「对齐链基准」是两个独立口径，不得互相覆盖：

执行铁律：基准以当批用户指定为准，并在交付说明写明「依据版本号」；发现两套基准数值冲突时回报确认，不得自行择优。

10D. 流程图复核与整改工程经验 · 23 条判据 / 文本级手术 / 重接四级规则 / 跨工件一致性（2026-10-19，12 份 .epros 实测）

> 本节对应复核链：对既有 .epros 做逻辑与规范复核，并把「可机械判定」的缺陷直接改回文件。
> 实测规模：12 份 / 319 图元 / 224 流程节点 / 194 条连线；初检 194 条问题；完成第一优先整改后 175 → 136 条（高 98 → 63）。
> 工程锚点：<工作区>/流程10.18/_review/（epros_model.py 解析 → _review_epros.py 22 条机检 → _fix_epros.py 整改 → _fix_geometry.py 折线修补 → _compare.py 图文比对 → _report_html.py / _build_xlsx2.py 出交付）。

D1 复核判据表（23 条 = 连线逻辑 15 + 走向与结构 5 + 命名 2 + 元素语义 1，逐条可机检）

> 等级口径（2026-11-05 起）：P0 = 交付阻断，不修完不得出交付物；P1 = 告警，须在报告中列明并给出处置意见；P2 = 提示，可留待人工润色。「阻断」列直接对应 §6 的交付门：P0 项 > 0 → 拒绝交付。

判定口径两条铁律：① RoleFigure / MapNameText / DottedRect / FreeText 是装饰图元，不参与连通性；② 吸附到协作框的线要计入源/目标的视觉度数，否则会与「死路径」重复计数。

D2 三个判据陷阱（都踩过，务必先看）

1. 「分支条件普遍缺失」是错的判断。初判 13 处无条件，实测 20 个判断节点里 18 个已标注，只有 2 个节点、4 条出线缺失。先统计再下结论；本批真正的缺口在汇合侧（16 处多入边无网关），不在分支侧。
2. 「同名图元」必须分两类：degree=0 的才是改版残留（删）；两端都连线的可能是真多实例（如「战略规划流程」在同一张图出现两次），只提示、不动。
3. 入口不能只看 FlowFigureStart：多数文件用 EventFigure 触发事件当入口。两者都无时才用「入度 0 且出度>0 的最左活动」推定，并必须标注为推定——否则可达度恒为 0，一片误报。

D3 整改手术规范（不重序列化）

D4 重接四级判据（纯几何就近会判错）

按序命中即停，每条都记录判定理由；四级都不满足 → 不改，列入「待人工确认」：

> 反例：2.4.1 若纯按距离，会把「参与客户信息深度调研」（近 2px）当成主活动；规则 2 纠正为「客户信息深度调研」。实测 20 条中 15 条可判、1 条判「两端都是协作框→删除」、4 条留给人工（客户满意度 3 + 商务谈判 1）。

D5 重接后必须重算折线

只改 EndFigure 不改坐标 → 线头停在旧协作框边缘，视觉上仍是断的，且 C-17/C-18 立刻报错。按三走向重建 3 段正交线：

D6 副作用、验收与「不要自动做」的项

• 重接会暴露被掩盖的缺陷：某菱形的第 2 条出边原本连在协作框上，不计入内部出度，故「判断无分支」从未报出；重接后 C-11 才出现。这类必须在报告里标「新暴露的既有缺陷」，不能算整改回归。
• 画布必须复核：WorkflowWidth/Height 可能小于内容 extent（实测 2/12：画布 1464×644 装 2728×910 的内容，右侧 1/3 图元在画布外）。改为 extent + 60。
• 整改后必须另起进程全量复审，并做前后逐文件对比（本次逐条留痕 fix_plan.json）；同一进程内自检会漏掉未生效项。
• 起止图元不要自动加：图元自 x≈180 起排、紧贴泳道名列，补「流程开始」需把整图右移约 160px，属版面重构；自动平移会破坏客户版面。→ 出作业单（每份：加什么、建议坐标、连到哪个活动），由人在 EPROS 内 2 分钟完成。

D7 文档侧取证要点（三条都会造成误判）

D8 交付形态（四件套）

1. 复核报告 docx：范围与方法 → 总体结论 → 分文件统计 → 问题分类与标准修正动作 → 逐份问题清单（位置/描述/建议）→ 整改优先级 → 说明与局限。
2. 问题清单 xlsx：双表「待整改 / 已整改」，含状态列；整改后重出，已整改项进第二表而不是消失。
3. 整改执行记录 docx：执行概述 → 已完成（含逐条改动与判定依据）→ 前后对比 → 未自动整改项及原因 → 起止图元作业单 → 回退与复验。
4. 备份目录：.epros 原件快照，报告写明回退方法。

> xlsx 多表：Worksheets.Add() 之后必须 ws.Move(wb.Worksheets(n)) 排序——Add(After=...) 关键字在 pywin32 下不生效，新表会插到最前（与 §10C C7 同一结论）。

D9 跨工件一致性：三级分类与「不得自动改」的红线

复核「图 ↔ 文档」是否一致时，先限定比对对象，否则假阳性会淹没真问题：

差异按三级分类，处置门槛逐级升高：

红线：不得自行决定「以图为准」还是「以文档为准」。判权威侧的依据是信息完备度——活动表带编号/角色/输入/输出/测量点（可执行），图只有名称与连线；但先看数量（见 D10），数量不等时改哪边都是错的。

D10 编号一致性：三处必须同时对齐

活动编号同时存在于三个地方，只改一处就会断链：

1. 文档第 8 章活动说明表的「活动编号」列；
2. 文档正文与 KPI 表中的引用，形如「活动总结与效果评估（110）」——这类括号引用极易漏；
3. .epros 图元的 ActivityId 属性（可能带前缀，如 HTQD-010、SCHDCH-020）。

> 实测反例（务必记住）：2.2.7 文档编号 010–150、170–210（缺 160）被初判为「跳号」，按 010–200 重排后，反而与图中 HTQD-010~210（21 个连续节点）整体错位 5 个号。真相是文档漏了 160「合同审批授权判定」那一行——正确动作是补行，不是重排。发现后已回退编号、恢复原状并改判为「文档漏登」。

D11 规范与基准冲突时，先裁定再动手

基线文件本身可能不合规。实测：作为格式基准的 2.1.1/2.1.2，表格为「审批栏 16 / 普通表 14 / 行距 13.9」，而编制规范写的是「所有表格内容＝小四 12 磅、行间距 16 磅」，无任何表型例外。

D12 Word/COM 批量整改的三个坑

> 另注：批量处理 10 份以上时每份独立 DispatchEx + Quit()，并在批间清理无窗口 WINWORD（MainWindowTitle -eq ''）；有窗口的实例可能是用户正在编辑的文档，不得强杀。

11. 变更记录

| v1.4.1 | 流程梳理全案经验归纳 + 协作框双通道判据 + 生成器自动协作框（2026-10-16 深夜，单日五轮迭代收口）。① 新增「§10A 流程梳理全案经验 · 应包含的要点 / 覆盖范围 / 预期效果」总纲章节：10 条要点对照表（参考标准解析 / 编号口径 / 多源融合 / 顺序重梳 / 角色映射 / 竖向分叉点对齐 / 多人员活动标注 / 校验闭环 / 版本快照 / 双版本输出）＋覆盖范围三段（输入侧 / 处理侧 / 输出侧）＋预期效果三款（六类不踩坑 / 一次做对 / 全链可核对）。②「多角色活动 · 协作框规范」补强：标题加「亦称协助框」；新增「双通道判据」（多人员活动必须择一表达——协作框优先 / 依据逻辑关系添加连线；禁止孤立悬挂）与「生成器默认行为」（跨泳道副本组自动外裹协作框：左右余 17px、上下余 23px、橙 235,97,27、先于节点与连线绘制；实测 2.2.7「签字确认」4 副本 → 134×706）。③ 布线纪律第 7 条（竖向分叉点对齐）补实证数据（2.2.7 全图 8 组共杆：1072 / 1312×4 / 1642 / 1832 / 2022 / 2212 / 2848×3 / 3162）。④ 版本号 v1.4.0→v1.4.1。 |
| v1.4.0 | 模板基准换版 V1.1 + Word COM 运行时陷阱集 + 列宽铁律 + 竖向分叉点对齐规范（2026-10-16，单日四轮实测驱动）。① 模板基准由 9.25 换为 产品市场信息调研分析流程-V1.1.docx / 竞争对手产品分析流程-V1.1.docx（两份实测格式 100% 同构）——新增「V1.1 版式口径」12 项速查表：章标题「N、＋Tab＋章名」15 磅加粗悬挂缩进 li=21/fi=−21／单倍18／段前15.6段后7.8（末章「支持文件」7.8/3.1）；子节「N.＋Tab＋名」14 磅／li=47.95；表题注「表 N＋Tab＋名」12 磅居中；目录双制表位（TOC1 左31.5／TOC2 左42.0＋右481.4点线）；全部表格边框外内统一 0.5 磅（含审批栏）、审批栏单元格 12 磅；封面信息行 li=104.85/fi=7.05、无独立「审批栏」标题段；节3＝7-8 章横向（第8章9列表放不下）、节3 页眉距 28.35。② 新增「Word COM 生成 · 运行时陷阱与收口」大节：结构性七坑（InsertXML 本机不可用／Paragraphs.Add 覆盖同段／分节符位置／InsertAfter 样式继承／单元格继承「标题1」／空标题段／占位符双下划线＋对象 Range 漂移）＋运行时格式五陷阱（空段行距／表后自动段继承表题注／TOC 域范围延伸波及后续段／分节符段字体／TOC2 字符单位缩进）＋三道收口（分节→格式化→TOC后复检→兜底回落）＋四脚本校验闭环。③ 新增「表格列宽铁律」：先按所在节可用页宽定上限（9638／9426／14358 twips）再按内容适配（勿照搬基准 gridCol——基准无 tblW 靠 AutoFit 隐式压缩，值本身常超页宽）；档案表参考分配 [2300,1200,2360,1900,1666]。④ 布线纪律新增第 7 条「竖向分叉点对齐」（2026-10-16 用户拍板 · 强制规范）：横向多条连线时，同源出线的多条分支共用同一竖杆 x、同目标入线的多条分支共用同一竖杆 x，各分叉/汇合点必须对齐同一位置，禁止参差；附分组实现法与坐标断言校验。⑤ 第 7 章交付形态更新：客户要求「图＋节点表」时按表 3 位次插入「流程节点连接关系表」（图题 14 磅居中 li=36/fi=17.85 → 图片 → 表题注 → 节点表 → 注释段）。⑥ 版本号 v1.3.7→v1.4.0。 |
| v1.3.7 | 手工修改比对与版本快照（2026-10-15，同一图三轮手工改版实测驱动）。① 生成链新增「手工修改比对与版本快照」小节（7 条）：先 cp 快照再比对（客户端保存原地覆盖上一版，无快照只能反推基线）；禁止文本 diff（保存重写 UUID/属性序），改按 (FigureType,FigureText,roleName) 匹配图元、(StartFigure→EndFigure, LineText) 三元组匹配连线做语义 diff，基线取生成器内存重建（不落盘）。② 双副本挂载副本轮换 ≠ 缺陷：用户可把连线由主责副本切到审批/后置方泳道副本（实测 2.2.5 的 060 由营销部长→事业部经理，四条线重走、孤立副本同步轮换），判据为节点集/连线集/标签不变；与协作框「只接主责副本」冲突时回报确认主责口径，勿自行改回。③ 分组框避让与穿越豁免：出线竖段须移出框缘（1455→1507），进出框内节点的必需穿越段应豁免，入线优先共用竖干线汇合（3 段优于 5 段 Z 形）。④ 批次固有告警判读：孤立副本 / ActivityId 重复 / 节点表行数差 1 三类只核数量与标签、不拦交付，有 FAIL 才拦。⑤ 类型词同步：规格新增类型词（起始/结束）须同步补校验器词汇表，否则生成侧接受、校验侧报假 WARN。⑥ 编号口径先核对：同名 .epros 可能同号不同名（2.2.4 报价流程 vs 2.2.4 关键角色攻关流程），取号以架构卡为准并同步生成器 ABBR 映射。⑦ 新增「比对后自检 4 项」；§4 硬约束新增「★ 人工改版先留快照」。⑧ 同步 frontmatter version 至 1.3.7（原 1.3.2 与 §11 漂移）。 |
| v1.3.6 | 模板基准严格对齐（2026-10-14 用户指定 9.25 目录为唯一基准）。① 新增「模板基准（9.25）」小节：实测锁定 docx 实例 + HT-MK xlsx 模板的章节骨架（12 章+2 子节，序号+顿号编号）与表格口径（10 表列头逐字，表5 活动说明=9 列 活动编号\|活动名称\|活动内容\|角色\|输入\|输出\|相关文件\|相关规则/标准\|相关IT系统，表6~8 每指标独立一表）；编制要求（PPT 15 字段）映射入章节不另起结构。② 连接关系表定位修正：模板无此独立表 → 仅内部图文对照/校验用，不入正式文档正文（留存放「附则」附件/交付留痕）。③ 生成链内容纪律更新：活动编号取 ActivityId、双责任活动合并行（角色列「主责；参与」）、KCP/风险控制措施写入「活动内容」列。④ G 系列新增 G-09 章节骨架一致 / G-10 表格列头一致；Phase C-G 门禁加「章节骨架/表格列头与基准不一致→停止并复核」。⑤ 修复审计缺口：原缺 7 章节（定义/目的/适用范围/裁剪指南/支持文件/拟制修订记录/附则）、活动表列头未固化、5 编制字段未覆盖——现全部纳入基准映射。 |
| v1.3.5 | 序号呈现规范（2026-10-14 用户定稿）。① Phase A 新增「序号呈现规范」小节：EPROS 客户端活动框双层结构（顶栏渲染 ActivityId、正文渲染 FigureText），流程序号（源文档活动表三位编号 010/020/…）必须放顶栏（ActivityId:=序号、FigureText:=纯名称）；勿把序号写进 FigureText 前缀（避免双序号冲突）；协作框双副本顶栏同号；序号取源 V1.1 活动表「编号」列，先核对再改，不得自造编号体系；渲染器顶栏读 ActivityId。② 实战回归：两图 35 个活动框序号由 FigureText 前缀迁入 ActivityId 顶栏，坐标/连线零漂移。 |
| v1.3.4 | 连接点规范 + EPROS 打开兼容性根因库 + 连线修改经验（2026-10-13~14 实测排障与手动修改比对驱动）。① Phase A 新增「EPROS 客户端打开兼容性」根因表（6 项：整数属性小数化 NumberFormatException @ Integer.parseInt / ActivityId 空重复 / <figures> 后置 / FigureType=VerticalLines 误值 / OrderIndex 重复 / DottedRect 样式缺省）+ 排障方法（读 epros_log.txt 堆栈 + 最小探针二分）。② 布线纪律后新增「连接点（锚点）规范」：矩形=四边中点、菱形=四顶点（落斜边即红 ✕）、同方向单锚点（多边共用）、菱形出边顶点分工硬规则（通过=右顶点/不通过=底顶点/不得共用）、精确吸附偏差 <0.01。③ 新增「EPROS 客户端行为特性」（OrderIndex 保存自动重编号→用三元组追踪 / 画布声明不自动扩展→手动核宽高 / 拖动自动吸附）。④ 新增「连线修改经验」（节点平移折点同步 Δ / 退回线贴紧 30~50 间距 / 拐头按走廊重算非平移 / 大幅重排必查画布与泳道带高度为正）与「修改后自检清单 6 步」。⑤ 实战回归：B 图画布声明 1969×671→2552×800 修复 7 处越界 + 底部泳道带 -89 负高度；4 个菱形顶点分工核查全合规。 |
| v1.3.3 | 多角色活动协作框规范 + 布线纪律（2026-10-13，依据《恒泰-EPROS操作标准化-V1.0》协作框页实测）。① 生成链内容纪律新增「多角色活动 · 协作框规范」小节：活动标注多责任人（分号分隔）时不再单框单泳道近似，改为每责任角色泳道各一个同文本副本 + 橙色虚线 DottedRect 协作框（BodyColor 橙 235,97,27）外裹；副本并行、同进同出；分主次（首位=主责）连线只接主责副本，不分主次接框边。② 新增布线纪律六条（重排/改造类任务）：左进右出（复杂可左、上进）、同排直连、改前断言原值+改后拓扑守恒、干线走廊 ≥10 单位、绕行走带外走廊禁穿框内、横向交叉数=0 目标（严格内点相交计 1，共线共享干道/端点汇入不计；源图固有交叉留痕，重排时一并消除）。③ 渲染细节「分组盒」条目升级为「分组盒 / 协作框」：协作框橙色虚线，普通红色分组盒照源色。④ 实战回归：两份流程图（A 14 活动/B 15 活动）按规范改造——A 增 1 组协作框（130 营销部长+产品经理）、B 增 4 组（030/070/110/140），连线重排后两图横向交叉均归零（含消除源图既有 1 处 e35×e47 交叉：120→110 退回边改走「客户」空带顶部走廊），11 项几何校验全 PASS。 |
| v1.3.2 | P3 工程化（选型报告阶段路径收尾）。① 新增 benchmark/run_bench.py + 基线 benchmark/baseline_20261013.json：三类基线（B-1 epros 解析耗时 / B-2 边框解析双引擎耗时+等价断言 / B-3 渲染耗时+几何保真），全部合成样本不依赖 COM；实测发现大样本下 regex 比 lxml 快约 40× 且结果等价——默认仍取 lxml 的结构稳健性，性能差异留档基线；--json 可与基线比对（>3× 判漂移）。② references/engineering-conventions.md 新增 §十一 发布流程约定：一处编写三处派生（SKILL.md §11 ↔ pyproject version ↔ 交付说明）、版本号语义、发布前四道门槛（pytest/selfcheck/bench 基线/依赖三维评估）、基线更新是显式动作、观察名单季度复查。③ selfcheck.py 新增第 6 段「文档门槛」（D-Doc）：10 个核心脚本模块 docstring 自含性 AST 检查（16→17 项）。④ CI 化结论：selfcheck 退出码分层 + stdout/stderr 分离，可直接被计划任务/CI 消费（每日 --json 跑批+告警），约定落 §十一。 |
| v1.3.1 | P2 通道冗余。① dlp_channel.py COM 级扩展为双后端降级链：pywin32 首选 → comtypes（纯 Python，Enthought 维护）备用，open_word_doc(backend="auto") 逐后端尝试，失败/切换事件写入模块级 COM_SWITCH_LOG + stderr（供执行审计）；com_available 同步按后端链探测并注明可用后端名。整体通道链现为 mcp → com(pywin32 → comtypes) → python_structured → plain。② 新增 4 个桩测试（auto 首选/降级留痕/双失败抛最后错/显式后端不降级），不触碰真实 COM。③ comtypes 真实 COM 冒烟 PASS：显式 comtypes 后端建档（17.7KB）→ 只读回开 → 内容/表格读取全通；auto 链正确首选 pywin32。④ 依赖登记：comtypes>=1.4,<2 入 office/test 档（评分 7.75：周下载 430,195 / Enthought 商业维护近 12 月 4 版 / pywinauto 生态引用）。⑤ 观察名单（季度复查，下次 2026-12-13）：python-redlines、pywinauto、Docxodus。 |
| v1.3.0 | P1 解析升级。① docx_probe.parse_borders_xml 升级为双引擎：lxml 首选（recover=True 容错片段级 XML + resolve_entities=False XXE 加固 + local-name 匹配命名空间无关），正则降级（auto 异常回落 / 可显式 engine="regex" 对照）；属性次序错配类缺陷从结构上免疫。② 等价性实测：5 组合成样本（含事故形态「sz 写在 val 前」）双引擎全等 + 真实 Word XML A/B 冒烟 PASS（COM 现场建档含表级+单元格级覆写，tblBorders/tcBorders/72KB 全文档三组全等）。③ probe 画像 JSON 契约版本化：schema: 2 + parse_engine 字段。④ 新增 8 个回归测试（等价 5 例 + auto 回落 + recover 容错契约 + schema 断言），全量 120 用例 0 失败。⑤ 依赖登记：lxml>=6,<7 入 office/test 档（评分 9.7，BSD-3，周下载 9,100 万）。⑥ Phase E 门禁强化：交付说明缺 fingerprint.json 留痕 → 不交付。 |
| v1.2.6 | P0 护栏与分层（零新依赖）。① pyproject.toml extras 重构为三档：minimal（仅解析校验，无需 Windows/COM）/ office（完整作业运行时）/ test（全量回归），主依赖收敛为 pywin32 + defusedxml——安装面最小化（对标 docling 分层）。② 维护模式依赖加护栏：defusedxml==0.7.1、openpyxl==3.1.5 锁定并注明理由（API 冻结不可替代 / 仓库在 Heptapod 发布慢）；matplotlib/pyyaml/pillow 从主依赖移入 office/test 档（缺失时优雅降级语义不变）。③ python-docx 正式定位为参考实现（不入运行时依赖；若未来引入须 >=1.2,<2 上限锁定 + 薄适配层）。④ SKILL.md §7 依赖表按分层重构 + 锁定理由入表。 |
| v1.2.5 | 遗留项落地（N-01~N-05，2026-10-13，承接 v1.2.4 优化方案 §七）。① N-01 verify_docx.py 复用 docx_probe.classify_table_role 统一表格角色口径：collect() 逐表记 role，活动表定位改走 activity_candidates()（先角色（列数）后关键字），消除与 docx_probe 的双份口径、封堵 P18 复发面。② N-02 selfcheck.py 依赖前置断言升级：pytest/matplotlib 缺失时除报告 D-X 外，退出码升为 3（EXIT_ENV_MISSING），不再静默成功（--skip-tests 显式豁免）。③ N-03 新增 references/delivery-note-template.md（交付说明≤5 节模板：概要/变更表/校验结果/待确认项/留痕路径，「依据版本号」「待确认项」为门禁字段，解 P24 膨胀）。④ N-04 结构指纹进入交付留痕：docx_probe 新增 write_fingerprint / load_fingerprint / compare_fingerprint_files 与 CLI --fingerprint OUT、--fp-compare A B（不开 Word 跨轮比对，结构漂移退出码 1；段落数漂移属合法，节数/表数/表形状/页面设置漂移必拦）。⑤ N-05 多形态报告评估落地：verify_common.Report.write_html() + 各校验器统一 --html 参数（自包含单文件、零第三方依赖、无脚本、detail 已转义）；评估结论——写侧为 Python 直写（与 --json 同通道，已验证可行），「打开」侧依赖浏览器在 DLP 白名单内，未实测前 HTML 定位为留痕/拷贝查阅；DOCX 形态不采用（需 Word 写通道，DLP 成本高收益低）。⑥ 回归测试 +11 例（活动表统一口径 4、指纹留痕 4、HTML 报告 3）。 |
| v1.2.4 | 原语化重构 + 执行时守卫（2026-10-12 单日实测驱动，当日两起事故的工程化收敛）。① 新增 scripts/docx_probe.py（只读探测原语 + CLI）：段落三分类 / 空行连续段 / 分节符载体判定 / 边框 OOXML 权威读取 / 单元格有效值 / TOC 条目与制表位 / 结构指纹 / 表格角色判定。一条命令 python scripts/docx_probe.py <file.docx> [--json out.json] 产出一图流结构画像，取代当日 12 个一次性探测脚本。② 新增 scripts/docx_guard.py（写侧守卫）：Guard 结构不变量上下文管理器（节数/表数/表形状/页面设置在编辑前后必须不变，违规抛异常禁止保存）、safe_delete_paragraphs（内置分节符保护）、allowed_blank_plan（按「空行段+其后接标题」的允许保留数出方案）、refresh_toc_then_restore（先刷域→再重建制表位，顺序固定）、set_toc_entry_tabs（按层级取值）、save_dlp（SaveAs2+重试）、cleanup_orphan_word / remove_lock_files。③ 新增 23 个单元测试（tests/test_docx_probe_guard.py），含三起事故的回归用例：分节符载体判定、边框属性次序不得错配、宽表不得被关键字误判。④ 依赖落地：本机所有 Python 环境原先既无 pytest 也无 matplotlib（致 101 用例长期不可验证）→ 已装齐并实测 101 用例 0 失败；pyproject.toml 补 test extra 与实测安装命令。⑤ SKILL.md §4 新增「结构不变量守卫」「删段落必排分节符」两条硬约束与「§4.1 执行时守卫」（四道闸门表）。⑥ references/docx-com-recipes.md 新增 §九 事故档案（症状→根因→处置→守卫，共 21 条，含 A 级事故 3 条 / B 级障碍 9 条 / C 级静默判定 5 条 / D 级返工 3 条）与五条铁律。 |
| v1.2.3 | 分节符保护 + 目录层级制表位 + 目录独占一页（2026-10-12 傍晚，用户反馈「目录需要单独一页／每个小节内部的空行需要删除」驱动）。① ⚠️⚠️ 分节符藏在段落标记里，批量删段落前必须排除——空段落可能承载分节符（纵向→横向 分界），删除后节数减少、横向节被合并（本次真实事故：节数 4→3 已回退重做）。判据：p(i).Range.Information(2) != p(i+1).Range.Information(2) ⟺ p(i) 承载分节符；⚠️ 反例：Range.WordOpenXML 检索 <w:sectPr 无区分度（实测 369/379 段全命中）。加固：删除后断言 Sections.Count 不变，异常则中止不保存。② TOC 条目左制表位随层级不同：TOC 1 = 31.50、TOC 2 = 42.00、TOC 3 = 63.00（右侧统一 481.40 right/dots）——统一设同一值会导致带缩进的层级文字被跨过 → 跳右制表位 → 换行 + 两端对齐撑散（本次用户可见缺陷）。③ 目录独占一页＝给「目录」标题加段落级 PageBreakBefore（勿插入分页符段落）。④ 删段落流程的通用加固：先按「空行连续段 + 其后接标题」设定允许保留数 → 排除分节符载体 → 从后往前删 → Sections.Count 守卫 → 刷新域 → 重建制表位。 |
| v1.2.2 | 表格边框与目录制表位的复查修复（2026-10-12 下午，用户反馈「目录页和表格边框存在问题」驱动）。① 边框判定必须用 WordOpenXML，禁用 COM Borders 哨兵——单元格级 tcBorders 覆盖表级时 COM tb.Borders 可能返回 9999999（未定义哨兵），据此判形会误得「无内线」，v1.2.1 前的对齐即因此把 T#04/T#08/T#09 改错并抹掉全部单元格级 tcBorders。② 单元格级 Borders 只支持四边（-1..-4），-5/-6 抛「集合所要求的成员不存在」。③ 共享竖线取有效值：cell(i,j).right 与 cell(i,j+1).left 是同一条物理线，Word 只留一个有效值；复刻应以 COM 有效值为目标而非原始 XML。④ TablesOfContents.Update() 会重生成条目制表位（按样式缩进漂移）→ 应在 Update() 之后重建条目制表位为模板口径（pos=31.50 left/none ＋ pos=481.40 right/dots）。⑤ 复刻目标首选「同批备份原件」而非模板：模板行列数与批内文档常不同，用备份可保证逐格等价；功能等价性以逐表逐格 COM 有效边框比对为准。 |
| v1.2.1 | DLP 保存策略修正（2026-10-12 实测推翻旧结论）。① SaveCopyAs 在本机 DLP 环境全局失效（写目标目录/兄弟路径/%TEMP% 一律报 OLE 0x800a1704）→ 保存策略改为 SaveAs2 临时名 → Close → os.replace 原子换名（落盘仍为加密态 00005b00…）。② Table.Borders 必须用整数索引 (-1..-6)，链式 b.Top.LineStyle 抛 AttributeError。③ Border.LineWidth 取 wdLineWidth 枚举（2/4/6/8/12 = 0.25/0.5/0.75/1.0/1.5 磅），非磅值。④ 表格语义角色判定须先判列数（≥8→活动说明表）再判关键字，否则表头含「角色/职责」的宽表会被误判。均已在 references/docx-com-recipes.md §三/§五 落文。 |
| v1.2.0 | 技能体系工程化（对照官方 Skill 规范 + GitHub 热门工程实践）。① 新增 verify_common.py 统一校验框架——消除两套互不兼容的结果 schema（{item,ok} vs {item,status}）与重复的 _chk；引入稳定校验编号、退出码分层（0/1/2/3/4）、stdout-stderr 分离（结果走 stdout、诊断走 stderr）。② 新增 tests/ 78 个 pytest 用例（合成夹具、不依赖用户数据），覆盖解析不变量、几何工具、结果模型、CLI 契约、DLP 探测、渲染闭环。③ 新增 pyproject.toml 作为依赖唯一事实源 + pytest/ruff/coverage 配置。④ 新增 scripts/selfcheck.py 一键自检（依赖→配置→解析→渲染→测试，16 项），落实官方强调的「跑校验器→修复→重复」环。⑤ frontmatter 补 dependencies/version/license。⑥ 新增 references/engineering-conventions.md（改脚本前必读）。⑦ 细节修复：bootstrap() 取代散落的 sys.path.insert；JSON 基准缺失时给出可操作提示而非堆栈；无 ParallelLines 时显式声明「泳道未正式划分」。 |
| v1.1 | 流程图画图能力增强（重点：连线走线与位置排布准确性）。① 改用 manhattanLines/lineSegments 的源正交折线逐段照搬（此前用直线近似）；② 修复 LineText 字段读错导致 167 条判据标签静默丢弃；③ 修复非业务图元被当装饰丢弃（漏画 9 个图元 + 丢 2 条带标签的边），改为「非业务节点≠不绘制」且边不按端点类型过滤；④ 采用源文件自带配色（BGColor 渐变/BodyColor）；⑤ 补齐角色标签列、图名标题、责任标记、自由注释；⑥ 字号改为按真实坐标缩放精确约束，消除文字溢出；⑦ 输出改用可解析映射（弃 bbox_inches='tight'）并写 meta.json 侧车；⑧ 新增 verify_flowchart.py 几何保真度校验（14 项）。<br>依赖取舍：明确不引入任何布局/布线库（Graphviz/ELK/pyorthogonalrouting 等）——源已给精确几何，重排反而降精度；完整评估表见 §7.1 |
| v1.0 | 由 epros-flowchart-to-docx + doc-format-align 合并而成。统一为「两条链 + 共享底座」架构；新增 dlp_channel.py 通道层（含误判修复与写后回验闭环）、check_config.py（修正原脚本硬编码路径）；verify_docx.py 统一 G/V 双系列；详细知识下沉至 references/ 三份文档 |