公文流转核对 PerryLink/dsh-gongwen-flow-check

dsh-gongwen-flow-check — 公文流转与办理期限登记核查

dsh-gongwen-flow-check 读取一份收文登记簿及其办理步骤台账——公文头部信息，加上每个办理步骤一行——核查登记簿自身的完整性与内部一致性：每个步骤是否都在 handler 中写明办理人，receivedAt 与 doneAt 能否解析为日期且先后顺序正确，办结时间是否落在登记簿自己在 dueAt 中记录的期限之内，每个 status 是否取自你配置的词表，docNo 是否只登记一次，以及头部是否写明公文标题与收文日期。它不判断办理是否逾期，不判断是否该催办，也不认定谁该负责。

它能回答什么

| 你问 | 它回答什么 |
| 某个办理步骤没填办理人。登记簿会被告知什么？ | GF-001 要求每个步骤都填 handler 列，并报出该列为空的那个步骤。它只检查这一列是否填了，不检查办理是否及时——不判断该步骤是否该催办，也不认定谁该负责。 |
| 办结日期早于收文日期。这能查出来吗？ | 能。GF-002 把 receivedAt 与 doneAt 一起解析，两个日期先后顺序不对时报出该步骤。它只比较台账里写下的这两个日期——同一天算作不晚于——不判断办理是否落在期限之内。无法解析的日期会单独报出，不会悄悄跳过。 |
| 某一行始终没写办理期限。核查会自己假定一个吗？ | 不会。只有登记簿自己在 dueAt 中写下期限时，GF-003 才运行；dueAt 为空时，这条规则会在 skipped 中报告自己。规定没有固定天数，插件也不硬编码任何天数，因此绝不会推断出期限。命中意味着「这与你记录的期限不符」，而不是「这已经逾期」。 |
| 办理状态填的值不在配置的列表里。 | status 值不在你在 values 中配置的值里时，GF-004 报出该行。默认发布时该列表为空，也就是未配置，因此这条规则会在 skipped 中报告自己，而不是悄悄通过。它只检查该值是否在你的列表上，不检查公文实际处于哪个阶段。 |
| 同一个公文编号在登记簿里出现两次。 | GF-005 要求 docNo 在登记簿中唯一；比较时忽略空白字符。命中通常意味着重复登记或编号抄错，需要人工确认：docNo 重复会让读者分不清是同一份公文登记了两次，还是两份不同的公文用了同一个编号。 |
| 登记簿本身从不声明公文标题和收文日期。 | GF-006 要求表头在顶层同时声明 title 和 receivedAt，两者缺一就报告表头。它只检查这两项是否声明，不检查标题格式是否正确，也不检查办理记录是否真的属于那份公文。 |

遵循的标准

| 文件 | 文号 | 引用规则 |
| 《党政机关公文处理工作条例》 | 中办发〔2012〕14号（自 2012 年 7 月 1 日起施行） | GF-001, GF-002, GF-003, GF-004, GF-005, GF-006 |

边界： 本插件检查的是收文登记与办理环节台账中登记簿能被机械核查的部分——每一步是否写明承办人，收文日期和办结日期能否解析且先后顺序正确，办结是否落在登记簿自己声明的时限内，状态是否取自你的词表，公文编号是否唯一，表头是否标明公文。它不判断办理是否逾期、是否该催办、该由谁负责。条例要求紧急公文写明办理时限，并要求在规定时限内办结——条例本身不规定天数，所以时限永远来自来文或你自己的规则，本插件绝不凭空编造。

⚠️ 本插件报告里的引用究竟依据什么

条例全文已获取并核对。 《党政机关公文处理工作条例》(中办发〔2012〕14号) 逐字读自中央政府门户网站，rules/evidence/clause-verification.md 记录了究竟引用了哪些条款——第五条（原则）、第二十四条（七项收文办理程序，含「紧急公文应当明确办理时限」）和第四十二条（自 2012-07-01 起施行，取代此前两份文件）。这次核对修正了本规则包自己的措辞：此前说国家规则只有一条笼统原则，而第二十四条实际上要求紧急公文写明时限。

规则里的 excerpt 字段仍写着「本次未取得」，每条规则也仍是 warn 或 info——这是有意为之。本插件检查的是登记簿是否完整、是否自洽；条例管的是公文如何办理，这是两回事。把「这一列是空的」标成「办理应当详细记录」的 direct 引用，等于把登记簿的缺漏包装成违反条例，而这正是本系列要避免的过度断言。检查也把时限的长短留给来文和单位决定，正如第二十四条那样。

《党政机关公文格式》(GB/T 9704-2012) 未获取，何况本插件根本不检查版式。

时限规则值得单独说明。GF-003 把办结日期与登记簿自己写明的时限（dueAt）比较；没有记录时限时，它会在 skipped 中报告自己而不是假定一个天数。它的结论写的是「这与你记录的期限不符」，不是「这已逾期」——是否逾期取决于提醒、延期和文件自身的紧急程度。

兼容性

| 层面 | 状态 |
| Harness | 对等版本范围 >=0.1.2-rc.1 <0.2.0 \|\| >=0.2.0-0 <0.3.0 —— 已验证可接受 0.2.0-rc.2 和 0.2.1-alpha.1。刻意不声明 engines.dsh：它没有读取方，也无法拒绝宿主 |
| Node | ^22.19.0 || >=24.0.0 |
| 平台 | 全部（纯 ESM；无原生代码、无网络、无模型调用） |
| 工具模式 | 在 native、ptc 和 both 下都能用；年度登记簿请用 ptc |

它做什么

注册 gongwen_flow_check 工具。它读取一份办理登记簿——文件抬头，加上每个办理环节一行——套用带版本的规则包，返回一份报告。

| 规则 | 检查内容 | 严重级别 | 依据类型 |
| GF-001 | 每个环节都写明承办人 | warn | principle |
| GF-002 | 收文日期和办结日期能解析，且先后顺序正确 | warn | principle |
| GF-003 | 办结落在记录的期限之内 | info | local |
| GF-004 | 状态取自你的词表（默认关闭） | info | local |
| GF-005 | 文件编号在登记簿内唯一 | warn | principle |
| GF-006 | 登记簿声明了文件标题和收文日期 | warn | principle |

安装

dsh plugin --profile <name> add dsh-gongwen-flow-check
dsh --profile <name> --dump-config | grep 'dsh-gongwen-flow-check'

配置

| 键 | 类型 | 默认值 | 说明 |
| rulesFile | string | rules/gongwen-flow-check.yaml | 规则包路径，相对于包根目录 |
| disabledRules | string[] | [] | 停止运行的规则 id；每个都会出现在 skipped 里 |
| onlyRules | string[] | [] | 只运行这些规则 id；留空则运行全部规则 |
| skipNotes | string | "" | 附加到每条 skipped 原因后面的备注 |
| timeoutMs | number | 120000 | 协作式工具超时预算 |

几个值得了解的规则级参数：

- GF-003 需要登记簿的 办理期限 / dueAt 列；没有这一列规则就不运行，并会说明原因。
插件从不按天数推算期限。
- GF-004 的 values —— 你的环节词表，例如 [待办, 承办中, 已办结, 已归档]。留空表示不检查。
- GF-001 的 field —— 承办人所在列，默认是 handler。

材料格式

工具接受 JSON 或 YAML：

docNo: 某发〔2026〕15号 title: 关于某某工作的通知 docKind: 通知 issuer: 某某机关 receivedAt: 2026-03-02 rows:
- { 序号: '1', 办理环节: 承办, 承办人: 张科, 收文日期: 2026-03-02,
办理期限: 2026-03-12, 办结日期: 2026-03-10, 办理状态: 已办结 }

列名匹配不区分大小写，并忽略空格、下划线和连字符；登记簿自己的列名会保留，这样结论里能写出它读的是哪一列。日期可以写成 2026-03-02 或 2026-03-02 09:30。

规则来源

规则数据放在 rules/gongwen-flow-check.yaml。规则包的头部完整说明了引用缺口，每条规则的 note 又重复了与该规则相关的那部分。加载时的守卫通常强制要求「摘录必须是至少八个字符的真实引用」，但它分不清引用和描述——所以这个规则包靠头部、每条规则的 note，以及一个测试来兜底，该测试断言每个 excerpt 都承认这个缺口。

故障排查

- GF-003 报告自己被跳过。 登记簿没有记录截止期限。这是有意为之：插件不会凭空编一个，因为截止期限来自收到的文件或你自己的办理规则。
- GF-003 触发了，但我认为办理是及时的。 登记簿里的 办理期限 与完成日期不一致。要么截止期限那一列过期了，要么完成日期写错了——检查结果会说明它比较的是哪两个单元格。
- GF-004 从不运行。 它的词表是空的；用你所在机构的环节名称填进去。
- GF-002 在我能看懂的日期上触发了。 读取器接受 2026-03-02 和 2026-03-02 09:30；2026年3月2日 会被报为无法解析，这是故意的。
- 插件装上了，但工具始终不出现。 检查 main 是否指向 lib/index.mjs，以及 pnpm run build 是否生成了它；main 写错会让加载器静默跳过入口。
- dsh plugin add 以不兼容为由拒绝这个包。 peer 范围覆盖 0.1.x 和 0.2.x；如果你的运行时不在这个范围内，显式授予豁免： dsh plugin --profile <name> allow-version dsh-gongwen-flow-check@0.1.0 --dsh-version <runtime> --accept-risk
- check 报告 manifest-peers 失败。 静态检查器比对的是一个硬编码的 peer 范围，它早于 0.2 系列。运行时会在安装时强制校验 peer 兼容性，所以声明的范围才是正确的；这是 dsh-plugin-dev 里已知的上游问题。

开发

pnpm install
pnpm run typecheck # tsc --noEmit
pnpm test # vitest, the shared table-plugin suite plus paired fixtures
pnpm run build # tsdown -> lib/index.mjs + lib/index.d.mts
node ../scripts/sync-shared.mjs dsh-gongwen-flow-check # refresh src/shared from ../_shared

这个插件是纯数据的：src/model.ts 声明表结构，共享工具包提供读取器和检查引擎，规则包声明每一项检查。

许可证

Apache License 2.0 © 2026 dsh-gongwen-flow-check contributors。