-- Sprint 7 — One-time data fix: retarget Friday-keyed plan(s) to the
-- equivalent upcoming Monday.
--
-- Background: pre-Sprint 7, the orchestrator's `_current_week_start()`
-- returned the most recent Friday. The Friday email was sent for that
-- date, and the plan was keyed by it. Sprint 7 changes the convention
-- to "upcoming Monday" (Mon-Sun week). Existing plans keyed by a
-- Friday are migrated to the equivalent upcoming Monday so:
--
--   1. The user's just-voted-on plan (3 pending items, week of
--      2026-06-05) lives under the same date the new code will use.
--   2. The webui default (upcoming Monday) and the plan key line up.
--
-- This script is idempotent: re-running it is a no-op once 2026-06-05
-- has no rows. The transaction wraps both the count and the UPDATE so
-- a partial run can't leave the table in an inconsistent state.
--
-- Run on the deployment host (db is in a container, no host psql):
--
--   docker compose exec -T db psql -U mealplanner -d mealplanner \
--     -f /dev/stdin < backend/scripts/fix_2026_06_05_to_2026_06_08.sql
--
-- Expected output:
--
--   rows_to_migrate
--   ----------------
--                 1
--   UPDATE 1
--   id                                  | week_start_date
--   ------------------------------------+-----------------
--   <uuid-for-2026-05-15-plan>           | 2026-05-11
--   <uuid-for-2026-05-22-plan>           | 2026-05-18
--   <uuid-for-2026-05-29-plan>           | 2026-05-25
--   <uuid-for-2026-06-05-plan-NOW-2026-06-08> | 2026-06-08
--
--   COMMIT

BEGIN;

-- (1) How many rows will be migrated?  A count of 1 is the expected
-- outcome for the 2026-06-05 plan.  Zero is also safe (nothing to do).
SELECT COUNT(*) AS rows_to_migrate
  FROM meal_plan
 WHERE week_start_date = DATE '2026-06-05';

-- (2) The actual migration.  Single-row target; safe under concurrent
-- readers (the row stays visible under the default REPEATABLE READ).
UPDATE meal_plan
   SET week_start_date = DATE '2026-06-08'
 WHERE week_start_date = DATE '2026-06-05';

-- (3) Verify.  Lists all plans ordered by week, so the operator can
-- eyeball that the migration took effect and that the date keys are
-- all Mondays (or Fridays, if a pre-2026-05-15 plan was missed).
SELECT id, week_start_date
  FROM meal_plan
 ORDER BY week_start_date;

COMMIT;

-- ---------------------------------------------------------------------
-- Optional: also migrate the 2026-05-29 plan (and any other Friday-keyed
-- plan) to the equivalent Monday.  The 2026-05-29 plan contains 3
-- approved items the family has already acted on; migrating it is
-- cosmetic (the plan keeps the same items, just under a Monday key so
-- the webui's "current calendar week" view -- if anyone navigates to
-- it -- agrees with the calendar).  Comment out the block below if
-- you do NOT want to migrate older plans.
--
-- BEGIN;
-- SELECT COUNT(*) AS rows_to_migrate_0529
--   FROM meal_plan
--  WHERE week_start_date = DATE '2026-05-29';
-- UPDATE meal_plan
--    SET week_start_date = DATE '2026-06-01'
--  WHERE week_start_date = DATE '2026-05-29';
-- COMMIT;
