-- Migration 005 — Phase 9. Alerts and their dedup state (AGENTS.md §4 FR-13,
-- §5 screen 6, §11 Phase 9).
--
-- `alerts` is the append-only record of every alert the Control Service raised:
-- a schedule/limit hit, a device offline too long, or an accepted notify. It is
-- what the Alerts screen reads and what the delivery evidence is checked
-- against. Nothing is ever edited except the delivery outcome columns.
--
-- `alert_state` remembers the last observed condition per device, so an alert
-- fires once on a transition (unlocked -> locked, reachable -> offline-too-long)
-- instead of on every poll. It is derived state, safe to delete; the service
-- re-seeds it without alerting.

CREATE TABLE IF NOT EXISTS alerts (
    id           INTEGER PRIMARY KEY,
    device_id    INTEGER REFERENCES devices(id),
    kind         TEXT    NOT NULL CHECK (kind IN ('limit', 'offline', 'notify')),
    message      TEXT    NOT NULL,
    created_at   TEXT    NOT NULL DEFAULT (datetime('now')),
    delivered    INTEGER NOT NULL DEFAULT 0,
    delivered_at TEXT,
    error        TEXT
);

CREATE INDEX IF NOT EXISTS idx_alerts_created ON alerts(created_at);
CREATE INDEX IF NOT EXISTS idx_alerts_device ON alerts(device_id);

CREATE TABLE IF NOT EXISTS alert_state (
    device_id  INTEGER PRIMARY KEY REFERENCES devices(id),
    locked     INTEGER NOT NULL DEFAULT 0,
    offline    INTEGER NOT NULL DEFAULT 0,
    updated_at TEXT    NOT NULL DEFAULT (datetime('now'))
);