av
3df42afeca
- открытых вопросов не осталось: три решения владельца доведены до берущегося вида, по entity-without-parsed-label принято хранить с NULL-меткой после Read API - unseen-sections-check сжата до остатка — активная проверка появления секции; разбор невиденных секций из неё вынут, вслепую он не пишется - спринт под целью parsing-and-storage: categorical-value-dictionary и unseen-sections-check, обеим написаны критерии приёмки с оракулами
69 lines
5.1 KiB
Markdown
69 lines
5.1 KiB
Markdown
# Активная проверка: поток принёс секцию, которой раньше не было
|
||
|
||
- **Секция:** ядро
|
||
- **Зачем:** Момент появления новой секции фиксируется в базе, но заметить его может только тот, кто догадается заглянуть в колонку
|
||
- **Теги:** goal:parsing-and-storage
|
||
|
||
Разбор пишется по тем данным, что видел поток, а он приносил только `metrics`,
|
||
`workouts` и `stateOfMind`. Не виденны живьём: `symptoms`, `ecg`,
|
||
`heartRateNotifications`, `cycleTracking`, `medications`, а также вес — а вес
|
||
агенту-медику нужен наверняка.
|
||
|
||
Пользователь настраивает оставшиеся метрики на телефоне, так что данные
|
||
появятся сами. **Задача — не пропустить момент.** Разбор самих секций сюда не
|
||
входит и входить не может: их формы никто не видел, и вслепую разбор
|
||
сознательно не пишется. Каждая приехавшая секция станет отдельной задачей —
|
||
тогда, когда её будет на чём проверить.
|
||
|
||
## Что уже сделано
|
||
|
||
Разбор перечисляет непокрытые секции и пишет их в `delivery.uncovered_sections`
|
||
(change `2026-08-01-nerazobrannye-sekcii-dostavki`). Событие **фиксируется** —
|
||
но ничем не наблюдается: узнать о нём можно только запросом в базу руками.
|
||
|
||
Модель под секции с собственным `id` заложена (change
|
||
`2026-08-02-trenirovki-i-zapisi`): таблица `record` ключуется парой
|
||
`род + id`, и новая секция добавляется **одной строкой** в множество покрытых
|
||
имён разбора, а не миграцией.
|
||
|
||
## Что известно про сами секции
|
||
|
||
Часть вопроса закрыта разбором экспортов (находка 42): в Health эти данные
|
||
**есть** и в экспорте присутствуют — `BodyMass` (1127 записей),
|
||
`BloodPressureSystolic`/`Diastolic` (по 18), `BodyTemperature` (11), `Headache`
|
||
(36), `SexualActivity` (46), `Dietary*` (по 88). Значит вопрос не «есть ли
|
||
данные», а «доедут ли они через HAE и в какой форме».
|
||
|
||
Остаётся непроверенным `stateOfMind`: в экспорте его нет ни одним типом. Если
|
||
подтвердится, что Apple его не выгружает, то экспорт ему не источник истины —
|
||
устаревание нижнего слоя к нему неприменимо, держим всегда.
|
||
|
||
Давление приезжает обёрткой `Correlation` из двух записей (находка 44) — в
|
||
экспорте точно, а вот как его отдаёт HAE, неизвестно. Это первое, на что
|
||
смотреть, когда данные появятся.
|
||
|
||
## Критерии приёмки
|
||
|
||
- имя секции, которого разбор раньше не встречал, порождает событие уровня выше
|
||
рутины — оракул: тест на доставке с выдуманной секцией, в логе ровно одна
|
||
строка с этим именем
|
||
- то же имя во второй доставке события больше не порождает — оракул: тот же
|
||
тест на двух доставках подряд, вторая молчит
|
||
- список всего, что поток когда-либо приносил и разбор не покрыл, достаётся
|
||
одной командой, без ручного SQL — оракул: прогон команды на живой базе,
|
||
вывод сходится с `SELECT DISTINCT` по `delivery.uncovered_sections`
|
||
- перечень не виденных живьём секций в `docs/research/apple-health.md` сходится
|
||
с множеством покрытых имён в `internal/hae` — оракул: глазами, сверка двух
|
||
списков поимённо
|
||
- повторный прогон живого архива даёт то же состояние — оракул:
|
||
`task verify:archive`
|
||
|
||
## Рамки
|
||
|
||
Схема не трогается: колонка `uncovered_sections` уже есть. Разбор новых секций
|
||
не пишется. Данные только читаются; перезапуск сервиса допустим.
|
||
|
||
Связано: `docs/architecture.md` → «Неразобранные секции доставки», находки 42,
|
||
44; идея [monthly-manual-sections-pass](monthly-manual-sections-pass.md) ждёт
|
||
тех же данных.
|