BossAgents Digital Employee Optimization Plan (Revised Based on Existing Implementation)

Revised based on the 2026-06-14 strategic plan, incorporating existing code implementations of BossScheduler + LiteScheduler

I. First, correct factual errors in the plan

1.1 Employee Statistics Correction

The plan states "13 active employees". The actual situation is:

| Original Employee ID | Actual Status | Correction |

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

| DS-BOSS-001 | ❌ Not present in YAML profile | Old seed, inactive |

| DS-BOSS-002 | ❌ Not present in YAML profile | Old seed, inactive |

| ⟦DS-SCSAI-001⟧ | ❌ Not present in YAML profile | Old seed, inactive |

| DS-ECR-001 | ⏸️ No worker/capability, scheduling skipped | Empty shell |

| DS-REVIEW-001 | ✅ Present, but worker="" | Pure capability routing |

| DS-DATA-001 | ✅ Present, in cron scheduling | Data Synchronization Agent |

| DS-VEN-001 | ✅ Present, in cron scheduling | Vendor Steward |

| DS-SYS-001 | ✅ Present | System Operations Engineer (2 with the same name) |

| DS-PROC-001 | ✅ Exists | Procurement Assistant (Core) |

| DS-COST-001 | ✅ Exists | Cost Optimizer |

| DS-CONTENT-001 | ✅ Exists | Content Generator |

| DS-REPORT-001 | ✅ Exists | Report Analyst |

| DS-OPS-001 | ✅ Exists | Data Steward |

There are actually 11 active employees, with 4 leaning towards operations (data-clerk, data-caretaker, system-health x 2).

1.2 Correction for "Only 5 out of 7 capabilities are used"

Current LiteScheduler CAPABILITY_MAP (lite-scheduler.js:31-39):

identify: 'identify',    // ✅ 被 data-clerk 使用
validate: 'validate',    // ✅ 被 ECR/SYS 使用
repair: 'repair',        // ⚠️ 接口存在，0 次实际调用
optimize: 'optimize',    // ⚠️ 接口存在，0 次实际调用
compare: 'compare',      // ⚠️ 接口存在，procurement 硬编码不走
generate: 'generate',    // ⚠️ 接口存在，content/report 硬编码不走
create: 'create',        // ✅ 被 content 使用
inspect: 'inspect',      // ⚠️ 接口存在，0 次调用

实际情况：3 种能力被使用（identify/validate/create），5 种闲置。不是"7中5"，是8中3。

1.3 Core Issue: "Hardcoded workers" is the most severe problem

The proposal states "procurement/health/caretaker bypass CapabilityRuntime". Code review reveals:

| Worker | Status | Problem |

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

| procurement.js | ❌ Fully hardcoded | 9000 bytes self-contained: implements supplier query, email sending, price comparison, PO generation all by itself |

| system-health.js | ❌ Fully hard-coded | Self-query SCSAI, self-template coverage check |

| data-clerk.js | ⚠️ Partially hard-coded | Synchronized via CapabilityRuntime identify, but sync logic self-implemented |

| cost-optimizer.js | ⚠️ Partially hard-coded | Calls local API, bypasses capability routing |

| vendor-review.js | ❌ Fully hard-coded | Self SCSAI query + self-generate report |

This is the core architectural issue—the capability framework is effectively non-functional.

II. Optimization Plan Based on Current Code State

Optimization 1: Rule Engine Syntax Fix (Code Available for Repair)

File: rule-engine.js:1570 + generate-operation-rules.js:319

Status: JSON.parse in _deserializeRule is fixed, but the data writing end remains plain text.

// generate-operation-rules.js:319 — 当前错误写入
tags: 'validate,date_format'  // 纯文本！

// 应改为
tags: JSON.stringify(['validate', 'date_format'])  // JSON 数组

操作：改 generate-operation-rules.js 中所有 insRule.run() 的 tags 参数 → 重新跑 node scripts/generate-operation-rules.js --full

Impact: After the fix, CapabilityRuntime's identify/validate can use the rule engine, no longer downgrading to LLM every time.

Optimization 2: Collaboration Chain Integration (Code Already Implemented, Only Needs Activation)

Current Collaboration Infrastructure Status:

| Component | Code Location | Status |

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

| taskQueue.createTask() | task-queue.js:38 | ✅ Available |

| taskQueue.completeTask() + collaborationNext | task-queue.js:94-113 | ✅ Available |

| _processStaffTasks() Consume Pending Tasks | lite-scheduler.js:306-329 | ⚠️ Activated (Fixed Today) |

| cron Pre-processing | lite-scheduler.js:357-368 | ⚠️ Activated (Fixed Today) |

Implemented Collaboration Task Creation (New Today):

// procurement.js Phase 3 — 采购完成后
ctx.taskQueue.createTask({ assignedTo: 'DS-COST-001', type: 'cost_review' });
ctx.taskQueue.createTask({ assignedTo: 'DS-VEN-001', type: 'vendor_review' });

// vendor-review.js — 评分下降
ctx.taskQueue.createTask({ assignedTo: 'DS-PROC-001', type: 'vendor_alert' });

下次 cron 轮询时：目标员工会先处理协作任务再执行自己的定时任务。

Missing but can be added:

| Source | Collaboration Target | Condition | Code Change |

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

| data-clerk sync complete | DS-REPORT-001 Update Dashboard | Has synchronized data | data-clerk.js end +10 lines |

| cost-optimizer finds alternative material | DS-PROC-001 Re-request Quote | Alternative material found | cost-optimizer.js end +10 lines |

| Content Publishing Article | DS-REPORT-001 Generate Marketing Performance Report | Publish Success | content.js end +10 lines |

Optimization 3: Business Daily Report MVP (Start from scratch, not dependent on existing workers)

Approach: Bypass CapabilityRuntime, directly write a lightweight worker

Code Structure:

server/boss-scheduler/workers/biz-daily.js  (约 120 行)

数据来源：

| Data Item | Source Code | Retrieval Method |

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

| Yesterday's Purchase Orders | findPurchaseOrders() | Read data/purchase-orders/*.json |

| Inventory Alerts | querySCSAIStock() | SCSAI Part.qty_on_hand |

| Vendor Score | readVendorReports() | Read data/reports/vendor-review-*.html |

| System Health | readSystemHealthLog() | Read recent health records from staffLogs |

| Content Publishing | queryContentLog() | Read content records from staffLogs |

YAML Configuration:

- id: DS-BIZ-001
  name: 小智-经营日报
  title: 经营日报生成器
  description: 每天早7点生成经营日报并推送飞书
  cron: "0 7 * * 1-5"
  worker: report-analyst    # 复用 report-analyst worker 的报告生成能力
  llm: true
  keywords: ["经营", "日报", "利润", "分析", "报告", "business", "daily", "report"]
  params:
    reportType: daily_brief
    channels: ["feishu", "email"]

实现要点：

• Reuse the generateAndSendReport method from report-analyst.js
• Add daily_brief type, not via LLM, use template concatenation
• Push to Feishu: use existing feishu-bot.pushMessage()

Optimization 4: procurement uses CapabilityRuntime (architectural change, requires caution)

Current state: procurement.js is a self-contained 9000-byte hardcoded module

Gradual migration plan:

Step 1 (without modifying procurement.js): Add DS-SCM-001 as a capability routing employee

- id: DS-SCM-001
  name: 小智-供应智囊
  capability: create        # 走 CapabilityRuntime Path 2
  item_types: [Vendor, Part, BOM]
  llm: true

此时 DS-PROC-001 保留不动。两个员工并行运行。

Step 2: Procurement v4 (bypass worker, use capability chain)

// 新文件：server/boss-scheduler/workers/procurement-v4.js
// 仅作为 CapabilityRuntime 的编排层，实际执行走能力
async function runProcurementV4(staff, ctx, intent, parameters) {
  const { capability } = ctx;
  
  // identify — 找供应商
  const vendors = await capability.identify({ 
    item_type: 'Vendor', 
    data: { product, maxResults: 5 } 
  });
  
  // compare — 比价
  const best = await capability.compare({
    item_type: 'Vendor',
    candidates: vendors,
    criteria: { product, quantity, budget }
  });
  
  // create — Generate PO
  const po = await capability.create({
    item_type: 'PurchaseOrder',
    data: { vendor: best, product, quantity, amount }
  });
}

Step 3：DS-PROC-001 标记 deprecated，DS-SCM-001 成为主入口

Optimization 5: Customer Steward DS-CRM-001 (requires new database table)

Evidence of missing customer data in current system:

| Data | Source | Status |

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

| Customer / Company | SCSAI Customer / Company | Possibly in SCSAI, not currently queried by AML |

| Sales Orders | SCSAI Sales Order | Possibly in SCSAI, not currently queried |

| Accounts Receivable | No data source | ❌ Completely missing |

| Delivery Records | No data source | ❌ Completely missing |

Two-phase approach:

Step 1: Add SCSAI customer query capability

// capability-runtime.js identify 方法中
// Identify item_type: 'Customer' 时查 SCSAI
const aml = `<AML><Item type="Customer" action="get" select="id,name,email,phone" maxRecords="50"></Item></AML>`;

Step 2：新增本地 customers 和 orders 表

CREATE TABLE customers (
  id TEXT PRIMARY KEY,
  name TEXT, email TEXT, phone TEXT,
  company TEXT, credit_limit REAL, 
  last_order_date TEXT, total_orders INTEGER
);

CREATE TABLE orders (
  id TEXT PRIMARY KEY,
  customer_id TEXT, product TEXT, quantity INTEGER,
  amount REAL, status TEXT, delivery_date TEXT,
  payment_status TEXT
);

三、分阶段实施路线（基于代码实际）

| 阶段 | 内容 | 工期 | 核心文件 | 前置依赖 |

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

| P0 | Rule engine tags fix + regenerate data | 30 minutes | generate-operation-rules.js | None |

| P0-2 | Collaboration chain completion (data-clerk+content+cost) | 1 hour | Add 10 lines at the end of each worker file | None |

| P1 | Business Daily Report DS-BIZ-001 | Half a day | workers/biz-daily.js (new) | None |

| P2 | Procurement v4 capability enablement (DS-SCM-001 parallel run) | 1 day | workers/procurement-v4.js | P0 |

| P3 | CRM customer data channel (SCSAI Customer query) | 1 day | capability-runtime.js | None |

| P4 | Frontend boss dashboard refactoring | 1 day | DigitalStaff.vue + new page | P1 |

Recommended execution order: P0 → P1 → P0-2 → P2 → P3 → P4

Execute P0 (30-minute rule engine fix) + P1 (half-day Business Daily Report) first, so the boss can see the daily report in Feishu tomorrow. This is the fastest path to show results.

IV. Summary of Technical Debt (Must Be Addressed)