идентичность эпизода — интервал: блокер снят измерением

- находка 47: ключ (date,start,end) даёт 174 координаты сна против 170 по
  метке и ноль столкновений внутри доставки против 33; value в ключе лишний
- UUID в выгрузку Apple не попадает, другой идентичности у эпизода нет
- поэпизодный sleep_analysis вернулся в scope razbor-metrik-v-obekty

openspec/changes/razbor-metrik-v-obekty/specs/storage/spec.md

@@ -2,11 +2,11 @@
 
 ### Requirement: Идентичность точки по координатам
 
-Система SHALL адресовать точку координатами `метрика + слой + метка времени`.
-Поле `source` в ключ входить MUST NOT: оно нестабильно — то же измерение с тем
-же значением приезжает то как `Apple Watch Ultra 3|iPad (Anton)`, то как
-`Apple Watch Ultra 3`, потому что Health переосмысливает атрибуцию задним
-числом.
+Система SHALL адресовать точку-измерение координатами
+`метрика + слой + метка времени`. Поле `source` в ключ входить MUST NOT: оно
+нестабильно — то же измерение с тем же значением приезжает то как
+`Apple Watch Ultra 3|iPad (Anton)`, то как `Apple Watch Ultra 3`, потому что
+Health переосмысливает атрибуцию задним числом.
 
 Идентичность по хешу содержимого проверялась и отвергнута: она задваивала
 минутный слой целиком — 120 точек в часе вместо 60.
@@ -21,27 +21,38 @@
 - **WHEN** точка с теми же координатами приезжает с другой строкой `source`
 - **THEN** она остаётся одной точкой, а не превращается в две
 
-### Requirement: Эпизодные схемы не сохраняются до решения об идентичности
+### Requirement: Идентичность эпизода по интервалу
 
-Система MUST NOT сохранять точки схем, у которых метка времени не уникальна, —
-пока модель их идентичности не определена. Такие точки разбираются и
-учитываются счётчиком, но в объекты не пишутся.
+Система SHALL адресовать точку-интервал координатами
+`метрика + слой + начало + конец`. Метки времени для неё недостаточно: под
+одной меткой лежит до трёх разных эпизодов сна.
 
-Известная такая схема одна: поэпизодный `sleep_analysis`. Измерено: 31
-координата в 21 доставке из 89 задвоена **внутри одной доставки**, где
-`received_at` общий и тай-брейк по нему неприменим в принципе. Сохранять их по
-правилу, о котором известно, что оно теряет, хуже, чем не сохранять: тела
-остаются в архиве, и после решения их подберёт пересборка.
+Эпизодность SHALL выводиться из формы точки — точка несёт `start` и `end`,
+отличные от `date`, — а не назначаться списком имён метрик. Список был бы
+вторым способом описывать то, что уже сказано формой точки, и разошёлся бы с
+ней на первой же новой метрике HAE.
 
-Развилка вынесена блокером `identichnost-epizodnyh-metrik`. Суточной сводки
-(`sleep_analysis_summary`) ограничение не касается — у неё метка на полуночи
-уникальна.
+Измерено на всех 94 доставках (1880 эпизодных точек, находка 47): ключ по метке
+даёт 170 координат и 33 столкновения **внутри одной доставки**, ключ по
+интервалу — 174 координаты и ноль столкновений. Внутридоставочные столкновения
+и делают ключ по метке неисправимым: `received_at` там общий, тай-брейк по нему
+неприменим в принципе, и исход решал бы порядок элементов в JSON-массиве — а он
+нестабилен.
 
-#### Scenario: Поэпизодная запись сна не попадает в объект
+Час объекта для точки-интервала SHALL определяться по началу эпизода: эпизод
+пересекает границы часов, и любой другой выбор сделал бы принадлежность
+объекту зависящей от длительности.
 
-- **WHEN** разобрана точка метрики `sleep_analysis` поэпизодной схемы
-- **THEN** она не сохраняется в часовой объект
-- **AND** факт учитывается счётчиком в итоге разбора доставки
+#### Scenario: Эпизоды с одной меткой и разными интервалами не схлопываются
+
+- **WHEN** в доставке приходят точки `sleep_analysis` с одинаковым `date` и
+  разными парами `start`/`end`
+- **THEN** каждая сохраняется отдельной точкой
+
+#### Scenario: Повтор эпизода в следующей доставке не задваивает
+
+- **WHEN** точка с тем же `start` и `end` приезжает следующей доставкой
+- **THEN** она остаётся одной точкой
 
 ### Requirement: Разрешение столкновений по полноте