-- 180_seed_sber_freshness_monitor.sql
-- Audit п.1 — seed scrape_schedules row for the daily СберИндекс data-freshness monitor.
--
-- Context (verified on prod 2026-07-12):
--   estimator._load_sber_index_series (#794/#audit-5a) applies a СберИндекс time-adjustment
--   to ДКП deals and only LOGS a per-estimate warning when the latest series month is older
--   than settings.sber_index_max_age_days (35d). The `sber_index_pull` job runs monthly
--   (enabled), but СберИндекс publishes with an inherent ~1-2 month lag, so
--   sber_price_index.period_month drifts. Current max(period_month) for the oblast secondary
--   segment = 2026-05-01 (~72d old). NOT a silent failure, but the staleness is buried in
--   per-estimate warnings — invisible at monitor cadence.
--
--   Audit gap: ops has no monitor-frequency signal for СберИндекс staleness. This monitor
--   watches max(period_month) directly and raises a per-day WARNING when the data is stale
--   beyond the allowed publication lag.
--
--   Staleness threshold (app/tasks/sber_freshness_monitor.py::evaluate_sber_freshness):
--     age_days      = now() - max(period_month)
--     max_age_days  = settings.sber_index_max_age_days (35) + lag_allowance_days (25) = 60
--     stale         = age_days > max_age_days
--   The +25 lag_allowance covers the INHERENT СберИндекс publication lag (source is 1-2mo
--   behind; period_month is the first-of-month label; the monthly pull has not yet caught the
--   newest period). Below 60d the latest period is treated as normally-lagging -> NO alert
--   (avoids daily noise on штатный lag). Above 60d the data is stuck beyond ~2 months -> alert.
--   At 2026-07-12: max=2026-05-01, age=72d > 60 -> alert=1 (surfaces the current drift).
--
--   Components deployed together:
--     1. app/tasks/sber_freshness_monitor.py — check_sber_freshness() + evaluate_sber_freshness()
--     2. app/services/product_handlers.py — kit Handler 'sber_freshness_monitor'
--     3. This migration — seeds the scrape_schedules row (enabled=true, daily window)
--
-- Schedule window 09:00-10:00 UTC:
--   Daily cadence, placed AFTER deals_freshness_monitor (08:00-09:00 UTC) so the two
--   data-freshness monitors do not overlap. Cheap: one SELECT max(period_month), no external
--   HTTP — safe to run daily even though sber_index_pull itself is monthly.
--
-- default_params.lag_allowance_days = 25:
--   Allowance for СберИндекс publication lag on top of the 35d per-estimate guard (-> 60d).
--
-- next_run_at bootstrapped to tomorrow 09:00 UTC — scheduler will not fire immediately
-- on deploy (same pattern as 162/093/096/160).
--
-- Idempotent: ON CONFLICT (source) DO NOTHING — safe to re-apply.
--
-- Dependencies:
--   052_scrape_schedules.sql (table + UNIQUE(source))
--   sber_price_index table (populated by app.tasks.sber_index_pull)
--   app/services/product_handlers.py + tasks/sber_freshness_monitor.py deployed
--
-- Deploy order:
--   Apply after deploying the product_handlers.py + task changes so the dispatch can resolve
--   'sber_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
(
    'sber_freshness_monitor',
    true,                                        -- SAFE: single SELECT max(period_month), no ext calls
    9,                                           -- window 09:00-10:00 UTC (after deals_freshness_monitor)
    10,
    ((CURRENT_DATE + INTERVAL '1 day') + make_interval(hours => 9)) AT TIME ZONE 'UTC',
    '{"lag_allowance_days": 25}'::jsonb          -- publication-lag allowance over the 35d per-estimate guard
)
ON CONFLICT (source) DO NOTHING;

COMMIT;
