av
3d24248075
- каждая запись каталога задач получила тип вместо тега kind: и префикса заголовка; секция роадмапа «Разработка» стала «Сопровождением», порядок секций канонический - поправлены протухшие факты: нереализованные маршруты Read API, MCP и `healthlog import`, словарь слоёв в инварианте, семантика гейта по покрытию диффа, периметр перестал дублировать security.md - замер слияния переведён с находки 49 на находку 54, заполнены Purpose спек storage и parsing
60 lines
4.9 KiB
Markdown
60 lines
4.9 KiB
Markdown
# ✨ Помечать нижний слой устаревшим после экспорта
|
||
|
||
- **Тип:** feature
|
||
- **Категория:** Ядро
|
||
- **Зачем:** Нижний слой растёт на ~100 тысяч координат в сутки, а после экспорта Apple он избыточен
|
||
- **Теги:** goal:lower-layer-cleanup
|
||
|
||
Нижний слой растёт примерно на 100 тысяч координат в сутки против ~3 700 у
|
||
минутного и ~100 у часового — разница в три порядка (находка 41). Всё давление
|
||
по объёму создаёт он один, и ровно там родной экспорт Apple оказывается
|
||
настоящим надмножеством.
|
||
|
||
Два ограничителя, без которых правило опасно:
|
||
|
||
- пометка вешается по **загруженному и проверенному** экспорту, а не по
|
||
сделанному: проверка — непрерывность по дням и сходимость сумм с часовым
|
||
слоем;
|
||
- пометка ≠ удаление. Удаление включается только после того, как восстановление
|
||
из экспорта отработает на живых данных хотя бы раз.
|
||
|
||
Двигает строку «Завершения» цели: «Нижний слой помечен покрытым после проверенного экспорта».
|
||
|
||
## Чем помечать: разряд на диапазон, а не провенанс на точку
|
||
|
||
Решено при постановке 2026-08-04. Пометка — **одна строка на диапазон**:
|
||
`метрика + слой + период + «покрыто проверенным экспортом»`. Не поле у точки.
|
||
|
||
Основание — соотношение цены и потребности:
|
||
|
||
- **вопрос, на который надо ответить, диапазонный**: «за этот период нижний
|
||
слой обеспечен настоящими сэмплами Apple, посекундную развёртку HAE можно
|
||
выбросить». Он не требует знать, из какой доставки приехало конкретное число;
|
||
- **цена совпадает с самой проблемой**: нижний слой растёт на ~100 тысяч
|
||
координат в сутки, и поле у точки платит тем же объёмом, который задача и
|
||
пришла экономить. Пометка на диапазон — десятки строк.
|
||
|
||
**Провенанс на точку рассмотрен и отвергнут по цене, а не по ненадобности.**
|
||
Различать эти два основания важно: отказ по ненадобности закрывает вопрос
|
||
навсегда, отказ по цене — только до появления потребителя. Появится тот, кому
|
||
нужно «покажи, из какой конкретно доставки это число», — решение
|
||
пересматривается. Сегодня такого потребителя нет: ни агент-медик, ни трекер, ни
|
||
игра его не просят ([passport.md](../../passport.md)).
|
||
|
||
Отдельно стоит помнить, что **отделить старое от нового можно и без пометок**:
|
||
состояние по определению есть `import(экспорт) + replay(доставок по
|
||
received_at)`, порядок известен, происхождение значения выводится пересборкой.
|
||
Пометка нужна ровно затем, чтобы отвечать на этот вопрос **при чтении**, не
|
||
пересчитывая.
|
||
|
||
Смежное: у сущностей (`workouts`, `stateOfMind`) провенанс уже есть — колонки
|
||
`delivery_id` и `delivery_received_at` (миграция `00007`). У часового объекта
|
||
метрики есть `first_delivery_id` (миграция `00003`), но это **первая** доставка,
|
||
а не источник каждой точки, и для этой задачи он не годится.
|
||
|
||
Приоритет низкий: пока история измеряется днями, экономить нечего. Задача
|
||
станет актуальной, когда нижний слой перевалит за несколько гигабайт.
|
||
|
||
Зависит от импорта экспорта Apple — до него помечать нечем; выставляет пометку
|
||
[apple-export-import](apple-export-import.md).
|