grabowski
b4108c5a36
Phase 1 of the maintenance-reminders feature. - notification_kind: + maintenance_due_soon, maintenance_overdue. These are distinct from maintenance_event_recorded (service performed) so the bell list can group/filter reminder vs service cleanly. - New maintenance_reminder_kind enum: due_soon | overdue. - New maintenance_reminders_sent table with UNIQUE(schedule_id, kind, due_at). The cron uses INSERT … ON CONFLICT DO NOTHING on this composite to make the fire-once-per-window guarantee atomic even under concurrent runs. Once the schedule's next_due_at advances after a service event, the tuple is fresh and a new reminder fires. No service code yet — Phase 2 wires the readers and orchestrator. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
drizzle migrations
This directory holds SQL migrations generated by drizzle-kit generate from the
TypeScript schema in src/lib/server/db/schema/.
Commands:
pnpm run db:generate— diff the schema vs. the latest snapshot and emit a new.sqlfilepnpm run db:migrate— apply pending migrations toDATABASE_URLpnpm run db:push— skip migrations and sync the schema directly (dev only)pnpm run db:studio— open the Drizzle Studio UI
After every generate, review the SQL for surprises — especially around:
- enum additions (non-blocking) vs. removals (require a separate data migration)
- index changes on large tables (use
CONCURRENTLYin production rollouts) - anything touching
assets.custom_fields— seeproject_buildfor_life_ops.mdmemory for the immutable-key policy.