healthlog/openspec/specs/reindex/spec.md

reindex Specification

Purpose

Пересборка витрины проигрыванием журнала: import(снапшот) + replay(доставки). Витрина производна, источник истины — сырой архив тел; значит любое повреждение, включая ошибку нашего же разбора любой давности, лечится пересборкой, а не восстановлением из бекапа. Здесь живут состав журнала, порядок проигрывания, детерминированность, оракул сходимости и граница «что не восстанавливается».

Requirements

Requirement: Пересборка витрины проигрыванием журнала

Система SHALL уметь собрать витрину заново, проиграв журнал целиком: import(снапшот) + replay(доставки). Стадия снапшота в этой дельте пуста — пересборка из архива есть вырожденный случай с пустым снапшотом, — и отдельной операции «пересборка из архива» рядом с импортом экспорта заводить MUST NOT.

Проигрываться SHALL все доставки журнала, а не только те, чей parse_status говорит о неразобранности. Отбор по учётному статусу сделал бы результат функцией предыдущего прогона, а не журнала; дешевизну повторного проигрывания обеспечивает хеш-детектор объекта, а не пропуск доставок.

Пересборка собственного разбора и собственного слияния иметь MUST NOT: она зовёт тот же код, что и приём, по идентификатору доставки, и тело читает из архива тем же путём, с тем же пределом размера распакованного тела. Второй путь разбора разошёлся бы с первым молча, а другой предел означал бы, что тело, принятое со 200, вечно отказывает на каждой пересборке.

Условие сходимости SHALL называться требованием, а не оговоркой сценария. Правило слияния точек разрешает равную полноту в пользу пришедшей доставки, то есть содержимое витрины есть функция порядка свёртки, а не только множества доставок. Отпечаток пересборки равен отпечатку накопленной приёмом витрины тогда и только тогда, когда живая свёртка шла в порядке журнала. Прежде от порядка зависел только вывод слоя; теперь от него зависят значения точек, то есть цена нарушения выросла и должна быть названа здесь, а не выведена читателем.

Посылка равенства SHALL перечисляться рядом с ним, а не подразумеваться, потому что оракул, чья посылка не названа, краснеет по причине, к правилу отношения не имеющей, и краснота становится неотличимой от дефекта. Посылок три: живая свёртка шла в порядке журнала; в журнале нет доставок, чью свёртку живой путь провалил, а пересборка проведёт (статус failed); за время пересборки новых доставок не приезжало.

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

Равенство «пересборка = приём» SHALL проверяться оракулом, а не рассуждением: журнал, содержащий доставки с равнополными столкновениями, проигранный живым путём (фоновый воркер, в том числе с доставкой, отложенной занятостью базы) и путём пересборки, обязан давать один отпечаток витрины.

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

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

Scenario: Пересобранная витрина совпадает с накопленной приёмом

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

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

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

Scenario: Повторная пересборка ничего не меняет

• WHEN пересборка того же журнала выполняется второй раз
• THEN отпечаток витрины не меняется

Scenario: Разобранная доставка проигрывается наравне с неразобранной

• WHEN в журнале есть доставки со статусом parsed и со статусом pending
• THEN проигрываются обе

Requirement: Порядок проигрывания задаётся журналом

Система SHALL проигрывать доставки строго в порядке (received_at, id), а не в порядке обхода каталога архива.

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

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

Проигрывание SHALL быть последовательным. Распараллеливать его MUST NOT: слой есть функция префикса журнала, а запись часового объекта — чтение, слияние и запись обратно.

Scenario: Порядок не зависит от раскладки файлов в архиве

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

Scenario: Доставки одной секунды упорядочены идентификатором

• WHEN две доставки имеют одинаковый received_at
• THEN порядок между ними задаётся идентификатором и одинаков в каждом прогоне

Requirement: Журналом считается архив, а не таблица доставок

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

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

Для такого тела идентификатор берётся из имени файла, метка приёма — из времени создания в ULID, приведённого к UTC. Дата каталога меткой служить MUST NOT: она задаёт сутки, а порядок нужен внутри суток. Размер и хеш пересчитываются по распакованному телу — так же, как их считает приём; иначе в тех же колонках появились бы значения другой природы.

Заголовки доставки при этом восстановлены быть не могут — в архиве их нет. Подобранное тело SHALL проигрываться без них, с честной деградацией вывода слоя: наследовать не от чего и подтверждать нечем.

Строка учёта, у которой тела в архиве нет, отказом быть MUST NOT: она станет штатной, когда появится ретеншен архива. Такая строка SHALL считаться и называться в отчёте.

Файл архива, не подходящий под форму тела (чужое расширение, остаток *.tmp от прерванной записи, имя не разбирается как ULID), SHALL пропускаться и учитываться счётчиком. Молчаливый пропуск недопустим: тело есть, а в отчёте его нет. Тело, чей идентификатор уже встретился в другом каталоге, SHALL пропускаться тем же порядком: вторая запись журнала с тем же ключом сорвала бы весь прогон, то есть один посторонний файл лишал бы пересборки всё остальное.

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

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

Scenario: Тело без учётной записи подбирается

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

Scenario: Учётная запись без тела не роняет пересборку

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

Scenario: Файл, не являющийся телом, считается отдельно

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

Scenario: Повтор идентификатора не срывает прогон

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

Scenario: Каталог архива не читается

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

Requirement: Пересборка не трогает рабочую базу

Система SHALL собирать витрину в отдельный файл базы и MUST NOT записывать в рабочую базу ничего — ни объектов, ни строк учёта, ни миграций схемы.

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

Рабочая база SHALL открываться только для чтения и без наката миграций. Обычное открытие накатывает миграции безусловно, а миграции меняют и данные (та, что ввела частичный разбор, переписала parse_status у всех строк) — то есть штатный путь чтения нарушал бы запрет выше. Хуже: свежий бинарь мигрировал бы схему под работающим старым сервисом.

Расхождение версии схемы рабочей базы с версией, которую знает бинарь, SHALL быть отказом с указанием обеих версий, а не поводом мигрировать.

Scenario: Рабочая база остаётся нетронутой

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

Scenario: Отказ посреди пересборки не портит рабочую базу

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

Scenario: Схема рабочей базы старше бинаря

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

Requirement: Файл назначения и его жизненный цикл

Файл назначения по умолчанию SHALL быть соседом рабочей базы — так подмена остаётся переименованием внутри одной файловой системы.

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

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

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

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

Scenario: Файл назначения совпадает с рабочей базой

• WHEN файл назначения — тот же файл, что рабочая база, пусть и по другому пути
• THEN команда завершается ошибкой и не пишет ничего

Scenario: Файл назначения уже существует

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

Scenario: Затребованная перезапись даёт ту же витрину

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

Scenario: Прерванная пересборка не оставляет файла назначения

• WHEN пересборка прерывается на середине журнала
• THEN файла по пути назначения не существует

Requirement: База назначения пригодна к подмене

База назначения SHALL нести полноценный учёт доставок, а не только объекты витрины: подменяется файл базы целиком, а не одна таблица.

Состав переноса нормируется явно, потому что колонки delivery двух разных родов:

факты журнала   id, received_at, automation_name, automation_id, aggregation,
                period, session_id, bytes, sha256, raw_path, headers
                                              ← переносятся дословно
производные     parse_status, points, derived_layer, uncovered_sections,
                skipped_entities              ← начинаются пустыми

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

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

Производные от разбора поля MUST начинаться пустыми. Перенос derived_layer особенно опасен и незаметен: доставка, чей повторный разбор отказал (штатный исход, когда слой не выводится), сохранила бы слой прежнего разбора, и следующая доставка той же автоматизации унаследовала бы его. Витрина снова стала бы функцией предыдущего прогона, а не журнала, причём оба прогона были бы самосогласованы — проверка «повторная пересборка ничего не меняет» этого не ловит. Для числа пропущенных сущностей цена та же и хуже: пустота у него значит «не измерялось», и перенесённое число выдавало бы измерение прежнего разбора за измерение текущего — а по нему принимается необратимое решение об удалении тела.

Scenario: Учёт переносится полностью

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

Scenario: Слой прошлого разбора в наследование не попадает

• WHEN в рабочей базе у доставок проставлен derived_layer
• THEN отпечаток пересобранной витрины совпадает с отпечатком пересборки того же журнала из учёта без проставленных слоёв

Scenario: Число пропущенных сущностей не переносится из журнала

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

Requirement: Подмену рабочей базы делает человек

Система SHALL оставлять замену рабочей базы пересобранной человеку и выполнять её сама MUST NOT.

Файл базы держит открытым процесс сервиса, а переименование не касается уже открытого дескриптора: процесс продолжит писать в отвязанный inode, читатели увидят новый файл, и данные разойдутся молча. Документация SQLite называет переименование используемого файла прямой причиной порчи базы. Безопасная подмена требует остановленного сервиса, а остановить его команда не может: сервисом управляет окружение снаружи.

Отчёт SHALL печатать процедуру подмены буквально — команды, а не намёк, — и только тогда, когда прогон признан успешным (см. «Отчёт, оракул и исход команды»).

Scenario: Отчёт называет процедуру подмены

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

Requirement: Отчёт, оракул и исход команды

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

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

Отказы SHALL считаться по классам: слой не выводится, содержимое не разбирается, работа отложена по обстоятельствам, всё прочее. Невыведенный слой есть в каждом журнале и штатен; общий счётчик отправлял бы человека искать дефект там, где его нет. Отдельно называть человеку следует только нештатные отказы.

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

Число объектов «было и стало» SHALL печататься рядом с отпечатками: отпечатки отвечают «да/нет», а решение о подмене необратимо, и по «да/нет» нельзя судить о направлении расхождения. Именно пара чисел — 1737 против 1742 — поймала прошлый дефект наследования слоя.

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

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

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

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

Исход команды. Расхождение отпечатков отказом быть MUST NOT: после исправления разбора оно ожидаемо и есть сам смысл пересборки. Отказ отдельной доставки отказом команды тоже MUST NOT быть: доставка, слой которой не выводится, — штатный исход.

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

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

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

Scenario: Отчёт сравнивает отпечатки

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

Scenario: Счётчики покрывают все единицы хранения

• WHEN пересборка завершилась
• THEN отчёт печатает «до и после» отдельно для часовых объектов, тренировок, записей и строк реестра категориальных значений

Scenario: Пустой реестр рабочей витрины назван ожидаемым классом

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

Scenario: Расхождение отпечатков не является отказом

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

Scenario: Пустой журнал — отказ, а не идеальная сходимость

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

Scenario: Ни одна доставка не свернулась

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

Scenario: Приезд доставок за время прогона отменяет подмену

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

Scenario: Отчёт после отмены не сравнивает неизмеренного

• WHEN прогон отменён
• THEN отчёт не содержит ни ответа о совпадении отпечатков, ни разницы числа доставок

Scenario: Рабочей базы нет вовсе

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

Scenario: Отчёт не раскрывает данных о здоровье

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

Requirement: Отказ на одной доставке не останавливает пересборку

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

Останавливаться на первой нельзя: журнал заведомо содержит доставки, слой которых не выводится, — это штатный исход, а не поломка, и он не должен лишать пересборки остальные тела.

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

Scenario: Битое тело не срывает прогон

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

Scenario: Отмена прекращает проигрывание

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

Requirement: Отчёт пересборки показывает удержанные версии сущностей

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

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

Число SHALL печататься всегда, а не только при ненулевом значении: ноль здесь утверждение, а не отсутствие новостей.

Scenario: Удержанная версия видна в отчёте пересборки

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