# Итог: уникальность IP-адреса в VRF (изменение 011)

## Что сделано
- **Миграция `0007`:** `prefixes` — уникальность `(id, vrf_id)`; `addresses.vrf_id` (заполнен из префиксов), составной FK `(prefix_id, vrf_id)` → `prefixes` (`ON DELETE CASCADE`, `ON UPDATE CASCADE` — при переносе префикса в другой VRF адреса следуют автоматически), уникальность `(vrf_id, address)`.
  Перед изменениями миграция ищет дубли и **останавливается** с перечнем; найденные ранее в родителе адреса, попадающие в дочерний префикс, переносятся в самый узкий префикс. `scripts/find_duplicate_addresses.py` — поиск дублей (только чтение).
- **API (`prefixes.py`):** `create_address` — адрес из диапазона вложенного префикса → 422 «назначьте его там»; дубль в VRF → 409; `rehome_addresses()` — создание префикса, `allocate_subnet` и перенос VRF забирают адреса родителя из своего диапазона (число — `moved_addresses` в журнале);
  перенос префикса в VRF с тем же адресом → 409 с перечнем (без частичных изменений).
- `app/models.py`: `Address.vrf_id`, ограничения; `README.md`: раздел «Модель данных».

## Проверка
Проверка: стенд `ipam_control_006` пересобран, миграции применены до 0008 (`alembic check` — расхождений нет); ручная проверка (скрипт во временной папке, в репозиторий не добавлялся); автотесты по условию этапа не писались. .5 в родителе → 201; создание дочернего /25 переносит .5; повторный .5 в родителе → 422, в дочернем → 409; перенос префикса в VRF с тем же адресом → 409; миграция на стенде (без дублей) прошла.
Не проверено: остановка миграции на реальном дубле, перенос префикса без конфликта (rehome при смене VRF).

## Риски
Изменение модели данных. Перед применением на рабочей БД — запустить `scripts/find_duplicate_addresses.py` и сделать резервную копию.