ScreenTinker 7ab19adcea fix(db): observable migrations + fail-fast schema verification (#37) ... Self-hosters rebuilding could end up schema-behind-code, failing only at runtime (a missing users.must_change_password locked out all logins). Two root causes: 1. The migration loop swallowed EVERY error (catch {}), so a real ALTER failure was indistinguishable from the benign 'duplicate column' on an already-migrated DB. Now only 'duplicate column'/'already exists' is treated as a no-op; any other error is logged loudly, and a one-line summary reports how many new column migrations actually applied this boot. 2. Nothing verified the schema after migrations. Added lib/schema-check.js: verifyAndRepairSchema() checks the tables + columns the request path REQUIRES, idempotently repairs missing repairable columns (logging each), and if anything required is STILL missing, prints a loud FATAL block and exits - failing fast at boot instead of at the first authed request. Note: the reported 'audit_log missing' was a misdiagnosis - the code uses activity_log (0 refs to audit_log), created by schema.sql on every boot. Tests: healthy (no-op), auto-repair of must_change_password, missing-table report.		2026-06-09 09:31:52 -05:00
..
database.js	fix(db): observable migrations + fail-fast schema verification (#37)	2026-06-09 09:31:52 -05:00
schema.sql	feat(layouts): per-zone fit mode + default to 'contain'	2026-06-09 08:55:15 -05:00