Выпускной проект программы

Финал программы SDD: спроектировать и собрать небольшой сервис через спецификации — от модели предметной области до кода, принятого тестами. Шесть вариантов тем разного размера, критерии Simple/Medium/Strong/Boss с самопроверкой и автопроверками курса, структура репозитория, шаблон отчёта, связь с ДЗ sdd-hw02-implement и выпускным проектом основного курса, итоги программы.

УРОКsdd/sdd-4-practice/04-capstone.mdx2 чУрок 4 из 4

После урока вы сможете

Провести свой сервис через полный цикл — модель предметной области, конституция, спецификация, план, задачи, реализация с агентом, проверка
Выбрать тему и масштаб проекта и оценить результат по уровням Simple/Medium/Strong/Boss с помощью чек-листа и автопроверок курса
Оформить репозиторий и отчёт так, чтобы по ним был виден процесс — итерации, ошибки агента, изменения спецификации, время
Наметить, как применять SDD дальше — в основном курсе, на работе и в своих проектах

Зачем это нужно

За программу вы по отдельности освоили все детали SDD: спецификации с требованиями и сценариями, план с интерфейсами, задачи с зависимостями, Spec Kit и OpenSpec, полный цикл с агентом, проверку и подводные камни. Домашние работы тренировали половины пути: в sdd-hw01-spec вы писали документы без кода, в sdd-hw02-implement — код по чужим документам. Выпускной проект соединяет всё: вы сами проходите путь от разговора о предметной области до кода, принятого тестами, и честно пишете, что получилось.

Здесь встречаются две программы курса. DDD отвечает на вопрос, что строить: какие понятия, слова, правила и границы. SDD — как передать это агенту и проверить результат. Проект показывает, работает ли эта связка у вас: хватает ли модели, чтобы спецификация вышла однозначной, и хватает ли спецификации, чтобы агент не додумывал.

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

Что вы построите

Небольшой сервис — пакет на Python со стандартной библиотекой и pytest, без базы данных, веба и фреймворков (как в домашних работах программ). В центре — модель предметной области с правилами, а не инфраструктура: хранилище в памяти за абстрактным интерфейсом, время — только параметром now.

flowchart LR
T["Тема и описание<br/>ядра"] --> M["Модель:<br/>глоссарий, события,<br/>контексты, агрегат"]
M --> C["Конституция<br/>и файл памяти"]
C --> S["Спецификация<br/>REQ и SC"]
S --> Q["Уточнения"]
Q --> S
S --> P["План<br/>и задачи"]
P --> X["Тесты<br/>из сценариев:<br/>красные"]
X --> I["Агент:<br/>задача за задачей"]
I --> V["Проверка:<br/>трассируемость,<br/>ревью, сверка"]
V -->|"расхождение"| S
V --> D["Изменение<br/>требований<br/>(Boss)"]
D --> S
V --> R["Отчёт"]

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

Этап	Что сделать	Артефакт	Уроки
0. Тема и рамки	выбрать вариант, описать ядро на одну страницу	`domain/vision.md`	DDD.1.3
1. Модель предметной области	глоссарий, события, контексты и связи, канва главного агрегата	`spec/glossary.md`, `domain/events.md`, `domain/context-map.md`, `domain/aggregate.md`	DDD.1–DDD.3
2. Конституция и память агента	5–8 проверяемых принципов, короткий файл памяти	`spec/constitution.md`, `CLAUDE.md` или `AGENTS.md`	SDD.1.2, SDD.2.3
3. Спецификация и уточнения	истории, требования, сценарии, вне рамок, открытые вопросы; вопросы агента до кода	`spec/spec.md`	SDD.2.1
4. План и задачи	архитектура, модель данных, публичный интерфейс, решения; задачи с зависимостями	`spec/plan.md`, `spec/adr/`, `spec/tasks.md`	SDD.2.2, SDD.2.3
5. Тесты из сценариев	один тест на сценарий, все красные	`tests/test_acceptance.py`	SDD.4.2
6. Реализация	задача за задачей, коммит на задачу, хук с тестами	код и история git	SDD.4.1
7. Проверка	трассируемость, ревью диффов, сверка, инварианты	вывод `tools/trace.py`, заметки ревью	SDD.4.2
8. Изменение (Boss)	дельта требований и её реализация	`spec/changes/001-….md`	SDD.3.2
9. Отчёт	итерации, ошибки агента, изменения, время, метрики	`REPORT.md`	этот урок

Этап 1 — облегчённый вариант процесса моделирования DDD Crew (DDD Starter Modelling Process): из его восьми шагов вам хватит четырёх — понять задачу бизнеса, найти события, разрезать на контексты и спроектировать главный агрегат по канве агрегата (Aggregate Design Canvas). Авторы процесса подчёркивают, что он не линейный: по шагам возвращаются. В проекте так же: уточнение в спецификации нередко меняет глоссарий.

Варианты тем

Четыре варианта — в онлайн-школе, два — вне её. Правила в описаниях — заготовки и условия учебного примера: дополните их, уточните и запишите открытые вопросы. Где в теме стоит «решите сами», ответа «как правильно» нет — есть ваше обоснованное решение в ADR.

Вариант	Где	Размер, часов	Ядро правил	Где подвох
А. Промокоды	онлайн-школа: Каталог или Оплата — решите сами и обоснуйте в ADR	S, 10–12	промокод даёт скидку в процентах или фиксированную (`Money`); действует в период (`Period`); лимит применений; один промокод на счёт; итог не меньше 0	округление процента до копейки и в чью пользу; граница срока действия; лимит при двух применениях одновременно
Б. Библиотека	вне школы	S–M, 10–14	читатель берёт до 5 экземпляров на 14 дней; одно продление, если нет брони; штраф 10 руб. в день просрочки, не больше цены книги; бронь — по очереди	книга и экземпляр — разные понятия; продление при появившейся брони; штраф в копейках
В. Перенос записи	онлайн-школа, Набор: реализация вашего пакета из ДЗ sdd-hw01-spec	M, 15–18	правила вы уже записали сами; инварианты Набора из глоссария школы	перенос меняет два агрегата `Cohort` — как сохранить согласованность (DDD.3.2)
Г. Посещаемость	онлайн-школа, Обучение (основной поддомен)	M, 15–20	занятия потока не пересекаются; отметить посещение можно от начала занятия до 24 часов после конца; прогресс — доля посещённых обязательных занятий	данные о записях приходят из Набора: что модель Обучения знает о них и откуда
Д. От оплаты до сертификата	онлайн-школа: Оплата, Набор, Сертификация	L, 25–30	цепочка событий ПлатёжПолучен → ЗаписьПодтверждена → … → СертификатВыдан; предохранительный слой для ответов платёжной системы; идемпотентные обработчики	контракты событий между контекстами, повторная доставка и порядок (DDD.4.2)
Е. Своя тема	работа, хобби, другой домен	любой	не меньше 5 правил с числами, статусами или сроками; хотя бы один агрегат с инвариантами	без секретов и закрытого кода работодателя; сначала одна страница описания ядра

Как выбрать:

Первый проект с агентом — А или Б: правил хватает, чтобы поймать агента на границах, а объём не съест месяц.
Сделали ДЗ sdd-hw01-spec — В: спецификации уже есть, и проект честно покажет, достаточно ли их было агенту. Это лучший тест вашей же работы.
Прошли программу DDD целиком — Г или Д: в них главное — границы контекстов и интеграция.
Хотите проект для портфолио по специальности — Е, но сначала проверьте тему на «пять правил с числами». Если их нет, это CRUD, и SDD здесь не покажет силу (урок SDD.4.3, раздел «Когда SDD не нужен»).

На этапе модели агент — хороший интервьюер, но плохой эксперт: правила он придумает «типичные». Пусть он спрашивает, а отвечаете вы (или настоящий эксперт):

Ты — аналитик, я — методист онлайн-школы. Мы проектируем промокоды. Задавай мне вопросы по одному, всего не больше
десяти: сроки, лимиты, округление, отмена записи, оплаченный счёт. Ничего не предлагай сам и не додумывай ответы.
В конце выпиши: термины для глоссария (русский → имя в коде → как не говорим), правила с числами, открытые вопросы.

Сравните итог с вашим domain/vision.md: всё, о чём агент спросил, а вы не знали ответа, — открытый вопрос спецификации, а не повод «решить по ходу».

Структура репозитория

Структура совпадает с домашними работами программы: пакет спецификаций лежит в spec/ в формате ДЗ sdd-hw01-spec, а код и тесты устроены как в sdd-hw02-implement. Поэтому автопроверки курса можно направить на ваш проект (ниже).

my-capstone/
├── README.md                 # что за сервис, как запустить тесты, ссылка на отчёт
├── CLAUDE.md                 # или AGENTS.md: правила для агента, где спецификации и глоссарий
├── domain/                   # модель предметной области (DDD) — до спецификаций
│   ├── vision.md             # описание ядра на одну страницу
│   ├── events.md             # события в прошедшем времени, команды, правила между ними
│   ├── context-map.md        # контексты и связи между ними (можно схемой Mermaid)
│   └── aggregate.md          # канва главного агрегата: состояния, инварианты, команды, события
├── spec/                     # пакет спецификаций — формат ДЗ sdd-hw01-spec
│   ├── constitution.md
│   ├── glossary.md           # термин → имя в коде → вид → определение → «не говорим»
│   ├── spec.md               # REQ-…, SC-… «Дано / Когда / Тогда», вне рамок, открытые вопросы
│   ├── plan.md               # архитектура, модель данных, публичный интерфейс (зафиксирован), решения
│   ├── tasks.md              # T-… с полями «Требования», «Зависит от», «Готово, когда», статус
│   ├── adr/0001-….md         # решения с последствиями (Strong)
│   └── changes/001-….md      # дельта требований после реализации (Boss)
├── promo/                    # ваш пакет, имя — из глоссария: model.py, events.py, errors.py, repository.py, service.py
├── tests/
│   ├── conftest.py           # подключает корень репозитория к sys.path
│   ├── test_acceptance.py    # def test_sc_001_…(): по одному тесту на сценарий
│   └── test_invariants.py    # случайные последовательности команд с фиксированным seed (Strong)
├── tools/
│   └── trace.py              # трассируемость (ниже) и ваши решения браузерных заданий программы
└── REPORT.md                 # отчёт по шаблону ниже

Два правила, которые сэкономят часы. Первое: коммит со спецификациями до первой строки кода — от него на уровне Boss вы начнёте повторную реализацию. Второе: одна задача — один коммит с ID задачи и требований в сообщении; по истории git потом пишется раздел отчёта «Итерации».

Критерии Simple / Medium / Strong / Boss

Уровни устроены лестницей, как в домашних работах курса: следующий засчитывается, только если выполнены все пункты предыдущих. Автогрейдера у проекта нет — это самооценка по чек-листу, но большую часть пунктов проверяют инструменты, а не ощущения.

Уровень	Что нужно	Чем проверить
🥉 Simple — сквозной путь	`vision.md` на страницу; глоссарий не меньше 8 терминов; конституция не меньше 3 принципов; `spec.md` со всеми разделами, не меньше 5 требований с ID, у каждого — сценарий «Дано / Когда / Тогда»; основные сценарии реализованы, тесты `test_sc_…` зелёные; `REPORT.md` со всеми разделами	автопроверка sdd-hw01-spec — уровни Simple и Medium; `python -m pytest -q`
🥈 Medium — модель и трассируемость	канва агрегата с инвариантами и событиями; карта контекстов; `plan.md` с зафиксированным интерфейсом; задачи покрывают все требования, граф без циклов; маркеры `[УТОЧНИТЬ]` закрыты или вынесены; у каждого сценария есть тест, тестов-сирот нет; в модели нет чтения часов; имена — из глоссария; одна задача — один коммит	автопроверка sdd-hw01-spec до Strong; `tools/trace.py` без ✗; линтер единого языка из урока DDD.1.2; `git log`
🥇 Strong — границы и честность	у каждого правила с числом — сценарии по обе стороны границы; тест инвариантов на случайных последовательностях команд с фиксированным seed; хотя бы один ADR; ревью спецификации другим человеком или субагентом-критиком, замечания записаны; ревью каждого диффа по чек-листу SDD.4.2; после сверки расхождений нет; в отчёте метрики	чек-лист ревью из SDD.4.2; `trace.py`; таблица «Итерации» в отчёте
🐉 Boss — изменение и воспроизводимость	после реализации — изменение требований: дельта в `spec/changes/` с продолжением нумерации, реализована, старые сценарии не сломаны; повторная реализация с чистого листа (новая ветка от коммита со спецификациями, новая сессия или другой агент), результат в отчёте; защита: 10 минут демонстрации и ответы на вопросы или публичный репозиторий с README и ИИ-ревью	те же тесты на обеих реализациях; `trace.py` с учётом `changes/`; запись или заметки защиты

Повторная реализация на Boss — главный эксперимент проекта. Если новая сессия без истории чата по тем же документам проходит те же приёмочные тесты, знание действительно живёт в спецификациях. Если нет — в отчёте появится самый ценный раздел: чего в спецификации не хватило и что агент додумал. Это прямое измерение недетерминизма из урока SDD.4.3.

Инструменты самопроверки

Форма пакета спецификаций. Автопроверка ДЗ sdd-hw01-spec читает папку из переменной окружения CHINAAI_TARGET (см. homework/sdd-hw01-spec/tests/conftest.py), поэтому её можно направить на ваш проект:

# из корня проекта; путь к репозиторию курса — свой
CHINAAI_TARGET="$PWD" python -m pytest ~/ChinaAI/homework/sdd-hw01-spec/tests -q

Её уровни Simple–Strong проверяют файлы, разделы, ID, сценарии, размытые слова, граф задач и связь плана с глоссарием — то есть форму вашего пакета. Boss этой автопроверки ищет файл acceptance_test.py из ДЗ; в проекте его роль играют tests/ и trace.py. Формат разметки — по README ДЗ sdd-hw01-spec.

Браузерные задания программы как инструменты. Линтер требований из урока SDD.2.1, граф задач из урока SDD.2.3 и матрица трассируемости из урока SDD.4.2 — перенесите свои решения в tools/ и запускайте локально.

Трассируемость целиком. Скрипт ниже проходит по всей цепочке «требование → сценарий → задача → тест» и заодно ищет чтение часов в коде модели. Формат — как в домашних работах: - **REQ-001**: …, заголовки ### SC-001: … и ## T-001: … (уровень заголовка не важен) со строкой Требования: REQ-…, тесты def test_sc_001_…. Файлы дельт в spec/changes/ читаются тоже.

"""Трассируемость пакета спецификаций: требование → сценарий → задача → тест (+ часы в коде).

Запуск: python trace.py <папка spec> <папка тестов> [<папка кода>]
Формат разметки — как в ДЗ sdd-hw01-spec и sdd-hw02-implement: «- **REQ-001**: …»,
«### SC-001: …» и «## T-001: …» со строкой «Требования: REQ-…», тесты def test_sc_001_…
"""
import re
import sys
from pathlib import Path

CLOCK = re.compile(r"datetime\.now\(|datetime\.today\(|date\.today\(|time\.time\(")


def blocks(text, kind):
    """{ID: множество REQ из строки «Требования:»} для блоков «## T-001: …» или «### SC-001: …»."""
    parts = re.split(rf"^#{{2,4}}\s+({kind}-\d{{3}})\b.*$", text, flags=re.M)
    result = {}
    for block_id, body in zip(parts[1::2], parts[2::2]):
        line = re.search(r"Требования:(.*)", body)
        result[block_id] = set(re.findall(r"REQ-\d{3}", line.group(1))) if line else set()
    return result


def main(spec_dir, tests_dir, src_dir=None):
    reqs, scenarios, tasks, tests = set(), {}, {}, set()
    for path in sorted(Path(spec_dir).rglob("*.md")):             # spec.md, tasks.md, changes/*.md
        text = path.read_text(encoding="utf-8")
        reqs |= set(re.findall(r"^\s*- \*\*(REQ-\d{3})\*\*", text, flags=re.M))
        scenarios |= blocks(text, "SC")
        tasks |= blocks(text, "T")
    for path in Path(tests_dir).rglob("test_*.py"):
        tests |= {f"SC-{n}" for n in re.findall(r"^def test_sc_(\d{3})_", path.read_text(encoding="utf-8"), re.M)}
    linked = set().union(*scenarios.values(), *tasks.values())
    checks = {
        "требования без сценария": reqs - set().union(*scenarios.values()),
        "требования без задачи": reqs - set().union(*tasks.values()),
        "ссылки на несуществующие требования": linked - reqs,
        "сценарии без теста": set(scenarios) - tests,
        "тесты-сироты (такого сценария нет)": tests - set(scenarios),
    }
    if src_dir:
        checks["чтение часов в коде"] = {f"{p.name}:{n}" for p in Path(src_dir).rglob("*.py")
                                        for n, line in enumerate(p.read_text(encoding="utf-8").splitlines(), 1)
                                        if CLOCK.search(line)}
    print(f"Требований {len(reqs)}, сценариев {len(scenarios)}, задач {len(tasks)}, "
          f"сценариев с тестом {len(set(scenarios) & tests)} из {len(scenarios)}")
    for title, items in checks.items():
        shown = ", ".join(sorted(items)[:6]) + (" …" if len(items) > 6 else "")
        print(f"  {'✗' if items else '✓'} {title}: {len(items)}{' — ' + shown if items else ''}")
    return sum(map(len, checks.values()))


if __name__ == "__main__":
    sys.exit(1 if main(*sys.argv[1:]) else 0)

Прежде чем запускать скрипт на своём проекте, проверьте его на пакете из ДЗ sdd-hw02-implement. Из корня репозитория курса, пока ДЗ не начато (в code/tests_student/ ещё нет ваших тестов; путь к trace.py — свой):

$ python trace.py homework/sdd-hw02-implement/spec homework/sdd-hw02-implement/code/tests_student
Требований 16, сценариев 24, задач 10, сценариев с тестом 0 из 24
  ✓ требования без сценария: 0
  ✓ требования без задачи: 0
  ✓ ссылки на несуществующие требования: 0
  ✗ сценарии без теста: 24 — SC-001, SC-002, SC-003, SC-004, SC-005, SC-006 …
  ✓ тесты-сироты (такого сценария нет): 0

Пакет связный: у каждого требования есть сценарий и задача, а тестов пока нет. 16 требований, 24 сценария и 10 задач — это 14 требований и 20 сценариев из spec.md и 9 задач из tasks.md плюс 2 требования, 4 сценария и 1 задача из дельты changes/001-honors.md (скрипт читает все .md в папке spec/, включая changes/; вывод проверен на пакете ДЗ 6 октября 2026 года). На эталонном решении скрипт показывает «сценариев с тестом 24 из 24», все строки с ✓, включая «чтение часов в коде: 0». Код возврата — 0, если всё чисто, и 1, если есть хоть одна ✗: скрипт можно ставить в хук агента или CI.

Шаблон отчёта

Отчёт — не сочинение, а журнал: по нему другой инженер должен понять, как шла работа, и повторить её. Разделы «Итерации», «Где агент ошибся», «Что изменили в спецификации» и «Время» — те же, что в REPORT.md ДЗ sdd-hw02-implement; в проекте к ним добавляются модель, процесс и метрики.

# Отчёт: промокоды для онлайн-школы

**Вариант:** А · **Агент и модель:** … · **Уровень по самооценке:** Strong · **Не выполнено для Boss:** …

## Что было в спецификации
- Модель: контекст …, агрегат … (инварианты: …), событий …, терминов в глоссарии …
- Требований …, сценариев …, из них на границах …; задач …
- Открытых вопросов в начале …, закрыто …, вынесено за рамки …
- Объём: spec.md — … слов, весь пакет — … слов. Сколько из этого вы перечитали перед реализацией?

## Итерации
| Задача | Попыток агента | Принята без правок | Что пришлось сказать агенту |
|---|---|---|---|
| T-001 | 1 | да | — |
| T-004 | 3 | нет | «округление — по REQ-007, в пользу студента»; откат и новая сессия |

## Где агент ошибся
1. Симптом → причина (пробел в спецификации / агент проигнорировал / недетерминизм) → как поймали
   (тест SC-…, ревью диффа, trace.py) → что изменили.

## Что изменили в спецификации
- v1.0 → v1.1: что и почему, какие ID добавлены (нумерация продолжается), какие сценарии.

## Что изменили в процессе
- Например: «после T-003 режем задачи мельче», «хук запускает trace.py», «агенту запрещено править tests/».

## Время
| Фаза | Часы |
|---|---|
| модель предметной области | |
| спецификация и уточнения | |
| план и задачи | |
| реализация с агентом (ваше активное время) | |
| проверка и ревью | |
| отчёт | |

## Метрики
- Сценариев с тестом: … из … (trace.py); задач, принятых без правок: … из …
- Повторная реализация (Boss): с первого раза прошли … из … приёмочных тестов; чего не хватило в спецификации: …

## Выводы
Три–пять пунктов: что сработало, что было лишним, что сделаете иначе.

Самый ценный раздел — «Где агент ошибся». Пустой раздел почти всегда значит, что вы не смотрели, а не что агент не ошибался. Честность здесь — то же, что раздел «Неудачные попытки» в техотчёте выпускного проекта основного курса (урок 10.1.2).

Связь с ДЗ и с выпускным проектом основного курса

ДЗ sdd-hw02-implement — генеральная репетиция. Сделайте его до проекта: там спецификации и интерфейс уже готовы, и вы сосредоточены на работе с агентом. Из ДЗ в проект переносится почти всё устройство:

	ДЗ sdd-hw02-implement	Выпускной проект
Спецификации	готовы: «Выдача сертификатов»	пишете сами, от модели предметной области
Интерфейс	зафиксирован в `plan.md`, на него опираются скрытые тесты	фиксируете сами в `plan.md`
Проверка	автогрейдер `python homework/check.py sdd-hw02-implement`	самооценка по чек-листу и инструменты курса
Отчёт	итерации, ошибки агента, изменения спецификации, время	то же плюс модель, процесс и метрики
Boss	дельта «сертификат с отличием»	своя дельта и повторная реализация с чистого листа

Выпускной проект основного курса (урок 10.1.1) — своя LLM от токенизатора до агента с инструментом. SDD подходит не ко всем его этапам. Сервер с OpenAI-совместимым /v1/chat/completions и агент с калькулятором — хорошие кандидаты: у них есть контракт и проверяемое поведение, их сценарии превращаются в тесты. Токенизатор, претрейн, SFT и GRPO — исследовательский код: там результат определяет эксперимент, и нужен план эксперимента с метриками, а не спецификация (урок SDD.4.3). Если вы проходите оба проекта, проведите через SDD именно сервер и агента — и сравните в отчёте, где процесс помог, а где мешал. Критерии лестницей и честный раздел о неудачах в обоих проектах устроены одинаково.

Практика: первый вечер проекта

Цель первого вечера (2–3 часа) — не код, а репозиторий, в котором агенту нечего додумывать на старте.

Репозиторий и скелет. Создайте структуру из раздела выше и сделайте первый коммит:

mkdir my-capstone && cd my-capstone && git init
mkdir -p domain spec/adr spec/changes tests tools
touch README.md CLAUDE.md REPORT.md domain/vision.md spec/glossary.md
git add . && git commit -m "Скелет выпускного проекта"

Описание ядра и интервью. Напишите domain/vision.md на одну страницу (кто пользователи, какую боль решаем, какие правила самые важные), затем проведите интервью-промпт из раздела «Варианты тем». Ответы — в глоссарий и в открытые вопросы.

Файл памяти. Короткий CLAUDE.md (или AGENTS.md) — по образцу урока SDD.1.2, с правилами именно этого проекта:

# Промокоды онлайн-школы — выпускной проект SDD

## Команды
- Тесты: `python -m pytest -q`; трассируемость: `python tools/trace.py spec tests promo`

## Где что лежит
- `domain/` — модель; `spec/` — конституция, глоссарий, спецификация, план, задачи. Перед задачей прочитай её
  строку в `spec/tasks.md` и только перечисленные там файлы.

## Правила
1. Имена — только из `spec/glossary.md`. Новое понятие — сначала вопрос мне.
2. Деньги — `Money` в копейках; время — только параметром `now`.
3. `spec/` и `tests/test_acceptance.py` не правь без моего согласия. Падает тест — правь код.
4. Неясно — не додумывай: остановись и задай мне вопрос. Ответ в спецификацию внесу я.
5. Одна задача — один коммит: `T-00N: что сделано (REQ-…)`.

Проверка инструментов. Сохраните tools/trace.py и запустите его на пакете ДЗ sdd-hw02-implement, как показано выше, — пока ДЗ не начато, вывод должен совпасть. Затем направьте автопроверку sdd-hw01-spec на свой проект: сейчас она ожидаемо упадёт уже на Simple — нет файлов спецификаций. Это ваш список дел на следующие вечера.
План работ. Распишите этапы 1–9 по вечерам с «готово, когда» для каждого (например, «спецификация готова, когда автопроверка sdd-hw01 проходит Medium и методист прочитал её за 10 минут»). Без такого условия этап не заканчивается никогда.

Когда спецификация готова, перед реализацией попросите независимую оценку:

Ты — преподаватель программы SDD курса ChinaAI и строгий ревьюер. Прочитай domain/, spec/ и CLAUDE.md
моего выпускного проекта. Оцени их по уровням Simple/Medium/Strong/Boss из урока SDD.4.4 (таблицу вставляю ниже).
Для каждого уровня: что выполнено, чего нет, со ссылками на файлы и ID (REQ, SC, T). Отдельно найди три места,
где спецификация допускает два толкования, и три правила с числами без сценария на границе. Не переписывай
документы и не пиши код — в конце задай мне три вопроса на понимание.

Повторите ту же просьбу в конце, добавив код и REPORT.md, — это ИИ-ревью для уровня Boss. Помните урок SDD.4.3: ревьюер-модель снимает с вас проверку формы, но не заменяет эксперта и тесты.

Проверь себя

Проверь себя6 вопросов

1 Почему выпускной проект начинается с модели предметной области, а не сразу со spec.md?Так требует Spec KitГлоссарий, события, инварианты и границы дают словам спецификации однозначный смысл; без них агент назовёт всё Order и User и додумает правилаМодель нужна только для красоты отчётаБез модели нельзя запустить pytest

2 Что в проекте проверяется автоматически инструментами курса? Выберите все верные варианты.Можно выбрать несколько ответовВ spec.md есть все разделы, у требований — ID и сценарииУ каждого сценария есть тест test_sc_…, тестов-сирот нетПравило округления скидки выгодно школеГраф задач без циклов, каждое требование покрыто задачейАгент понял требования так, как их понимает методист

3 Вы выполнили все пункты Strong и Boss, но в Medium остались два незакрытых маркера [УТОЧНИТЬ] без пометки «вне рамок». Какой у проекта уровень?SimpleMediumStrongBoss

4 В отчёте: 16 задач, 12 из них агент выполнил так, что вы приняли их без правок. Какова доля задач, принятых без правок, в процентах?

5 Зачем на уровне Boss нужна повторная реализация с чистого листа по тем же спецификациям?Чтобы получить два варианта кода и выбрать красивыйЧтобы проверить, что знание живёт в документах, а не в истории чата, и измерить недетерминизм: новая сессия должна пройти те же приёмочные тестыЧтобы удвоить число коммитовЧтобы агент выучил проект

6 Какие этапы выпускного проекта основного курса (своя LLM) лучше всего подходят для SDD?Претрейн и GRPO: у них много гиперпараметровСервер с OpenAI-совместимым API и агент с инструментом: у них есть контракт и проверяемое поведениеТокенизатор: его можно описать одной фразойВсе этапы одинаково

Итоги

Выпускной проект соединяет программы DDD и SDD: модель предметной области даёт слова, правила и границы, спецификации передают их агенту, тесты из сценариев и трассируемость проверяют результат.
Шесть вариантов тем разного размера — от промокодов (S) до цепочки «оплата → сертификат» (L); подойдёт и своя тема с пятью правилами с числами.
Уровни Simple/Medium/Strong/Boss — лестница самооценки: форму проверяют автопроверка sdd-hw01-spec, браузерные задания и trace.py, смысл — вы, эксперт и ревью. Boss — изменение требований и повторная реализация с чистого листа.
Отчёт — журнал процесса: что было в спецификации, итерации, где агент ошибся, что изменили, время, метрики.

Что вы теперь умеете

Модуль	Умение
SDD.1 Идея SDD	решать, нужен ли задаче SDD; устраивать контекст агента — файл памяти, режим планирования, субагенты; не пускать агента к секретам
SDD.2 Спецификации	писать требования с ID и сценариями «Дано / Когда / Тогда», план с интерфейсами и ADR, задачи с графом зависимостей и конституцию
SDD.3 Инструменты	вести фичу через Spec Kit, изменения — через OpenSpec, собирать свой минимальный процесс и не гнаться за модой
SDD.4 Практика	работать с агентом короткими итерациями, проверять его тестами из сценариев и трассируемостью, видеть подводные камни SDD и провести свой сервис от модели до кода

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

Что дальше

Программа DDD, если вы её ещё не прошли: урок DDD.1.1. Особенно пригодятся тактическое проектирование (модуль DDD.3) и урок DDD.4.4 «DDD и системы с ИИ».
Ступень 8 основного курса — как агент устроен изнутри: агентный цикл, инструменты и MCP, безопасность и оценка агентов, промпт как код и эвалы в модуле 8.4.
Ступень 11 «Профессия» — работа с чужим кодом (там пригодится OpenSpec для существующих систем) и резюме и портфолио: выпускной проект с честным отчётом — сильный пункт портфолио.
На работе начните с одной фичи и лёгкой спецификации, соберите метрики из отчёта и только потом решайте, нужен ли команде инструмент. Инструменты SDD меняются каждый месяц — перечитывайте их README с датой и ещё раз статью Бёккелер: с собственным опытом она читается иначе.

Дальше: программа SDD пройдена — отметьте прогресс на странице «Карта курса и прогресс». Если вы ещё не проходили программу DDD, начните с урока DDD.1.1 «Зачем DDD»: модель предметной области сделает ваши следующие спецификации заметно точнее.