1c Feature Dev

Принципы

• Адаптивность: глубина анализа и количество агентов зависят от сложности
• Ранняя валидация: ревью плана до реализации, а не после
• Атомарные шаги: этапы с критериями приемки и проверками
• Отслеживание прогресса: отмечай завершённые фазы в списке задач
• Устойчивость к сбоям агентов: если агент вернул пустой, бесполезный или противоречивый результат — перезапусти с уточнённым фокусом (макс. 1 повтор). При повторной неудаче — продолжай своими силами и отметь это в артефакте

Артефакты

Папка задачи: .tasks/[YYYY]/[MM]/[DD]/[feature-name]/ (дата начала работы).

Файл создаётся только если для него есть содержание.

05-implementation-stage-NN.md создаётся после каждого завершённого этапа — это обеспечивает возможность продолжения работы в новом чате с точного места остановки.

Передача контекста агентам

При запуске любого агента передавай полные пути к артефактам от корня проекта, например: .tasks/2026/02/12/print-form-invoice/01-requirements.md. Агенты работают в изоляции и не знают текущую папку задачи.

Возобновление задачи

Если пользователь просит продолжить ранее начатую задачу — найди папку в .tasks/ и определи фазу по артефактам:

• Есть 08-documentation.md → задача завершена полностью (включая документацию), сообщи пользователю
• Есть 07-summary.md → проверь конфигурацию документации в CLAUDE.md целевого проекта: если documentation: true → продолжи с шага 4 Фазы 7 (документация); если нет → задача завершена, сообщи пользователю
• Есть 06-code-review.md → продолжи с Фазы 7 (итоги)
• Есть 05-implementation-summary.md → продолжи с Фазы 6 (ревью)
• Есть файлы 05-implementation-stage-*.md → возобновление внутри Фазы 5:
  1. Прочитай 03-architecture.md → определи общее количество этапов
  2. Найди все 05-implementation-stage-NN.md → определи последний
  3. Прочитай последний stage-файл → проверь статус:
     • Статус: ЗАВЕРШЁН → следующий этап = NN + 1
     • Статус: В РАБОТЕ → этап был прерван, продолжи его (проверь git diff для понимания что уже сделано)
  4. Прочитай секцию «Контекст для следующего этапа» из последнего завершённого stage-файла
  5. Если NN < общего количества этапов → продолжи Фазу 5 с этапа NN+1
  6. Если NN = общему количеству → все этапы завершены, создай 05-implementation-summary.md и перейди к Фазе 6
• Есть 03-architecture.md с - [ ] или - [ ] 🔄, нет файлов 05-implementation-stage-* → начни Фазу 5 с Этапа 1
• Есть 03-architecture.md без незакрытых этапов → продолжи с Фазы 4 (валидация)
• Есть 02-exploration.md, нет 03-architecture.md → продолжи с Фазы 3 (архитектура)
• Есть только 01-requirements.md → продолжи с Фазы 2 (исследование)

Прочитай все существующие артефакты для восстановления контекста. При возобновлении Фазы 5 обрати особое внимание на stage-файлы — они содержат полный контекст каждого выполненного этапа.

Оценка сложности

Сложность определяет поведение в каждой фазе (см. пометки «адаптивность»).

Фаза 0: Проверка окружения

Цель: убедиться, что обязательные MCP-серверы доступны до начала работы

Действия:

1. Проверь доступность каждого обязательного MCP-сервера — вызови любой базовый tool:
   • EDT MCP Server (поиск метаданных, проверка синтаксиса)
2. Составь карту доступности и сообщи пользователю: какие MCP доступны, какие нет
3. Если обязательный MCP недоступен → ОСТАНОВИСЬ. Сообщи пользователю:
   • Какой сервер недоступен
   • Зачем он нужен
   • Ссылку на установку (см. mcp-requirements.md)
   • Предложи: запустить сервер и повторить, или продолжить без MCP (с предупреждением о рисках)
4. Если все обязательные MCP доступны → переходи к Фазе 1

Фаза 1: Сбор требований

Цель: понять задачу, уточнить неясности, оценить масштаб

Начальный запрос: $ARGUMENTS

Действия:

1. Если запрос неясен — спроси: какую проблему решает, что должна делать доработка, есть ли ограничения
2. Резюмируй понимание и получи подтверждение
3. Оцени сложность (см. таблицу выше), обоснуй
4. Создай папку задачи, список задач со всеми фазами
5. Сохрани 01-requirements.md: исходный запрос, Q&A, резюме, требования, сложность

Фаза 2: Исследование кодовой базы

Цель: понять существующий код, паттерны и зависимости

Адаптивность: решай сам — сколько агентов 1c-code-explorer запустить (1-4), параллельно или последовательно. Глубина важнее ширины: лучше углубиться последовательно, чем дублировать параллельно.

Типичные фокусы для агентов (распределяй по необходимости):

• Метаданные и структура: объекты метаданных, реквизиты, табличные части, формы
• Потоки выполнения: цепочки вызовов, обработчики, точки входа в затрагиваемых модулях
• Похожие доработки: паттерны реализации аналогичных задач в кодовой базе
• Зависимости и влияние: кто использует затрагиваемые объекты, оценка каскадных изменений

Действия:

1. Запусти агентов 1c-code-explorer с путём к 01-requirements.md и указанием фокуса
2. Прочитай ключевые файлы, возвращённые агентами
3. Если понимания недостаточно — запусти ещё агентов для углубления
4. Если после исследования появились технические вопросы (граничные случаи, обработка ошибок, интеграции, обратная совместимость, производительность) — задай их пользователю и дождись ответов
5. Переоцени сложность: если исследование показало, что задача сложнее/проще, чем оценено в Фазе 1 — обнови оценку в 01-requirements.md и скорректируй подход
6. Сохрани 02-exploration.md: паттерны, похожие доработки, ключевые компоненты, архитектурные инсайты, прочитанные файлы, Q&A (если были)

Фаза 3: Проектирование архитектуры

Цель: спроектировать архитектуру реализации

Адаптивность:

• Простая/средняя: 1 агент 1c-code-architect, один практичный план. Для средней — опционально 2 агента, если решение неочевидно
• Сложная/критичная: 2-3 агента параллельно (минимальные изменения / чистая архитектура / прагматичный баланс). Представь все варианты с рекомендацией, спроси пользователя

Действия:

1. Запусти агентов с путями к 01-requirements.md, 02-exploration.md
2. Создай 03-architecture.md:
   • Постановка задачи, сложность, выбранный подход с обоснованием
   • Паттерны и соглашения из Фазы 2
   • Архитектурные инварианты — список правил, которые НЕЛЬЗЯ нарушить при реализации ни на одном этапе. Примеры:
     • «Все обращения к контрагентам ТОЛЬКО через модуль КонтрагентыСервер»
     • «Регистр обновляется ТОЛЬКО при проведении документа»
     • «Форма НЕ обращается к БД напрямую — только через серверные методы»
     • «Обращение к реквизитам через ОбщегоНазначения.ЗначениеРеквизитаОбъекта»
     • Инварианты формулируются на основе: правил из 1c-rules.md, паттернов из 02-exploration.md, специфики конкретной задачи
   • Этапы реализации (чеклист):
     • Гранулярность: простая = 1, средняя = 2-4, сложная = 4-8, критичная = 5-10+
     • Атомарность: этап завершается за 1 сессию агента, имеет проверяемый результат
     • Формат: - [ ] **Этап N**: описание + файлы + критерии приемки + зависимости
     • Каждый этап включает поле «Контекст для следующего этапа»: что создаётся на этом этапе и понадобится на следующих (экспортные процедуры, объекты метаданных, зависимости)
   • Mermaid-диаграммы (архитектура, потоки данных)
   • План самодостаточен — понятен без контекста беседы

Фаза 4: Валидация плана

Цель: убедиться в корректности плана ДО реализации

Ревью агентом (только сложные/критичные)

1. Запусти агента 1c-code-architect для ревью
2. Передай все артефакты: 01-requirements.md, 02-exploration.md, 03-architecture.md
3. Фокус: полнота, корректность, реалистичность, зависимости этапов
4. При проблемах — обнови 03-architecture.md, повтори ревью (макс. 2 итерации)
5. Сохрани 04-plan-review.md

Одобрение пользователем (ВСЕ задачи, включая простые)

1. Представь план: краткое резюме + этапы с критериями приемки
2. Спроси: «План готов к реализации, можем начинать?»
3. Если пользователь отклоняет или просит изменения:
   • Уточни, что именно не устраивает
   • Скорректируй 03-architecture.md
   • Представь обновлённый план повторно

НЕ ПЕРЕХОДИ К ФАЗЕ 5 БЕЗ ЯВНОГО ОДОБРЕНИЯ ПОЛЬЗОВАТЕЛЯ

Фаза 5: Реализация

Цель: построить доработку по плану, создавая артефакт после каждого этапа для возможности продолжения в новом чате

Адаптивность:

• До 4 этапов: один агент 1c-code-writer на все этапы
• 5+ этапов: разбей на группы по 3-4 этапа, запускай агентов последовательно. Каждый следующий получает путь к плану, предыдущие stage-файлы и информацию, какие этапы уже выполнены

Действия:

1. Прочитай 03-architecture.md, включая секцию «Архитектурные инварианты»

2. Если это возобновление — прочитай все существующие 05-implementation-stage-*.md и определи, с какого этапа продолжать (см. «Возобновление задачи»)

3. Запусти агента 1c-code-writer:

   • Передай путь к плану и укажи правила: 1c-rules.md, 1c-ssl.md, 1c-edt-metadata.md
   • Если доработка затрагивает запросы — дополнительно укажи 1c-query-optimization.md
   • Передай архитектурные инварианты из 03-architecture.md
   • Если есть предыдущие stage-файлы — передай путь к последнему (секция «Контекст для следующего этапа»)
   • Этапы последовательно, с критериями приемки
   • Агент ОБЯЗАН обновлять чеклист этапов в 03-architecture.md: при начале этапа - [ ] → - [ ] 🔄, при завершении - [ ] 🔄 → - [x]

4. После каждого завершённого этапа — агент создаёт 05-implementation-stage-NN.md (NN = номер этапа с ведущим нулём):

   # Этап N: <название из плана>
   
   ## Статус: ЗАВЕРШЁН | В РАБОТЕ
   
   ## Что сделано
   - <конкретные действия>
   
   ## Изменённые файлы
   - <путь к файлу> (создан | изменён, строки X-Y)
   
   ## Ключевые решения
   - <решение и обоснование>
   
   ## Архитектурные инварианты (проверено)
   - [x] <инвариант 1>
   - [x] <инвариант 2>
   
   ## Контекст для следующего этапа
   - <экспортные процедуры, созданные объекты, зависимости — всё, что нужно знать для продолжения>
   

5. Мини-валидация после каждого этапа (DoD):

   • Проверь критерии приемки этапа из 03-architecture.md
   • Запусти MCP-валидацию изменённых объектов (синтаксис, ошибки проекта)
   • Проверь архитектурные инварианты
   • Если критерии НЕ выполнены или есть ошибки → исправь до перехода к следующему этапу
   • Обнови статус в stage-файле: В РАБОТЕ → ЗАВЕРШЁН только после прохождения валидации

6. Пауза между этапами (опционально):

   • Проверь CLAUDE.md целевого проекта на наличие настройки pause_between_stages: true (в секции 1c-feature-dev)
   • Если true → после каждого этапа сообщи пользователю: «Этап N завершён (N из M). Продолжить с Этапом N+1 или хотите проверить результат?»
   • Если настройка отсутствует или false → продолжай автоматически

7. При невыполненных этапах — запусти агента повторно с описанием оставшегося и путём к последнему stage-файлу

8. После завершения ВСЕХ этапов — создай 05-implementation-summary.md:

   # Итог реализации
   
   ## Статус: ВСЕ ЭТАПЫ ЗАВЕРШЕНЫ (N/N)
   
   ## Выполненные этапы
   | Этап | Описание | Файл отчёта |
   |------|---------|-------------|
   | 1 | <описание> | 05-implementation-stage-01.md |
   | 2 | <описание> | 05-implementation-stage-02.md |
   
   ## Все изменённые файлы
   - <сводный список из всех stage-файлов>
   
   ## Технический долг
   - <если что-то осталось>
   

Фаза 6: Ревью кода

Цель: проверить качество кода и валидировать через MCP

Адаптивность: для простых задач — пропусти ревью агентом, но MCP-валидацию выполни всегда.

Действия:

1. MCP-валидация (все задачи): запусти перевалидацию изменённых объектов через MCP, проверь отсутствие новых ошибок проекта. При наличии ошибок — исправь до ревью
2. Ревью агентом (средние, сложные, критичные): запусти 1c-code-reviewer с путями к 03-architecture.md и 05-implementation-summary.md (список изменённых файлов)
   • Фокус: баги, соответствие плану, 1c-rules.md, читаемость, DRY
   • Reviewer решает, нужен ли 1c-code-simplifier — если код избыточно сложен, запускает его самостоятельно
3. Сохрани 06-code-review.md
4. Представь проблемы пользователю, спроси:
   • Исправить сейчас → запусти 1c-code-writer, затем повторное ревью (макс. 2 итерации)
   • Исправить позже → добавь в 03-architecture.md секцию «Технический долг»
   • Продолжить как есть

Фаза 7: Итоги

Цель: задокументировать результат

Действия:

1. Отметь все задачи как завершённые
2. Сохрани 07-summary.md:
   • Что построено (ссылки на этапы)
   • Ключевые решения
   • Изменённые файлы (git diff --stat)
   • Технический долг (если есть)
   • Предлагаемые следующие шаги
3. Если доработка содержит бизнес-логику — предложи пользователю сгенерировать тесты агентом 1c-code-test-generator (YaXUnit / Vanessa Automation)
4. Документация (опционально):
   • Прочитай CLAUDE.md целевого проекта (корень проекта)
   • Найди секцию ## Documentation (или ## Документация)
   • Если секция существует и documentation: true: a. Извлеки конфигурацию: documentation-types (по умолчанию [technical, user]), documentation-technical-path (по умолчанию docs/technical/), documentation-user-path (по умолчанию docs/user/) b. Спроси пользователя: «Сгенерировать документацию для этой доработки? Настроенные типы: {documentation-types}» c. При согласии — запусти агента 1c-code-documenter:
     • Передай пути к артефактам: 01-requirements.md, 03-architecture.md, 05-implementation-summary.md, 07-summary.md
     • Передай documentation-types, documentation-technical-path, documentation-user-path из конфигурации d. Сохрани 08-documentation.md: какие файлы документации созданы, пути к ним
   • Если секция отсутствует или documentation: false — пропусти молча
5. Представь резюме пользователю