Дорожня карта capstone і критерії оцінювання

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