BossAgents数据库旁路堵漏修正（2026-07-15 第二轮）
用户修正版诊断（已验证采纳）
v2 sqlite-compat.js 已修核心层（better-sqlite3 单例 + WAL + FAILFAST + save() no-op）。但仍有绕过点直接绕过单例。
修正事实核对（关键：用户原方案有 3 处需收窄）
- 旁路③
ai-task-manager.js不存在 → 幽灵文件，跳过（不盲改不存在的文件）。 - "313 个空 catch" 被高估：实测 310/313 是良性兜底（
fs.mkdirSync/fs.statSync/JSON 解析回退/表未建预期错误）。改 console.error+重抛会让正常工况崩溃。仅数据层关键写入 catch 需暴露日志。 - 旁路①
_recoverMetaIfEmpty用 sql.js 特有std.exec()返回{columns,values}语法，不能直接 replace 成createDatabase（compat 的exec走 better-sqlite3 原生，不取结果）。需改写取数逻辑为 compat 的prepare().all()。
实际执行改动
| 文件 | 行 | 改动 | 风险 |
|---|---|---|---|
| server/self-evolving-pipeline.js | 32-43 | getDb() 由 new better-sqlite3() 改为 require('./sqlite-compat').createDatabase(dbPath) | 零风险（sccapp_process_data.db 已在 KNOWN_DBS，自动归一化+单例+WAL） |
| server/core/rule-engine.js | 313-316 | _recoverMetaIfEmpty 的 sql.js 只读兜底改写为 compat 单例读源库（prepare().all() 取 schema/数据，替代 std.exec 的 columns/values）；删 std.close()/this.db.save() | 低风险（保留恢复逻辑，语法兼容） |
| server/core/rule-engine.js | 466 | 列迁移 catch(e){} → catch(e){ this.logger.error(...)}（不重抛，避免初始化中断） | 零风险 |
| server/core/rule-engine.js | 3040 | 规则历史写入 catch(e){} → error 日志（不重抛） | 零风险 |
| server/core/rule-engine.js | 3045 | _updateRuleStats catch(e){} → error 日志（不重抛，保留 if(!this.db) return 守卫） | 零风险 |
明确未动（避免回归）
- 310 个良性空 catch（fs 类/JSON 解析回退/表未建预期）— 不应改成 console.error+重抛。
rule-engine.jsL1734/1804/1816 等解析回退 catch — 失败回退到 props 兜底属设计意图。rule-engine.jsL301/340 的try{this.db.save()}catch(_){}— save() 已是 v2 no-op，捕获非错误是设计。- 不新建 db-registry.js（canonicalPath 已承担此角色）；不换驱动（better-sqlite3 已是底层）。
验证结果
- 残留 sql.js 代码引用：0（4 处均为注释）。
- 语法校验：rule-engine.js / self-evolving-pipeline.js 均 OK。
- 单例复用：
sccapp_process_data.db在_debugInstances缓存键数 = 1，跨包装器读写同一底层数据成功。 - WAL：pipeline 库 journal_mode = wal（此前直连无 WAL）。
- 服务重启：
/api/health200、/api/rule-engine/stats= {total:2413, active:2386}，引擎初始化无 dead/unsupported 告警。
遗留（非本轮范围）
- 310 个良性空 catch 长期仍建议分类审计，但不紧急（不造成数据层静默失败）。
- 14 个 .db 文件未物理合并，仍靠 canonicalPath 逻辑归一化路径；多库并存是独立架构债。
- 27 条退役规则（SCSAI 原生/业务建议型）业务能力无本地引擎承载，依赖 SCSAI/LLM 侧。
