Рентген core 0.1.0.dev9 — проверяемые правки и аудит

Рентген core 0.1.0.dev9 — проверяемые правки и наблюдение за проектом

0.1.0.dev9 — новый prerelease локального ядра после 0.1.0.dev8. Он
поставляет накопленные возможности работы с выгрузкой 1С, ограниченного
применения правок, восстановления и аудита Git. Это выпуск компонента для
Windows x64 и CPython 3.11; полной приёмкой продукта он не является.
Архив core-v0.1.0-dev8 и его контрольные суммы остаются неизменными.

Что нового после dev8

Метаданные 1С и EDT

• Снимок умеет читать ограниченный набор EDT MDO/XML и сохранять identity,
  UUID и принадлежность объектов. CLI предоставляет привязанный к снимку
  inventory и доказательства для реквизитов каталога.
• Добавлены планирование и материализация проверяемых кандидатов
  трёхстороннего слияния. Неоднозначные изменения, смешанные корни EDT и
  Designer XML, столкновения путей и чужие XML-объявления отклоняются.
• Workspace writer создаёт отдельную принадлежащую копию, проверяет исходный
  inventory, сохраняет backup и квитанцию и поддерживает явные status, undo и
  recover. Native EDT adapter повторяет выбранный preview только в такой копии;
  опубликованная рабочая информационная база не меняется этим сценарием.
• Отдельный bounded live writer поддерживает один base Designer XML слой и
  операцию переименования реквизита каталога. Ещё один writer применяет
  запечатанное предложение к одному существующему BSL-файлу. Для обоих нужны
  зарегистрированный исходный каталог, точное совпадение ожидаемого состояния
  и явная команда на запись.

Восстановление после прерывания

• Live writers ведут журнал с привязкой к проекту, операции и исходному
  inventory. Undo проверяет фактические байты перед заменой; Recover
  восстанавливает только проверенный backup. Посторонние изменения в
  исходниках блокируют автоматическое продолжение.
• Исправлено согласование прерванных квитанций Apply, Undo и Recover.
  Корректная временная запись состояния или результата сверяется с исходной
  операцией, result ID и inventory перед завершением. Повторный Recover
  проверяет собственный staging, восстанавливает перенесённые файлы из backup
  и может продолжить после очередного прерывания. Повреждённые или
  противоречивые записи требуют разбора владельцем.
• Журнал и исходное дерево должны находиться на одном файловом томе: иначе
  атомарная замена файла невозможна, и новая live-операция отклоняется до
  записи. Эта граница действует для обоих writers.

Наблюдение, отчёты и нативные проверки

• Наблюдение за Git получило ограниченный scheduler, проверку непрерывности
  истории, привязку commit к снимку и сохранённые findings. Локальный outbox,
  owner reports, bounded SARIF и read-only BSL adapter сохраняют
  воспроизводимую цепочку доказательств.
• Добавлены контракт Windows ServiceMain/SCM, входная точка службы,
  ограниченная подготовка Git audit и ядро приёмника уведомлений с
  идемпотентностью и проверкой конфликтов. Это поставленные контракты и
  локальные сценарии; live SCM deployment и внешний HTTPS receiver ещё не
  принимались как продукционная служба.
• Для платформенных операций добавлены native archive с явными правами
  администратора и owned ibcmd fixture executor с квитанциями. Сценарии
  данных и переименования Article → SKU проверялись на принадлежащей
  синтетической базе 1С 8.3.27.2342; типовые конфигурации не квалифицированы.

Удобство и поставка

• Новые команды CLI и локального MCP дают доступ к inventory, плану,
  workspace и live status/recovery, owner reports и архивированию native-run
  при соответствующих правах. Расширение Companion 0.1.9 добавляет профиль
  для core dev9; история черновиков и проверка результата остаются привязанными
  к сохранённой ревизии.
• README получил крупную схему из шести шагов,
  которая показывает путь от выгрузки 1С до решения о применении правки.

Как устанавливать и проверять

Скачайте ZIP, manifest.json, SHA256SUMS и эти заметки из
GitHub Release.
Сверьте SHA256 ZIP с манифестом, распакуйте в новый каталог и следуйте
инструкции первого запуска.
Комплект содержит ядро, исходники, scanner, закреплённые wheels MCP, лицензии
и контрольные суммы. Python 3.11, платформа 1С, EDT, модель и доверенный CFE
YAxUnit устанавливаются отдельно. Уже работающие окружения dev8 не меняйте
поверх: для dev9 создайте отдельное окружение и профиль редактора.

Поставленные файлы должны соответствовать принятому успешному CI для точного
коммита в манифесте. Тег core-v0.1.0-dev9 указывает на этот коммит исходников;
манифест с хэшами фиксируется следующим коммитом после сборки и не меняет тег.
На локальном Windows-кандидате полный Python-набор завершился результатом
2295 passed, 3 skipped (три пропуска связаны с недоступным созданием
symlink); Node-контракты Companion — 56 passed, тесты Go scanner — успешно.
Отдельные fault injection тесты проверили прерывания Apply, Undo и Recover
перед записью исходника, временного состояния и терминального результата.
Для точного коммита d0a86f6e9ddce4372eaf4a4db37b034ca26a686e оба
запуска Product CI завершились успешно: push 35812232162
и PR 35812234924.
В скачанном отчёте push CI — 2298 Python-тестов, 0 ошибок, 0 пропусков.
Две сборки wheel/sdist/scanner совпали побайтно, установка комплекта из
закреплённых wheels без индекса прошла. Отдельная проверка скачанного ZIP
на фиксированном локальном томе подтвердила SHA256, inventory и работу
установленных CLI/MCP; доступно 32 локальных инструмента MCP.

Границы готовности

Live writer покрывает только указанные Designer XML и BSL-сценарии. Не
заявлены произвольный round-trip .cf/.cfe, полная семантика расширений,
форм и СКД, применение в рабочую ИБ через EDT/1С, внешняя concurrent CAS,
типовые конфигурации, production SCM/HTTPS deployment и интеграция Spectorn.
Результат BSL-анализа и синтетические тесты не доказывают корректность
бизнес-логики. Подробная таблица — в
границах готовности.

Послерелизная нативная проверка BSL apply/Undo — 23 сентября 2026

После выпуска я проверил точный опубликованный core 0.1.0.dev9, а не новую сборку исходников. ZIP rentgen-core-0.1.0.dev9-windows-py311.zip имеет SHA256 5615383c3985c4c3144eb636424157619dab959f0a30af7003cc8c88a21c58d9, wheel внутри — a710a72b8f9d48eef42b05099bbbbc2152b448d303ff9fc578b924134066adc2. Офлайн-установка на фиксированном локальном томе прошла с --require-hashes; установленная версия — 0.1.0.dev9. Релизный тег по-прежнему указывает на исходный commit d0a86f6e9ddce4372eaf4a4db37b034ca26a686e. Бинарные файлы релиза и их хэши не менялись.

Повторяемый verifier из commit d60e68e4adee007fa62a7febc66092f2c31ca9eb использовал принадлежащую тесту копию Designer XML и новую файловую базу на 1С 8.3.27.2342 (SHA256 1cv8.exe: 2a9ef3653367b6de29000a3a51749a19e6450134347925713c9075674e9f0956). Сначала установленный CLI подтвердил корректное предложение и диагностику заведомо ошибочного BSL. Затем proposal-live-apply записал ровно предложенный BSL. Платформа загрузила изменённое дерево, прошла /CheckConfig и /UpdateDBCfg; запуск приложения дал 43. После proposal-live-undo полный inventory исходников вернулся к прежним хэшам. Повторная загрузка и проверка прошли, приложение дало 42. UUID конфигурации и общего модуля сохранились, экспортированный BSL совпал с проверенными байтами после нормализации BOM/CRLF. В 11 нативных шагах нет ненулевого кода или таймаута; project head остался прежним, обращений к модели не было.

Доказательства: сводная машинная квитанция и raw результат verifier, SHA256 raw JSON с LF 4469070678ed693e141dd503a6146c7515d94518634cf244d49e6e9ade52b6cf. Описание сценария и границ. Изменение принято через PR #6, merge commit d584a90e5f7b2259e93f3b91981a025254fce85a, независимое read-only ревью — APPROVE.

Для точного head f92b9c2037576705d1d4b4d80b2539461f3addbb успешны push Product CI и PR Product CI. JUnit из push run сверен по GitHub SHA256 732031ce37e2e5e8f903c52abfc3e3b7ab5af14b9536006a728f69493feca01c: 2298 tests, 0 failures, 0 errors, 0 skips. Проверки Companion, Go scanner, воспроизводимой офлайн-сборки, установленного snapshot и observer тоже завершились успешно.

Граница результата: один синтетический общий модуль, одна версия платформы, собственная тестовая база. Это не приёмка типовых конфигураций, расширений, форм/СКД, внешних конкурентных writers или рабочей ИБ. Production deployment не выполнялся; весь продукт пока не объявляется готовым.