Capstone brief і шість форматів проєкту

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

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

Бо capstone у цьому курсі — не конкурс на найбільший застосунок. Це перевірка того, чи вмієте ви вести розробку за допомогою AI як інженер, а не як людина, яка три ночі підживлювала ІІ кофеїном і надією. Один студент написав дві тисячі рядків без структури, інший вибудував акуратний потік роботи зі специфікацією та доказами — курс обере другого.

Тому brief тут потрібен не для натхнення, а для рамки: що допустимо, як оцінюють, які докази важливі і що не вимагається. Останній пункт особливо цінний. Багато студентів переускладнюють проєкт не тому, що тема складна, а тому, що вчасно ніхто не сказав: вам не потрібно розгортати це в production і будувати маленький космодром.

У дуже стислому вигляді нервова система такого документа має такий вигляд:

# CAPSTONE_BRIEF.md

## Дозволені формати
- Feature in existing codebase
- AI-native MVP
- Legacy modernization mini-project
- Migration slice
- DevOps automation
- Team workflow design

## Жорсткі правила
- оберіть рівно один формат
- один core flow від початку до кінця
- SPEC.md є обов'язковим
- докази починаються з першого дня
- немає вимоги до production deployment

Кожен рядок тут важливий і працює. obеріть рівно один формат — щоб проєкт не став Франкенштейном, де ви водночас робите MVP, міграцію, командний workflow і на всяк випадок автоматизуєте реліз. SPEC.md є обов'язковим — capstone починається з інженерного контракту, а не з генерації файлів. А немає вимоги до production deployment рятує сотні годин життя.

Простіше кажучи, 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, а з тверезого вибору формату, зрозумілого масштабу і дуже дорослої думки: фінальний проєкт — це не вистава про вашу безмежну креативність, а перевірювана історія про те, як ви вмієте працювати.