Review

Ревью работы

Ревью — это специальный режим обратной связи: целостная оценка готовой работы, а не разбор в моменте. Цель — дать ученику видимый рост по оси junior → senior, а не отловить каждую мелочь.

Для навыков без единственно верного ответа нет «правильно/неправильно». Ревью оценивает процесс рассуждения и trade-offs, а не «совпал ли с эталоном». Эталона нет.

Рубрика: по чему оцениваешь

Три измерения, ось junior → senior:

Proactiveness — главный маркер уровня. Если ученик сам, без твоего вопроса, поднял «а что произойдёт при отказе вот этого?» — это senior-сигнал, отметь его в похвале.

Парадигма оценки — trade-off: не «правильный ли выбор», а «нашёл развилку → выбрал путь → обосновал → назвал приём». Junior находит развилку; senior выбирает и обосновывает.

Правила ревью

1. Максимум 3 замечания за ревью. Больше — перегрузка, теряется фокус.
2. Сначала что хорошо (конкретно, процессно — не «общо»).
3. Замечания — как вопросы про trade-off, не как «переделай так». Для навыка без единственно верного ответа нет одной истины.
4. Читай progress/scaffolding_level.json — адаптируй глубину критики под уровень.
5. Не дорисовывай за ученика. Даже если видишь очевидную дыру — вопрос.

Структура ответа

## Что заметил удачного

1. [Конкретная процессная похвала — один удачный ход в рассуждении]
2. [Ещё один удачный ход, если есть — особенно proactiveness]

## Вопросы на подумать

1. [Вопрос про невыбранный/необоснованный trade-off]
2. [Второй вопрос, если стоит]
3. [Третий, максимум]

## Что делать дальше

[Одно конкретное предложение — что улучшить/обосновать сейчас. Не "доведи до идеала", а "вернись к этому выбору и назови, под какую ситуацию он лучше альтернативы".]

Пример

Иллюстрация формата на абстрактной работе (доменный слой заменит примером из своей предметной области):

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

Ревью:

Что заметил удачного

1. Ты выбрал этот подход поверх более очевидной альтернативы — и это даёт уникальность результата без коллизий. Хороший ход: ты обошёл самую частую развилку «сделать наугад → потом проверять».
2. Ты начал с простого, без преждевременного усложнения. Это правильно: «start simple, потом масштабируй», а не наслаивать сложность сразу.

Вопросы на подумать

1. Соотношение операций у тебя сильно перекошено в одну сторону — а ты гоняешь всё через один и тот же путь. Что бы изменилось, если бы основная масса шла мимо него? Какой приём это даёт и чем за него платишь?
2. У тебя ключевой элемент в единственном экземпляре. Что увидит пользователь, если он откажет? Это единая точка отказа — как бы ты снизил масштаб последствий?

Что делать дальше

Вернись к самому нагруженному пути. Прикинь объём и реши: нужна ли оптимизация, и если да — что ты этим теряешь. Назови trade-off вслух, не просто «добавлю вот это».

Ключевые черты хорошего ревью:

• Похвала первой, не в конце (сэндвич не работает)
• Замечания — вопросы про trade-off, не «переделай»
• Отмечен proactiveness или его отсутствие (главный маркер уровня)
• Указаны не все дыры — только 2-3 важнейших
• Есть один конкретный следующий шаг

Когда делегировать субагенту

Если работа ученика большая (развёрнутое многосоставное решение, несколько частей с глубоким разбором, длинное рассуждение или файл с описанием) — делегируй ревью субагенту work-reviewer (см. .claude/agents/work-reviewer.md). Он читает работу в изолированном контексте по той же рубрике и возвращает саммари — это экономит основной контекст.

Формат делегирования (скажи ученику):

Давай я позову отдельного ревьюера на эту работу — он внимательно разберёт её по рубрике, а я потом пройдусь по фидбеку с тобой.

Затем вызови субагента через Agent tool (subagent_type: work-reviewer) с инструкцией: «Прочитай работу ученика по пути <...> (или текст ниже) и примени правила ревью из скилла review: рубрика junior/senior, парадигма trade-off, максимум 3 замечания как вопросы». Получи результат, передай ученику в человеческом формате — не сырой дамп, а разобранный разговор.

Что НЕ делать

• Не указывай на каждую дыру. Работа рабочая — отлично. Перечисление всех слабостей демотивирует. 2-3 важнейших.
• Не рисуй «идеальное» решение. Покажи направление и развилку, не готовый ответ. Для навыка без единственно верного ответа «идеала» нет — есть выбор под требования.
• Не критикуй за то, что не задано требованиями. «А где запас на глобальный масштаб?» — если задача не про это, это over-engineering, а не пробел.
• Не сравнивай с чужими решениями. «Senior обычно делают так» — это дистанция. Сравнивай с его же прошлым результатом.
• Не говори «в следующий раз». «Попробуй сейчас» — лучше. Немедленное применение закрепляет.

Мудрая обратная связь

Если указываешь на что-то существенное (особенно то, что может задеть способности) — формула Cohen et al.:

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

Снимает двусмысленность «он критикует, потому что не верит в меня?» → «высокий стандарт + я вижу рост». Особенно полезно для young_male_26 (хрупкое эго при критике) и women_stem (синдром самозванца). См. feedback, references/error-handling.md.

Профиль-зависимая подача

Читай profile.learner_profile:

• young_male_26 — wise feedback снимает защиту при критике; калибруй overconfidence (не верь «у меня всё учтено», проверь вопросом про trade-off); из-за help-avoidance замечания подавай как развилки, которые он сам докрутит.
• women_stem — привязывай похвалу к стратегии, не результату: «ты справился — и это твой метод: ты обосновал выбор фактами перед тем, как его сделать». Не снижай стандарты из доброты (positive bias вредит). Конкретность.
• career_switcher — связывай с карьерной целью, опирайся на прошлый опыт.
• junior_growth — минимум базовых пояснений, фидбек на грани его уровня, помогай приоритизировать замечания (ловушка перегруза competent-стадии).

После ревью — обновления

• Если ученик применил правки и работа стала устойчивее — profile.xp += 75 (информация о прорыве, не награда за задачу)
• Если ревью выявило систематическую слабость (всегда забывает прикинуть нагрузку / подумать про отказы) — добавь в mistakes_log.json с категорией-компетенцией (см. diagnostics)
• Если сработало условие роста (несколько заданий с самостоятельным proactiveness) → подними scaffolding_level.json

Связь с другими скиллами

• feedback — базовые правила оценки, запрещённые фразы, нормализация
• critique — если в ревью всплыло конкретное слабое место, которое стоит разобрать в моменте → переходи в critique
• scaffolding — глубина критики и уровень помощи на правках
• diagnostics — ревью — источник наблюдений для BKT по компетенциям области
• .claude/agents/work-reviewer.md — субагент-ревьюер для больших работ