Міграції даних і конфігурації

Data і configuration мають окремий migration contract

Data migration змінює records, schema або format; configuration migration змінює спосіб, яким код отримує settings, flags, credentials references чи defaults. Вони можуть бути повʼязані, але не повинні зливатися в один рядок plan: data має integrity і recovery concerns, config — startup, scope та secret-handling concerns.

Для кожної зміни потрібні source/target representation, compatibility window, owner, sequencing, validation та backout або forward-fix strategy. Якщо операція irreversible, це blocking decision, а не дрібна примітка.

Inventory і sequencing

Compatibility patterns і їхні межі

• expand-contract дає coexistence window, але потребує retirement criteria;
• dual-read/dual-write додає reconciliation та idempotency risk;
• backfill має бути resumable, observable і обмеженим за blast radius;
• versioned configuration повинна мати explicit default і безпечний unknown-key behavior;
• секрети не копіюються в task spec, logs, templates або evidence;
• forward-fix може бути безпечнішим за backout для state, який не можна повернути.

Перевірка до і після перемикання

1. Зіставте data/config inventory з dependency graph і affected behavior flows.
2. Визначте compatibility window, допустиму coexistence і точку припинення.
3. Підготуйте validation для counts, invariants, reads, writes, startup і representative scenarios.
4. Виконайте pilot лише за наявності owner та recovery path; недоступні checks позначте Unknown.
5. Після switch порівняйте behavior, integrity і operational signals; не видаляйте source path до exit criteria.
6. Зафіксуйте GO, HOLD, rollback або forward-fix як окреме рішення з evidence.