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

难度等级: 中等

预计学习时间: 12-16 часов (теория: 4 часа, практика: 8-12 часов)

前置要求: Знание SDD-методологии из частей 1-21 курса

Опыт работы с Qwen Code CLI

Базовые навыки работы с Git и ветками

Понимание структуры specs/ директории

Знакомство с markdown-спецификациями

学习目标: Провести полный цикл SDD-разработки фичи от намерения до слияния, создав спецификацию (requirements.md, plan.md, validation.md), реализовав код и пройдя проверку с оценкой не менее 21 балла по 25-балльной шкале

Выявить минимум 8 критических проблем в некорректной спецификации и переписать её в SDD-формате с конкретными границами, решениями и проверяемыми критериями приёмки

Ответить письменно на 22 контрольных вопроса о принципах SDD, продемонстрировав понимание источника истины, различий между QWEN.md и tech-stack.md, причин написания спецификации до реализации, содержания validation.md и правил безопасности секретов

Выполнить ролевое взаимодействие «автор-ревьюер» в парном зачёте, показав способность давать и получать конструктивную обратную связь по четырём слоям ревью: код, спецификации, факты, процесс

概述: Практический зачёт — кульминация курса SDD (Specification-Driven Development), заменяющая пассивный тест реальной проверкой навыков. Студент должен доказать способность провести фичу через полный цикл: от намерения до проверки с использованием Qwen Code CLI. Зачёт состоит из четырёх блоков: быстрые вопросы (теоретическая база), анализ проблем в спецификации (критическое мышление), переписывание спецификации в SDD-формат (практика документирования) и итоговый проект «форма обратной связи» (полный цикл разработки). Особенность зачёта — поддержка парного варианта, где участники чередуются в ролях автора и ревьюера, что моделирует реальную командную работу и снимает иллюзию пассивности ревью. Оценка по 25-балльной шкале охватывает пять измерений: спецификации, реализация, проверка, процесс, командная готовность и безопасность. Результат 21+ балла означает готовность к промышленному применению SDD.

关键概念: Источник истины в sdd: Версионируемая спецификация в репозитории, а не память агента, устные договорённости или внешние документы. Это позволяет заменять агентов и IDE, сохраняя непрерывность процесса. Любое расхождение между спецификацией и кодом — дефект, подлежащий исправлению.

Qwen.md vs tech-stack.md: QWEN.md задаёт правила поведения агента (как работать), tech-stack.md — технические решения продукта (что использовать). Пересечение недопустимо: конституция агента отделена от архитектуры продукта. tech-stack.md — долговременные решения (язык, фреймворк, СУБД); requirements.md фичи — решения уровня одной фазы (маршруты, поля, тексты ошибок).

Спецификация до реализации: Агент не должен угадывать границы и критерии приёмки. Спецификация фиксирует намерение человека до того, как агент начнёт генерировать код. Это предотвращает «галлюцинации» агента и даёт основу для объективной проверки.

Validation.md: Содержит четыре элемента: команды для автоматических проверок (npm test, typecheck), ручные проверки с конкретными шагами, проверки расхождения (сравнение кода со спецификацией), определение готовности (чёткий критерий завершения фазы). Без validation.md невозможно объективно сказать, завершена ли фича.

Перепланирование: Выполняется между фичами, когда новые знания должны обновить конституцию (QWEN.md), дорожную карту (roadmap.md) или процесс. Изменение спецификации выносится в отдельную ветку, когда затрагивает стек, дорожную карту, конституцию, правила агента или несколько будущих фич.

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

Три вопроса перед спецификацией: Границы (что входит в работу), решения (какие технические выборы сделаны), контекст (какие ограничения и предпосылки существуют). Ответы на эти вопросы формируют структуру requirements.md.

Безопасность секретов: API-ключи, токены доступа, пароли, приватные ключи, персональные данные пользователей, внутренние URL и идентификаторы инфраструктуры нельзя хранить в QWEN.md, спецификациях и памяти агента. Спецификации коммитятся и читаются агентом; секреты должны жить в переменных окружения или хранилище секретов.

Проектный навык vs личный навык: Проектный навык разделяется командой и версионируется с репозиторием. Личный навык привязан к одному пользователю и не наследуется. Проектный навык обеспечивает заменяемость агента — возможность сменить агента или IDE, сохранив процесс через артефакты репозитория.

Заменяемость агента: Возможность сменить агента или IDE, сохранив процесс через артефакты репозитория. Достигается за счёт того, что вся существенная информация находится в версионируемых файлах, а не в памяти агента или привычках конкретного разработчика.

Ревью в sdd-проекте: Ревьюер проверяет не только код, но и требования, план, факты проверки, изменения вне границ фичи и соответствие реализации спецификации. Четыре слоя ревью: код, спецификации, факты, процесс.

Три типа изменений в pr помимо кода: Изменения в tech-stack.md или roadmap.md без обсуждения; новые хуки, MCP-серверы или зависимости; расхождение между validation.md и фактами в PR.

Зелёные точки в mvp-фазе: Тегирование коммитов, дающих работающий инкремент. Обеспечивает точку отката без потери всей работы фазы и делает явным сигнал «следующая группа всё ломает».

Защитный хук vs журналирующий хук: Защитный хук блокирует операцию по правилу (PreToolUse, ненулевой код возврата); журналирующий хук только пишет событие и не влияет на ход работы. Разделение ответственности критично для безопасности.

Память агента на sqlite: Оправдана, когда у команды накапливаются устойчивые наблюдения о коде и процессе. Избыточна, если хватает QWEN.md, конституции и журнала изменений. Память — подсказка и журнал устойчивых выводов; спецификация — ревьюируемый источник истины для продукта.

Антипаттерны начинающих sdd-команд: Спецификация без фактов (невозможно проверить), объединение конституции и спецификации в один файл (нарушение разделения ответственности), реализация без /clear между фазами (утечка контекста и неконтролируемые решения).

Внешний текст как инструкция: Issue, веб-страницы, логи и внешние документы нельзя считать доверенными инструкциями для агента, так как могут содержать инъекции инструкций. Их нужно читать как данные, а не как команды к действию.

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

练习题: 名称: Блок 1: Быстрые вопросы — самопроверка

问题: Пройдите 22 контрольных вопроса, записав ответы письменно без использования Qwen Code. Примеры вопросов: Что является источником истины в SDD? Чем QWEN.md отличается от specs/tech-stack.md? Почему спецификация фичи пишется до реализации? Что должно быть в validation.md? Когда нужно делать перепланирование? Почему /clear полезен между фазами работы? Какие три вопроса нужно задать перед созданием спецификации фичи? Почему нельзя хранить ключи API в спецификациях? Чем проектный навык лучше личного навыка для команды? Что означает заменяемость агента? Что ревьюер должен проверять в SDD-проекте кроме кода? Когда изменение спецификации нужно выносить в отдельную ветку перепланирования? Зачем нужны хуки Qwen Code? Почему внешний текст нельзя считать доверенной инструкцией для агента? Чем память агента отличается от спецификации? Где проходит граница между tech-stack.md и requirements.md фичи? Какие три типа изменений в pull-запросе ревьюер должен искать кроме кода? Зачем нужно тегировать «зелёные точки» во время MVP-фазы? Чем отличается защитный хук от хука для журналирования инструментов? Какие данные относятся к категории «секреты»? Какие три антипаттерна из части 20 чаще всего встречаются у начинающих SDD-команд? Когда подключение памяти агента на SQLite оправдано, а когда избыточно?

解决方案: 1. Версионируемая спецификация в репозитории. 2. QWEN.md задаёт правила поведения агента; tech-stack.md задаёт технические решения продукта. 3. Чтобы агент не угадывал границы и критерии приёмки. 4. Команды, ручные проверки, проверки расхождения и определение готовности. 5. Между фичами, когда новые знания должны обновить конституцию, дорожную карту или процесс. 6. Он проверяет, достаточно ли контекста записано в файлах. 7. Границы, решения, контекст. 8. Спецификации коммитятся и читаются агентом; секреты должны жить в переменных окружения или хранилище секретов. 9. Проектный навык разделяется командой и версионируется с репозиторием. 10. Возможность сменить агента или IDE, сохранив процесс через артефакты репозитория. 11. Требования, план, факты проверки, изменения вне границ фичи и соответствие реализации спецификации. 12. Когда изменение затрагивает стек, дорожную карту, конституцию проекта, правила агента или несколько будущих фич. 13. Чтобы автоматически выполнять маленькие повторяемые действия: добавлять контекст, вести журнал, проверять опасные команды, собирать события. 14. Потому что issue, веб-страницы, логи и внешние документы могут содержать инъекции инструкций; их нужно читать как данные. 15. Память — подсказка и журнал устойчивых выводов; спецификация — ревьюируемый источник истины для продукта. 16. tech-stack.md — долговременные решения проекта; requirements.md фичи — решения уровня одной фазы. 17. Изменения в tech-stack.md или roadmap.md без обсуждения; новые хуки, MCP-серверы или зависимости; расхождение между validation.md и фактами в PR. 18. Чтобы иметь точку отката без потери всей работы фазы и чтобы сигнал «следующая группа всё ломает» был явным. 19. Защитный хук блокирует операцию по правилу; журналирующий хук только пишет событие. 20. API-ключи, токены доступа, пароли, приватные ключи, персональные данные пользователей, внутренние URL и идентификаторы инфраструктуры. 21. Спецификация без фактов, объединение конституции и спецификации в один файл, реализация без /clear между фазами. 22. Память оправдана, когда у команды накапливаются устойчивые наблюдения; избыточна, если хватает QWEN.md, конституции и журнала изменений.

难度: intermediate

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

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

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

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

Границы

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

Решения

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

Проверка

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

Найдите минимум 8 проблем. Запишите каждую проблему и объясните, почему она критична для SDD-процесса.

解决方案: Минимум 11 проблем:

1. Не указана аудитория — «администраторы» не определены, нет понимания, кто именно будет использовать панель.
2. Нет границ того, что не входит в работу — невозможно сказать, когда фича закончена.
3. «Красивую» не проверяется — субъективный критерий, невозможно автоматизировать проверку.
4. «Полезная статистика» не определена — нет конкретных метрик, которые должны отображаться.
5. «Графики» не определены — не указаны типы, источники данных, форматы.
6. Зависимость разрешена без проверки tech-stack.md — «лучшая библиотека» может противоречить утверждённому стеку.
7. Нет источника данных — непонятно, откуда берутся данные для статистики.
8. Нет маршрута — не указан URL, по которому доступна панель.
9. Нет прав доступа — не определено, кто может видеть какие данные.
10. Нет автоматических проверок — validation.md пуст, невозможно CI/CD.
11. Нет ручного сценария проверки — тестировщик не знает, что делать.
12. Нет определения готовности — нет критерия завершения фазы.

难度: intermediate

名称: Блок 3: Перепишите спецификацию в SDD-формате

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

Требуемая структура:

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

Границы

За границами

Решения

Контекст

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

解决方案: ```markdown

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

Границы

• Серверный рендеринг HTML на маршруте /dashboard
• Отображение четырёх счётчиков: агенты, недуги, терапии, записи на приём
• Данные из существующей SQLite-базы
• Базовая вёрстка без внешних CSS-фреймворков

За границами

• Аутентификация и авторизация (фаза без auth)
• Библиотеки графиков (Chart.js, D3 и т.д.)
• Фильтрация, сортировка, поиск по данным
• Экспорт отчётов
• WebSocket-обновления в реальном времени

Решения

• SQL-запросы SELECT COUNT(*) для каждой сущности
• Серверный шаблонизатор проекта (указать конкретный, согласно tech-stack.md)
• Маршрут добавляется в существующий router
• Стили в рамках существующего CSS-подхода проекта

Контекст

• Фаза без аутентификации: панель доступна всем по прямому URL
• SQLite уже используется в проекте, схема существует
• MVP-подход: графики отложены до подтверждения потребности

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

Автоматические:

• npm run typecheck проходит без ошибок
• npm test проходит, включая новые тесты маршрута
• Маршрут /dashboard возвращает HTTP 200

Ручные:

• Открыть /dashboard, увидеть 4 числа
• Проверить, что числа соответствуют реальным данным в базе
• Проверить отображение на мобильном (320px) и десктопе (1280px)
• Проверить, что ссылка на панель отсутствует в навигации (нет auth)

Готовность: все автоматические проверки проходят, ручные проверки выполнены, нет секретов в коде.

难度: intermediate

名称: Блок 4: Итоговый проект — форма обратной связи

问题: Выполните на своём AgentClinic или другом маленьком проекте. Добавьте фичу «форма обратной связи»: страница `/feedback`; форма с `name` и `message`; POST-маршрут; сохранение в SQLite; список последних записей обратной связи; базовая валидация; тесты; журнал изменений. Следуйте процессу: чистый main → ветка фичи → директория спецификации specs/YYYY-MM-DD-feedback-form/ с requirements.md, plan.md, validation.md → коммит спецификации до реализации → реализация по группам → проверка в отдельной сессии Qwen Code → обновление дорожной карты и журнала изменений → pull-запрос по SDD-шаблону → проверка безопасности → слияние после проверок. Используйте рекомендуемые сценарии Qwen Code для каждой фазы.

解决方案: Полный пошаговый процесс:

**Подготовка:**

git checkout main git pull git checkout -b feature/feedback-form mkdir -p specs/2024-01-15-feedback-form

**Фаза 1: Спецификация (сессия Qwen Code):**

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

Создать requirements.md, plan.md, validation.md, закоммитить.

**Фаза 2: Реализация (новая сессия Qwen Code):**

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

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

Повторять для каждой группы плана, тегировать зелёные точки.

**Фаза 3: Проверка (новая сессия Qwen Code):**

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

Исправить найденные проблемы в отдельной сессии.

**Фаза 4: Завершение:**

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

Обновить roadmap.md, подготовить PR по шаблону, проверить отсутствие секретов, выполнить слияние.

**Самооценка по 25 баллам:**
- Спецификации (5): наличие трёх файлов, конкретные границы, соответствие tech-stack.md, группировка плана, автоматические и ручные проверки
- Реализация (5): соответствие спецификации, отсутствие лишних рефакторингов, понятная миграция, соглашения проекта, обработка ошибок
- Проверка (5): typecheck, тесты, ручной проход, некорректный ввод, адаптивность
- Процесс (5): правильная ветка, спецификация до кода, обновлённые roadmap и changelog, проверка соответствия
- Командная готовность и безопасность (5): описание связи в PR, отсутствие изменений вне границ, отсутствие секретов, ревью хуков, явные слабые факты

难度: intermediate

案例研究:
名称: Кейс: AgentClinic — внедрение формы обратной связи через полный цикл SDD

场景: Маленькая команда из двух разработчиков использует AgentClinic (упрощённая система управления клиникой) для обучения SDD-методологии. Продукт работает на Node.js + SQLite с серверным рендерингом. Пользователи жалуются, что нет способа сообщить о проблемах без email. Команда решает добавить форму обратной связи через полный SDD-цикл как учебную фичу для практического зачёта.

挑战: Оба разработчика ранее работали по классической agile-модели с неформальными требованиями. Проблемы: (1) привычка писать код сразу после обсуждения, без документирования; (2) непонимание, зачем нужна validation.md, если «и так всё проверим»; (3) страх, что /clear «сотрёт полезный контекст»; (4) нежелание делать ревью спецификаций, а не только кода; (5) хранение тестового API-ключа в QWEN.md для удобства.

解决方案: Команда применяет парный зачёт: разработчик А — автор, разработчик Б — ревьюер. Автор начинает с /clear и создаёт спецификацию через навык Qwen Code, отвечая на три вопроса (границы, решения, контекст). Ревьюер читает requirements.md до реализации и находит критический пробел: не указано ограничение длины message (SQL-инъекция через длинный текст). Спецификация дорабатывается до коммита. Реализация ведётся по группам с /clear между фазами. Проверка выполняется на машине ревьюера, который обнаруживает, что тесты проходят, но ручная проверка показывает: форма принимает пустое имя (спецификация требовала «базовую валидацию», но не уточняла конкретику). Это фиксируется как «слабый факт» для ретроспективы. Перед слиянием ревьюер проверяет отсутствие секретов — находит тестовый API-ключ в QWEN.md, удаляет, добавляет правило в .gitignore и конституцию проекта.

结果: Фича слита с оценкой 23/25. Потерянные баллы: (1) в validation.md не было явного теста на XSS в message (ручная проверка нашла, но не была формализована), (2) roadmap.md обновлён, но без приоритета следующей фичи. Ретроспектива показала: «Что агенту пришлось вывести самому» — 2 пункта (конкретное ограничение длины, формат отображения ошибок), что приемлемо. Команда зафиксировала правило: если больше 3 пунктов — следующая спецификация пишется подробнее. Проектный навык «спецификация формы обратной связи» добавлен в репозиторий и используется как шаблон для новых фич.

经验教训:
Ревью спецификации до реализации экономит 3-5 часов на переделку кода; найденный ревьюером пробел с ограничением длины предотвратил production-инцидент

/clear между фазами выявил, что validation.md первой версии был неполным — агент не смог его использовать как контекст, что доказало необходимость доработки

Парный формат создаёт здоровое напряжение: автор стремится к конкретике, ревьюер тренирует навык давать конструктивную обратную связь по четырём слоям

Проверка на машине ревьюера, а не на словах автора, нашла расхождение в версиях Node.js, которое typecheck не ловил — это подтвердило важность независимой верификации

Найденный API-ключ в QWEN.md привёл к созданию защитного хука PreToolUse, блокирующего коммиты с паттернами ключей — инвестиция в безопасность окупилась сразу

相关概念:
Источник истины в SDD

Парный зачёт и роли автора-ревьюера

validation.md и четыре элемента проверки

Безопасность секретов и защитные хуки

/clear между фазами

Ретроспектива SDD и порог в 3 пункта

Проектный навык vs личный навык

名称: Кейс: Переписывание спецификации панели администратора — от антипаттерна к образцу

场景: Разработчик-студент получает задание переписать спецификацию панели управления из блока 2 курса. Исходная спецификация типична для «agile-спешки»: красивые слова, субъективные критерии, отсутствие границ. Студент должен применить SDD-подход с учётом реальных ограничений проекта AgentClinic.

挑战: Студенту сложно отказаться от привычных формулировок типа «красивая панель» и «полезная статистика». Психологическое сопротивление: кажется, что конкретика «убивает творчество». Техническая сложность: нужно учесть отсутствие аутентификации в текущей фазе, что создаёт риск утечки данных. Ещё одна проблема: студент хочет добавить Chart.js «про запас», хотя явно запрещено.

解决方案: Студент проходит чеклист из 11 проблем исходной спецификации. Для каждой проблемы формулирует конкретную замену: «красивая» → «базовая вёрстка в рамках существующего CSS-подхода», «полезная статистика» → «четыре счётчика: агенты, недуги, терапии, записи на приём». Особое внимание к разделу «За границами»: явное указание «нет аутентификации» защищает от соблазна добавить login «пока руки в коде». Раздел «Решения» сверяется с tech-stack.md проекта — подтверждено использование существующего шаблонизатора, новая библиотека не добавляется. Validation.md включает проверку на мобильном, что студент изначально считал «лишним».

结果: Спецификация принята ревьюером с одним замечанием: не указана максимальная длина SQL-запроса при большом объёме данных (COUNT(*) может быть медленным на миллионах записей). Добавлено примечание в «Контекст» о текущем размере базы и условии пересмотра при росте. Студент осознаёт: конкретика не убивает творчество, а переносит его в архитектурные решения уровня проекта, а не уровня «придумать на ходу».

经验教训:
Каждая расплывчатая формулировка — потенциальный конфликт между автором и реализатором; конкретика — инвестиция в предсказуемость

Раздел «За границами» часто важнее «Границ»: он защищает от scope creep и даёт психологическое разрешение «не делать сейчас»

Проверка на мобильном, казавшаяся «лишней» для админ-панели, нашла реальную проблему: таблица с 4 счётчиками ломалась на 320px из-за flex-wrap

Сверка с tech-stack.md перед фиксацией решений предотвратила добавление Chart.js «про запас» — экономия 2-3 дней на интеграцию ненужной зависимости

相关概念:
Границы и за границами в спецификации

tech-stack.md как ограничитель решений

validation.md с ручными и автоматическими проверками

Перепланирование и отложенные факты

Конкретика vs субъективность в требованиях

学习建议:
Проходите блоки последовательно, не перепрыгивая: теория (блок 1) → критический анализ (блок 2) → конструирование (блок 3) → полный цикл (блок 4). Каждый блок готовит навыки для следующего

Для блока 1: пишите ответы от руки или в текстовом редакторе без подсмотра, затем сверяйтесь. Механическое заучивание бесполезно — важно понимать логику, чтобы адаптировать к новым ситуациям

Для блока 2: не останавливайтесь на 8 проблемах. Чем больше найдёте, тем глубже понимание. Сравните свои находки с чеклистом курса — если пропустили что-то важное, вернитесь к соответствующей части курса

Для блока 3: переписывайте спецификацию дважды: первый раз самостоятельно, второй — после прочтения образца. Сравните: где ваш вариант точнее, где — избыточен

Для блока 4: обязательно используйте /clear между фазами. Это не ритуал, а функциональная проверка: если после /clear агент не может продолжить без ваших пояснений — спецификация недостаточна

Найдите партнёра для парного зачёта даже если учитесь самостоятельно. Роль ревьюера можно «сыграть» самому через временной зазор: напишите спецификацию, отложите на сутки, затем читайте как ревьюер

Ведите личный журнал SDD-ошибок: фиксируйте, какие проблемы вы пропускали, какие антипаттерны повторялись. Это станет вашей «памятью агента» — но личной, проектной, версионируемой

Для ретроспективы: будьте честны в разделе «Что агенту пришлось вывести самому». Если больше 3 пунктов — это не провал, а сигнал для следующей итерации. Скрытие проблем дороже их признания

Практикуйте объяснение SDD-подхода коллеге, не знакомому с методологией. Если не можете объяснить за 5 минут — значит, сами не до конца понимаете

Используйте таймер: 30 минут на спецификацию, 60 на реализацию, 30 на проверку. Жёсткие временные рамки имитируют реальное давление и учат приоритизировать конкретику

Перед финальным зачётом: выполните пробный проход на выдуманной фиче (например, «подписка на рассылку»), не доводя до слияния. Это снимет тревожность и покажет слабые места в процессе

附加资源:
Части 1-21 курса sdd: Базовый материал, на который ссылается практический зачёт. Особенно важны: часть 6 (границы tech-stack.md и requirements.md), часть 7 (уточнение), часть 12 (MVP и зелёные точки), часть 16 (четыре слоя ревью), часть 17 (хуки), часть 18 (секреты), часть 19 (память агента), часть 20 (антипаттерны)

Qwen.md — шаблон конституции агента: Пример файла, задающего правила поведения агента. Используйте как основу для своего проекта, но не копируйте без адаптации

Specs/tech-stack.md — пример технического стека: Образец документа с долговременными решениями проекта. Обратите внимание на структуру и уровень детализации

Changelog.md — шаблон журнала изменений: Пример формата для фиксации изменений по фичам. Важен для процессного балла в зачёте

Git flow / github flow: Материалы по работе с ветками. SDD не диктует конкретную модель, но требует изоляции фич и коммита спецификации до реализации

Owasp cheat sheet series: Практические рекомендации по безопасности. Особенно разделы по валидации ввода и хранению секретов — напрямую связаны с validation.md и требованиями безопасности зачёта

Cognitive load theory in software development: Понимание когнитивной нагрузки помогает осознать, зачем нужны /clear и разделение фаз — ключевые практики SDD

Примеры спецификаций из открытых sdd-проектов: Реальные specs/ директории с requirements.md, plan.md, validation.md для сравнения с вашим уровнем детализации

摘要: Практический зачёт — это не экзамен на зубрёжку, а демонстрация способности провести реальную фичу через полный цикл SDD. Ключевые навыки: писать конкретные спецификации с измеримыми критериями, использовать Qwen Code CLI как инструмент с чёткими фазами и /clear между ними, выполнять четырёхслойное ревью (код, спецификации, факты, процесс), обеспечивать безопасность через изоляцию секретов и защитные хуки. Успешная сдача (21+/25) означает готовность к промышленному применению; результат 16-20 требует улучшения проверки и командного контура; ниже 16 указывает на необходимость уменьшить размер фаз и детализировать спецификации. Парный формат зачёта моделирует реальную командную динамику и учит обе стороны SDD-диалога. Финальная ретроспектива с порогом в 3 пункта «выведенного самостоятельно» создаёт механизм непрерывного улучшения. Главный принцип: SDD — это не про больше документации, а про правильную документацию в правильный момент, чтобы агент не угадывал, а выполнял проверяемые намерения.