Уровневые expectations и guardrails

1. Capstone нельзя мерить одной линейкой

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

Если пытаться оценивать всех одной линейкой, картина получится странной. Junior берёт migration slice, потому что «звучит серьёзно», тонет в совместимости зависимостей и планах отката и до демо не доживает. Senior делает симпатичный экранчик без рисков, валидации и компромиссов — формально работает, а владение процессом не раскрыто. Дело не в том, что один хуже. Доказывать им нужно разное.

Вот полезная короткая таблица, которую стоит держать в голове весь блок:

Обратите внимание: нигде нет пункта «написать побольше кода». Главный герой capstone — ваш процесс работы, а не то, что результат возник из тумана после ночного диалога с Claude.

2. Уровневые expectations: разные фокусы оценки

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

Поэтому правильнее думать не «Junior — маленький capstone, Senior — большой», а иначе: Junior доказывает завершённость, Middle — управляемость, Senior — контролируемую сложность. Это важно ещё и потому, что снимает лишнюю театральность: изображать Senior ради впечатления не нужно. Скромный, но честно доведённый проект с хорошим verification trail сильнее полуразрушенного «супераппа», который на словах умеет всё, а на демо открывает главную страницу и загадочно обещает масштабироваться.

3. Junior: законченный core flow важнее амбиций

Для Junior capstone должен выглядеть не как мини-стартап, а как один внятный, законченный, проверяемый сценарий. Ключевое слово здесь — законченный. Не «почти работает», не «тут руками подправить JSON — и будет красиво», не «потом добавлю обработку ошибок». Core flow проходится от начала до конца и пересказывается за пару предложений: оператор видит список заявок на отмену подписки, открывает карточку, подтверждает действие, получает статус. Этого достаточно, если есть SPEC.md, базовый README, простая smoke-проверка и объяснение, где помогал Claude, а что вы проверяли сами.

Вот так может выглядеть фрагмент хорошего Junior SPEC.md:

# Фрагмент SPEC.md

Проблема: оператору неудобно вручную отменять тестовую подписку
Core flow: открыть клиента → нажать «Отменить» → подтвердить действие
Smoke check: отмена тестовой подписки проходит без ошибки
Не входит: роли, email-уведомления, платежный возврат, деплой

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

Для Junior особенно важно запомнить простое правило: отсутствие advanced mechanisms — не слабость. Не используете MCP, hooks, собственных агентов и plugin-архитектуру — нормально, пока workflow дисциплинирован. Иногда лучший инженерный поступок на Junior — честно отказаться от красивой ненужной сложности. Накануне дедлайна это смотрится не так эффектно, зато зрело.

4. Middle: проект становится не больше, а прозрачнее

На Middle-уровне capstone не обязан внезапно раздуться в три раза. Отличие не в числе экранов, а в том, что становится видимым сам процесс разработки. Junior доказывает «я умею закончить», Middle — «я умею вести инженерную задачу по шагам и не терять контроль».

Это означает, что от вас уже ждут не просто рабочий сценарий, а структуру движения к нему: разбиение на задачи, «сначала план, потом код», небольшие коммиты, проверки, чтение diff, обновление документации, demo scenario. Claude Code здесь — уже не только «помощник написать код», но и инструмент для исследования, черновиков документации, ревью и проверки гипотез.

Например, один и тот же сценарий отмены подписки на Middle-уровне может сопровождаться приземлённым, но сильным планом:

## План реализации

1. Описать текущий сценарий и критерии приёмки
2. Добавить экран подтверждения отмены
3. Добавить smoke- или regression-проверку
4. Проверить diff и обновить README

Или даже так, в истории коммитов:

feat: добавить экран подтверждения отмены подписки
test: добавить smoke-сценарий отмены
docs: обновить README и DEMO.md

С виду это не космические технологии. Но именно такие вещи отделяют «у меня получилось» от «я умею инженерно провести задачу от идеи до демонстрации».

На Middle-уровне особенно часто срабатывает забавная ловушка. Студент думает: «Чтобы показать рост, надо больше фич», — и добавляет второй поток, третий экран, четвёртую интеграцию. Рост показывается иначе: через traceability и управляемость. Проект попроще, но с ясным SPEC.md, понятным backlog, небольшими коммитами, checks, demo path и внятным README — сильнее хаотичного «богатого» продукта, который не воспроизвести с холодного старта. Middle — момент, когда capstone из «просто штуки, которая работает» становится хорошо рассказанной инженерной историей.

5. Senior: сложность только вместе с доказательствами

На Senior-уровне действительно можно брать более тяжёлые форматы: legacy modernization, migration slice, DevOps automation, team workflow design. Но вместе с уровнем приходит важное правило: сложность не запрещена, но она должна быть оплачена доказательствами. Это значит, что формула «сделал сложную штуку — значит молодец» не работает.

Если вы трогаете legacy-зону — нужны исследование с опорой на evidence, RISK_MAP.md и понимание границ изменения. Migration slice — нужны не только план обновить зависимости, но и логика валидации, мышление о совместимости, путь отката. Team workflow design — сила не в словах «plugin», «policy», «agents», а в наличии owner, README, change log, границ использования и объяснении, зачем этот toolkit нужен команде.

Фрагмент Senior-артефакта может выглядеть вот так:

## Риск

Security-конфиг затрагивается миграцией

## Проверки
- логин
- refresh-сессия
- отмена подписки авторизованным пользователем

## Откат
вернуться на последний зелёный тег и отключить migration branch

Обратите внимание: здесь мало пафоса, много скучной взрослой аккуратности. Сила Senior-уровня выглядит именно так — не как фейерверк, а как способность объяснить, почему выбран этот путь, а не красивый, но опасный rewrite. Здесь многие пытаются впечатлить громкими словами: «DevOps automation с AI agents и governance» звучит красиво, но без воспроизводимого сценария, артефактов и объяснения, кто что проверяет и как проект откатывается, это остаётся красивой вывеской.

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

6. Scope guardrails: ограничения, спасающие capstone

Слово guardrails можно перевести по-человечески как «ограничители» или «защитные рельсы». Звучит не слишком романтично, но работает прекрасно: нужны они, чтобы capstone не уехал в кювет на середине курса с гордым лозунгом «зато идея была амбициозная». Главная мысль здесь простая: в capstone почти всегда опаснее добавить лишнее, чем убрать. Каждое «ещё маленькое улучшение» тянет за собой новые проверки, сценарии, unknowns и шансы сломать демо.

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

flowchart TD
    A[Идея capstone] --> B{Есть один core flow?}
    B -- Нет --> C[Сузить scope]
    B -- Да --> D{Соответствует вашему уровню?}
    D -- Нет --> E[Упростить формат или идею]
    D -- Да --> F{Нужны advanced mechanisms?}
    F -- Нет --> G[Не добавлять их ради красоты]
    F -- Да --> H[Записать, какую боль они решают]
    G --> I[Зафиксировать в SPEC.md]
    H --> I

Эта схема специально скучная — как и вся дисциплина guardrails. Но именно она спасает больше capstone-проектов, чем любой мотивационный спич. Самые частые guardrails выглядят так:

## Не входит в проект

- production deployment
- реальный платежный провайдер
- многоарендность
- push-уведомления
- административная панель

Многим студентам поначалу кажется, что такой блок — признание слабости. На самом деле это выглядит как инженерная зрелость. Строить весь мир вы не обязаны — вы обязаны честно ограничить мир проекта до размера, который сможете защитить.

Есть несколько особенно коварных ловушек. Первая — обещание «production-ready»: для учебного capstone это размывает границы и открывает бесконечный список — а где наблюдаемость, деплой, безопасность, план восстановления? Честнее: «прототип, готовый к демо, с воспроизводимым core flow и понятными ограничениями». Вторая — сложные интеграции с авторизацией и оплатой «для реализма»: реализм заканчивается там, где начинается отладка конфигов вместо подготовки демо. Третья — advanced mechanisms ради красоты: если agent, hook, plugin, MCP или сложная автоматизация не решают конкретную боль проекта, они засоряют capstone.

Проще говоря, если вы не можете в одном предложении ответить на вопрос «зачем здесь этот механизм?», его, скорее всего, не должно быть.

7. Примеряем идею к своему уровню

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

# Проверка идеи capstone

Мой уровень:
Формат:
Какой один сценарий я покажу на демо:
Что в проект точно не входит:
Какие 2–3 проверки я реально смогу показать:
Где Claude поможет:
Что я буду проверять руками:

Если на строке про сценарий вы начинаете писать полстраницы — core flow не найден. Строка «Что не входит» пуста — scope не зажат. На строке про проверки начинается нервный кашель и взгляд в потолок — verification-часть не продумана. А «Где Claude поможет» звучит как «ну… вообще везде» — проект пока слишком туманный.

Если этот шаблон заполняется спокойно — у вас уже есть результат этой лекции: выбранный формат, один core flow и список того, что в проект точно не входит. Дальше именно это и переедет в SPEC.md, а не туманное «хочу сделать что-нибудь полезное с AI».

Очень хороший признак зрелой идеи — когда вы можете объяснить её спокойно, без спецэффектов: «Я Middle, беру Feature in existing codebase. На демо покажу отмену подписки с подтверждением, smoke-проверку и воспроизводимый README. Не делаю деплой, не трогаю реальные платежи и не добавляю агентов, потому что они не решают конкретную боль проекта». Не блокбастер. Зато проект, который реально можно довести и защитить.

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