1c-typical-safe-change

Быстрый старт

1. •Запросить или восстановить из контекста вход по шаблону: Контекст, Текущее поведение, Ожидаемое поведение, Ограничения, Артефакты.
2. •Перед реализацией обновить docs/work-plan.md:
   • •добавить шаги со статусами planned, in_progress, done, blocked;
   • •после каждого шага фиксировать результат, риск и следующий шаг;
   • •добавить строку в Лог обновлений с датой/временем.
3. •Предложить краткие варианты решения и выбрать минимально рискованный.
4. •Реализовать минимальным безопасным инкрементом с приоритетом расширения над правкой типового.
5. •Пройти чеклист проверки и зафиксировать риски, совместимость и откат.

Рабочий процесс

1. Диагноз

1. •Проверить фактическое поведение по артефактам: модуль формы, объектный модуль, запросы, логи.
2. •Явно сформулировать причину проблемы в терминах бизнес-поведения.
3. •Зафиксировать предположения по совместимости: УТ 11.5, ERP 2.5, КА 2.5.

2. Варианты решения

1. •Дать 2-3 коротких варианта.
2. •Для каждого варианта указать влияние на обновляемость типовой конфигурации.
3. •Рекомендовать вариант с минимальным числом перехватов и побочных эффектов.

3. Реализация

1. •Держать клиентский код тонким; тяжелую логику и запросы переносить на сервер.
2. •Для форм:
   • •явно описывать точку встраивания;
   • •добавлять защиту от повторного запуска событий;
   • •фиксировать запасной вариант, если типовая форма изменится.
3. •Для запросов:
   • •выбирать только нужные поля;
   • •не выполнять повторяющиеся запросы в циклах;
   • •учитывать индексы и объем данных для частых отборов.
4. •Для кода:
   • •использовать имена процедур по бизнес-смыслу;
   • •держать процедуры небольшими и с одной ответственностью;
   • •формировать явные сообщения об ошибках с бизнес-контекстом.

4. Проверка

1. •Сверить результат с docs/definition-of-done.md.
2. •Пройти релевантные сценарии из docs/test-scenarios-price-loader.md.
3. •Проверить риски регрессии и обновить docs/known-issues.md при необходимости.
4. •Добавить краткую техническую заметку: что изменено и почему.

5. Фиксация результата

1. •Обновить docs/work-plan.md:
   • •финальные статусы шагов;
   • •лог обновлений;
   • •риски и следующий шаг.
2. •Если выявлено неизвестное знание по проекту:
   • •записать это в docs/work-plan.md (раздел Лог обновлений);
   • •добавить/уточнить постоянное правило в AGENTS.md.
3. •Сделать коммит сразу после логически завершенного шага:
   • •feat: ... новое поведение;
   • •fix: ... исправление;
   • •refactor: ... без изменения поведения;
   • •docs: ... только документация.

Чеклист перед сдачей

• •Ожидаемое поведение воспроизведено.
• •Риски регрессии перечислены.
• •Проверки по сценариям пройдены или явно отмечены пропуски.
• •Добавлена техническая заметка (что и почему изменено).
• •План и лог обновлений актуальны.