agentlas 1.0.48 → 1.0.50

package/README.md

@@ -228,7 +228,9 @@ The launcher (`bin/agentlas.cjs`) runs system Node against `engine/`. The defaul
 | Windows | `%APPDATA%\Agentlas` |
 | Linux | `$XDG_CONFIG_HOME/Agentlas` (default `~/.config/Agentlas`) |
 
-The SQLite database file is `agentlas.sqlite` (`user_version=86`). When launched for the first time without an existing database, it bootstraps schemas using `engine/bootstrap-schema.sql`. Consequently, **projects, installed agents, task history, automation sessions, and MCP registrations are shared across Desktop and Terminal**. The first ordered project agent remains the controller; additional agents are task-scoped and are stored only as execution ledgers, never as global conversations or durable owners.
+The SQLite database file is `agentlas.sqlite` (`user_version=97`). When launched for the first time without an existing database, it bootstraps schemas using `engine/bootstrap-schema.sql`. Consequently, **projects, installed agents, task history, automation sessions, and MCP registrations are shared across Desktop and Terminal**. The first ordered project agent remains the controller; additional agents are task-scoped and are stored only as execution ledgers, never as global conversations or durable owners.
+
+**Single migration authority.** The Desktop app owns the schema migration ladder; the CLI never migrates the shared database. `engine/bootstrap-schema.sql` is generated by running that ladder to completion against an empty database, so a CLI-created store already sits at the ladder head and has nothing left for Desktop to upgrade. If the CLI opens a store older than the version it knows, it refuses with an actionable message instead of migrating or silently proceeding — a second migrator on this lock-free file is what corrupted the store once before. On a machine with no Desktop app, an operator can set `AGENTLAS_STORE_MIGRATION_ROLE=owner` for a single deliberate upgrade run with every other Agentlas process closed.
 
 SQLite driver priority: `better-sqlite3` (optional dependency native build), then Node 22+ `node:sqlite` when the first driver is unavailable.
 
@@ -289,7 +291,7 @@ Engine source code resides in `engine/*.cjs`.
 ```sh
 sh test/smoke.sh                              # Runs surface tests, guard tests, fresh DB tests, contract tests & parity gates
 npm run smoke                                 # Equivalent to npm run test:release-contracts
-sh scripts/gen-bootstrap-schema.sh [db-path]  # Regenerates engine/bootstrap-schema.sql
+node scripts/gen-bootstrap-schema.cjs         # Regenerates engine/bootstrap-schema.sql from the Desktop ladder (never reads a live store)
 ```
 
 Smoke tests run isolated inside a temporary `AGENTLAS_USER_DATA_DIR` and do not touch local user data.

package/bin/agentlas.cjs

@@ -155,12 +155,22 @@ function bootstrapDbIfMissing() {
     throw new Error(`Bootstrap schema not found: ${schemaFile}`);
   }
   const sql = fs.readFileSync(schemaFile, "utf8");
+  // ★새 저장소는 태어날 때부터 WAL 이어야 한다 (2026-08-18 실측).
+  // journal_mode 는 파일에 박히는 값이고, delete→WAL 전환은 **배타 락**을 요구하며
+  // busy_timeout 이 걸려 있어도 즉시 SQLITE_BUSY 로 실패할 수 있다. 그래서 터미널이
+  // 만든 DB 를 delete 모드로 남기면, 데스크탑과 터미널이 그 파일을 처음 동시에 여는
+  // 순간 한쪽이 "database is locked" 로 죽는다 — 첫 부팅에서만 나는, 재현이 어려운
+  // 결함이다. 여기서 한 번 켜 두면 그 전환 자체가 존재하지 않는다.
+  const WAL_PRAGMA = "PRAGMA journal_mode=WAL;\n";
   // DB를 정식 경로에서 직접 만들면 두 첫 실행이 모두 exists=false를 본 뒤 한 프로세스의
   // 실패 cleanup이 다른 프로세스의 정상 DB까지 지울 수 있다. 각자 같은 볼륨의 임시 DB를
   // 완성하고 hard-link(EEXIST=다른 프로세스 승리)로만 정식 이름을 원자 획득한다.
   const temp = `${p}.bootstrap-${process.pid}-${Date.now()}-${Math.random().toString(16).slice(2)}.tmp`;
   const db = openSqlite(temp);
   try {
+    // 임시 파일에서 켠다. journal_mode 는 DB 헤더에 박히므로 hard-link 로 정식 이름을
+    // 얻은 뒤에도 유지된다(닫을 때 -wal 은 체크포인트되고 사라진다).
+    db.exec(WAL_PRAGMA);
     db.exec(sql);
   } catch (e) {
     db.close();

package/engine/agentlas-sqlite-policy.cjs

@@ -4,6 +4,15 @@
 // lock waits bounded, and acquire writer authority before a transaction reads
 // state that it may subsequently update. A deferred read-to-write upgrade can
 // fail immediately with SQLITE_BUSY even when busy_timeout is configured.
+//
+// ★This value must stay identical to `STORE_BUSY_TIMEOUT_MS` in
+// agentlas_desktop/electron/store/db.ts. Until 2026-08-18 the Desktop waited 5s
+// and the terminal 15s on the very same file, so under contention the Desktop
+// was always the first to give up with SQLITE_BUSY — even when the terminal was
+// the slow writer. That asymmetry made shared-file contention look like a
+// Desktop-only bug. 15s is the agreed value: nothing holds a transaction on this
+// file for long (the longest writer is the migration ladder), so it is a ceiling
+// that is essentially never reached rather than added latency.
 const SQLITE_BUSY_TIMEOUT_MS = 15_000;
 
 // `foreign_keys` 는 파일이 아니라 **커넥션** 속성이다. 데스크탑은

package/engine/agentlas-workload-routing.cjs

@@ -485,14 +485,18 @@ function createDecisionReceipt({ taskId, stage, decision, resolution, role, usag
       modelId: normalized && normalized.exactModelId
         ? normalized.exactModelId
         : source === "user-pin" ? cleanText(resolution && resolution.model, 255) || null : null,
-      effort: normalized ? normalized.effort : "none",
+      // "none" is an effort level; no request is not one. Rendering the
+      // absence as a level made the receipt claim a decision nobody made —
+      // measured on the desktop twin, 17 of 46 receipts said resolved.effort
+      // "none" while carrying no effort-* reason code at all.
+      effort: normalized ? normalized.effort : null,
     },
     resolved: {
       tier: resolution && resolution.tier ? cleanText(resolution.tier, 32) : normalized ? normalized.tier : null,
       provider: cleanText(resolution && resolution.provider, 80) || null,
       modelId: cleanText(resolution && resolution.model, 255) || null,
       sessionId: cleanText(resolution && resolution.runtimeId, 255) || null,
-      effort: cleanText(resolution && resolution.effort, 16) || "none",
+      effort: cleanText(resolution && resolution.effort, 16) || null,
     },
     reasonCodes,
     inputFeatureHash: normalized && normalized.inputFeatureHash ? normalized.inputFeatureHash : featureHash,