doctor command: db.get() is not a valid better-sqlite3 API, and ESM require() misreports core modules as "not available" #23

Confirmed on 3.0.0-alpha.20 (current npm latest at time of filing). Two independent bugs in dist/cli/commands/doctor.js.

Bug 1 — wrong better-sqlite3 API, fails every real database

doctor.js line 84:

const config = db.get('SELECT * FROM config WHERE key = ?', ['initialized']);

better-sqlite3's Database instance has no .get() method — the real API is db.prepare(sql).get(...params). This throws TypeError: db.get is not a function immediately, caught by the outer try/catch and reported as:

❌ Database error: db.get is not a function

...on every database, regardless of actual health. Same issue at line 92 (db.get(\SELECT COUNT(*) as count FROM ${table}`)`).

A second, independent problem in the same query: even with the correct API, SELECT * FROM config assumes a config table that doesn't exist in the schema AgentDB itself creates. Verified against a real, populated agentdb.db — 28 real tables (episodes, skills, causal_edges, learning_sessions, recall_certificates, etc.), none named config.

Bug 2 — require() used in an ESM file, misreports fs/path/crypto as missing

package.json declares "type": "module", and doctor.js itself opens with import { createDatabase } from '../../db-fallback.js'; — genuinely ESM. Lines ~148-158:

for (const mod of coreModules) {
    try { require(mod.module); ... }
    catch { console.log(`  ❌ ${mod.name} not available`); }
}

In ESM, bare require is undefined — this throws ReferenceError: require is not defined, caught and misreported as "fs/path/crypto not available," even though these are always-present Node builtins. The same require(...) pattern appears again around line 246 for the optional @xenova/transformers check — likely the same root cause, just less obviously wrong there since "not installed" happens to still read as a plausible message.

Repro

agentdb doctor

against any real, populated database.

Impact

doctor reports ❌ System Status: ISSUES DETECTED on fully healthy installations — actively misleading for anyone using it to diagnose real problems.

Suggested fix

• Replace db.get(sql, params) with db.prepare(sql).get(...params), and drop or rewrite the config table check to match the actual schema.
• Replace the require() core-module probe with import(mod.module) (or just remove it — these are guaranteed-present builtins).