BossAgents Architecture Reality-Check and Main Chain Unification Plan

Generation Time: 2026-07-06

Method: All claims are verified against source code (grep/read), not AI inference.

Scope: Excludes "data volume" issues, focuses on architecture/product/engineering closed-loop.

Zero. First, a correction: One point from the previous analysis needs to be overturned.

Original analysis claim: "SmartLLMRouter does not exist / LLM scheduling three-track not implemented."

Actual test result: server/digital-staff/smart-llm-router.js exists (1043 lines, contains MTCLAW→Ollama→DeepSeek→rule engine multi-level fallback chain).

Revised conclusion: SmartLLMRouter is implemented but not adopted by the main path. The real gap is 'implemented vs. not integrated into main path,' not 'not implemented.' This is more optimistic than the original analysis—less work to converge.

I. Verified Fact List (✅=Confirmed by Source Code)

P0-1 Digital Staff Quantity: Plan 12 vs. Code 27

• profiles/local.yaml actual ID count = 30 (including 3 LLM platform placeholders mtclaw/ollama/deepseek + auto-loop staff).
• Actual business staff: 27, only 3 with enabled: false.
• Plan V7.0 primarily promotes "12 Major Digital Staff."
• Qualitative ✅: "Product definition drift" with 12 external and 27 internal instances is confirmed.

P0-2 LLM Scheduling: Implemented but the main path directly connects to LLMBrain.

• Scattered new LLMBrain() instantiation points on the main path:
• server/routes/aml.js ×9 (4188/4368/5380/5858/5972/6184/6318/6420, etc.)
• conversation-engine.js:78, object-modeler.js:273, procurement-workflow-v3.js:16, health-patrol.js:175
• SmartLLMRouter reference points exist (server.js / lite-scheduler.js / capability-api.js / smart-llm-router.js itself).
• Qualitative ✅: Coexistence of three tracks is confirmed, but the root cause is "main path not converged to SmartLLMRouter", not "not implemented".

P0-3 Create Main Path Interruption: Frontend + backend bypass the rule engine in parallel.

• Frontend: src/composables/useCapabilityCreate.js + useCreate.js

buildAML() → bomService._SCSAIApiRequest('ApplyItem', mainAml) directly calls SCSAI.

• Backend: server/routes/unified-create.js

Directly getSharedClient → precreateItem / createRelationshipsRecursive directly calls SCSAI

No references to ruleEngine / CapabilityRuntime / llm-router found in the entire text

• Rule engine entry point /api/rule-engine/create-post (server.js:2320) is never called by the frontend
• Qualitative assessment ✅ (more severe than original analysis): Not only does the backend bypass, but the frontend also directly connects to SCSAI. The "90% rule-based fallback" cannot be tracked or audited on the Create path

P0-4 "Five-Dimensional" is misnamed

• In the code, "Five-Dimensional" = Five-dimensional data health check scoring: Completeness/Accuracy/Timeliness/Availability/Security (confirmed by frontend govern module)
• The proposal mixes the term "Five-Dimensional Object Marketplace" with "Five-Dimensional Health Check"
• Qualitative assessment ✅: Genuine naming conflict, will be challenged during due diligence

P1-1 Workers not unified to CapabilityRuntime

Actual test of 19 worker call patterns (CR=via CapabilityRuntime, LLM=directly connects to LLMBrain):

| Worker | CR | LLM | Description |

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

| SCSAI-creator | ✅ | ❌ | Go through CR |

| biz-analyst | ✅ | ❌ | Go through CR |

| cost-optimizer | ✅ | ❌ | Go through CR |

| data-clerk | ✅ | ❌ | Go through CR |

| ecr-worker | ✅ | ❌ | Go through CR |

| report-analyst | ✅ | ❌ | Go through CR |

| vendor-review | ✅ | ❌ | Go through CR |

| auto-loop-worker | ❌ | ❌ | Independent storage auto-loop-data.json |

| content | ❌ | ❌ | Custom logic |

| data-caretaker | ❌ | ❌ | Custom logic |

| doc-worker | ❌ | ❌ | Custom logic |

| equip-worker | ❌ | ❌ | Custom logic |

| mkt-worker | ❌ | ❌ | Custom logic |

| pm-worker | ❌ | ❌ | Custom logic |

| process-worker | ❌ | ❌ | Custom logic |

| procurement | ❌ | ❌ | Custom logic |

| stock-manager | ❌ | ❌ | Custom logic |

| system-health | ❌ | ❌ | Custom logic |

Conclusion: Only 7/19 went through CR, the remaining 12 implemented their own business logic. The plan's "six capabilities × industry knowledge" translates to "12 implementation styles" in engineering.

Qualitative ✅: "No FDE required, copy and deploy" is difficult to prove.

P1-2 Dual Database Split

• server/data/core_runtime.db (1.7MB, 89 tables)
• server/data/core_runtime.db (20KB, 2 tables)
• Two databases coexist, risk of behavioral inconsistency.
• Qualitative ✅

P1-3 Legacy Not Cleaned Up

• server/digital-staff/index.js still exists (2423 lines), dual entry with boss-scheduler.
• Qualitative ✅: Cognitive burden + routing ambiguity.

P1-4 mtclaw-tools.yaml is an "Empty Socket"

• Registers 9 handlers: leftarm.db.query / leftarm.rule_engine.cost_calc / leftarm.notification.send, etc.
• Zero leftarm handler implementations in the entire repository.
• Qualitative ✅: Configuration exists but lacks backend; Phase2 MTClaw not implemented.

P1-5 Self-evolving not integrated into main path

• rule-evolution.js exists, but only triggered by DS-LOOP-001 bypass cron
• Not connected to rule engine post-execution hooks (hit_count / user_correction → candidate rules)
• Qualitative ✅: The "increasing accuracy with use" claim in the proposal can only be discussed in design, cannot be live demoed

P2-1 Test Coverage

• Only 3 test files: aml-integrity.test.mjs / digital-staff.test.mjs / rule-engine.test.mjs
• Thousands of files in the entire repo, high risk for financing due diligence
• Qualitative ✅

P2-2 Multi-tenancy

• tenant-db.js has an enterprises table, but scheduling/dual-database/employee configuration lacks tenant isolation
• Qualitative ✅ (Partial): Framework exists, isolation missing

II. Optimization Plan (No data import, only modify architecture/routing/convergence)

Plan Overview: A single, unified main chain

用户意图/前端操作
  → SmartLLMRouter（唯一 LLM 入口，含降级链）
  → CapabilityRuntime（规则引擎优先，LLM 降级）
  → 六能力（Identify/Create/Repair/Optimize/Compare/Generate）
  → 统一 SCSAI 适配层（禁止各 worker 直连）
  → 可审计结果（rule hit_count + execution_log）

改动清单（按优先级）

#### 【P0】主链收敛（本次立即动手）

1. Create process unified into a closed loop

• Frontend useCapabilityCreate.js / useCreate.js: After buildAML, call /api/rule-engine/create-post (instead of directly connecting to _SCSAIApiRequest)
• Backend unified-create.js: Modified to first query rule engine + dual-database deduplication, then applyAML; retain direct connection as an ?bypass=rule escape hatch
• Acceptance: Create operation generates records in the sciot_rule_hits table

1. LLM Single Entry

• Establish global.__smartLLMRouter = new SmartLLMRouter(...) upon server.js startup
• Modify 9 locations in aml.js + other scattered new LLMBrain() calls to global.__smartLLMRouter.call(...)
• Acceptance: All LLM calls go through unified metrics export

1. "Five-Dimensional" Renaming

• In code: Keep health check named "Five-Dimensional Scoring"
• Proposal: Rename "Five-Dimensional Object Trading Market" to "Six-Type Object Trading Market" (data/model/rule/Skill/workflow/digital employee)
• Avoid due diligence naming conflicts

#### 【P1】OS Kernelization (Step 2)

1. Worker must go through CapabilityRuntime

• 12 unconnected workers: Change each to runtime.call({capability, itemType, params})
• Retain worker as "parameter configurator + capability orchestrator", prohibit direct access to LLM/SCSAI

1. Merge two databases

• Unify to use server/data/core_runtime.db, remove references to server/data/core_runtime.db
• DB_PATH configuration item as the single source of truth

1. Legacy cleanup

• Mark digital-staff/index.js as deprecated, route all to boss-scheduler
• Delete after 1 version

1. mtclaw empty socket handling

• Either implement leftarm.* handler (reuse existing db/rule-engine/notification modules)
• Or remove from mtclaw-tools.yaml to avoid 'configuration hallucination'

1. Self-evolution into main path

• rule-evolution.js hooks into CapabilityRuntime post-execution
• After each capability execution: update hit_count + collect user_correction → generate candidate rules

#### 【P2】Scaling (Step 3)

1. Complete testing: add integration tests for core main chain (create/identify/router)
2. Multi-tenant isolation: inject tenant_id into scheduling context
3. Product-level convergence: split local.yaml by profile (boss-lite / enterprise), main narrative uses only 12 standard Skills

III. Immediate optimizations to execute (three P0 items)

Refer to the 'Optimization Execution Record' below.