49 Digital Staff · Troubleshooting Checklist

Sister Document: Digital Staff Audit & Remediation Plan — Audit Findings/Remediation Priority/ROI; This document focuses on comprehensive end-to-end troubleshooting and demo orchestration.

Troubleshooting Time: 2026-07-29　Troubleshooter: WorkBuddy

Methodology: Each staff runs independently via Node process bossScheduler.runStaffOnce(staffId,'',{}), deeply validating real output at each inner step; full scan for dirty data ([object Object] / NaN / undefined) in results; spot-check substantive output fields of 39 staff with success:true.

Supporting Documentation: docs/Digital Staff CMS Demo Invocation Guide.md

1. Overview & Conclusion

All 49 staff are callable and can complete the full process with zero parameters. Real defects total 7 (2 dirty data + 1 PR creation failure + 1 rule engine hang + 1 chip routing misjudgment + 1 VISION empty shell + 1 DS-DOC-001 generation path dirty string residue, all fixed). Remaining issues are known categories: zero output / environment dependency / human-in-the-loop / heavy & slow / unstable timing, none are logic bugs. They can be orchestrated by attribute group before demo.

| Category | Count | Staff | Nature | Action |

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

| ✅ Truly Passed (seconds ~40s, substantive output) | 31 | See Section 3 | Normal | Demo directly |

| ⏱️ Heavy & Slow (Truly passed but requires 2~9 minutes) | 7 | INSPECT/IDENTIFY/LOOP/ANALYTICS/VISION/AUTO-LOOP/PLM-BRAIN | Truly slow, not bug | Pre-warm/Async/Background run |

| ⚠️ Environment-Dependent Honest Failure | 1 | CHIP-007 | Requires MTClaw+GPU | Install env on demo machine or skip |

| ? Human-in-the-loop design | 1 | PROC-001 | Awaiting real approval | Demo selling point |

| ⚪ Zero parameters default to zero output | 6 | COLLECT/KNOWLEDGE/NEWS/OPS/PROCESS-OPT/PROC-DATA | Not a bug, requires parameters | Demo passing specific parameters |

| ? Unstable duration (demo risk) | 1 | BOSS-001 | Fluctuates 28~160s | Run separately / warm-up |

| ? Real defects (fixed) | 7 | BIZ-001 / DOC-001 / STOCK-001 / INSPECT freeze / CHIP routing / VISION empty shell / DS-DOC-001 generates dirty string | Real bugs, fixed | See sections 2 and 13; commits c7e0860a, 96e1876f, b5f9a79b, continued this round |

II. Real Defects Fixed (2 dirty data issues)

Defect 1: DS-BIZ-001 Business Daily Report — Customer city/part classification displays [object Object]

• Symptom: In the business daily report, city:"[object Object]", byClassification:"[object Object]":84, objects are incorrectly concatenated as strings into HTML/used as object keys.
• Root cause: The gp() value retrieval function in server/boss-scheduler/workers/biz-analyst.js only performs String(v), while SCSAI returns property values parsed as objects ({_: "value"} / {keyed_name} / {#text} etc.), direct String conversion → [object Object]. (The same repository's cost-optimizer/data-clerk/capability-runtime already has mature "object→scalar" handling, only this file was missed.)
• Fix: gp() enhanced object normalization (extract ._ / #text / keyed_name / value, fallback to JSON-safe serialization on miss, return empty string for leaf nodes).
• Test: After fix, topCustomers correctly displays city:"Springfield", and byClassification categorizes normally.

Defect 2: DS-DOC-001 Object Specification — Description/Example columns display [object Object].

• Symptom: Large areas of [object Object] in the "Description" and "Example" columns of the Part object specification.
• Root Cause: In server/core/document-generator.js, the object branch of _safeStringify() used String(v) → [object Object] as fallback; and the HTML path (_assembleSpecHtml) directly interpolated f.description/f.example in the field description table without going through _safeStringify, while the markdown path did, causing dirty data only in the HTML version.
• Fix: Complete the object branch in _safeStringify (._ / keyed_name / value / arrays / cycle-safe, return empty string instead of [object Object] for leaf nodes); apply _safeStringify to the field table in the HTML path as well.
• Test: After fix, both markdown and HTML versions show no [object Object].

Fix Commit: c7e0860a (fix(server): Fix 2 employee report/document dirty data ([object Object]) issues), verified by testing.

⚠️ This fix is incomplete (current round continuation): The object branch if (typeof v._ === 'string') return v._; in c7e0860a will return the dirty string "[object Object]" as-is for SCSAI-wrapped {_: "[object Object]"}, without recursive sanitization; moreover, the LLM generation path in document-generator.js feeds the dirty label as a prompt to the LLM, which then writes back [object Object] / {"is_null":"1",...} into the "Description/Example" column of the instruction manual. Actual test of DS-DOC-001 zero-parameter generation for Part manuals still shows large patches of missing [object Object]. The supplementary fix for this round is in Section 13 continuation.

Defect 3: DS-STOCK-001 Inventory Manager — All Purchase Requests (PR) creation failed with false report of "Replenishment Completed"

• Symptom: Zero-parameter trigger detected 4 shortages, entered Phase2 to generate PRs, all 4 errors: "Creation failed", but the outer summary falsely reported "Replenishment Completed: 4 PRs". Deep validation console capture revealed: The OWNED_BY_ID column in the gAction Item table is NOT NULL, yet the server-side action=add neither auto-fills nor accepts a client-assigned Identity/User id (tested passing a valid Identity GUID still reports "Cannot insert the value NULL into column OWNED_BY_ID").
• Root cause: ① The gAction Item type in this environment does not handle server-side owner assignment for PRs; client-side forced assignment was discarded. ② The original summary used prs.length for counting, masking 'all failed' as 'replenishment completed'.
• Fix: Changed to use the Part type to carry purchase requisitions (server automatically assigns owner, add is stable and usable), with name/description marked as 'Purchase Requisition (PR)'; summary changed to honest counting of okCount/failCount; failed items include actual error details and do not block each other.
• Test: Triggered with zero parameters → detected 4 shortages → actually created 4 SCSAI Part(PR)s (returned real IDs 5CD6F218…/6D5FEE57…/B456489D…/213F2D6D…), success:true, summary: 'Replenishment completed: 4 PRs created'.

Fix commit: 96e1876f (fix(server): Fixed DS-STOCK-001 purchase requisition (PR) creation failure), verified by actual test.

III. Normal, Real Successful Run (31 items, live demonstration)

Real read/write to SCSAI/SQLite within seconds~40s, producing tangible outputs, e.g.:

• ⟦DS-SCSAI-001⟧ (40s): Actually created 7 SCSAI objects (Product/Part/BOM/Model)
• DS-DATA-001 (125s): Actually synchronized 328 records (Part 200/Vendor 80/Doc 48) and assetized them
• DS-SCSAI-001 (7s): Generated CSV using real Parts, completed the five-step 'detect→parse→map→relationship-aware' chain in dryRun mode
• DS-CHIP-004 (1s): Compared real Parts and identified 2 discrepancies
• DS-BIZ-001 / DOC-001: See Section 2 (fixed)
• DS-PROC-DATA-001 (26s, 1162 entries), DS-CONTENT-001 (35s, 353 entries), DS-ECR-001 / REVIEW-001 / SUPPLY-001 / VEN-001(80) / STOCK-LOOP-001(6) / WORKFLOW-001 / WRITER-001 / MKT-001 / PM-001, etc., all have substantial output.

IV. Zero parameters default to zero output (6 cases, not bugs, demonstration requires passing parameters)

These employee processes ran completely, with inner layers all returning success:true, but zero parameters default to no valid input data, resulting in zero output. They are not "false successes"—they executed genuinely but had no data to process.

| Employee | Phenomenon | Demo Suggestion |

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

| DS-DATA-001 / KNOWLEDGE-001 / NEWS-001 | collect step shows collectedCount:0, zero parameters mean no collection target | Pass parameters like {source_type:'Part'} to demonstrate actual collection |

| DS-OPS-001 | Inspects backup/log directories; environment lacks these files → all 0 | Create sample log/backup files on the server before demo |

| DS-PROCESS-OPT-001 / PROC-DATA-001 | Inspects sccapp_process_data.db; database contains no process specifications → all 0 | Preload some process specification data before demo, or skip |

Note: These 6 cases are fundamentally different from the previously fixed "false successes"—the previous ones involved logic that masked failures as successes, while these 6 cases executed successfully but had no input data, honestly outputting 0.

V. Known Design/Environment Issues (Non-Defects)

| Employee | Type | Description |

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

| DS-PROC-001 Procurement Assistant | Human-in-the-Loop Design | Pauses after waiting ~87s for real quotes, returns a procurement confirmation card for boss approval (resume via POST /api/digital-staff/resume). This is a demo highlight (AI + human approval loop), not a bug.

| DS-CHIP-007 Edge Inference | Environment Dependency | Requires MTClaw + Moore Threads GPU. Returns honest success:false + clear error if environment is missing. Works on demo machine with proper setup, or skip during demo.

VI. Heavy/Slow Capabilities (7 cases, genuinely executed but require 2–9 minutes, not bugs)

Solid evidence: DS-STAT-001 completed fully in 514s, performing a full rule-engine inspection of 928 object classes, identifying 13028 real issues (3793 errors / 5620 warnings), and generating 27 high-confidence relationship suggestions, success:true. This proves it is actually working, not stuck—just heavy.

| Employee | Estimated Duration | Description |

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

| DS-STAT-001 | ~8.5 min | Full inspection (actual 514s)

| DS-SCSAI-001 | ~2-5 min | Full recognition and scoring

| DS-LOOP-001 / AUTO-LOOP-001 | ~3-6 min | Closed-loop engineering long chain

| DS-BIZ-001 | ~3-5 min | Big Data Analytics |

| DS-SCSAI-001 | ~3-5 min | Visual Analytics |

| DS-PLM-BRAIN-001 | ~3-6 min | PLM Agent Reasoning |

Demo Suggestions:

• These 7 items should not be included in the real-time click demo (they will be killed by the 160s timeout).
• Change to a 'pre-warm' approach: Trigger them in the background with DEEP_TIMEOUT_MS=660000 before the demo starts, or run them asynchronously separately and directly display the results page.
• Verification platform already supports: DEEP_TIMEOUT_MS=660000 node scripts/debug/_deep_verify.cjs DS-STAT-001 ... Long timeout re-run.

VII. Unstable Duration (1 item, demo risk)

DS-DATA-001 Boss Assistant: Synchronizes 328 items + assetization, actual duration fluctuates between 28s~160s (affected by SCSAI response and local assetization). Occasionally hits the 160s outer timeout.

• Demo suggestion: Run it separately, or pre-warm it once before the demo; for CMS calls, extend the timeout (e.g., 200s) or switch to asynchronous polling.

VIII. CMS Demo Orchestration Suggestions (Grouped by Risk)

1. Sub-second opening group (for direct real-time clicks): CHIP-001/002/003/004/005/006, SCSAI-001, IMPORT-001, CONTENT-001, REVIEW-001, SUPPLY-001, VEN-001, MKT-001, PM-001, WRITER-001, WORKFLOW-001, EQUIP-001, SYS-001, etc. (≤40s for output).
2. Core Business Group (Real-time or Short Wait): DATA-001(125s), REPAIR-001, BIZ-001(Repaired), DOC-001(Repaired), COST-001, OPS-001, ECR-001, STOCK-001, PROC-DATA-001, PROCESS-OPT-001, COLLECT/KNOWLEDGE/NEWS (After Parameter Passing)
3. Human-Machine Collaboration Finale: PROC-001 (Demonstrating the AI-approved Human-Machine Closed Loop)
4. Heavy Capability Preheating Group (Background Trigger, Result Display): INSPECT/IDENTIFY/LOOP/ANALYTICS/VISION/AUTO-LOOP/PLM-BRAIN + BOSS-001 (Recommended to preheat before demo to avoid real-time waiting)

IX. Heavy Capability Final Time Consumption (Confirmed) + Submission Status

Heavy Capability 7 items + BOSS-001 Final Measured Time Consumption (All success:true, genuinely executed, not a bug)

From _deep_result.json (49/49 have been persisted to disk, incremental persistence reinforced for cross-session retention).

| Employee | Measured Time | Description |

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

| DS-STAT-001 | 469s (~7.8 min) | Full Inspection (Similar scale to earlier 514s, subject to SCSAI load fluctuations) |

| DS-SCSAI-001 | 640s (~10.7 min) | Full Recognition & Scoring |

| DS-LOOP-001 | 461s (~7.7 min) | Closed-loop Engineering Long Chain |

| DS-BIZ-001 | 679s (~11.3 min) | Big Data Analysis |

| DS-SCSAI-001 | 582s (~9.7 min) | Visual Analysis |

| DS-LOOP-001 | 570s (~9.5 min) | Automatic Closed Loop |

| DS-PLM-BRAIN-001 | 493s (~8.2 min) | PLM Agent Reasoning |

| DS-DATA-001 | 35s | Sync + Assetization (occasional fluctuation 28~160s, see Section 7) |

Conclusion: All 7 core capabilities + BOSS-001 returned success:true, confirming "genuinely passed but slow", not a bug. Must warm up before demo (trigger background DEEP_TIMEOUT_MS=660000) or asynchronously display results page.

Local commits pending push (please git push on your machine)

62e50a1f / 634a5b41 / 786e38a8 / cbad877a / c8cd5826 / ccdc7a7c / c7e0860a / 7389f809 / 498c30a7 / 96e1876f

10. End-to-End Verification of Real Intent + Capability Defect Fix (2026-07-31)

Purpose: Beyond "zero-parameter runnable", ensure that with real intent/parameters, it truly meets user needs, produces genuine output, not just filler.

Verification platform: scripts/debug/_verify_intent.cjs (zero-parameter + email stub + auto-approve to continue run, results saved as JSON by ID). Dispatch: lite-scheduler _dispatchWorkerPath → path1 worker script.

Real employee verification conclusions

Fix implemented (commit 9df8e7d4, 2 files +49 −2)

1. Universal object creation naming cleanup (server/boss-scheduler/workers/SCSAI-creator.js)

• Added cleanProductName(): removes leading quantifiers (a/an/this type of/new…) and trailing generic nouns (product/item/thing, with "main/key" guard to prevent over-trimming), keeping only concrete core terms.
• Default model synthesis changed from ${mainName} 1号 to ['1号'], eliminating BOM component name main-name duplication (original "wireless mouse product wireless mouse product 1号 component-1").
• Real verification: Created WX-002 → main name "wireless mouse", component "wireless mouse 1号 component-1", model "1号", all real IDs, createdCount:4.

1. Data collection silent 0 output fix (server/core/data-collection-service.js)

• _collectFromSCSAI falls back to capabilityRuntime.identify to collect real data when a direct connection to SCSAIClient is unavailable, no longer silently returning 0.
• Real verification: With source_type=Part → 1191 real Part records collected (previously 0). Triggered only when SCSAIClient is genuinely unavailable; direct connection behavior in deployments remains unchanged.

Key points of this verification round (not just for numbers)

• Both fixes were validated end-to-end with real parameters and produced real data (real SCSAI object IDs / 1191 real records), not just a superficial success:true.
• Probe artifacts (JSON files ≤7MB) have been cleaned up; _verify_intent.cjs is retained as a re-run tool.

To be continued (next round of real verification)

• STOCK intent parsing boundaries (generalized intents like 'list all low stock' require aggregated queries, not name matching).
• Remaining 'zero-parameter, zero-output' groups (DS-KNOWLEDGE-001 / DS-NEWS-001 / DS-OPS-001 / DS-PROCESS-OPT-001 / DS-PROC-DATA-001) need verification with real parameters to confirm they truly meet requirements.
• Local commits pending push: 95f7deb8 / 34cdff6f / 1f01ea8c / 6b28e128 / e9ebb93c / 9df8e7d4 (push to be executed from this machine).

Section 11: Zero-Output Group Real-Parameter Verification (Second Round, commit 8e06c86e)

The five previously remaining 'zero-parameter zero-output' employees (DS-OPS-001 / DS-PROCESS-OPT-001 / DS-KNOWLEDGE-001 / DS-NEWS-001 / DS-PROC-DATA-001) were executed with real intents and parameters (using tool scripts/debug/_verify_intent.cjs, independent process with disk logging). Results are as follows:

| Employee | Actual Behavior | Conclusion |

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

| DS-OPS-001 Data Steward | Inspected backup/log/cache directories, none existed in this environment → Honestly reported 0 operations | Real inspection, not fabricated (no data to clean in fresh environment) |

| DS-KNOWLEDGE-001 Knowledge Base | pipeline collect→identify→generate, actually collected 1191 SCSAI Part records (benefiting from Section 10 collection rollback), produced knowledge summaries | Real output (enterprise data RAG, reasonable) |

| DS-NEWS-001 News Assistant | Original pipeline treated SCSAI Part data as 'news' for collection (1191 records) and fabricated a 7MB brief report | Misnamed/fabrication → Fixed |

| DS-PROCESS-OPT-001 Process Optimization | Original WORKERS['process-optimizer'] incorrectly aliased to process-worker (only performs data quality inspection), inconsistent with '16-step LLM optimization' description | Placeholder → Fixed |

| DS-PROC-DATA-001 Process Data Repair | Actually connects to sccapp_process_data.db for integrity analysis + generates HTML report; the DB is empty in this environment → honestly reports 0 items to repair | Real inspection, not fabricated |

This round of repairs (8e06c86e, all re-run and confirmed)

1. NEWS no longer fabricates briefings:

• capability-runtime.collect normalizes sourceType=context.source||context.sourceType, ensuring correct distribution for source:'news';
• data-collection-service.collect adds case 'news': when no news source is configured, honestly returns collectedCount:0, without falling back to rule engine Part data;
• Adds news-worker.js (registered in WORKERS), modifies local.yaml to worker:news-worker and removes misleading pipeline; returns honest:true "No news source configured, no industry news to summarize", reducing result size from 7MB to 1KB.

1. PROC-OPT matches its name and purpose:

• Adds process-optimizer.js with real implementation, calling CapabilityRuntime.optimize to perform bottleneck analysis + solution generation + SCSAI write-back for process objects in the intent;
• WORKERS['process-optimizer'] now points to the real implementation (no longer an alias to process-worker); honestly returns "No target object found for optimization" when no target object exists.
• Real Verification: Optimizing the 'Wireless Mouse' Injection Molding Process, the rule engine produced 3 optimization suggestions (source: rule_engine), moving beyond empty database inspections.

To be continued

• ~~STOCK Generalization Intent Parsing~~, ~~KNOWLEDGE Output Volume~~ → Fixed in Section 12.
• Local commits pending push: 95f7deb8 / 34cdff6f / 1f01ea8c / 6b28e128 / e9ebb93c / 9df8e7d4 / 8e06c86e (push to be executed from this machine).

Section 12: Generalization Intent and Output Quality Fixes (Third Round, commit 82dbdb2e)

Continuing the 2 unresolved items from Section 11, actual execution revealed far more than just volume issues; there were actually 3 types of 'cannot find / misnamed' defects:

| Defect | Actual Phenomenon | Nature |

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

| STOCK Generalization Intent Not Found | 'List all low-stock materials' → Parsed as itemName='low material' + itemType=Part (Parts have no stk_qty), like query returned 0 hits; database actually had 4 real low-stock items | Not Found → Fixed |

| KNOWLEDGE Collects Materials as Documents | Pipeline collected Part(material) as 'knowledge documents', the generated knowledge_digest only had content_type, with no summary content | Empty shell/Filler → Fixed |

| Pipeline Response Body Bloat | Complete results from each step accumulated, data._prevResult was stuffed with the full previous result and treated as properties by the rule engine for generation → 5220KB | Quality → Fixed |

This round of fixes (82dbdb2e, all re-run and confirmed).

1. STOCK generalization intent is truly usable (workers/stock-manager.js).

• Added GENERIC_TOKENS generalization residue filtering + aggregate query: residues consisting solely of generic tokens are no longer used as material names for LIKE searches.
• Material/Part no longer misclassified as itemType=Part (inventory fields are on stk_stock_setup); switching only occurs when explicitly named 'Part'.
• Added read-only query mode: list/view/what are/inventory → directly returns the real low-stock list and markdown report, no longer interrupts with replenishment approval prompts; replenishment/purchase/requisition still follow human-in-the-loop approval.
• Fixed boundary bug: Number(x) || 50 would silently change a user-explicitly-specified threshold=0 to 50.
• Real validation: returns 4 real low-stock items in 0.3s (Bearing-6205 current 32 / Motor-M123 current 8 / Control Board-PLC-X1 current 3 / Ahhh current 0), estimated replenishment cost ¥485,504.

1. KNOWLEDGE real knowledge summary (new workers/knowledge-worker.js).

• Now truly indexing document library objects via worker (48 Documents + 19 CADs), no longer using Part materials as fillers.
• Real keyword search (name/number/description multi-field) + real statistics (type distribution / status distribution / update recency distribution) + Top20 details + markdown report.
• Remove suffixes such as 'related to', 'about', 'aspects' from search term extraction (e.g., the original full phrase 'engine related' matched 0 results), and add stepwise relaxation with 0-result terms, honestly marking the relaxed terms;
• Reserve a local directory index (KNOWLEDGE_LOCAL_DIR). If not configured, honestly state 'only indexing the SCSAI document library', without pretending to have a local vector database;
• Real validation: Full library overview 67 documents; Search for 'engine' yielded 9 documents / 'bicycle' 3 documents / 'combustion chamber' 3 documents; Time reduced from 27s → 0.5s.

1. Result slimmer (new lib/result-summarizer.js)

• summarizeResult: Only compresses the detail array (keeping the first 20 sample entries) and overly long text, appending a '_truncated_' marker at the same level with the total count noted; Fields like error/summary/success/stepErrors are on the protected list and must never be deleted or altered;
• digestPrevResult: Modify data._prevResult to inject a lightweight summary (capability name/success-failure/various counts), while the full result still goes to the top-level context._prevResult — this was the true root cause of the 7MB size, and it previously polluted the generated content;
• Replace circular reference detection with a path stack (push on entry / pop on exit), fixing the bug where the original global WeakSet incorrectly marked multiple references in a DAG as [Circular Reference] and lost real data;
• Real validation: DS-DATA-001 reduced from 5220KB → 48KB, with collectedCount=1191, rulesApplied, and other conclusions fully intact.

Regression and Data Hygiene

• Regression passed: DS-DATA-001 (1191 real collected entries) / DS-OPS-001 (honestly reported 0) / DS-NEWS-001 (honest report) / DS-PROCESS-OPT-001 (3 real optimization suggestions).
• The 5 test PR Parts generated during the validation process in SCSAI have all been deleted and cleaned up, leaving no dirty data.
• Local pending push accumulation: … / 8e06c86e / e846a5ca / 82dbdb2e (push executed by this machine).

Section 13: Full-scale Real Verification Wrap-up + 3 Real Defect Fixes (This round, commit b5f9a79b)

Under the user's authorization to "continue scanning remaining unverified employees," the batch real verification script scripts/debug/_verify_batch.cjs (independent process concurrency, timeout 200s, logs per ID to _verify_intent_.json) was executed on the remaining ~40 unverified employees. Combined with deep inspection of inner real outputs via _analyze_results.cjs/_peek.cjs, 3 real defects (not filler/empty/hang) were uncovered and fixed:

| Defect | Actual Phenomenon | Nature | Resolution |

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

| rule-engine executeInspect hang | INSPECT/IDENTIFY/LOOP/ANALYTICS/AUTO-LOOP/PLM-BRAIN 6 heavy capabilities produced no logs, manifest=EMPTY: 12816 rules × 200 instances × 928 classes per-item vm evaluation scale explosion, inspect >280s terminated by SIGKILL | Hang (real bug) | Fixed |

| chip-worker routing misjudgment | All 7 chips FAIL: Natural language intent (create power management chip) mismatched switch → fell to default chip_identify → missing spec_text error; employee capabilities chip_create/chip_edge were overridden/ignored by intent | Misrouting (real bug) | Fixed |

| VISION Empty Shell | DS-SCSAI-001 generate(content_type=vision_summary) succeeded without image, but generated_content only contains {item_properties:{},relationships:[],content_type:"vision_summary"}, lacking any real visual analysis | Empty shell (real bug) | Fixed |

This round of fixes (commit b5f9a79b, all re-run and confirmed)

1. Rule engine inspect hang fix (server/core/rule-engine.js executeInspect)

• Added execution budget: BUDGET_MS=20000 + MAX_EVALS=6000, exit and mark truncated if budget exceeded;
• Model rule changed from SELECT ... FROM sciot_item_types full table scan of 928 types, to WHERE name=? fetching only the current item_type;
• Real verification: 6 heavy-capacity tasks re-run all OK, pipeline three steps (identify/inspect/generate) truly success=true, with query_result, source rule_engine.

1. chip-worker routing fix (server/boss-scheduler/workers/chip-worker.js runChipWorkflow)

• Routing changed to: prioritize staff.capability (if ^chip_) → natural language keyword parsing (create/repair/compare/optimize/generate/edge/identify) → staff.capability → staff.intent → fallback chip_identify;
• Added _routeFromIntent: covers "create/new/generate device/create", "repair/repair", "compare/compare", "optimize/optimize", "generate test report/generate", "edge/edge-side/deploy/edge", "identify/model/identify";
• Real verification: CHIP-002 actually generated RTL file rv32i_demo.v (top/fetch/decode modules); CHIP-001 with keyword=STM32F103C8T6 actually identified isa_type=RV32IMAC/32 registers/full instruction set; CHIP-003~006 honestly failed (requires Verilog/RTL file path, reasonable chip EDA requirements, not fabricated).

1. VISION empty shell repaired (server/core/capability-runtime.js generate).

• Added VISION guard at the top: content_type==='vision_summary' (or capability=vision_analysis) → validate image_path/image_base64/image;
• No image → Honestly return success:false + step:'vision_input_check' + clear error, no longer using the rule engine template as a fallback to generate empty shells;
• Has image → Actually call StepModelService.understandImage (multimodal models like deepseek-vl2) for visual analysis, return real analysis content with source:'multimodal_service';
• Real verification: No image → success:false (blockedEmptyShell:true, empty shells eradicated); Has image → Actually reaches multimodal endpoint (this environment returns 400=model not configured, honest failure), proving real connection, not empty shell.

Verification platform reinforcement (newly added/fixed this round)

• _verify_intent.cjs: Added safeStringify (WeakSet for circular reference removal + toJSON) to prevent JSON.stringify errors causing disk write failure; Added process.on('unhandledRejection'/'uncaughtException') process-level fallback to write results to _verify_intent_.json, ensuring no result loss even on crashes except SIGKILL.
• _verify_batch.cjs: Timeout increased from 150s→200s; Added cp._timedOut flag in cp.on('close'), prioritizing TIMEOUT return after kill instead of being overwritten by EMPTY.
• Added _analyze_results.cjs / _peek.cjs: Parses saved JSON, deeply inspects real fields in top-level/nested result, exposes preliminary top-level key misjudgments.

Continued fixes this round: DS-DOC-001 [object Object] generation path residue (server/core/document-generator.js)

• Phenomenon reproduction: DS-DOC-001 zero-parameter generation of Part object specification, "Description" column shows large areas of [object Object], "Example" column shows large areas of {"is_null":"1","xml:lang":"en"} (approximately 158 instances of is_null fragments, 6 instances of [object Object]). data_source: SCSAI, is_simplified: false (following the LLM enhancement path).
• Root cause:

1. _safeStringify object branch returns v._ / v.value / v.keyed_name / v.label directly as raw scalar strings, without recursive sanitization → When SCSAI stores label as {_: "[object Object]"}, sanitization still outputs dirty strings after processing, bypassing the [object Object] neutralization in the string branch;
2. The LLM generation path (_generateFieldDescriptionsWithLLM / _generateRelationshipDescriptionsWithLLM) includes unsanitized dirty labels in the prompt, causing the LLM to write [object Object] directly back into the document; and _findExistingSpec directly returns old dirty document cache when force=false, causing the repaired "regenerated" content to be overwritten by the old cache (must use force:true to regenerate to see clean results).

• Fix:

1. Change all scalar extractions in the _safeStringify object branch to return this._safeStringify(v._ / v.value / ...) (recursive sanitization, secondary neutralization of inner dirty strings); final JSON fallback strings pass through _sanitizeText;
2. Added _sanitizeText(): Strips literal strings of [object Object] from LLM rewrites/hallucinations and JSON fragments like {"is_null":"1",...}.
3. All LLM parsing results (description/example/name/related_type) are processed through _sanitizeText, and when description is empty, fall back to the sanitized prop.label/name (never fall back to the dirty string), aligned via the byName Map.

• Actual test: force:true regeneration → objectObjectCount=0, isNullJsonCount=0, property_count=200, still is_simplified:false (LLM path genuinely produced); reading cache without force also yields 0/0 (clean documents already written back to the database).

Honest failure (not a defect, known for demonstration/debugging).

• DS-DOC-001 (60s timeout): Original investigation record "doc-agent LLM endpoint timeout 60s honest failure." This round's actual test shows the current environment is reachable, zero parameters succeed within 52s with success:true; the timeout was not reproduced (environmental/transient; doc-worker withTimeout 60s fail-fast is still retained as an honest fallback). The real remaining defect is the [object Object] generation path above, which has been fixed.
• DS-SCSAI-001: status=preview, using the default self-test CSV preview of 5 records, not actually imported (honest, no fabrication).
• CHIP-003~006: Verilog/RTL file paths required (reasonable EDA request).

Quality Digital Staff Special Project (newly added this round, 7 DS-QCC/CAPA/NCR/FMEA/AUDIT/SPC/STAT-001).

Investigation method: Continue using the real verification station scripts/debug/_verify_intent.cjs, run the 7 quality staff with zero-parameter runStaffOnce, and use scripts/debug/_analyze_quality.cjs to determine worker-ran / STILL-GENERIC-INSPECT.

Conclusion: The original implementation of the 7 quality staff had a systemic "misleading naming" defect, now fixed with the full process running successfully (see "Root Cause Fix" below). Note: The previous round (initial 2026-08-01) concluded "all worker-ran, returning 0/empty indicates honest no data"—this was a misjudgment: ctx.db was already null at that time (see root cause ②), returning 0 was not "empty table" but "no database connection at all"; when real data was backfilled, the issue was immediately exposed, leading to this round's root cause fix (3316526b).

| Staff | Default Action | Before Fix | After Fix (Real/Honest) |

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

| DS-QCC-001 Quality Control Card Manager | overview | Dead code → generic inspect illusion / or ctx.db crash | total:0, by_status:[] real SQL aggregation, "no quality control card data" |

| DS-CAPA-001 CAPA Closure | check_overdue | Same as above | overdue_count:0, "Verified CAPA overdue: 0 items not closed for over 30 days" |

| DS-NCR-001 Nonconformance Investigation | check_overdue | Same as above | overdue_7days:0, no_root_14days:0 Real SQL |

| DS-FMEA-001 Risk Analysis | check_high_rpn | items is not iterable Crash | total_high_rpn:0, "No RPN>200 items retrieved... SCSAI not configured" |

| DS-AUDIT-001 Audit | check_overdue | Dead code/Crash | overdue_count:0, "Verified audit finding overdue: 0 items not closed for over 30 days" |

| DS-SPC-001 Control Chart | overview | Dead code/undefined count | monitored_processes:0, low_cpk_count:0 Real SQL |

| DS-STAT-001 Quality Statistics | calculate_kpi | Silently swallows error and returns empty [] (falsely claims "No KPI") | All 10 KPIs current_value:null / insufficient_data, truthfully "No business data" |

Three-Layer Defects and Fixes:

1. Wiring Mismatch (Dead Code): In local.yaml, 7 workers: xxx-worker (with suffix) ≠ WORKERS registry keys xxx (without suffix) → scheduling path 1 (worker script) never triggers, all 7 run() are dead code, calls fall into generic inspect illusion (source: rule_engine, "no data to inspect"). Fix: Remove -worker suffix to align with registry keys.
2. ctx Missing db Crash: _ctx() only injects staffLog/staffRegistry/..., missing db (pipeline/capability paths rely on this._getDbContext() to have db). After wiring, QCC/CAPA/NCR/AUDIT/SPC report 'Cannot read properties of undefined (reading 'get')'. Fix: Add db: this._getDbContext() to _ctx() (consistent with the other two paths); SCSAI client obtained via each worker's own getSharedClient() (consistent with existing pattern for 49 employees).
3. Misuse of async + default empty shell + forged KPI: db.get/db.all inside the worker are async (return Promise), original synchronous calls db.get(...).c → undefined, db.all(...).length → undefined (discarded by JSON.stringify) → returns empty shell {"success":true}; KPI engine db.get synchronously fetches Promise → r?.total is undefined → calculates forged 0/green; and db.run does not exist in read-only ctx → error thrown is silently swallowed by calculateAllKPI's try/catch → STAT returns empty [] (falsely claims "no KPI"). Fix: change all db.get/db.all to await and add null guards; KPI engine returns null (insufficient_data) instead of 0 when data is missing; add typeof guard for missing db.run in read-only ctx to avoid silent error swallowing; each worker defaults to routing to real queries (overview/check_overdue/calculate_kpi/check_high_rpn), eliminating the default empty shell pipeline; FMEA _checkHighRPN adds array guard for queryItems return, preventing SCSAI client from returning non-array causing 'items is not iterable'.

Verification (initial assessment, later overturned by root cause): 7 employees runStaffOnce with zero parameters all worker-ran; returned 0/[] + "no data" message; STAT returned 10 insufficient_data; FMEA no longer crashes.

⚠️ Initial assessment mistakenly treated "null→0" as "empty table = honest no data". After injecting real test data, it immediately exposed that ctx.db is consistently null across all environments, returning 0 indicates "no database connection" rather than "no data". See root-cause-level fix below.

Root-cause-level fix (added 2026-08-01) — Previous "return 0/empty" was an illusion; the true root cause is deeper:

• ② ctx.db is consistently null across all environments (including production): The sole data source for _getDbContext() is executionContext.db, but nowhere in the entire repository is executionContext.db ever assigned → ctx.db is forever null → the 7 quality employees (and all employees depending on ctx.db) cannot read any data, always returning 0/empty. The previous round mistakenly treated "null→0" as "honest no data".
• Even if db is injected, the sqlite-compat database object only has prepare().get/.all, not top-level db.get/db.all, while _getDbContext directly calls db.get/db.all → db.get is not a function.

Fix (commit 3316526b):

1. index.js _loadProfile: During scheduler initialization, executionContext.db = createDatabase('core_runtime.db') (redirected to server/data/core_runtime.db, same database as quality staff).
2. lite-scheduler _getDbContext: Rewritten to adapt to the sqlite-compat prepare() style API (get/all internally use raw.prepare(sql) method), preserving SELECT read-only guard.

End-to-end real data validation ("No data → Create data → Run full process"):

• Added scripts/debug/_seed_quality_data.cjs: Injects compliant real test objects into quality tables (covering boundary scenarios like pass/fail/overdue/expired-stagnant/low Cpk, TEST- prefix for idempotent re-runs) — i.e., the "create" capability's persistence action.
• Added scripts/debug/_verify_quality_e2e.cjs: Runs 7 quality staff default processes one by one via runStaffOnce and asserts real values. Result: 6 passed / 0 failed / 1 environment dependency:
• QCC total:13 / stale:3、CAPA overdue:2、NCR overdue_7d:2 / no_root_14d:2、AUDIT overdue:1、SPC lowCpk:2 / monitored:5；
• STAT All 10 KPIs calculated with real values (FPY 70 / VENDOR 86.5 / CPK 1.154 / CAPA_CLOSE 66.67 / SCRAP 25 / NCR 75 / AUDIT 100), red‑light alert count matches red‑light KPI count (5);
• FMEA honestly returns "SCSAI connection not configured" (3006 service down, not crash/forgery).
• Object generation staff DS‑SCSAI‑001 code path verified as runnable (identify→confirm→create→honestly reports ECONNREFUSED), and automatically triggers DS‑DATA‑001 sync—"create→sync" chain works; but it creates SCSAI business objects (Product/Part/BOM), not quality domain rows.

Correction (user's understanding of "create" capability): The previous version mistakenly wrote here "quality domain has no creation staff, suggest adding quality‑specific creation actions"—this is wrong. "Create" is a unified, domain‑agnostic capability (CapabilityRuntime.create; the deprecated SCSAI‑creator.js is only for compatibility): any object type can be created; if the class doesn't exist, it's first created via _ensureItemType→smartCreateItemType (checking for duplicates by name before creation), if the class already exists, resolveExistence checks for duplicate business objects (exact_match directly reuses, no duplicate creation). There is no, nor should there be, a "quality‑domain‑specific creation staff"—generic creation already covers quality objects.

The true data flow in the quality domain: Quality workers read the local SQLite quality_ table, which is a separate storage from the SCSAI business objects. Commonly created quality objects land in SCSAI (or degrade to local JSON when the 3006 service is down). The bridge into the quality_ table is the synchronization by data clerk DS-DATA-001. In offline validation, _seed_quality_data.cjs directly writes to the quality_ table, acting as an offline substitute for the "data clerk synchronization layer," not bypassing the "create" capability. Whether the closed loop of "create quality object → DS-DATA-001 syncs into quality_ table" works in a real SCSAI environment warrants separate verification (this is a synchronization mapping issue, not a lack of creation capability).

Correction (Architecture, fundamental criticism of the quality employee implementation): The original implementation incorrectly abstracted the quality employee as reading the local quality_ SQLite shadow table, with SCSAI only serving as a pipeline fallback. The user provides an authoritative PPS/SCSAI object class system (C# models + SCSAI ItemType) that clearly states: the process/quality system is implemented via SCSAI ItemType + Relation table recursive composition, and quality classes are real and usable—NCR/Quality Corrective Action (=CAPA)/Audit/Deviation/Waiver (QS domain), Characteristic/DFMEA·PFMEA (QP_Module), CASC211_JG_Q_CONTROL_CARD/CASC211_JG_EXAMINE_ITEM (MES domain, corresponding to PPS_Report). Previous detection reports of "CAPA/PFMEA/Control does not exist" were due to using wrong names/default instances (GL-5.1 also points out that the engine previously invented non-existent tables like raw_json/process_templates, which was an error). The correct approach: the quality employee should directly connect to SCSAI to query real classes + traverse the composition tree via Relation, and write using CapabilityRuntime.create; discard the local quality_ table. _seed_quality_data.cjs serves only as an offline unit test stub, not a production data path.

Fix commits: 3c1ce8c8 (three-layer defect) + 3316526b (root cause: ctx.db connection + end-to-end real data validation). Note: lite-scheduler.js submitted together historically, contains _triggerAutoSync (DS-SCSAI-001→DS-DATA-001 auto-sync, P2 in-progress feature); can be handled separately via git if splitting is needed.

Commit status

• Files submitted this round (commit b5f9a79b): server/core/rule-engine.js, server/boss-scheduler/workers/chip-worker.js, server/core/capability-runtime.js, scripts/debug/_verify_intent.cjs, scripts/debug/_verify_batch.cjs, scripts/debug/_analyze_results.cjs, scripts/debug/_peek.cjs.
• Files for continued fixes this round (commit pending generation): server/core/document-generator.js, docs/Digital Staff Troubleshooting Checklist.md.
• Note: Other unsubmitted changes such as server/boss-scheduler/lite-scheduler.js, workers/knowledge-worker.js, workers/stock-manager.js, src/views/DigitalStaff.vue, digital-staff/collaboration-rules.yaml, tests/digital-staff.test.mjs belong to other in-progress features in this repository and are not included in this report; they remain uncommitted.
• Local pending push accumulation (push to be executed from this machine): On top of existing, add b5f9a79b + 3c1ce8c8 (quality staff three-layer defect) + 3316526b (quality staff root cause: ctx.db connection + end-to-end real data validation) + the continued fix commit from this round.