dsh-contract-stance 0.2.0 → 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 ADDED
@@ -0,0 +1,37 @@
1
+ # Changelog
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
+
20
+ ## 0.2.1
21
+
22
+ - Ship `CHANGELOG.md` and `SECURITY.md` inside the package. `files` is an
23
+ allowlist and neither was on it, so no release note had ever reached anyone
24
+ who installed this package, and npm had no changelog section to show.
25
+ ## 0.2.0
26
+
27
+ - Release infrastructure brought to the family standard: `verify:self-contained`,
28
+ `check:lockfile`, `check:readmes` and `check:citations` gates, a `prepublishOnly` that
29
+ re-runs the whole chain, SECURITY.md, dependabot, and the OpenSSF Scorecard workflow.
30
+ - `check:citations` enforces the rule this pack's own header states: every `excerpt`
31
+ must be a verbatim quotation, findable in `rules/evidence/`. Rules that are not
32
+ traceable yet are listed in `rules/citations-baseline.json`, and that file can only
33
+ shrink - anything new has to be sourced before it can land.
34
+ - The README install command now names the published package instead of a local tarball.
35
+ - Five-language READMEs hold the same section count and the same configuration keys.
36
+ - Rule pack: 7 rules across CS-001..CS-007.
37
+ - Licensed Apache-2.0.
package/README-es.md CHANGED
@@ -1,4 +1,23 @@
1
- # dsh-contract-stance
1
+ # dsh-contract-stance — Verificación de la integridad y la coherencia interna del registro de posturas sobre cláusulas contractuales
2
+
3
+ `dsh-contract-stance` lee un registro de posturas sobre cláusulas —la cabecera del contrato más una fila por cláusula— y comprueba la integridad y la coherencia interna de ese registro: que se recoja el texto de cada cláusula, que su postura proceda de su propio vocabulario y que la calificación de riesgo también, que una cláusula irrenunciable registre tanto un límite de concesión como un responsable, que los números de cláusula sean únicos, que el registro declare el contrato y su propia parte y que no quede ningún marcador de plantilla sin sustituir en el texto de la cláusula.
4
+
5
+ ## Qué responde
6
+
7
+ | Usted pregunta | Qué responde |
8
+ |---|---|
9
+ | Una fila tiene tema, pero la columna del texto de la cláusula está vacía. ¿Se informa de eso? | Sí. `CS-001` exige la columna `text` en todas las filas: sin el texto no se puede comprobar a qué redacción se refiere la postura. La regla solo comprueba que el texto esté recogido; no juzga si la cláusula debe aceptarse ni si entraña riesgo jurídico. |
10
+ | La postura y la calificación de riesgo están rellenas, pero todas las filas vuelven como `skipped`. ¿Por qué? | Porque las dos listas de valores vienen vacías de fábrica. `CS-002` solo acepta una postura de la lista configurada para él, y `CS-003` hace lo mismo con la calificación de riesgo; sin lista configurada ninguna de las dos reglas puede ejecutarse, así que cada una se informa en `skipped` en lugar de pasar en silencio. `CS-002` solo comprueba que el valor esté en su lista, no que la postura sea adecuada; `CS-003` solo comprueba que esté en la lista, no cuán alto es el riesgo real de esa cláusula. |
11
+ | Una cláusula está marcada como irrenunciable, pero nadie escribió hasta dónde se puede ceder ni quién decide. | `CS-004` lee la propia columna de irrenunciable del registro: cuando la fila lleva `是`, `Y`, `yes`, `true`, `必保` o `√` (valores fijados por `conditionValues`) exige que se rellenen las columnas `fallback` y `owner`. Solo comprueba que ambas estén rellenas, no si el límite de concesión es razonable; qué cláusulas son irrenunciables depende por completo del proyecto y la regla no lo decide. |
12
+ | El mismo número de cláusula aparece en dos filas, una por borrador de negociación. ¿Es un hallazgo? | `CS-005` informa de un número de cláusula repetido, comparando sin tener en cuenta los espacios. Un número repetido impide señalar con precisión una sola cláusula. Que una cláusula aparezca una vez por borrador es una forma normal: distíngala en la columna de versión en lugar de reutilizar el número. Ninguna cláusula exige que los números sean únicos: la unicidad es lo que hace referenciable el registro. |
13
+ | La cabecera no dice de qué contrato se trata ni cuál es nuestra parte. | `CS-006` exige que la cabecera del material declare `contractName` y `party`: sin esos dos datos la postura no puede rastrearse hasta una operación y una parte concretas. Si su formulario tiene una columna de versión para los borradores, añádala a los `fields` de esa regla. La regla solo comprueba que la cabecera declare los dos. |
14
+ | El texto de la cláusula se copió tal cual de un modelo y todavía contiene 【】 o TBD. | `CS-007` informa del texto de la columna `text` que aún contiene alguno de sus términos de plantilla: `【`, `】`, `{{`, `}}`, `XXX`, `xxx`, `待填`, `待补充`, `TBD`, `todo`, `示例`, ajustables a su propia plantilla. Remitirse a un modelo está permitido; el peligro es que un marcador de plantilla se lea como redacción ya revisada. La regla solo busca esos términos en la columna de texto, no examina la cláusula. |
15
+
16
+ ## Normas que sigue
17
+
18
+ | Documento | Número | Reglas que lo citan |
19
+ |---|---|---|
20
+ | 《中华人民共和国民法典》 | 现行版本与条号本次未核实 | CS-001, CS-002, CS-003, CS-004, CS-005, CS-006, CS-007 |
2
21
 
3
22
  **Boundary:** this plugin checks a **合同条款立场台账** for what a register can be held to — that each clause's
4
23
  text is recorded, that your stance comes from your vocabulary, that the risk grade does too, that a must-have
package/README-hi.md CHANGED
@@ -1,4 +1,23 @@
1
- # dsh-contract-stance
1
+ # dsh-contract-stance — संविदा खंड पक्ष-रुख रजिस्टर की पूर्णता और आंतरिक सुसंगति की जाँच
2
+
3
+ `dsh-contract-stance` संविदा खंडों के पक्ष-रुख रजिस्टर को पढ़ता है — संविदा का हेडर और प्रत्येक खंड की एक पंक्ति — और उसी रजिस्टर की पूर्णता तथा आंतरिक सुसंगति की जाँच करता है: क्या प्रत्येक खंड का मूल पाठ दर्ज है, क्या आपका पक्ष-रुख आपकी अपनी शब्दावली से लिया गया है और जोखिम-श्रेणी भी, क्या अनिवार्य खंड में छूट की सीमा और ज़िम्मेदार व्यक्ति दोनों दर्ज हैं, क्या खंड-संख्याएँ अद्वितीय हैं, क्या रजिस्टर संविदा और आपके पक्ष का उल्लेख करता है, और क्या खंड के पाठ में कोई अपरिवर्तित टेम्पलेट प्लेसहोल्डर शेष नहीं है।
4
+
5
+ ## यह किन सवालों का जवाब देता है
6
+
7
+ | आपका सवाल | इसका जवाब |
8
+ |---|---|
9
+ | किसी पंक्ति में विषय भरा है, पर खंड-पाठ का कॉलम खाली है। क्या यह दर्ज होता है? | हाँ। `CS-001` हर पंक्ति में `text` कॉलम की अपेक्षा करता है: पाठ के बिना यह जाँचा ही नहीं जा सकता कि पक्ष-रुख किस शब्दावली पर है। नियम केवल यह देखता है कि पाठ दर्ज है; यह नहीं आँकता कि खंड स्वीकार्य है या उसमें विधिक जोखिम है। |
10
+ | पक्ष-रुख और जोखिम-श्रेणी दोनों भरे हैं, फिर भी हर पंक्ति `skipped` आती है। क्यों? | क्योंकि दोनों मान-सूचियाँ फ़ैक्टरी से खाली आती हैं। `CS-002` पक्ष-रुख केवल उसके लिए कॉन्फ़िगर की गई सूची से स्वीकार करता है, और `CS-003` जोखिम-श्रेणी के साथ वही करता है; सूची कॉन्फ़िगर न हो तो कोई भी नियम चल नहीं सकता, इसलिए दोनों चुपचाप पास होने के बजाय स्वयं को `skipped` में दर्ज करते हैं। `CS-002` केवल यह देखता है कि मान आपकी सूची में है, यह नहीं कि पक्ष-रुख उपयुक्त है; `CS-003` केवल यह देखता है कि मान सूची में है, यह नहीं कि उस खंड का वास्तविक जोखिम कितना ऊँचा है। |
11
+ | एक खंड अनिवार्य चिह्नित है, पर कहीं नहीं लिखा कि कहाँ तक छूट दी जा सकती है और निर्णय कौन लेगा। | `CS-004` रजिस्टर के अपने अनिवार्य-कॉलम को पढ़ता है: जब उसमें `是`, `Y`, `yes`, `true`, `必保` या `√` हो (मान `conditionValues` से तय होते हैं), तो `fallback` और `owner` दोनों कॉलम भरे होने चाहिए। यह केवल यह देखता है कि ये दोनों भरे हैं, यह नहीं कि छूट की सीमा उचित है; कौन-से खंड अनिवार्य हैं, यह पूरी तरह परियोजना पर निर्भर है और नियम इसका निर्णय नहीं करता। |
12
+ | एक ही खंड-संख्या दो पंक्तियों में है, हर मसौदे के लिए एक। क्या यह दोष है? | `CS-005` दोहराई गई खंड-संख्या दर्ज करता है और तुलना में रिक्त स्थान छोड़ देता है। दोहरी संख्या से किसी एक खंड की सटीक पहचान नहीं हो पाती। एक खंड का प्रति-मसौदा एक बार आना सामान्य है: संख्या दोहराने के बजाय संस्करण कॉलम में उसे अलग दिखाएँ। कोई खंड यह नहीं कहता कि संख्याएँ अद्वितीय हों — अद्वितीयता रजिस्टर की संदर्भ-योग्यता के लिए है। |
13
+ | हेडर में नहीं लिखा कि यह कौन-सी संविदा है और हमारा पक्ष कौन है। | `CS-006` अपेक्षा करता है कि सामग्री का हेडर `contractName` और `party` दर्ज करे: इन दोनों के बिना पक्ष-रुख किसी विशेष सौदे और पक्ष तक नहीं जोड़ा जा सकता। यदि आपके फ़ॉर्म में मसौदों के लिए संस्करण कॉलम है, तो उसे उस नियम के `fields` में जोड़ दें। नियम केवल यह देखता है कि हेडर ये दोनों घोषित करता है। |
14
+ | खंड-पाठ सीधे किसी नमूना-प्रारूप से कॉपी किया गया है और उसमें अब भी 【】 या TBD है। | `CS-007` ऐसे पाठ को दर्ज करता है जिसमें उसके प्लेसहोल्डर शब्द अब भी हैं: `【`, `】`, `{{`, `}}`, `XXX`, `xxx`, `待填`, `待补充`, `TBD`, `todo`, `示例` — इन्हें अपने प्रारूप के अनुसार बदला जा सकता है। नमूना-प्रारूप देखना अनुमत है; ख़तरा यह है कि टेम्पलेट का प्लेसहोल्डर पहले से समीक्षित शब्दावली मान लिया जाए। नियम केवल पाठ-कॉलम में इन शब्दों को खोजता है, खंड की समीक्षा नहीं करता। |
15
+
16
+ ## यह किन मानकों पर आधारित है
17
+
18
+ | दस्तावेज़ | संख्यांक | इन्हें उद्धृत करने वाले नियम |
19
+ |---|---|---|
20
+ | 《中华人民共和国民法典》 | 现行版本与条号本次未核实 | CS-001, CS-002, CS-003, CS-004, CS-005, CS-006, CS-007 |
2
21
 
3
22
  **Boundary:** this plugin checks a **合同条款立场台账** for what a register can be held to — that each clause's
4
23
  text is recorded, that your stance comes from your vocabulary, that the risk grade does too, that a must-have
package/README-pt.md CHANGED
@@ -1,4 +1,23 @@
1
- # dsh-contract-stance
1
+ # dsh-contract-stance — Verificação da completude e da coerência interna do registo de posições sobre cláusulas contratuais
2
+
3
+ `dsh-contract-stance` lê um registo de posições sobre cláusulas —o cabeçalho do contrato mais uma linha por cláusula— e verifica a completude e a coerência interna desse registo: se o texto de cada cláusula está registado, se a sua posição vem do seu próprio vocabulário e se a classificação de risco também, se uma cláusula irrenunciável regista tanto um limite de cedência como um responsável, se os números de cláusula são únicos, se o registo declara o contrato e a sua própria parte e se não resta nenhum marcador de modelo por substituir no texto da cláusula.
4
+
5
+ ## O que ele responde
6
+
7
+ | Você pergunta | O que ele responde |
8
+ |---|---|
9
+ | Uma linha tem tema, mas a coluna do texto da cláusula está vazia. Isso é reportado? | Sim. `CS-001` exige a coluna `text` em todas as linhas: sem o texto não é possível verificar a que redação se refere a posição. A regra verifica apenas que o texto está registado; não julga se a cláusula deve ser aceite nem se envolve risco jurídico. |
10
+ | A posição e a classificação de risco estão preenchidas, mas todas as linhas voltam como `skipped`. Porquê? | Porque as duas listas de valores vêm vazias de fábrica. `CS-002` só aceita uma posição da lista configurada para ele, e `CS-003` faz o mesmo com a classificação de risco; sem lista configurada nenhuma das regras consegue correr, por isso cada uma se reporta em `skipped` em vez de passar em silêncio. `CS-002` verifica apenas se o valor consta da sua lista, não se a posição é adequada; `CS-003` verifica apenas se consta da lista, não quão alto é o risco real dessa cláusula. |
11
+ | Uma cláusula está marcada como irrenunciável, mas ninguém escreveu até onde se pode ceder nem quem decide. | `CS-004` lê a própria coluna de irrenunciável do registo: quando a linha traz `是`, `Y`, `yes`, `true`, `必保` ou `√` (valores definidos por `conditionValues`) exige que as colunas `fallback` e `owner` estejam preenchidas. Verifica apenas que ambas estão preenchidas, não se o limite de cedência é razoável; que cláusulas são irrenunciáveis depende inteiramente do projeto e a regra não o decide. |
12
+ | O mesmo número de cláusula aparece em duas linhas, uma por minuta de negociação. É um achado? | `CS-005` reporta um número de cláusula repetido, comparando sem considerar os espaços. Um número repetido impede apontar com precisão uma única cláusula. Uma cláusula surgir uma vez por minuta é uma forma normal: distinga-a na coluna de versão em vez de reutilizar o número. Nenhuma cláusula exige que os números sejam únicos: a unicidade é o que torna o registo referenciável. |
13
+ | O cabeçalho não diz de que contrato se trata nem qual é a nossa parte. | `CS-006` exige que o cabeçalho do material declare `contractName` e `party`: sem esses dois dados a posição não pode ser rastreada até uma operação e uma parte concretas. Se o seu formulário tiver uma coluna de versão para as minutas, acrescente-a aos `fields` dessa regra. A regra verifica apenas que o cabeçalho declara os dois. |
14
+ | O texto da cláusula foi copiado tal e qual de um modelo e ainda contém 【】 ou TBD. | `CS-007` reporta o texto da coluna `text` que ainda contém algum dos seus termos de modelo: `【`, `】`, `{{`, `}}`, `XXX`, `xxx`, `待填`, `待补充`, `TBD`, `todo`, `示例`, ajustáveis ao seu próprio modelo. Recorrer a um modelo é permitido; o perigo é um marcador de modelo ser lido como redação já revista. A regra procura apenas esses termos na coluna de texto, não examina a cláusula. |
15
+
16
+ ## Normas que segue
17
+
18
+ | Documento | Número | Regras que o citam |
19
+ |---|---|---|
20
+ | 《中华人民共和国民法典》 | 现行版本与条号本次未核实 | CS-001, CS-002, CS-003, CS-004, CS-005, CS-006, CS-007 |
2
21
 
3
22
  **Boundary:** this plugin checks a **合同条款立场台账** for what a register can be held to — that each clause's
4
23
  text is recorded, that your stance comes from your vocabulary, that the risk grade does too, that a must-have
package/README-zh.md CHANGED
@@ -1,4 +1,23 @@
1
- # dsh-contract-stance
1
+ # dsh-contract-stance — 合同条款立场台账核对
2
+
3
+ `dsh-contract-stance` 读取一份合同条款立场台账——合同表头加每条条款一行——核对这份台账自身的齐备与自洽:条款是否摘录原文、本方立场是否使用本机构口径的取值、风险等级是否同样在册、必保条款是否同时写明退让底线与责任人、条款号是否唯一、台账是否声明合同与本方主体、条款原文是否残留未替换的占位符。
4
+
5
+ ## 它回答什么问题
6
+
7
+ | 你会问 | 它怎么答 |
8
+ |---|---|
9
+ | 某行只填了条款主题,条款原文栏是空的,会被报出吗? | 会。`CS-001` 要求每行都填写 `text` 栏:没有原文,就无法核对立场是针对什么措辞作出的。本条只核对原文栏是否填写,不判断该条款是否应当接受、是否存在法律风险。 |
10
+ | 立场栏与风险等级栏都填了,为什么每行都报 `skipped`? | 因为两份取值清单出厂都是空的。`CS-002` 只接受为本机构配置的清单里的 `stance` 取值,`CS-003` 对 `riskLevel` 同理;未配置清单时两条规则都无法执行,于是各自报告 `skipped`,而不是静默通过。`CS-002` 只核对所填值是否在册,不判断该立场是否恰当;`CS-003` 只核对是否在册,不判断该条款的实际风险有多高。 |
11
+ | 某条标了「必保」,但没有写可以让到哪里、由谁决策。 | `CS-004` 读取台账自己的「是否必保」栏:该栏取值为 `是`、`Y`、`yes`、`true`、`必保` 或 `√`(由 `conditionValues` 配置)时,要求 `fallback` 与 `owner` 两栏都填写。它只核对这两栏是否填写,不判断该退让底线是否合理;哪些条款属于必保条款完全取决于本项目,本条不作判定。 |
12
+ | 同一个条款号在两行各出现一次,一行对应一个谈判稿版本,算问题吗? | `CS-005` 会报出重复的条款号,比较时忽略空白字符。条款号重复会让人无法准确指认是哪一条;同一条款在多个谈判稿版本中各有一行是正常情形,请在版本栏加以区分,而不是重复使用条款号。没有任何条文规定条款号不得重复,唯一性只是台账可指认性的需要。 |
13
+ | 表头没有写明这是哪份合同、本方是哪个主体。 | `CS-006` 要求材料顶层写明 `contractName`(合同名称)与 `party`(本方名称):不写明这两项,立场就无法追溯到具体的交易与主体。若本机构表式另有版本栏,把该栏加进本条的 `fields` 即可。本条只核对表头是否声明了这两项。 |
14
+ | 条款原文是从示范文本直接抄来的,里面还留着【】或 TBD。 | `CS-007` 会报出 `text` 栏仍含占位符术语的行,术语清单为 `【`、`】`、`{{`、`}}`、`XXX`、`xxx`、`待填`、`待补充`、`TBD`、`todo`、`示例`,可按本机构模板调整。参照示范文本订立合同是允许的,但照抄模板留下的占位符会让人误以为已经审阅了实际条款。本条只核对原文栏是否残留这些术语,不判断条款本身。 |
15
+
16
+ ## 依据的标准
17
+
18
+ | 文件 | 文号 | 引用它的规则 |
19
+ |---|---|---|
20
+ | 《中华人民共和国民法典》 | 现行版本与条号本次未核实 | CS-001, CS-002, CS-003, CS-004, CS-005, CS-006, CS-007 |
2
21
 
3
22
  **Boundary:** this plugin checks a **合同条款立场台账** for what a register can be held to — that each clause's
4
23
  text is recorded, that your stance comes from your vocabulary, that the risk grade does too, that a must-have
package/README.md CHANGED
@@ -1,4 +1,23 @@
1
- # dsh-contract-stance
1
+ # dsh-contract-stance — Contract clause stance register completeness and self-consistency check
2
+
3
+ `dsh-contract-stance` reads one clause-stance register — the contract header plus one row per clause — and checks that register's own completeness and self-consistency: that each clause's text is recorded, that your stance comes from your own vocabulary, that the risk grade does too, that a must-have clause records both a fallback position and an owner, that clause numbers are unique, that the register names the contract and your side, and that no unreplaced placeholder survives in the clause text.
4
+
5
+ ## What it answers
6
+
7
+ | You ask | What it answers |
8
+ |---|---|
9
+ | A clause row carries a topic, but the clause-text column is blank. Is that reported? | Yes. `CS-001` requires the `text` column on every row: without the wording, a stance cannot be checked against what it is a stance on. The rule checks only that the wording is recorded — it does not judge whether the clause should be accepted or whether it carries legal risk. |
10
+ | The stance and the risk grade are both filled in, yet every row comes back as `skipped`. Why? | Both value lists ship empty. `CS-002` accepts a stance only from the list configured for it, and `CS-003` does the same for the risk grade; with no list configured neither rule can run, so each reports itself in `skipped` rather than passing quietly. `CS-002` checks only that the value is on your list, not that the stance is appropriate; `CS-003` checks only that the grade is on your list, not how high the actual risk of that clause is. |
11
+ | A clause is marked must-have, but nobody wrote how far we can concede or who decides. | `CS-004` reads the register's own must-have column: for a row marked `是`, `Y`, `yes`, `true`, `必保` or `√` (the values set by `conditionValues`) it requires both the `fallback` and the `owner` column to be filled. It checks only that those two are filled, not whether the fallback is reasonable; which clauses count as must-have depends entirely on the project, and the rule never decides that. |
12
+ | The same clause number appears on two rows, one per negotiating draft. Is that a finding? | `CS-005` reports a repeated clause number, comparing with whitespace ignored. A repeated number makes it impossible to point at one clause precisely. One clause appearing once per draft is a normal shape: distinguish it in the version column instead of reusing the number. No clause requires clause numbers to be unique — uniqueness is what makes the register referable. |
13
+ | The header does not say which contract this is, nor which side we are. | `CS-006` requires the material's header to state `contractName` and `party`: without those two, a stance cannot be traced to a specific transaction and party. If your form carries a version column for negotiating drafts, add it to that rule's `fields`. The rule only checks that the header declares those two. |
14
+ | The clause text was copied straight from a model form and still contains 【】 or TBD. | `CS-007` reports clause text that still holds any of its placeholder terms — `【`, `】`, `{{`, `}}`, `XXX`, `xxx`, `待填`, `待补充`, `TBD`, `todo`, `示例` — which can be adjusted to your own template. Referring to a model form is allowed; the danger is that a template placeholder is read as wording already reviewed. The rule only looks for those terms in the `text` column, not at the clause itself. |
15
+
16
+ ## Standards it follows
17
+
18
+ | Document | Number | Cited by rules |
19
+ |---|---|---|
20
+ | 《中华人民共和国民法典》 | 现行版本与条号本次未核实 | CS-001, CS-002, CS-003, CS-004, CS-005, CS-006, CS-007 |
2
21
 
3
22
  **Boundary:** this plugin checks a **合同条款立场台账** for what a register can be held to — that each clause's
4
23
  text is recorded, that your stance comes from your vocabulary, that the risk grade does too, that a must-have
package/SECURITY.md ADDED
@@ -0,0 +1,39 @@
1
+ # Security Policy
2
+
3
+ ## Reporting a vulnerability
4
+
5
+ Please report security vulnerabilities **privately** through GitHub's private
6
+ vulnerability reporting:
7
+
8
+ **Security → Report a vulnerability** at
9
+ https://github.com/PerryLink/dsh-contract-stance/security/advisories/new
10
+
11
+ Do **not** open a public issue for security findings.
12
+
13
+ Before reporting, **sanitize everything you paste**: remove tokens, API keys,
14
+ credentials, authorization headers, session contents, and personal data. Logs
15
+ without secrets only.
16
+
17
+ ## Scope note
18
+
19
+ This plugin is an offline checker. It reads the material you hand it and
20
+ compares it against a versioned rule pack; it makes no network calls and no
21
+ model calls, and it stores nothing.
22
+
23
+ ## What to include
24
+
25
+ - affected package version (and DeepSeek Harness runtime version)
26
+ - a minimal reproduction
27
+ - your impact assessment
28
+
29
+ ## Response expectations
30
+
31
+ - acknowledgement within **7 days**
32
+ - status updates at least every **14 days** until resolution
33
+ - coordinated disclosure: the fix and advisory are prepared first; the finding
34
+ is disclosed publicly after the fix ships
35
+
36
+ ## Credits and disclosure
37
+
38
+ - reporters are credited in the advisory and CHANGELOG unless they ask to stay anonymous
39
+ - advisories follow GitHub's advisory workflow and are published together with the fix
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "dsh-contract-stance",
3
- "version": "0.2.0",
3
+ "version": "0.2.2",
4
4
  "description": "合同条款立场台账核对(按立场、风险等级与退让底线核对台账自洽,仅提示差异,不作出定性结论)",
5
5
  "type": "module",
6
6
  "main": "lib/index.mjs",
@@ -23,7 +23,9 @@
23
23
  "README-hi.md",
24
24
  "locale/*.json",
25
25
  "icon.svg",
26
- "rules"
26
+ "rules",
27
+ "CHANGELOG.md",
28
+ "SECURITY.md"
27
29
  ],
28
30
  "scripts": {
29
31
  "build": "tsdown",
@@ -32,7 +34,7 @@
32
34
  "verify:self-contained": "node scripts/verify-self-contained.mjs",
33
35
  "check:lockfile": "node scripts/check-lockfile-drift.mjs",
34
36
  "check:readmes": "node scripts/check-readme-sync.mjs",
35
- "prepublishOnly": "pnpm run typecheck && pnpm test && pnpm run build && pnpm run verify:self-contained && pnpm run check:readmes && pnpm run check:citations",
37
+ "prepublishOnly": "pnpm run typecheck && pnpm test && pnpm run build && pnpm run verify:self-contained && pnpm run check:lockfile && pnpm run check:readmes && pnpm run check:citations",
36
38
  "prepare": "tsdown",
37
39
  "check:citations": "node scripts/check-citations.mjs"
38
40
  },