检查工作票字段完整性与许可终结时间顺序
30/100
综合分
0
GitHub 星标
—
npm 周下载
—/5
用户评分
数据截至 2026/10/9 · 周下载取自 npm 全网(含 CI / 镜像),非本站安装数;综合分由星标、活跃度与兼容性检查合成。
安装命令 · 需先装 dsh CLI 引擎
dsh plugin --profile web add PerryLink/dsh-power-ticket-check该包不可直接 npm 安装,改从 GitHub 源安装(明细见下方安装检查)
状态速览
判定依据:实装验证 · 静态安装检查 · 自动扫描 · 仓库维护状态信任档位:需留意
是什么
dsh 原生插件 · tool
安全吗
本站尚未对该插件做风险分级
暂未覆盖,不等同于无风险
还在维护吗
活跃:最近一次提交在 26 天前
档位由哪些信号合成
本站实装验证(真实安装 L4 覆盖全站;L5 为运行时冒烟或实机截图,覆盖范围小于 L4) · 验证所用 dsh 版本 · 静态安装检查 · 风险分级 · 仓库维护状态。 下方各区块是它的证据明细。
⚠︎ 实装验证未通过(unknown · 2026/11/3) ——可能是验证环境差异,装前建议到 GitHub 仓库确认最近更新与 issue。
社区实装还没有人打卡 · 装过的第一个就是你
安全扫描自动 · 静态分析源码v2.7.0🔵 扫描:含敏感能力尚无人工评估展开查看扫描说明与证据 ↓
安全扫描自动 · 静态分析源码
v2.7.0静态扫描发现插件具备触达本地系统的能力:执行外部命令、读写/删除本地文件、读取剪贴板或密钥类环境变量(至少其一)。这是能力清单,不是危险判定——具体能力项与证据见下方,安装前请自行判断是否需要。
读写/删除本地文件
查看扫描证据(共 1 处,展示前 1 条)
- 读取本地文件samples/quickstart/run.mjs:7
const material = await readFile(join(here, 'input', "PT-001-unsafe.json"), 'utf8')
扫描于 2026/11/4(0 天前) · 范围 入口闭包 + 发布文件清单 · 来源 GitHub 仓库
静态扫描只反映源码中出现的调用,不构成安全背书;人工评估与自动扫描相互独立、互不覆盖。
依赖的 DSH / Cordis 模块
@deepseek-ai/cordis@deepseek-ai/dsh-package-manifest@deepseek-ai/dsh-tools@deepseek-ai/schemastery给这个插件打分还没有人投票↓
用户评分
还没有人投票,来当第一个
功能亮点
- 检查工作票字段完整性
- 核对许可终结时间顺序
- 仅提示差异
电力工作票核对:依据《电力安全工作规程 发电厂和变电站电气部分》(GB 26860—2011)。仅提示差异,不作出定性结论。
README
由 DeepSeek 最新模型翻译生成dsh-power-ticket-check — 电力工作票完整性与许可终结顺序检查
dsh-power-ticket-check 读取一张电力工作票,把它当作一份扁平映射:工作票自身的列名对应列值,再加上票面上写明的角色。然后按一张表单能被要求的标准去检查这张票:你配置的 requiredFields 里每一列都已填写;工作票种类在你部署列出的范围内;签发时间 → 许可时间 → 终结时间构成物理上可能的先后顺序;延期时间把结束时间往后推,且不早于许可时间;你配置为互斥的角色由不同的人担任;安全措施与许可文字里带有本包要查找的五项安全技术措施术语和三项许可手续术语。无法运行的检查会连同原因列在 skipped 里,而不是悄悄判为通过。
它能回答什么
| 你问 | 它怎么回答 |
| 开箱即用,我跑进去的每张票都通过——为什么? | 因为 PT-001 把自己报在 skipped 里,而不是报成通过。它的 requiredFields 列表出厂时是空的,规则跑不起来;把它填成你自己表单要求的列。即便配置好了,PT-001 检查的也只是某一列填没填,而不是里面的值对不对,而且它的级别是 info。 |
| 这张票是电气第一种工作票,但工作性质里提到带电作业——它会报这个矛盾吗? | 不会。PT-002 只报两件事:工作票种类缺失,或者不在你部署列出的种类里。
展开完整文档(README 剩余 1 节)
dsh-power-ticket-check — 电力工作票完整性与许可终结顺序检查 dsh-power-ticket-check 读取一张电力工作票,把它当作一份扁平映射:工作票自身的列名对应列值,再加上票面上写明的角色。然后按一张表单能被要求的标准去检查这张票:你配置的 requiredFields 里每一列都已填写;工作票种类在你部署列出的范围内;签发时间 → 许可时间 → 终结时间构成物理上可能的先后顺序;延期时间把结束时间往后推,且不早于许可时间;你配置为互斥的角色由不同的人担任;安全措施与许可文字里带有本包要查找的五项安全技术措施术语和三项许可手续术语。无法运行的检查会连同原因列在 skipped 里,而不是悄悄判为通过。 它能回答什么 | 你问 | 它怎么回答 | | 开箱即用,我跑进去的每张票都通过——为什么? | 因为 PT-001 把自己报在 skipped 里,而不是报成通过。它的 requiredFields 列表出厂时是空的,规则跑不起来;把它填成你自己表单要求的列。即便配置好了,PT-001 检查的也只是某一列填没填,而不是里面的值对不对,而且它的级别是 info。 | | 这张票是电气第一种工作票,但工作性质里提到带电作业——它会报这个矛盾吗? | 不会。PT-002 只报两件事:工作票种类缺失,或者不在你部署列出的种类里。它的 ticketKinds 列表出厂时是空的,规则随后把自己报在 skipped 里,跟 PT-005 在 exclusiveRolePairs 列表为空时的表现完全一样;插件不判断一项作业需要哪种票。等你把这两个列表填好,再给 PT-005 配上工作许可人与工作负责人这一对,就能让两列填了同一个人的情况被报出来。这两条规则都不评判谁有没有资格,也不评判兼任两个角色是否经过批准。 | | 许可时间写得比签发时间还早,而且有一列时间解析不出来。 | PT-003 两样都报:许可时间早于签发时间、终结时间早于许可时间,以及任何读不出来的列报为无法解析为日期时间,期望的格式形如 2026-03-15 08:30。两端都会换算成绝对分钟数,所以跨零点的票也能正确比较。如果签发时间或许可时间根本读不出来,规则就把自己报在 skipped 里,因为顺序检查无法成立。它从不检查作业是否真的按票执行,可选的间隔或时长上限由你自己配置。 | | 延期时间早于计划结束时间,所以这次延期是缩短了作业而不是延长。 | PT-004 会报出来,同时还会报延期时间早于许可时间。标准对一张票能延期多久、能延期几次没有设上限,所以这条规则不带任何量化限制,也不检查延期手续是否办完。 | | 安全措施 列已填写,但只提到 停电 和 验电。 | PT-006 会逐条报告缺失的三个术语。它是这里唯一处于 error 的规则,因为其第 6.1.1 条位于强制性章节,而且它检查的是工作票上是否写明了五项措施,而不是这些措施是否与现场相符、是否已执行。如果找不到可读的措施列,它会以 skipped 报告自身。 | | 工作票上没有任何内容表明 工作许可人 与 工作负责人 再次去了现场。 | PT-007 会报告它读取的文本中缺少三个许可手续术语中的哪几个,该文本是 permitColumns 加上角色列中的姓名。它只读取措辞:无法判断现场复核是否真的发生,而希望此项阻断的机构可以在规则包中提高该规则的严重级别,无需改动代码。 | 遵循的标准 | 文档 | 编号 | 引用规则 | | 《电力安全工作规程 发电厂和变电站电气部分》 | GB 26860—2011 | PT-001, PT-002, PT-003, PT-004, PT-005, PT-006, PT-007 | 边界: 本插件检查一张 电力工作票 中表单可被要求的内容——必填栏是否填写、签发 / 许可 / 终结 是否按物理上可能的顺序发生、延期 是否将结束时间向后推移、你要求分离的角色是否由不同的人担任。它不判断工作票上写的安全措施是否充分,不说明某项工作需要哪种工作票,也不核实任何人的资质是否真实。 ⚠️ 本插件拒绝做的三件事,以及修正其严重级别的 effect 层级 1. 它尊重标准自身的 effect 层级。 GB 26860—2011 的前言逐字写道:「本标准的第5章和7.3.4为推荐性,其余为强制性」——工作票制度位于推荐性的第 5 章。 因此,所有依托第 5 章的规则都以 warn 或 info 发布,其中任何规则都不能阻断工作流。PT-006(五项安全技术措施,第 6.1.1 条)是唯一的 error,因为第 6 章是强制性的。PT-007(许可手续,第 5.5.1 条)是 warn;其说明指出,希望这些手续阻断的机构可以通过编辑规则包来提高它,无需改动代码。一项测试断言两个方向:没有任何第 5 章规则是 error,且 PT-006 是唯一的一个。 2. 它不采纳三项在标准中毫无依据的说法。 完整阅读 GB 26860—2011 和 GB 26859—2011 后:任何地方都没有「第一种工作票应工作前一日送达」的期限;5.3.12 和 5.4.10 只说「延期应办理手续」,对时长或次数没有上限;法定名称是紧急抢修单(5.2.4),而不是「事故应急抢修单」。一项测试断言规则包记录了这三项。 3. 它不把工作票版式视为强制性。 5.1.2 说工作票「可包含」这些项目,且附录 A–D 在标准目录中标注为资料性附录。因此 PT-001 以空字段列表发布,由你根据自己的表单填写,并以 info 报告。 另外两份清单归你维护:PT-002 的票据种类,以及 PT-005 的互斥角色对。两者出厂都是空的。 插件从不判断票据上写的安全措施是否到位、某项作业需要哪种票据种类,也不判断任何人的资格是否真实——标准只规定角色的职责(5.4.1–5.4.5),没有资格条件。 兼容性 | 层面 | 状态 | | 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 | 它能做什么 注册 power_ticket_check 工具。它把一张票据读成扁平映射,键是票据自己的列名,值是列的内容,然后套用带版本的规则包,返回一份报告。 | 规则 | 检查内容 | 严重级别 | 依据类型 | | PT-001 | 每个已配置的列都已填写(默认关闭,用于提示版式) | info | local | | PT-002 | 票据种类是你使用的种类,且与作业性质相符 | warn | direct | | PT-003 | 签发 → 许可 → 终结 是可能的顺序;可选的时间间隔与时长限制 | warn | principle | | PT-004 | 延期把结束时间往后推,并跟在许可之后 | warn | direct | | PT-005 | 你要求分离的角色由不同的人担任(默认关闭) | warn | direct | | PT-006 | 五项安全技术措施已写在票据上 | error | direct | | PT-007 | 许可手续(现场复查、指明带电部位、双方签名) | warn | direct | 安装 dsh plugin --profile <name> add dsh-power-ticket-check dsh --profile <name> --dump-config | grep 'dsh-power-ticket-check' 配置 | 键 | 类型 | 默认值 | 说明 | | rulesFile | string | rules/power-ticket-check.yaml | 规则包路径,相对于包根目录 | | disabledRules | string[] | [] | 要停止运行的规则 id;每个都会出现在 skipped 里 | | onlyRules | string[] | [] | 只运行这些规则 id;留空则运行全部规则 | | skipNotes | string | "" | 附加到每条 skipped 原因后面的备注 | | timeoutMs | number | 120000 | 协作式工具超时预算 | 值得了解的规则级参数: - PT-001 requiredFields —— 必须填写的列,用材料里同样的列名。 - PT-002 ticketKinds —— 你的票据种类,例如 [第一种工作票, 第二种工作票, 带电作业票]。也可以按调用传入。 - PT-003 minMinutesBeforeWork —— 你要求 签发 与 许可 之间的最短间隔。0 关闭间隔比较。 - PT-003 maxDurationHours —— 单张票据最长可运行多久。0 关闭时长检查。 - PT-005 exclusiveRolePairs —— 不能由同一人担任的角色对,写法 ['工作票签发人|工作许可人']。 材料格式 工具接受 JSON 或 YAML。一张工作票就是一个扁平映射: 工作票编号: DL-2026-0001 工作票种类: 第一种工作票工作地点: 35kV 某某变电站工作任务: 10kV 某某线 01 号杆更换隔离开关计划开始时间: 2026-03-15 08:00 计划结束时间: 2026-03-15 18:00 签发时间: 2026-03-14 16:00 许可时间: 2026-03-15 08:30 终结时间: 2026-03-15 17:00 工作票签发人: 张工工作负责人: 李工工作许可人: 王工 时间可以写成 2026-03-15 08:30,也可以只写日期。只写日期时按午夜处理,报告在需要时会说明这一点。角色列可以带后缀——工作负责人签名 会被识别为工作负责人角色——所以导出的表单即使带着签名框,也能干净地映射。 时序检查在同一条连续时间轴上比较两端,所以许可时间落在更早的一天时,报告的是更早的时刻,而不是当天一个很小的负区间。 规则来源 规则数据放在 rules/power-ticket-check.yaml。每条规则都带一份文档、一个文档编号、按来源自身编号体系给出的条款号、一段逐字摘录,以及摘录的读取 URL。加载器强制要求:摘录必须是真实引用,至少八个字符;依据一般原则或地方政策做出的检查,永远不能判定为 error。 引用的条款来自 GB 26860—2011《电力安全工作规程 发电厂和变电站电气部分》——5.1.2、5.2.1–5.2.4、5.3.7、5.3.12、5.5.1、5.7.5 和 6.1.1——标准的前言给出了效力层级,决定每条规则的严重程度。条款文本取自全文扫描转录,并与第二个独立站点逐字交叉核对。 这一族标准目前有效,均已对照标准平台核实: | 标准 | 生效日期 | 备注 | | GB 26860—2011 发电厂和变电站电气部分 | 2012-06-01 | 强制性,第 5 章和 7.3.4 除外;修订版「正在报批」 | | GB 26859—2011 电力线路部分 | 2012-06-01 | 线路侧的对应标准 | | DL/T 408—2023 发电厂和变电站电气部分 | 2024-06-28 | 代替 DL 408—1991,与 GB 26860 并行——不是替代它 | | DL/T 409—2023 电力线路部分 | 2024-06-28 | | | DL/T 560—2022 高压试验室部分 | 2022-11-13 | 代替 DL 560—1995 | DL/T 408—2023 的条款文本无法获取,所以本规则包没有引用它的任何条款。 它的身份和章节结构已核实,DL/T 408—2023 把紧急抢修单改名为故障紧急抢修单,并新增带电作业票和双签发——这就是 PT-002 同时接受两个名称、而不是只挑一个的原因。 完整的条款核实报告,包括已检查并排除的来源,在 rules/evidence/clause-verification.md。 故障排查 - PT-001、PT-002 或 PT-005 报告自身被跳过。 它们的列表是空的。按你所在企业的规则要求填上。 - PT-003 不报告任何顺序问题。 签发时间和许可时间没有同时出现;规则会在 skipped 里说明。如果时间存在但读不出来,规则报告的是那件事,而不是跳过,所以无法解析的单元格永远不会掩盖检查。 - PT-003 会在我们看来正常的时长上触发。 maxDurationHours 默认是 0;如果你设置了它,它就会作用于工具看到的每一张工单。如果你的工单本来就会跑很久,就把它留在 0。 - PT-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-power-ticket-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, paired fixtures per rule pnpm run build # tsdown -> lib/index.mjs + lib/index.d.mts node ../scripts/sync-shared.mjs dsh-power-ticket-check # refresh src/shared from ../_shared 许可证 Apache License 2.0 © 2026 dsh-power-ticket-check contributors.
预览分享卡片长什么样 ↓
分享 · DeepSeek Harness Hub
PerryLink/dsh-power-ticket-check
检查工作票字段完整性与许可终结时间顺序
相关插件 · 工具 / 效率
破甲管控台kingcharleslzy-ai/dsh-purge
dsh-purge Community · DeepSeek Harness 社区维护版:宿主兼容、状态诊断、提示词管理、更新与本机备份回滚。基于小杨 / YuJunZhiXue 的 dsh-purge。
★ 4,330已汉化DeepSeek 客户端
74.5
网文长卷lingfengQAQ/webnovel-writer
基于 Claude Code 的长篇网文辅助创作系统,解决 AI 写作中的「遗忘」和「幻觉」问题,支持 200…
★ 7,826已汉化DSH
72.2
花束设计alchaincyf/huashu-design
一句话生成网页、原型、PPT 与信息图等可交付设计
★ 28,638已汉化DSH
71.7
多智能体协作HKUDS/AutoSwarm
AutoSwarm: Unify Your Agents. Unify Your Context (Codex · Claude Code · DeepSeek Harness · Muse · Grok · WorkBuddy· nanobot · and more)
★ 2,349已汉化DSH
71.6
Vox 拼贴视频生成Alisa0808/vox-director
🎬 Vox Director拼贴动效导演
★ 2,129已汉化DSH
71.4
Agent 演化引擎Q00/ouroboros
智能体 OS:智能体自己变聪明,我们只守住底线:面试准入、分阶段评估、带预算的进化循环。MCP 服务器,14 种运行时:Claude Code、Codex CLI、Gemini CLI、OpenCode、Copilot、Kiro 等。
★ 6,311已汉化DSH
71.4
这是你的仓库?认领条目