BossAgents Coding Task Planning

Generate based on design document design.md and requirements specification spec.md

Generation Date: 2026-07-20

Project: BossAgents — Data Employees for the Industry (HICOOL MTClaw Agent Track)

1. Three Modes of the Loop Closed-Loop Engine

Objective: Extend the LoopEngine in LiteScheduler to support three closed-loop modes—monitor, goal_driven, and self_repair—fully aligned with the loop field in the YAML Profile.

1.1 Implement the LoopEngine Core State Machine

• [ ] Create the LoopEngine class in server/boss-scheduler/loop-engine.js, implementing the Idle→Checking→Executing/RepairAndVerify→Completed state machine, with execution strategy branches supporting the three modes (monitor/goal_driven/self_repair) [P0] [M]
• [ ] Implement the run(staffId, loopConfig, params) method: Select execution strategy based on loop.mode, loop execution until the condition is met or max_iterations is reached, return { iterations, results, final_status } [P0] [M]
• [ ] Implement monitor mode: cron trigger → check condition → execute action if met → wait for next trigger if not met [P0] [S]
• [ ] Implement goal_driven mode: cron trigger → check goal → execute action if not achieved → complete if achieved [P0] [S]
• [ ] Implement self_repair mode: cron trigger → execute repair → execute validate → retry if validation fails → complete if validation passes, up to max_iterations retries [P0] [M]
• [ ] Implement Loop execution record persistence: each iteration records { iteration, timestamp, action_result, condition_met }, writes summary to server/data/loop-logs/ after Loop completion [P1] [S]

Dependencies: CapabilityRuntime (implemented), LiteScheduler (implemented)

Acceptance: Execute self_repair mode for DS-VEN-LOOP-001, verify the repair→validate→retry loop, up to 3 iterations.

1.2 Extend the loop field in the YAML Profile

• [ ] In server/boss-scheduler/profiles/local.yaml, add a mode field for Loop-type staff: add mode: monitor for DS-PROC-LOOP-001, mode: goal_driven for DS-BOSS-LOOP-001, mode: self_repair for DS-VEN-LOOP-001, mode: monitor for DS-STOCK-LOOP-001 [P0] [S]
• [ ] In server/boss-scheduler/staff-registry.js, extend the loop configuration parsing to support reading the mode/trigger/condition/action/max_iterations fields [P0] [S]

Dependencies: None

Acceptance: After StaffRegistry loads local.yaml, the loop.mode field for Loop-type staff can be correctly read.

1.3 Integrating LoopEngine into LiteScheduler

• [ ] In server/boss-scheduler/lite-scheduler.js, integrate the LoopEngine instance. When an employee's configuration has loop.enabled=true, use LoopEngine to execute the closed-loop logic instead of the original simple cron scheduling [P0] [M]
• [ ] In the LiteScheduler's cron callback, check the employee's loop configuration. If loop.mode exists, call LoopEngine.run(); otherwise, follow the original logic [P0] [S]
• [ ] Extend the Loop API in server/routes/digital-staff-routes.js. GET /api/digital-staff/loops/:id should return loop execution records (iteration count, result of each iteration, final status) [P1] [S]

Dependencies: 1.1, 1.2

Acceptance: After LiteScheduler starts, Loop-type employees execute closed-loops according to their configured mode, and execution records can be queried via the API

2. Orchestrating and Completing 43 Professional Digital Employees

Objective: Supplement missing digital employee definitions in local.yaml, complete pipeline steps for Pipeline-type employees, ensuring 43 employees cover 10+ domains.

2.1 Supplement Missing Digital Employee Definitions

• [ ] In server/boss-scheduler/profiles/local.yaml, supplement missing employee definitions (currently 50, need to verify if the target of 43 professional employees is met). Focus on supplementing: Data Repairer (DS-VEN-LOOP-001 exists but needs loop configuration verification), Price Monitor (DS-PROC-LOOP-001 exists), Target Tracker (DS-BOSS-LOOP-001 exists), Inventory Alert Officer (DS-STOCK-LOOP-001 exists). [P1] [S]
• [ ] For all Loop-type employees, verify the completeness of loop configuration: ensure enabled/trigger/condition/action/max_iterations/mode fields are complete. [P0] [S]
• [ ] For all Pipeline-type employees, supplement complete pipeline step definitions: verify that pipeline configurations for DS-SUPPLY-001 (identify→repair→generate), DS-COST-001 (compare→optimize), DS-REVIEW-001 (identify→compare→generate), etc., are complete. [P1] [M]

Dependency: 1.2 (loop.mode field)

Acceptance: GET /api/digital-staff/ returns employee count ≥43, all Loop-type employees have non-empty loop.mode field, Pipeline-type employees have complete pipeline steps

2.2 Supplement Collaboration Event Configuration

• [ ] In local.yaml, add collaboration configuration for employees with collaborative relationships, e.g., DS-BIZ-001's onComplete triggers DS-REPORT-001, add condition field (e.g., result.success === true) and params field [P1] [S]
• [ ] Confirm all employees' keywords cover both Chinese and English keywords, aligned with StaffRouter's STAFF_KEYWORDS [P1] [S]

Dependency: 3.1 (CollaborationChain supports condition)

Acceptance: When DS-BIZ-001 execution completes and result.success=true, automatically trigger DS-REPORT-001.

3. Collaborative Event onComplete Condition Trigger

Objective: Extend CollaborationChain to support onComplete conditional expressions, dynamic payload parameter passing, and circular dependency detection.

3.1 Extend CollaborationChain Condition Evaluation

• [ ] In the onTaskCompleted method of server/boss-scheduler/collaboration-chain.js, add evaluation of the collaboration.condition expression: if condition exists, execute it within a vm.createContext secure sandbox, and only trigger the downstream employee when the condition is true [P0] [M].
• [ ] Extend collaboration.params dynamic payload support: When triggering the downstream employee, merge collaboration.params with _upstreamResult and pass it, supporting parameter extraction from the upstream result (e.g., params.order_id = upstreamResult.order_id) [P0] [S].
• [ ] Support collaboration.next as an array type: When next contains multiple target employee IDs, trigger them sequentially in order [P1] [S]

Dependencies: None

Acceptance: Configure DS-BIZ-001 with collaboration: { next: DS-REPORT-001, condition: 'result.success === true' }. Trigger DS-REPORT-001 upon successful execution; do not trigger on failure.

3.2 Circular Dependency Detection

• [ ] In the CollaborationChain constructor or initialization phase, traverse all employee collaboration configurations, build a directed graph, and use DFS to detect circular dependencies [P0] [M]
• [ ] When a circular dependency is detected, log an error and throw a configuration exception to prevent service startup (or degrade to skipping that collaboration chain) [P0] [S]
• [ ] In the execute-chain interface of server/routes/collaboration-chain-api.js, add runtime circular dependency detection to prevent cycles caused by dynamic configuration at runtime [P1] [S]

Dependency: 3.1

Acceptance: When configuring the DS-A→DS-B→DS-A circular dependency, the service startup should report an error or the log should be marked with circular_dependency_detected.

4. MTClaw Acceleration Performance Statistics

Objective: Add a new MTClawStatsCollector statistics component to aggregate L1/L2/L3 hit distribution, acceleration ratio, and degradation count, and persist the data to SQLite.

4.1 Implement the MTClawStatsCollector Component

• [ ] Create the MTClawStatsCollector class in server/core/mtclaw-stats-collector.js, maintaining an in-memory statistics object { total_calls, accelerated_calls, degraded_calls, failed_calls, avg_duration_ms, l1_hits, l2_hits, l3_hits, acceleration_ratio } [P0] [M]
• [ ] Implement the record(routeResult) method: Accumulate statistics after each MTClaw call, where routeResult contains { layer: 'l1'|'l2'|'l3'|'degraded'|'failed', duration_ms, source } [P0] [S]
• [ ] Implement getStats() method: returns current aggregated statistics, calculate acceleration_ratio = average cloud duration / average MTClaw duration [P0] [S]
• [ ] Implement scheduled persistence: every 60s write in‑memory statistics to the mtclaw_stats table in server/data/core_runtime.db, table structure { id, total_calls, accelerated_calls, degraded_calls, failed_calls, avg_duration_ms, l1_hits, l2_hits, l3_hits, acceleration_ratio, recorded_at } [P1] [M]
• [ ] Implement loading statistics from SQLite on startup: after service restart, load the most recent record from the mtclaw_stats table as the initial value [P1] [S]

Dependency: SQLite (core_runtime.db, already exists)

Acceptance: After 10 consecutive calls to MTClaw, getStats() returns correct L1/L2/L3 hit counts and speedup ratio

4.2 Integrate MTClawStatsCollector into the Scheduling Pipeline

• [ ] Inject an MTClawStatsCollector instance into server/scheduler/mtclaw-scheduler.js, call record() after each MTClaw invocation to report routing results [P0] [S]
• [ ] In the _tryMTClawPreRoute method of server/routes/scheduler-routes.js, report statistics after MTClaw call completes [P0] [S]
• [ ] In the getMTClawStats method of server/boss-scheduler/lite-scheduler.js, return the result of MTClawStatsCollector.getStats() [P1] [S]

Dependency: 4.1

Acceptance: The mtclaw_stats field in the response of GET /api/scheduler/status contains complete L1/L2/L3 hit distribution and speedup ratio

5. MockDataDetector Component

Objective: Add a Mock Data Detection component to automatically scan execution results for mock keywords, ensuring demonstration authenticity.

5.1 Implement MockDataDetector

• [ ] Create the MockDataDetector class in server/core/mock-data-detector.js, implementing a scan(result) method that takes execution results (text or JSON) and outputs { is_mock: boolean, mock_indicators: string[], scanned_at: string } [P0] [M]
• [ ] Implement keyword regex scanning: Match keywords such as mock/test/example/dummy/placeholder/fake/sample/MockData/test_data (case-insensitive), recursively scanning all string values in JSON results [P0] [S]
• [ ] Implement whitelist mechanism: allow configuration of excluded keywords (e.g., "test" in "unit test" is not considered mock) to avoid false positives [P1] [S]
• [ ] Export as an independent module, callable at the routing layer and in demo workflows [P0] [S]

Dependencies: No external dependencies, pure utility module

Acceptance: scan({ content: "This is sample data" }) returns { is_mock: true, mock_indicators: ["sample"] }

5.2 Integrate MockDataDetector into Demo Workflow

• [ ] In server/routes/scheduler-routes.js demo-related APIs, automatically call MockDataDetector.scan() to scan all stage outputs after demo completion [P0] [S]
• [ ] Add mock_detection field to demo API response, returning detection results [P0] [S]

Dependencies: 5.1

Acceptance: Demo API response includes mock_detection: { is_mock: false, mock_indicators: [], scanned_at: "..." }

6. CircuitBreaker Component

Objective: Add a CircuitBreaker. Trigger circuit break after ≥5 consecutive downgrades, recover to half-open after 60s. Integrate into MTClawScheduler and LLMRouter.

6.1 Implement CircuitBreaker State Machine

• [ ] Create a CircuitBreaker class in server/core/circuit-breaker.js, implementing the closed→open→half_open state machine [P0] [M]
• [ ] Implement the recordSuccess() method: Reset failure counter on success. If currently half_open, switch to closed [P0] [S]
• [ ] Implement the recordFailure() method: Increment failure_count on failure. Switch to open state after ≥5 consecutive failures (configurable threshold), record opened_at timestamp [P0] [S]
• [ ] Implement the getState() method: If currently open and time since opened_at ≥60s (configurable recovery_timeout), switch to half_open and return half_open; otherwise return current state [P0] [S]
• [ ] Implement canExecute() method: returns true when closed, false when open, and true when half_open (only allowing one probe request) [P0] [S]
• [ ] Implement circuit breaker event logging: log { from, to, reason, timestamp } for each state transition [P1] [S]

Dependencies: No external dependencies

Acceptance: After 5 consecutive calls to recordFailure(), getState() returns open; after 60s, getState() returns half_open

6.2 Integrate CircuitBreaker into the Scheduling Pipeline

• [ ] In server/scheduler/mtclaw-scheduler.js, create a CircuitBreaker instance for MTClaw. Check canExecute() before calling MTClaw, and call recordSuccess()/recordFailure() based on the result [P0] [M]
• [ ] In server/digital-staff/smart-llm-router.js, inject the CircuitBreaker reference (circuitBreakerRef field already exists) and call recordFailure() during fallback [P0] [S]
• [ ] In server/digital-staff/llm-router.js, use the existing setCircuitBreakerRef(cb) method to receive the CircuitBreaker instance [P1] [S]
• [ ] When the CircuitBreaker is in open state, MTClawScheduler skips the MTClaw call and directly falls back to LLM Router [P0] [S]

Dependencies: 6.1

Acceptance: After 5 consecutive failures of MTClaw, subsequent requests automatically skip MTClaw and go to LLM Router, attempting recovery after 60s

7. Data Asset 8‑Category Valuation List

Objective: Extend AssetValuator to support detailed output of valuations by 8 asset categories, with a total valuation target of ¥150,000

7.1 Extend AssetValuator Valuation Details

• [ ] In server/core/asset-valuator.js, extend the valuate method to add a per_asset_type parameter. When per_asset_type=true, perform the three-stage valuation separately for the 8 asset types (Part/BOM/Vendor/Document/ECR/ECO/ProcessSpec/Equipment) [P0] [M]
• [ ] Implement detailed valuation output for each asset type: split cost_breakdown/income_breakdown/market_breakdown by asset type, output an array of { asset_type, asset_count, cost_value, income_value, market_value, weighted_value } [P0] [M]
• [ ] Adjust valuation parameters so the total valuation ≈ ¥150,000: Calibrate parameters such as acquisition cost/processing cost/storage cost/maintenance cost/discount rate/market reference price in server/boss-scheduler/profiles/valuation.yaml [P0] [S]
• [ ] Valuation result annotation source: Each valuation must be marked with source: 'rule_engine' | 'llm_estimated' | 'actual_measurement'. No values without source allowed. [P0] [S]

Dependencies: AssetValuator (implemented), valuation.yaml (exists)

Acceptance: Calling valuate('all', { per_asset_type: true }) returns valuations for 8 asset types + total valuation ≈ ¥150,000, with each item annotated with source.

7.2 Valuation API Extension

• [ ] Extend the valuation API in server/routes/platform-asset.js to support the ?per_asset_type=true query parameter, returning detailed valuations for 8 asset types. [P1] [S]
• [ ] Include a valuation table for the 8 asset types in the valuation report generation, each row displaying asset type/quantity/cost method/income method/market method/weighted valuation. [P1] [S]

Dependencies: 7.1

Acceptance: GET /api/platform-asset/valuation?per_asset_type=true returns detailed valuations for 8 asset types.

8. Rule Engine Three-Level Defense Pass Rate Statistics

Objective: Add RuleEngineStats component to aggregate pass rates of create_pre/validate/create_post three-level defenses, target ≥89%

8.1 Implement RuleEngineStats Component

• [ ] Create RuleEngineStats class in server/core/rule-engine-stats.js, maintaining statistics categorized by scope: { scope, total_executions, passed, failed, pass_rate, avg_duration_ms, last_calculated_at } [P0] [M]
• [ ] Implement record(scope, result, duration_ms) method: accumulate statistics after each rule execution, result is passed/failed [P0] [S]
• [ ] Implement getPassRate(scopes) method: calculate weighted average pass rate for specified scope list, weighted by each scope's execution count proportion [P0] [S]
• [ ] Implement three-level defense pass rate calculation: getThreeLevelPassRate() returns weighted average pass rate of create_pre/validate/create_post [P0] [S]

Dependency: UnifiedRuleEngine (implemented)

Acceptance: After executing 100 rules, getThreeLevelPassRate() returns a pass rate ≥89%

8.2 Integrate RuleEngineStats into the rule engine

• [ ] In the execute method of server/core/rule-engine.js, call RuleEngineStats.record() after each rule execution to report the result and duration [P0] [S]
• [ ] Add a new GET /api/rule-engine/stats endpoint in server/routes/rule-engine.js, returning the three-level defense pass rate statistics [P1] [S]
• [ ] In the existing getRuleEngineStats() method in server/routes/platform-asset.js, return the calculation results from RuleEngineStats [P1] [S]

Dependencies: 8.1

Acceptance: GET /api/rule-engine/stats returns { create_pre: { pass_rate: 0.92 }, validate: { pass_rate: 0.88 }, create_post: { pass_rate: 0.90 }, weighted_pass_rate: 0.90 }

9. Scheduler Status Query Interface Extension

Objective: Extend the GET /api/scheduler/status interface to return the complete status (MTClaw availability, GPU status, circuit breaker status, acceleration effect statistics)

9.1 Extend the status interface return fields

• [ ] In the GET /api/scheduler/status handler in server/routes/scheduler-routes.js, add the following return fields: mtclaw_available (boolean), gpu_available (boolean), mtclaw_circuit_breaker ('closed'|'open'|'half_open') [P0] [M]
• [ ] Add mtclaw_stats field: retrieve acceleration statistics from MTClawStatsCollector.getStats() [P0] [S]
• [ ] Add staff_count field: retrieve registered employee count from StaffRegistry [P1] [S]
• [ ] Add uptime_seconds field: record service start time and calculate uptime [P1] [S]
• [ ] Ensure response format complies with the SchedulerStatusResponse interface signature in the design document [P0] [S]

Dependencies: 4.2 (MTClawStatsCollector), 6.2 (CircuitBreaker)

Acceptance: GET /api/scheduler/status returns { scheduler_type, model_provider, mtclaw_available, gpu_available, mtclaw_circuit_breaker, mtclaw_stats, staff_count, uptime_seconds }

10. Digital Employee API Route Alignment

Objective: Ensure that the GET /api/digital-staff/ and GET /api/digital-staff/:id API response formats align with the spec definition.

10.1 Align Digital Staff List API

• [ ] In server/routes/digital-staff-routes.js, confirm that GET /api/digital-staff/list returns a format containing: id/name/title/capability/department/enabled/mtclaw_enabled/pipeline/loop/collaboration/keywords fields [P0] [M]
• [ ] Confirm that GET /api/digital-staff/:id returns the staff details, including the complete pipeline step definitions, loop configuration, and collaboration configuration [P0] [S]
• [ ] Ensure the loop field returns the format { enabled, mode } (aligned with the design document DigitalStaffListResponse) [P0] [S]
• [ ] Ensure the collaboration field returns the format { next } [P1] [S]

Dependency: 1.2 (loop.mode field)

Acceptance: The employee list format returned by GET /api/digital-staff/ must exactly match the spec-defined DigitalStaffListResponse

11. Full-Link Closed-Loop Demo: 6-Stage Integration

Objective: Integrate the actual execution of Step5 Data Assetization and Step6 Private Deployment into the demo page, annotate real time consumption for each stage, and automatically run MockDataDetector upon demo completion

11.1 Backend Demo API Implementation

• [ ] Implement the POST /api/demo/full-loop interface in server/routes/scheduler-routes.js, executing sequentially in 6 stages: Step1 Product Creation → Step2 BOM Generation → Step3 Marketplace Listing → Step4 Content + Documentation → Step5 Data Assetization → Step6 Private Deployment [P0] [L]
• [ ] Step1: Call CapabilityRuntime.create(Part, data) and record duration_ms [P0] [S]
• [ ] Step2: Call CapabilityRuntime.generate(BOM, {part_id}), record duration_ms [P0] [S]
• [ ] Step3: Deterministic operations, directly processed by rule engine (auto-generate product page + SKU), record duration_ms [P0] [S]
• [ ] Step4: Parallel call CapabilityRuntime.generate(Content, params) to generate posters/manuals/brochures, record duration_ms [P0] [S]
• [ ] Step5: Call AssetValuator.valuate('all', { per_asset_type: true }), output 8 types of asset valuation list + total valuation ¥150,000, record duration_ms [P0] [S]
• [ ] Step6: Display private deployment configuration (from trial to enterprise-dedicated platform), record duration_ms [P1] [S]
• [ ] After demo, call MockDataDetector.scan() to scan all stage outputs, return mock_detection result [P0] [S]
• [ ] Return DemoResult format: { stages: DemoStage[6], total_duration_ms, mock_detection, report_path } [P0] [S]

Dependencies: 5.1 (MockDataDetector), 7.1 (8 types of asset valuation)

Acceptance: POST /api/demo/full-loop returns actual execution results of 6 stages, each with duration_ms, total duration ≤60s, mock_detection.is_mock=false

11.2 Frontend Demo Page Integration

• [ ] Integrate Step5 data assetization display in public/demo/closed-loop.html: 8 types of asset valuation table + total valuation ¥150,000 [P0] [M]
• [ ] Integrate Step6 private deployment display in public/demo/closed-loop.html: deployment configuration info + description from trial to enterprise-dedicated platform [P1] [S]
• [ ] Label each stage with actual measured duration (read from the duration_ms field in API response), format as "Actual Measurement: ~Xms" [P0] [S]
• [ ] After demo completion, display mock detection results: when is_mock=false, show "✓ Real data verification passed"; when is_mock=true, list mock metrics [P0] [S]
• [ ] Synchronously update the 6-stage display logic in public/demo/real-exec.html [P1] [M]

Dependency: 11.1

Acceptance: Open closed-loop.html, execute the 6 stages sequentially, display actual time consumption for each stage, Step5 shows 8 types of asset valuation ¥150,000, Step6 shows private deployment, finally display Mock detection passed

12. Six Major Implementation Case Studies Module

Objective: Add case-studies.yaml configuration file and case display API to showcase 6 real customer cases

12.1 Case Data Configuration

• [ ] Create server/boss-scheduler/profiles/case-studies.yaml, define 6 major implementation cases: Macheng General Red (Agricultural Product Processing), Luotian Meteorological Bureau (Meteorological Services), Dachaihu Immigrant Memorial Museum (Cultural Tourism), A Provincial Power Company (Electric Power), High-end Equipment Process Data Restoration (High-end Equipment), Guizhou Phosphate Group (Chemical Industry) [P0] [M]
• [ ] Each case includes: id/name/industry/deployment_mode/summary/metrics, with each metric item annotated with its source (actual measurement/customer feedback/internal statistics) [P0] [S]
• [ ] Quantitative metrics for each case include: data governance volume, pass rate improvement, labor savings, etc. [P1] [S]

Dependencies: None

Acceptance: case-studies.yaml contains 6 cases, each with complete metrics and source annotations

12.2 Case Study API

• [ ] Create server/routes/case-studies-routes.js, implementing GET /api/case-studies/ to return the case list, and GET /api/case-studies/:id to return case details [P0] [M]
• [ ] Load case data from case-studies.yaml and cache it in memory [P0] [S]
• [ ] Register the case-studies route in server/server.js [P0] [S]
• [ ] Response format complies with the CaseStudyListResponse interface signature defined in the design document [P0] [S]

Dependency: 12.1

Acceptance: GET /api/case-studies/ returns a list of 6 case studies, GET /api/case-studies/macheng returns the details of the Macheng General Red case study

13. Integration Testing and Verification

Objective: End-to-end validation of all new and extended features, ensuring the full-link closed-loop demo is operational

13.1 Core Component Unit Tests

• [ ] Verify LoopEngine's three modes: Create loop-engine.test.js in server/tests/ to test the execution and termination conditions of monitor/goal_driven/self_repair modes [P0] [M]
• [ ] Verify CircuitBreaker state machine: Test the complete state transition closed→open→half_open→closed [P0] [S]
• [ ] Verify MockDataDetector: Test inputs containing and not containing mock keywords [P0] [S]
• [ ] Verify MTClawStatsCollector: Test statistical accumulation, speedup ratio calculation, and persistence recovery [P1] [S]
• [ ] Verify RuleEngineStats: Test pass rate calculation for three-level defense lines [P1] [S]
• [ ] Verify CollaborationChain condition triggering: Test trigger behavior when condition is true/false [P0] [S]

Dependencies: 1.1, 3.1, 5.1, 6.1, 4.1, 8.1

Acceptance: All test cases pass

13.2 End-to-End Validation for Full-Link Closed-Loop Demo

• [ ] Start BossAgents service (:3006), verify GET /api/scheduler/status returns complete status [P0] [S]
• [ ] Execute POST /api/demo/full-loop, verify 6 stages execute sequentially, each returns actual duration [P0] [M]
• [ ] Verify Step5 data assetization returns 8 types of asset valuations + total valuation ≈ ¥150,000 [P0] [S]
• [ ] Verify MockDataDetector scan result is_mock=false [P0] [S]
• [ ] Verify CircuitBreaker automatically trips and recovers when MTClaw is unavailable [P1] [S]
• [ ] Verify Loop-type employee (DS-VEN-LOOP-001) executes closed-loop in self_repair mode [P1] [S]
• [ ] Verify collaborative event (DS-BIZ-001→DS-REPORT-001) triggers on condition [P1] [S]
• [ ] Verify GET /api/digital-staff/ returns a list of 43+ employees [P0] [S]
• [ ] Verify GET /api/case-studies/ returns 6 cases [P1] [S]

Dependencies: All prerequisite tasks

Acceptance: Full-link closed-loop demo total duration for 6 stages ≤60s, Mock checks pass, all APIs return correct format

13.3 Environment Compatibility Verification

• [ ] Verify in GPU-less environment: Automatically switches to cloud DeepSeek, scheduling logic unchanged [P1] [S]
• [ ] Verify in MTClaw-unavailable environment: Automatically degrades to BuiltinScheduler, all API entry points maintain consistent response format [P1] [S]
• [ ] Verify it can run directly on MTT AIBOOK (AIOS 1.4.2 / Ubuntu 22.04) [P1] [S]

Dependencies: 13.2

Acceptance: API entry points and response formats are completely consistent across four deployment scenarios (MTClaw+GPU/MTClaw no GPU/no MTClaw+GPU/no MTClaw no GPU)

Task Dependency Graph

1.1 LoopEngine核心 ──→ 1.3 集成到LiteScheduler
1.2 YAML loop字段  ──→ 1.3
                      ──→ 10.1 Digital StaffAPI对齐

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 CasesAPI

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

优先级汇总

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

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

| P0 (Must Complete) | 48 | Core features, impact demo and competition scoring |

| P1 (Should Complete) | 23 | Enhancement features, improve completeness and experience |

| P2 (Can Defer) | 0 | None |

Effort Summary