dsh-fmea-table-check

dsh plugin --profile web add dsh-fmea-table-check

dsh-fmea-table-check — FMEA worksheet element completeness and risk priority number consistency check

[English](README.md) · [简体中文](README-zh.md) · [Español](README-es.md) · [Português](README-pt.md) · [हिन्दी](README-hi.md)

<!-- topblock:v1 -->

What it is — FMEA worksheet element completeness and risk priority number consistency check. It returns a list of what is inconsistent, where, and what to fix.

Who it is for — quality and process engineers; 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 "Professional Document Check Suite" in WorkBuddy / Coze (the full set; this check is one part of it; availability as listed); or:

dsh plugin --profile <name> add dsh-fmea-table-check

<!-- /topblock:v1 -->



dsh-fmea-table-check reads one FMEA worksheet — rows keyed by the sheet's own column names, in Chinese or English — and checks in it what a sheet can be held to mechanically: that the analysis chain is recorded, that the severity, occurrence and detection scores are operable numbers, that the risk priority number equals their product, that a high-risk row carries an action with an owner and a due date, that action statuses come from your own vocabulary, and that no template placeholder survives in the failure mode.

Install

dsh plugin --profile <name> add dsh-fmea-table-check
dsh --profile <name> --dump-config | grep 'dsh-fmea-table-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 fmea_table_check

Input

~~~json

{"rows":[{"失效模式":"密封面泄漏","严重度":"8","频度":"4","探测度":"3","风险优先数":"100"}]}

~~~

Output

~~~json

{

"id": "dsh-fmea-table-check.FM-003.de09b5a6",

"ruleId": "FM-003",

"severity": "warn",

"locator": {

"field": "rpn",

"row": 1

},

"found": "第 1 行「rpn」填报 100，而 8 × 4 × 3 = 96",

"expected": "「rpn」应等于 severity × occurrence × detection",

"fix": "核对是否抄错或漏改；本条只做算术核对，不判断各因子是否正确"

}

~~~

Observed from tests/fixtures/FM-003/FM-003-unsafe.json (cases.json expects FM-003 count 1); run via lib/index.mjs rules/fmea-table-check.yaml

You ask · What it answers

The RPN cell does not equal severity × occurrence × detection — is that caught? · Yes. FM-003 recomputes rpn from severity × occurrence × detection with a tolerance of 0 and reports the row whose stored value differs. It runs only when all four cells hold parseable numbers; if the occurrence score is not a number the rule reports skipped rather than a pass. A worksheet built on the AIAG-VDA handbook scores with AP instead of RPN, so repoint resultField and factorFields, or disable the rule.

The severity cell holds 高 instead of a score. What happens? · FM-002 requires severity to be an operable positive number and reports the row when it is not. Its check names the severity field only, so occurrence and detection need the same rule added with a different field; it sets no score range, so it does not enforce a scale from 1 to 10 and does not judge whether a score is appropriate. A score it cannot parse also sends FM-003 to skipped, because the product cannot be recomputed.

A row recommends an action, but the owner and the due date are blank. · FM-005 runs on every row whose recommended-action cell is filled and requires both owner and dueAt; it reports the row missing either one. Those are the canonical names after alias resolution, so a sheet with other column headers needs the alias in the column mapping or requiredFields adjusted. It checks that the two cells are filled — not that the date is realistic or that the owner has accepted it. Rows with an empty action cell are FM-004's business.

Our worksheet never says which product or process it is analysing. · FM-007 reads the sheet header's item and reports it when the analysis subject is missing: an FMEA is carried out for a specific product or process, and without it the conclusions cannot be traced back or matched to a scoring table. It is a presence check — an analysis subject that is filled in but wrong is not reported. If your sheets must also name the method used, add method to its fields.

Some rows still read 待填 or XXX in the failure-mode column, and other rows have nothing there at all. · FM-008 reports a row whose failure-mode cell still contains one of the pack's placeholder terms (【, 】, {{, }}, XXX, xxx, 待填, 待补充, TBD, todo, 示例), because a sheet copied from a template reads as a finished analysis; it reads the failure-mode column only, and terms follows your template. FM-001 reports a row where failure mode, effect and cause are all blank, but it only requires one of the three to be filled — a cell holding 待填 satisfies FM-001 and is caught by FM-008 instead. Neither rule judges whether the failure modes are complete or the consequences analysed far enough.

The report lists FM-004 and FM-006 as skipped. Is something wrong? · No. Both ship unconfigured and the pack reports that instead of passi

…(truncated)