Rule Engine × Six Capabilities Integrated Diagnosis (2026-07-11)

Method: Directly dump the rule base without relying on memory + read the engine's _evaluateCondition source code + runtime item-by-item verification.

Conclusion: The rule engine itself can run, but it is severely disconnected from the rule base—approximately 1/3 of the rules are "dead rules" (condition.type not implemented by the engine, always matched=false).

Moreover, the core write path (create) bypasses the rule engine's own validation checks. This causes breaks in the "identify issue → fix issue" closed loop at multiple points.

I. The System's Actual Capability Landscape (Not Just 6)

capability-runtime.js exposes 13 capabilities:

create / validate / repair / optimize / compare / identify / generate (6 main capabilities)

+ inspect / collect / valuate / update / delete / approve / transform (extended capabilities).

The six capabilities are only a subset. The following examines the "identify issue → fix issue" closed loop.

II. Critical Issue 1: 33% of the Rule Base are Dead Rules (Condition Types Unrecognized by the Engine)

The rule base sciot_rules_v2 contains 76 rules in total, all with is_active=1. However, the engine's _evaluateCondition only implements about 25 condition.type + 10 operator types.

Other types (heavily used in the rule library) have no corresponding branch → fall into the default case of switch(cond.operator): return false → never match.

Quantification (dead rules 25/76 = 33%):

| scope | dead rule count | description |

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

| inspect | 6/6 | Entire inspection capability is disabled.

| collect | 5/5 | Entire collection capability is disabled.

| repair | 6/12 | Among 8 has_* rules, only 2 (001/002 operator type) survive; the other 6 (has_price_change/has_missing_vendor_fields/has_low_stock/has_low_score/has_overdue_order/has_duplicate_candidates) have no corresponding type in the engine → dead.

| validate | 3/9 | builtin-validate-001(type_check), builtin-validate-002(length_check), and project-validate-001~003(field_check) are all dead.

| create | 2/3 | builtin-create-001/002(operator=missing/duplicate) Engine lacks this operator → dead |

| create_post | 1/4 | check_relationships dead |

| valuate | 2/2 | asset_count_check / income_data_check dead |

Runtime evidence:

• validate (existing complete object): Out of 6 rules, only builtin-generic-required-check(has_required_fields) triggered; the other 5 block/warn type rules all had matched=false.
• inspect (object missing item_number): executed=true but issues_found=empty results=0 — should have reported null value, but output was zero.
• collect: 400 error, the capability endpoint itself is not stable.

Root cause: When designing the rule repository schema, a vocabulary of condition types was defined (type_check / field_empty / field_check / length_check / source_match / check_relationships / asset_count_check …), but the engine implementation only covers a small subset (has_* / always / keyword_match + a few operators). There is no contract validation between rule authoring and engine implementation; no one checks if a new rule's type is supported by the engine when adding it.

3. Fatal Issue 2: Required Validation for Create is Bypassed by "Dual-Track" System

• unified-create.js (the main create workflow) implements its own required validation (driven by the is_required field, lines 451/605/956/1032…), independent of the rule engine.
• The builtin-create-001 (required block) in the rule engine's create scope is dead because operator=missing is not recognized.
• The main capability-runtime.create flow directly calls require('../routes/unified-create').handleCreate; the rule engine's create scope is merely an "optional pre-check," and this pre-check itself is also dead.

Runtime evidence: Creating a Part missing the name via POST /api/unified/create results in success=true and actual database persistence (id=1658BD…).

→ Required validation relies solely on the private logic in unified-create; the rule engine's create rules are a completely redundant and ineffective layer.

Risk: The private validation in unified-create and the rule engine's rule base have two different sets of benchmarks. The "correctness" defined in the rule library imposes zero constraints on the create pipeline; once there is an oversight in the private logic of unified-create, the rule library cannot compensate.

IV. Critical Issue 3: "Semi-closed-loop" Write-back in repair

• The repair entry has passed selected_ids → _resolveSelectedData fetches the real objects → Write-back to SCSAI has been verified (the previous unit change to EA was successful).
• However, 6 out of the 12 rules in repair are dead (see above). Real business scenarios:
• Abnormal numbering format (invalid_format) → Alive, can be fixed.
• Empty name → Alive, can be fixed.
• Missing supplier tax ID/address/phone, abnormal price, low inventory, duplicate candidates, low score, overdue orders → All dead. These issues will never be automatically fixed.
• That is, "identifying problems (the 6 categories repair should fix)" is silently discarded at the rule layer, with no user awareness.

V. Critical Issue 4: inspect / collect are hollow capabilities

• inspect: All 6 rules are dead → Zero output from periodic inspection (verified). The system's claimed capability of "periodically inspecting and discovering dirty data" effectively does not exist.
• collect: Entry returns 400, and all 5 source_match/auto_catalog rules are dead. The capability for automatic data collection/cataloging effectively does not exist.
• These two are the root cause behind the previously identified "lack of periodic inspection capability" in the summary—it's not that no one calls them, but that calls yield no output due to dead rules.

VI. Critical Issue 5: Asymmetry between "hit takes effect" and "suggestions are ignored" rules

• Block-type rules (required/type in validate/create): Only a few like has_required_fields can truly block; the rest are dead, making the validation strength nominal.
• Suggest-type rules (suggestions from optimize/identify/repair): Return suggestions but auto_apply=false by default, meaning no write-back (it was previously confirmed that optimize only suggests with no write-back, except for 1 auto_fix rule).
• The auto_fix class: repair writes back to close the loop, but 4 out of the 6 auto_fix rules are dead (has_non_standard_unit is active, the rest of the has_* rules are dead).

→ The system publicly claims "six-capability closed loop," but in reality, only validate (partial)/repair (partial)/optimize (suggestions)/create (private validation) are functional, while inspect/collect are completely idle.

7. Repair Priority Recommendations

P0 (Restore Core Closed Loop)

1. Complete the missing condition.type implementations for _evaluateCondition to align with the rule library contract:

• type_check (validate by field 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.
• Alternatively, rewrite the dead rule condition on the rule library side to a type already supported by the engine (e.g., field_check→operator:empty).

1. Establish contract testing: Scan sciot_rules_v2 on startup, validate if all condition.type/operator are supported by the engine, and log a 'Dead Rule List' to prevent silent failures.

P1 (Unified Validation Baseline)

1. Determine the single source of truth for create validation: Either have unified-create reuse the rule engine's validate scope (removing private validation), or rewrite the rule engine's create scope to use engine-supported types and integrate it into the main workflow. Eliminate the dual-track system.
2. Repair dead rules by completing their implementation, making issues related to supplier/price/inventory/duplication truly fixable.

P2 (Fill Shell Capabilities)

1. Connect inspect / collect to real data sources or explicitly mark them as disabled (not exposed in public capabilities), avoiding the 'appears functional but is empty' scenario.

VIII. Evidence Checklist (Current Runtime)

• validate(50066E) → 6 rules, only 1 matched, 5 rules block/warn matched=false
• inspect(50066E, missing item_number) → issues_found=empty, results=0
• collect → HTTP 400
• create(missing name) via /api/unified/create → success=true, persisted (id=1658BD91969E4337BFF61A4C1C3A21D1)
• repair(existing object) → executed=true issues=1 applied=2 SCSAI=true (but only operator-type rules took effect)
• Rule library dump: 76 rules, 25 rules have unsupported cond.type (33%)

IX. Appendix: The temporary diagnostic script used for this analysis has been cleaned up; no business code was modified.