Rescued from an uncommitted worktree (analyticshq-bughq-fixes), rebased onto current main.
Remote command actions
The framework's default remote-command actions import the optional ~/config/remote module. AnalyticsHQ does not configure dashboard-managed SSH hosts or commands and has no such file, so the import fails.
Two application overrides replace them:
RemoteCommandIndexActionreturns a valid, empty registry ({ hosts: [], commands: [] })RemoteCommandRunActionfails closed rather than attempting a command against hosts that were never configured
Migration 0000000053
AnalyticsHQ enables the framework newsletter routes, but its migration corpus predates the framework Subscriber models, so a clean database could not serve the public signup action. This adds subscribers and subscriber_emails.
Two properties worth noting in review:
- Idempotent —
CREATE TABLE IF NOT EXISTSplusCREATE UNIQUE INDEX IF NOT EXISTSfor both indexes, so a re-run is a no-op. - Foreign keys declared inline in
CREATE TABLE, not viaALTER TABLE ... ADD CONSTRAINT ... FOREIGN KEY. That form is what SQLite rejects withnear "FOREIGN": syntax error, and it is the cause of the statushq deploy failures being fixed in statushqorg/status#18. Declaring them inline sidesteps it.
BIGSERIAL is Postgres syntax. That matches config/database.ts:17 (default: env.DB_CONNECTION ?? 'postgres') and follows two existing migrations in this repo that already use it — so it introduces no new constraint, though it does mean this migration will not apply against the SQLite that .env.example:32 suggests for local development.
Verification
- Suite: 983 pass / 0 fail on
main→ 988 pass / 0 fail here (+5, the new tests) - Lint: 0 errors, 0 warnings across 191 files
- Typecheck: clean
Tests cover both halves: the actions load without the optional config alias and the run action fails closed; the migration creates both tables, keeps email and uuid unique, and links subscriber_emails to subscribers.