-- 162_seed_deals_freshness_monitor.sql
-- Issue #2212 — seed scrape_schedules row for the daily deals-data freshness monitor.
--
-- Context (verified on prod 2026-07-02):
--   deals.deal_date is the LABEL of a quarter's start (2026-01-01 == 2026Q1); Rosreestr
--   publishes quarterly dumps. Current max(deal_date) = 2026Q1 — the LATEST published
--   quarter, so the import is NOT broken (rows_fetched 49791 / inserted 0 == already
--   fully imported). Downloading a new dump is a MANUAL operator step; rosreestr_quarter_poll
--   only detects availability and alerts — it does not ingest.
--
--   Audit gap: the `done` status of rosreestr_quarter_poll / rosreestr_dkp_import MASKS
--   staleness of the DATA. A green job-status can sit on top of quarter-stale deals if
--   the operator missed the manual import. This monitor watches max(deal_date) directly
--   and raises an ERROR alert (→ GlitchTip via sentry logging integration) when the next
--   quarter is overdue for publication.
--
--   Overdue arithmetic (app/tasks/deals_freshness_monitor.py::evaluate_deals_freshness):
--     latest_q_start    = max(deal_date)                      (2026-01-01)
--     latest_q_end      = latest_q_start + 3 months           (2026-04-01, start of Q2)
--     overdue_threshold = latest_q_end + 3 months + lag_days  (2026-07-01 + 45d = 2026-08-15)
--     overdue           = now() > overdue_threshold
--   At 2026-07-02 the threshold (2026-08-15) is not reached -> NO alert. If Q2 is still
--   not imported by 2026-08-16, the monitor starts alerting daily.
--
--   Components deployed together:
--     1. app/tasks/deals_freshness_monitor.py — check_deals_freshness() + evaluate_deals_freshness()
--     2. app/services/scheduler.py — trigger_deals_freshness_monitor_run() + dispatch branch
--        `elif source == "deals_freshness_monitor"`
--     3. app/services/product_handlers.py — kit Handler 'deals_freshness_monitor'
--     4. This migration — seeds the scrape_schedules row (enabled=true, daily window)
--
-- Schedule window 08:00-09:00 UTC:
--   Daily cadence, placed AFTER rosreestr_dkp_import (04:16 UTC window) so the monitor
--   observes the freshest possible deals state each morning. Cheap: one SELECT max(deal_date),
--   no external HTTP — safe to run daily.
--
-- default_params.lag_allowance_days = 45:
--   Allowance for Rosreestr to publish the next quarter's dump after that quarter ends.
--
-- next_run_at bootstrapped to tomorrow 08:00 UTC — scheduler will not fire immediately
-- on deploy (same pattern as 093/096/160).
--
-- Idempotent: ON CONFLICT (source) DO NOTHING — safe to re-apply.
--
-- Dependencies:
--   052_scrape_schedules.sql (table + UNIQUE(source))
--   002_core_tables.sql (deals table with deal_date)
--   app/services/scheduler.py + product_handlers.py + tasks/deals_freshness_monitor.py deployed
--
-- Deploy order:
--   Apply after deploying the scheduler.py + product_handlers.py + task changes so the
--   dispatch can resolve 'deals_freshness_monitor' correctly on first fire.

BEGIN;

INSERT INTO scrape_schedules (
    source,
    enabled,
    window_start_hour,
    window_end_hour,
    next_run_at,
    default_params
)
VALUES
(
    'deals_freshness_monitor',
    true,                                        -- SAFE: single SELECT max(deal_date), no ext calls
    8,                                           -- window 08:00-09:00 UTC (after rosreestr_dkp_import)
    9,
    ((CURRENT_DATE + INTERVAL '1 day') + make_interval(hours => 8)) AT TIME ZONE 'UTC',
    '{"lag_allowance_days": 45}'::jsonb          -- publication-lag allowance before alerting
)
ON CONFLICT (source) DO NOTHING;

COMMIT;
