git:20260918.6e0b441 to git:20260918.acb1abf

---

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»

- Или фича уже сделана и нужно закрыть цикл: «завершаем», «фича готова», «перенеси в архив»

## 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