healthlog/openspec/changes/archive/2026-08-04-tie-break-equal-completeness/specs/storage/spec.md

MODIFIED Requirements

Requirement: Разрешение столкновений по полноте

Когда по одним координатам приходят разные содержимые, система SHALL оставлять более полную точку — ту, чьё множество ключей с непустым значением является строгим надмножеством множества другой, — а не последнюю пришедшую. Иначе бедная доставка стирает у богатой поля, которых сама не несёт.

Полнота SHALL сравниваться множествами, а не их размером. Число сравнимо всегда, и потому счётчик даёт ответ там, где ответа нет: точка с пятью полями, не несущими содержания, побеждала бы настоящее измерение с двумя полями и стирала бы его безвозвратно.

Измерено (находка 49): настоящих столкновений 2 897 из 444 256 координат (0.65%); из них 981 различаются набором полей — это и есть область правила полноты, — 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 определяться по разобранному значению, а не по байтам: 0, 0.0, 0e0, -0 и { } — та же пустота, что 0 и {}.

false пустотой MUST NOT считаться: для булева поля это одно из двух значений, а не отсутствие содержания (isIndoor: false — тренировка на улице).

Поле source в множество не входит — оно нестабильно и переписывается задним числом (находка 36), так что о полноте измерения ничего не говорит.

Содержимое, которое не разбирается как JSON-объект, SHALL нести пустое множество ключей: так оно проигрывает любой точке с содержанием и не загрязняет наблюдение о несравнимых наборах.

Надмножество побеждает только тогда, когда оно несёт то же содержание: значения ключей, содержательных у обеих точек, MUST совпадать (с точностью до канонической формы). Иначе точки несут разные измерения, и надмножество имён о полноте не говорит ничего — такая пара MUST разрешаться как равнополная. Без этого условия точка {date, qty:0.001, p1:null, p2:null} вытесняла бы {date, qty:72.5}, то есть точка, где ни одно значение не измерение, стирала бы измерение — ровно то, ради отрицания чего правило переписано.

Если множества ключей с непустым значением равны и значения совпали, система SHALL сравнить множества всех ключей, кроме source, и оставить строгое надмножество. Без этого разряда правило теряло бы поля там, где заведено их беречь: точка {date, qty:10, Min:0, Max:0} и точка {date, qty:10} несут одинаковое содержание, и Min с Max исчезли бы из витрины по жребию. Несравнимость на этом разряде исходом MUST NOT быть: лишние ключи там заведомо пусты, объединять в них нечего.

Если полнота ответа не дала — равные множества с разными значениями либо несравнимые множества, — победителем SHALL быть точка, пришедшая разбираемой доставкой, а не лежавшая в объекте. Байтовый порядок канонических форм на этом разряде отвергнут замером: он берёт меньшее значение в 1 847 случаях из 1 912 (находка 49), то есть системно хранит версию, которую источник уже пересчитал. Ценой этого выбора час 2026-08-03T07:00Z метрики step_count остался с недосчитанным значением, сверка слоёв объявила метрику мгновенной против 23 согласных часов, и род ушёл в unknown — Read API потерял право суммировать шаги.

Значение точки в правило входить MUST NOT: «брать бо́льшее» верно для накопительных метрик и неверно для мгновенных, которые источник досчитывает вниз. Род метрики в правило входить MUST NOT тоже — род есть функция витрины, а правило слияния, читающее собственную выдачу, перестаёт быть функцией префикса журнала.

Столкновение ВНУТРИ одной доставки 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 NOT: на живом потоке несравнимые наборы наблюдаются единицами (2 на 155 доставок), и реализация правила, которое почти не срабатывает, стоила бы больше, чем счётчик, который скажет, если оно станет массовым.

Победителем SHALL оставаться одна из пришедших точек дословно: правило выбирает, а не конструирует. Каноническая форма существует только в момент сравнения — вернуть её вместо исходных байт значило бы сохранить округлённое число вместо присланного.

Scenario: Бедная точка не стирает поля богатой

• WHEN сохранена точка с Avg, Min, Max и context
• AND по тем же координатам приезжает точка только с Avg, Min и Max
• THEN сохранённая точка остаётся с context

Scenario: Поля без содержания полноты не добавляют

• WHEN сохранена точка с пятью полями, значения которых 0, {} и []
• AND по тем же координатам приезжает точка с date и ненулевым qty
• THEN остаётся точка с date и qty

Scenario: При равном содержании поля не теряются

• WHEN сохранена точка {date, qty, Min:0, Max:0}
• 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: Одинаково полные точки с разными значениями

• GIVEN по координатам сохранена точка предыдущей доставки
• WHEN следующей доставкой приезжает точка с тем же множеством ключей и другим значением
• THEN в витрине остаётся пришедшая точка

Scenario: Одинаково полные точки внутри одной доставки

• WHEN в одном теле по одним координатам приезжают две точки с одинаковыми множествами ключей и разными значениями
• THEN остаётся точка с меньшей канонической формой
• AND исход не зависит от порядка этих точек в массиве

Scenario: Повторная присылка сохранённого содержимого ничего не переписывает

• GIVEN по координатам сохранена точка
• WHEN следующей доставкой приезжает точка с той же канонической формой и другими байтами
• THEN в витрине остаются сохранённые байты
• AND объект не переписывается

Scenario: Полнота сильнее происхождения

• GIVEN по координатам сохранена точка с Avg, Min и Max
• WHEN следующей доставкой приезжает точка только с Avg и теми же значениями общих ключей
• THEN остаётся сохранённая точка
• AND счётчик удержаний в итоге разбора доставки растёт

Scenario: Несравнимые множества считаются, а не сливаются

• WHEN по одним координатам приходят две точки, каждая из которых несёт ключ с непустым значением, которого нет у другой
• THEN остаётся ровно одна точка, выбранная тем же правилом
• AND счётчик несравнимых наборов в итоге разбора доставки растёт
• AND система пишет WARN с координатами объекта и без значений точки

Scenario: Содержимое, которое не разбирается в объект

• WHEN по координатам сталкиваются точка с непустыми полями и содержимое, не разбирающееся как JSON-объект
• THEN остаётся точка с полями
• AND счётчик несравнимых наборов не растёт

Столкновением SHALL считаться расхождение канонических форм, а не байтов. Байты нестабильны — ради этого канонизация и заведена: из 81 952 повторно приехавших точек 67 534 различаются лишь порядком ключей, ещё 63% — последним разрядом double. Побайтовое сравнение давало бы тысячи ложных срабатываний на каждом глубоком проходе, и настоящий отказ правила стал бы неотличим от нормы.

Scenario: Столкновение с различием содержимого оставляет след

• WHEN по одним координатам сохраняется точка, каноническая форма которой отличается от уже сохранённой
• THEN система пишет запись уровня WARN без значений точки
• AND запись несёт координаты объекта: метрику, слой и час
• AND увеличивает счётчик перезаписей в итоге разбора доставки

Scenario: Дребезг сериализации столкновением не считается

• WHEN та же точка приезжает с другим порядком ключей или отличаясь последним разрядом числа
• THEN счётчик перезаписей не растёт и WARN не пишется

Без этого следа допущение «меньше полей не значит новее» не получит ни одного наблюдения, а отказ правила будет неотличим от нормальной работы до сверки с экспортом Apple — то есть месяцами.

Requirement: Замена версии сущности не теряет содержания

Сущность с собственным id SHALL замещаться целиком, а не сливаться по полям: она приезжает повторно, пока источник её досчитывает. Замер на живом архиве: одна тренировка приехала 26 раз в трёх различных содержимых — сперва добавились stepCadence и stepCount вместе с изменившимся рядом activeEnergy, затем при том же наборе полей досчитались totalEnergy и basalEnergy.

Замещение MUST быть условным: приехавшая версия побеждает, если не теряет содержания сохранённой. Порядок разбора:

1. хеш канонического содержимого совпал        → содержимое не пишется,
                                                  провенанс поднимается до
                                                  более поздней позиции журнала
2. содержание приехавшей покрывает сохранённую
   и сверх того                                → приехавшая замещает целиком
3. приехавшая теряет содержание сохранённой    → остаётся сохранённая,
                                                  счётчик + WARN
4. содержание сравнимо, наборы равны           → версия из более поздней
                                                  доставки журнала
5. наборы несравнимы                           → остаётся сохранённая,
                                                  счётчик + WARN

Содержание сравнивается множествами ключей и формой их значений — но не значениями. Сравнение полноты, принятое для точек, здесь неприменимо: оно гасит отношение включения, когда значения общих содержательных ключей разошлись, а у сущности они расходятся всегда — источник её досчитывает. Проверено: сохранённая тренировка с маршрутом против приехавшей без маршрута даёт «надмножество» при неизменных значениях и «равенство» при изменившихся, то есть на живых данных защита не сработала бы вовсе, а тест на фикстуре с неизменёнными значениями остался бы зелёным. Условия «значения общих ключей совпали» здесь быть MUST NOT.

Покрытие SHALL проверяться четырьмя условиями, все — по верхнему уровню содержимого:

1. каждый ключ сохранённой с непустым значением есть у приехавшей и тоже непуст;
2. при равенстве множеств содержательных ключей — каждый ключ сохранённой, включая пустые, есть у приехавшей. Тот же второй разряд записан для точек, и с тем же условием: иначе ключ с пустым значением исчезает по жребию тай-брейка. Безусловным он быть MUST NOT — проверено оракулом: версия с пустым ключом и без маршрута оказывалась несравнимой с законным досчётом, у которого маршрут приехал, а этого ключа нет, и маршрут не доезжал НИКОГДА;
3. форма значения не вырождается: где у сохранённой объект, у приехавшей MUST быть объект; где массив — массив. Версия, подменившая объект или массив скаляром, покрывающей быть MUST NOT — иначе «скелет» из скаляров и null-ов той же длины признаётся равным настоящей тренировке и выигрывает тай-брейк журнала;
4. верхнеуровневый массив не теряет ни длины, ни содержательных элементов: усечённый маршрут (три точки вместо 593) ключа не теряет, а маршрут из [null,null,null] не теряет и длины — притом что маршрут это 95% содержимого тренировки. Досчёт ряды удлиняет, поэтому и укорачивание, и опустошение элементов — законные признаки «приехало меньше».

Содержательность элемента ряда SHALL определяться той же пустотой, что и содержательность поля точки: null, пустая строка, ноль в любой записи, пустой объект, пустой массив; false содержателен. Второй словарь пустоты в проекте завёл бы два ответа на один вопрос. Цена этого выбора называется вслух: ряд из настоящих нулей ([0,0,0]) считается лишённым содержания, поэтому версия с таким рядом сохранённую не заместит. Ошибка направлена в безопасную сторону — правило удерживает, а не затирает, — и событие видно счётчиком; наблюдённые ряды HAE состоят из объектов, а не из чисел.

Условия 3 и 4 применяются к ключам, содержательным у сохранённой версии. Ключ, содержания не несущий, проверяется только на присутствие (условие 2): формы у пустоты нет, и требовать её сохранения означало бы отличать [] от 0 там, где ни то, ни другое ничего не несёт.

Предел правила называется вслух и не закрывается: сокращение внутри элемента ряда (точка маршрута без altitude при непустом элементе и той же длине) не ловится ничем, кроме сверки с телом в архиве.

Содержимое сущности, не разбирающееся как объект JSON, SHALL давать пустые множества ключей — то же правило, что для точки: такая версия проигрывает любой версии с содержанием и не загрязняет наблюдение о несравнимых наборах.

Единственная причина повторной присылки — доезжающий маршрут, то есть рост: обратного за 44 доставленные копии не случилось ни разу. Но восстановление требует пересборки всего журнала, поэтому событие делается наблюдаемым, а не необратимым.

Тай-брейк при равных наборах — позиция доставки в журнале (received_at, id), а не порядок свёртки. Порядок свёртки приведён к порядку журнала требованием capability приёма, но равенство это неполное: строка учёта становится видимой воркеру только после записи тела, и при конкурентном приёме остаётся окно, в котором доставка с более ранней меткой сворачивается позже. Она вернула бы витрину к недосчитанной версии, и пересборка разошлась бы с живым приёмом молча, в содержимом тренировки. Хранимая позиция журнала снимает это целиком: исход зависит от журнала, а не от того, кто раньше добрался до базы, — то есть у сущности гарантия строго сильнее, чем у точки, и держится она на колонке провенанса, которой у точки нет.

Ровно поэтому провенанс сущности SHALL обновляться и тогда, когда хеш совпал: сохранённая позиция журнала участвует в тай-брейке пункта 4, и если в ней осталась первая свёрнутая копия вместо победителя журнала, отложенная доставка вернёт витрину к прежнему содержимому — то есть живая витрина разойдётся с пересборкой. Обновление MUST касаться только провенанса; содержимое при совпавшем хеше не переписывается, счётчик записанных сущностей не растёт (он считает содержимое витрины, и его сравнимость с прежними замерами важнее учёта обновления), и метка изменения содержимого не двигается тоже: иначе она стала бы меткой касания строки и дребезжала бы двадцать шесть раз на неизменившейся тренировке, а потребитель запроса «что изменилось с момента X» получил бы шум, неотличимый от настоящего досчёта. Провенанс несёт собственную метку — времени приёма своей доставки, — и для тай-брейка её достаточно.

Обновление провенанса SHALL быть идемпотентным: равные позиции журнала (та же доставка, свёрнутая повторно) ничего не меняют.

Слово «провенанс» у сущности и у часового объекта означает разное, и это называется вслух: у объекта хранится доставка, создавшая его, и она не поднимается никогда; у сущности — доставка, чья версия лежит сейчас, и она поднимается до максимума по журналу среди версий с этим содержимым. Причина в том, что у объекта нет замещения версии целиком, а у сущности только оно и есть.

Чтение сохранённой версии, сравнение и запись результата SHALL идти одной транзакцией: хеш и провенанс, на которых держится весь тай-брейк, читаются там же, где пишется исход. Оптимистичное чтение до транзакции допустимо только с перепроверкой обоих внутри — иначе две конкурентные свёртки одной сущности прочитают одну и ту же старую позицию, обе решат «я позже», и победит та, что закоммитила последней: исход снова станет функцией порядка коммитов, а не журнала, причём молча.

Отличие от точки — в механизме, а не в намерении, и критерий выбора между ними записан здесь, чтобы третья единица хранения не открывала спор заново. Обе предпочитают позднюю версию: у сущности — по хранимой позиции журнала, у точки — по происхождению кандидата (пришла доставкой или лежала в объекте). Различает их одно: у сущности есть колонка провенанса, у точки её нет и рамка решения владельца заводить её запретила. Отсюда и разная сила гарантии, названная выше. Порядок канонических форм у обеих остался тем же и там же — тай-брейком внутри одной доставки, где провенанс общий и различать нечем. Тай-брейк по канонической форме между доставками заморозил бы тренировку на произвольной из версий навсегда, вместе с недосчитанной энергией, а у точки — систематически хранил бы меньшее значение (находка 49).

Версии одного ключа внутри одной доставки позициями не различаются, и победитель среди них SHALL быть функцией множества версий, а не порядка элементов массива: сперва отбрасываются строго покрытые кем-то из остальных, среди оставшихся берётся минимум канонической формы. «Строго покрыта» означает «покрыта другой версией и сама её не покрывает»: покрытие — предпорядок, две версии могут покрывать друг друга взаимно, и отбрасывание всего покрытого опустошило бы множество, потеряв обе. Порядок при этом обязан быть тотальным до конца: при совпавших канонических формах решает минимум исходных байтов — иначе победителем оказывается тот, кто стоял в массиве раньше, а порядок ключей в JSON от HAE нестабилен, и в хранилище легли бы разные байты при одинаковом содержимом. Попарная свёртка здесь неверна ровно так же, как она была неверна для точек: покрытие — частичный порядок, тай-брейк — тотальный, и вместе они дают нетранзитивное отношение победы, при котором [A,B,C] и [B,C,A] дают разных победителей, а порядок элементов в JSON-массиве нестабилен. Сворачиваться между собой такие версии SHALL до сравнения с сохранённой.

Факт «в одном теле приехали две версии одного ключа с разным содержанием» SHALL считаться симметрично и тоже быть функцией множества: считаются кандидаты, чья каноническая форма отличается от формы победителя. Счётчик этот SHALL быть ОТДЕЛЬНЫМ от счётчика удержаний: две версии в одном теле содержания не теряют — победитель ложится в витрину целиком, — и одно число на два события отвечало бы ни на одно. На счётчик удержаний опирается единственный контроль того, что правило покрытия не стало слишком строгим; примесь делает его неотличимым от шума.

Версии с совпавшей канонической формой SHALL схлопываться ДО выбора победителя. Выбор квадратичен по числу кандидатов, а их число приходит из чужого тела; без схлопывания тело в пределах приёма занимает свёртку на часы. Отбор SHALL видеть отмену: иначе дедлайн свёртки, заведённый ровно против зависшей работы, не значит ничего. Побайтовое различие при совпавшей канонической форме событием MUST NOT считаться — порядок ключей в JSON от HAE нестабилен и дребезг последнего разряда double тоже, так что счётчик по байтам срабатывал бы на измеренной норме потока. Различие содержимого при совпадающих множествах ключей и длинах массивов считаться SHALL: сегодня ровно этот случай даёт ноль и молчащий счётчик.

Поля версий MUST NOT объединяться: несравнимые наборы (приехавшая принесла новые ключи и потеряла старые) разрешаются в пользу сохранённой и считаются тем же счётчиком. Объединение отвергнуто там же и по той же причине, что для точек: на живом потоке событие не наступало, и вместо реализации заведено наблюдение.

Исход SHALL быть функцией журнала в его порядке. Остаточный предел называется вслух: сравнение сохранённой с приехавшей попарно — в витрине лежит победитель прошлых слияний, а не все кандидаты истории, — поэтому при несравнимых наборах (пункт 5) исход зависит от порядка проигрывания. Тот же предел есть у часового объекта; пункты 1–4 от порядка свёртки не зависят, а пункт 5 сопровождается счётчиком и WARN.

Scenario: Доехавший маршрут замещает тренировку без маршрута

• WHEN та же тренировка приезжает повторно, добавив route
• THEN в хранилище лежит версия с маршрутом

Scenario: Досчитанные значения при том же наборе полей побеждают

• WHEN та же тренировка приезжает повторно с тем же набором полей и изменившимися значениями, доставкой с более поздней позицией журнала
• THEN в хранилище лежит приехавшая версия

Scenario: Версия из более ранней доставки не откатывает витрину

• WHEN две доставки несут одну тренировку с равными наборами полей, и свёрнута сперва более поздняя по журналу, затем более ранняя
• THEN в хранилище лежит версия из более поздней доставки
• AND тот же исход даёт свёртка в обратном порядке

Scenario: Обеднённая версия сохранённую не затирает

• WHEN та же тренировка приезжает повторно без route, который был у сохранённой, и с изменившимися значениями общих полей
• THEN в хранилище остаётся сохранённая версия
• AND факт учитывается счётчиком и записью WARN с идентификатором тренировки

Scenario: Усечённый маршрут сохранённый не затирает

• WHEN та же тренировка приезжает повторно с тем же набором полей, но route короче сохранённого
• THEN в хранилище остаётся сохранённая версия
• AND факт учитывается тем же счётчиком

Scenario: Маршрут из пустых элементов сохранённый не затирает

• WHEN та же тренировка приезжает повторно с route той же длины, все элементы которого пусты (null либо пустой объект)
• THEN в хранилище остаётся сохранённая версия с координатами маршрута
• AND факт учитывается тем же счётчиком

Scenario: Скелет из скаляров сохранённую тренировку не затирает

• WHEN та же тренировка приезжает повторно, где каждый вложенный объект заменён числом, а каждый массив — массивом той же длины из null
• THEN в хранилище остаётся сохранённая версия
• AND факт учитывается тем же счётчиком

Scenario: Ключ с пустым значением не исчезает по жребию

• WHEN та же тренировка приезжает повторно без ключа, значение которого у сохранённой было пустым, при совпадающих содержательных ключах
• THEN в хранилище остаётся сохранённая версия
• AND факт учитывается тем же счётчиком удержаний

Scenario: Пустой ключ не запирает законный досчёт

• WHEN у сохранённой версии есть ключ с пустым значением, а приехавшая его не несёт, но приносит содержательный ключ, которого у сохранённой не было
• THEN приехавшая замещает сохранённую
• AND счётчик удержаний не растёт

Scenario: Две версии одной сущности в одном теле

• WHEN тело содержит два элемента секции с одним id
• THEN исход не зависит от их порядка в массиве
• AND счётчик различающихся версий тоже не зависит от их порядка

Scenario: Три версии одной сущности в одном теле

• WHEN тело содержит три элемента секции с одним id, из которых один покрывает второй, а третий несравним с обоими
• THEN победитель одинаков при любой перестановке этих трёх элементов

Scenario: Две версии разного содержания при равной длине массивов

• WHEN тело содержит два элемента секции с одним id, содержимое которых различается, но множества ключей и длины верхнеуровневых массивов совпадают
• THEN факт учитывается счётчиком различающихся версий

Scenario: Разные байты при совпавшей канонической форме событием не считаются

• WHEN тело содержит два элемента секции с одним id, различающихся только порядком ключей либо записью числа
• THEN счётчик различающихся версий не растёт
• AND в хранилище лежат одни и те же байты при любой перестановке элементов

Scenario: Повторная присылка обновляет провенанс

• WHEN та же сущность приезжает повторно с тем же содержимым доставкой, стоящей в журнале позже сохранённой
• THEN содержимое не переписывается
• AND провенанс сущности указывает на более позднюю доставку

Scenario: Отложенная доставка не возвращает витрину к прежнему содержимому

• WHEN журнал несёт содержимое A, затем B, затем снова A, и доставка с B свёрнута последней
• THEN содержимое сущности и отпечаток витрины совпадают со свёрткой того же журнала в его порядке

Scenario: Составной ключ не даёт коллизии отпечатка

• WHEN две витрины различаются только тем, где проходит граница между родом и идентификатором записи
• THEN отпечатки не совпадают

Scenario: Несравнимые наборы полей не объединяются

• WHEN приехавшая версия несёт содержательный ключ, которого нет у сохранённой, и теряет содержательный ключ, который у сохранённой есть
• THEN в хранилище остаётся сохранённая версия
• AND факт учитывается тем же счётчиком

Scenario: Повторная свёртка того же журнала состояния не меняет

• WHEN те же доставки сворачиваются повторно в том же порядке
• THEN содержимое сущностей не меняется

ADDED Requirements

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 счётчик потери содержания не растёт