закрыта задача unseen-sections-check

docs/tasks/SPRINT.md

@@ -5,4 +5,3 @@
 Урожай спринта поднимается `tasks.py list --tag sprint:2026-08-03` — это первая порция переоценки на сессии.
 
 ## Набор
-- [Активная проверка: поток принёс секцию, которой раньше не было](items/unseen-sections-check.md) — Момент появления новой секции фиксируется в базе, но заметить его может только тот, кто догадается заглянуть в колонку

docs/tasks/items/unseen-sections-check.md

@@ -1,68 +0,0 @@
-# Активная проверка: поток принёс секцию, которой раньше не было
-
-- **Секция:** ядро
-- **Зачем:** Момент появления новой секции фиксируется в базе, но заметить его может только тот, кто догадается заглянуть в колонку
-- **Теги:** 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) ждёт
-тех же данных.