1. Capstone оценивают по rubric, а не по ощущению
Когда студент впервые слышит слово rubric, в голове иногда возникает что-то пугающее и слегка бюрократическое: будто сейчас придёт человек с лицом налогового инспектора и проверит, достаточно ли у вас духовной близости с README.md. На деле проще: rubric нужна, чтобы оценка не зависела от впечатления и настроения. Ментор не слышит драматичную музыку, под которую вы чинили баг в два ночи. Он видит артефакты.
К этому моменту у вас уже есть две опоры: собранный submission package и понятный defense narrative. Rubric не строит поверх них третью систему — она читает те же README.md, SPEC.md, DEMO.md, EVIDENCE.md и тот же рассказ глазами reviewer.
flowchart LR
A[Результат] --> E[Доверие к capstone]
B[Процесс] --> E
C[Качество] --> E
D[AI-native workflow] --> E
Удобнее всего смотреть на rubric не как на длинный страшный список, а как на четыре крупных блока: результат, процесс, качество и AI-native способ работы. Внутри них — те самые 11 направлений оценки из плана курса.
| Блок оценки | Что внутри | На что реально смотрит ментор | Какие артефакты это показывают |
|---|---|---|---|
| Результат | working result, demo clarity, portfolio readiness | Работает ли core flow, можно ли быстро понять ценность проекта, годится ли он как proof-of-work | DEMO.md, видео, README, скриншоты, живая демонстрация |
| Процесс | scope discipline, task spec quality, Git/diff discipline, traceability | Управляли ли вы задачей как инженер, а не как человек в режиме “ой, оно само выросло” | SPEC.md, EVIDENCE.md, commits, diff, PR walkthrough |
| Качество | tests/checks, documentation, risk awareness | Есть ли доказательства корректности, умеете ли вы видеть границы и риски | тесты, smoke checks, README.md, limitations, verification notes |
| AI-native workflow | Claude Code usage, relevance over quantity | Использовали ли вы Claude Code осознанно и уместно, а не как декоративный фейерверк | CLAUDE.md, notes по skills/agents, review notes, evidence по использованию AI |
Здесь есть тонкий, но очень важный момент. Rubric отвечает не на «понравился ли проект», а на «можно ли доверять этому результату и человеку, который его сделал?». Маленький проект с сильной traceability бьёт большой и эффектный, разваливающийся на первом же «а как вы это проверяли?».
Поэтому working result — только один слой. Демо сработало, но нет SPEC.md, evidence по проверкам, объяснения роли Claude Code, всё держится на «ну у меня запускалось» — оценка будет слабее. Инженерия не конкурс фокусов: важен не кролик из шляпы, а понимание, почему он не взорвётся при следующем запуске.
2. Обязательный минимум для любой защиты
Иногда студенты воспринимают rubric как систему, где обязательно надо «добрать фишек»: два агента, один hook, три скриншота — почти комбо. Но у защиты есть нижняя граница — must-have минимум, ниже которого capstone выглядит не как инженерный проект, а как надежда, замаскированная под репозиторий.
| Что должно быть | Зачем это нужно | Что ломается, если этого нет |
|---|---|---|
| Рабочий core flow | Показывает, что проект не только задуман, но и доведён до результата | Защита превращается в рассказ о прекрасных намерениях |
| Понятный README и setup | Позволяет внешнему человеку запустить проект без телепатии | Возникает классическое “works on my machine” |
| SPEC.md и видимый scope | Показывают, что задача была поставлена осознанно | Проект кажется хаотичным и случайно разросшимся |
| Evidence по tests/checks | Доказывают, что результат проверялся, а не просто понравился автору | Любой баг на демо выглядит как системная проблема |
| Честные limitations | Показывают инженерную зрелость и понимание границ | Ограничения найдёт ментор, и эффект будет хуже |
| Ясное объяснение роли Claude Code | Показывает вашу ответственность за процесс | Возникает вопрос: “это сделали вы или просто включили генератор?” |
| Отсутствие секретов и приватных данных | Это базовая профессиональная гигиена | Даже сильный capstone получает неприятный красный флаг |
Хорошая новость в том, что этот минимум требует не «суперпроекта», а собранности. Воспроизводимый MVP с ясным core flow, внятным README.md, сохранённым SPEC.md, базовыми проверками и честными ограничениями уже стоит на крепкой земле. Не на небоскрёбе из маркетинговых обещаний, зато не по колено в болоте.
Вот так может выглядеть вполне нормальный фрагмент evidence для capstone уровня MVP:
## Проверка
- Core flow: тикет → классификация → черновик ответа → ручное подтверждение
- Команда проверки: `pytest -q`
- Smoke check: high-value refund не уходит без подтверждения
- Limitations: мультиязычность и CRM-интеграция вне текущего scope
Этот фрагмент хорош не длиной: после него у проверяющего меньше белых пятен — видно, что именно работает, чем это проверено и чего вы сознательно не обещаете. Из этого собирается доверие.
Полезно помнить и ещё одну вещь: must-have минимум одинаково важен для всех уровней. Junior не скажет «я новичок, мне можно без evidence», Senior — «у меня сложный проект, мне README.md не нужен». Разница между уровнями не в наличии артефактов, а в их глубине.
3. Одни критерии, три уровня: Junior, Middle, Senior
Здесь появляется часть, которую студенты особенно любят недооценивать: раз rubric одна, значит и всех меряют одной линейкой. Но курс устроен аккуратнее. Оси оценки одинаковые, а глубина ожиданий разная.
| Направление | Junior | Middle | Senior |
|---|---|---|---|
| Результат | Есть рабочий core flow и понятное демо | Есть reproducible demo и более явный walkthrough | Есть полная защита с акцентом на архитектуру, риски или governance, если формат это требует |
| Процесс | Видно, что был task spec и дисциплина по scope | Видно issue-to-PR мышление, commits и traceability | Видно управление рисками, decision points, иногда policy или migration logic |
| Качество | Есть smoke checks и базовая проверка | Есть более серьёзные tests/checks, иногда CI evidence | Есть зрелая verification-логика, rollback thinking или characterization evidence, если релевантно |
| AI-native workflow | Понятно, где помог Claude и что проверяли вручную | Есть осмысленное применение Claude в анализе, коде, review, документации | Есть не только использование, но иногда и проектирование workflow-слоя: agents, policy, team assets |
Самый важный вывод из этой таблицы такой: Senior не обязан быть «больше», он обязан быть глубже. Junior не проигрывает из-за отсутствия migration slice или team policy. Аккуратный MVP не ругают за отсутствие compatibility matrix — ругают за расплывчатый scope, непроверяемый result, vague usage Claude Code и проект, который держится на «но идея была классная».
Здесь очень помогает помнить про capstone-формат. Сравнивать Support Inbox MVP и Migration slice — как спорить, кто лучше, отвёртка или микроволновка. Оба полезны в разных задачах. Поэтому advanced-части rubric привязаны к формату: MVP — user value, demo scenario и scope discipline; migration slice — compatibility, rollback и validation evidence; team workflow design — policy, governance и package maturity.
Если это правило забыть, начинается забавная, но грустная картина: студент с хорошим MVP лепит псевдо-миграционные заметки «для солидности», а студент с migration capstone добавляет лишний UI «для красивой морды». Сильная работа — не максимум всего подряд, а попадание в ожидания своего уровня и формата.
4. AI-native workflow: уместность важнее зоопарка
Самый коварный участок. На словах все согласны с правилом relevance over quantity, а на практике рука тянется написать: «использовал 3 агентов, 2 hooks, MCP, custom skill и ещё одну штуку, которая называется красиво, но уже никто не помнит зачем». Для ментора это не зрелость, а AI-зоопарк.
Сильный AI-native workflow — это не перечисление механизмов Claude Code, а объяснение, какую конкретную инженерную проблему каждый из них решал. Иногда ответ — «никакую, поэтому я их и не использовал». И это, между прочим, отличный ответ.
Сравните два варианта описания.
Плохой вариант
Использовал 2 hooks, 3 agents, MCP server и custom plugin.
Claude очень помог в разработке.
Хороший вариант
Использовал `issue-analysis` skill для уточнения критериев приёмки.
Запускал reviewer-agent в read-only режиме перед демонстрацией diff.
После этого вручную проверил изменения и прогнал smoke check.
Hooks и MCP не подключал: для этого capstone они не давали дополнительной ценности.
Во втором варианте сразу видно: вы управляли инструментами, а не они вами. Rubric хочет не «вау, сколько включено», а «я понимаю, зачем это нужно и почему что-то не понадобилось».
Ещё полезнее смотреть на advanced credit через призму формата capstone.
| Формат capstone | Что особенно усиливает оценку |
|---|---|
| Feature in existing codebase | issue-to-PR trail, хороший diff, checks, reproducible walkthrough |
| AI-native MVP | user/JTBD, чёткий release slice, убедительный demo scenario |
| Legacy modernization | characterization tests, маленькие безопасные refactor-шаги, behavior preservation |
| Migration slice | compatibility matrix, rollback plan, validation evidence |
| DevOps automation | воспроизводимость pipeline, логи, bounded automation, явные границы риска |
| Team workflow design | policy, package maturity, plugin/skill architecture, governance |
Эта таблица очень хорошо лечит от лишнего героизма. У вас Support Inbox MVP — помогут пользовательский сценарий, SPEC.md, честные checks и роль Claude Code, а не насильно выращенный migration appendix. У вас migration slice — никто не ждёт посадочной страницы с тремя градиентами; ждут evidence, rollback, parity, понимание рисков.
Иногда самый высокий балл даёт не «ещё один инструмент», а строка в EVIDENCE.md, где видно, что вы сознательно остановились: «агента на write не переводил, потому что задача затрагивала критичный модуль». Это говорит о зрелости сильнее пяти заявлений про «активное использование AI».
5. Самостоятельный прогон rubric перед защитой
Самая полезная привычка в этом модуле — перестать относиться к оценке как к сюрпризу. Пока вы в режиме «надеюсь, ментору понравится», защита — лотерея. Откройте rubric, честно сопоставьте её со своими артефактами — и защита станет обычной инженерной проверкой. Волнение останется, мистика уйдёт.
Самопроверку удобно вести не в числах, а в простых статусах: strong, medium, weak. Это человеческий формат. Без иллюзии точности, зато сразу видно, где проект крепкий, а где хрупкий.
Вот минимальный шаблон, с которого можно начать:
| Направление | Статус | Evidence |
|-------------------|--------|----------|
| working result | strong | `DEMO.md`, видео, smoke check |
| task spec quality | medium | `SPEC.md` есть, критерии приёмки можно сузить |
| tests/checks | weak | есть только smoke, нет regression test |
| Claude usage | strong | `EVIDENCE.md`, review notes, ручная проверка diff |
Вся хитрость в третьей колонке. Статус без evidence — это просто настроение. Ставите strong — покажите артефакт. Ставите weak — зато знаете, где именно слабое место. Уже половина пользы.
Очень часто после такого self-check вскрывается полезная правда: working result strong, а tests/checks — medium, потому что есть только smoke; или Claude usage weak-medium, потому что в EVIDENCE.md всё общими словами — «Claude помогал с кодом». Ментор это тоже увидит. Лучше познакомиться с мыслью дома, за чаем, чем на защите.
И ещё один взрослый вывод: слабая строка в одном базовом направлении часто важнее нескольких красивых advanced-фишек. Weak reproducibility не спасёт лишний agent, vague task spec не исправит аккуратный hook. Rubric не даёт замазать фундамент красивой мишурой.
Когда вы честно прогоняете capstone по этой матрице, проект не становится хуже — он становится видимым. Вместо нервного «вдруг оценят не то» появляется карта: где результат силён, где процесс собран, где качество подтверждено, а где AI-native workflow надо объяснить точнее. Один из самых полезных навыков финального блока курса.
Именно поэтому self-check делайте до внешнего review. Если строка держится только на ощущении, mentor увидит ту же дыру снаружи. Лучше прийти на review с понятной картой: где capstone уже strong, где medium, а где нужна доработка или честное ограничение.
ПЕРЕЙДИТЕ В ПОЛНУЮ ВЕРСИЮ