хранилище описано как свёртка по журналу событий

- экспорт Apple это снапшот всей истории, доставки после его даты — события
  поверх; состояние пересобирается как import(экспорт) + replay(доставки)
- отсюда ретеншен архива меняется с произвольных 14 дней на «до следующего
  проверенного экспорта» (~2 ГБ за квартал, измерено), а свёртка обязана быть
  детерминированной — воспроизведение строго по received_at
- названы границы модели: stateOfMind в экспорт не попадает вовсе, а верхние
  слои за периоды с удалёнными доставками не воскресают и досчитываться не
  должны — каталог обязан говорить это честно
This commit is contained in:
av
2026-08-01 14:27:13 +03:00
parent 7ee55057e0
commit b2885c79e3
10 changed files with 162 additions and 46 deletions
+16 -4
View File
@@ -3,14 +3,26 @@
**Приоритет:** высокий
Разбор пишется по реальным данным и будет ошибаться — это норма, а не риск.
Риск в другом: сырой архив живёт 14 дней, и окно на исправление ошибки равно
этому сроку. Без `reindex` ошибка разбора становится потерей данных.
Риск в другом: без пересборки ошибка разбора становится потерей данных —
исправленный код не применится к тому, что уже разобрано неверно.
Пересчёт по всей истории сразу ещё и **точнее** приёма: вывод слоя и род
агрегации на полном ряду доставок надёжнее, чем на одной.
Готово, когда `healthlog reindex` пересобирает хранилище с нуля из `data/raw`
и результат совпадает с накопленным приёмом.
Проектировать это надо сразу как **свёртку по журналу**, а не как разовую
утилиту: состояние есть `import(снапшот экспорта) + replay(доставки после его
даты)`, и пересборка из архива — вырожденный случай с пустым снапшотом. Тогда
`reindex` и `import` окажутся одной операцией с разным входом, а не двумя
похожими.
Отсюда требование, которое легко упустить: **свёртка обязана быть
детерминированной.** Проигрывание должно давать то же состояние, что приём в
реальном времени. Слияние «выигрывает более полная точка» коммутативно, но две
одинаково полные точки с разными значениями разрешает порядок — значит
воспроизведение идёт строго по `received_at`, а не по порядку файлов в каталоге.
Готово, когда пересборка с нуля даёт состояние, совпадающее с накопленным
приёмом, и повторный прогон ничего не меняет.
Связано: план шаг 3, `docs/architecture.md` → «Сырой архив».