store: при равной полноте точек побеждает пришедшая доставка

- байтовый порядок канонических форм остался тай-брейком только внутри одной
  доставки: на живом корпусе он решал 98,8% спорных координат и системно хранил
  меньшее значение, из-за чего step_count терял род и verify:archive был красным
- правило перестало быть коммутативным осознанно, поэтому порядок свёртки
  приведён к журнальному: проход воркера прекращается на отложенной доставке,
  а свёртка вне порядка журнала пишет WARN
- заведены счётчики PointsHeld и PointsErased — удержание полнотой и
  единственное направление, в котором правило теряет содержание

openspec/specs/storage/spec.md

@@ -79,6 +79,14 @@ TBD - created by archiving change razbor-metrik-v-obekty. Update Purpose after a
 полноты, — 1 916 несут равные наборы и разные значения, где исход решает
 тай-брейк, а несравнимых наборов ноль.
 
+Перемер 2026-08-04 на выросшем корпусе (155 доставок, 460 995 координат,
+настоящий ключ со слоем) уточнил соотношение и сделал тай-брейк главным
+разрядом правила, а не крайним: спорных координат 80 129, полнота отбрасывает
+кого-то в 981 из них (1,2%), остальные 79 148 (98,8%) уходят в тай-брейк.
+Смена тай-брейка меняет исход на 75 494 координатах, из них 71 773 —
+`basal_energy_burned` слоя `raw`, то есть посекундная развёртка HAE, которую
+Read API суммировать и так не имеет права.
+
 Пустым значением MUST считаться `null`, пустая строка, число, равное нулю (в
 любой записи), пустой объект и пустой массив: поле без содержания не делает
 точку полнее точки, где этого поля нет вовсе. Пустота MUST определяться по
@@ -111,37 +119,92 @@ TBD - created by archiving change razbor-metrik-v-obekty. Update Purpose after a
 витрины по жребию. Несравнимость на этом разряде исходом MUST NOT быть:
 лишние ключи там заведомо пусты, объединять в них нечего.
 
-Если равны и эти множества, а значения различаются, исход MUST быть
-детерминированным и не зависеть от порядка, в котором доставки дошли до
-хранилища: свёртка по журналу обязана давать то же состояние, что приём в
-реальном времени.
+**Если полнота ответа не дала — равные множества с разными значениями либо
+несравнимые множества, — победителем SHALL быть точка, пришедшая разбираемой
+доставкой, а не лежавшая в объекте.** Байтовый порядок канонических форм на
+этом разряде отвергнут замером: он берёт меньшее значение в 1 847 случаях из
+1 912 (находка 49), то есть системно хранит версию, которую источник уже
+пересчитал. Ценой этого выбора час `2026-08-03T07:00Z` метрики `step_count`
+остался с недосчитанным значением, сверка слоёв объявила метрику мгновенной
+против 23 согласных часов, и род ушёл в `unknown` — Read API потерял право
+суммировать шаги.
 
-Победитель MUST быть функцией **множества** точек координаты, а не порядка их
-поступления. Попарная свёртка этого не даёт: полнота — частичный порядок,
-тай-брейк — тотальный, и вместе они образуют нетранзитивное отношение победы
-(A превосходит B по полноте, B бьёт C тай-брейком, C бьёт A тай-брейком).
-При таком цикле повторная свёртка одной и той же доставки меняет содержимое
-объекта, и витрина перестаёт быть функцией журнала. Поэтому система SHALL
-отбросить кандидатов, превзойдённых по полноте кем-то другим, и выбрать
-победителя среди оставшихся по тотальному порядку — обе операции зависят
-только от состава множества.
+Значение точки в правило входить MUST NOT: «брать бо́льшее» верно для
+накопительных метрик и неверно для мгновенных, которые источник досчитывает
+вниз. Род метрики в правило входить MUST NOT тоже — род есть функция витрины, а
+правило слияния, читающее собственную выдачу, перестаёт быть функцией префикса
+журнала.
 
-Сравнение по `received_at` для этого не годится: у сохранённой точки нет
-провенанса — ни времени приёма, ни идентификатора доставки, — и сравнивать
-не с чем. Детерминизм обеспечивается свойством самих значений (например,
-порядком канонических форм), а не порядком событий.
+**Столкновение ВНУТРИ одной доставки SHALL разрешаться порядком канонических
+форм**: провенанс у таких точек общий, различать их нечем, а порядок элементов
+в JSON-массиве от HAE нестабилен. Точка, канонически совпавшая с сохранённой,
+SHALL считаться пришедшей — иначе сохранённый кандидат проигрывал бы соседу по
+доставке, которого обязан был обойти по байтам, и «внутри доставки решают
+байты» нарушалось бы ровно тогда, когда доставка ничего не изменила. Побеждает
+при этом сохранённое содержимое дословно: хеш не двигается, объект не
+переписывается. Тем же правилом схлопываются две точки одного тела с совпавшей
+канонической формой — в витрине остаются байты **встреченной первой**. Выбор
+между ними ненаблюдаем по построению: различие при совпавшей канонической форме
+это порядок ключей или последний разряд double, и хеш содержимого объекта
+считается по канонической форме, а не по байтам.
+
+Цена нового тай-брейка называется вслух и ограничивается разрядом, на котором
+он работает. **Когда значения общих содержательных ключей разошлись, полнота
+ответа не даёт по построению** — «надмножество имён о полноте не говорит
+ничего», см. выше, — и пришедшая точка побеждает, даже если сохранённая несла
+сверх того ключи **без содержания** (`Min:0`, `Max:0`). Такие ключи по
+определению пустоты этого же требования содержания не несут, и второй разряд их
+бережёт только там, где содержание совпало. Прежний байтовый порядок сохранял
+их случайно — по тому, что каноническая форма с ключом `Max` сортируется раньше
+формы с одним `date`, — и рассчитывать на такую защиту было нельзя.
+
+**Класс входа, на котором правило ведёт себя хуже прежнего, называется здесь.**
+Две автоматизации, чьи наборы метрик пересекаются, наполняют одну координату
+разными значениями (находка 14); прежний тай-брейк давал на ней устойчивый
+исход, новый — чередование по последней доставке, то есть перезапись объекта и
+`WARN` на каждой доставке. Защита остаётся операционной («наборы метрик между
+автоматизациями не пересекать»), система её не проверяет, и это записано, чтобы
+следующий разбор не искал причину заново.
+
+**Победитель SHALL быть функцией множества точек координаты и их происхождения
+(доставка или витрина), а не порядка элементов внутри доставки.** Попарная
+свёртка этого не даёт: полнота — частичный порядок, тай-брейк — тотальный, и
+вместе они образуют нетранзитивное отношение победы (A превосходит B по
+полноте, B бьёт C тай-брейком, C бьёт A тай-брейком). При таком цикле повторная
+свёртка одной и той же доставки меняет содержимое объекта. Поэтому система
+SHALL отбросить кандидатов, превзойдённых по полноте кем-то другим, и выбрать
+победителя среди оставшихся по тотальному порядку — сперва происхождение,
+затем каноническая форма.
+
+**Правило тем самым есть явная функция порядка журнала, и цена этого называется
+вслух.** Функцией множества оно быть перестало: «пришедшая побеждает» не
+коммутативно. Витрина остаётся свёрткой журнала только пока порядок свёртки
+равен порядку журнала — требование, которое capability приёма обязана
+обеспечивать, а capability пересборки обязана проверять оракулом. Восстановить
+коммутативность «для чистоты» MUST NOT: это откатило бы починку молча.
+
+Сравнение по `received_at` для тай-брейка не годится: у сохранённой точки нет
+провенанса — ни времени приёма, ни идентификатора доставки, — и сравнивать не с
+чем. Заводить его это изменение SHALL NOT: колонка провенанса на точку означала
+бы смену формата содержимого объекта, миграцию и рост нижнего слоя, а
+«пришедшая побеждает» даёт тот же исход, пока порядок свёртки равен порядку
+журнала. Запрет этот **бюджетный, а не принципиальный**: он назван решением
+владельца от 2026-08-04 и снимается тем же порядком. Если окно конкурентного
+приёма закрыть на приёме не удастся, провенанс (на объект, не на точку)
+остаётся единственным ходом, и спека обязана это допускать, а не запрещать
+вечно.
 
 Если множества **несравнимы** — каждое несёт ключ с непустым значением,
-которого нет у другого, — система SHALL выбрать победителя тем же
-детерминированным правилом, что и при равных множествах, и MUST оставить
-наблюдение: счётчик в итоге разбора доставки, координаты объекта и запись
-`WARN` без значений точки. Несравнимый набор — частный случай столкновения:
-счётчик перезаписей растёт вместе с ним, а координаты попадают в оба списка.
+которого нет у другой, — система SHALL выбрать победителя тем же правилом, что
+и при равных множествах, и MUST оставить наблюдение: счётчик в итоге разбора
+доставки, координаты объекта и запись `WARN` без значений точки. Несравнимый
+набор — частный случай столкновения: счётчик перезаписей растёт вместе с ним, а
+координаты попадают в оба списка.
 
-Объединять поля двух точек система SHALL NOT: на живом потоке несравнимых
-наборов не встретилось ни разу (0 из 2 897 столкновений, при обоих определениях
-пустоты), и реализация правила, которое никогда не срабатывает, стоила бы
-больше, чем счётчик, который скажет, если оно наступит.
+Объединять поля двух точек система SHALL NOT: на живом потоке несравнимые
+наборы наблюдаются единицами (2 на 155 доставок), и реализация правила, которое
+почти не срабатывает, стоила бы больше, чем счётчик, который скажет, если оно
+станет массовым.
 
 Победителем SHALL оставаться одна из пришедших точек **дословно**: правило
 выбирает, а не конструирует. Каноническая форма существует только в момент
@@ -163,21 +226,52 @@ TBD - created by archiving change razbor-metrik-v-obekty. Update Purpose after a
 #### Scenario: При равном содержании поля не теряются
 
 - **WHEN** сохранена точка `{date, qty, Min:0, Max:0}`
-- **AND** по тем же координатам приезжает точка `{date, qty}` с другим `qty`
+- **AND** по тем же координатам приезжает точка `{date, qty}` с тем же `qty`
 - **THEN** остаётся точка с `Min` и `Max`
 
+#### Scenario: При разошедшихся значениях пустые ключи не удерживают точку
+
+- **WHEN** сохранена точка `{date, qty:10, Min:0, Max:0}`
+- **AND** по тем же координатам следующей доставкой приезжает точка
+  `{date, qty:12}`
+- **THEN** остаётся пришедшая точка, а `Min` и `Max` в витрине не остаются
+- **AND** счётчик перезаписей растёт
+
 #### Scenario: Одинаково полные точки с разными значениями
 
-- **WHEN** по одним координатам приходят две точки с одинаковыми множествами
-  ключей и разными значениями
-- **THEN** исход определяется детерминированно и не зависит от порядка
-  воспроизведения доставок
+- **GIVEN** по координатам сохранена точка предыдущей доставки
+- **WHEN** следующей доставкой приезжает точка с тем же множеством ключей и
+  другим значением
+- **THEN** в витрине остаётся пришедшая точка
+
+#### Scenario: Одинаково полные точки внутри одной доставки
+
+- **WHEN** в одном теле по одним координатам приезжают две точки с одинаковыми
+  множествами ключей и разными значениями
+- **THEN** остаётся точка с меньшей канонической формой
+- **AND** исход не зависит от порядка этих точек в массиве
+
+#### Scenario: Повторная присылка сохранённого содержимого ничего не переписывает
+
+- **GIVEN** по координатам сохранена точка
+- **WHEN** следующей доставкой приезжает точка с той же канонической формой и
+  другими байтами
+- **THEN** в витрине остаются сохранённые байты
+- **AND** объект не переписывается
+
+#### Scenario: Полнота сильнее происхождения
+
+- **GIVEN** по координатам сохранена точка с `Avg`, `Min` и `Max`
+- **WHEN** следующей доставкой приезжает точка только с `Avg` и теми же
+  значениями общих ключей
+- **THEN** остаётся сохранённая точка
+- **AND** счётчик удержаний в итоге разбора доставки растёт
 
 #### Scenario: Несравнимые множества считаются, а не сливаются
 
 - **WHEN** по одним координатам приходят две точки, каждая из которых несёт
   ключ с непустым значением, которого нет у другой
-- **THEN** остаётся ровно одна точка, выбранная детерминированно
+- **THEN** остаётся ровно одна точка, выбранная тем же правилом
 - **AND** счётчик несравнимых наборов в итоге разбора доставки растёт
 - **AND** система пишет `WARN` с координатами объекта и без значений точки
 
@@ -631,13 +725,15 @@ HAE состоят из объектов, а не из чисел.
 необратимым.
 
 **Тай-брейк при равных наборах — позиция доставки в журнале `(received_at, id)`,
-а не порядок свёртки.** «Побеждает приехавшая» было бы функцией порядка
-свёртки, а он порядку журнала не равен: воркер сворачивает в порядке журнала
-только среди видимых ему доставок и абсолютного порядка при конкурентных
-приёмах не обещает. Доставка с более ранней меткой, свёрнутая позже, вернула бы
+а не порядок свёртки.** Порядок свёртки приведён к порядку журнала требованием
+capability приёма, но равенство это неполное: строка учёта становится видимой
+воркеру только после записи тела, и при конкурентном приёме остаётся окно, в
+котором доставка с более ранней меткой сворачивается позже. Она вернула бы
 витрину к недосчитанной версии, и пересборка разошлась бы с живым приёмом молча,
-в содержимом тренировки. Позиция журнала снимает это: исход зависит от журнала,
-а не от того, кто раньше добрался до базы.
+в содержимом тренировки. Хранимая позиция журнала снимает это целиком: исход
+зависит от журнала, а не от того, кто раньше добрался до базы, — то есть у
+сущности гарантия строго сильнее, чем у точки, и держится она на колонке
+провенанса, которой у точки нет.
 
 Ровно поэтому **провенанс сущности SHALL обновляться и тогда, когда хеш
 совпал**: сохранённая позиция журнала участвует в тай-брейке пункта 4, и если
@@ -669,12 +765,17 @@ HAE состоят из объектов, а не из чисел.
 закоммитила последней: исход снова станет функцией порядка коммитов, а не
 журнала, причём молча.
 
-Отличие от точки здесь содержательное: у точки на одних координатах законно
-встречаются два разных измерения, и предпочитать позднее нет оснований — там
-исход решает порядок канонических форм. У сущности `id` — идентичность одного
-объекта HealthKit, и вторая версия есть тот же объект, пересчитанный источником;
-тай-брейк по канонической форме заморозил бы тренировку на произвольной из
-версий навсегда, вместе с недосчитанной энергией.
+Отличие от точки — в **механизме**, а не в намерении, и критерий выбора между
+ними записан здесь, чтобы третья единица хранения не открывала спор заново. Обе
+предпочитают позднюю версию: у сущности — по хранимой позиции журнала, у точки —
+по происхождению кандидата (пришла доставкой или лежала в объекте). Различает их
+одно: у сущности есть колонка провенанса, у точки её нет и рамка решения
+владельца заводить её запретила. Отсюда и разная сила гарантии, названная выше.
+Порядок канонических форм у обеих остался тем же и там же — тай-брейком
+**внутри одной доставки**, где провенанс общий и различать нечем. Тай-брейк по
+канонической форме между доставками заморозил бы тренировку на произвольной из
+версий навсегда, вместе с недосчитанной энергией, а у точки — систематически
+хранил бы меньшее значение (находка 49).
 
 Версии одного ключа **внутри одной доставки** позициями не различаются, и
 победитель среди них SHALL быть **функцией множества версий, а не порядка
@@ -1494,3 +1595,76 @@ HealthKit рядом. Значение хранится **дословно**, т
 - **THEN** в разобранных записях лога нет ни одной наблюдённой строки и ни
   одного кода
 - **AND** счётчики значений без кода в записи присутствуют
+### Requirement: Проигрыш пришедшей точки считается отдельно
+
+Итог разбора доставки SHALL нести счётчик координат, где пришедшая точка
+проиграла сохранённой, и координаты первых таких объектов — метрику, слой и
+час, без значений точек.
+
+Счётчик SHALL быть отдельным от счётчика перезаписей. Перезаписи считают
+столкновение в обе стороны (на корпусе 2026-08-04 они сработали бы около 84 000
+раз), и отличить по ним «оставили пришедшую» от «выбросили пришедшую» нельзя —
+то есть единственное событие, ради наблюдения за которым правило и переписано,
+остаётся невидимым.
+
+Под новым правилом пришедшая точка проигрывает ровно тогда, когда сохранённая
+**строго полнее**. То есть счётчик меряет одно направление правила полноты — то,
+в котором оно спорит с журналом; случай «пришедшая строго полнее» им не
+считается, потому что там полнота и журнал согласны. Молчащий счётчик означает,
+что правило полноты перестало спорить вовсе, и это событие для разбора, а не
+отказ.
+
+Счётчик SHALL быть виден не только в логе свёртки, но и в отчёте пересборки —
+рядом с удержанными версиями сущностей и по той же причине: сходимость
+отпечатка правило удержания не проверяет по построению, живой приём и пересборка
+пользуются одним правилом и одинаково сойдутся на одинаково удержанной точке.
+
+Значений точек счётчик и его координаты содержать MUST NOT — данные о здоровье
+чувствительнее токенов.
+
+#### Scenario: Удержание сохранённой точки видно в итоге доставки
+
+- **GIVEN** по координатам сохранена точка, строго более полная, чем пришедшая
+- **WHEN** доставка сворачивается
+- **THEN** счётчик удержаний растёт
+- **AND** координаты объекта попадают в список удержаний
+- **AND** счётчик остаётся нулевым, когда побеждает пришедшая точка
+
+### Requirement: Потеря содержания пришедшей точкой считается и не молчит
+
+Система SHALL считать отдельным счётчиком координаты, где победителем оказалась
+**пришедшая** точка, а у проигравшей был ключ с непустым значением, которого у
+победительницы нет. Координаты таких объектов SHALL попадать в лог, и система
+SHALL писать `WARN` — без значений точек.
+
+Это единственное направление, в котором новое правило способно потерять
+содержание, и защитить его нечем **по построению**: разряд полноты в этом
+случае погашен — значения общих содержательных ключей разошлись, и надмножество
+имён о полноте не говорит ничего. До смены тай-брейка тот же исход случался по
+жребию байтового порядка и так же молча; разница в том, что теперь он
+детерминирован, а значит либо не случается вовсе, либо случается всегда.
+
+Счётчик SHALL быть отдельным и от перезаписей, и от удержаний: перезаписи
+считают столкновение в обе стороны, удержания — противоположное направление, и
+ни один из них на вопрос «потеряли ли мы содержание» не отвечает.
+
+Запрещать такое слияние система SHALL NOT: измерено — 2 координаты из 80 129
+спорных на живом корпусе, и обе те же, что дают несравнимые наборы. Событие
+обратимо пересборкой, пока жив архив, поэтому вместо запрета — наблюдение, тем
+же решением и по той же причине, по какой отложено объединение полей.
+
+Значений точек ни счётчик, ни координаты, ни запись содержать MUST NOT.
+
+#### Scenario: Пришедшая точка унесла содержательный ключ сохранённой
+
+- **GIVEN** сохранена точка `{date, asleep:7.5, rem:1.2}`
+- **WHEN** следующей доставкой приезжает точка `{date, asleep:7.4}`
+- **THEN** в витрине остаётся пришедшая точка
+- **AND** счётчик потери содержания растёт, а счётчик удержаний — нет
+- **AND** система пишет `WARN` с координатами объекта и без значений точек
+
+#### Scenario: Пришедшая точка ничего не унесла
+
+- **WHEN** множества ключей у сохранённой и пришедшей совпадают, а значения
+  различаются
+- **THEN** счётчик потери содержания не растёт