rlm-bsl-search

name	rlm-bsl-search
description	Правила использования RLM tools для проектного поиска и навигации по 1C/BSL

RLM tools для 1C/BSL

Когда применять

Используй этот навык, когда работаешь с 1C/BSL и для ответа нужна проектная разведка по исходникам конфигурации, даже если пользователь явно не просил "поиск".

Ситуация	Первый инструмент
Найти реализацию процедуры, функции, обработчика, подписки, регламентного задания	rlm_start
Понять, где используется объект метаданных, реквизит, табличная часть, форма, роль, запрос	rlm_start
Найти похожую реализацию перед изменением BSL-кода	rlm_start
Разобраться в бизнес-механизме или цепочке вызовов по проекту	rlm_start
Исследовать XML/MDO/forms/rights/query и связи с BSL-кодом	rlm_start
Оценить blast radius изменения в 1C-конфигурации	rlm_start, затем точечная проверка через BSL LS

Главное правило: для широкого 1C/BSL поиска используй RLM до Grep, Glob, широкого Read, Bash rg, grep, find и ручного рекурсивного чтения файлов.

Быстрое решение: RLM или BSL LS

Если тебе нужно...	Используй
Найти, где в проекте живёт механизм, похожая реализация или бизнес-цепочка	RLM first
Найти все проектные связи объекта: BSL, запросы, XML/MDO, формы, права, подписки, регламентные задания	RLM first
Понять blast radius до выбора конкретного файла/символа	RLM first
Перейти к definition/references уже известного символа в конкретном месте	BSL LS first
Получить hover, signature, completion, diagnostics, code actions, rename	BSL LS first
Проверить изменённый BSL-файл после правки	BSL LS diagnostics, затем финальная проверка через v8-runner
Быстро прочитать один известный файл/фрагмент	Read / LSP file tool

Модель работы: RLM отвечает на вопрос “где и что искать по проекту?”, BSL LS отвечает на вопрос “что точно означает этот символ/тип/позиция?”. Если задача начинается с неясной бизнес-потребности или широкого поиска по 1C-исходникам — начинай с RLM. Если задача уже позиционная — начинай с BSL LS.

Когда не применять первым

Ситуация	Инструмент
Нужны diagnostics, hover, signature, completion	BSL LS/LSP tools
Нужны definition/references/rename/formatting/code actions по уже известной позиции	BSL LS/LSP tools
Нужно прочитать один уже известный файл или маленький фрагмент	Read или LSP file tool
Поиск не относится к 1C/BSL исходникам	обычные инструменты поиска
RLM недоступен, индекс сломан или явно не подходит	fallback на Grep/rg, зафиксировав причину

MCP-инструменты

Инструмент	Когда использовать	Подводные камни
rlm_start	Открыть сессию проектной разведки по 1C/BSL исходникам	path должен указывать на source root 1C, а не на произвольный root репозитория
rlm_execute	Выполнить батч поиска/навигации через helper'ы RLM	Печатай компактный результат, не большие тела файлов
rlm_help	Выбрать helper/recipe перед нетривиальной разведкой	Вызывать до rlm_execute, если стратегия из rlm_start недостаточна
rlm_end	Закрыть RLM-сессию	Закрывай после завершения разведки
rlm_index	Проверить состояние индекса (info) или администрировать индекс	Build/update обычно делает контейнер, не агент
rlm_projects	Работать с registry проектов RLM	Не нужен для обычной сессии, если известен path

Цикл работы

1. Определи, что задаче нужна проектная 1C/BSL разведка.
2. Вызови rlm_start.
3. В query передай короткую рабочую цель разведки. Это не промпт во внутреннюю LLM: query помогает RLM выбрать effort, strategy и business recipe.
4. В path передай каталог исходников 1C-конфигурации, обычно <project-root>/src, или точный root конфигурации, где лежит Configuration.xml. Не передавай root git-репозитория, если он не является root исходников 1C.
5. Прочитай ответ rlm_start: session_id, warnings, index status, extension context, strategy, available functions.
6. Для нетривиальной задачи или сомнения в helper'ах вызови rlm_help до rlm_execute.
7. Делай разведку через rlm_execute: пиши компактный Python, используй helper'ы RLM и печатай только полезный результат.
8. Если после широкой разведки нужна точная IDE-семантика по конкретному символу/позиции, переходи к BSL LS/LSP tools.
9. Закрой сессию через rlm_end, когда разведка закончена.

Что передавать в path

path должен указывать на каталог, где RLM сможет найти дерево исходников 1C:

<project-root>/src
<project-root>/src/xml
<project-root>/src/cf

Допустим и точный каталог конфигурации, содержащий Configuration.xml.

MCP proxy может нормализовать относительные, host и container paths, но это только техническое преобразование пути. Семантика не меняется: путь должен вести к исходникам 1C, а не к произвольному каталогу проекта.

RLM и LLM

rlm_start.query сам по себе не вызывает LLM. Он задает цель сессии и влияет на:

• auto effort;
• strategy;
• business recipe;
• подсказки для последующего rlm_execute.

Опциональные llm_query и llm_query_batched доступны только внутри rlm_execute, если сервер RLM настроен с LLM provider. Без LLM RLM остается deterministic index/search/navigation tool.

Что делать в rlm_execute

Предпочитай один содержательный rlm_execute вместо множества мелких Grep/Read.

Для сложной разведки разделяй работу на фазы:

1. Первый rlm_execute — только discovery: найти и дедуплицировать кандидатов (объекты, методы, регистры, формы), вывести компактную таблицу name/category/path/count и следующий шаг.
2. Второй rlm_execute — профиль 3-5 выбранных production-кандидатов (get_object_profile, get_object_full_structure, extract_queries), без callers по всем найденным методам.
3. Третий rlm_execute — точечный trace/callers/usages только для методов, выбранных после профиля.

Не смешивай в первом батче discovery + профили объектов + callers/call hierarchy. Такой вывод быстро становится шумным, попадает в лимиты max_output_chars и теряет хвост результата.

Выводи компактно:

• найденные методы/объекты;
• пути файлов;
• номера строк;
• краткие связи: callers, usages, forms, rights, query refs;
• следующий точечный шаг, если нужен BSL LS.

Не печатай большие тела файлов без необходимости. Сначала найди кандидатов и только потом читай точные фрагменты. Дедуплицируй варианты регистра и языка поисковых терминов (PnL/PNL/Pnl, OKX/okx, русские падежи), а также исключай тестовые расширения/модули из production-вывода, если задача не про тесты. Если тестовые находки нужны как evidence, печатай их отдельной секцией с лимитом.

Индекс

Обычно агент не строит индекс руками. Контейнер сам запускает RLM build/update:

• при старте;
• после изменений файлов через watcher.

rlm_index используй в основном для диагностики info. Ручные build, update, drop применяй только когда явно нужно администрировать индекс или исправлять его состояние.

Сценарии

Найти существующую реализацию перед изменением

1. rlm_start(query="найти существующую реализацию <механизм>", path="<project-root>/src")
2. Если неясно, какие helper'ы применить: rlm_help(category="discovery").
3. rlm_execute: сначала search(...) / search_methods(...), затем точечно read_file(...) или helper для usages/callers.
4. Если найден конкретный символ и нужна точная позиционная проверка — перейти к BSL LS.
5. rlm_end.

Оценить влияние изменения объекта метаданных

1. rlm_start(query="оценить использования объекта метаданных <Объект>", path="<project-root>/src")
2. rlm_execute: найти code usages, формы, запросы, права, подписки, регламентные задания.
3. Свести результат по типам использования и рискам.
4. Для точечных definition/references по конкретному BSL-символу использовать BSL LS.
5. rlm_end.

Диагностировать индекс

1. Если RLM отвечает странно или медленно, сначала rlm_index(action="info", path="<project-root>/src").
2. Если индекс stale/missing, проверь логи контейнера и настройки watcher.
3. Ручной build/update/drop делай только если это явно нужно для восстановления индекса.

Правильно / неправильно

Правильно:

Нужно понять, где рассчитывается скидка.
1. rlm_start(query="найти расчет скидки и связанные вызовы", path="<project-root>/src")
2. rlm_execute: search("скидк"), search_methods("Скид"), get_callers(...)
3. Read/BSL LS только по найденным конкретным файлам/позициям.

Почему: RLM использует индекс и helper'ы, не тащит в контекст тысячи файлов.

Неправильно:

Grep("Скид", glob="**/*")
Read десятков найденных файлов
Bash rg по всему src

Почему: широкий raw search по большой 1C-конфигурации медленнее, шумнее и теряет связи метаданных, форм, прав, запросов и графа вызовов.

Приоритеты

RLM first:

• широкий статический поиск по 1C/BSL;
• поиск похожих реализаций;
• metadata usages;
• call graph;
• формы, роли, XML/MDO, запросы;
• бизнес-контекст и связи по проекту.

BSL LS first:

• cursor/position based операции;
• diagnostics;
• hover/signature/completion;
• definition/references по уже известной позиции;
• rename/formatting/code actions.

Raw search fallback:

• RLM недоступен;
• задача вне 1C/BSL;
• нужен простой поиск в одном известном файле;
• RLM не покрывает конкретный технический случай.