Перейти к содержимому
EDT-Bridge
Русский
EnglishРусский
Esc
↑↓navigate↵open⌘Jpreview
На этой странице

История изменений

Что менялось в EDT-Bridge от версии к версии, с разбивкой по дням.

Заметные изменения EDT-Bridge, свежие сверху. Записи сгруппированы по дням; версии, вышедшие в этот день, перечислены в заголовке. Формат основан на Keep a Changelog, проект следует семантическому версионированию. Jar плагина и обвязка edt-bridge-mcp используют один номер версии.

06.09.2026 – 0.21.0

Добавлено

  • edt_project_errors говорит, что маркер старше своего файла. Маркер – снимок, который переживает код, ради которого был записан, и отчёт по старым маркерам читался как свежий – узнать правду можно было только через edt_clean_project с полной пересборкой: минуты на большой конфигурации ради одного модуля. Теперь у каждой выведенной проблемы есть stale, если маркер старше последнего изменения файла на диске, и unsynchronized, если рабочая область это изменение ещё не прочитала; сводка их считает, а hint говорит, что делать. refresh=true перечитывает суженную область и делает инкрементальную сборку перед чтением маркеров: секунды и на месте – там, где очистка пересобирала всё.

05.09.2026 – 0.20.0

Исправлено

  • edt_project_errors оставляет НЕСКОЛЬКО важностей: severity: "ERROR,WARNING". Одна важность – не тот вопрос, который задают: вызов несуществующего метода EDT считает предупреждением, и проверка с фильтром ERROR читается чистой над сломанным кодом. Хуже того, форма с запятой не совпадала ни с одной важностью: на живой рабочей области из 13 698 проблем она отвечала нулём – неотличимо от чистой конфигурации.

02.09.2026 – 0.19.0

Добавлено

  • edt_validate_query следит за временными таблицами пакета. Валидатор EDT проверяет каждый запрос против метаданных, а пакет – ни против чего, поэтому запрос, читающий ПОМЕСТИТЬ-таблицу, которую ни один предыдущий запрос не создаёт или которую предыдущий уничтожил, признавался валидным и падал только на платформе. Теперь мост ведёт учёт того, что каждый запрос создаёт и уничтожает, и сообщает о таком чтении с позицией: ошибка для queryText, чей текст считается самодостаточным пакетом; заметка INFO для литерала модуля, где таблицу обычно даёт общий менеджер временных таблиц или другой литерал – на большой рабочей конфигурации все 195 таких чтений в 3125 литералах оказались законными.
  • У edt_project_errors появилась краткая форма brief. По одной текстовой строке на проблему – важность, ресурс со строкой, сообщение, идентификатор проверки – под сводкой в одну строку, вместо полных объектов с extraInfo и путями, которыми прежде оплачивался вопрос “чист ли этот объект”.

Изменено

  • Страница инструментов говорит, что видит edt_project_errors. Вызов метода, которого нет в другом модуле, для EDT предупреждение (SU239), а не ошибка – ошибка только у неопределённого вызова без имени модуля, – а modulePath достаёт одни маркеры Eclipse, поэтому проверка сгенерированного кода читает предупреждения и сужает через fqn. Замерено на живой модели, где такой вызов выглядел чистым.

30.08.2026 – 0.18.1

Изменено

  • Описание пакета называет то, что даёт мост. Сводка на карточке PyPI описывала одну обвязку – посредника до работающей EDT – и молчала про диагностики, метаданные, валидацию запросов, инструменты записи, информационные базы и отладчик за ней.

28.08.2026 – 0.18.0

Добавлено

  • Плагинам доступен живой мост. Обработчик плагина, объявивший параметр bridge – handler(arguments, bridge), – получает функцию: один вызов инструмента работающего моста, в ответе текст его результата. EDT ради этого не запускается: без моста функция поднимает исключение с внятным сообщением, и плагин отвечает запиской, а не вешает вызвавшего на минуты headless-старта. Функцию передают оба пути диспетчеризации – MCP-сервер и call из командной строки. Именно это позволяет плагину документации искать по обоим корпусам сразу: книги, которые он несёт с собой, плюс синтакс-помощник за мостом – одним поиском.
  • self-update обновляет и плагины обвязки. Каждый пакет с точками расширения edt_bridge.tools обновляется через pip из источника своей установки – git-репозитория (читается из direct_url.json по PEP 610) либо реестра пакетов по имени проекта; адрес реестра задаёт EDT_BRIDGE_PLUGIN_INDEX. Дорога к pip выбирается по окружению: pipx runpip для pipx-окружения (работает и на venv от uv, где модуля pip нет), иначе собственный pip окружения; в отличие от самой обвязки, у плагина нет exe, который держал бы работающий клиент, поэтому путь через pip здесь безопасен. --plugins-only ограничивает запуск плагинами; по каждому печатается имя: было -> стало.

27.08.2026 – 0.17.0

Добавлено

  • Обвязка принимает плагины. Внешние пакеты, установленные в окружение обвязки (pipx inject edt-bridge-mcp <пакет>), объявляют инструменты MCP через группу точек расширения edt_bridge.tools; обвязка перечисляет их рядом с инструментами моста и выполняет сама – они отвечают даже тогда, когда ни одна EDT не запущена. Это дом для того, чему не место в публичном репозитории: справочных материалов под чужой лицензией, инструментов, завязанных на внутренний сервис. Команда plugins показывает, что подключено и почему сломанный плагин не загрузился; EDT_BRIDGE_NO_PLUGINS=1 выключает поиск. Несработавшая точка расширения, повтор имени инструмента и имя, затеняющее собственные инструменты обвязки, громко отвергаются при обнаружении – кроме самого MCP-сервера, который продолжает обслуживать мост и сообщает о сбое в stderr, а не умирает вместе со всеми инструментами.

26.08.2026

Добавлено

  • edt_validate_query берёт запрос из самого модуля. Вместо вставки текста можно назвать модуль (modulePath, при желании один method): мост достаёт из живой модели литералы запросов с обрамлением |, снимает обрамление и проверяет каждый – проверенный текст не может разойтись с тем, что лежит в модуле, а один вызов покрывает все запросы модуля. Что считается запросом, сужено сознательно: многострочный литерал с обрамлением, чьё первое слово – ВЫБРАТЬ или SELECT; однострочная подпись до валидатора не доходит, куски запроса, собираемого конкатенацией, не подходят никогда.

23.08.2026 – 0.15.0, 0.16.0

Добавлено

  • edt_add_form_handler регистрирует обработчик события формы или её элемента – ту запись handlers в Form.form, без которой платформа процедуру не вызывает. Список допустимых событий берётся у EDT, а заготовка, которую инструмент может записать, несёт сигнатуру и директиву самого события.
  • edt_modify_form_item переименовывает элемент (newName) – раньше это было нечем сделать: edt_rename работает по метаданным, а не по частям формы.
  • Учётные данные информационной базы – в схеме edt_infobase_sessions: infobaseUser и infobasePassword читались, но не объявлялись, и найти их вызывающему было негде.

Изменено

  • Инструменты форм сошлись на одном имени параметра – formFqn. edt_form_structure и edt_form_render звали его fqn, а всё, что форму пишет, – formFqn; расхождение было косметическим, пока аргумент вне схемы не начал отменять вызов. Прежнее имя по-прежнему читается, а в ответах рядом со старым ключом fqn появился formFqn.

Исправлено

  • shutdown видит сеанс, у которого замолчал порт. CLI переживает framework, который в нём работал, и держит блокировку воркспейса, а ответ был “нечего останавливать” – следующий запуск падал на блокировке, которую никто не искал.
  • --json-file принимает файл с меткой порядка байтов – именно такой пишут оболочки Windows по умолчанию.
  • edt_dump_external_object уходит на дисковый маршрут, когда отказал штатный дампер – на объекте, привязанном к базовой конфигурации, всё кончалось отказом, – и возвращает автогенерацию выгрузок, если отказ её выключил. route задаёт маршрут явно.
  • scripts/sync-docs.mjs переносит перевод строки CRLF – раньше начальный блок страницы попадал в блок README, и тот выглядел устаревшим.
  • Аргумент, которого нет в схеме, отменяет вызов. Раньше он молча отбрасывался: удаление, заказанное с deleteContents, оставляло файлы на диске и отвечало как о сделанном. Отказ называет близкое имя и перечисляет принимаемые аргументы.
  • Скрипты запуска называют установку, из которой стартуют. Установок EDT на машине несколько, скрипт выбирает её сам, а подменённый jar лежит в dropins той, которую записали: правка, ушедшая в другую установку, выглядела как несобравшийся jar. run-headless.ps1 и run-gui.ps1 печатают установку, её dropins, имя и время jar моста, предупреждают, когда jar два (Equinox грузит произвольный) и когда собранный в build/ новее установленного.

17.08.2026 – 0.14.0

Добавлено

  • Объектные типы в грамматике реквизита формы – ВнешняяОбработкаОбъект.X, СправочникОбъект.X и остальная семья теперь разбираются, то есть основной реквизит формы можно добавить инструментом. Раньше разбирались только ссылочные типы, а edt_add_form_attribute отвечал “type does not parse”: реквизит, через который форма дотягивается до модуля объекта, приходилось дописывать в Form.form руками.

Исправлено

  • Заголовок таблицы больше не тиражируется в каждую сгенерированную колонку. EDT передаёт дескриптор нового элемента каждой колонке, которую порождает из связанного реквизита, поэтому таблица с заголовком “Курсы валют” выходила с этой же надписью у всех колонок. Теперь таблица создаётся без заголовка и получает его следом, а колонки сохраняют штатный заголовок EDT.

16.08.2026 – 0.13.0

Добавлено

  • edt_import_project – зарегистрировать в workspace СУЩЕСТВУЮЩИЙ каталог проекта, программный аналог “Импорт существующего проекта”. Этого шага не хватало в цикле создать–поработать–удалить: второй проект – БАЗОВЫЙ, с которым сверяется расширение в режиме изменения и контроля, взятый из worktree целевого релиза, – добавлялся только руками в интерфейсе. Своё имя позволяет держать рядом два чекаута одного репозитория, на диске ничего не переписывается.
  • Все переменные EDT_BRIDGE_* описаны – двумя таблицами на странице установки: что читает обвязка при своём запуске и что читает плагин внутри EDT, у каждой строки флаг или свойство запуска и значение по умолчанию. EDT_BRIDGE_PORT_SCAN и EDT_BRIDGE_WINDOW_WAIT не были названы вообще нигде, остальные жили только в README обвязки, вне сайта.
  • Сторож документации – scripts/docsguard.py, его гоняет набор тестов обвязки, а значит и CI. Он валится на инструменте без строки на странице инструментов, на упоминании инструмента, которого больше нет, на переменной, которую код читает, а документация не называет, на протухшем блоке в README и на картинке, за которой нет файла. Каждое замечание провоцируется тестом: проверка, тихо переставшая что-либо находить, выглядит ровно как чистый репозиторий.

Изменено

  • У каталога инструментов один источник. Он вёлся руками и в README, и на странице сайта; теперь источник – docs/tools*.md, а scripts/sync-docs.mjs вставляет его в README между маркерами, на обоих языках.
  • Схемы следуют теме читателя. Палитра переехала в переменные CSS с ветвью prefers-color-scheme, поэтому на сайте картинка совпадает со страницей вокруг неё. README по-прежнему получает PNG, но какую палитру несёт этот PNG, больше не решает машина, которая его рисует: scripts/render-diagrams.py (взамен render-diagrams.sh) закрепляет палитру перед снимком.
  • Схема архитектуры открывает главную страницу – раньше до неё можно было добраться только из README на GitHub, странное место для картинки, объясняющей всё устройство.
  • Страница безопасности перестала повторять себя. На ней был список из README, а следом модель угроз, пересказывающая его же, и ссылка обратно в README “за полной картиной”. Список теперь один, а настройки порта ведут к переменным окружения.

Исправлено

  • edt_clean_project больше не объявляет число замечаний окончательным до того, как отработали проверки. Он ждал, пока счётчик перестанет меняться, но проверки EDT не входят в семейства заданий сборки, которых он дожидается: сразу после очистки счётчик стоит на нуле просто потому, что ничего ещё не сообщено, а “0 замечаний, устаканилось” – худший из возможных ответов: за этим числом и звали очистку. Теперь ожидание требует ещё и покоя workspace, а в ответе видно, работали ли проверки вообще.
  • edt_build_extension создаёт каталог файла, который пишет. ibcmd его не создаёт, а его отказ читается как проблема сборки, а не как отсутствующая папка. В сухом прогоне теперь названо, какой каталог будет создан.
  • Схема поставки не понимала тему читателя на странице инструментов. Страница вставляла PNG – тот файл, у которого палитра закреплена ради README, – и читателю в светлой теме доставалась тёмная картинка. Теперь страница показывает SVG, а вставляемая в README копия получает PNG подменой в scripts/sync-docs.mjs: источник один, на каждой поверхности свой файл. Сторож это судит – такую оплошность не видно, пока кто-нибудь не откроет страницу в другой теме.
  • Копия каталога инструментов в README разошлась со страницей сайта – у edt_designer_agent появились уборка и остановка по простою, а собственный инструмент обвязки edt_open_gui там не значился вовсе. И то, и другое было только на сайте; теперь это один текст.

07.08.2026 – 0.12.0

Добавлено

  • edt_project_errors называет каталог диска за каждым проверенным проектом (объект locations отчёта; о нём же говорит описание инструмента). Модель проверяет ЗАРЕГИСТРИРОВАННЫЙ каталог, и правящий параллельный чекаут тех же исходников получал правдоподобный отчёт про ЧУЖОЕ дерево – молча, имена файлов ведь совпадают. Теперь расхождение видно в самом отчёте.
  • edt_symbol_info отвечает вычисленными типами локальной переменной. Ссылка на переменную (даже присвоенную строкой выше) давала types: [], хотя ховер редактора типы показывал: переменная половина системы типов ВЫВОДИТСЯ, а голая загрузка ресурса состояний типов не несёт. Инструмент теперь ставит древесную систему типов на модуль по требованию (один проход вывода на запрос) и считает по фактическим окружениям модуля. На имени вызываемого метода ответ несёт ещё и invocationTypes – вычисленные типы самого вызова рядом с ОБЪЯВЛЕННЫМ типом возврата доступа; ровно до них раньше добирались, тыкая в запятые и закрывающие скобки.

Изменено

  • Сборка из исходников сама подбирает JDK под бандлы EDT. Новые версии EDT несут class-файлы Java 25, и компиляция против такого пула требует JDK, умеющего их читать: скрипт сборки теперь читает уровень class-файлов из пула и сам находит подходящий JDK – включая установленный рядом с EDT, – а не умирает на слишком старом JAVA_HOME. Jar по-прежнему собирается под Java 17, поэтому одна сборка грузится и в версиях EDT на Java 17.

31.07.2026 – 0.11.2

Исправлено

  • self-update сразу после релиза больше не пропускает его. Список файлов обвязки брался из JSON-метаданных PyPI – кэша, который догоняет публикацию минутами: в этом окне команда отвечала “уже актуально”, а с явной версией – “нет колеса”, потому что файлы читались из того же отстающего документа. Теперь список берётся из SIMPLE-индекса (PEP 691), последняя версия ранжируется численно (0.9.0 раньше 0.11.1, без предрелизов и отозванных файлов), а JSON остался запасным путём для индекса, который PEP 691 не понимает. Затронута только половина с обвязкой – jar по-прежнему приходит из ассетов релиза GitHub, а там такого кэша нет.

31.07.2026 – 0.11.1

Исправлено

  • self-update --from принимает корень репозитория. Обвязка живёт в подкаталоге python/, и команда требовала именно его: переданный корень - а его передают естественно - получал ответ “no edt_bridge_mcp package”, и очевидная команда превращалась во вторую попытку. Теперь проверяются все три расположения, а каталог без пакета сообщает, где именно искали.

30.07.2026 – 0.11.0

Добавлено

  • edt_open_gui – передача воркспейса от headless EDT к клиентской. Чтобы получить окно EDT, приходилось искать 1cedtcli в диспетчере задач, снимать его и запускать EDT руками: мост умел остановить свою EDT, но не открыть следующую. Инструмент останавливает headless, дожидается, пока его процессы действительно исчезнут, и запускает клиентскую EDT на том же воркспейсе. Один /shutdown такую сессию не завершает, что показала живая проба: каркас OSGi останавливается, порт замолкает, а 1cedtcli продолжает работать - он запущен с keepalive-трубой на stdin. Поэтому следом закрывается keepalive-обёртка: это не убийство EDT (та уже остановила себя сама), а закрытие трубы, которой держится процесс, после чего CLI получает EOF и выходит. Ждать порт недостаточно – он замолкает, пока среда ещё держит блокировку воркспейса, и именно этот остаток потом ищут руками; force снимает то, что не завершилось в срок, первой - keepalive-обёртку: она родитель CLI, и убийство дерева снизу до неё не достаёт. Инструмент отдаёт ОБВЯЗКА, а не мост: инструмент внутри EDT не может отчитаться об EDT, которую сам же завершил. В шелле – edt-bridge-mcp gui.
  • Окно выводится ВПЕРЁД, а повторный вызов команды поднимает его снова. У отсоединённого процесса нет прав на передний план: рабочее место открывалось позади всех окон, и это неотличимо от “не запустилось вовсе”. Запуск больше не отсоединяется, а окно ищется обходом дерева процессов запускателя: оно принадлежит javaw, которую тот поднимает, а javaw живёт в том JDK, который разрешила установка, – вовсе не обязательно внутри каталога EDT. Большой воркспейс грузится минутами, поэтому ожидание окна ограничено (EDT_BRIDGE_WINDOW_WAIT, 90 секунд), и промах сообщается, а не пережидается.

Исправлено

  • На локализованной Windows обвязка не видела ни одного процесса EDT. tasklist отвечает в OEM-кодировке консоли, а обвязка декодировала вывод как UTF-8: декодирование падало в потоке чтения и оставляло список ПУСТЫМ, что все вызывающие читали как “процесса нет”. Поэтому защита, запрещающая поднимать headless при запущенной клиентской EDT, на такой машине не срабатывала никогда, и вторая EDT стартовала на заблокированный воркспейс. Вывод декодируется кодировкой консоли.

27.07.2026 – 0.10.0

Добавлено

  • Агенты конфигуратора убирают за собой. Каждый агент пишет в свой /AgentBaseDir – каталог, который штатная остановка удаляет, а падение оставляет, – след с именем базы, процессом и идентификатором сеанса, который он открыл в кластере. Найдя такой след с мёртвым процессом, мост завершает ИМЕННО ЭТОТ сеанс и убирает каталог: сеанс упавшего агента держит БЛОКИРОВКУ КОНФИГУРИРОВАНИЯ базы, и до сих пор следующий вызов падал с “Ошибка блокировки информационной базы для конфигурирования”, пока сеанс не находили и не снимали руками. Принадлежность ДОКАЗЫВАЕТСЯ следом, а не угадывается по хосту и пользователю сеанса: EDT поднимает собственных агентов конфигуратора, со стороны кластера они неотличимы от наших, и очевидная эвристика завершила бы конфигуратор самого разработчика. Уборка идёт перед каждым запуском агента и по требованию – edt_designer_agent action=sweep; action=list показывает остатки, а stopRunning=true останавливает и живых агентов прежнего запуска моста (по умолчанию выключено).
  • Простаивающий агент останавливается сам. Стоящий агент серверной базы всё время своей жизни занимает клиентскую лицензию и сеанс конфигуратора, а на стенде с малым пулом это место, отнятое у человека. Настраивается через edt.bridge.agent-idle-minutes / EDT_BRIDGE_AGENT_IDLE_MINUTES / настройку agentIdleMinutes: по умолчанию 30 минут, off или 0 выключают – как и НЕРАСПОЗНАННОЕ значение, сознательно: опечатка не должна молча сокращать жизнь агента. Вызов в работе всегда важнее: жнец берёт блокировку агента и держит её всю остановку, поэтому операцию нельзя оборвать на середине. edt_designer_agent action=list показывает время простоя каждого агента и настроенный таймаут.

Исправлено

  • Остановка агента больше не оставляет его сеанс в кластере. Вежливое завершение запрашивалось, и процесс тут же убивался, не успевая закрыть соединение с базой, – то есть каждая остановка производила ровно ту сироту, о которой сказано выше; убитый процесс вдобавок держал открытым собственный лог, и каталог агента тоже оставался. Теперь процессу дают уйти самому (20 с) и убивают только после этого, а если убить всё же пришлось – сеанс завершается явно.

24.07.2026 – 0.9.0

Добавлено

  • edt_infobase_maintenance – окно обслуживания вокруг обновления конфигурации базы данных, через rac: begin поднимает scheduled-jobs-deny (по запросу и sessions-deny с кодом доступа), ждёт, пока в списке сеансов останутся только разрешённые приложения, и отвечает “clear to update”; end опускает флаги; status только отчитывается. Смысл: на живой базе сеансы BackgroundJob пересоздаются каждую минуту, и завершать их бесполезно – с поднятым флагом они иссякают сами за минуту, убивать никого не нужно. Проверено вживую на кластерной базе: поднятый флаг остановил пересоздание и задания иссякли сами; опущенный вернул очередь за секунды. Агент конфигуратора этого не умеет вовсе – в его SSH-клиенте нет операции для флагов запрета, – поэтому путь rac, и инструменту нужен администратор базы.
  • Справочник команд и его генератор под тестами (python/tests/test_cli_docs.py): каждый аргумент описан, русский прогон действительно русский, языковые версии различаются, каждая команда покрыта разделом страницы и отвечает на --help за отведённое время, а закоммиченные страницы равны выводу генератора. Сам генератор получил недостающий таймаут – команда, не разбирающая --help, поднимает сервер и виснет.
  • edt_add_route предупреждает о конструкции, которая не загрузится: СОБСТВЕННЫЙ шаблон URL у ЗАИМСТВОВАННОГО сервиса расширения EDT принимает и молча сериализует, но платформа отказывается загружать его в режиме совместимости расширения 8.5.1 и ниже. Ответ теперь несёт serviceAdopted, compatibilityMode расширения и предупреждение ровно об этом – раньше отказ всплывал только на загрузке в базу, далеко от инструмента, писавшего маршрут.
  • edt-bridge-mcp shutdown – штатное завершение EDT, обслуживающей мост, вместо убийства её процессов. Обвязка шлёт мосту новый /shutdown (под токеном), тот останавливает OSGi-фреймворк по порядку: .lock рабочей области освобождается для запуска GUI, а агенты конфигуратора, которые держит сама EDT, закрываются корректно – их сеансы уходят из кластера вместе с ними, тогда как убитый процесс оставляет сеанс держать конфигурационную блокировку. GUI EDT без --force получает отказ, чтобы скрипт случайно не закрыл чьё-то окно; shutdown без работающего моста – тихая пустая операция.

Изменено

  • Применённое edt_infobase_sessions terminate отвечает идентификаторами завершённых сеансов (и terminatedCount) вместо полного списка: список снимался до завершения, и завершённые сеансы выглядели в нём живыми – а на живом кластере ответ тонул в шуме. list, dry-run и частичный сбой список сохраняют.
  • edt_delete_object говорит в описании то, чему научил живой прогон: построение каскада удаления анализирует ссылки по всем открытым проектам – в workspace с большой конфигурацией это минуты, и операция доходит до конца, даже когда клиент перестал ждать. Пятиминутное “зависание” первого удаления в проекте расширения было ровно этим: каскад доработал в фоне и оставил модель чистой.
  • edt_update_infobase (transport=edt) говорит, что поедет следом: у синхронизации EDT нет границы “один проект” – база приводится в соответствие ВСЕМ ассоциированным с ней проектам workspace, а конфигурационный проект тянет свои проекты-расширения по зависимости. Ответ перечисляет их в syncProjects, план называет поимённо, а обновление нескольких проектов несёт предупреждение со ссылкой на transport=agent для загрузки одного. Раньше обновление из основной конфигурации молча утаскивало два посторонних проекта-расширения.
  • Агент конфигуратора ФАЙЛОВОЙ базы останавливается сразу после операции: живущий агент держал базу открытой, и следующий пакетный конфигуратор – или человек, открывающий Конфигуратор, – получал отказ “база уже открыта”. Серверная база держит агента между вызовами, как раньше; переподключение к локальному файлу дёшево, блокировка – нет.
  • Отказ “Ошибка блокировки информационной базы для конфигурирования” несёт подсказку: обычный виновник – Designer-сеанс погибшего агента (кластер хранит сеанс, сеанс держит блокировку, а текст платформы туда не указывает). Подсказка называет edt_infobase_sessions как выход.

Исправлено

  • Агент сам переподключается, когда реструктуризация базы роняет соединение процесса с ИБ: “Соединение с информационной базой не установлено” – это отказ ДО выполнения команды, поэтому каждая операция через агента теперь один раз переподключается и повторяет себя, а не падает – прежде этот ответ стоил ручного повтора после каждой тяжёлой операции (замерено: пять раз за вечер). Прочие ошибки проходят как раньше.
  • edt_infobase_sessions падал “Ошибка разбора параметра: –infobase-user”, когда передавались реквизиты информационной базы: rac session list принимает только --infobase и --licenses, аутентификации базы у него нет вовсе. Реквизиты туда больше не передаются (и инструментом не объявляются) – они принадлежат операциям, которым действительно нужны.
  • Сообщения об ошибках агента больше не топят диагноз в лицензионном дампе платформы: один отказ приезжал десятками килобайт – полный перечень оборудования, повторённый на каждый файл лицензии и каждую стадию поиска, и ещё раз обёрнутый SSH-клиентом. Шлюзы теперь выбрасывают инвентарные строки и повторы (с пометкой “N строк опущено”); обычные сообщения проходят нетронутыми. Замер вживую: ~25 КБ -> 2.4 КБ, первая строка сразу говорит “нет лицензии”.
  • Платформа говорит на двух языках, и мост теперь слышит оба: каждый распознаваемый ответ – отказ конфигурационной блокировки, ответ агента “соединение не установлено” (он запускает автопереподключение), “расширение не найдено”, запрос учётных данных ibcmd – сверяется и с английской формулировкой, и с русской; обе взяты из ресурсных файлов самой платформы. Прежняя английская догадка распознавателя ibcmd (“authentication is required”) исправлена на настоящую строку платформы (“Authentication in the infobase is required…”), мимо которой она промахивалась.

22.07.2026 – 0.8.0

Добавлено

  • Справка CLI обвязки стала двуязычной. Каталог i18n (ru/en, язык из EDT_BRIDGE_LANG, иначе локаль) покрывает описания флагов и команд, usage, эпилог, встроенные строки argparse и рукописную справку self-update. Ответы инструментов агенту остались английскими – это протокольная поверхность плагина, а не текст для человека.
  • edt_project_errors сообщает sourceType маркера и его extraInfo – именно это различает два семейства проверок: документированные приходят из фреймворка стандартов, а короткий код вроде SU200 – из собственной проверки метаданных EDT.
  • edt_check_info распознаёт короткий код и объясняет, что это, вместо ответа “ничего не найдено”. Никакого соответствия “код – идентификатор” внутри движка проверок, как предполагалось в 0.7.1, нет: семейства просто разные, и путь к описанию – совпадение по заголовку.

Исправлено

  • run-headless.ps1 отказывался стартовать, если существовал любой процесс графической EDT, включая уже закрываемый. Теперь проверяются настоящие конфликты – порт, замок воркспейса, общий каталог dropins. Рядом всплыли два: -Port менял только опрашиваемый порт, поэтому нестандартный порт поднимал второй сервер на 8770; и воркспейс без проектов объявлялся неготовым, хотя сервер работал.

21.07.2026 – 0.6.0, 0.7.0, 0.7.1

Добавлено

  • Агент конфигуратора как третий транспорт к информационной базе. Запущенный с /AgentMode, он держит открытый сеанс и принимает команды по SSH – и входит в базу под учётной записью пользователя, чего не могут ни синхронизация EDT, ни ibcmd. Серверная база, спрашивающая, кто к ней пришёл, стала достижима, вместе с расширениями. Один агент на базу, переиспользуется; edt_designer_agent показывает и останавливает.
  • edt_infobase_config_state – ждёт ли обновление конфигурации базы данных? Отвечает сама платформа: обновление запускается, а подтверждение ему отказывается, поэтому ничего не применяется, а ожидающие изменения возвращаются списком.
  • edt_update_database_config – применяет конфигурацию базы данных. Загрузка проекта этого не делает, и до применения каждый сеанс выполняет прежний код – именно так выглядит свежий HTTP-маршрут, отвечающий 404. sessionTermination=force проходит запрет / завершение / применение одним вызовом.
  • edt_infobase_sessions – сеансы кластера через rac: перечислить и завершить. Ни агент, ни ibcmd до них не дотягиваются. Понадобилось из-за тупика: убитый, а не закрытый конфигуратор держит замок конфигурации, и дальше любая операция падает так, будто базу конфигурирует кто-то ещё.
  • edt_delete_extension – снять расширение с базы, шаг, замкнувший односторонний жизненный цикл. Требует force поверх apply.
  • edt_infobase_dump – выгрузить базу в .dt через ibcmd: та самая резервная копия, которой место перед применением конфигурации.
  • edt_update_infobase принимает transport=agent: XML конфигуратора уходит прямо в базу, без временной базы и без .cf посередине – это и делает путь пригодным для конфигурации на миллион объектов.
  • edt_extension_properties принимает infobase и идёт через агента – только так расширения серверной базы вообще достижимы.
  • edt_add_route – добавить маршрут в HTTPService. Раньше это означало править .mdo руками и сочинять uuid блока urlTemplates и вложенного methods.
  • Инструменты поверх ibcmd принимают учётные данные информационной базы рядом с данными СУБД. Без них ibcmd спрашивает имя пользователя в стандартном вводе – для неинтерактивного вызова это зависание, а не ошибка, и EOF он игнорирует (134 МБ приглашений за 60 секунд, замерено). Вывод теперь читается порциями, а процесс снимается, как только приглашение появилось.
  • Инструменты поверх агента адресуют базу, которой EDT не знает: srv\база или каталог файловой.
  • У каждого вызова ibcmd свой рабочий каталог; иначе они запирают один и тот же, и следующий вызов где угодно падает.

Изменено

  • edt_project_errors умеет отвечать на вопрос “что не так с модулем, который я только что правил”. Раньше он принимал имя проекта и возвращал всё – на большой конфигурации это 13 850 замечаний и ~5 МБ. Появились fqn / modulePath, severity и countOnly, а также total, bySeverity, bySource и ограничение списка.
  • edt_module_text принимает includeMethods (по умолчанию true): запрос одного метода больше не тянет за собой весь перечень модуля – 147 методов на одном рабочем модуле, и так при каждом чтении.
  • edt_module_text, edt_add_method и edt_delete_method понимают HTTPService.X и WebService.X: все три страдали от одного пробела в карте каталогов.
  • В таблицах инструментов README появился раздел про всё, что говорит с запущенной базой, с явным указанием транспорта – что чем достижимо, читателю нужно в первую очередь. Обе схемы перерисованы.
  • Набор тестов обвязки и workflow ci (Linux и Windows, 3.10 и 3.12), который оба релизных workflow вызывают первым, поэтому красные тесты останавливают релиз. Ядро набора – три регрессии, которые реально уехали в релиз.
  • Тесты JUnit для той части плагина, что не зависит от EDT: она вынесена в ...edtbridge.core, поэтому её собирает и проверяет обычный JDK.

Исправлено

  • self-update оставлял старый jar в dropins, когда релизный уже лежал там, – а две копии одного бандла и заставляют Equinox взять произвольный.
  • Схемы потеряли прозрачные углы; scripts/render-diagrams.sh теперь фиксирует флаги, которые это решают, – рецепт до сих пор нигде не жил.

19.07.2026 – 0.3.0, 0.3.1, 0.4.0, 0.4.1, 0.5.0

Добавлено

  • Формы целиком: edt_add_form создаёт управляемую форму штатным генератором EDT – тем самым, что стоит за мастером “Новая форма”. Элементы (edt_add_form_item и пара на изменение и удаление) идут через службу, которую вызывает сам редактор форм, поэтому имена, идентификаторы, фактический тип поля и автозаполнение колонок таблицы решает EDT. Так же и реквизиты с командами: edt_add_form_attribute и edt_add_form_command со своими парами, идентификаторы из штатной службы, заготовка обработчика пишется в модуль формы. Удаление перечисляет, что ещё ссылается, и требует force.
  • edt_adopt_object – заимствовать объект базовой конфигурации в расширение штатным адаптером EDT. Без него созданный проект расширения останавливался на полпути: перехват метода требует, чтобы владелец был заимствован.
  • edt_search_modules – полнотекстовый поиск по модулям проекта. Чтение идёт через буферы Eclipse, поэтому открытый в редакторе модуль ищется в том виде, в каком он сейчас, вместе с несохранённым.
  • edt_clean_project – сбросить результаты сборки, чтобы проверки прошли заново, программный аналог “Очистить” в EDT. Иначе устаревший маркер переживает код, который его вызвал.
  • edt_delete_project – удалить проект из воркспейса через Eclipse, чтобы обновилось дерево ресурсов; удаление папки руками оставляет призрачный проект, занимающий имя.
  • edt_extension_properties – читать и задавать то, что расширение несёт внутри базы (безопасный режим, защита от опасных действий, активность, область). Свежезарегистрированное расширение получает безопасный режим и защиту включёнными, а расширение, меняющее методы базовой конфигурации, ни под тем, ни под другим не работает.
  • edt_build_extension и edt_update_infobase сообщают changesMethods и, если он истинен, называют два флага, которые должны быть сняты.
  • Обвязкой edt-bridge-mcp можно управлять из шелла: call <инструмент>, tools, status. Раньше всё вне MCP-клиента означало писать своего клиента к порту 8770. Коды возврата разводят “вызов не состоялся” (1) и “инструмент отработал и вернул ошибку” (2).
  • self-update --from <каталог> ставит обвязку из локальной сборки вместо PyPI.
  • Инструменты платформы и баз: edt_platform_installations, edt_register_platform, edt_create_infobase, edt_build_extension (сборка .cfe через ibcmd).
  • edt_metadata_details сообщает флаги компиляции общего модуля и состав плана обмена – за тем и другим раньше приходилось идти в .mdo на диске.
  • edt_create_external_object принимает scriptVariant: EDT по умолчанию делает отдельный проект английским, из-за чего сгенерированные члены выходили как Object, а не Объект.
  • Страница настроек EDT-Bridge (токен, порт, переключатель evaluate), чтобы графическая EDT, запущенная обычным ярлыком, умела пускать инструменты записи.

Исправлено

  • edt_create_extension создавал проект, который не принимала ни одна база: загрузка падала с “Загрузка не должна менять принадлежность основного объекта конфигурации”. Корневой Configuration строился фабрикой метаданных, а она даёт обычную полную конфигурацию. Теперь корень – заимствованная базовая конфигурация, тот же шаг, что делает штатный мастер, и движок пишет всё, что расширению положено. Заодно закрылись два следствия: заимствованные объекты несут uuid-связь с базовым объектом вместо привязки по имени, а язык базовой конфигурации приходит вместе с ней.
  • edt_dump_external_object снова собирает .epf/.erf там, где EDT не может: она берёт самую свежую сборку линейки, поэтому линейка с тонкими клиентами наверху падала с MatchingRuntimeNotFound. Появился путь через диск, а сухой прогон перестал врать про него.
  • Модули внешних объектов разрешаются по FQN – ExternalDataProcessor и ExternalReport просто отсутствовали в карте каталогов.
  • self-update не мог обновить обвязку на свежем pipx: в venv, собранном через uv, вообще нет pip. Установщик больше не используется – колесо распаковывается поверх пакета средствами стандартной библиотеки.
  • Обвязка два релиза сообщала устаревшую версию: __init__.py нёс литерал, который pyproject.toml не использовал. Теперь версия пакета берётся из этого одного атрибута.
  • MCP-сервер сообщает собственную версию плагина из манифеста бандла, а не захардкоженную строку, поэтому дашборд и хендшейк не могут разойтись.
  • Обвязка фиксирует UTF-8 в стандартных потоках. На Windows они по умолчанию брали кодовую страницу ANSI, и “→” в описании инструмента рвал tools/list – клиент не регистрировал ни одного инструмента.
  • edt_infobases раскрывает группы, поэтому сгруппированные и серверные базы больше не теряются.

Изменено

  • Внутреннее: единый шлюз к модели разбит на шлюзы по областям (проект, чтение и запись метаданных, формы, платформа, отладка, BSL, документация). Чистый рефакторинг.

18.07.2026 – 0.1.0, 0.1.1, 0.2.0, 0.2.1

Добавлено

  • Полный цикл создать / разработать / собрать / доставить по MCP, инструменты записи – с сухим прогоном по умолчанию.
  • Обвязка edt-bridge-mcp (pipx): перенаправляет в запущенную EDT, сама поднимает headless, если ни одна не открыта, и доставляет jar плагина в dropins/.
  • edt_platform_help – Синтакс-помощник платформы из поставки EDT: настоящий справочник по API, с поиском, на русском и английском.
  • Многопоточный MCP-сервер и фолбэк по порту: если 8770 занят, берётся следующий свободный, и обвязка его находит.

Исправлено

  • apply при создании проектов работает надёжно: собирается и присоединяется отдельная Configuration или внешняя обработка, вместо того чтобы спорить с жизненным циклом headless EDT.

Изменено

  • Типографика по правилам проекта во всём репозитории – среднее тире вместо длинного, три точки вместо символа многоточия, – включая описания инструментов и обвязку.

11.07.2026 – 0.0.1

Добавлено

  • Первый выпуск: инструменты чтения по MCP (проекты, проблемы валидации, детали и списки метаданных, ссылки, валидация запросов, формы), встроенная панель и MCP-сервер на localhost.

Эта страница была полезной?