规则引擎 × 六大能力 集成诊断（2026-07-11）

方法：不依据记忆，直接 dump 规则库 + 读引擎 _evaluateCondition 源码 + 运行时逐项验证。

结论：规则引擎本身能跑，但与规则库严重脱节——约 1/3 规则是"死规则"（condition.type 引擎未实现，永远 matched=false），

且核心写链路（create）已绕过规则引擎自管校验。导致"发现问题→修复问题"的闭环在多处断裂。

一、系统实际能力版图（不只是 6 个）

capability-runtime.js 公开了 13 个 capability：

create / validate / repair / optimize / compare / identify / generate（6 主能力）

+ inspect / collect / valuate / update / delete / approve / transform（扩展能力）。

六能力只是子集。下面按"发现问题 → 修复问题"闭环审视。

二、致命问题 1：规则库 33% 是死规则（condition 类型引擎不识别）

规则库 sciot_rules_v2 共 76 条，全部 is_active=1。但引擎 _evaluateCondition 只实现了约 25 种 condition.type + 10 种 operator。

其余 type（规则库大量使用）无对应分支 → 落到 switch(cond.operator) 的 default: return false → 永远不命中。

量化（死规则 25/76 = 33%）：

| scope | 死规则数 | 说明 |

|---|---|---|

| inspect | 6/6 | 巡检能力整体失效 |

| collect | 5/5 | 采集能力整体失效 |

| repair | 6/12 | 8 条 has_* 中只有 2 条（001/002 operator 类）能活，其余 6 条（has_price_change/has_missing_vendor_fields/has_low_stock/has_low_score/has_overdue_order/has_duplicate_candidates）引擎无此 type → 死 |

| validate | 3/9 | builtin-validate-001(type_check)、builtin-validate-002(length_check) 及 project-validate-001~003(field_check) 全死 |

| create | 2/3 | builtin-create-001/002(operator=missing/duplicate) 引擎无此 operator → 死 |

| create_post | 1/4 | check_relationships 死 |

| valuate | 2/2 | asset_count_check / income_data_check 死 |

运行时佐证：

• validate（既有完整对象）：6 条规则仅 builtin-generic-required-check(has_required_fields) 命中，其余 5 条 block/warn 类全 matched=false。
• inspect（对象缺 item_number）：executed=true 但 issues_found=空 results=0 —— 明明该报空值，却零输出。
• collect：400 错误，能力入口本身未接稳。

根因： 规则库 schema 设计时定义了一套 condition type 词汇表（type_check / field_empty / field_check / length_check / source_match / check_relationships / asset_count_check …），但引擎实现只覆盖了其中一小半（has_* / always / keyword_match + 少量 operator）。规则编写与引擎实现两侧没有契约校验，新增规则时无人检查 type 是否被引擎支持。

三、致命问题 2：create 必填校验被"双轨"架空

• unified-create.js（create 主链路）自己实现必填校验（is_required 字段驱动，line 451/605/956/1032…），不依赖规则引擎。
• 规则引擎 create scope 的 builtin-create-001(必填 block) 因 operator=missing 不被识别 → 死。
• capability-runtime.create 主流程直接 require('../routes/unified-create').handleCreate，规则引擎 create scope 只是"可选预检"，且预检本身也死。

运行时佐证： 通过 POST /api/unified/create 创建缺 name 的 Part，结果 success=true 真落库（id=1658BD…）。

→ 必填校验只靠 unified-create 的私有逻辑，规则引擎的 create 规则是完全冗余且失效的一层。

风险： unified-create 私有校验与规则引擎规则库两套基准不同源。规则库里定义的"正确性"对 create 链路零约束；一旦 unified-create 私有逻辑有疏漏，规则库无法补位。

四、致命问题 3：repair 写回"半闭环"

• repair 入口已传 selected_ids → _resolveSelectedData 拉回真实对象 → 写回 SCSAI 已验证（之前 unit 改 EA 成功）。
• 但 repair 的 12 条规则里 6 条死（见上）。真实业务场景：
• 编号格式异常（invalid_format）→ 活，能修。
• name 为空 → 活，能修。
• 供应商缺税号/地址/电话、价格异常、库存偏低、重复候选、低分、逾期订单 → 全死，这些问题永远不会被自动修复。
• 即"发现问题（repair 应修的 6 类）"在规则层就被静默丢弃，用户无感知。

五、致命问题 4：inspect / collect 是空壳能力

• inspect：6 条规则全死 → 巡检零输出（已验证）。系统"周期性巡检发现脏数据"的能力事实不存在。
• collect：入口 400，且 5 条 source_match/auto_catalog 规则全死。数据自动采集/编目能力事实不存在。
• 这两项是之前 summary 已识别的"缺周期性巡检能力"的深层根因——不是没人调，是调了也因规则死而无输出。

六、致命问题 5：规则"命中即生效"与"建议即忽略"的不对称

• block 类（validate/create 的 required/type）：真能拦的只有 has_required_fields 等少数；其余 block 规则死了，校验强度名不副实。
• suggest 类（optimize/identify/repair 建议）：返回建议但 auto_apply=false 默认不写回（之前已确认 optimize 全 suggest 不回写，仅 1 条 auto_fix）。
• auto_fix 类：repair 写回闭环，但 6 条 auto_fix 规则里 4 条死（has_non_standard_unit 活，其余 has_* 死）。

→ 系统对外宣称"六能力闭环"，实际只有 validate(部分)/repair(部分)/optimize(建议)/create(私有校验) 在起作用，inspect/collect 完全空转。

七、修复优先级建议

P0（恢复核心闭环）

1. 给 _evaluateCondition 补齐缺失的 condition.type 实现，与规则库契约对齐：

• type_check（按字段 data_type 校验）、length_check、field_check(empty/compare)、field_empty/multi_field_empty/field_empty_check、field_pattern、field_value(not_in)、staleness_check、source_match、auto_catalog、check_relationships、asset_count_check、income_data_check、has_price_change/has_missing_vendor_fields/has_low_stock/has_low_score/has_overdue_order/has_duplicate_candidates。
• 或在规则库侧把死规则 condition 改写为引擎已支持的 type（如 field_check→operator:empty）。

1. 建立契约测试：启动时扫描 sciot_rules_v2，对所有 condition.type/operator 校验引擎是否支持，打印"死规则清单"到日志，避免再次静默失效。

P1（统一校验基准）

1. 决定 create 校验的单一真相源：要么 unified-create 复用规则引擎 validate scope（删私有校验），要么规则引擎 create scope 重写为引擎支持的 type 并接到主链路。消除双轨。
2. repair 死规则补全实现，让供应商/价格/库存/重复类问题真正可修。

P2（补空壳能力）

1. inspect / collect 接入真实数据源或明确标记为未启用（不在公开 capability 暴露），避免"看起来有实则空"。

八、验证证据清单（本次运行时）

• validate(50066E) → 6 规则仅 1 命中，5 条 block/warn matched=false
• inspect(50066E, 缺 item_number) → issues_found=空, results=0
• collect → HTTP 400
• create(缺 name) via /api/unified/create → success=true 落库 (id=1658BD91969E4337BFF61A4C1C3A21D1)
• repair(既有对象) → executed=true issues=1 applied=2 aras=true（但仅 operator 类规则生效）
• 规则库 dump：76 条，25 条 cond.type 引擎不支持（33%）

九、附：本诊断临时脚本已清理，未改动任何业务代码。