🎁 福利专区全网大模型免费应用 + 新用户福利 + 注册活动入口,低成本玩转 AI

文档链登记表核对 PerryLink/dsh-pipeline-check

DeepSeek Harness
PerryLink27 天前有提交已提供中文文档扫描:未发现敏感能力

检查项目文档登记表的完整性与日期金额一致性

30/100
综合分
0
GitHub 星标
—
npm 周下载
—/5
用户评分

数据截至 2026/10/8 · 周下载取自 npm 全网(含 CI / 镜像),非本站安装数;综合分由星标、活跃度与兼容性检查合成。

安装命令 · 需先装 dsh CLI 引擎
dsh plugin --profile web add PerryLink/dsh-pipeline-check
该包不可直接 npm 安装,改从 GitHub 源安装(明细见下方安装检查)

状态速览

判定依据:实装验证 · 静态安装检查 · 自动扫描 · 仓库维护状态
信任档位:需留意
是什么
dsh 原生插件 · tool
装得上吗
实装验证未通过(unknown),装前请到仓库确认最近更新与 issue
L4 · 真实安装等级说明 →
安全吗
本站尚未对该插件做风险分级
暂未覆盖,不等同于无风险
还在维护吗
活跃:最近一次提交在 27 天前
档位由哪些信号合成

本站实装验证(真实安装 L4 覆盖全站;L5 为运行时冒烟或实机截图,覆盖范围小于 L4) · 验证所用 dsh 版本 · 静态安装检查 · 风险分级 · 仓库维护状态。 下方各区块是它的证据明细。

验证判据与等级说明 →
⚠︎ 实装验证未通过(unknown · 2026/11/4) ——可能是验证环境差异,装前建议到 GitHub 仓库确认最近更新与 issue。
社区实装还没有人打卡 · 装过的第一个就是你
安全扫描自动 · 静态分析源码
v2.7.0
🟢 扫描:未发现敏感能力尚无人工评估
展开查看扫描说明与证据 ↓

静态扫描未发现敏感能力:最多只发网络请求、读取自身元数据或只读文件,未发现执行命令、文件写入或敏感信息读取。

扫描于 2026/11/3(1 天前) · 范围 入口闭包 + 发布文件清单 · 来源 GitHub 仓库

静态扫描只反映源码中出现的调用,不构成安全背书;人工评估与自动扫描相互独立、互不覆盖。

依赖的 DSH / Cordis 模块
@deepseek-ai/cordis@deepseek-ai/dsh-package-manifest@deepseek-ai/dsh-tools@deepseek-ai/schemastery
给这个插件打分还没有人投票↓
用户评分
还没有人投票,来当第一个

功能亮点

  • 核对登记表完整性
  • 检查日期金额一致性
  • 仅提示差异

管道检验记录核对:按本机构口径,无公开标准可引。仅提示差异,不作出定性结论。

README

由 DeepSeek 最新模型翻译生成
dsh-pipeline-check — 项目全过程文档链登记表检查 dsh-pipeline-check 读取一份项目全过程文档链登记表——项目表头加上每个阶段文档一行——检查登记表自身的完整性与内部一致性:项目是否已标识、每行是否写明阶段或文档、各阶段是否按你声明的顺序排列、审批与签署日期能否解析且先后有序、文档编号是否唯一、金额能否按数字解析、文档名称里是否还残留模板占位符。 它能回答什么 | 你的疑问 | 它的回答 | | 全新安装后,阶段顺序规则报 skipped,是哪里坏了吗? | 不是。PC-003 拿登记表里的阶段和规则包中的 order 列表比对,而该列表出厂时是空的,表示未配置,所以规则把自己报成 skipped,而不是悄悄通过。把 order 填上你所在机构的顺序(规则包里的示例是 立项、可行性研究、初步设计、概算、招标、合同、开工、变更、结算、决算),它此后只检查登记表里出现的阶段是否遵循该顺序,允许中间有缺口;它从不判断跳过某个阶段是否合规,其依据里也记录了不存在可引用的条款,因此上限为 info。 | | 登记表里的签署日期早于审批日期——这能查出来吗? | 能。PC-004 比对 signedAt 与 approvedAt:两者都必须能解析成日期,且签署日期不得早于审批日期,同一天算不晚于。无法解析的日期会单独报出,而不是默不作声地放过。
展开完整文档(README 剩余 1 节)
dsh-pipeline-check — 项目全过程文档链登记表检查

dsh-pipeline-check 读取一份项目全过程文档链登记表——项目表头加上每个阶段文档一行——检查登记表自身的完整性与内部一致性:项目是否已标识、每行是否写明阶段或文档、各阶段是否按你声明的顺序排列、审批与签署日期能否解析且先后有序、文档编号是否唯一、金额能否按数字解析、文档名称里是否还残留模板占位符。

它能回答什么

| 你的疑问 | 它的回答 |
| 全新安装后,阶段顺序规则报 skipped,是哪里坏了吗? | 不是。PC-003 拿登记表里的阶段和规则包中的 order 列表比对,而该列表出厂时是空的,表示未配置,所以规则把自己报成 skipped,而不是悄悄通过。把 order 填上你所在机构的顺序(规则包里的示例是 立项、可行性研究、初步设计、概算、招标、合同、开工、变更、结算、决算),它此后只检查登记表里出现的阶段是否遵循该顺序,允许中间有缺口;它从不判断跳过某个阶段是否合规,其依据里也记录了不存在可引用的条款,因此上限为 info。 |
| 登记表里的签署日期早于审批日期——这能查出来吗? | 能。PC-004 比对 signedAt 与 approvedAt:两者都必须能解析成日期,且签署日期不得早于审批日期,同一天算不晚于。无法解析的日期会单独报出,而不是默不作声地放过。它只比对这两个日期——不判断签署是否越权,也不判断审批本身是否有效。 |
| 金额写成 1,200.50 或 1200万元,还能读出来吗? | 能。PC-006 接受带千位分隔符或单位的金额,只报出无法按数字解析的金额。它只检查能否解析:金额是否超概算、是否需要审批,不归这条规则管。 |
| 某行既没有阶段名,也没有文档名。 | PC-002 要求每行至少填 stage 或 document 之一,并报出两者皆无的行。它只检查两者至少填了一个;该阶段是否本就该处理、对应文档是否齐全,都不作判断。 |
| 同一个文档编号出现在两行上。 | PC-005 报出重复的 docNo,比对时忽略空白,因为重复会让去重失效、金额被重复计入。它分不清是重复登记,还是两份文档被错编成同一个编号,所以命中后需要人工确认。 |
| 文档名仍然是 【待填】 或 TBD。 | PC-007 会报告 document 中含包内模板词的任何行——【、】、{{、}}、XXX、xxx、待填、待补充、TBD、todo、示例——因为从模板复制来的台账会让未处理的环节看起来已经落实。只搜索列出的这些词,terms 可以改成你自己的模板词。 |

遵循的标准

| 文档 | 编号 | 引用它的规则 |
| 本机构项目管理办法与投资管理制度(无国家标准) | 无统一标准(本条依据为台账可追溯性) | PC-001 |
| 本机构项目管理办法与投资管理制度(无国家标准) | 无统一标准(本条依据为链条齐备性) | PC-002 |
| 本机构项目管理办法与投资管理制度(无国家标准) | 无统一标准(本条依据为本机构配置的环节顺序表) | PC-003 |
| 本机构项目管理办法与投资管理制度(无国家标准) | 无统一标准(本条依据为日期自洽) | PC-004 |
| 本机构项目管理办法与投资管理制度(无国家标准) | 无统一标准(本条依据为台账唯一性) | PC-005, PC-008 |
| 本机构项目管理办法与投资管理制度(无国家标准) | 无统一标准(本条依据为金额可比性) | PC-006 |
| 本机构项目管理办法与投资管理制度(无国家标准) | 无统一标准(本条依据为台账真实性) | PC-007 |

边界: 这个插件检查项目全流程文件链条台账中台账本身能担责的部分——项目是否可识别,每行是否写明环节或文档,环节是否按你声明的顺序排列,审批和签署日期能否解析且前后相继,文档编号是否唯一,金额能否解析,以及是否还有模板占位符残留。它不判定项目是否合规、审批是否越权、支出是否超概算,也不判定谁该负责。这些取决于本机构的投资制度和审批权限。

⚠️ 这件事没有国家标准,本包也不假装有

项目经过哪些环节、按什么顺序,由各机构的项目与投资制度规定——而且行业之间(电力、市政、建筑、水利)、政府投资与企业投资项目之间差别很大。不存在统一的国家标准,所以本包不编造标准编号:每条规则的 excerpt 都明说其依据是链条自洽或可追溯性,且没有可引用的条款。有测试断言每条 excerpt 都带有这样的声明。

插件不自带环节表。 PC-003 的 stageOrder 出厂为空,什么都不配置时它把自己报进 skipped,而不是凭空编出一套环节顺序。这样配置:

order: [立项, 可行性研究, 初步设计, 概算, 招标, 合同, 开工, 变更, 结算, 决算]

之后检查会验证台账中出现的环节处于该顺序,跳过项目合理未经过的环节;它从不判断跳过是否被允许。

兼容性

| 层面 | 状态 |
| 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 |

功能

注册 pipeline_check 工具。它读取一份项目链登记表——项目头部加上每个阶段文档一行——套用版本化的规则包,返回报告。

| 规则 | 检查项 | 严重级别 | 依据 |
| PC-001 | 登记表写明项目名称和编号 | warn | 可追溯性 |
| PC-002 | 每行写明阶段或文档 | warn | 完整性 |
| PC-003 | 阶段顺序符合你配置的序列(默认关闭) | info | 本地顺序表 |
| PC-004 | 签署日期不早于批复日期 | warn | 日期一致性 |
| PC-005 | 文档编号唯一 | warn | 登记表唯一性 |
| PC-006 | 金额能解析为数字 | warn | 可比性 |
| PC-007 | 文档名称里没有未替换的占位符 | warn | 登记表完整性 |
| PC-008 | 阶段编号唯一 | warn | 登记表唯一性 |

安装

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

配置

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

规则级参数里值得了解的几项:

- PC-003 order —— 你的阶段序列。留空表示该规则不运行。阶段名带尾注(招标(二次))时按基础名匹配。
- PC-004 field / notBeforeField —— 要比较的日期对,默认拿签署日期对批复日期。生效日期再加一条规则。
- PC-007 terms —— 要查找的占位符。

材料格式

工具接受 JSON 或 YAML:

project: 某某技改项目 projectNo: XM-2026-018 rows:
- { 序号: '1', 环节: 立项, 文件名称: 项目立项批复, 文件编号: LX-2026-001,
金额: 1200万元, 批复日期: 2026-01-10, 签署日期: 2026-01-15, 生效日期: 2026-01-16 }

列名匹配不区分大小写,并忽略空格、下划线和连字符;登记表自己的列名会保留,所以每条发现都会指明它读的是哪一列。金额可以带千位分隔符和单位(1,200.50、1200万元)。

规则来源

规则数据放在 rules/pipeline-check.yaml。项目的阶段链没有国家标准可依,所以规则包的 basis 条目会明说这一点,而不是引用某个标准。加载时的守卫仍然要求每条规则都带文档、条款、摘录和来源,也仍然禁止把 derived-from-principle 或本地配置的检查设为 error。

故障排查

- PC-003 报告自己已跳过。 它的顺序表是空的。项目要经过哪些阶段你所在机构的规则,插件不会替你猜。
- PC-003 在某个阶段名上触发。 这个名字不在你的顺序表里。要么改正登记,要么补上这个阶段——报错会告诉你它无法归位的是哪个名字。
- PC-006 在我能读出的金额上触发。 读取器接受 1,200.50 和 1200万元;单元格里放的是范围(约 1200 万)或备注时,会故意报为无法解析。
- PC-005 在同一份文档上触发两次。 修订稿复用同一个编号时,这可能是合理的。在备注里说明,而不是删掉一行。
- 插件装上了,但工具一直不出现。 检查 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-pipeline-check@0.1.0 --dsh-version <runtime> --accept-risk
- check 报告 manifest-peers 失败。 静态检查器拿一个硬编码的 peer 范围来比对,而这个范围早于 0.2 系列。运行时在安装时强制校验 peer 兼容性,所以声明的范围才是正确的;这是 dsh-plugin-dev 里已知的上游问题。

Development

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-pipeline-check # refresh src/shared from ../_shared

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

License

Apache License 2.0 © 2026 dsh-pipeline-check contributors.
预览分享卡片长什么样 ↓PerryLink/dsh-pipeline-check
分享 · DeepSeek Harness Hub
PerryLink/dsh-pipeline-check

检查项目文档登记表的完整性与日期金额一致性

这是你的仓库?认领条目

回到顶部