bug(runtime): изолировать hash/CDFI state по ИБ и не изменять ConfigDumpInfo в source tree

[zeegin]

Контекст

Связано с:

• bug(workspace): mutation tools не помечают metadata/BSL dirty и делают source↔IB round-trip небезопасным IngvarConsulting/unica#76 — безопасный mutation → build → partial dump round-trip;
• bug(build): transactional snapshot/rollback ConfigDumpInfo.xml on failed build #24 — зафиксированный global churn и отсутствие rollback для ConfigDumpInfo.xml.

Повторный анализ #24 и интеграционного сценария Unica показывает, что backup/target-scoped merge tracked-файла устраняет симптом, но сохраняет неверное владение состоянием.

ConfigDumpInfo.xml содержит внутренние id/configVersion платформы и является локальным состоянием синхронизации конкретной редактируемой конфигурации/ИБ. Методика 1С для Git исключает его из репозитория. Значения configVersion нельзя синтезировать или коллективно согласовывать.

Проблемы текущего контракта

1. Hash state не изолирован по информационной базе

ADR-0002 и ADR-0012 адресуют redb context через workPath и source-set (designer-<sourceSetName>/edt-<sourceSetName>), но не через identity ИБ.

Если тот же checkout и workPath переключить на другую infobase.connection через primary/local config, runner может повторно использовать snapshot первой ИБ и вернуть Skipped, хотя выбранная ИБ этот source ещё не получала.

2. Платформа изменяет CDFI в пользовательском source root

Designer build вызывает:

/LoadConfigFromFiles <source-root> -updateConfigDumpInfo

Платформа создаёт/перезаписывает <source-root>/ConfigDumpInfo.xml. В результате локальное состояние ИБ оказывается внутри пользовательских исходников; при двух ИБ они перетирают один файл, а при tracking через Git возникает бессодержательный churn и конфликты.

3. Build receipt не доказывает обработанные targets

Текущий BuildStep сообщает source_set, mode, ok и для partial только file_count. Точные requested/processed/skipped пути и их raw hashes отсутствуют. Интегратор не может корректно очистить target-level dirty state после partial build.

4. Incremental/partial dump пишет прямо в source

Full dump использует staging publication, но incremental и partial Designer dump направлены непосредственно в platform_target_path. Если source отличается от последнего успешно загруженного baseline, dump может молча перезаписать более новое содержимое версией из ИБ.

Дополнительно текущий Designer DSL передаёт -updateConfigDumpInfo для /DumpConfigToFiles, хотя документированный platform contract относит этот параметр к /LoadConfigFromFiles; это нужно отдельно проверить реальной platform acceptance.

Ожидаемая архитектура

Per-IB runtime identity

Ввести identity runtime-контекста как минимум из:

normalized/redacted infobase identity
+ source-set raw identity
+ canonical source root
+ source format/backend

Секреты не сохраняются: для пути/state используется стабильный fingerprint нормализованной identity.

Runtime state размещается только под workPath, например:

workPath/ib-state/<ib-fingerprint>/<source-set>/
  ConfigDumpInfo.xml
  hash-storage.redb
  transactions/

Смена connection/local overlay выбирает другой state либо явно инвалидирует прежний; она никогда не должна приводить к Skipped по snapshot другой ИБ.

Private ConfigDumpInfo lifecycle

• ConfigDumpInfo.xml не требуется в tracked source и не является source target.
• Full load выполняется через private staging source; -updateConfigDumpInfo создаёт platform-generated CDFI, который сохраняется в per-IB state.
• Partial load получает private staging source, seeded соответствующим CDFI выбранной ИБ.
• Runner никогда не публикует CDFI в пользовательский source root.
• Никакие id/configVersion не создаются и не merge-ятся вручную.
• Missing/corrupt/incompatible CDFI приводит к безопасному full bootstrap, а не к попытке partial операции.

Exact build receipt

Typed JSON result должен возвращать для каждого source set:

requested[]
processed[]
skipped[]
conflicted[]

Для каждого пути нужны raw pre/post hash и terminal status. Persisted hash state обновляется только для фактически успешно загруженных и применённых targets.

Safe incremental/partial dump

• Платформа всегда пишет в private shadow/staging.
• Runner сравнивает current source, last successfully loaded/dumped hash и shadow output.
• При divergence по умолчанию source не меняется и возвращается structured conflict.
• Явный force, если будет поддержан, публикует только полностью проверенный owner/target bundle.
• Обновлённый CDFI остаётся в per-IB state; в source публикуются только декларативные XML/BSL-файлы.

Критерии готовности

• Чистый clone без ConfigDumpInfo.xml успешно проходит full build; после операции Git tree остаётся чистым по CDFI.
• Две disposable ИБ используют один checkout/workPath и получают независимые hash/CDFI states.
• Переключение infobase.connection при неизменных source не возвращает Skipped до синхронизации новой ИБ.
• Failed/cancelled/timeout build не изменяет пользовательский source root.
• Partial build возвращает точные processed paths/hashes и подтверждает только их.
• Partial/incremental dump при source↔IB divergence ничего не записывает без явного force.
• Restart сохраняет per-IB baseline и не смешивает states разных ИБ.
• CDFI не включается в source scanner, source receipt или publication manifest.
• Acceptance выполнена на disposable file ИБ как минимум для Designer backend.

Отношение к #24

Эта задача уточняет root cause #24. Transactional rollback остаётся полезной защитой, но target-scoped merge tracked CDFI не должен становиться целевой моделью: CDFI должен быть полностью выведен из пользовательского source tree и изолирован по ИБ.

[zeegin]

Связанный Unica-side Draft PR: IngvarConsulting/unica#150

До появления private per-IB CDFI/hash state, exact path/hash receipts и shadow publication Unica временно fail-closed блокирует applied partial/incremental dump. PR не подменяет и не закрывает эту runner-задачу; после реализации #30 барьер можно заменить интеграцией с typed receipt.

[zeegin]

Unica PR IngvarConsulting/unica#150 merged with client-side interim guardrails.

Unica now blocks applied partial/incremental/unknown source dumps unless mode=full is explicit, keeps preview available, and diagnoses tracked ConfigDumpInfo.xml from staged Git-index content without deleting anything. The docs also make the ownership boundary explicit: platform-generated CDFI is per-infobase local runtime state and configVersion must not be synthesized or merged by clients.

This issue remains open and is still required for the complete solution: private per-IB CDFI/hash state under workPath, exact requested/processed/skipped/conflicted receipts with hashes, shadow/staging output for partial and incremental dumps, and divergence-safe publication into user sources. Unica #76 remains open until that end-to-end contract exists.

[korolevpavel]

Работаю над этой задачей в отдельной ветке fix/per-ib-runtime-state.

Уже реализованы изоляция runtime-state по информационной базе, точные sync receipts, приватный staging/CDFI для Designer и отложенная публикация EDT-state до успешного downstream load/apply. Сейчас завершаю безопасный dump через private shadow, трёхстороннее слияние baseline/source/dump и crash-recovery публикации.

После завершения обязательных тестов и независимых Rust-review открою pull request.

[korolevpavel]

Работа завершена, PR открыт: #39

Реализована изоляция runtime-state по информационной базе, исключена публикация ConfigDumpInfo.xml в source tree, добавлены точные receipts и транзакционные private shadows для sync/dump.

Проверено targeted Rust suites, независимыми tester/reviewer/Rust expert проходами и на реальной 1С 8.3.27: сценарии A → A(skip) → B → A(skip), bootstrap без CDFI, FULL applied и INCREMENTAL/PARTIAL conflict без изменения source и ib-state.

GitHub пока не создал Actions-run для PR из форка; падений CI нет, доступен успешный статус CodeRabbit. PR mergeable, merge state CLEAN.

[korolevpavel]

Проблема сохраняется в обезличенном downstream benchmark.

После successful full Designer build ConfigDumpInfo.xml всё ещё появился в user source tree как platform-generated churn: изменения были массовыми и unrelated к целевым объектам, поэтому downstream workflow очистил его из Git baseline. Такой же side effect наблюдался и на failed timeout attempts, что отдельно относится к rollback-сценарию #24.

Клиентские исходники, локальные пути, job IDs, строки подключения и данные ИБ не публикую. Вывод: в observed release path CDFI всё ещё не изолирован в private per-IB runtime state и продолжает загрязнять пользовательские исходники.