Дозакрыты находки ревью по слиянию сущностей

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

openspec/specs/storage/spec.md

@@ -486,15 +486,30 @@ Apple его нет (находка 46). Поэтому список MUST сох
 за двое суток и основанием для второй транзакции не является.
 
 Система SHALL хранить рядом с сущностью хеш её канонического содержимого и
-пропускать запись, если хеш не изменился. Тренировка переприсылается каждой
-доставкой автоматизации, пока не доедет маршрут: на живом архиве 44 доставленные
-копии дают три различных содержимых.
+пропускать запись содержимого, если хеш не изменился. Тренировка
+переприсылается каждой доставкой автоматизации, пока не доедет маршрут: на
+живом архиве 44 доставленные копии дают три различных содержимых.
 
 Сравнение SHALL начинаться с хеша, читаемого **без** содержимого сохранённой
 сущности: маршрут доходит до мегабайта, разжимать и канонизировать его на каждой
-из 44 копий не за чем. Хеш приехавшей сущности SHALL считаться один раз на
-доставку, а не на каждой попытке повтора транзакции при занятости базы:
-канонизация материализует значение целиком, и повтор умножал бы пик кучи.
+из 44 копий не за чем.
+
+Каноническая форма приехавшей сущности SHALL считаться **один раз на версию и
+до входа в транзакцию**, а хеш SHALL браться из уже посчитанной формы. Внутри
+транзакции канонизации приехавших версий быть MUST NOT: транзакция открывается
+`immediate`, то есть блокирует запись, и повторяется до пяти раз при занятости
+базы — измерено, что тело 40 МиБ даёт пик кучи 768 МиБ, а тело 63 МиБ удерживает
+блокировку 5.019 с при `busy_timeout` 5000, после чего конкурентная доставка
+исчерпывает повторы. Считать форму дважды (в хеше и в сравнении) система MUST
+NOT: это ровно та же работа над теми же байтами.
+
+Остаточный предел называется вслух: разбор **сохранённой** версии остаётся
+внутри транзакции — её содержимое читается оттуда же и только когда хеш
+разошёлся. Значит удержание блокировки по-прежнему пропорционально размеру
+сохранённой сущности, и класс отказа «конкурентный приём исчерпал повторы → 500
+по доставке, тело которой уже в архиве» этим требованием **не закрывается**, а
+лишь становится различимым в логе. Закрыть его может только предел на размер
+сущности вместе с потоковым расчётом — отдельная задача.
 
 #### Scenario: Тренировка хранится одной строкой с маршрутом
 
@@ -514,7 +529,8 @@ Apple его нет (находка 46). Поэтому список MUST сох
 
 #### Scenario: Повторная присылка той же тренировки не пишет в базу
 
-- **WHEN** приезжает тренировка, содержимое которой совпадает с сохранённым
+- **WHEN** приезжает тренировка, содержимое которой совпадает с сохранённым, и
+  её доставка стоит в журнале не позже сохранённой
 - **THEN** хеш совпадает и запись не выполняется
 
 #### Scenario: Отказ посреди доставки не оставляет части сущностей
@@ -522,6 +538,13 @@ Apple его нет (находка 46). Поэтому список MUST сох
 - **WHEN** свёртка доставки прерывается на середине
 - **THEN** не записывается ни одна сущность этой доставки
 
+#### Scenario: Каноническая форма сущности считается один раз
+
+- **WHEN** доставка с сущностью сворачивается, и транзакция повторяется из-за
+  занятости базы
+- **THEN** каноническая форма приехавшей сущности не пересчитывается ни на
+  повторе, ни отдельно от хеша
+
 ### Requirement: Замена версии сущности не теряет содержания
 
 Сущность с собственным `id` SHALL замещаться **целиком**, а не сливаться по
@@ -535,7 +558,9 @@ Apple его нет (находка 46). Поэтому список MUST сох
 содержания** сохранённой. Порядок разбора:
 
 ```
-1. хеш канонического содержимого совпал        → записи нет
+1. хеш канонического содержимого совпал        → содержимое не пишется,
+                                                  провенанс поднимается до
+                                                  более поздней позиции журнала
 2. содержание приехавшей покрывает сохранённую
    и сверх того                                → приехавшая замещает целиком
 3. приехавшая теряет содержание сохранённой    → остаётся сохранённая,
@@ -546,21 +571,59 @@ Apple его нет (находка 46). Поэтому список MUST сох
                                                   счётчик + WARN
 ```
 
-**Содержание сравнивается множеством ключей с непустым значением — и только им.**
-Сравнение полноты, принятое для точек, здесь неприменимо: оно гасит отношение
-включения, когда значения общих содержательных ключей разошлись, а у сущности
-они расходятся **всегда** — источник её досчитывает. Проверено: сохранённая
-тренировка с маршрутом против приехавшей без маршрута даёт «надмножество» при
-неизменных значениях и «равенство» при изменившихся, то есть на живых данных
-защита не сработала бы вовсе, а тест на фикстуре с неизменёнными значениями
-остался бы зелёным. Условия «значения общих ключей совпали» здесь быть MUST NOT.
+**Содержание сравнивается множествами ключей и формой их значений — но не
+значениями.** Сравнение полноты, принятое для точек, здесь неприменимо: оно
+гасит отношение включения, когда значения общих содержательных ключей
+разошлись, а у сущности они расходятся **всегда** — источник её досчитывает.
+Проверено: сохранённая тренировка с маршрутом против приехавшей без маршрута
+даёт «надмножество» при неизменных значениях и «равенство» при изменившихся, то
+есть на живых данных защита не сработала бы вовсе, а тест на фикстуре с
+неизменёнными значениями остался бы зелёным. Условия «значения общих ключей
+совпали» здесь быть MUST NOT.
 
-Дополнительно к множеству ключей SHALL сравниваться **длина верхнеуровневых
-массивов**: усечённый маршрут (три точки вместо 593) ключа не теряет, а теряет
-95% содержимого тренировки. Досчёт ряды удлиняет, поэтому укорачивание —
-законный признак «приехало меньше». Предел правила называется вслух: сокращение
-**внутри** элемента ряда (точка маршрута без `altitude`) не ловится ничем, кроме
-сверки с телом в архиве.
+Покрытие 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 доставленные копии не случилось ни разу. Но восстановление
@@ -576,6 +639,36 @@ Apple его нет (находка 46). Поэтому список MUST сох
 в содержимом тренировки. Позиция журнала снимает это: исход зависит от журнала,
 а не от того, кто раньше добрался до базы.
 
+Ровно поэтому **провенанс сущности SHALL обновляться и тогда, когда хеш
+совпал**: сохранённая позиция журнала участвует в тай-брейке пункта 4, и если
+в ней осталась первая свёрнутая копия вместо победителя журнала, отложенная
+доставка вернёт витрину к прежнему содержимому — то есть живая витрина
+разойдётся с пересборкой. Обновление MUST касаться **только** провенанса;
+содержимое при совпавшем хеше не переписывается, счётчик записанных сущностей
+не растёт (он считает содержимое витрины, и его сравнимость с прежними замерами
+важнее учёта обновления), и метка изменения содержимого не двигается тоже:
+иначе она стала бы меткой касания строки и дребезжала бы двадцать шесть раз на
+неизменившейся тренировке, а потребитель запроса «что изменилось с момента X»
+получил бы шум, неотличимый от настоящего досчёта. Провенанс несёт собственную
+метку — времени приёма своей доставки, — и для тай-брейка её достаточно.
+
+Обновление провенанса SHALL быть идемпотентным: равные позиции журнала (та же
+доставка, свёрнутая повторно) ничего не меняют.
+
+Слово «провенанс» у сущности и у часового объекта означает **разное**, и это
+называется вслух: у объекта хранится доставка, **создавшая** его, и она не
+поднимается никогда; у сущности — доставка, **чья версия лежит сейчас**, и она
+поднимается до максимума по журналу среди версий с этим содержимым. Причина в
+том, что у объекта нет замещения версии целиком, а у сущности только оно и есть.
+
+Чтение сохранённой версии, сравнение и запись результата SHALL идти **одной
+транзакцией**: хеш и провенанс, на которых держится весь тай-брейк, читаются
+там же, где пишется исход. Оптимистичное чтение до транзакции допустимо только
+с перепроверкой обоих внутри — иначе две конкурентные свёртки одной сущности
+прочитают одну и ту же старую позицию, обе решат «я позже», и победит та, что
+закоммитила последней: исход снова станет функцией порядка коммитов, а не
+журнала, причём молча.
+
 Отличие от точки здесь содержательное: у точки на одних координатах законно
 встречаются два разных измерения, и предпочитать позднее нет оснований — там
 исход решает порядок канонических форм. У сущности `id` — идентичность одного
@@ -583,15 +676,42 @@ Apple его нет (находка 46). Поэтому список MUST сох
 тай-брейк по канонической форме заморозил бы тренировку на произвольной из
 версий навсегда, вместе с недосчитанной энергией.
 
-Две версии одного ключа **внутри одной доставки** позициями не различаются и
-SHALL разрешаться минимумом канонической формы — включая случай несравнимых
-наборов. Внутри доставки «сохранённой» версии не существует, есть только
-порядок элементов в JSON-массиве, а он нестабилен: правило «остаётся первая
-встреченная» сделало бы исход функцией порядка на проводе. Сворачиваться между
-собой такие версии SHALL до сравнения с сохранённой, а факт «в одном теле
-приехали две версии одного ключа с разным содержанием» SHALL считаться
-**симметрично**: счётчик, зависящий от порядка элементов, наблюдал бы событие
-через раз.
+Версии одного ключа **внутри одной доставки** позициями не различаются, и
+победитель среди них SHALL быть **функцией множества версий, а не порядка
+элементов массива**: сперва отбрасываются строго покрытые кем-то из остальных,
+среди оставшихся берётся минимум канонической формы. «Строго покрыта» означает
+«покрыта другой версией и сама её не покрывает»: покрытие — предпорядок, две
+версии могут покрывать друг друга взаимно, и отбрасывание всего покрытого
+опустошило бы множество, потеряв обе. Порядок при этом обязан быть **тотальным
+до конца**: при совпавших канонических формах решает минимум исходных байтов —
+иначе победителем оказывается тот, кто стоял в массиве раньше, а порядок ключей
+в JSON от HAE нестабилен, и в хранилище легли бы разные байты при одинаковом
+содержимом. Попарная свёртка здесь
+неверна ровно так же, как она была неверна для точек: покрытие — частичный
+порядок, тай-брейк — тотальный, и вместе они дают нетранзитивное отношение
+победы, при котором `[A,B,C]` и `[B,C,A]` дают разных победителей, а порядок
+элементов в JSON-массиве нестабилен. Сворачиваться между собой такие версии
+SHALL до сравнения с сохранённой.
+
+Факт «в одном теле приехали две версии одного ключа с разным содержанием» SHALL
+считаться **симметрично** и тоже быть функцией множества: считаются кандидаты,
+чья каноническая форма отличается от формы победителя. Счётчик этот SHALL быть
+ОТДЕЛЬНЫМ от счётчика удержаний: две версии в одном теле содержания не теряют —
+победитель ложится в витрину целиком, — и одно число на два события отвечало бы
+ни на одно. На счётчик удержаний опирается единственный контроль того, что
+правило покрытия не стало слишком строгим; примесь делает его неотличимым от
+шума.
+
+Версии с совпавшей канонической формой SHALL схлопываться ДО выбора победителя.
+Выбор квадратичен по числу кандидатов, а их число приходит из чужого тела; без
+схлопывания тело в пределах приёма занимает свёртку на часы. Отбор SHALL видеть
+отмену: иначе дедлайн свёртки, заведённый ровно против зависшей работы, не
+значит ничего. Побайтовое различие при
+совпавшей канонической форме событием MUST NOT считаться — порядок ключей в
+JSON от HAE нестабилен и дребезг последнего разряда double тоже, так что
+счётчик по байтам срабатывал бы на измеренной норме потока. Различие
+**содержимого** при совпадающих множествах ключей и длинах массивов считаться
+SHALL: сегодня ровно этот случай даёт ноль и молчащий счётчик.
 
 Поля версий MUST NOT объединяться: несравнимые наборы (приехавшая принесла
 новые ключи и потеряла старые) разрешаются в пользу сохранённой и считаются
@@ -600,11 +720,11 @@ SHALL разрешаться минимумом канонической фор
 наблюдение.
 
 Исход SHALL быть функцией журнала в его порядке. Остаточный предел называется
-вслух: слияние попарное — сохранённая против приехавшей, — поэтому при
-несравнимых наборах (пункт 5) исход зависит от порядка проигрывания. Тот же
-предел есть у часового объекта, где хранится победитель прошлых слияний, а не
-все кандидаты истории; пункты 2–4 от порядка свёртки не зависят, а пункт 5
-сопровождается счётчиком и `WARN`.
+вслух: сравнение сохранённой с приехавшей попарно — в витрине лежит победитель
+прошлых слияний, а не все кандидаты истории, — поэтому при несравнимых наборах
+(пункт 5) исход зависит от порядка проигрывания. Тот же предел есть у часового
+объекта; пункты 1–4 от порядка свёртки не зависят, а пункт 5 сопровождается
+счётчиком и `WARN`.
 
 #### Scenario: Доехавший маршрут замещает тренировку без маршрута
 
@@ -639,12 +759,73 @@ SHALL разрешаться минимумом канонической фор
 - **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** две витрины различаются только тем, где проходит граница между родом
@@ -708,3 +889,123 @@ SHALL разрешаться минимумом канонической фор
 - **WHEN** отпечаток снимается, а параллельно коммитится свёртка
 - **THEN** отпечаток отражает одно состояние базы, а не смесь снимков
 
+### Requirement: Открытие базы отказывает при схеме из будущего
+
+Открытие витрины SHALL сверять версию схемы базы с версией, вшитой в бинарь, до
+наката миграций. Версия базы **выше** версии бинаря MUST быть отказом с
+указанием обеих, а не поводом мигрировать: прецедент уже записан для открытия
+только на чтение — «расхождение версий — отказ, а не повод мигрировать».
+
+Без этого откат бинаря проходит молча: старый бинарь поверх новой схемы
+стартует успешно, незнакомые секции игнорирует и доставки за окно отката
+помечает разобранными — то есть ничто не намекает, что для этого окна нужна
+пересборка. Класс «молчание», и цена его растёт вместе с ретеншеном: после
+удаления тел окно становится невосстановимым.
+
+Асимметрия относится **только к открытию с накатом миграций**: там версия базы
+ниже версии бинаря отказом быть MUST NOT — ради этого случая миграции и
+существуют. Открытие **только на чтение** сохраняет строгое равенство версий,
+как уже нормировано пересборкой: утилита, которой достаточно прочитать учёт, на
+базе старее бинаря читала бы колонки, которых там ещё нет. Ослабление этого
+отказа настоящим требованием запрещено.
+
+В одно место SHALL выноситься **чтение** версии, а не сравнение: сравнивают эти
+два способа открытия по-разному, а читают одинаково. Отсутствие журнала
+миграций (новая база) SHALL означать версию 0, и распознаваться это MUST по
+структуре базы, а не по тексту ошибки драйвера — сообщения драйвера контрактом
+не являются, и это уже записанное правило проекта.
+
+Читать версию система SHALL средствами того же инструмента миграций, которым их
+накатывает, если он это умеет: имя таблицы учёта, имя колонки и правило
+«максимум = текущая версия» принадлежат ему, и рукописная копия его приватной
+схемы разошлась бы при обновлении зависимости — причём не отказом, а тем, что
+страж перестал бы ловить. Если цена такого чтения неприемлема (например, оно
+требует записи на соединении только для чтения), копия допустима, но SHALL жить
+одной функцией с названной вслух причиной.
+
+Эксплуатационная цена отказа называется вслух, потому что она реальна: сервис не
+поднимется, а телефон шлёт непрерывно и молча, и доставка, не попавшая в архив,
+в журнал не попадает вовсе. Выбор сделан так потому, что откат бинаря — действие
+оператора, который в этот момент рядом и видит отказ сразу, а дыры плотных
+метрик закрывают широкий и глубокий проходы синхронизации. Не закрывается ими
+`stateOfMind`: у него доставки HAE единственный источник, и окно простоя для
+него — потеря без возврата. Молчаливый старт при этом стоит дороже: он портит
+витрину за всё окно отката, и узнать об этом неоткуда.
+
+#### Scenario: Старый бинарь не открывает базу из будущего
+
+- **WHEN** в журнале миграций базы стоит версия выше последней, вшитой в бинарь
+- **THEN** открытие завершается отказом с указанием обеих версий
+- **AND** миграции не накатываются
+
+#### Scenario: Новая база открывается и мигрирует
+
+- **WHEN** базы ещё нет либо журнал миграций пуст
+- **THEN** открытие проходит и накатывает миграции до версии бинаря
+
+#### Scenario: Открытие только на чтение остаётся строгим
+
+- **WHEN** версия схемы базы ниже последней, вшитой в бинарь, и база
+  открывается только на чтение
+- **THEN** открытие завершается отказом с указанием обеих версий
+
+### Requirement: Пропущенные сущности видны в учётной записи доставки
+
+Учётная запись доставки SHALL нести число сущностей, которые разбор пропустил:
+без `id`, с непомерно длинным `id`, с неразбираемой меткой времени или не
+разобравшихся как объект.
+
+Причина не в отчётности. Ретеншен сырого архива решает «что потеряется, если
+тело удалить», **по базе**, и сегодня получает ответ «терять нечего» ровно там,
+где потеряна тренировка с маршрутом: сущность в витрину не попала, список
+непокрытых секций пуст, статус `parsed`. Лог здесь не годится — он ротируется,
+а решение об удалении тела необратимо.
+
+Число SHALL замещаться целиком при каждой свёртке доставки, включая замещение
+нулём: иначе доставка, пропуски которой исчезли вместе с поумневшим разбором,
+осталась бы помеченной навсегда. Записываться оно SHALL в обоих исходах свёртки
+— и при успехе, и при отказе, если разбор успел досчитать, — тем же правилом,
+каким уже записывается список непокрытых секций.
+
+**«Не измерялось» SHALL быть отличимо от нуля, и на пути отказа тоже.** Разбор,
+вернувший ошибку, отдаёт нулевые счётчики по построению, а не по измерению;
+записать этот ноль значило бы объявить проверенной доставку, содержимое которой
+никто не смотрел. Число SHALL записываться только когда разбор досчитал; во всех
+прочих исходах колонка MUST оставаться нетронутой — той же идиомой, какой уже
+сохраняется выведенный слой. Доставки, свёрнутые разбором,
+который пропусков не считал, значения не имеют, и подстановка нуля объявила бы
+их проверенными: ретеншен получил бы то самое ложное «терять нечего», ради
+которого счётчик и заводится, — только теперь с видом измерения. Поэтому
+колонка допускает отсутствие значения, миграция его не подставляет, а читатель,
+принимающий по счётчику необратимое решение, SHALL трактовать отсутствие как
+«не удалять». Замер на живом архиве (118 тел) даёт ноль пропусков всех классов,
+то есть исторический корпус ничего не потерял, — но «ничего не потерял по
+замеру» и «проверено этим разбором» это разные утверждения, и колонка обязана
+их различать.
+
+Счётчик — производное от разбора поле: пересборка витрины SHALL начинать его
+пустым и переносить из журнала MUST NOT, иначе свежая витрина унаследует
+измерение прежнего разбора.
+
+Статус разбора от пропуска сущности меняться MUST NOT: `partial` определён
+списком непокрытых секций, и второй источник истины для него завёл бы ровно то
+расхождение читателей, которое учёт частичного разбора запрещает явно.
+
+#### Scenario: Пропущенная сущность видна в учёте доставки
+
+- **WHEN** тело несёт покрытую секцию, один элемент которой не разобрался
+- **THEN** число пропущенных сущностей у доставки больше нуля
+- **AND** соседние сущности той же секции сохранены
+
+#### Scenario: Пересвёртка без пропусков обнуляет счётчик
+
+- **WHEN** доставка с ненулевым числом пропущенных сущностей сворачивается
+  повторно разбором, который эти элементы понимает
+- **THEN** число пропущенных сущностей у доставки равно нулю
+
+#### Scenario: Доставка, свёрнутая до появления счётчика, отличима от нулевой
+
+- **WHEN** доставка была свёрнута разбором, который пропусков не считал, и с тех
+  пор не пересворачивалась
+- **THEN** её число пропущенных сущностей отсутствует, а не равно нулю
+