Capstone roadmap и критерии оценки

1. Без дорожной карты capstone остаётся красивой папкой

Без дорожной карты формат, границы и baseline проекта легко остаются просто красивой папкой в репозитории и не становятся рабочим процессом. Capstone опасен не размером, а длиной: он тянется во времени. А длинные задачи, как вы уже знаете, прекрасно притворяются «почти готовыми» до самого неприятного момента.

У capstone есть одна особенность: он не живёт в отдельной волшебной комнате, где весь курс замирает и смотрит, как вы пишете проект. Наоборот, он идёт поверх следующих блоков курса: пока вы читаете про legacy, migration, MVP и demo, проект должен не ждать в холодильнике, а двигаться маленькими проверяемыми шагами. Именно поэтому нужна не мотивация «работайте регулярно», а контрольные вехи.

Полезно держать перед глазами очень простую схему:

flowchart TD
    A[Текущий уровень:
формат + baseline + SPEC] --> B[Понять и зафиксировать
один рабочий сценарий]
    B --> C[Запустить core flow
локально]
    C --> D[Уточнить ценность,
сузить scope]
    D --> E[Собрать demo-ready пакет:
README, проверки, evidence]
    E --> F[Защита проекта]

Эта схема кажется почти слишком простой — но в этом и смысл. Вам не нужен roadmap на двадцать восемь строк с цветными зависимостями, будто вы строите космодром. Нужен маршрут на три вопроса: что готово к каждой вехе, как понять, что вы отстали, и что делать, если отстали.

Есть хорошая инженерная формула:

Если вех нет — всё кажется одинаково важным. А когда всё одинаково важно, обычно не двигается ничего.

2. Milestone-карта: вехи по пути к защите

Теперь идею «двигаться постепенно» пора превратить в несколько конкретных точек. Эти точки почти одинаковы для любого capstone-формата: разница не в том, что у одного roadmap есть, а у другого нет, а в том, насколько глубоко вы проходите блоки курса и какой артефакт считаете основным результатом.

Ниже — опорная milestone-карта. Это не календарь в днях и не замена разговору с ментором — именно навигационные знаки, на которые вы можете смотреть по ходу работы.

На эту таблицу полезно смотреть не как на «план отличника», а как на диагностический прибор. Например, самая критичная веха — та, где core flow уже запускается локально. Не «почти написан», не в голове, не пять заметок в чате с Claude — реально запускается. Пусть криво, без интерфейса, с честным списком ограничений, но запускается.

Если к этой точке проект всё ещё существует в режиме «у меня уже почти всё спроектировано» — это очень важный сигнал. Обычно он означает не «поднажать», а то, что scope выбран слишком широко. И здесь многие делают классическую ошибку: пытаются спасать положение ускорением. На практике capstone почти никогда не спасается ускорением. Он спасается урезанием лишнего.

Можно запомнить короткое правило:

Поэтому правильная реакция на пропущенную веху — не героизм в стиле «три ночи без сна», а шаг назад к SPEC.md, non-goals и одному рабочему сценарию.

И ещё одна важная вещь. Подробный темп — версию README, дни на polishing, момент промежуточного показа — задаёт ментор: у него есть контекст вашего уровня, формата и общей скорости. Но без этой базовой карты ему, по сути, не на что опираться, и всё сползает в «ну как у вас дела?».

3. Параллельные блоки курса без раздувания проекта

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

Следующий блок покажет legacy и migration на примере CashFlow Dashboard. Это важная сквозная опора курса, но не приглашение превратить ваш capstone в его копию. Проект остаётся вашим. Вы просто смотрите на него через разные инженерные линзы: где риск, где нужен characterization-подход, где думать про rollback, а где всё это избыточно.

Если говорить ещё проще, у вас есть три режима чтения будущих тем: «это прямо про мой capstone», «не напрямую, но даёт полезный вопрос к нему», «хороший профессиональный контекст, но в проект я это сейчас не втаскиваю». Все три нормальны.

Особенно важно это помнить на простом формате — аккуратная feature в существующем коде или небольшой MVP. В таком проекте очень легко искусственно усложнить себе жизнь. Читаете про migration, вдохновляетесь, решаете заодно поменять стек, добавить pipeline, прикрутить хитрый hook и, раз уж пошла такая пьянка, написать своего reviewer-agent. Звучит впечатляюще. На защите обычно ещё впечатляюще звучит список того, что из этого не довели до рабочего вида.

Здесь работает одно из лучших правил всего capstone-блока:

Если следующая тема не усиливает ваш проект прямо сейчас, вы имеете полное право взять из неё только способ думать, а не кусок реализации.

Именно так и стоит входить в модуль 26, где начнётся legacy discovery на CashFlow Dashboard: для modernization и migration formats это уже часть project work, для остальных — линза на риск и границы, а не причина раздувать capstone.

4. EVIDENCE.md как живой рабочий журнал

EVIDENCE.md к этому моменту уже лежит рядом со SPEC.md — зачем он нужен, повторять не буду. Важнее другое: в длинном capstone этот файл помогает видеть drift по roadmap и заранее собирать материал для защиты.

Если записи появляются только в конце, EVIDENCE.md превращается в посмертный пересказ. А нужен живой след: где вы уточнили scope, что попросили у Claude, что решили руками и какими проверками закрыли.

Хороший каркас записи выглядит так:

## 2026-05-24

### Что попросил у Claude
Проверить мой `SPEC.md` на неясные формулировки и скрытый overscope.

### Что решил сам
Убрал экспорт в PDF из первой версии проекта. Оставил только CSV.

### Проверки
Сверил `SPEC.md` с brief и level expectations.

### Что остаётся неясным
Не решил, нужен ли отдельный экран настроек.

Этого уже достаточно, чтобы через пару недель не гадать, почему проект выглядит именно так. Из записи видно, где Claude ускорил работу, а где решение приняли вы, — именно это потом связывает roadmap, критерии оценки и защиту.

Полезно сравнить слабую и сильную запись:

Записи не обязаны быть длинными. Но маленькие решения вроде «убрал PDF из первого релиза» или «заморозил scope перед demo» и есть тот самый evidence, по которому видно: проектом управляли, а не просто гнали код.

5. Критерии оценки — навигатор, а не страшилка

У многих есть странная привычка: критерии оценки они боятся открывать рано, чтобы «не пугаться». Но на самом деле сильнее всего критерии пугают в последний момент; открытые с самого начала — это не угроза, а навигация. Поэтому читайте их с первого дня.

В capstone вас оценивают не по числу упомянутых технологий и не по количеству файлов, а по связности результата и процесса. Поэтому сверяться с критериями полезно не после финиша, а на каждом шаге, как с направлением.

Ниже — компактная версия того, как эти критерии лучше понимать на практике.

Обратите внимание на тонкую, но важную вещь. Критерий «Claude Code workflow» не требует натащить побольше возможностей Claude — он требует, чтобы использование было осмысленным и прослеживаемым. Одна хорошая запись в EVIDENCE.md о том, как вы через Claude сузили scope и переписали план проверки, работает на оценку сильнее трёх «впечатляющих» механизмов, которые вы не смогли объяснить.

Есть хорошая проверка, которую полезно задавать себе по ходу проекта: если убрать из capstone одну штуку, станет ли проект слабее как инженерный результат? Ответ «нет» — штука была декоративной. Это одинаково про функции продукта и про сложные AI-механизмы.

В этом смысле открытые критерии помогают не украшать проект, а чистить его.

6. Защита начинается не в день demo, а сейчас

Когда люди слышат слово «защита», они обычно представляют финальный день: экран с демонстрацией, волнение, вопросы ментора и резкий всплеск любви к README. Но настоящая защита начинается гораздо раньше — в тот момент, когда вы начинаете собирать narrative проекта по ходу работы. Если EVIDENCE.md ведётся честно, половина narrative уже лежит у вас в репозитории.

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

## Опоры защиты

- Problem: какую проблему решает проект
- Core scenario: какой один сценарий я реально показываю
- Claude Code workflow + verification: где помог Claude и как я проверял результат
- Limitations & trade-offs: что я сознательно не делал и почему

Лучше всего эти опоры не выносить в отдельный красивый документ ради будущего, а держать рядом с живой работой — дописывая коротко в EVIDENCE.md по мере того, как проект проясняется. Тогда к demo у вас не «подготовиться с нуля», а «собрать уже существующую историю в связный рассказ».

Вот как это может выглядеть прямо в журнале:

### Проблема
Магазин тратит слишком много времени на ручной отбор подарков по фильтрам.

### Основной сценарий
Пользователь задаёт бюджет и интерес, получает подборку и открывает один товар.

### Проверка
Локальный smoke check, ручная проверка README, проверка пустого результата.

### Ограничения
Нет оплаты, нет личного кабинета, нет сохранения истории поиска.

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

И, пожалуй, это один из самых зрелых признаков сильного capstone: к demo у вас уже есть не только рабочий сценарий, но и понятная история того, как вы к нему пришли. Часто именно она отличает инженерный проект от набора файлов в репозитории.