dd-delivery · git:20260918.6e0b441 · 2026-09-18 · sha256 a8a60701f166bfd9
dd-delivery git:20260918.6e0b441A
Immutable. This exact content never changes and is served at /api/v1/blob/a8a60701f166bfd9.
--- name: dd-delivery description: Трек Delivery в DD-SDD. Берёт RFC из docs/rfc/, реализует задачу с тестами, дописывает в RFC раздел «Тест инструкции», обновляет спецификации в docs/specs/ и переносит design doc в docs/rfc/archive/ после готовности или по команде в чате. trigger_phrases: - "начинаем делать" - "берём в работу" - "реализуем по RFC" - "имплементируем" - "приступаем к реализации" - "dd delivery" - "завершаем фичу" - "фича готова" - "закрой спеку" - "перенеси в архив" related_skills: - dd-sdd - dd-discovery --- # dd-delivery Трек **Delivery**: реализовать фичу по RFC, покрыть тестами, дописать в RFC инструкцию по проверке результата, привести `docs/specs/` в соответствие с фактическим состоянием системы и убрать отработавший design doc в архив. ## Когда использовать - RFC создан и прошёл ревью (статус `review`/`approved`) - Пользователь говорит «берём в работу», «начинаем делать», «реализуем по RFC» - Или фича уже сделана и нужно закрыть цикл: «завершаем», «фича готова», «перенеси в архив» Рекомендуемый паттерн — **чистая сессия**: кодинг-агент получает только RFC (~1000 слов). Спека самодостаточна, история сессии, где она писалась, не нужна. ## Workflow ### Шаг 1. Найти RFC - Если пользователь указал фичу — открыть `docs/rfc/<slug>.md` - Если не указал — показать список активных RFC из `docs/rfc/` (без `archive/`) и спросить, какой берём в работу ### Шаг 2. Проверить готовность RFC Прочитать RFC и проверить: - Статус не `draft` (если `draft` — предупредить и спросить, точно ли начинаем без ревью) - Заполнены критерии приёмки и дорожная карта - Декомпозиция сходится: составляющие, критерии приёмки и дорожная карта описывают одни и те же блоки — нет составляющей без критерия и шага карты, которого нет в составляющих Если критерии приёмки пустые или размытые, либо декомпозиция не сходится — предложить сначала дополнить RFC (вернуться к **dd-discovery**: декомпозиция — его ответственность, delivery её не переписывает молча). ### Шаг 3. Составить план реализации На основе разделов «Составляющие и особенности» и «Дорожная карта» RFC: - Разбить работу на конкретные задачи - Зафиксировать порядок и зависимости - Создать todo-лист сессии (todowrite) План показать пользователю перед стартом. ### Шаг 4. Реализовать - Перевести статус RFC во frontmatter в `implementing` - Реализовывать задачи по плану - По ходу работы отмечать выполненные пункты в чеклисте «Критерии приемки» прямо в файле RFC (`- [ ]` → `- [x]`) ### Шаг 5. Тесты Реализация не считается завершённой без проверки: - Покрыть тестами поведение, описанное в критериях приёмки — в стиле и стеке, принятых в проекте - Прогнать тесты проекта (как минимум затронутую область) и линтеры/типы, если они настроены - Красные тесты — чинить, а не игнорировать и не подгонять под код - Если тестов в проекте нет или автотест невозможен — описать, как проверялось вручную, и согласовать это с пользователем ### Шаг 6. Дописать в RFC раздел «Тест инструкции» По итогам реализации дописать в файл RFC раздел `## Тест инструкции` — пошаговую инструкцию, как проверить результат работы. Формат: - каждый шаг проверки — заголовок третьего уровня `### <что проверяем>`; - внутри шага — список пунктов, где каждый пункт даёт **ссылку** на то, чем и где проверяем: файл теста, команда, страница UI, эндпоинт API, миграция, конфиг, лог; - ссылки — относительные пути от корня проекта в Markdown-формате: `[tests/feature/OnboardingTest.php](../../tests/feature/OnboardingTest.php)`; для UI и API — URL или маршрут. Шаги идут в том порядке, в котором проверяющий их выполняет: от автотестов к ручным сценариям. Инструкция пишется так, чтобы по ней мог пройти человек, не участвовавший в реализации. ```markdown ## Тест инструкции ### 1. Автотесты - [tests/feature/OnboardingTest.php](../../tests/feature/OnboardingTest.php) — сценарии регистрации и первого входа - Запуск: `npm test -- onboarding` ### 2. Ручная проверка UI - [/onboarding](http://localhost:3000/onboarding) — пройти шаги мастера до конца - [src/components/OnboardingWizard.tsx](../../src/components/OnboardingWizard.tsx) — компонент, отвечающий за шаги ### 3. API - `POST /api/onboarding/complete` — вернуть 200 и записать флаг в профиль - [docs/specs/user-profile.md](../specs/user-profile.md) — ожидаемое состояние профиля после завершения ``` Раздел уходит в архив вместе с RFC — это зафиксированный способ перепроверить фичу позже. Если часть проверок описана в `docs/specs/`, в инструкции достаточно ссылки на соответствующий документ. ### Шаг 7. Проверка по критериям приёмки Когда все задачи выполнены и тесты зелёные — сверить результат с каждым критерием приёмки: - Все критерии закрыты → переходим к шагу 8 - Что-то не закрыто → показать список и спросить: доделываем или закрываем с оговорками (незакрытое зафиксировать в `docs/specs/` как известное ограничение) ### Шаг 8. Обновить спецификации в docs/specs/ Прочитать статьи в `docs/specs/` (включая вложенные Markdown-файлы). Найти документы, связанные с RFC по предметной области, компонентам, сущностям, API, пользовательским сценариям или уже зафиксированным решениям. - Если связанные спеки есть — дополнить их итоговым состоянием фичи: новым поведением, принятыми решениями, отклонениями от RFC, ограничениями и ссылкой на архивный RFC, когда она полезна для трассировки. Не дублировать один и тот же материал в отдельной сводке. - Сохранять структуру, терминологию и полезное содержимое существующих документов. Обновлять или заменять устаревшие утверждения, а не дописывать противоречащие им параллельные версии. - Если связанные спеки отсутствуют — создать `docs/specs/<slug>.md` (и папку при необходимости) по формату ниже. - Если RFC затрагивает несколько самостоятельных тем — обновить каждый релевантный документ; отдельную сводку создавать только для той части решения, которой ещё негде жить. - Если фича ничего не меняет в описанном поведении системы (например, чисто внутренний рефакторинг) — спеки можно не трогать, но сказать об этом пользователю явно. Формат нового документа: ```markdown --- title: "<название фичи>" status: done completed: YYYY-MM-DD rfc: ../rfc/archive/<slug>.md --- # Spec: <название фичи> ## Что сделано <краткая сводка: итоговое состояние, что реально работает> ## Ключевые решения <решения, принятые в ходе реализации, включая отклонения от RFC> ## Отклонения от RFC <что сделали иначе и почему; если не было — «не было»> ## Известные ограничения / дальнейшие шаги <незакрытые критерии, техдолг, идеи на будущее; если нет — «нет»> ``` Документация должна описывать фактическое текущее состояние системы, а не план из RFC. Архивный RFC остаётся историей принятия решения; `docs/specs/` — единым актуальным источником знаний по предметной области. ### Шаг 9. Перенести RFC в архив Архивируем, когда всё готово, — либо раньше, по прямой команде в чате («перенеси в архив», «закрой спеку»). По команде архивируем даже при незакрытых критериях, но незакрытое сначала фиксируем в `docs/specs/` как известное ограничение. - Обновить frontmatter RFC: `status: done`, добавить `completed: YYYY-MM-DD` - Переместить файл: `docs/rfc/<slug>.md` → `docs/rfc/archive/<slug>.md` - В git-репозитории использовать `git mv` ### Шаг 10. Отчитаться Показать пользователю: - Что реализовано и какие тесты прогнаны (с результатом) - Раздел «Тест инструкции», дописанный в RFC - Созданные и обновлённые документы в `docs/specs/` — что и почему интегрировано в каждый - RFC в архиве: `docs/rfc/archive/<slug>.md` - Предложить внести правки в актуальную документацию ## Правила - Не выходить за рамки RFC: если в работе всплывает что-то за пределами спеки — зафиксировать в разделе «Открытые вопросы» RFC и спросить пользователя - Существенное отклонение от решения, описанного в RFC → сначала обновить RFC, потом код - Отклонения и неожиданные находки — обратная связь для discovery: они попадают в `docs/specs/` и, при необходимости, в новый RFC