steelmorgan/code-verification

Верификация кода (Code Verification)

Навык описывает порядок проверки BSL-кода после внесения правок. Три слоя проверки, каждый ловит свой класс ошибок.

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

| Триггер | Действие | |---------|----------| | После изменения BSL-кода | Полный цикл (все 3 слоя) | | Ревью чужого кода | Слой 2 + Слой 3 | | Вопрос пользователя «проверь синтаксис» | Полный цикл |

Слои проверки

Слой 1 — LSP-диагностика (быстрая)

Цель: немедленная обратная связь по изменённому файлу.

1. get_diagnostics(uri) — получить ошибки/предупреждения от BSL Language Server.
2. Если есть error-уровень — исправить до перехода к слою 2.
3. Если LSP недоступен — перейти к слою 2, отметив что LSP-проверка пропущена.

Слой 2 — Напарник (VALIDATE_BSL)

Цель: проверка синтаксиса, стандартов, поиск аналогов в БСП.

Что передавать: целиком процедуры/функции, в которых были правки. Не фрагменты, не отдельные строки — полные тела методов.

Вызов: ask_ai_assistant с шаблоном VALIDATE_BSL из buddy-prompting.

Как интерпретировать результат:

| Ситуация | Действие | |----------|----------| | Напарник нашёл ошибки | Проанализировать каждую. Ложные «необъявленная переменная» на глобальные методы — фильтровать. Остальное — исправить или обосновать. | | Напарник не нашёл ошибок | НЕ считать доказательством корректности. У Напарника ограниченный контекст — он не видит проект. Перейти к слою 3. | | Напарник рекомендует замену на БСП | Проверить через search_ssl_functions, что рекомендованная функция существует. |

Слой 3 — Верификация платформенного API

Цель: подтвердить, что каждый используемый в коде платформенный объект, метод, свойство и конструктор реально существует на указанном типе.

Алгоритм:

1. Извлечь из изменённого кода все обращения к платформенному API:

   • Новый <Тип>(...) — создание объектов
   • <Объект>.<Метод>(...) — вызовы методов
   • <Объект>.<Свойство> — чтение/запись свойств
   • Обращения к менеджерам, перечислениям, предопределённым значениям

2. Для каждого обращения — верифицировать:

   | Что в коде | Как проверить | Capability | |------------|---------------|------------| | Новый <Тип> | Тип существует? | search_syntax_reference → get_type_info | | Новый <Тип>(парам1, парам2) | Конструктор с такими параметрами? | getConstructors | | Объект.Метод() | Метод есть на этом типе? | getMember | | Объект.Свойство | Свойство есть на этом типе? | getMember | | Тип неясен | Поиск по имени | search_syntax_reference → getMembers | | Тип переменной/выражения неизвестен | Вывести тип значения под курсором | get_hover_info |

3. Особое внимание — коллекционные типы. API Структура, Соответствие, ТаблицаЗначений, Массив различается. Не предполагать одинаковые методы — проверять на конкретном типе.

4. Определение типа переменной. Когда непонятно, какой тип у переменной (а значит — какой API на ней допустим), get_hover_info(uri, line, character) по имени переменной возвращает выведенный BSL LS тип значения (Type System v2). Это вывод типа конкретного значения в этой точке, а не справка по всем типам платформы. Затем верифицировать члены полученного типа через getMember/getMembers. Если get_hover_info недоступен — определить тип по месту объявления/присваивания через navigate_symbol.

Иерархия доверия

v8-runner syntax …  (компилятор)   ← формальная проверка, финальный вердикт
  > get_diagnostics (LSP)          ← быстрая диагностика
    > bsl-platform-context         ← авторитетный справочник API
      > ask_ai_assistant           ← совещательный голос (не доверять отсутствию ошибок)

При расхождении — побеждает источник выше по иерархии.

Формат отчёта

По итогам проверки — структурированный вывод:

1. LSP: ошибки / предупреждения (или «LSP чист / недоступен»).
2. Напарник: найденные проблемы + рекомендации (или «замечаний нет — НО это не гарантия»).
3. Платформенный API: подтверждённые / неподтверждённые обращения.
4. Итог: тип каждой проблемы — синтаксис / ошибка API / нарушение стандарта / рантайм-риск.

Ошибки и ограничения

| Проблема | Обходной путь | |----------|---------------| | LSP недоступен | Пропустить слой 1, перейти к слою 2. Отметить в отчёте. | | Напарник недоступен | Пропустить слой 2. Усилить слой 3. | | bsl-platform-context не знает тип | Тип из проекта (не платформенный) — проверить через navigate_symbol. | | Ложная «необъявленная переменная» от Напарника | Нормально для глобальных методов — фильтровать. | | search_syntax_reference пустой | Уточнить имя типа (русское/английское написание), проверить версию. | | Напарник рекомендует несуществующую функцию БСП | Проверить через search_ssl_functions. |

Capabilities

| Capability | Слой | Назначение | |------------|------|------------| | get_diagnostics | 1 | LSP-диагностика файла | | ask_ai_assistant | 2 | VALIDATE_BSL через Напарника | | search_ssl_functions | 2 | Проверка рекомендаций по БСП | | search_syntax_reference | 3 | Поиск платформенного типа | | get_type_info | 3 | Информация о типе | | getMembers | 3 | Список членов типа | | getMember | 3 | Проверка конкретного члена | | getConstructors | 3 | Проверка конструктора | | get_hover_info | 3 | Вывод типа значения переменной/выражения под курсором | | navigate_symbol | 3 | Определение типа переменной по объявлению (fallback к get_hover_info) | | v8-runner syntax … | * | Финальная проверка компилятором (CLI; см. навык v8-runner) |

---

depends_on: [syntax-checking, buddy-prompting, code-navigation]