verification-criteria

Verification Criteria Generator & Auditor

Generate, audit, and trace VCs for functional system requirements. ASPICE SYS.2 BP5 / ISO/IEC 29148 / VC-First.

Quick Mode Selector

≤5 条粘贴到对话 → 自动走 ⚡ Lite Mode（跳过 CHECKPOINT）。文件路径 / >5 条 → Full Mode。

Route — 3 步定模式（入口）

flowchart TD
    START["用户请求"] --> R1{"输入方式?"}
    R1 -->|"对话内直接粘贴 ≤5 条"| LITE["⚡ Lite Mode"]
    R1 -->|"文件路径 / >5 条"| FULL["Full Mode"]
    LITE --> R2{"关键词?"}
    FULL --> R2
    R2 -->|"生成/编写/创建"| A["A — VC Generation"]
    R2 -->|"审核/评审/SMARTR-OC/评分"| B["B — VC Quality Audit"]
    R2 -->|"覆盖率/追溯/traceability/遗漏"| C["C — Coverage Audit"]
    R2 -->|"≥2 模式命中"| ASK["🔴 vscode_askQuestions 确认顺序"]

Step 1 — Lite vs Full

Step 2 — 关键词定模式（唯一模式命中 → 跳过模式确认，合并到源确认）

⚠️ 强制 vscode_askQuestions：Never assume intent. 需要确认模式/等待决策时必须调用工具，而非输出文字等待手动回复（反例 #11）。

Step 3 — Todo List + 源文档确认（Full Mode 强制；Lite 跳过）

Full Mode 加载对应 workflow 文件后，立即 manage_todo_list（从 workflow 文件的 "## Todo List Template" 复制）。无 todo list = 协议违规。然后用 vscode_askQuestions 一次性确认模式 + 源文档 + Todo List（Token 优化：三合一，不单独发轮）。

🔴 CHECKPOINT · 🛑 STOP — 必须在源文档确认中明确告知当前模式。绝不静默跳转模式。绝不输出执行流程概要（反例 #10）。

Mode A — VC Generation（加载 references/vc-workflow-a.md）

⚡ 一句话：为每条需求生成可独立验证的测试标准（方法+条件+数值判据+来源标注）

触发："生成"/"编写"/"创建" VC | 输入：需求文档（md/xlsx/csv） | 输出：VC 表 + Source Depth 标注 + 覆盖率报告

🔴 CHECKPOINT · 🛑 STOP — A.0 发现已有 VC 时必须 vscode_askQuestions（增量/覆盖/切换），禁止静默覆盖。A.4 后覆盖率 < 100% 不得直接结束（反例#4）。

VC-First 7步循环（每条需求）：理解意图 → 选择方法 → 定义标准 → Source Depth 标注 → 设定条件 → 编写VC → SMARTR-OC 自检

验证方法决策树（A.2 步，按需求类型自动匹配 — 红线：全用 "Test" 违反反例#5）：

🔒 本表是「需求类型 → 验证方法」映射的 single source of truth。references/vc-workflow-a.md 有一份抽象 mermaid 决策流（教学用），逻辑与本表一致——更新方法映射规则时只改本表。

Hybrid 方法（硬规则，禁止自行裁量）：需求在决策树中命中 ≥2 行 → 强制组合 ≥2 方法（主方法 + 第二方法交叉验证）；仅命中 1 行 → 单方法，禁止自行叠加。示例：SOC 估算精度命中"逻辑/算法"+"时序"两行 → 强制 Analysis（模型仿真+边界值注入）+ Test（HIL 对标精密 SOC 仪表）。安全/保护类已内置 Test+Analysis 组合（命中即自动 2 方法）。

Speed Tier（快速通道 · 用户显式请求"快速/quick/简要"时触发）

Speed Tier 只减展示不降质量：SMARTR-OC / Source Depth / 反例扫描 / 覆盖率仍 100% 执行，仅跳过中间展示环节。

Mode B — VC Quality Audit（加载 references/vc-workflow-b.md）

⚡ 一句话：对已有 VC 做 SMARTR-OC 8维评分 + CK-01~CK-10 清单，给 Pass/Revise/Blocked 处置

触发："审核"/"SMARTR-OC"/"评分" | 输入：VC 文档（md/xlsx/csv） | 输出：SMARTR-OC 评分表 + CK 清单 + 质量报告

B.2 双重审核判定矩阵（B.2 步必查 — 关键决策点）

对每条 VC 单遍扫描同时打 SMARTR-OC + CK 分，按下表给 disposition：

CK-01~CK-10 严重度速查（完整表见 assets/vc-checklist.md）：

B.3 修复原则：SMARTR-OC 失败按 vc-smartr-oc.md 的"If ✗"列修；CK Critical 失败直接修对应项。必须同时清 SMARTR-OC ≥ 6/8 和 全部 🔴 Critical。反复失败 → 升级修订需求。

Mode C — Coverage Audit（加载 references/vc-workflow-c.md）

⚡ 一句话：检查需求↔VC双向覆盖完整性，输出 UNCOVERED/ORPHAN 清单 + 覆盖率矩阵

触发："覆盖率"/"追溯"/"traceability" | 输入：需求文档 + VC 文档（可同文件） | 输出：覆盖率矩阵 + UNCOVERED/ORPHAN 清单

🔴 CHECKPOINT · 🛑 STOP — C.0 必须 vscode_askQuestions 确认需求+VC 双源，缺任一源不得继续。C.2 >30% UNCOVERED → 暂停 C，提示回退 Mode A 补齐。

C.2/C.3 缺陷判定阈值（C.2~C.3 步必查 — 关键决策点）

覆盖率公式：Coverage% = Covered Reqs / Total Reqs（UNCOVERED + PARTIAL 均不计入分子）。目标 100%；< 100% 不允许直接结束（反例#4）。

🔒 A→C 快速通道（A+C 混合，single source of truth）：A.4 完成后跳过 C.0/C.1 → C.2 用 A.4 矩阵增量检查 → C.3 扫 A 输出标 ORPHAN → C.4 加 disposition 列 → C.5 输出。异常章节的混合模式表仅引用本定义，不重复。

Parallel Dispatch（仅 Mode A，需求 > 50）

先用 scripts/split_req.py 按功能域拆分为独立 .md 文件（≤100条/文件，域不跨文件），再并行 runSubagent，每个子Agent prompt 只传 {requirements_file_path}（不内联全文），子Agent自行 read_file 加载。

分层复核（两阶段门控）：阶段一 SMARTR-OC 抽样（8/8 → 进入阶段二 / 6-7 抽样 20%（1条不一致→全量）/ <6 全量 / 均分偏离全局 >1.0 全量）；阶段二 Gate 11 格式抽查（仅对 8/8 候选：检测 Test Conditions/Pass-Fail 列 ; 误用，命中则降级到 6-7 抽样桶，不依赖子Agent 自报告）。由 scripts/merge_vc.py 自动执行。

🔴 CHECKPOINT · 🛑 STOP — A.1a 拆分完成后、spawn 子Agent前：展示拆分方案（domain + ID 范围 + 条数 + 输出路径），vscode_askQuestions 确认后并行执行。禁止跳过。

共享规则（三模式通用）

VC-First Methodology

Core Principle: Write the VC simultaneously with every requirement. VC is the requirement's "other half" — requirement says "what"; VC says "how we prove it."

See references/vc-anti-patterns.md for common VC-First mistakes and corrective examples.

Requirement Maturity Gate

🔴 CHECKPOINT · 🛑 STOP — 累计 ≥3 VC-BLOCKED → 暂停所有 VC 工作，vscode_askQuestions 让用户选择"修订需求后继续"或"终止"。

Key Principles（每条独有的 🔴 GATE；反例详见 ⛔ Do Not 黑名单）

• VC-First — 🔴 GATE：无法写出 VC → 立即标记 VC-BLOCKED，不继续下一条
• VC is a design activity — 🔴 GATE：写 VC 时主动质疑需求可测性，必要时回推修订需求
• VC ownership — Requirements engineer 写 VC；test engineer 审 testability
• One VC = one independently verifiable aspect — 🔴 GATE：精度/响应时间/覆盖范围各自独立成条
• Source Depth — No Unsourced Content — 🔴 GATE：≥3 [A] → VC-BLOCKED；Any [A] → SMARTR-OC A=✗
• Engineer-Readable — 每 VC 字段 10 秒内被陌生工程师理解，无缩写解码

批量展示 + 最终输出 CHECKPOINT

🔴 CHECKPOINT · 🛑 STOP：

1. ≤3 条（Lite Mode）：跳过中间 CHECKPOINT，SMARTR-OC + 覆盖率内联展示，仅在最终输出前一次 vscode_askQuestions 确认
2. ≤10 条需求 → 逐条展示 VC + SMARTR-OC；>10 条 → 每 10 条批量展示，vscode_askQuestions 确认后继续
3. A.3 完成后 → 展示 SMARTR-OC 汇总（⛔ 反例#12 — 仅列出 <8/8 或非 Ready 的 VC；8/8 全 ✅ 不列入表格，一句汇总即可）。格式定义见 vc-report-templates.md。用户选择：(a)修订重检 / (b)标记 disposition 继续 A.4 / (c)终止导出
4. 最终输出前 → 展示完整 VC 文档 + 覆盖率摘要，vscode_askQuestions 确认后输出

Speed Tier 覆盖：用户显式请求"快速/quick"→ 跳过 CHECKPOINT #2/#3，仅保留 #4（最终确认）。

异常与边界条件

绝不静默跳过或静默失败（反例 #8）：异常先告知用户，再按规则处理。

关键 Fallback（最常触发；完整规则见 references/vc-exceptions.md）

混合模式执行顺序与交叉联动

交叉发现联动（后 Workflow 发现的问题反馈到前 Workflow）：

• C.3 发现 ORPHAN VC → B.2 报告标注 ⚠️ cross-flagged: ORPHAN，质量评分降权
• C.2 发现 UNCOVERED → 提示回退 A.2 补齐
• B.2 发现 VC-BLOCKED → C 覆盖率矩阵标注 ⚠️ VC-BLOCKED，覆盖率待定

Lite Mode 信息不完整处理

• 缺工作温度范围 → 常温 + ⚠️ 需求未指定温度边界，仅按常温(25°C)验证 → 🟡 VC-PARTIAL
• 缺故障条件 → 正常工况 + ⚠️ 未覆盖故障/异常工况 → 🟡 VC-PARTIAL
• 数值无来源 → [A: Lite Mode推断，需确认] + 提示补充 → 🟠 VC-ASSUMPTION
• 主观形容词（良好/快速/稳定） → 🔴 VC-BLOCKED，必须量化为 ≤/≥/= + 数值 + 单位后重写

累积 ≥3 🟡/🟠 → 不触发升级（与 ≥3 🔴 VC-BLOCKED 不同）。但需在输出摘要标注信息缺口。

Lite Mode VC-BLOCKED 定义（与 Full Mode B.3 区别）：精简改进循环 → 首次 SMARTR-OC < 6/8 给一次修订机会（仅修正不达标维度，不重跑全流程）→ 修订后仍 <6/8 → 直接判 BLOCKED。仅 🔴 级（反例#3 主观词 / 反例#6 全 [A] / SMARTR-OC M=✗）触发。🟡/🟠 不作为 BLOCKED，仅质量标记注明。

触发升级：Lite Mode 发现 ≥3 VC-BLOCKED 或覆盖率 <100% → 暂停，提示切换 Full Mode。

References（按需加载）

加载对应 workflow 步骤前验证文件存在；缺失按 references/vc-exceptions.md "引用文件缺失" fallback。

⛔ Do Not — 反例黑名单

执行任何 workflow 时一律禁止。遇到即标记错误，必须修正。

完整反例库见 references/vc-anti-patterns.md。本表为主文件必看的最小集。