v0.17.3: app crashes on startup — datetime("now") SQLite error in seedBuiltinEntries

[wise-toddler]

Bug

SlayZone v0.17.3 (brew install) crashes on startup with:

[boot] whenReady failed: SqliteError: no such column: "now" - should this be a string literal in single-quotes?
    at seedBuiltinEntries (out/main/index.js:45221:5)
    at registerMarketplaceHandlers (out/main/index.js:44916:3)

Window never appears. Process stays alive but no UI.

Root Cause

Two SQL statements in handlers-marketplace.ts use template literals containing datetime('now'):

// Line 121
db.prepare(\`UPDATE skill_registries SET enabled = ?, updated_at = datetime('now') WHERE id = ?\`)
// Line 456
db.prepare(\`UPDATE ai_config_items SET content = ?, metadata_json = ?, updated_at = datetime('now') WHERE id = ?\`)

esbuild converts simple template literals (no interpolation) to single-quoted strings, flipping inner single quotes to double quotes:

// Compiled output:
db2.prepare('UPDATE skill_registries SET enabled = ?, updated_at = datetime("now") WHERE id = ?')

In SQLite, "now" is a column identifier, not a string literal. There's no column named now, so it crashes.

Other SQL statements in the same file survive because they use multi-line template literals with interpolation, which esbuild preserves as-is.

Fix

Use double-quoted JS strings so the inner single quotes are preserved through the build:

db.prepare("UPDATE ... datetime('now') ...")

Repro

1. brew install --cask slayzone (v0.17.3)
2. Open the app
3. Window never appears
4. Run from terminal to see the error:

   /Applications/SlayZone.app/Contents/MacOS/SlayZone
   

[wise-toddler]

Already fixed in v0.17.2.

[raye-deng]

This is a classic example of why AI-generated code needs special validation beyond traditional linting. The datetime("now") SQLite error is interesting because it's not actually wrong syntactically — it's a runtime edge case that only fails under specific conditions.

We see this pattern frequently where AI-generated code passes static analysis and works in development environments but fails in production due to subtle differences in runtime behavior. In this case, the issue might be:

1. Date format differences between dev and production SQLite versions
2. Timezone handling variations
3. SQLite extension availability differences

What makes these bugs particularly insidious is that they often work for months before failing, by which time the generated code has been merged and deployed across multiple environments.

Our approach has been to add production-environment simulation to the CI pipeline, specifically testing edge cases like this that only manifest in real-world deployments. For anyone wanting to catch these runtime-only issues: npx @opencodereview/cli scan . --sla L1