git:20261012.c1cbcc4 to git:20261025.517d4a0

40 added, 2 removed. Audit A to A.

---
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` и прямо говорит, что
+ - **`status: passed` означает, что ни один отработавший валидатор из
+ `validators` — анализатор кода по его действующим правилам и валидаторы
+ метаданных — не нашёл ошибок с учётом фильтров `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 ищет
литерал сама.
+
+ ### Неопределённые имена и программные реквизиты формы
+
+ В поставляемом анализаторе правило `UnresolvedName` выключено по
+ умолчанию. Поэтому `passed` стандартного профиля совместим с ошибочными
+ чтениями необъявленных переменных. При исследовании пропущенной находки
+ сверь действующую настройку проекта и код правила; не объявляй потерю в
+ проекции Unica по одному отсутствию диагностики.
+
+ Для отдельного эксперимента правило можно явно включить в настройке анализатора
+ в корне исходников. Если там есть `bsl-analyzer.toml`, анализатор читает только
+ его, а `.bsl-analyzer.json` пропускает; добавь в TOML:
+
+ ```toml
+ [diagnostics.parameters]
+ UnresolvedName = true
+ ```
+
+ Без TOML то же задаётся в `.bsl-analyzer.json`:
+
+ ```json
+ {"diagnostics":{"parameters":{"UnresolvedName":true}}}
+ ```
+
+ У этого правила есть ложные срабатывания: форма, которую платформа
+ компилирует, может получить находку на встроенный метод формы, например
+ `ИзменитьРеквизиты`. Явное включение требует оценки
+ находок и не служит рекомендацией менять профиль всего проекта.
+
+ Программно добавленные реквизиты верхнего уровня читаются через
+ `ЭтотОбъект.<Имя>`. Присваивание bare-имени в другом методе объявляет локальную
+ переменную и не делает это имя реквизитом формы. Статические реквизиты,
+ локальные и модульные переменные проверяй отдельно. Поведение платформы
+ уточняй через `unica.docs` по `ClientApplicationForm.ChangeAttributes`;
+ проверка анализатором не заменяет компиляцию.
### Чего на канонической поверхности пока нет
Называй это пробелом контракта, а не обходи стороной:
- **сплошной прогон по всему набору** — `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
Проверка одного модуля:
```jsonc
{
"jsonrpc": "2.0",
"method": "tools/call",
"params": {
"name": "unica.check",
"arguments": { "at": "main:CommonModule.Продажи" }
}
}
```
Стандарт за диагностикой:
```jsonc
{
"jsonrpc": "2.0",
"method": "tools/call",
"params": {
"name": "unica.docs",
"arguments": {
"query": "АПК:142 LineLength",
"source": "development-standard"
}
}
}
```
Вхождения символа перед правкой общего кода:
```jsonc
{
"jsonrpc": "2.0",
"method": "tools/call",
"params": {
"name": "unica.search",
"arguments": {
"query": "ПередЗаписью",
"role": "symbol",
"scope": "main:Configuration"
}
}
}
```