@aexol/spectral 0.9.185 → 0.9.186

package/dist/server/storage.js

@@ -4,10 +4,12 @@
  * Two-tier model:
  *   projects ─< sessions ─< messages
  *
- * Single-process, single-file. Using `better-sqlite3` because:
- *  - Synchronous API is a perfect fit for the per-WS-event write pattern.
- *  - No connection pool, no callback churn, transactions are trivial.
- *  - Native module ships prebuilt binaries for every Node version we support.
+ * Single-process, single-file. The storage layer goes through the `SqliteAdapter`
+ * abstraction (see `sqlite-adapter.ts`) which prefers Node's built-in
+ * `node:sqlite` on modern Node, `bun:sqlite` under Bun, and only falls back
+ * to `better-sqlite3` on older Node runtimes. The synchronous adapter API is a
+ * perfect fit for the per-WS-event write pattern: no connection pool, no
+ * callback churn, transactions are trivial.
  *
  * Schema migrations:
  *   We track schema with the `user_version` PRAGMA. When opening a DB whose
@@ -1478,8 +1480,9 @@ export function preflightSqlite(dbPath) {
         const msg = err instanceof Error ? err.message : String(err);
         return {
             ok: false,
-            error: `Failed to load native sqlite module (${msg}).\n` +
-                `  This usually means the native binary couldn't be built for your Node.js version.\n` +
+            error: `Failed to load the SQLite storage module (${msg}).\n` +
+                `  On Node >= 22.5 spectral uses the built-in node:sqlite module; on older\n` +
+                `  Node it falls back to better-sqlite3, which needs its native binary built.\n` +
                 `  Try: cd ${getConfigDir()} && npm rebuild better-sqlite3\n` +
                 `  Or reinstall: npm install -g @aexol/spectral`,
         };

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@aexol/spectral",
-  "version": "0.9.185",
+  "version": "0.9.186",
   "description": "AI coding agent for Aexol with relay-based browser access.",
   "type": "module",
   "private": false,