BossAgents 编码任务规划

基于设计文档 design.md 和需求规格 spec.md 生成

生成日期：2026-07-20

项目：BossAgents — 工业界的数据员工（HICOOL MTClaw智能体赛道）

1. Loop闭环引擎三种模式

目标：在LiteScheduler中扩展LoopEngine，支持monitor/goal_driven/self_repair三种闭环模式，与YAML Profile的loop字段完全对齐

1.1 实现LoopEngine核心状态机

• [ ] 在 server/boss-scheduler/loop-engine.js 中创建LoopEngine类，实现Idle→Checking→Executing/RepairAndVerify→Completed状态机，支持三种mode（monitor/goal_driven/self_repair）的执行策略分支 [P0] [M]
• [ ] 实现 run(staffId, loopConfig, params) 方法：根据loop.mode选择执行策略，循环执行直到condition满足或达到max_iterations，返回 { iterations, results, final_status } [P0] [M]
• [ ] 实现monitor模式：cron触发→检查condition→满足则执行action→不满足则等待下次触发 [P0] [S]
• [ ] 实现goal_driven模式：cron触发→检查goal→未达成则执行action→达成则完成 [P0] [S]
• [ ] 实现self_repair模式：cron触发→执行repair→执行validate→校验失败则重试→校验通过则完成，最多重试max_iterations次 [P0] [M]
• [ ] 实现Loop执行记录持久化：每次迭代记录 { iteration, timestamp, action_result, condition_met }，Loop完成后汇总写入 server/data/loop-logs/ [P1] [S]

依赖：CapabilityRuntime（已实现）、LiteScheduler（已实现）

验收：对DS-VEN-LOOP-001执行self_repair模式，验证修复→校验→重试循环，最多3次迭代

1.2 扩展YAML Profile的loop字段

• [ ] 在 server/boss-scheduler/profiles/local.yaml 中为Loop型员工添加mode字段：DS-PROC-LOOP-001添加 mode: monitor，DS-BOSS-LOOP-001添加 mode: goal_driven，DS-VEN-LOOP-001添加 mode: self_repair，DS-STOCK-LOOP-001添加 mode: monitor [P0] [S]
• [ ] 在 server/boss-scheduler/staff-registry.js 中扩展loop配置解析，支持读取mode/trigger/condition/action/max_iterations字段 [P0] [S]

依赖：无

验收：StaffRegistry加载local.yaml后，Loop型员工的loop.mode字段可正确读取

1.3 集成LoopEngine到LiteScheduler

• [ ] 在 server/boss-scheduler/lite-scheduler.js 中集成LoopEngine实例，当员工配置loop.enabled=true时，通过LoopEngine执行闭环逻辑替代原有简单cron调度 [P0] [M]
• [ ] 在LiteScheduler的cron回调中，检测员工loop配置，若loop.mode存在则调用LoopEngine.run()，否则走原有逻辑 [P0] [S]
• [ ] 在 server/routes/digital-staff-routes.js 中扩展Loop API，GET /api/digital-staff/loops/:id 返回loop执行记录（迭代次数、每次迭代结果、最终状态） [P1] [S]

依赖：1.1、1.2

验收：LiteScheduler启动后，Loop型员工按配置的mode执行闭环，执行记录可通过API查询

2. 43个专业数字员工编排补全

目标：在local.yaml中补充缺失的数字员工定义，为Pipeline型员工补充完整pipeline步骤，确保43个员工覆盖10+领域

2.1 补充缺失的数字员工定义

• [ ] 在 server/boss-scheduler/profiles/local.yaml 中补充缺失员工定义（当前50个，需校对是否达到43个专业员工目标），重点补充：数据修复员(DS-VEN-LOOP-001已有但需确认loop配置完整)、价格监控员(DS-PROC-LOOP-001已有)、目标追踪员(DS-BOSS-LOOP-001已有)、库存预警员(DS-STOCK-LOOP-001已有) [P1] [S]
• [ ] 为所有Loop型员工确认loop配置完整性：enabled/trigger/condition/action/max_iterations/mode字段齐全 [P0] [S]
• [ ] 为所有Pipeline型员工补充完整pipeline步骤定义：确认DS-SUPPLY-001(identify→repair→generate)、DS-COST-001(compare→optimize)、DS-REVIEW-001(identify→compare→generate)等pipeline配置完整 [P1] [M]

依赖：1.2（loop.mode字段）

验收：GET /api/digital-staff/ 返回的员工数量≥43，所有Loop型员工loop.mode字段非空，Pipeline型员工pipeline步骤完整

2.2 补充协同事件配置

• [ ] 在local.yaml中为有协同关系的员工补充collaboration配置，如DS-BIZ-001的onComplete触发DS-REPORT-001，添加condition字段（如 result.success === true）和params字段 [P1] [S]
• [ ] 确认所有员工的keywords覆盖中英文关键词，与StaffRouter的STAFF_KEYWORDS对齐 [P1] [S]

依赖：3.1（CollaborationChain支持condition）

验收：DS-BIZ-001执行完成且result.success=true时，自动触发DS-REPORT-001

3. 协同事件onComplete条件触发

目标：扩展CollaborationChain支持onComplete条件表达式、动态负载参数传递、循环依赖检测

3.1 扩展CollaborationChain条件判断

• [ ] 在 server/boss-scheduler/collaboration-chain.js 的onTaskCompleted方法中，增加collaboration.condition条件表达式判断：若condition存在，在vm.createContext安全沙箱中执行，仅当条件为true时触发下游员工 [P0] [M]
• [ ] 扩展collaboration.params动态负载支持：在触发下游员工时，将collaboration.params与_upstreamResult合并传递，支持从上游结果中提取参数（如 params.order_id = upstreamResult.order_id） [P0] [S]
• [ ] 支持collaboration.next为数组类型：当next为多个目标员工ID时，按顺序依次触发 [P1] [S]

依赖：无

验收：DS-BIZ-001配置 collaboration: { next: DS-REPORT-001, condition: 'result.success === true' }，执行成功时触发DS-REPORT-001，失败时不触发

3.2 循环依赖检测

• [ ] 在CollaborationChain构造函数或初始化阶段，遍历所有员工的collaboration配置，构建有向图，使用DFS检测循环依赖 [P0] [M]
• [ ] 检测到循环依赖时，记录错误日志并抛出配置异常，阻止服务启动（或降级为跳过该协同链） [P0] [S]
• [ ] 在 server/routes/collaboration-chain-api.js 的execute-chain接口中，增加循环依赖运行时检测，防止运行时动态配置导致的循环 [P1] [S]

依赖：3.1

验收：配置DS-A→DS-B→DS-A循环依赖时，服务启动报错或日志标记circular_dependency_detected

4. MTClaw加速效果统计

目标：新增MTClawStatsCollector统计组件，聚合L1/L2/L3命中分布、加速比、降级次数，持久化到SQLite

4.1 实现MTClawStatsCollector组件

• [ ] 在 server/core/mtclaw-stats-collector.js 中创建MTClawStatsCollector类，维护内存统计对象 { total_calls, accelerated_calls, degraded_calls, failed_calls, avg_duration_ms, l1_hits, l2_hits, l3_hits, acceleration_ratio } [P0] [M]
• [ ] 实现 record(routeResult) 方法：每次MTClaw调用后累加统计，routeResult包含 { layer: 'l1'|'l2'|'l3'|'degraded'|'failed', duration_ms, source } [P0] [S]
• [ ] 实现 getStats() 方法：返回当前聚合统计，计算acceleration_ratio = 云端平均耗时/MTClaw平均耗时 [P0] [S]
• [ ] 实现定时持久化：每60s将内存统计写入 server/data/core_runtime.db 的mtclaw_stats表，表结构 { id, total_calls, accelerated_calls, degraded_calls, failed_calls, avg_duration_ms, l1_hits, l2_hits, l3_hits, acceleration_ratio, recorded_at } [P1] [M]
• [ ] 实现启动时从SQLite恢复统计：服务重启后从mtclaw_stats表加载最近一条记录作为初始值 [P1] [S]

依赖：SQLite（core_runtime.db，已存在）

验收：连续调用MTClaw 10次后，getStats()返回正确的L1/L2/L3命中次数和加速比

4.2 集成MTClawStatsCollector到调度链路

• [ ] 在 server/scheduler/mtclaw-scheduler.js 中注入MTClawStatsCollector实例，每次MTClaw调用后调用record()上报路由结果 [P0] [S]
• [ ] 在 server/routes/scheduler-routes.js 的_tryMTClawPreRoute方法中，MTClaw调用完成后上报统计 [P0] [S]
• [ ] 在 server/boss-scheduler/lite-scheduler.js 的getMTClawStats方法中，返回MTClawStatsCollector.getStats()结果 [P1] [S]

依赖：4.1

验收：GET /api/scheduler/status 返回的mtclaw_stats字段包含完整的L1/L2/L3命中分布和加速比

5. MockDataDetector组件

目标：新增Mock数据检测组件，自动扫描执行结果中的mock关键词，确保演示真实性

5.1 实现MockDataDetector

• [ ] 在 server/core/mock-data-detector.js 中创建MockDataDetector类，实现 scan(result) 方法，输入执行结果（文本或JSON），输出 { is_mock: boolean, mock_indicators: string[], scanned_at: string } [P0] [M]
• [ ] 实现关键词正则扫描：匹配mock/测试/示例/dummy/placeholder/fake/sample/MockData/test_data等关键词（不区分大小写），JSON结果递归扫描所有字符串值 [P0] [S]
• [ ] 实现白名单机制：允许配置排除关键词（如"单元测试"中的"测试"不算mock），避免误报 [P1] [S]
• [ ] 导出为独立模块，可在路由层和演示流程中调用 [P0] [S]

依赖：无外部依赖，纯工具模块

验收：scan({ content: "这是一个示例数据" }) 返回 { is_mock: true, mock_indicators: ["示例"] }

5.2 集成MockDataDetector到演示流程

• [ ] 在 server/routes/scheduler-routes.js 的演示相关接口中，演示完成后自动调用MockDataDetector.scan()扫描所有阶段输出 [P0] [S]
• [ ] 在演示API响应中增加mock_detection字段，返回检测结果 [P0] [S]

依赖：5.1

验收：演示API返回结果包含 mock_detection: { is_mock: false, mock_indicators: [], scanned_at: "..." }

6. CircuitBreaker熔断器组件

目标：新增CircuitBreaker熔断器，连续降级≥5次触发熔断，60s后半开恢复，集成到MTClawScheduler和LLMRouter

6.1 实现CircuitBreaker状态机

• [ ] 在 server/core/circuit-breaker.js 中创建CircuitBreaker类，实现closed→open→half_open状态机 [P0] [M]
• [ ] 实现 recordSuccess() 方法：成功时重置失败计数器，若当前为half_open则切换到closed [P0] [S]
• [ ] 实现 recordFailure() 方法：失败时累加failure_count，连续失败≥5次（threshold可配置）切换到open状态，记录opened_at时间戳 [P0] [S]
• [ ] 实现 getState() 方法：若当前为open且距opened_at≥60s（recovery_timeout可配置），切换到half_open并返回half_open；否则返回当前状态 [P0] [S]
• [ ] 实现 canExecute() 方法：closed时返回true，open时返回false，half_open时返回true（仅放行1个探测请求） [P0] [S]
• [ ] 实现熔断事件日志：每次状态切换记录 { from, to, reason, timestamp } [P1] [S]

依赖：无外部依赖

验收：连续调用recordFailure() 5次后getState()返回open，60s后getState()返回half_open

6.2 集成CircuitBreaker到调度链路

• [ ] 在 server/scheduler/mtclaw-scheduler.js 中创建MTClaw的CircuitBreaker实例，MTClaw调用前检查canExecute()，调用后根据结果调用recordSuccess()/recordFailure() [P0] [M]
• [ ] 在 server/digital-staff/smart-llm-router.js 中注入CircuitBreaker引用（已有circuitBreakerRef字段），降级时调用recordFailure() [P0] [S]
• [ ] 在 server/digital-staff/llm-router.js 中使用已有的setCircuitBreakerRef(cb)方法接收CircuitBreaker实例 [P1] [S]
• [ ] 当CircuitBreaker处于open状态时，MTClawScheduler跳过MTClaw调用，直接降级到LLM Router [P0] [S]

依赖：6.1

验收：MTClaw连续失败5次后，后续请求自动跳过MTClaw走LLM Router，60s后尝试恢复

7. 数据资产8类估值清单

目标：扩展AssetValuator支持按8类资产分别估值的明细输出，总估值目标¥150,000

7.1 扩展AssetValuator估值明细

• [ ] 在 server/core/asset-valuator.js 中扩展valuate方法，增加 per_asset_type 参数，当per_asset_type=true时，按8类资产（Part/BOM/Vendor/Document/ECR/ECO/ProcessSpec/Equipment）分别执行三阶段估值 [P0] [M]
• [ ] 实现每类资产的估值明细输出：cost_breakdown/income_breakdown/market_breakdown按资产类型拆分，输出 { asset_type, asset_count, cost_value, income_value, market_value, weighted_value } 数组 [P0] [M]
• [ ] 调整估值参数使总估值≈¥150,000：在 server/boss-scheduler/profiles/valuation.yaml 中校准采集成本/处理成本/存储成本/维护成本/折现率/市场参考价等参数 [P0] [S]
• [ ] 估值结果标注来源：每项估值标记 source: 'rule_engine' | 'llm_estimated' | '真实测量'，禁止无来源数值 [P0] [S]

依赖：AssetValuator（已实现）、valuation.yaml（已存在）

验收：调用valuate('all', { per_asset_type: true })返回8类资产分别估值+总估值≈¥150,000，每项标注来源

7.2 估值API扩展

• [ ] 在 server/routes/platform-asset.js 中扩展估值API，支持 ?per_asset_type=true 查询参数，返回8类资产估值明细 [P1] [S]
• [ ] 在估值报告生成中包含8类资产估值表格，每行显示资产类型/数量/成本法/收益法/市场法/加权估值 [P1] [S]

依赖：7.1

验收：GET /api/platform-asset/valuation?per_asset_type=true 返回8类资产估值明细

8. 规则引擎三级防线通过率统计

目标：新增RuleEngineStats组件，聚合create_pre/validate/create_post三级防线通过率，目标≥89%

8.1 实现RuleEngineStats组件

• [ ] 在 server/core/rule-engine-stats.js 中创建RuleEngineStats类，维护按scope分类的统计 { scope, total_executions, passed, failed, pass_rate, avg_duration_ms, last_calculated_at } [P0] [M]
• [ ] 实现 record(scope, result, duration_ms) 方法：每次规则执行后累加统计，result为passed/failed [P0] [S]
• [ ] 实现 getPassRate(scopes) 方法：计算指定scope列表的加权平均通过率，权重为各scope执行次数占比 [P0] [S]
• [ ] 实现三级防线通过率计算：getThreeLevelPassRate() 返回create_pre/validate/create_post的加权平均通过率 [P0] [S]

依赖：UnifiedRuleEngine（已实现）

验收：执行100次规则后，getThreeLevelPassRate()返回≥89%的通过率

8.2 集成RuleEngineStats到规则引擎

• [ ] 在 server/core/rule-engine.js 的execute方法中，每次规则执行后调用RuleEngineStats.record()上报结果和耗时 [P0] [S]
• [ ] 在 server/routes/rule-engine.js 中新增GET /api/rule-engine/stats接口，返回三级防线通过率统计 [P1] [S]
• [ ] 在 server/routes/platform-asset.js 中已有的getRuleEngineStats()方法中，返回RuleEngineStats的计算结果 [P1] [S]

依赖：8.1

验收：GET /api/rule-engine/stats 返回 { create_pre: { pass_rate: 0.92 }, validate: { pass_rate: 0.88 }, create_post: { pass_rate: 0.90 }, weighted_pass_rate: 0.90 }

9. 调度器状态查询接口扩展

目标：扩展GET /api/scheduler/status接口，返回完整状态（MTClaw可用性、GPU状态、熔断器状态、加速效果统计）

9.1 扩展status接口返回字段

• [ ] 在 server/routes/scheduler-routes.js 的GET /api/scheduler/status处理中，增加返回字段：mtclaw_available（boolean）、gpu_available（boolean）、mtclaw_circuit_breaker（'closed'|'open'|'half_open'） [P0] [M]
• [ ] 增加mtclaw_stats字段：从MTClawStatsCollector.getStats()获取加速效果统计 [P0] [S]
• [ ] 增加staff_count字段：从StaffRegistry获取已注册员工数量 [P1] [S]
• [ ] 增加uptime_seconds字段：记录服务启动时间，计算运行时长 [P1] [S]
• [ ] 确保响应格式符合设计文档的SchedulerStatusResponse接口签名 [P0] [S]

依赖：4.2（MTClawStatsCollector）、6.2（CircuitBreaker）

验收：GET /api/scheduler/status 返回 { scheduler_type, model_provider, mtclaw_available, gpu_available, mtclaw_circuit_breaker, mtclaw_stats, staff_count, uptime_seconds }

10. 数字员工API路由对齐

目标：确保GET /api/digital-staff/和GET /api/digital-staff/:id接口返回格式与spec定义对齐

10.1 对齐数字员工列表接口

• [ ] 在 server/routes/digital-staff-routes.js 中确认GET /api/digital-staff/list返回格式包含：id/name/title/capability/department/enabled/mtclaw_enabled/pipeline/loop/collaboration/keywords字段 [P0] [M]
• [ ] 确认GET /api/digital-staff/:id返回员工详情，包含完整的pipeline步骤定义、loop配置、collaboration配置 [P0] [S]
• [ ] 确保loop字段返回 { enabled, mode } 格式（与设计文档DigitalStaffListResponse对齐） [P0] [S]
• [ ] 确保collaboration字段返回 { next } 格式 [P1] [S]

依赖：1.2（loop.mode字段）

验收：GET /api/digital-staff/ 返回的员工列表格式与spec定义的DigitalStaffListResponse完全一致

11. 全链路闭环演示6阶段集成

目标：在演示页面中集成Step5数据资产化和Step6私有化部署的真实执行，每阶段标注真实耗时，演示完成后自动运行MockDataDetector

11.1 后端演示API实现

• [ ] 在 server/routes/scheduler-routes.js 中实现POST /api/demo/full-loop接口，按6阶段顺序执行：Step1产品创建→Step2 BOM生成→Step3商城上架→Step4内容+文档→Step5数据资产化→Step6私有化部署 [P0] [L]
• [ ] Step1：调用CapabilityRuntime.create(Part, data)，记录duration_ms [P0] [S]
• [ ] Step2：调用CapabilityRuntime.generate(BOM, {part_id})，记录duration_ms [P0] [S]
• [ ] Step3：确定性操作，规则引擎直接处理（自动生成商品页面+SKU），记录duration_ms [P0] [S]
• [ ] Step4：并行调用CapabilityRuntime.generate(Content, params)生成海报/说明书/宣传册，记录duration_ms [P0] [S]
• [ ] Step5：调用AssetValuator.valuate('all', { per_asset_type: true })，输出8类资产估值清单+总估值¥150,000，记录duration_ms [P0] [S]
• [ ] Step6：展示私有化部署配置（从体验到企业专属平台），记录duration_ms [P1] [S]
• [ ] 演示完成后调用MockDataDetector.scan()扫描所有阶段输出，返回mock_detection结果 [P0] [S]
• [ ] 返回DemoResult格式：{ stages: DemoStage[6], total_duration_ms, mock_detection, report_path } [P0] [S]

依赖：5.1（MockDataDetector）、7.1（8类资产估值）

验收：POST /api/demo/full-loop 返回6阶段真实执行结果，每阶段有duration_ms，总耗时≤60s，mock_detection.is_mock=false

11.2 前端演示页面集成

• [ ] 在 public/demo/closed-loop.html 中集成Step5数据资产化展示：8类资产估值表格+总估值¥150,000 [P0] [M]
• [ ] 在 public/demo/closed-loop.html 中集成Step6私有化部署展示：部署配置信息+从体验到企业专属平台的说明 [P1] [S]
• [ ] 每阶段标注真实测量耗时（从API返回的duration_ms字段读取），格式为"真实测量：~Xms" [P0] [S]
• [ ] 演示完成后显示Mock检测结果：is_mock=false时显示"✓ 真实数据验证通过"，is_mock=true时列出mock指标 [P0] [S]
• [ ] 同步更新 public/demo/real-exec.html 的6阶段展示逻辑 [P1] [M]

依赖：11.1

验收：打开closed-loop.html，6阶段依次执行，每阶段显示真实耗时，Step5显示8类资产估值¥150,000，Step6显示私有化部署，最终显示Mock检测通过

12. 六大落地案例模块

目标：新增case-studies.yaml配置文件和案例展示API，展示6个真实客户案例

12.1 案例数据配置

• [ ] 创建 server/boss-scheduler/profiles/case-studies.yaml，定义6大落地案例：麻城将军红（农产品加工）、罗田气象局（气象服务）、大柴湖移民纪念馆（文旅）、某省电力公司（电力）、高端装备工艺数据修复（高端装备）、贵州磷化集团（化工） [P0] [M]
• [ ] 每个案例包含：id/name/industry/deployment_mode/summary/metrics，metrics中每项标注source（真实测量/客户反馈/内部统计） [P0] [S]
• [ ] 每个案例的量化指标包含：数据治理量、通过率提升、人工节省等 [P1] [S]

依赖：无

验收：case-studies.yaml包含6个案例，每个案例有完整的metrics和source标注

12.2 案例展示API

• [ ] 创建 server/routes/case-studies-routes.js，实现GET /api/case-studies/返回案例列表，GET /api/case-studies/:id返回案例详情 [P0] [M]
• [ ] 从case-studies.yaml加载案例数据，缓存到内存 [P0] [S]
• [ ] 在 server/server.js 中注册case-studies路由 [P0] [S]
• [ ] 响应格式符合设计文档的CaseStudyListResponse接口签名 [P0] [S]

依赖：12.1

验收：GET /api/case-studies/ 返回6个案例列表，GET /api/case-studies/macheng 返回麻城将军红案例详情

13. 集成测试与验证

目标：端到端验证所有新增和扩展功能，确保全链路闭环演示可运行

13.1 核心组件单元测试

• [ ] 验证LoopEngine三种模式：在 server/tests/ 中创建loop-engine.test.js，测试monitor/goal_driven/self_repair三种模式的执行和终止条件 [P0] [M]
• [ ] 验证CircuitBreaker状态机：测试closed→open→half_open→closed完整状态转换 [P0] [S]
• [ ] 验证MockDataDetector：测试包含mock关键词和不包含mock关键词的输入 [P0] [S]
• [ ] 验证MTClawStatsCollector：测试统计累加、加速比计算、持久化恢复 [P1] [S]
• [ ] 验证RuleEngineStats：测试三级防线通过率计算 [P1] [S]
• [ ] 验证CollaborationChain条件触发：测试condition为true/false时的触发行为 [P0] [S]

依赖：1.1、3.1、5.1、6.1、4.1、8.1

验收：所有测试用例通过

13.2 全链路闭环演示端到端验证

• [ ] 启动BossAgents服务(:3006)，验证GET /api/scheduler/status返回完整状态 [P0] [S]
• [ ] 执行POST /api/demo/full-loop，验证6阶段顺序执行，每阶段返回真实耗时 [P0] [M]
• [ ] 验证Step5数据资产化返回8类资产估值+总估值≈¥150,000 [P0] [S]
• [ ] 验证MockDataDetector扫描结果is_mock=false [P0] [S]
• [ ] 验证CircuitBreaker在MTClaw不可用时自动熔断和恢复 [P1] [S]
• [ ] 验证Loop型员工(DS-VEN-LOOP-001)按self_repair模式执行闭环 [P1] [S]
• [ ] 验证协同事件(DS-BIZ-001→DS-REPORT-001)条件触发 [P1] [S]
• [ ] 验证GET /api/digital-staff/返回43+个员工列表 [P0] [S]
• [ ] 验证GET /api/case-studies/返回6个案例 [P1] [S]

依赖：所有前置任务

验收：全链路闭环演示6阶段总耗时≤60s，Mock检测通过，所有API返回正确格式

13.3 环境兼容性验证

• [ ] 在无GPU环境下验证：自动切换云端DeepSeek，调度逻辑不变 [P1] [S]
• [ ] 在MTClaw不可用环境下验证：自动降级到BuiltinScheduler，所有API入口响应格式一致 [P1] [S]
• [ ] 在MTT AIBOOK（AIOS 1.4.2 / Ubuntu 22.04）上验证可直接运行 [P1] [S]

依赖：13.2

验收：四种部署场景（MTClaw+GPU/MTClaw无GPU/无MTClaw+GPU/无MTClaw无GPU）下API入口和响应格式完全一致

任务依赖关系图

1.1 LoopEngine核心 ──→ 1.3 集成到LiteScheduler
1.2 YAML loop字段  ──→ 1.3
                      ──→ 10.1 数字员工API对齐

3.1 协同条件触发  ──→ 3.2 循环依赖检测
                  ──→ 2.2 协同事件配置

4.1 StatsCollector ──→ 4.2 集成到调度链路 ──→ 9.1 status接口扩展
6.1 CircuitBreaker ──→ 6.2 集成到调度链路 ──→ 9.1

5.1 MockDetector  ──→ 5.2 集成到演示 ──→ 11.1 演示API
7.1 8类估值      ──→ 7.2 估值API     ──→ 11.1
11.1 演示API     ──→ 11.2 前端页面

12.1 案例数据    ──→ 12.2 案例API

所有任务 ──→ 13.1 单元测试 ──→ 13.2 端到端验证 ──→ 13.3 环境兼容

优先级汇总

| 优先级 | 任务数 | 说明 |

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

| P0（必须完成） | 48 | 核心功能，影响演示和比赛评分 |

| P1（应该完成） | 23 | 增强功能，提升完整度和体验 |

| P2（可以延后） | 0 | 无 |

工作量汇总