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: Excluding "data volume" issues, focusing only on architecture/product/engineering closure

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, containing multi-level fallback chain: MTCLAW→Ollama→DeepSeek→rule engine).

Revised conclusion: SmartLLMRouter is implemented but not adopted by the main path. The real gap is 'implemented vs. not integrated into the main path', not 'unimplemented'. 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 IDs = 30 (including 3 LLM platform placeholders mtclaw/ollama/deepseek + auto-loop staff)
• Formal business staff: 27, enabled: false only 3
• Plan V7.0 promotes "12 Major Digital Staff"
• Qualitative ✅: The 'product definition drift' of 12 externally vs. 27 internally is confirmed.

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

• Main path scattered with new LLMBrain() points:
• 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 assessment ✅: Three-track coexistence is established, but the root cause is "main path not converging to SmartLLMRouter", not "not implemented"

P0-3 Create Main Path Interruption: Frontend + backend double bypass of the rules engine

• 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) never called by 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 Dimensions" name does not match reality

• Code's "Five Dimensions" = Data Health Check Five-Dimensional Scoring: Completeness/Accuracy/Timeliness/Availability/Security (confirmed by frontend govern module)
• The proposal conflates "Five-Dimensional Object Trading Market" and "Five-Dimensional Health Check" using the same term
• Qualitative assessment ✅: Genuine naming conflict, will be challenged during due diligence

P1-1 Workers not unified under CapabilityRuntime

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

| Worker | CR | LLM | Description |

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

| SCSAI-creator | ✅ | ❌ | Via CR |

| biz-analyst | ✅ | ❌ | Via CR |

| cost-optimizer | ✅ | ❌ | Via CR |

| data-clerk | ✅ | ❌ | Via CR |

| ecr-worker | ✅ | ❌ | Via CR |

| report-analyst | ✅ | ❌ | Via CR |

| vendor-review | ✅ | ❌ | Via 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 go through CR, the remaining 12 implement their own business logic. The "six capabilities × industry knowledge" in the plan 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 codebase.
• Qualitative ✅: Configuration exists but lacks backend; Phase2 MTClaw not implemented.

P1-5 Self-evolution not on the main path

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

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 repository, 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 does not

II. Optimization Plan (No data import, only architecture/routing/consolidation changes)

Plan Overview: A single, unique main chain

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

改动清单（按优先级）

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

1. Create closed-loop unification

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

1. LLM Single Entry Point

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

1. "Five-Dimensional" Renaming

• In code: Keep the naming as "Five-Dimensional Score" for health checks
• Proposal: Rename "Five-Dimensional Object Marketplace" to "Six-Category Object Marketplace" (data/model/rule/Skill/workflow/digital employee)
• Avoid naming conflicts with due diligence

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

1. Workers must go through CapabilityRuntime

• 12 unintegrated workers: Modify each to runtime.call({capability, itemType, params})
• Retain workers as "parameter configurators + capability orchestrators", 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, with all routes pointing to boss-scheduler
• Delete after 1 version

1. mtclaw empty socket handling

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

1. Main path for self-evolution

• Connect rule-evolution.js to the CapabilityRuntime post-execution hook
• After each capability execution: update hit_count + collect user_correction → generate candidate rules

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

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

III. Immediate optimizations to be executed this time (three P0 items)

Refer to the 'Optimization Execution Record' below.