bug(change-detection): full dump оставляет hash snapshot устаревшим

[korolevpavel]

Контекст

Расследование IngvarConsulting/unica#76 выявило отдельный воспроизводимый residual-сценарий для change detection в v8-runner master 7ce1b062843d86644fe55741dbe0ee79f7ca767d. Его нужно закрыть внутри #39 либо в узком successor PR, если #39 будет разделён.

В проверенном сценарии format=DESIGNER, builder=DESIGNER, configuration source-set успешный dump --mode full заменяет source tree результатом платформы, но не reconciles и не invalidates workPath/hash-storages/designer-<source-set>.redb. Snapshot продолжает описывать дерево до dump.

Из-за этого следующий ordinary build для той же ИБ и того же source-set видит собственную только что опубликованную выгрузку как внешние изменения и снова загружает её в ИБ.

Наблюдаемое поведение

Live-сценарий на macOS, 1С 8.3.27.2214, builder DESIGNER:

1. build --full-rebuild — успешно;
2. ordinary build — Skipped;
3. dump --mode full — успешно;
4. ordinary build без пользовательских изменений — найдено 36 изменённых файлов, затем выполнен долгий Full load по partial-load rules;
5. ещё один ordinary build — Skipped.

В итоговом diff также было ровно 36 файлов. Это сильная атрибуция по количеству и моменту, но не exact per-path receipt: текущий build receipt не сохраняет обработанные пути.

Детерминированный unit-level repro без платформы:

1. создать SourceSetContext и выполнить rescan_and_commit_full для дерева before;
2. выполнить успешный full dump, fake platform публикует дерево after;
3. запустить обычный build для той же пары ИБ/source;
4. ожидается BuildMode::Skipped и отсутствие platform invocation;
5. сейчас analyzer возвращает Changes::Modified, и платформа вызывается повторно.

Ожидаемый контракт

Успешный full dump устанавливает fixed point для той же runtime identity, которую должен изолировать #30/#39.

Если после публикации никто не менял отслеживаемые source-файлы, следующий ordinary build той же пары обязан вернуть Skipped и не вызывать платформу.

Нельзя просто вызвать текущий rescan_and_commit_full() после dump на master: существующий storage key не содержит identity ИБ/source root, поэтому такой commit может создать ложный NoChanges при переключении на другую ИБ. Reconciliation должен использовать identity contract #30/#39 или его узкого successor.

Atomicity / failure contract

• snapshot строится по sealed staged tree либо по доказанно опубликованным exact bytes;
• snapshot становится current только после успешной публикации того же поколения;
• platform failure, interruption/cancellation, validation failure или publication failure до commit boundary сохраняют прежние target bytes и прежнее поколение snapshot;
• interruption после зафиксированной публикации может быть deferred; current state тогда обязан целиком описывать уже опубликованное новое поколение;
• mismatch identity, generation race или ошибка reconciliation должны fail safe: следующий build не может быть Skipped.

Acceptance

• RED-тест successful full dump -> ordinary build same pair -> Skipped/no platform call;
• GREEN guard interruption before publish -> target and snapshot generation unchanged;
• regression включён в fix(runtime): isolate state by infobase #39 либо в узкий successor, использующий тот же runtime identity contract;
• ADR/spec фиксирует commit boundary dump -> snapshot, если он ещё не покрыт решением по bug(runtime): изолировать hash/CDFI state по ИБ и не изменять ConfigDumpInfo в source tree #30/fix(runtime): isolate state by infobase #39.

Граница вывода

Этот дефект доказан для рассинхронизации опубликованного declarative tree и redb snapshot. ConfigDumpInfo.xml — отдельное platform-generated состояние, scanner его игнорирует; причинная роль CDFI в 36 изменениях не доказана. Rollback/приватизация CDFI остаются отдельной задачей (#24, #30/#39).