| name | dev-1c |
| description | Разработка в 1С 8.2 (BSL): добавить фичу, исправить баг, провести исследование кодовой базы. Используй когда: нужно реализовать задачу в 1С, исправить баг в 1С, написать код BSL, отревьюировать BSL-код, изучить объекты конфигурации через mcp_1c, спроектировать изменение в 1С. Покрывает полный цикл Research → Design → Plan → Implement с Quality Gates. Включает правила работы с mcp_1c, стандарты BSL-кода, паттерны для документов, справочников, регистров, форм, общих модулей. |
| argument-hint | Тип (feature / bug) и краткое описание: что нужно сделать в 1С |
Разработка в 1С 8.2 — RDPI
Методология: Research → Design → Plan → Implement
Инструментарий: mcp_1c (анализ конфигурации) + Copilot Chat (генерация кода)
ОБЯЗАТЕЛЬНО: Весь код пишется строго для платформы 1С:Предприятие 8.2.
Синтаксис и парадигма 8.2 принципиально отличаются от 8.3 — использование конструкций 8.3 недопустимо.
Подробности → references/bsl-standards.md — раздел «Специфика 8.2»
Критические отличия 8.2 от 8.3 (запрещённые конструкции)
| Область | 8.3 (ЗАПРЕЩЕНО) | 8.2 (ОБЯЗАТЕЛЬНО) |
|---|
| Директивы компилятора | &НаКлиенте, &НаСервере, &НаСервереБезКонтекста | Отсутствуют — весь модуль формы выполняется в одном контексте |
| Доступ к элементам формы | НазваниеЭлемента.Значение напрямую | ЭлементыФормы.НазваниеЭлемента.Значение |
| Реквизиты формы | ЭтаФорма.НазваниеРеквизита | Напрямую по имени переменной модуля формы |
| Модуль формы | Разделён на клиент/сервер | Единый, исполняется на клиенте (толстый клиент) |
| Управляемые формы | Форма объект | Обычные формы (ДиалогВыбораФайла а не ВыборФайла) |
ОткрытьФорму | Асинхронный вызов с ОписаниеОповещения | Синхронный вызов, возвращает ссылку на форму |
Правила поведения агента
-
Один вариант, не несколько. Всегда выдавать одно лучшее решение с обоснованием — не «можно сделать так или так». Варианты перечислять только если пользователь явно попросил.
-
Не соглашаться при наличии фактических причин. Если предложение пользователя противоречит фактам из кода, метаданным конфигурации или стандартам BSL — возразить прямо, назвать конкретную причину со ссылкой на объект/строку/правило. Додуманные или гипотетические риски — не основание для возражения.
Шаг 0: Определи тип задачи
| Тип | Процесс |
|---|
| Feature (новая функциональность) | Все 4 фазы в полном объёме |
| Bug (исправление ошибки) | Сокращённый процесс → раздел Bug Fix |
| Только Research | Только фаза 1 |
| Только ревью кода | Чеклист → BSL Standards |
Фаза 1: Research — Исследование
Цель: Собрать факты о текущем состоянии кода (AS-IS). Никаких советов и мнений — только факты со ссылками на объект/модуль/строку.
Артефакт: docs/research/<задача>/research.md
Алгоритм для агента
1. Найти точку входа в задачу через mcp_1c-mcp_search_code("<ключевое слово>")
2. Получить метаданные всех затронутых объектов
3. Прочитать код всех затронутых модулей
4. Найти все зависимости и точки интеграции
5. Зафиксировать ограничения и открытые вопросы
6. Записать в research.md
Инструменты mcp_1c для Research
mcp_1c-mcp_search_code("<слово>") — найти где встречается
mcp_1c-mcp_get_object_metadata("<Тип.Имя>") — реквизиты, ТЧ, команды
mcp_1c-mcp_get_module_code("<Модуль>") — полный код модуля
mcp_1c-mcp_get_function_code("<Функция>") — код одной функции
mcp_1c-mcp_get_module_structure("<Модуль>") — список функций модуля
mcp_1c-mcp_get_form_context("<Форма>") — реквизиты и команды формы
mcp_1c-mcp_analyze_dependencies("<Модуль>") — что вызывает / что вызывается
mcp_1c-mcp_find_function_usage("<Функция>") — где вызывается функция
mcp_1c-mcp_list_objects("<Тип>") — список объектов по типу
Полный справочник инструментов → references/mcp-1c-tools.md
Формат <Тип.Имя> для get_object_metadata
Документ.ПлатежноеПоручение
Справочник.Контрагенты
РегистрСведений.КурсыВалют
ОбщийМодуль.РаботаСФайлами
Обработка.ИмпортДанных
Шаблон research.md
# Исследование: <Название задачи> — AS-IS
> Дата: <дата>
## 1. Затронутые объекты 1С
| Тип | Имя | Реквизиты/ТЧ (релевантные) |
|---|---|---|
## 2. Ключевые функции и процедуры
| Имя | Модуль | Строка | Назначение | Параметры |
|---|---|---|---|---|
## 3. Потоки данных
(откуда → как обрабатывается → куда записывается)
## 4. Точки входа и интеграции
(формы, регл. задания, внешние системы, файлы)
## 5. Текущие ограничения
(что сейчас НЕ делается, где ручное действие пользователя)
## 6. Файлы для изменения
(список BSL-файлов)
## 7. Открытые вопросы
Gate → переход к Design разрешён если
Фаза 2: Design — Проектирование
Цель: Спроектировать решение. Код не пишем — только архитектура, диаграммы, контракты.
Артефакт: docs/design/<задача>/ (5-6 файлов)
Создаваемые файлы
| Файл | Содержание | Инструмент |
|---|
architecture.puml | Компонентная диаграмма (PlantUML C4/flowchart) | plantuml |
sequence.puml | Sequence-диаграмма вызовов BSL | plantuml |
data-flow.puml | Поток данных: вход → обработка → объекты 1С | plantuml |
decisions.md | ADR: решения, альтернативы, риски | markdown |
contracts.md | Сигнатуры новых/изменённых процедур BSL | markdown |
testing.md | Тест-кейсы для ручной проверки | markdown |
Шаблон contracts.md
## <ИмяПроцедуры>(Параметр1, Параметр2)
**Тип**: Процедура | Функция | Экспортная функция
**Модуль**: <где находится>
**Параметры**:
- `Параметр1` (Тип) — описание
- `Параметр2` (Тип, необязательный) — описание
**Возвращает**: Тип — что означает
**Псевдокод**:
```bsl
// Шаг 1: ...
// Шаг 2: ...
// Шаг 3: ...
### Gate → переход к Plan разрешён если
- [ ] Все файлы дизайна созданы и заполнены
- [ ] Сигнатуры в `contracts.md` соответствуют стандартам BSL (русский язык, CamelCase)
- [ ] ADR содержит выбранный вариант + обоснование + риски
- [ ] Соблюдён принцип минимального вмешательства в существующий код
---
## Фаза 3: Plan — Планирование
**Цель**: Разбить дизайн на атомарные фазы. **Одна фаза = один логически завершённый коммит**.
**Артефакт**: `docs/plan/<задача>/` (overview.md + phase-N.md)
### Правила разбивки
Фаза 1..N-2 — только добавление нового кода, существующий не трогаем
Фаза N-1 — интеграция: подключение нового к существующему
Фаза N — финальный интеграционный тест
### Шаблон phase-N.md
```markdown
# Фаза N: <Название>
## Цель
<Что именно реализуется в этой фазе — один абзац>
## Изменяемые файлы
| Файл | Тип изменения | Что именно |
|---|---|---|
| МодульОбъекта.bsl | Добавление функции | `НоваяФункция()` |
## Новый код (из contracts.md)
<Сигнатуры и псевдокод>
## Критерии завершённости (DoD)
- [ ] Код соответствует BSL-стандартам (именование, отступы, комментарии)
- [ ] Нет хардкода и магических строк/чисел
- [ ] Ресурсы (ЧтениеXML, соединения) закрываются во всех ветках
- [ ] Все изменения в рамках contracts.md
## Quality Gates
- [ ] GATE PASSED: BSL Style (ревью кода)
- [ ] GATE PASSED: Design Compliance (соответствие contracts.md)
- [ ] Ручная проверка (см. testing.md)
Фаза 4: Implement — Реализация
Цель: Реализовать каждую фазу плана. Gate-ревью обязательно перед переходом к следующей фазе.
Цепочка на каждую фазу
1. Читаем phase-N.md и contracts.md через mcp_1c или read_file
2. Пишем код (только в рамках фазы)
3. Ревью BSL-стиля → [bsl-standards.md](./references/bsl-standards.md)
4. Ревью соответствия дизайну → сравнение с contracts.md и sequence.puml
5. Ручной тест
6. Коммит → следующая фаза
Правила написания кода BSL
Полный чеклист → references/bsl-standards.md
Критичные правила (не забывать никогда):
// ПРАВИЛЬНО: Число только после замены разделителей
СуммаЧисло = Число(СтрЗаменить(СтрЗаменить(СуммаСтрока, " ", ""), ",", "."));
// ПРАВИЛЬНО: ЧтениеXML закрывается ВО ВСЕХ ветках
Попытка
Чтение.ОткрытьФайл(ПутьКФайлу);
// обработка...
Исключение
Сообщить("Ошибка чтения XML: " + ОписаниеОшибки());
КонецПопытки;
Чтение.Закрыть(); // всегда после Попытки
// ПРАВИЛЬНО: Запрос вместо объектного чтения в цикле
Запрос = Новый Запрос;
Запрос.Текст = "ВЫБРАТЬ ... ИЗ Справочник.Контрагенты ...";
Quality Gates сводная таблица
| Gate | Что проверяем | Метод |
|---|
| BSL Style | Именование, форматирование, ошибки | Чеклист bsl-standards.md |
| Design Compliance | Сигнатуры, скоуп, sequence | Сравнение с contracts.md |
| Безопасность | Нет SQL-инъекций, открытых запросов | Copilot Chat |
| Ручной тест | Функциональность | Запуск в 1С |
Если хотя бы один Gate не пройден — возврат на доработку. К следующей фазе не переходим.
Bug Fix — Сокращённый процесс {#bug-fix}
Типы багов
| Тип бага | Признак | Пример |
|---|
| Падение | Исключение, зависание, несохранение | «Ошибка при проведении документа» |
| Некорректное поведение | Результат неправильный, но ошибки нет | Неверная сумма при определённой валюте |
| Ситуативный | Воспроизводится только при стечении условий | Баг при конкретной последовательности действий оператора |
| Данные | Зависит от входных данных | Отрицательное количество, пустой реквизит, нестандартный формат |
| Фаза | Содержание |
|---|
| Research | Определить тип бага. Зафиксировать точку кода. Описать минимальный сценарий воспроизведения: конкретные входные данные, состояние объектов, действия оператора. Проверить гипотезу: запустить сценарий и убедиться, что найденная точка действительно даёт ожидаемый некорректный результат. |
| Plan | Одна фаза: конкретное изменение + тест-кейсы воспроизведения + критерий «баг исчез». |
| Implement | Минимальное исправление + прогон по всем тест-кейсам. |
Железное правило: баг-фикс не содержит рефакторинг и новую функциональность.
Алгоритм Research для ситуативных и поведенческих багов
1. Зафиксировать гипотезу о точке бага:
mcp_1c-mcp_search_code("<ключевое слово из сценария>")
mcp_1c-mcp_get_function_code("<функция обработки>")
mcp_1c-mcp_find_function_usage("<функция>") — все вызовы
mcp_1c-mcp_get_call_graph("<функция>") — граф вызовов
2. Проверить условные ветки:
- Какие условия (Если/ИначеЕсли) обрабатывают данный сценарий?
- Какая ветка срабатывает при проблемных данных?
- Есть ли непокрытые граничные случаи?
3. Составить минимальный воспроизводящий сценарий:
- Конкретные значения реквизитов и ТЧ, при которых проявляется баг
- Последовательность действий оператора (шаг за шагом)
- Состояние связанных объектов (другие документы, регистры, справочники)
- Граничные значения: нулевые суммы, пустые реквизиты, Неопределено, нестандартный формат
4. Проверить гипотезу — прогнать сценарий в 1С:
- Воспроизвелся ли некорректный результат?
- Соответствует ли он описанному фактическому результату?
- Если НЕ воспроизвелся — вернуться к п.1, гипотеза неверна
→ Только после подтверждения гипотезы переходить к Plan
Шаблон описания бага (для research.md)
## Описание бага
**Тип**: падение | некорректное поведение | ситуативный | данные
**Сценарий воспроизведения**:
1. <шаг 1>
2. <шаг 2>
**Входные данные для воспроизведения**:
- Реквизиты: <конкретные значения>
- ТЧ: <состав строк>
- Связанные объекты: <другие документы/справочники, если важны>
**Ожидаемый результат**: <что должно быть>
**Фактический результат**: <что происходит>
**Гипотеза — точка бага**: <Модуль>, функция <Функция>, строка ~N
**Условие срабатывания**: <при каком сочетании факторов>
**Гипотеза подтверждена**: да / нет (если нет — описать почему и указать новую гипотезу)
Структура артефактов после RDPI-цикла
docs/
├── research/<задача>/
│ └── research.md
├── design/<задача>/
│ ├── architecture.puml
│ ├── sequence.puml
│ ├── data-flow.puml
│ ├── decisions.md
│ ├── contracts.md
│ └── testing.md
└── plan/<задача>/
├── overview.md
├── phase-1.md
└── phase-N.md
Справочники
