[Phase 2] feat(core): fee alerts — database schema and CRUD endpoints

[Tinna23]

Overview

Add the database schema and REST endpoints for managing fee alert rules. An alert rule defines a threshold condition that, when met, triggers a notification.

Database Schema

Add an alerts table to SQLite:

CREATE TABLE alerts (
  id          TEXT PRIMARY KEY,
  condition   TEXT NOT NULL,  -- 'ABOVE' | 'BELOW'
  threshold   INTEGER NOT NULL,
  metric      TEXT NOT NULL,  -- 'avg_fee' | 'base_fee' | 'max_fee'
  email       TEXT,           -- nullable, for email delivery
  active      INTEGER NOT NULL DEFAULT 1,
  triggered   INTEGER NOT NULL DEFAULT 0,
  created_at  TEXT NOT NULL
);

Endpoints

POST /api/alerts

Create a new alert rule.
Request body:

{
  "condition": "ABOVE",
  "threshold": 500,
  "metric": "avg_fee",
  "email": "user@example.com"
}

Response: created alert object with generated id

GET /api/alerts

List all active alert rules.
Response: array of alert objects

DELETE /api/alerts/:id

Delete an alert rule by id.
Response: { "deleted": true }

GET /api/alerts/status

Returns currently firing alerts (rules where condition is currently met).
Response: array of firing alert objects with current metric value attached

Acceptance Criteria

• alerts table created via migration, not hardcoded CREATE TABLE IF NOT EXISTS
• All four endpoints implemented with correct HTTP status codes
• Input validation on POST — reject invalid condition, metric, or missing threshold
• id generated as a UUID
• Unit tests for CRUD operations
• CORS headers consistent with existing endpoints

Notes

• Related issues: alert checker, email sender, and frontend alert panel
• triggered field will be updated by the alert checker service (separate issue)