You cannot select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

Thomas Joise 0adce5844b fix(backup): resolve the production database the way the server does ... `npm run backup` ran scripts/backup.mjs, which read process.env.DATABASE_URL directly and exited when it was unset. On the production box DATABASE_URL is NOT exported -- the connection is resolved (D19) -- so the backup command could never reach the real data. The dump now lives in apps/hq (src/backup.ts + a thin scripts/backup.ts CLI, the same split the other maintenance scripts use, so it is typechecked and unit tested) and resolves its target through the shared resolveDbUrl. It logs the resolved host/db -- never the password -- before pg_dump runs, and a SQLite outcome is a loud error naming backup-hq.sh instead of a dump of nothing. Behaviour otherwise unchanged: -Fc dump under ./backups (or HQ_BACKUP_DIR), rotation to the newest HQ_BACKUP_KEEP (default 14), same pg_dump discovery. The .mjs entry could not import the TS resolver, and duplicating the resolution would have re-introduced the copy of the production connection string that 6f50799 deliberately removed -- hence the move to TS. `npm run backup` is unchanged for the operator; prod already runs `npx tsx apps/hq/scripts/...` for maintenance (see DEPLOY-HQ.md), so tsx is on the box. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>		1 day ago
..
hq	fix(backup): resolve the production database the way the server does	1 day ago
hq-web	fix(ui): restore sticky table headers, dashboard loading flash, ticket-type over-fetch	1 day ago