# Закрытие записи

В Ordinis нет «удалить» в привычном смысле — данные не пропадают. Вместо
этого запись **закрывается**: ей выставляется `valid_to = текущий момент`,
после чего она перестаёт считаться актуальной, но история остаётся.

## Зачем так

Bitemporal модель — два временных измерения:
- **valid_from / valid_to** — когда запись актуальна в реальном мире
- **created_at / updated_at** — когда запись была введена в систему

Это позволяет:
- Восстанавливать что было «на дату» (например, состав группировки
  спутников на 2024-12-31)
- Видеть, кто и когда вносил изменения
- Не ломать downstream-системы, которые могут читать архивные данные

## Когда закрывать запись

- Спутник **выведен из эксплуатации**
- Наземная станция **демонтирована**
- Контракт **истёк**
- Тип записи **переименован** (закрыть старую, открыть новую с новым кодом)
- Дубликат **обнаружен** (оставить одну, закрыть остальные)

## Как закрыть

1. Открой запись в drawer'е
2. Кнопка **«Удалить»** в footer'е (она же — «закрыть»)
3. Опционально укажи `valid_to` — момент закрытия. По умолчанию: сейчас.
4. Подтверди

После этого:
- В UI запись по умолчанию **не отображается** (фильтр «только активные»)
- В API при `GET /records?at=YYYY-MM-DD` — отображается только если
  на эту дату была активна
- История доступна через `GET /records/{id}/history`

## Как восстановить

Если запись закрыта ошибочно — открой панель **«История версий»** в
drawer'е, найди последнюю активную версию **до закрытия**, нажми
**«Восстановить как новую запись»**. Это создаст новую активную версию
с тем же бизнес-ключом, что и закрытая.

Альтернатива: создать запись с тем же бизнес-ключом заново — система
проверит, что нет пересекающихся периодов действия.

## Bulk-закрытие при cascade

Если запись X **используется** в других справочниках (через `x-references`),
система проверит ссылки:
- Если есть активные записи, ссылающиеся на X — будет предупреждение
- Можно: (а) сначала закрыть/обновить зависимые записи, (б) принять
  риск orphan'ов (downstream consumers получат FK-misses)

См. [Cross-references (FK)](../integration/api/x-references.md) о том,
как зависимости валидируются на уровне API.

## Закрытие vs полное удаление

**Полное удаление записи (DELETE из БД) не поддерживается** через UI и
обычный API. Это намеренно — целостность истории важнее «чистоты».

Если ОЧЕНЬ нужно (например, по GDPR / по приказу) — администратор
выполняет это через специальную процедуру с подтверждением. Свяжись с
ответственным за систему.

## Что произойдёт при закрытии

- В БД у записи обновляется `valid_to`
- В Kafka-топик публикуется событие `RecordClosed` с указанием
  `valid_to` и причины (если задана)
- В audit log пишется операция `CLOSE` с привязкой к оператору
- Downstream consumers (Альтум, BI) видят новую версию состояния
  справочника на следующем чтении (или сразу через событие)

## Чек-лист перед закрытием

- [ ] Я уверен, что закрываю правильную запись (бизнес-ключ совпадает)
- [ ] Если у записи есть зависимости через FK — я их проверил
- [ ] `valid_to` соответствует реальному моменту вывода из эксплуатации
      (не «сейчас» по умолчанию, если эксплуатация закончилась в прошлом)
- [ ] Я понимаю: история останется, downstream-консьюмеры узнают