Files

T

tasks: разобраны вопросы и набран спринт 2026-08-03

- открытых вопросов не осталось: три решения владельца доведены до берущегося
  вида, по entity-without-parsed-label принято хранить с NULL-меткой после Read API
- unseen-sections-check сжата до остатка — активная проверка появления секции;
  разбор невиденных секций из неё вынут, вслепую он не пишется
- спринт под целью parsing-and-storage: categorical-value-dictionary и
  unseen-sections-check, обеим написаны критерии приёмки с оракулами

2026-08-03 17:47:41 +03:00

5.1 KiB

Raw Blame History

Активная проверка: поток принёс секцию, которой раньше не было

Секция: ядро
Зачем: Момент появления новой секции фиксируется в базе, но заметить его может только тот, кто догадается заглянуть в колонку
Теги: 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 ждёт тех же данных.

5.1 KiB Raw Blame History