Date-Shift Runbook — how to move the launch / calendar without breaking anything

The whole calendar derives from two knobs and one rule. Shifting dates correctly is a 4-step

procedure that ends in a gate. This exists because the 2026-07-05 re-anchor broke ~6 places that had

hardcoded an absolute week instead of deriving it — those are now fixed + guarded.

The single source of truth

brands/temerarii-media/content/_context/GOAL.yaml
year.anchor — the Sun of fiscal 2026-W01 (FIXED). Every date = anchor + (week-1)*7.
schedule.campaigns[].start_week — RELATIVE placement. The earliest one = the launch week.
scope.produced_weeks — the produced window.
brands/temerarii-media/remotion/src/storyboard-registry.json — the 30 hero cells carry props.week

+ the W##-<campaign>-beat-N id. This is the actual week source content_index.py reads.

To shift the whole arc forward by N weeks

Registry — bump each cell's props.week +N and the W##- id prefix +N

(storyboard-registry.json). (This is the real week source — GOAL alone does NOT move the index.)

GOAL.yaml — bump every campaign.start_week +N, produced_weeks +N, the go-live comment.
Overlay — re-key authored-scripts.json +N on the week token of every non-holiday- key

(sed-style: W(\d+) → W(\d+ + N)). Holiday ids are real-date-anchored — leave them.

Regen + gate:

   python -m engine.lib.content_index          # rebuilds the index at the new weeks
   python -m engine.gates.verify_calendar_alignment   # MUST print CALENDAR-ALIGN PASS
   rm -rf apps/office/public/{storyboard,media,day,channels} && python apps/office/build_office.py

What now DERIVES automatically (no longer hardcoded — these used to break)

Thing	Derives from	File
Self-proof receipts	campaign-beat key (not week)	`content_index.py:SELF_PROOF_BY_CELL`
Social angle rotation baseline	min campaign `start_week`	`social_calendar._LAUNCH`
Holiday lane (drops pre-launch)	min produced cell week	`content_index.py` holiday lane
`/media` week window	`--weeks` default tracks produced range	`render_media.py`
All dates	`anchor + (week-1)*7`	`content_index._date_for`

Real-world-dated things DO NOT shift (they are not relative)

Holidays (_holidays.yaml): real dates. Pre-launch ones are dropped from production (a holiday

can't be "shifted" into the window). Post-launch ones stay on their true date.

gtm.yaml promos tied to real triggers (Delete Act Aug 1, BFCM Nov, Christmas Dec): keep the date,

re-point the calendar_tie week to whatever campaign now covers it.

The guardrail: `verify_calendar_alignment` (in the gate suite)

Fails the build if: launch week disagrees between GOAL and the index · the social baseline isn't re-based ·

any produced asset sits pre-launch · the launch date isn't anchor-derived · a self-proof key is hardcoded

to a week or orphaned. If you shift dates and forget a step, this gate catches it. Run it after any

calendar change.

Why the office can show stale pages after a shift (and the fix)

build_office writes pages but does NOT delete old ones. After a week renumber, prune the content-keyed

trees first: rm -rf apps/office/public/{storyboard,media,day,channels} then rebuild. (The dead old-week

URLs are never published — the office is gated + pre-launch — so no redirects are needed.)