av
f8200f7f80
- секции `workouts` и `stateOfMind` покрыты разбором: тренировка лежит одной строкой вместе с маршрутом и внутренними рядами, запись — по ключу `род + id`; миграция 00007 заводит обе таблицы и возвращает в очередь `partial`-доставки с этими ключами - сущность заменяется целиком, но условно: приехавшая побеждает, если не теряет содержания сохранённой (множество ключей и длины верхнеуровневых массивов), а при равном содержании выигрывает версия из более поздней доставки ЖУРНАЛА — «побеждает приехавшая» было бы функцией порядка свёртки, и живая витрина расходилась бы с пересборкой молча - отпечаток витрины покрывает тренировки и записи и снимается одним снимком базы; отчёт `reindex` считает «было и стало» по каждой единице хранения
46 lines
3.5 KiB
Markdown
46 lines
3.5 KiB
Markdown
# Проверка секций, которых поток ещё не приносил
|
|
|
|
**Приоритет:** средний
|
|
|
|
Разбор пишется по тем данным, что видел поток, а он приносил только `metrics`,
|
|
`workouts` и `stateOfMind`. Не виденны живьём: `symptoms`, `ecg`,
|
|
`heartRateNotifications`, `cycleTracking`, `medications`, а также вес — а вес
|
|
агенту-медику нужен наверняка.
|
|
|
|
Пользователь настраивает оставшиеся метрики на телефоне, так что данные
|
|
появятся сами. Задача — не пропустить момент: убедиться, что новые секции
|
|
разбираются, а не молча падают в `parse_status`.
|
|
|
|
Часть вопроса закрыта разбором экспортов (находка 42): в Health эти данные
|
|
**есть** и в экспорте они присутствуют — `BodyMass` (1127 записей),
|
|
`BloodPressureSystolic`/`Diastolic` (по 18), `BodyTemperature` (11), `Headache`
|
|
(36), `SexualActivity` (46), `Dietary*` (по 88). Значит вопрос не «есть ли
|
|
данные», а «доедут ли они через HAE и в какой форме».
|
|
|
|
Остаётся непроверенным `stateOfMind`: в экспорте его нет ни одним типом. Если
|
|
подтвердится, что Apple его не выгружает, то экспорт ему не источник истины —
|
|
устаревание нижнего слоя к нему неприменимо, держим всегда.
|
|
|
|
Давление приезжает обёрткой `Correlation` из двух записей (находка 44) — в
|
|
экспорте точно, а вот как его отдаёт HAE, неизвестно. Это первое, на что
|
|
смотреть, когда данные появятся.
|
|
|
|
Готово, когда каждая новая секция либо разобрана, либо явно описана в
|
|
`docs/local-research.md` как не пришедшая, и ни одна не числится в ошибках
|
|
разбора.
|
|
|
|
## Что уже сделано
|
|
|
|
Разбор перечисляет непокрытые секции и пишет их в `delivery.uncovered_sections`
|
|
(change `2026-08-01-nerazobrannye-sekcii-dostavki`). Момент, когда поток принесёт
|
|
секцию, которой раньше не было, теперь **фиксируется** — остаётся научиться
|
|
замечать его активно: один `SELECT DISTINCT` по колонке даёт список всего, что
|
|
поток приносил, и сравнение с известным набором закрывает задачу.
|
|
|
|
Модель под секции с собственным `id` заложена (change
|
|
`2026-08-02-trenirovki-i-zapisi`): таблица `record` ключуется парой
|
|
`род + id`, и новая секция добавляется **одной строкой** в множество покрытых
|
|
имён разбора, а не миграцией. Покрыты `workouts` и `stateOfMind`; остались
|
|
`ecg`, `symptoms`, `cycleTracking`, `medications`, `heartRateNotifications` —
|
|
их формы никто не видел, и разбор вслепую сознательно не писался.
|