-- 数据回填 —— 把排序键 priority_score 从「0-100 整数」还原成与展示同精度的「0-100 一位小数」
--
-- 【症状】召回池按优先级降序排,客服看到的却是「3.12 → 3.12 → 3.10 → 3.10 → 3.10 → 3.12 → …」,
--   像根本没排序。2026-07-29 用户截图报的。
--
-- 【根因】排序键 followup_plans.priority_score 由 priority-scorer 写入,当时是
--     score = Math.round(raw * 10)          → 0-100 的**整数**
--   而列表展示的是 breakdown.priority.raw 的**两位小数**(0-10)。
--   排序精度比展示精度粗 10 倍 → 同一个整数档里塞着一堆不同的展示分,档内只能按
--   created_at 兜底排,于是看起来乱序。
--   测试服实测:priority_score=31 一档里有 21 种展示分(3.20~2.59);
--   全池 126,073 张工单只有 93 个排序档位,却有 849 种展示分。
--
-- 【代码侧已修】priority-scorer 改为 score = round(raw,2) * 10 —— 与展示 1:1。
--   列本来就是 Float(schema 未变),量纲仍是 0-100(queueStats 的 70/40 分档、
--   前端进度条 score/100 都不受影响)。
--
-- 【为什么还要这条回填】存量行的 score 仍是旧整数。plan-engine 的 unchanged 分支确实会
--   就地改 priorityScore(`if (latest.priorityScore !== newPriorityScore) patch...`),
--   所以下一轮全量重算(每 2 小时)能自愈 —— 但在那之前,页面上所有分都会显得"变整"
--   (如 2.74 → 2.70),看着像精度倒退。这条把它一次性补齐,消除过渡期。
--
-- 【口径】breakdown.priority.raw 就是当初算出来的两位小数原值,乘 10 即得新排序键。
--   用 numeric 运算(不是 float)避免 3.12*10=31.200000000000003 这种噪声。
--   没有 raw 的老行(早期 reason 没落 breakdown)保持原值不动,等重算自然覆盖。
--
-- 【幂等】WHERE 带「值确实不同」判断,重复执行为空跑。
-- 【代价】生产 ~206k plan / ~25 万 reason,两条 UPDATE,秒级。

-- 1) reason 级:排序键 = breakdown.priority.raw × 10
UPDATE "plan_reasons" r
SET "priority_score" = round((r."breakdown" -> 'priority' ->> 'raw')::numeric * 10, 1)::double precision
WHERE r."breakdown" -> 'priority' ->> 'raw' IS NOT NULL
  AND r."priority_score"
      IS DISTINCT FROM round((r."breakdown" -> 'priority' ->> 'raw')::numeric * 10, 1)::double precision;

-- 2) plan 级:= MAX over 它的 reason(与 plan-engine 的 newPriorityScore 同口径)
UPDATE "followup_plans" p
SET "priority_score" = m."mx"
FROM (SELECT "plan_id", MAX("priority_score") AS "mx" FROM "plan_reasons" GROUP BY "plan_id") m
WHERE m."plan_id" = p."id"
  AND p."priority_score" IS DISTINCT FROM m."mx";
