dsh-power-ticket-check 0.2.1 → 0.2.2

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/CHANGELOG.md CHANGED
@@ -1,5 +1,22 @@
1
1
  # Changelog
2
2
 
3
+ ## 0.2.2
4
+
5
+ - Rework the README first screen. The H1 now names what the plugin checks rather
6
+ than repeating the package name, and a question-and-answer table and a standards
7
+ table come before the boundary paragraph.
8
+
9
+ The substance is unchanged and the boundary paragraph is verbatim: in a
10
+ compliance tool that paragraph is what stops a wrong "pass" being read as
11
+ approval, so it moved rather than shrank. What changed is the order - a reader
12
+ or an extractor previously met eleven badges, an install command and a
13
+ disclaimer before learning what the plugin does. The Q&A rows are derived from
14
+ each plugin's own rules and the standards table from the rule pack's
15
+ `document`/`number` fields, so no answer and no standard is hand-typed.
16
+
17
+ All five languages were restructured together; `check:readmes` holds them to the
18
+ same section count, install command and configuration keys.
19
+
3
20
  ## 0.2.1
4
21
 
5
22
  - Ship `CHANGELOG.md` and `SECURITY.md` inside the package. `files` is an
package/README-es.md CHANGED
@@ -1,4 +1,23 @@
1
- # dsh-power-ticket-check
1
+ # dsh-power-ticket-check — Verificación de la completitud del permiso de trabajo eléctrico y del orden de emisión, autorización y cierre
2
+
3
+ `dsh-power-ticket-check` lee un **电力工作票** como un mapa plano de los nombres de columna del propio formulario a sus valores, junto con los roles que figuran en él, y comprueba lo que puede exigirse a un formulario: que estén rellenas todas las columnas de su `requiredFields` configurado, que el 工作票种类 figure entre los que declara su implantación, que 签发时间 → 许可时间 → 终结时间 formen una secuencia físicamente posible, que un 延期时间 desplace el final hacia adelante y no sea anterior a la autorización, que los roles configurados como exclusivos los desempeñen personas distintas, y que el texto de medidas de seguridad y de autorización contenga los cinco términos de 安全技术措施 y los tres de 许可手续 que el paquete busca. Las comprobaciones que no pudieron ejecutarse se listan en `skipped` con su motivo, en lugar de pasar en silencio.
4
+
5
+ ## Qué responde
6
+
7
+ | Usted pregunta | Qué responde |
8
+ |---|---|
9
+ | Tal como viene, aprueba todos los permisos que le paso, ¿por qué? | Porque `PT-001` se declara a sí misma en `skipped`, no como aprobado. Su lista `requiredFields` viene vacía, así que la regla no puede ejecutarse; rellénela con las columnas que exige su propio formulario. Aun configurada, `PT-001` comprueba que la columna esté rellena, no que el valor sea correcto, y su nivel es `info`. |
10
+ | El permiso es un 电气第一种工作票 pero la 工作性质 menciona 带电作业, ¿se informa de esa contradicción? | No. `PT-002` informa solo de dos cosas: que falte el 工作票种类, o que no esté entre los tipos que declara su implantación. Su lista `ticketKinds` viene vacía y entonces la regla se declara en `skipped`, igual que `PT-005` cuando su lista `exclusiveRolePairs` está vacía; el plugin no decide qué tipo de permiso necesita un trabajo. Una vez rellene esas listas, configure `PT-005` con el par 工作许可人 y 工作负责人 para que se informe de la misma persona en ambas columnas. Ninguna de las dos reglas juzga la cualificación de nadie ni si se aprobó desempeñar dos roles. |
11
+ | El 许可时间 figura antes del 签发时间, y además una columna de tiempo no se puede analizar. | `PT-003` informa de ambas cosas: del 许可时间 anterior al 签发时间, del 终结时间 anterior al 许可时间, y de cualquier columna ilegible como 无法解析为日期时间, esperando una forma como `2026-03-15 08:30`. Ambos extremos se convierten a un recuento absoluto de minutos, así que un permiso que cruza la medianoche se compara bien. Si el 签发时间 o el 许可时间 no se pueden leer en absoluto, la regla se declara en `skipped`, porque la comprobación del orden no puede establecerse. Nunca comprueba si el trabajo siguió realmente el permiso, y el límite opcional de intervalo o de duración lo configura usted. |
12
+ | El 延期时间 es anterior al 计划结束时间, así que la prórroga acorta el trabajo en vez de alargarlo. | `PT-004` lo informa, y también informa de un 延期时间 anterior al 许可时间. La norma no fija ningún tope a cuánto ni a cuántas veces puede prorrogarse un permiso, así que la regla no lleva límite cuantitativo ni comprueba si se completaron los trámites de prórroga. |
13
+ | La columna 安全措施 está rellena, pero solo menciona 停电 y 验电. | `PT-006` informa de los tres términos que faltan, uno por uno. Es la única regla de nivel `error` aquí, porque su cláusula 6.1.1 está en el capítulo obligatorio, y comprueba que las cinco medidas estén escritas en el permiso, no que coincidan con el lugar ni que se hayan ejecutado. Si no encuentra ninguna columna de medidas legible, se declara en `skipped`. |
14
+ | Nada en el permiso muestra que el 工作许可人 volviera al lugar con el 工作负责人. | `PT-007` informa de cuáles de los tres términos de las formalidades de autorización faltan en el texto que lee, y ese texto son las `permitColumns` más los nombres de las columnas de rol. Solo lee la redacción: no puede saber si la revisión del lugar ocurrió de verdad, y una institución que quiera que esto bloquee puede subir el nivel de la regla en el paquete sin tocar el código. |
15
+
16
+ ## Normas que sigue
17
+
18
+ | Documento | Número | Reglas que lo citan |
19
+ |---|---|---|
20
+ | 《电力安全工作规程 发电厂和变电站电气部分》 | GB 26860—2011 | PT-001, PT-002, PT-003, PT-004, PT-005, PT-006, PT-007 |
2
21
 
3
22
  **Boundary:** this plugin checks one **电力工作票** for what a form can be held to — that the required
4
23
  boxes are filled, that 签发 / 许可 / 终结 happened in an order that is physically possible, that 延期
package/README-hi.md CHANGED
@@ -1,4 +1,23 @@
1
- # dsh-power-ticket-check
1
+ # dsh-power-ticket-check — विद्युत कार्य-अनुज्ञप्ति की पूर्णता तथा निर्गमन, अनुमति और समापन के क्रम की जाँच
2
+
3
+ `dsh-power-ticket-check` एक **电力工作票** को उसके अपने कॉलम नामों से मानों तक के सपाट मैपिंग के रूप में पढ़ता है — साथ में उस पर अंकित भूमिकाएँ — और उस अनुज्ञप्ति की वह जाँच करता है जो एक फ़ॉर्म से अपेक्षित की जा सकती है: आपके कॉन्फ़िगर किए गए `requiredFields` के हर कॉलम में मान भरा हो, 工作票种类 आपकी संस्था द्वारा सूचीबद्ध किस्मों में से हो, 签发时间 → 许可时间 → 终结时间 का क्रम भौतिक रूप से संभव हो, 延期时间 अंत को आगे बढ़ाए और अनुमति से पहले न हो, जिन भूमिकाओं को आपने अलग-अलग रखने के लिए कॉन्फ़िगर किया है वे अलग-अलग व्यक्तियों के हों, तथा सुरक्षा-उपाय और अनुमति के पाठ में नियम-पैक द्वारा खोजे जाने वाले 安全技术措施 के पाँच और 许可手续 के तीन शब्द मौजूद हों। जो जाँचें चल नहीं सकीं, वे चुपचाप पास होने के बजाय कारण के साथ `skipped` में दर्ज होती हैं।
4
+
5
+ ## यह किन सवालों का जवाब देता है
6
+
7
+ | आपका सवाल | इसका जवाब |
8
+ |---|---|
9
+ | जैसा यह आता है, मेरी हर अनुज्ञप्ति इसमें पास हो जाती है — क्यों? | क्योंकि `PT-001` स्वयं को पास के रूप में नहीं, `skipped` में दर्ज करता है। उसकी `requiredFields` सूची खाली आती है, इसलिए यह नियम चल ही नहीं सकता; उसमें अपने फ़ॉर्म के अनिवार्य कॉलम भरें। कॉन्फ़िगर होने पर भी `PT-001` यह देखता है कि कॉलम भरा है, यह नहीं कि उसमें लिखा मान सही है, और उसका स्तर `info` है। |
10
+ | अनुज्ञप्ति 电气第一种工作票 है पर 工作性质 में 带电作业 लिखा है — क्या यह विरोधाभास दर्ज होता है? | नहीं। `PT-002` केवल दो बातें दर्ज करता है: कि 工作票种类 ही नहीं लिखा, या वह आपकी संस्था द्वारा सूचीबद्ध किस्मों में नहीं है। उसकी `ticketKinds` सूची खाली आती है और तब यह नियम स्वयं को `skipped` में दर्ज करता है — ठीक वैसे ही जैसे `PT-005` अपनी `exclusiveRolePairs` सूची खाली होने पर करता है; किस काम के लिए कौन-सी अनुज्ञप्ति चाहिए, यह प्लगइन तय नहीं करता। इन सूचियों को भरने के बाद `PT-005` में 工作许可人 और 工作负责人 का युग्म कॉन्फ़िगर करें, ताकि दोनों कॉलमों में एक ही व्यक्ति दर्ज हो। कोई भी नियम किसी की योग्यता या दो भूमिकाएँ रखने की अनुमति की जाँच नहीं करता। |
11
+ | 许可时间 签发时间 से पहले लिखा है, और एक समय-कॉलम पढ़ा भी नहीं जा सकता। | `PT-003` दोनों दर्ज करता है: 许可时间 का 签发时间 से पहले होना, 终结时间 का 许可时间 से पहले होना, और किसी भी अपठनीय कॉलम को 无法解析为日期时间 के रूप में, `2026-03-15 08:30` जैसी लेखन-शैली की अपेक्षा के साथ। दोनों सिरों को पूर्ण मिनट-गणना में बदला जाता है, इसलिए आधी रात पार करने वाली अनुज्ञप्ति भी ठीक तुलना में आती है। यदि 签发时间 या 许可时间 बिल्कुल पढ़ा ही न जा सके, तो यह नियम स्वयं को `skipped` में दर्ज करता है, क्योंकि क्रम की जाँच तब सिद्ध नहीं होती। यह कभी नहीं देखता कि काम वास्तव में अनुज्ञप्ति के अनुसार हुआ; वैकल्पिक अंतराल या अवधि-सीमा आप स्वयं कॉन्फ़िगर करते हैं। |
12
+ | 延期时间 计划结束时间 से पहले है, यानी मंज़ूरी काम को बढ़ाने के बजाय घटा रही है। | `PT-004` इसे दर्ज करता है, और 许可时间 से पहले के 延期时间 को भी दर्ज करता है। मानक में यह तय नहीं है कि मंज़ूरी कितनी लंबी या कितनी बार हो सकती है, इसलिए इस नियम में कोई मात्रात्मक सीमा नहीं है और यह नहीं देखता कि मंज़ूरी की औपचारिकताएँ पूरी हुईं या नहीं। |
13
+ | 安全措施 कॉलम भरा है, पर उसमें केवल 停电 और 验电 का उल्लेख है। | `PT-006` छूटे हुए तीन शब्द एक-एक करके दर्ज करता है। यहाँ यह अकेला `error` स्तर का नियम है, क्योंकि उसका खंड 6.1.1 अनिवार्य अध्याय में है, और यह देखता है कि पाँचों उपाय अनुज्ञप्ति पर लिखे हैं, यह नहीं कि वे साइट से मेल खाते हैं या पूरे किए गए। यदि कोई पठनीय उपाय-कॉलम न मिले, तो यह स्वयं को `skipped` में दर्ज करता है। |
14
+ | अनुज्ञप्ति से यह नहीं दिखता कि 工作许可人 工作负责人 के साथ दोबारा साइट पर गया। | `PT-007` उन तीन अनुमति-औपचारिकता शब्दों में से जो उसके पढ़े गए पाठ में नहीं हैं, उन्हें दर्ज करता है — और वह पाठ `permitColumns` तथा भूमिका-कॉलमों के नामों से बनता है। यह केवल शब्दों की जाँच है: साइट पर दोबारा निरीक्षण वास्तव में हुआ या नहीं, यह बता नहीं सकता; और यदि आपकी संस्था चाहे कि यह प्रक्रिया रोके, तो कोड बदले बिना नियम-पैक में इसका स्तर बढ़ाया जा सकता है। |
15
+
16
+ ## यह किन मानकों पर आधारित है
17
+
18
+ | दस्तावेज़ | संख्यांक | इन्हें उद्धृत करने वाले नियम |
19
+ |---|---|---|
20
+ | 《电力安全工作规程 发电厂和变电站电气部分》 | GB 26860—2011 | PT-001, PT-002, PT-003, PT-004, PT-005, PT-006, PT-007 |
2
21
 
3
22
  **Boundary:** this plugin checks one **电力工作票** for what a form can be held to — that the required
4
23
  boxes are filled, that 签发 / 许可 / 终结 happened in an order that is physically possible, that 延期
package/README-pt.md CHANGED
@@ -1,4 +1,23 @@
1
- # dsh-power-ticket-check
1
+ # dsh-power-ticket-check — Verificação da completude do permiso de trabalho elétrico e da ordem de emissão, autorização e encerramento
2
+
3
+ `dsh-power-ticket-check` lê um **电力工作票** como um mapa plano dos nomes das colunas do próprio formulário para os respetivos valores, em conjunto com os papéis nele indicados, e verifica o que se pode exigir a um formulário: que todas as colunas do seu `requiredFields` configurado estejam preenchidas, que o 工作票种类 conste dos que a sua implantação declara, que 签发时间 → 许可时间 → 终结时间 formem uma sequência fisicamente possível, que um 延期时间 empurre o fim para a frente e não seja anterior à autorização, que os papéis configurados como exclusivos sejam desempenhados por pessoas diferentes, e que o texto das medidas de segurança e da autorização contenha os cinco termos de 安全技术措施 e os três de 许可手续 que o pacote procura. As verificações que não puderam ser executadas são listadas em `skipped` com o respetivo motivo, em vez de passarem em silêncio.
4
+
5
+ ## O que ele responde
6
+
7
+ | Você pergunta | O que ele responde |
8
+ |---|---|
9
+ | Tal como vem, aprova todos os permís que lhe passo, por quê? | Porque `PT-001` declara-se a si mesma em `skipped`, e não como aprovada. A sua lista `requiredFields` vem vazia, pelo que a regra não pode ser executada; preencha-a com as colunas que o seu próprio formulário exige. Mesmo configurada, `PT-001` verifica que a coluna está preenchida, não que o valor esteja correto, e o seu nível é `info`. |
10
+ | O permís é um 电气第一种工作票 mas a 工作性质 menciona 带电作业 — isso é reportado como contradição? | Não. `PT-002` reporta apenas duas coisas: que falte o 工作票种类, ou que não conste dos tipos que a sua implantação declara. A sua lista `ticketKinds` vem vazia e a regra declara-se então em `skipped`, tal como `PT-005` quando a sua lista `exclusiveRolePairs` está vazia; o plugin não decide de que tipo de permís uma tarefa precisa. Depois de preencher essas listas, configure `PT-005` com o par 工作许可人 e 工作负责人 para que a mesma pessoa nas duas colunas seja reportada. Nenhuma das regras julga a habilitação de alguém nem se foi autorizado acumular dois papéis. |
11
+ | O 许可时间 está escrito antes do 签发时间, e além disso uma coluna de tempo não é analisável. | `PT-003` reporta ambas as coisas: o 许可时间 anterior ao 签发时间, o 终结时间 anterior ao 许可时间, e qualquer coluna ilegível como 无法解析为日期时间, esperando uma forma como `2026-03-15 08:30`. Ambos os extremos são convertidos num total absoluto de minutos, pelo que um permís que atravessa a meia-noite é comparado corretamente. Se o 签发时间 ou o 许可时间 não puderem ser lidos de todo, a regra declara-se em `skipped`, porque a verificação da ordem não pode ser estabelecida. Nunca verifica se o trabalho seguiu realmente o permís, e o limite opcional de intervalo ou de duração é você quem o configura. |
12
+ | O 延期时间 é anterior ao 计划结束时间, pelo que a prorrogação encurta o trabalho em vez de o prolongar. | `PT-004` reporta-o, e reporta também um 延期时间 anterior ao 许可时间. A norma não fixa qualquer limite a quanto nem a quantas vezes um permís pode ser prorrogado, pelo que a regra não tem limite quantitativo nem verifica se as formalidades da prorrogação foram cumpridas. |
13
+ | A coluna 安全措施 está preenchida, mas menciona apenas 停电 e 验电. | `PT-006` reporta os três termos em falta, um por um. É a única regra aqui com nível `error`, porque a sua cláusula 6.1.1 está no capítulo obrigatório, e verifica que as cinco medidas estão escritas no permís, não que correspondam ao local ou tenham sido executadas. Se não encontrar nenhuma coluna de medidas legível, declara-se em `skipped`. |
14
+ | Nada no permís mostra que o 工作许可人 tenha voltado ao local com o 工作负责人. | `PT-007` reporta quais dos três termos das formalidades de autorização faltam no texto que lê, e esse texto são as `permitColumns` mais os nomes das colunas de papel. Lê apenas a redação: não pode saber se a revisão do local aconteceu de facto, e uma instituição que queira que isto bloqueie pode subir o nível da regra no pacote sem tocar no código. |
15
+
16
+ ## Normas que segue
17
+
18
+ | Documento | Número | Regras que o citam |
19
+ |---|---|---|
20
+ | 《电力安全工作规程 发电厂和变电站电气部分》 | GB 26860—2011 | PT-001, PT-002, PT-003, PT-004, PT-005, PT-006, PT-007 |
2
21
 
3
22
  **Boundary:** this plugin checks one **电力工作票** for what a form can be held to — that the required
4
23
  boxes are filled, that 签发 / 许可 / 终结 happened in an order that is physically possible, that 延期
package/README-zh.md CHANGED
@@ -1,4 +1,23 @@
1
- # dsh-power-ticket-check
1
+ # dsh-power-ticket-check — 电力工作票要素齐备性与签发许可终结顺序核对
2
+
3
+ `dsh-power-ticket-check` 读取一份 **电力工作票**——以票面栏目名为键、栏目取值为值的平铺映射,外加票上列出的人员角色——按一张票面能被要求到的范围核对:本机构配置的 `requiredFields` 各栏是否都已填写、工作票种类是否在本机构列出的票种之内、签发时间 → 许可时间 → 终结时间 的顺序是否物理上成立、延期时间是否把结束时间向后推且不早于许可时间、本机构配置为须分设的角色是否由不同人员担任,以及安全措施与许可文本中是否出现规则库要求核对的安全技术措施五项与许可手续三项关键词。未能执行的检查逐条列在 `skipped` 并写明原因,而不是静默通过。
4
+
5
+ ## 它回答什么问题
6
+
7
+ | 你会问 | 它怎么答 |
8
+ |---|---|
9
+ | 出厂状态下,随便一份工作票都能通过,为什么? | 因为 `PT-001` 是以 `skipped` 自报,不是判定通过。它的 `requiredFields` 清单出厂为空,本条无法执行;请按本机构票面把必填栏目填进去。即便配置好后,`PT-001` 也只核对栏目是否填写,不判断填写内容是否正确,且严重级为 `info`。 |
10
+ | 票种填的是电气第一种工作票,工作性质却写着带电作业,这种矛盾会报出吗? | 不会。`PT-002` 只报两种情况:工作票种类没有填写,或所填种类不在本机构列出的票种之内。它的 `ticketKinds` 清单出厂为空,此时本条以 `skipped` 自报——`PT-005` 在 `exclusiveRolePairs` 清单为空时也是如此;本插件不判断该作业应当使用哪一种票。把清单填上以后,可把 `PT-005` 的角色对配成工作许可人与工作负责人,同一人同时出现在这两栏时即会报出。两条规则都不判断人员资格,也不判断兼职是否经批准。 |
11
+ | 许可时间写得比签发时间还早,另有一个时间栏的格式读不出来。 | `PT-003` 两种情况都会报:许可时间早于签发时间、终结时间早于许可时间,以及读不出来的栏目报为无法解析为日期时间,提示应按本机构统一写法填写,如 `2026-03-15 08:30`。它把两端都换算为绝对分钟数比较,跨天填写也算得准。若签发时间或许可时间完全读不出来,本条改为以 `skipped` 自报,因为顺序核对不成立。它不判断实际作业是否按票执行;可选的间隔与时长上限由使用方自行配置。 |
12
+ | 延期时间早于计划结束时间,等于把工期改短了。 | `PT-004` 会报出,延期时间早于许可时间也一并报出。标准未规定延期可以延长多久、可以办几次,因此本条不带任何量化上限,也不判断延期手续是否齐备。 |
13
+ | 安全措施栏写了内容,但只提到停电和验电。 | `PT-006` 会逐项报出缺少的三项。本条是本库唯一使用 `error` 级的规则,因为其依据 6.1.1 落在强制性章节;它只核对票面是否写到这五项,不判断措施内容是否与现场相符、是否执行到位。若找不到可读取的安全措施栏目,本条以 `skipped` 自报。 |
14
+ | 票面上看不出工作许可人曾会同工作负责人再到现场复查。 | `PT-007` 会报出它所读取的文本中缺少三项许可手续里的哪几项,读取范围是 `permitColumns` 这些栏目加上各角色栏的人名。它只做字面核对:现场是否真的复查过,它无从判断;若本机构要求这类问题阻断流程,可在规则库中直接提高本条严重级,不必改代码。 |
15
+
16
+ ## 依据的标准
17
+
18
+ | 文件 | 文号 | 引用它的规则 |
19
+ |---|---|---|
20
+ | 《电力安全工作规程 发电厂和变电站电气部分》 | GB 26860—2011 | PT-001, PT-002, PT-003, PT-004, PT-005, PT-006, PT-007 |
2
21
 
3
22
  **Boundary:** this plugin checks one **电力工作票** for what a form can be held to — that the required
4
23
  boxes are filled, that 签发 / 许可 / 终结 happened in an order that is physically possible, that 延期
package/README.md CHANGED
@@ -1,4 +1,23 @@
1
- # dsh-power-ticket-check
1
+ # dsh-power-ticket-check — Power work-ticket completeness and issue-permit-termination order check
2
+
3
+ `dsh-power-ticket-check` reads one **电力工作票** as a flat mapping of the ticket's own column names to their values, together with the roles named on it, and checks that ticket for what a form can be held to: that every column in your configured `requiredFields` is filled, that the 工作票种类 is one your deployment lists, that 签发时间 → 许可时间 → 终结时间 form a sequence that is physically possible, that a 延期时间 pushes the end forward and does not precede the permit, that roles you configured as exclusive are held by different people, and that the safety-measure and permit text carries the five 安全技术措施 terms and the three 许可手续 terms the pack looks for. Checks that could not run are listed in `skipped` with their reason rather than passing silently.
4
+
5
+ ## What it answers
6
+
7
+ | You ask | What it answers |
8
+ |---|---|
9
+ | Out of the box it passes every ticket I run through it — why? | Because `PT-001` reports itself in `skipped`, not as a pass. Its `requiredFields` list ships empty, so the rule cannot run; fill it with the columns your own form requires. Even when configured, `PT-001` checks that a column is filled, not that the value in it is correct, and it sits at `info`. |
10
+ | The ticket is a 电气第一种工作票 but the 工作性质 mentions 带电作业 — is that a contradiction it reports? | No. `PT-002` reports only two things: that the 工作票种类 is missing, or that it is not among the kinds your deployment lists. Its `ticketKinds` list ships empty and the rule then reports itself in `skipped`, exactly as `PT-005` does when its `exclusiveRolePairs` list is empty; the plugin does not decide which kind of ticket a job needs. Once you fill those lists, configure `PT-005` with the pair 工作许可人 and 工作负责人 to have the same person in both columns reported. Neither rule judges anyone's qualification or whether holding two roles was approved. |
11
+ | The 许可时间 is written earlier than the 签发时间, and one time column will not parse. | `PT-003` reports both: 许可时间 earlier than 签发时间, 终结时间 earlier than 许可时间, and any unreadable column as 无法解析为日期时间, expecting a form such as `2026-03-15 08:30`. Both ends are converted to an absolute minute count, so a ticket spanning midnight compares correctly. If 签发时间 or 许可时间 cannot be read at all, the rule reports itself in `skipped`, because the order check cannot be established. It never checks whether the work actually followed the ticket, and an optional interval or duration limit is yours to configure. |
12
+ | The 延期时间 is earlier than the 计划结束时间, so the extension shortens the job rather than lengthening it. | `PT-004` reports it, and also reports a 延期时间 earlier than the 许可时间. The standard sets no ceiling on how long or how often a ticket may be extended, so the rule carries no quantitative limit and does not check whether the extension formalities were completed. |
13
+ | The 安全措施 column is filled in but mentions only 停电 and 验电. | `PT-006` reports the three missing terms one by one. It is the only rule here at `error`, because its clause 6.1.1 sits in the mandatory chapter, and it checks that the five measures are written on the ticket, not that they match the site or were carried out. If no readable measure column is found it reports itself in `skipped`. |
14
+ | Nothing on the ticket shows that the 工作许可人 went to the site again with the 工作负责人. | `PT-007` reports which of the three permit-formality terms are absent from the text it reads, that text being the `permitColumns` plus the names in the role columns. It reads wording only: it cannot tell whether the site re-check really happened, and an institution that wants this to block can raise the rule's severity in the pack without a code change. |
15
+
16
+ ## Standards it follows
17
+
18
+ | Document | Number | Cited by rules |
19
+ |---|---|---|
20
+ | 《电力安全工作规程 发电厂和变电站电气部分》 | GB 26860—2011 | PT-001, PT-002, PT-003, PT-004, PT-005, PT-006, PT-007 |
2
21
 
3
22
  **Boundary:** this plugin checks one **电力工作票** for what a form can be held to — that the required
4
23
  boxes are filled, that 签发 / 许可 / 终结 happened in an order that is physically possible, that 延期
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "dsh-power-ticket-check",
3
- "version": "0.2.1",
3
+ "version": "0.2.2",
4
4
  "description": "电力工作票要素齐备性与签发许可顺序核对(依据现行电力安全工作规程,仅提示差异,不作出定性结论)",
5
5
  "type": "module",
6
6
  "main": "lib/index.mjs",