Dual DB Split Repair Record (2026-07-11)

Root Cause

The project has two rule_engine.db files:

• D:\openclaw\bossagents\data\rule_engine.db (old DB, 471KB): 298 types / 2821 attributes / 431 relations / 298 templates / No sciot_rules_v2 table
• D:\openclaw\bossagents\server\data\rule_engine.db (new DB, 765KB): 616 types / 2821 attributes / 431 relations / 306 templates / 76 rules

Core code split into two sets:

• getSciotDb() in server/utils/SCSAI-tools.js uses '../../data' (from server/utils) = points to old DB, used by core creation/read chains like unified-create.js, aml.js, relationship-capability.js, itemtype.router.js, capability-pipeline.js.
• _initRuleEngine() in server/core/capability-runtime.js uses '../data' (from server/core) = points to new DB, used by the six capabilities.

This is precisely the root cause of the previous hidden issue of 'occasional inconsistent behavior and fluctuating rule counts in validate/repair'—two paths reading different databases.

Fix

1. Line 41 in server/utils/SCSAI-tools.js: change dbPath from

path.join(__dirname, '..', '..', 'data', 'rule_engine.db')

to

path.join(__dirname, '..', '..', 'server', 'data', 'rule_engine.db')

→ Unify to point to the new database.

1. Delete the isolated old database: A full-tree audit via tmp_audit_paths.js confirms that no files within server/ resolve to the old database at runtime (previously thought possible; tests show all ../data references from server/core, server/routes, etc., land in server/data/; consistency-check.js's '../../data' from server/boss-scheduler/lib also points to server/data/).

data/rule_engine.db has no runtime code references and is confirmed as pure historical residue.

Instead of direct rm, moved to data/_deprecated_rule_engine_db_20260711-184656/ for recoverable retention.

Verification (after deleting old DB + restart)

• Server restarted normally (pid 33584), /api/health returns ok.
• POST /api/unified/create (via SCSAI-tools.getSciotDb path) Part creation succeeded and persisted, no 'rule_engine.db unavailable' error in server.err.
• All six capabilities passed (no regression):
• VALIDATE (existing object with name 50066E...): executed=true blocked=false rules=6 source=rule_engine
• OPTIMIZE: found=4 source=rule_engine
• REPAIR: executed=true issues=1 applied=2 SCSAI=true (actual write-back)
• IDENTIFY: executed=true matched=true
• COMPARE: executed=true
• GENERATE: executed=true src=fallback
• Relational creation (Model + sourceId) still returns success=500 and repair remains effective; Model without sourceId returns 400, boundary correct.

Note

• Newly created test object 80761D7343DC4F7BAB2371822DA13FFB (name='POST_DEL_CHECK_PART') reports blocked=true in validate: 'name cannot be empty'—this is a historical mapping issue with the CREATE name field (SCSAI side name not correctly persisted), not a regression introduced by this old DB deletion (same method tested on existing object shows blocked=false normal).
• Temporary probe scripts (tmp_*.js) have all been cleaned up.