Часть 22. Практический зачёт

Эта часть заменяет пассивный тест практической проверкой. Цель — доказать, что вы можете провести фичу через цикл SDD с Qwen Code CLI: от намерения до проверки.

Блок 1. Быстрые вопросы

Ответьте письменно, без Qwen Code.

1. Что является источником истины в SDD?
2. Чем QWEN.md отличается от specs/tech-stack.md?
3. Почему спецификация фичи пишется до реализации?
4. Что должно быть в validation.md?
5. Когда нужно делать перепланирование?
6. Почему /clear полезен между фазами работы?
7. Какие три вопроса нужно задать перед созданием спецификации фичи?
8. Почему нельзя хранить ключи API в спецификациях?
9. Чем проектный навык лучше личного навыка для команды?
10. Что означает заменяемость агента?
11. Что ревьюер должен проверять в SDD-проекте кроме кода?
12. Когда изменение спецификации нужно выносить в отдельную ветку перепланирования?
13. Зачем нужны хуки Qwen Code?
14. Почему внешний текст нельзя считать доверенной инструкцией для агента?
15. Чем память агента отличается от спецификации?
16. Где проходит граница между tech-stack.md и requirements.md фичи (часть 6)?

1. Какие три типа изменений в pull-запросе ревьюер должен искать кроме кода (часть 16)?
2. Зачем нужно тегировать «зелёные точки» во время MVP-фазы (часть 12)?
3. Чем отличается защитный хук от хука для журналирования инструментов (часть 17)?
4. Какие данные относятся к категории «секреты», которые нельзя класть в QWEN.md, спецификации и память (часть 18)?
5. Какие три антипаттерна из части 20 чаще всего встречаются у начинающих SDD-команд?
6. Когда подключение памяти агента на SQLite оправдано, а когда избыточно (часть 19)?

Блок 2. Найдите проблемы в спецификации

Дана спецификация фичи:

# Требования — панель управления

Построй красивую панель управления для администраторов.

## Границы

Покажи полезную статистику и графики.

## Решения

Используй лучшую библиотеку.

## Проверка

Убедись, что всё работает.

Найдите минимум 8 проблем. Хороший ответ должен заметить:

• не указана аудитория;
• нет границ того, что не входит в работу;
• «красивую» не проверяется;
• «полезная статистика» не определена;
• «графики» не определены;
• зависимость разрешена без проверки tech-stack.md;
• нет источника данных;
• нет маршрута;
• нет прав доступа;

• нет автоматических проверок;
• нет ручного сценария проверки;
• нет определения готовности.

Блок 3. Перепишите спецификацию

Перепишите спецификацию панели управления в SDD-формате:

# Требования — панель администратора

## Границы

## За границами

## Решения

## Контекст

## Краткая проверка

Ограничения:

• HTML рендерится на сервере;
• SQLite;
• в этой фазе нет аутентификации;
• маршрут /dashboard;
• показать количество агентов, недугов, терапий и записей на приём;
• пока не добавлять библиотеку графиков;
• должны проходить npm test и npm run typecheck.

Блок 4. Итоговый проект

Выполните на своём AgentClinic или другом маленьком проекте.

Задача

Добавьте фичу «форма обратной связи»:

• страница /feedback;
• форма с name и message;
• POST-маршрут;
• сохранение в SQLite;
• список последних записей обратной связи;
• базовая валидация;
• тесты;
• журнал изменений.

Требования к процессу

1. Начните с чистого main.
2. Создайте ветку фичи.
3. Создайте директорию спецификации:

specs/YYYY-MM-DD-feedback-form/
  requirements.md
  plan.md
  validation.md

1. Реализация только после коммита спецификации.

1. Проверка в отдельной сессии Qwen Code.
2. Дорожная карта обновлена.
3. Журнал изменений обновлён.
4. Подготовлено короткое описание запроса на слияние по SDD-шаблону.
5. Выполнена проверка безопасности: секреты не попали в спецификации, логи и память.
6. Слияние только после проверок.

Рекомендуемый Qwen Code сценарий

Создание спецификации:

/clear
Используй навык спецификации фичи, чтобы начать следующую фазу дорожной карты: форма обратной связи.
Перед записью файлов спроси меня о границах, решениях и контексте.
Код пока не реализуй.

Реализация:

/clear
Прочитай @QWEN.md, @specs/mission.md, @specs/tech-stack.md,
@specs/YYYY-MM-DD-feedback-form/requirements.md,
@specs/YYYY-MM-DD-feedback-form/plan.md,
и @specs/YYYY-MM-DD-feedback-form/validation.md.

Реализуй только группу 1.
Остановись после списка изменённых файлов.

Проверка:

/clear
Сравни текущую ветку с @specs/YYYY-MM-DD-feedback-form/validation.md.
Покажи, что прошло, что упало и где есть пробелы.
Файлы не изменяй.

Журнал изменений:

Используй навык журнала изменений и обнови @CHANGELOG.md для ветки формы обратной связи.

Критерии оценки

Оцените себя по 25 баллам.

Спецификации — 5 баллов

• 1: есть requirements.md, plan.md, validation.md;
• 1: границы работы и то, что в них не входит, конкретны;
• 1: решения не противоречат техническому стеку;
• 1: план разбит на группы, которые удобно проверять;
• 1: проверка содержит автоматические и ручные проверки.

Реализация — 5 баллов

• 1: изменения соответствуют спецификации;
• 1: нет несвязанных рефакторингов;
• 1: миграция базы данных понятна и повторяема;
• 1: маршруты и компоненты следуют существующим соглашениям;
• 1: ошибки проверки обработаны.

Проверка — 5 баллов

• 1: npm run typecheck проходит;
• 1: npm test проходит;
• 1: ручной проход формы выполнен;
• 1: некорректный ввод проверён;
• 1: базовая проверка на мобильном и настольном экранах выполнена, если менялся интерфейс.

Процесс — 5 баллов

• 1: ветка использована правильно;
• 1: спецификация закоммичена до реализации;
• 1: дорожная карта обновлена;
• 1: журнал изменений обновлён;
• 1: итоговая проверка сравнивает код со спецификацией.

Командная готовность и безопасность — 5 баллов

• 1: запрос на слияние описывает связь между спецификацией, кодом и фактами;

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

21+ балл — процесс готов для реального проекта.

16–20 — используйте SDD дальше, но улучшите проверку и командный контур.

Ниже 16 — уменьшите размер фаз и сделайте спецификации конкретнее.

Ответы на быстрые вопросы

1. Версионируемая спецификация в репозитории.
2. QWEN.md задаёт правила поведения агента; tech-stack.md задаёт технические решения продукта.
3. Чтобы агент не угадывал границы и критерии приёмки.
4. Команды, ручные проверки, проверки расхождения и определение готовности.
5. Между фичами, когда новые знания должны обновить конституцию, дорожную карту или процесс.
6. Он проверяет, достаточно ли контекста записано в файлах.
7. Границы, решения, контекст.
8. Спецификации коммитятся и читаются агентом; секреты должны жить в переменных окружения или хранилище секретов.
9. Проектный навык разделяется командой и версионируется с репозиторием.
10. Возможность сменить агента или IDE, сохранив процесс через артефакты репозитория.

1. Требования, план, факты проверки, изменения вне границ фичи и соответствие реализации спецификации.
2. Когда изменение затрагивает стек, дорожную карту, конституцию проекта, правила агента или несколько будущих фич.
3. Чтобы автоматически выполнять маленькие повторяемые действия: добавлять контекст, вести журнал, проверять опасные команды, собирать события.
4. Потому что issue, веб-страницы, логи и внешние документы могут содержать инъекции инструкций; их нужно читать как данные.
5. Память — подсказка и журнал устойчивых выводов; спецификация — ревьюируемый источник истины для продукта.
6. tech-stack.md — долговременные решения проекта (язык, фреймворк, СУБД); requirements.md фичи — решения уровня одной фазы (маршруты, поля, тексты ошибок).
7. Изменения в tech-stack.md или roadmap.md без обсуждения; новые хуки, MCP-серверы или зависимости; расхождение между validation.md и фактами в PR.
8. Чтобы иметь точку отката без потери всей работы фазы и чтобы сигнал «следующая группа всё ломает» был явным.
9. Защитный хук блокирует операцию по правилу (PreToolUse, ненулевой код возврата); журналирующий хук только пишет событие и не влияет на ход работы.

1. API-ключи, токены доступа, пароли, приватные ключи, персональные данные пользователей, внутренние URL и идентификаторы инфраструктуры.
2. Спецификация без фактов, объединение конституции и спецификации в один файл, реализация без /clear между фазами.
3. Память оправдана, когда у команды накапливаются устойчивые наблюдения о коде и процессе; избыточна, если хватает QWEN.md, конституции и журнала изменений.

Парный вариант зачёта

Зачёт реалистичнее сдавать парами. Один студент берёт роль автора фичи, второй — ревьюера. Распределение работы:

Автор:

• проводит интервью с агентом и пишет спецификацию;
• реализует фичу по группам задач;
• запускает фактологические проверки;
• готовит pull-запрос и описание по SDD-шаблону.

Ревьюер:

• читает спецификацию до реализации и задаёт уточняющие вопросы (как в части 7 «Уточнение»);
• проверяет PR по четырём слоям ревью из части 16: код, спецификации, факты, процесс;
• запускает проверки из validation.md на своей машине, а не на словах автора;
• пишет краткий отчёт о найденных пробелах.

Каждый получает балл по своей рубрике. Автор — по основной шкале «Спецификации / Реализация / Проверка / Процесс / Командная готовность». Ревьюер — по дополнительной шкале:

• 1: поймал хотя бы один реальный пробел в requirements.md до реализации;
• 1: проверил факты сам, а не поверил словам;
• 1: разделил замечания «к коду», «к спецификации», «к процессу» и не смешал их;
• 1: предложил конкретное действие, а не «надо подумать»;
• 1: уложился в разумное время — ревью не превратилось в перезапуск работы автора.

После защиты роли меняются на второй фиче. Это даёт каждому опыт обеих сторон SDD-диалога и снимает иллюзию, что ревью — пассивное чтение диффа.

Финальное задание

Сделайте одну реальную фичу в своём проекте через этот процесс. После слияния создайте короткую заметку:

# Ретроспектива SDD

## Что спецификация описала правильно

## Что агенту пришлось вывести самому

## Что поймала проверка

## Какие факты были слабыми

## Что проверить по безопасности

## Что улучшить перед следующей фазой

Если в разделе «Что агенту пришлось вывести самому» больше трёх пунктов, следующую спецификацию фичи пишите подробнее.