Analysis of Current Status of Six Capabilities Functions

Time: 2026-07-10

Repository: D:\openclaw\bossagents\

I. Overall Architecture

HTTP 请求
  ├─ POST /api/unified/create   ──→  unified-create.js（独立路径）
  │
  └─ POST /api/capability/*      ──→  CapabilityDispatcher.execute()
                                           ├─ normalizeParams()
                                           └─ CapabilityRuntime[capability]()
                                                    │
                         ┌──────────────────────────┴────────────────────────┐
                         ▼                                                  ▼
               试规则引擎（rule_engine）                              规则引擎无匹配 → LLM降级
               execute{Capability}()                                     _callLLMViaRouter()
                         │
                         ▼
               _buildRepairAML / _applyOptimizeAction → SCSAI applyAML

二、各能力现状

1. create ✅ 可用（独立体系）

• 路径：unified-create.js → 7步流水线 → SCSAI 直写AML
• 6类主业务（Project/Product/Part/Vendor/Customer/ECN）均已验证真实落库
• 与其他5个能力完全独立

2. repair ⚠️ 表面可用，实际"假修复"

规则现状（8条内置）：

| Rule | Check Content | Actual Behavior |

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

| repair-001 | Invalid ID format | Trigger condition is ambiguous, difficult to hit |

| repair-002 | Name field is empty | ✅ Can be detected |

| repair-003 | Vendor tax ID/address missing | ✅ Can be detected |

| repair-004 | Non-standard unit (pcs→PC) | ✅ Can be repaired |

| repair-005 | Price anomaly (>100,000 or

| repair-006 | Invalid reference (contains {null{undefined}) | ✅ Can be detected |

| repair-007 | VendorQuote price increase >5% | ⚠️ Requires last_unit_price field |

| repair-008 | Vendor information auto-completion | ⚠️ Generates "To be filled-xxx" placeholder |

| repair-009 | Stock below safety stock → Generate purchase request | ⚠️ Requires stk_stock_setup type |

Core Defects:

• auto_apply defaults to false → By default, only "identifies problems" without writing back to SCSAI
• Write-back path exists (_applyRepairToSCSAI), but does not trigger by default
• Post-repair validation exists (executeValidate), but depends on options.SCSAIClient parameter
• Most critical: Rules only cover "specific known issues", cannot handle "any potential problems"
• For example: Part's classification field missing → No rule
• For example: Product's keyed_name format error → No rule
• For example: Relationship object missing → No rule

3. optimize ❌ False Optimization

Current Rule Status (5 built-in):

| Rule | Check Content | Actual Behavior |

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

| optimize-001 | Data Standardization for name/description | Suggest only, never auto_fix |

| optimize-002 | Part BOM Cost Analysis | Suggest only (text suggestions) |

| optimize-003 | Vendor Supplier Scoring

| optimize-004 | Inventory Turnover Rate

| optimize-005 | ECR Approval >7 Days | Suggest only (text suggestions) |

Core Defects:

• All rules action_type: 'suggest' → Never auto_fix
• No fields are actually written back to SCSAI
• No concept of "the optimized object meets a certain standard"
• auto_apply parameter exists but is never called

4. compare ✅ Basic functionality available

• Compare two objects, output a list of field differences
• Has 3 rules (field differences, version changes, vendor comparison)
• Belongs to the "analysis & display" category, results are reports, not actions
• No write-back mechanism: differences identified are not automatically synchronized

5. identify ✅ Available (but has dead code)

• L879 SCSAI query type: Actually usable, rule_engine + LLM fallback
• L772 Asset catalog type: Dead code, no call path
• Belongs to the "query & identification" category, outputs SCSAI data

6. generate ⚠️ LLM fallback

• Has rule_engine.executeGenerate path (queries prompt_templates table)
• Falls back to LLM routing when template is empty
• Belongs to the "content generation" category, can generate structured object content
• Content generated by LLM requires the create path to be persisted to the database

III. Root Causes of Core Issues

Issue 1: The "correct state" for repair and optimize is undefined

Any repair must first know "what is correct." Current system:

• VALIDATE rules define "what is wrong" (required fields, format, logic)
• But does not define "what is a correct Part / Product / Vendor"
• Therefore repair can only fix "known errors," cannot handle "unknown errors"
• optimize can only make suggestions, cannot define "optimization goals"

Comparison: The create path of SCSAI is complete—there is a template → required fields → default values → serial numbers → pre-created relationships → AML generation. Only when this entire set is complete does create truly work.

repair and optimize also need such a complete "definition of correctness":

正确性定义（每个 ItemType 都需要）
  ├─ 必填字段（不能为空）
  ├─ list 字段可选值（不能超范围）
  ├─ 字段逻辑约束（结束日期≥开始日期）
  ├─ 业务规则（Vendor 必须有税号 / Part 必须有单位）
  ├─ 关系完整性（Product 必须有 Model 关系）
  └─ 编号规范（格式正则匹配）

问题2：修复后验证缺失

即使 repair 规则能检测并修复，修复后的对象没有强制验证流程：

• Current: Repair → write back to SCSAI → call VALIDATE scope → if any error-level rules fail, set repair_validation_failed: true
• However, repair_validation_failed: true does not block the return; it is only added as an extra field.
• The caller may not know that the repair failed.

Issue 3: optimize is purely textual suggestions.

The action_script for optimize-001 Data Standardization:

// 只是字符串操作，不写回任何字段
var normalized = value.trim().replace(/\s+/g, ' ');
return { fixed: true, changes: { [field]: normalized } };

即使返回了 changes，optimize 路径没有 _applyOptimizeAction 的默认调用（只有 auto_apply=true 才调用）。

Issue 4: identify has two implementations.

Both L772 and L879 are named identify(); the latter overrides the former. The asset catalog type in L772 (autoClassify + detectDuplicate) is never called and is dead code.

IV. Directions for Fixes

Core Principles

Each capability must have a clear commitment: what state the object will be in after completion.

• repair commitment: no error-level VALIDATE rule failures.
• optimize commitment: complies with a certain business standard (to be defined).
• Inspection commitment: regular scanning + repair until no errors.

P0 Fix Items

1. Make post-repair validation mandatory.

• After repair write-back, the VALIDATE scope must be run.
• If any error-level rules fail → mark repaired: false, record unresolved issues.
• The caller must handle incomplete repair situations.

1. Implement an auto_fix path for optimize.

• Change optimize-001 Data Standardization to action_type: 'auto_fix'.
• Add a default call path for _applyOptimizeAction (inherits context settings when auto_apply is not specified).
• Define the "optimization target standard" for each ItemType.

1. Complete VALIDATE rules.

• Current VALIDATE rules: 6 (3 for Project-specific + 4 general)
• Missing: Required field rules for Product/Part/Customer/ECN
• Missing: Relationship integrity rules (a certain type must have a specific relationship)

1. Extension of "correctness definition" for repair

• Add business rules for each core ItemType:
• Part: Must have unit/unit_cost/classification/keyed_name
• Product: Must have Model relationship (type B)
• Vendor: Must have tax_id/address
• ECN: Must have affected_items
• When rule detection fails → repair can automatically fix or clearly report inability to fix

1. Implementation of patrol capability

• Based on repair capability, iteratively scan object list
• Find issue → repair → verify → record
• Periodic execution (cron)

P1 repair items

1. identify dead code cleanup (delete or mark deprecated at L772)
2. compare result write-back mechanism (differences identified can be selectively synchronized)
3. Bridge between generate and create (LLM-generated content directly enters the create pipeline)

V. Gap Between Current State and Goals