dsh-bid-qual-check — Bidder qualification condition register check

English · 简体中文 · Español · Português · हिन्दी

What it is — Bidder qualification condition register check. It returns a list of what is inconsistent, where, and what to fix. Who it is for — bid specialists and qualification reviewers; no command line required. What you give it — the source material the check works on (a table, register or document); the original is never modified. Excel can be converted to JSON/YAML first, in chat if the platform supports it. What it does not do — no compliance verdict, no liability finding, no replacement for the reviewer; differences only. How to start — search "Tender Compliance Suite" in WorkBuddy / Coze (this check is one part of it; availability as listed); or: dsh plugin --profile <name> add dsh-bid-qual-check

dsh-bid-qual-check reads one bidder qualification condition register — the 投标人资格条件核对表, its header plus one row per qualification condition — and checks that register's own closed loop: that each condition records its requirement, that the bidder's actual position is recorded, that evidence is attached, that the verdict comes from your vocabulary, that a pass/fail item records position, evidence and verdict together, that the register names its project and bidder, that condition numbers are unique, and that no unreplaced placeholder survives in the requirement column.

Install

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

What it looks like

Workflow overview: document → rule pack → findings. The examples below use the real command surface.

What it answers

Examples

The table below is the example set: the first row is the detailed walkthrough, the remaining rows are short cases.

Detailed output

Tool bid_qual_check

Input

{"rows":[{"序号":"1","资格条件":"","类别":"资格条件","要求内容":"", ...}]}

Output

{
  "id": "dsh-bid-qual-check.BQ-001.de09b5a6",
  "ruleId": "BQ-001",
  "severity": "warn",
  "locator": {
    "row": 1,
    "field": "required"
  },
  "found": "第 1 行 required、criterion 都为空",
  "expected": "required、criterion 至少应填写一项",
  "fix": "补填资格条件与要求内容；本条只核对是否填写，不判断该条件是否应当设置"
}

Observed from dsh-bid-qual-check/tests/fixtures/BQ-001/BQ-001-unsafe.json; dsh-bid-qual-check/tests/fixtures/BQ-001/cases.json; dsh-bid-qual-check/rules/bid-qual-check.yaml; dsh-bid-qual-check/tests/index.test.ts

| You ask | What it answers | |---|---| | One row has both 资格条件 and 要求内容 blank. Is that reported? | Yes. BQ-001 holds every row to at least one of those two columns and reports the row when both are empty. It checks that something was written, not whether that condition is lawful or should have been set at all — that is a review of the tender document itself. | | A condition has its 投标人情况 column empty, and no 证明材料 either. | Two findings: BQ-002 reports the row for the blank 投标人情况 (actual) and BQ-003 for the blank 证明材料 (evidence). Both check only that the cell is filled — not whether the position satisfies the condition, nor whether the document is valid, current or matches the original, which needs the originals and the committee's call. A column that is present with every cell blank is still reported row by row; a material without that column puts the rule in skipped instead of passing silently. | | The 核对结论 column is blank on a row. Does BQ-004 report it? | No — BQ-004 tests only the values that are written and skips blank cells. Its values list ships empty, so out of the box the rule reports itself in skipped; once you configure your institution's vocabulary in values (符合 / 不符合 / 需澄清, say), a value outside that list is reported row by row. It checks that the value is in your vocabulary, not that the conclusion is correct, and no value ever invalidates a bid. The rule is capped at info, because the vocabulary is your institution's to set. | | A row's 是否否决项 cell reads 是, but 投标人情况 or 证明材料 is missing. | BQ-005 requires 投标人情况, 证明材料 and 核对结论 together on every row whose 是否否决项 cell matches the configured marks (是, Y, yes, true, 否决项, √ by default) and reports the row with what is missing. Which conditions count as pass/fail comes entirely from the tender document and from that column, never from a built-in list. If no row carries such a mark, the rule reports itself in skipped instead of passing — and it never decides whether the bid should be rejected. | | The register's header names the tender number, but not the project or the bidder. | BQ-006 reports the header once and names what is missing: project (the project name) or bidder (the bidder name). It only checks that the header declares those two parties — it does not check the tender number or the check date, and adding the verdict vocabulary to this rule would not help, because that is controlled by BQ-004's values. | | This register was copied from a template: two rows share the number 3, and one 要求内容 cell still reads 待填. | BQ-007 reports the repeated 序号 (the comparison ignores whitespace, so 3 and 3 are the same number), and if no row carries a number at all it reports itself in skipped instead of passing. BQ-008 reports the residual placeholder in 要求内容 — 【, 】, {{, }}, XXX, 待填, 待补充, TBD, 示例 and the rest of its terms list, which you can narrow. Both checks are literal: neither judges whether the requirement itself is right, and a requirement genuinely quoted with an XXX in it is reported too. |

Standards it follows

| Document | Number | Cited by rules | |---|---|---| | 《中华人民共和国招标投标法》 | 1999年8月30日通过，2017年12月27日修正（全国人大常委会《关于修改〈中华人民共和国招标投标法〉、〈中华人民共和国计量法〉的决定》），本法自2000年1月1日起施行 | BQ-001, BQ-002, BQ-003, BQ-004, BQ-006, BQ-007, BQ-008 | | 《中华人民共和国招标投标法实施条例》 | 国务院令第613号（2011 年 12 月 20 日公布，2017 年 3 月 1 日修订，自 2012 年 2 月 1 日起施行） | BQ-005 |

Boundary: this plugin checks a 投标人资格条件核对表 for the closed loop a checklist can be held to — that every condition records its requirement and the bidder's actual position, that evidence is attached, that verdicts come from your vocabulary, that a pass/fail item records all three, that the table names its project and bidder, that numbers are unique, and that no placeholder survives. It does not decide whether a bidder is qualified, whether qualification fails, or whether a bid should be rejected. That is the qualification committee's call, made against the evidence originals and the tender document's conditions.

⚠️ Read this before trusting a citation in the report

excerpt status is per rule, not uniform. Some rules quote the clause verbatim (kind: direct), some are derived from the principle of the cited articles (kind: derived-from-principle, capped at warn), and some use thresholds your institution configures (kind: institutional-configuration, capped at info). The pack never paraphrases a quotation: when the text was not obtained, the excerpt field says so and the reasoning lives in note; a test asserts that no rule claims a quotation it does not have. For any rule still marked as not obtained, replace the excerpt with the real clause and raise kind to direct once the text is in hand.

The conclusion is the reviewer's: this plugin lists differences it can point to in the material and does not decide facts or compliance.

Compatibility

| Surface | Status | |---|---| | Harness | Peer range >=0.1.2-rc.1 <0.2.0 \|\| >=0.2.0-0 <0.3.0 — verified to accept both 0.2.0-rc.2 and 0.2.1-rc.2. engines.dsh is declared as >=0.2.1-0 <0.3.0 and is enforced by the host since 0.2.1 | | Node | ^22.19.0 || >=24.0.0 | | Platforms | All (plain ESM; no native code, no network, no model call) | | Tool mode | Works in native and ptc; for several bidders use ptc |

What it does

Registers the bid_qual_check tool. It reads one qualification register — the package header plus one row per condition — applies a versioned rule pack, and returns a report.

| Rule | Check | Severity | Basis kind | |---|---|---|---| | BQ-001 | every condition records its requirement | warn | direct | | BQ-002 | every condition records the bidder's actual position | warn | direct | | BQ-003 | every condition attaches evidence | warn | direct | | BQ-004 | the verdict comes from your vocabulary (off by default) | info | local | | BQ-005 | a pass/fail item records position, evidence and verdict | warn | principle | | BQ-006 | the table names its project and bidder | warn | principle | | BQ-007 | condition numbers are unique | warn | principle | | BQ-008 | the requirement column holds no unreplaced placeholder | warn | principle |

Configuration

| Key | Type | Default | Description | |---|---|---|---| | rulesFile | string | rules/bid-qual-check.yaml | Rule-pack path, relative to the package root | | disabledRules | string[] | [] | Rule ids to stop running; each appears in skipped | | onlyRules | string[] | [] | Run only these rule ids; empty runs every rule | | skipNotes | string | "" | Note appended to every skipped reason | | timeoutMs | number | 120000 | Cooperative tool timeout budget |

Rule-level parameters worth knowing:

• BQ-004 values — your verdict vocabulary, e.g. [符合, 不符合, 需澄清]. Empty means no check.
• BQ-005 conditionValues — the values in your 是否否决项 column that mark an item as pass/fail, by default [是, Y, yes, true, 否决项, √].
• BQ-008 terms — the placeholders to look for.

Material format

The tool accepts JSON or YAML:

project: 某某工程施工招标
tenderNo: ZB-2026-018
bidder: 某某建设有限公司
rows:
  - { 序号: '1', 资格条件: 施工资质等级, 要求内容: 建筑工程施工总承包二级及以上,
      投标人情况: 持有建筑工程施工总承包二级资质，证书在有效期内,
      证明材料: 资质证书复印件，资格文件第 12 页, 核对结论: 符合, 是否否决项: 是, 核对人: 李工 }

Column names are matched case-insensitively and ignoring spaces, underscores and hyphens; the register's own column names are kept, so a finding names the column it read.

Rule sources

Rule data lives in rules/bid-qual-check.yaml. The pack's header states the citation gap in full, and each rule's note repeats the part that matters for that rule. The load-time guard that normally enforces "an excerpt must be a real quotation of at least eight characters" cannot tell a quotation from a description — so this pack leans on the header, the per-rule notes and a test that asserts every excerpt admits the gap.

Troubleshooting

• BQ-004 or BQ-005 reports itself as skipped. The verdict vocabulary is empty, or no row is marked as a pass/fail item. Both depend on your project, and the plugin will not guess them.
• BQ-002 fires on a condition I consider self-evident. A blank actual-position cell means "not checked", which is the one thing a qualification register must never be. Record the position, even if it is obvious.
• BQ-005 fires on a pass/fail item missing evidence. That is the check: a pass/fail item without all three records cannot be defended after the fact.
• BQ-008 fires on a requirement I copied verbatim. The word XXX or 待填 really is in the cell. Narrow terms, or fix the register.
• The plugin installs but the tool never appears. Check that main resolves to lib/index.mjs and that pnpm run build produced it; a wrong main makes the loader skip the entry silently.
• dsh plugin add refuses the package as incompatible. The peer range covers 0.1.x and 0.2.x; if your runtime sits outside it, grant an explicit exemption: dsh plugin --profile <name> allow-version [email protected] --dsh-version <runtime> --accept-risk
• check reports manifest-peers as failed. The static checker compares against a hard-coded peer range that predates the 0.2 line. The runtime enforces peer compatibility at install time, so the declared range is the correct one; this is a known upstream issue in 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-bid-qual-check   # refresh src/shared from ../_shared

The plugin is data-only: src/model.ts declares the table shape, the shared kit supplies the reader and the check engine, and the rule pack declares every check.

PerryLink DSH Plugin Family

Full family index: choose a checker by material and all plugins. This repository is one of them.

License

Apache License 2.0 © 2026 dsh-bid-qual-check contributors.