-- 029_plan_generation_relative_seq.up.sql
-- Make plan-step seq generation-relative: 1..N within each
-- (session_id, generation). Before this, seq was globally increasing across
-- generations (gen1: 1..6, gen2: 7..12), so the model's 1-based
-- update_plan_step calls — which the prompt and schema explicitly tell it to
-- use — landed on superseded gen-1 rows after a re-plan while the live gen-2
-- work went unrecorded (or, worse, resurrected a `replaced` row as `done`).
-- The addressing key is now (session_id, generation, seq); updatePlanStep
-- resolves against MAX(generation), so a 1-based seq always maps to the
-- CURRENT plan. See plans/2026-07-30-session-review-plan-drift-and-dead-
-- activity-panel.md P0.1.

-- Renumber existing rows so seq resets to 1..N per (session, generation),
-- preserving each generation's step order.
WITH ranked AS (
  SELECT id,
         ROW_NUMBER() OVER (
           PARTITION BY session_id, generation
           ORDER BY seq, created_at
         ) AS new_seq
  FROM session_plan_steps
)
UPDATE session_plan_steps s
SET seq = ranked.new_seq
FROM ranked
WHERE s.id = ranked.id AND s.seq <> ranked.new_seq;

-- (session_id, seq) is no longer unique once seq resets per generation; the
-- store resolves via (session_id, generation, seq). Drop the old composite
-- index (it now collides on seq) and add the generation-scoped unique index.
DROP INDEX IF EXISTS idx_plan_steps_session;
CREATE UNIQUE INDEX IF NOT EXISTS idx_plan_steps_session_gen_seq
  ON session_plan_steps (session_id, generation, seq);