The seed rename in 3d19b18 changed the repository. It could not change a
database that already exists: 001_schema.sql is CREATE TABLE IF NOT
EXISTS, so it will not add ci_station, ci_point or poll_group to a live
historian_items, and deploy.sh only ever upserts - nothing deletes. A
plain reload would have failed on the missing columns, and had it not, it
would have left 45 retired keys beside their 45 replacements with two
foreign keys still pointing at the old ones.
The migration adds the columns, carries scada_point across into ci_point,
drops it, then re-keys: it captures the old-to-new mapping BEFORE touching
anything, inserts a replacement tags row per retired key, repoints
alarm_bits and historian_items, checks nothing still references a retired
key, and only then deletes.
The mapping is captured first because historian_items.tag_id is itself
about to change - reading the mapping through it afterwards finds nothing,
which would have left alarm_bits pointing at deleted rows. A silently
unmapped alarm bit is how an alarm count becomes wrong, so there is an
explicit check that every alarm_bits key has somewhere to go, and the
migration stops before touching anything if one does not.
Applied to lin001 2026-09-01 after a pg_dump of the three tables to
~/ai/backups/ and a dry run inside a rolled-back transaction. Result: 45
retired keys mapped, 6 alarm_bits rows repointed, 45 tags rows deleted,
65 tags before and after, ci_point populated on all 49 items.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
6a64c64588