Capstone brief и шесть форматов проекта

1. Финальный проект начинается не с кода, а с brief

Финальный проект здесь действительно начинается не с кода, а с CAPSTONE_BRIEF.md, и это хорошая новость. Когда человек слышит слова «финальный проект», внутри быстро просыпается маленький стартапер: ему хочется сразу «платформу», «экосистему», «AI-агента для всего» — и желательно за выходные. Реакция понятная и человеческая. Но курс в этот момент вежливо забирает у вас мегафон и вручает документ CAPSTONE_BRIEF.md.

Потому что capstone в этом курсе — не конкурс на самое большое приложение. Это проверка того, умеете ли вы вести разработку с помощью AI как инженер, а не как человек, который три ночи подкармливал ИИ кофеином и надеждой. Один студент написал две тысячи строк без структуры, другой выстроил аккуратный поток работы со спецификацией и доказательствами — курс выберет второго.

Поэтому brief нужен здесь не для вдохновения, а для рамки: что допустимо, как оценивают, какие доказательства важны и что не требуется. Последний пункт особенно ценен. Многие студенты переусложняют проект не потому, что тема сложная, а потому, что вовремя никто не сказал: вам не нужно деплоить это в прод и строить маленький космодром.

В очень сжатом виде нервная система такого документа выглядит так:

# CAPSTONE_BRIEF.md

## Разрешённые форматы
- Feature in existing codebase
- AI-native MVP
- Legacy modernization mini-project
- Migration slice
- DevOps automation
- Team workflow design

## Жёсткие правила
- choose exactly one format
- one core flow end-to-end
- SPEC.md is mandatory
- evidence starts on day one
- no production deployment requirement

Каждая строка здесь важна и работает. choose exactly one format — чтобы проект не стал Франкенштейном, где вы разом делаете MVP, миграцию, командный workflow и на всякий случай автоматизируете релиз. SPEC.md is mandatory — capstone начинается с инженерного контракта, а не с генерации файлов. А no production deployment requirement спасает сотни часов жизни.

Проще говоря, brief заранее защищает вас от самой популярной ошибки финальных проектов — от идеи «сейчас я как раз покажу весь свой масштаб». А масштаб в учебном проекте обычно означает либо бесконечный scope, либо README размером с роман при работающей только кнопке «Открыть localhost».

2. Шесть форматов — это не ограничение, а помощь

Здесь быстро возникает соблазн спросить: а почему нельзя просто дать всем полную свободу, пусть каждый выберет тему по душе? Один делает маркетплейс, другой — AI-бухгалтера, третий — симулятор марсианской бухгалтерии. Звучит демократично, но методически это катастрофа: сравнивать нечестно, помогать трудно, проверка превращается в лотерею. Поэтому форматов ровно шесть — способ сделать capstone сравнимым, проверяемым и привязанным к тому, что вы уже проходили.

Обратите внимание: здесь нет формата «что-нибудь крутое с AI», и это прекрасно — каждый формат сам подсказывает, что именно показать. От Feature in existing codebase ждут аккуратного issue-to-PR подхода, а не философии о продукте; в Team workflow design важны правила, границы и повторяемые артефакты, а не «я настроил себе одну удобную кнопку».

Очень полезно в этот момент уметь переводить идею из режима «мечта» в режим «формат». Например, так:

Плохая формулировка:
«Сделаю аналог Notion, Jira и Shopify с AI-агентами»

Рабочая формулировка:
Формат: AI-native MVP
Core flow: оператор загружает тикет и получает черновик ответа

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

Отдельно скажу важную вещь про уровни. Ограничения «Junior / Middle / Senior» — не формальность, они защищают от неправильного выбора. Migration slice на Junior — это как выдать человеку, который только научился парковаться, фуру с прицепом со словами «вы же водитель, разберётесь». Мотивация — хорошо, но лучше доехать домой живыми.

3. Ваш capstone и проекты курса — это не одно и то же

Здесь у многих возникает небольшая путаница, и лучше убрать её сразу. В лекциях этого блока появляются Commerce OS, Workflow Kit и CashFlow Dashboard. Но ваш финальный проект не обязан вырастать из них. Это учебные опоры и общий язык примеров. Ваш capstone — отдельный проект в отдельном репозитории под ваш формат.

Это различие принципиально. Когда на лекции я показываю на CashFlow Dashboard, как выглядит legacy-контекст и почему миграция нужна, это не значит, что строить capstone поверх него вы обязаны, если ваш формат — небольшой MVP или feature в существующем коде.

Именно здесь полезно понять термин advanced lens. Проще говоря, последующие блоки дадут разные «линзы» для разных типов проектов. Блок про legacy и migration полезен всем, но глубоко применять его к своему capstone стоит только тогда, когда формат этого требует. Делаете MVP — не пришивайте к нему миграцию старого Java-сервиса только потому, что курс позже заговорит о миграциях; иначе получится проект, сломанный сразу в нескольких измерениях. И обратно: в workflow design не добавляйте каталог товаров, подписки и поддержку клиентов. Курс любит связность, но не настолько, чтобы заставлять вас собирать технологического кентавра.

4. CashFlow Dashboard входит в курс через MRR

CashFlow Dashboard входит в курс через реальную бизнес-проблему — расхождение в MRR. Он появляется не потому, что «в учебном плане настало время legacy», а как часть истории продукта. Commerce OS давно показывает эту метрику, ежемесячную повторяющуюся выручку — одну из самых чувствительных цифр подписочного бизнеса. Ошибка на восемь процентов — уже не «где-то округлили», а история, где финансовый менеджер пишет вам не смайлик, а письмо.

Сигнал выглядит так:

# Финансовый сигнал

MRR в Commerce OS dashboard: 128 400 $
Фактическая выгрузка:        118 100 $
Отклонение:                  ~8%
Источник расчёта: CashFlow Dashboard

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

Само слово legacy тоже лучше расшифровать по-человечески. Legacy — это не просто старый код, а код, встроенный в бизнес: от него зависят деньги, отчёты, процессы и чьё-то давление. Его нельзя удалить с фразой «сейчас перепишем нормально». Сначала понять, потом зафиксировать поведение, и только потом менять маленькими шагами.

Именно поэтому появление CashFlow Dashboard выглядит таким естественным: это рабочая ситуация, а не выдуманный «Сервис Подсчёта Денег 3000». Курс специально держится доменов, похожих на настоящую оплачиваемую работу.

5. Миграция делится на два прыжка, а не один подвиг

Миграцию здесь специально делят на два прыжка, а не на один подвиг. Когда студенты впервые видят стек CashFlow Dashboard и целевой стек курса, возникает понятный вопрос: раз финальная цель похожа на современный стек Commerce OS, почему не мигрировать сразу до конца? Потому что курс хочет научить, а не устроить героический триатлон.

Это похоже на переезд квартиры. Теоретически можно за один раз запихнуть всё в одну машину, сверху посадить кота, сбоку привязать велосипед — и удивляться, почему на первом повороте всё поехало врозь. Практически разумнее сделать два захода.

Первый большой прыжок — это переход с Java 8 и Spring Boot 2.7 к современной базе на Java 21 и Spring Boot 3.x. Именно здесь и живёт учебная боль: меняются требования к платформе, всплывают устаревшие зависимости, появляются переходы вроде javax → jakarta, иначе ощущаются безопасность и конфигурация. Вы видите основные паттерны миграции концентрированно.

А вот финальный переход до Boot 4 и Java 25 курс оставляет как осознанное расширение — не потому, что он не важен, а потому, что методически ценнее хорошо разобрать один большой переход, чем поверхностно пробежать два и сделать вид, что всё «в целом понятно». А «в целом понятно» в инженерии часто означает «в пятницу вечером всё упало».

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

6. CAPSTONE_BRIEF.md глазами инженера

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

Если читать brief именно так, он очень быстро перестаёт быть скучным: он начинает работать как хороший технический собеседник, который не вдохновляет на безумие, а задаёт правильные вопросы. Полезная внутренняя формула после его чтения должна звучать так: «Я делаю [формат], показываю [один core flow], сознательно не делаю [три non-goals]».

Пока это ещё язык общего CAPSTONE_BRIEF.md — рамка для всех capstone-проектов. Дальше вы пропустите её через свой уровень, отрежете лишнюю сложность и соберёте личный SPEC.md. Если вы пока не можете произнести формулу вслух, значит, brief вы только пробежали глазами. А если можете, значит, вместо «хочу сделать что-то с AI» у вас появилась оформленная траектория.

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