Учебный стенд

Этот раздел нужен тому, кто готовит среду для занятий. Если ты получил готовый комплект, проверь его состав по первой таблице. Технические настройки ниже можно читать по необходимости.

Состояние на 27 сентября 2026 года: тексты и контрольные примеры готовы. Загрузка исходной базы, стартовые комплекты и полное прохождение уроков в 1С ещё не подтверждены. Практика пока заблокирована подготовкой среды и проверками в 1С.

Что нужно для каждого урока

Урок	Исходное состояние
1. Отгрузка	Каркас базы, описание нужных объектов, набор A0 и способ его восстановления
2. Сборка	Принятый результат первого урока либо подготовленная автором версия; данные компонентов и спецификаций
3. Последний товар	Отдельная версия с воспроизводимым дефектом и проверенным способом запуска двух сеансов

Во всех случаях нужны исходники под Git, вымышленные данные, разрешённые команды и способ восстановления базы. Для третьего урока нельзя поручать агенту ученика придумать себе ошибку: тогда он заранее будет знать причину.

Подготовка базы

Основа — каркас «1С:Специалиста» с официальной страницы. Сам по себе он не содержит готовых решений наших уроков.

1. Сохрани исходный файл, адрес загрузки, дату и контрольную сумму SHA-256.
2. Подготовь отдельную пустую учебную базу. Загрузка DT заменяет её содержимое, поэтому перед запуском проверь точный адрес базы и разрешение на загрузку.
3. Зафиксируй версию платформы, режим совместимости и способ выгрузки исходников.
4. Найди нужные объекты: товары, склады, поступление, расход, сборку, остатки и отчёты. Если чего-то нет, отметь необходимость создания.
5. Проверь восстановление каждого набора данных. Оно должно возвращать исходное состояние, а не добавлять поступления повторно.

Если в каркасе нет работающих поступлений и хранения остатков, их минимальная реализация входит в подготовку первого урока. Точный объём определяется после изучения базы.

Запиши настройки и проверенные команды в паспорт стенда. Авторские ответы, исправленная версия третьего урока и история создания дефекта должны находиться вне доступа ученика и его агентов.

Настройка BSL Flow Managed

Условия сверены с документацией BSL Flow 0.9.0-dev.1. Это предварительная версия; перед занятием проверь установленную поставку по инструкции установки и руководству по миграции.

На Windows сначала устанавливается Core, затем Managed той же версии. Порядок и команды приведены в уроке 8 базового курса. Если обновляешься с 0.8, старые файлы Managed могут остаться на диске после установки Core: перед запуском контроллера обязательно обнови и Managed.

Проверь записи установки ~/.bsl-flow/installed-core.json и ~/.bsl-flow/installed-managed.json, соответствие версий и доступность нужных навыков. Затем отдельно проверь исполнителя задач и провайдеров ревью. Установка Core не требует API-ключа или CLI модельного провайдера, но это не означает, что без них будут работать выбранные ревью и исполнение.

В Core крупная задача или задача высокого риска без Council блокируется. Фреймворк допускает отдельное решение владельца о принятии риска, но такое исключение не заменяет консилиум в наших упражнениях. Подробности этого исключения оставлены в руководстве по миграции.

Перед занятием проверь регистрацию задачи, полный цикл, чтение состояния и продолжение после остановки. Основной порядок:

inspect → spec → spec_review → implement → code_review → verify → acceptance.

Разбор замечаний и финальная проверка спецификации входят в spec_review. Проверка кода и покрытия требований выполняется до запуска тестов. После тестов курс предусматривает дополнительное независимое чтение итоговых материалов; это отдельное поручение только на чтение.

Для первого и третьего уроков нужен настоящий Council. Предложенный маршрут второго урока также использует консилиум из-за риска ошибок учёта. Изменение оценки риска нужно согласовать с поручением и паспортом стенда. Недоступного рецензента нельзя заменять отзывом автора решения.

Запуск и продолжение

• Start регистрирует задачу, Run ведёт её по разрешённым этапам.
• В первом уроке используется analysis_only с analysis_goal=specification: критерии задаются заранее, выполнение останавливается после принятой спецификации и обязательного ревью.
• Если условия не изменились, переход к реализации оформляется через Update(kind=authorization, mode=implement).
• Изменение требований или критериев требует scope_change с актуальным expected_revision и пересмотра затронутых заключений.
• Новый ведущий восстанавливает ту же задачу через Status, журнал и файлы. Для продолжения используется штатный Resume, когда он требуется состоянием задачи. Next лишь показывает следующее действие, а Cancel не служит учебной паузой.

Автор должен подготовить проверенные шаблоны запросов и обновлений. Готовность этих шаблонов в текущем комплекте ещё не подтверждена.

Подготовка тестов

Исполняемые тесты и наборы данных готовятся до реализации, отдельно от Run. Для профилей requirements/native защищённые входы задаются через protected_paths; исполнитель реализации не может их менять. Встроенного этапа написания тестов в этом маршруте нет.

Во втором раунде новые тесты готовятся, когда прежний исполнитель уже закончил работу. Обновлённый набор принимается через scope_change до следующей реализации. Проверка покрытия показывает, достаточно ли предусмотренных тестов, но не подтверждает их выполнение.

Автоматические исправления после провала теста ограничены параметром max_source_repairs: от нуля по умолчанию до трёх попыток. Они допустимы только для проверок файлов либо команд static/unit с явным retry_safe: true и защищёнными тестовыми входами. Этот механизм не разрешает повторять произвольные операции в базе.

Ограничения запусков в 1С

Описанный в текущем контракте bsl-flow встроенный маршрут ограничен Windows FILE-базой, снимком одного расширения и выбранными тестами YAxUnit. Это возможность инструмента, а не подтверждение готовности наших заданий.

Для первых двух уроков нужно проверить, подходят ли реальные объекты и изменения под этот маршрут. Если требуется правка основной конфигурации, работа через интерфейс или другой способ тестирования, он должен быть подготовлен и разрешён отдельно.

Для третьего урока нужны два сеанса одной клиент-серверной базы. Проверка независимых операций не покрывается указанным FILE-маршрутом. В паспорт входят платформа, СУБД, режим блокировок, точки наблюдения, предел ожидания и способ освобождения паузы.

Действующее ограничение Unica сохраняется: нельзя использовать durable jobs для сборки, загрузки, обновления и тестов или обходить запрет другой оболочкой. Разрешены чтение, работа с исходниками, диагностика и подготовка команд. Запуски, меняющие базу, остаются заблокированными до отдельного разрешения точного маршрута и базы.

Результат внешнего разрешённого запуска сохраняется отдельно. Он не переводит неподдерживаемую проверку управляемой задачи в успешный статус автоматически.

Проверка готовности курса

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

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

До подтверждения среды и всех обязательных сценариев полная практическая приёмка остаётся BLOCKED.