# Оновлення інстансу Podorozhnyk до 5.5.6

Короткий операційний огляд для узгодження вікна робіт і відповідальності. Повний технічний план (англійською), покрокові деплої, міграції та прапорці — у репозиторії:

`docs/developer/release/5.5.6/release-packs/podorozhnyk.md`

## Що оновлюємо

| Параметр | Значення |
|----------|-----------|
| Інстанс | podorozhnyk |
| Поточний Engine (kwinst) | `release_5.1.0+hotrevert` (5.1.0), кастомна лінія |
| Ціль | **5.5.6** (`release_5.5.6`) |
| Constructor у kwinst | порожнє значення — потрібна звірка з фактичним деплоєм |

## Шлях оновлення (контрольні точки)

Послідовність релізів без пропуску обов’язкових зупинок:

`5.1.0` → `5.2.2` → `5.2.7` → `5.3.1` → `5.3.5` → `5.3.11` → `5.5.6`

Критичні вікна:

- **5.2.2** — FULLTEXT на великих БД: плануйте **1–6+ годин** можливого простою/блокування під індексацію.
- **5.3.1** — великий чекпоінт (тикети, syncdb, пост-міграції) — **15–45 хв** плюс ручні скрипти після syncdb (див. повний пакет).
- **5.3.5** — обов’язкова зупинка перед 5.3.11 (не стрибати напряму на 5.3.11).

Деталі команд `docker exec`, міграцій, сидів і feature flags — у файлі Release Pack за посиланням вище.

## Ризики та узгодження

- Великий стрибок версій (5.1.x → 5.5.x), кастомний engine (`+hotrevert`): потрібна **перевірка, що всі хотфікси з кастомної гілки враховані** у фінальному коді 5.5.6.
- У повному пакеті зазначено **High** risk score; перед продакшеном — бекап БД, прогін шляху на staging з копією даних за можливості.
- Розділ «Business Impact» у технічному пакеті порожній (немає `client_flow` для автозаповнення) — бізнес-перевірки списком узгодити з власниками ботів.

## Наступні кроки

1. Затвердити вікно простою з урахуванням FULLTEXT на 5.2.2 та 5.3.1.
2. Інженерна звірка кастомної гілки та Constructor.
3. Виконати покроковий деплой згідно `podorozhnyk.md`, потім tech + business verification з того ж документа.

_Generated: 2026-05-06_