AI-EDT v0.2.34

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

• Решения возвращаются от того, кто их принял
• Состояние проекта после объединения
• ping, resources/list, resources/read
• Поиск по всей рабочей области
• Проверено на стенде

Решения возвращаются от того, кто их принял

compare_three_way получил decisionsFrom - путь к файлу настроек, записанному раньше этим же инструментом или человеком в EDT. Восстанавливаются обе половины файла: правила объединения и соответствия объектов, установленные вручную между теми, что не совпадают ни по UUID, ни по имени.

Затвор объединения считал только решения, переданные в том же вызове, поэтому объединение по файлу отклонялось с decided=0, пока окружение уже держало правила. Теперь затвор видит оба источника, а отказ называет оба пути входа. Файл, который разобрался и не нёс решений, отличается от применённого полем decisionsRestored.

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

Состояние проекта после объединения

При intent=MERGE затронутые объекты перевалидируются, и ответ несёт errorsAfterMerge и revalidatedAfterMerge. Взятие чужой версии объекта штатно ломает то, что ссылалось на прежнюю, поэтому ответ, останавливающийся на merged, верен и бесполезен.

Когда решения пришли файлом и списка объектов в вызове нет, объекты берутся из самого сравнения - иначе без проверки оставались бы ровно те объединения, что подготовлены вручную. Счёт ошибок по объектам реализован в одном месте, ProjectProblemsReader.countErrorsOn, и отвечает -1, когда его не удалось взять: ноль выглядит как чистый проект.

ping, resources/list, resources/read

Три метода, прежде отвечавшие -32601.

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

resources/list и resources/read отдают описания проверок EDT: 167 документов под схемой aiedt://checks/<id>, text/markdown. Схема своя, а не file:, потому что описание может лежать внутри jar-а плагина, где открывать клиенту нечего. Список строится тем же CheckDocReader, который их читает, поэтому перечислить нельзя то, чего затем не выдать.

Возможность resources объявлена и в рукопожатии, и в server/discover. Подписка и уведомления об изменении списка не объявлены: сервер их не шлёт.

Поиск по всей рабочей области

У search_in_code (code_search operation=text_search) projectName стал необязательным. Без него ищутся все открытые проекты с исходниками, и ответ называет их поимённо.

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

Проверено на стенде

EDT 2026.2.0+289, рабочая область с конфигурацией, её расширениями и вторым комплектом БСП - 11 проектов.

Проверка	Результат
Решение на родителе	синоним реквизита табличной части тремя уровнями ниже принял сторону поставки
Объединение по одному файлу, без аргумента decisions	decisionsRestored=true, merged=true, проект принял другую сторону
Файл отсутствует / расширение не .zip	обе ветки отказа называют путь и причину
Состояние после объединения	errorsAfterMerge=0, revalidatedAfterMerge=true
ping	пустой результат, обе ревизии протокола
resources/list / resources/read	167 документов, markdown отдан
Поиск по одному проекту против всей области	тот же запрос: 0 совпадений против 209 в 32 модулях

Сборка - 1640 тестов.