1c-feature-dev

Принципы

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

Артефакты

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

Файл	Фаза	Описание
01-requirements.md	1	Требования, оценка сложности
02-exploration.md	2	Паттерны, архитектура, уточнения
03-architecture.md	3	План реализации с архитектурными инвариантами
04-plan-review.md	4	Ревью плана (сложные/критичные)
05-implementation-stage-NN.md	5	Отчёт по этапу N: что сделано, файлы, решения, контекст для следующего этапа
05-implementation-summary.md	5	Итоговый лог реализации (создаётся после завершения ВСЕХ этапов)
06-code-review.md	6	Результаты ревью кода
07-summary.md	7	Итоговое резюме
08-documentation.md	7	Лог генерации документации (опционально)

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

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-файлы — они содержат полный контекст каждого выполненного этапа.

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

Уровень	Описание	Пример
Простая	Очевидная реализация, 1-2 файла	Добавить реквизит, простой обработчик
Средняя	Несколько модулей, понимание архитектуры	Новая печатная форма, доработка формы
Сложная	Несколько подсистем, неочевидные решения	Новый документооборот, интеграция
Критичная	Архитектурные изменения, высокие риски	Переработка подсистемы, миграция

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

---

Фаза 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. Представь резюме пользователю