# Пересборка хранилища из сырого архива

**Приоритет:** высокий

Разбор пишется по реальным данным и будет ошибаться — это норма, а не риск.
Риск в другом: без пересборки ошибка разбора становится потерей данных —
исправленный код не применится к тому, что уже разобрано неверно.

Пересчёт по всей истории сразу ещё и **точнее** приёма: вывод слоя и род
агрегации на полном ряду доставок надёжнее, чем на одной.

Проектировать это надо сразу как **свёртку по журналу**, а не как разовую
утилиту: состояние есть `import(снапшот экспорта) + replay(доставки после его
даты)`, и пересборка из архива — вырожденный случай с пустым снапшотом. Тогда
`reindex` и `import` окажутся одной операцией с разным входом, а не двумя
похожими.

Отсюда требование, которое легко упустить: **свёртка обязана быть
детерминированной.** Проигрывание должно давать то же состояние, что приём в
реальном времени. Слияние «выигрывает более полная точка» коммутативно, но две
одинаково полные точки с разными значениями разрешает порядок — значит
воспроизведение идёт строго по `received_at`, а не по порядку файлов в каталоге.

Готово, когда пересборка с нуля даёт состояние, совпадающее с накопленным
приёмом, и повторный прогон ничего не меняет.

Связано: план → шаг «Разбор и хранилище», `docs/architecture.md` → «Сырой архив».