/code-diagnostics

name: code-diagnostics
description: "Диагностика BSL и объяснение отключений правил. Используй, когда нужно запустить или разобрать диагностики BSL, АПК, EDT, BSL LS, inline/range disable markers, suppression-комментарии или стандарт v8std за диагностикой."

Code Diagnostics

MCP routing

• Диагностику узла даёт `unica.check {at}`. Валидаторы следуют из вида узла:

у модуля это BSL-анализатор, у объекта метаданных — его собственные проверки. Выбирать провайдера или действие не нужно. Без `at` проверяется готовность наборов исходников рабочего пространства.

• Необязательные `at`, `limit`, `cursor` можно пропустить; `null` равносилен

пропуску. Для первой страницы курсор отсутствует, а пустая строка тоже означает первую страницу. `limit` задаёт размер страницы: по умолчанию 20, максимум 50. Продолжай по возвращённому `cursor` с теми же адресом и размером страницы; вердикт относится ко всем находкам, даже если они ещё не прочитаны.

• Ответ несёт `status` (`passed` или `failed`), `validators` — какие проверки

отработали, и `diagnostics` — находки с кодом, важностью, местом и стандартом. Провалом считается `error`, а не всякая пометка: подсказка по стилю модуль не ломает.

• **Пустой `diagnostics` при `status: passed` подтверждает анализ с учётом

названных фильтров `data.suppressed`.** Если анализ не завершился, `check` отказывает `provider_unavailable` и прямо говорит, что модуль не проверен. Отдельного вопроса о готовности провайдера больше нет: чистый ответ и неотработавший провайдер теперь различимы по самому ответу.

• **Базовая линия проекта — фильтр.** Если в `bsl-analyzer.toml` настроен

`[diagnostics.baseline]`, `passed` значит «прошёл после фильтра базовой линии»: `data.suppressed` называет его — сколько известных находок скрыто (`known`) и сколько новых осталось (`new`), с `by: baseline` и тегами поставщика/валидатора. Сломанная линия (нет файла, неверная схема) — не «чисто»: `check` отказывает и называет её причину.

• **Фильтр авторов может скрыть находки.** Закреплённый CLI-анализатор не

передаёт их число. При действующем `[analysis].ignored_authors` (или `analysis.ignoredAuthors` в JSON) `check` отказывает `provider_unavailable` с причиной про авторский фильтр. Назови это ограничение проверки; не выдумывай число и не объявляй модуль чистым. `diff_base` сам по себе не мешает проверке одного модуля: Unica задаёт его полный модульный scope.

• Адрес узла даёт `unica.view {at}` по дереву или `unica.search {corpus: "names"}`

по имени. Если отправная точка — путь из диффа или лога сборки, переведи его в адрес аварийным `unica.resolve`; в обычном ходе работы он не нужен.

• Стандарт v8std спрашивается только через `unica.docs` с

`source: "development-standard"`. Не зови анализатор, стандарты или пакетные адаптеры напрямую.

• Код ищется `unica.search`: `role` выбирает, чем искать — `lexical` буквально,

`symbol` по индексу символов, `semantic` по смыслу. Без `role` Unica ищет литерал сама.

Чего на канонической поверхности пока нет

Называй это пробелом контракта, а не обходи стороной:

• **сплошной прогон по всему набору** — `check` проверяет один адрес; обхода

всех модулей одним вызовом нет;

• **отбор по важности и кодам** — `limit` ограничивает страницу, но не

фильтрует находки;

• **каталог правил провайдера** — коды берутся из находок и из `unica.docs`.

Влияние правки оценивай графом вызовов: узел метода называет ветви `Caller` и `Callee`, и `unica.view {at: "<метод>.Caller"}` возвращает вызывающих.

Workflow

1. Получи адрес узла: `unica.view {}` называет наборы исходников, `unica.search {corpus: "names"}` находит объект по имени, `unica.view {at}` спускается по дереву. У владельца есть ветвь `Module`, у модуля — `Method`. 2. Вызови `unica.check {at}` на модуле или объекте. Прочти `status`, `validators`, `diagnostics` и `data.suppressed`; при отказе прочти названную причину неполноты. 3. Сгруппируй находки по месту, коду и первопричине. Иди за точным диапазоном в самой находке. 4. Разгляди предмет: `unica.view {at}` на узле метода даёт подпись, контекст компиляции и собственные строки; `unica.search` находит вхождения. 5. Спроси стандарт: `unica.docs` с `source: "development-standard"` по коду, имени диагностики, токену АПК/EDT/BSL LS или соседнему фрагменту. 6. Отчитайся: причина в исходнике, затронутые диагностики, логический адрес и место, доказательство из стандарта, результат перепроверки.

Verification gate

This verification gate is mandatory:

• Проверяй `unica.check {at}` после правок, чувствительных к синтаксису, и

считай новые находки важности `error` блокирующими.

• Оценивай влияние при изменении экспортного метода, обработчика метаданных,

публичного API, пути запроса или контракта общего модуля. Пока графа вызовов на поверхности нет, доказательством служит `unica.search` по имени символа — и скажи, что доказательство неполное.

• Если публичный MCP `unica` не может показать нужное доказательство, сообщи о

пробеле контракта вместо заявления о полной проверке.

Suppression and range-disable comments

Когда inline/range disable markers или suppression-комментарии отключают диагностику строки или диапазона, считайте точный маркер частью доказательства.

• Extract literal rule codes from АПК, EDT, BSL LS, analyzer, or suppression comments.
• Explain an отключение only when the code, surrounding range, and standard support the reason.
• Prefer fixing the cause or narrowing the disabled range. Keep suppression only with standards, platform-help, or runtime evidence of an intentional false positive.

MCP examples

Проверка одного модуля:

{
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "name": "unica.check",
    "arguments": { "at": "main:CommonModule.Продажи" }
  }
}

Стандарт за диагностикой:

{
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "name": "unica.docs",
    "arguments": {
      "query": "АПК:14