Mentor review и remediation backlog

1. Рабочее демо отвечает не на тот вопрос

Когда capstone уже показывает рабочее демо, очень хочется внутренне выдохнуть и решить, что дальше будут только похвала, немного аплодисментов и торжественное закрытие ноутбука. На практике всё наоборот. Демо отвечает только на «запускается ли проект». Mentor review — на взрослый вопрос: можно ли результату доверять и понимаете ли вы, что сделали.

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

Mentor review нужен не затем, чтобы поймать вас на ошибке, а чтобы проверить проект там, где рядом нет автора, который всё объяснит голосом. Mentor открывает README.md, запускает проект, смотрит SPEC.md, читает EVIDENCE.md, оценивает проверки, задаёт вопросы. Картина ясная — capstone созрел. Нет — слабые места стали видимыми.

flowchart TD
    A[Рабочее демо] --> B[Mentor review]
    B --> C[Проверка доверия]
    C --> D[Grading по rubric]
    D --> E[REMEDIATION.md]

Заметьте важную вещь: review не отменяет защиту — он её продолжает. На защите вы рассказываете, как мыслите; на review mentor проверяет, выдерживает ли эта логика встречу с кодом, тестами и ограничениями.

На этом этапе особенно хорошо видны проекты, где автор слишком доверился Claude. Mentor спрашивает: «Откуда видно, что этот тест покрывает основной сценарий?» — и сразу ясно, был ли инженерный контроль или вы ехали по красивому AI-потоку в надежде, что он сам довезёт.

2. Ментор читает проект как историю решений

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

Если упростить, mentor почти всегда проходит по одним и тем же направлениям. Это не магия и не настроение дня — это продолжение знакомой вам rubric.

Теперь давайте приземлим это на наш пример с CSV Validator. Демо работает: система валидирует структуру и показывает отчёт по ошибкам. Mentor посмотрит глубже. Что будет с пустым CSV? Почему в SPEC.md обещан экспорт, а в демо только просмотр — и если экспорт убрали из scope, есть ли это в артефактах?

Вот здесь и становится заметно, что review — это чтение проекта как истории решений. Mentor восстанавливает ваш инженерный ход мысли по файлам. Может восстановить — capstone взрослый. Не может — проект кажется хрупким, даже когда на экране всё красиво мигает и не падает.

Полезно помнить ещё одну вещь: mentor не ждёт идеальности — он ждёт честности и управляемости. Написали прямо, что edge case с пустым датасетом не покрыт, — зрелый сигнал. «Ну вроде должно работать» — плохой. Разница не в коде, а в инженерной позиции.

3. Разговор на review без выпадов и паники

Самая частая проблема на review вообще не техническая, а эмоциональная. Когда человек слышит замечание после длинной работы, мозг любит реагировать как маленький личный адвокат: «Сейчас быстро объясню, почему это не проблема». Именно в этот момент разговор и портится.

Важно помнить простую вещь: mentor review — это не суд над вашей личностью. И не roast-session, хотя после третьего замечания иногда действительно хочется посмотреть в окно и задуматься о спокойной жизни садовника. Код не обижается, файлы не переживают — комментарии здесь данные, а не нападение.

Хороший разговор на review почти всегда строится вокруг уточнения. Mentor говорит, что проверки слабые, — не спешите с «но у меня же 12 тестов»: количество редко что-то доказывает. Полезнее спросить, что именно смущает: связь тестов с основным сценарием, непокрытый edge case, отсутствие smoke-check, неочевидный запуск, слабая привязка к SPEC.md. Разговор становится инженерным.

Ниже — очень типичный пример.

Ментор: Где видно, что ваши тесты покрывают основной сценарий, а не только
мелкие функции вокруг него?

Плохой ответ:
"Ну я же их запускал, они зелёные."

Хороший ответ:
"Понял вопрос. Сейчас в `TEST_PLAN.md` у меня нет явной привязки тестов к шагам
основного сценария. Значит, проблема не в количестве тестов, а в их связи
с демо-потоком. Это стоит вынести в доработки."

Сильный ответ на review почти всегда звучит спокойно и предметно. Вы не оправдываетесь — уточняете смысл замечания, проверяете, правильно ли поняли риск, и думаете, как зафиксировать: правкой кода, дописанным README, оформленным ограничением или переносом в Later.

Ещё один хороший навык — не отвечать всем сразу «да, всё исправлю»: mentor слышит не готовность к работе, а размывание приоритетов. Сильнее развести замечания: это бьёт по воспроизводимости — Must fix, а это усиливает документацию — Should fix. Так вы управляете изменениями, а не киваете.

4. Замечания превращаются в grading

После review у многих возникает ощущение, что grading — таинственная математика: семь замечаний, минус семь пунктов. К счастью, это не так. Оценка в capstone не диктант, где каждая ошибка минусует одинаково, а общая оценка доверия к вашему результату.

Mentor смотрит на те же направления rubric и собирает их не в арифметику, а в картину. Один серьёзный провал — проект невозможно запустить по README.md — весит сильнее пяти мелких stylistic comments. И наоборот: несколько небольших замечаний не ломают оценку, если сценарий воспроизводим, ограничения честно описаны, evidence убедителен.

Очень полезно смотреть на grading через сравнение типичных ситуаций.

Здесь как раз работает правило relevance over quantity, которое вы уже видели. Пять skills, три agents и один MCP-сервер сами по себе оценку не улучшают. CSV Validator с хорошим CLAUDE.md, внятным task spec, небольшими diff и аккуратными проверками часто сильнее проекта, где навесили половину возможностей Claude Code просто потому, что они есть.

Очень важный нюанс: grading учитывает не только то, что уже исправлено, но и то, как вы мыслите после замечаний: быстро поняли смысл, классифицировали риск, сформулировали доработку — сигнал зрелости. Поэтому не стоит воспринимать review как отъём баллов — правильнее видеть в нём проверку на честность. Иногда именно благодаря ей видно: у вас аккуратный, скромный, но зрелый capstone — ценнее эффектного хаоса.

5. Remediation backlog: управляемый план доработок

После хорошего review почти всегда накапливается набор замечаний. И вот здесь легко совершить классическую ошибку новичка — записать всё в один список «доделать потом»: такие списки живут недолго. Чтобы этого не произошло, превратите замечания в remediation backlog — приоритизированный список доработок.

Здесь помогает очень земная аналогия. Если течёт крыша, а вы одновременно думаете про новый цвет штор, сначала всё-таки крыша. Не потому, что шторы не важны, а потому, что важен порядок. В backlog хватает трёх корзин.

Must fix

Should fix

Later

Отдельная польза этой схемы в том, что она не даёт обещать невозможное. «Было бы здорово добавить поддержку XLSX» — не тащите в срочные правки: capstone защищался как минимальный CSV-инструмент, значит, XLSX — честный Later. А отсутствие инструкций по запуску — уже не Later: без них проект перестаёт быть воспроизводимым.

Ниже — простой пример REMEDIATION.md, который действительно можно держать в корне репозитория рядом с другими capstone-артефактами.

# REMEDIATION.md

## Must fix
- Указать версии Python и Node в `README.md`.
- Добавить scenario-level test для пустого CSV.

## Should fix
- Связать тесты с шагами основного сценария в `TEST_PLAN.md`.
- Добавить ссылки на ключевые коммиты в `EVIDENCE.md`.

## Позже
- Поддержка XLSX.
- GitHub Actions для smoke-check.

Обратите внимание на важную деталь: хорошие пункты backlog почти всегда конкретные. Не «улучшить документацию», а «указать версии Python и Node». Не «доработать тесты», а «добавить scenario-level test для пустого CSV». Конкретную запись можно проверить; размытая создаёт ощущение вечного долга.

Ещё полезнее — переводить замечание в backlog с объяснением приоритета. Это и есть feedback loop: вы не просто слышите критику, вы управляете ею.

6. Фиксация review: чтобы он не испарился через час

Даже очень хороший review бесполезен, если уже к вечеру вы не помните, что mentor имел в виду под «слабой связью тестов с основным сценарием». Поэтому замечания нужно заземлять письменно — иначе память сгладит формулировки, а backlog превратится в набор фраз, которые через три дня вы будете расшифровывать как археолог.

Удобнее всего держать review в разделе Review log внутри REVIEW_NOTES.md или, если ведёте всё компактно, внутри EVIDENCE.md. Смысл не в названии, а в привязке замечаний к направлениям rubric — чтобы не потерялся контекст.

Вот как это может выглядеть.

## Лог ревью

| Направление    | Статус  | Комментарий |
|----------------|---------|-------------|
| Task spec      | strong  | `SPEC.md` чётко ограничивает scope |
| Tests/checks   | weak    | Нужен scenario-level test для пустого CSV |
| Documentation  | medium  | Нет версий рантайма в `README.md` |
| AI workflow    | medium  | Роль Claude описана, но без ссылок на diff review |

Такой log сразу показывает две вещи. Во-первых, проект почти никогда не бывает «весь плохой» или «весь хороший». Во-вторых, review из массы замечаний превращается в карту проекта: здесь вы сильны, здесь нужен ремонт, здесь достаточно уточнения.

Дальше связка работает просто. Замечание из Review log либо уходит в пункт REMEDIATION.md, либо фиксируется как accepted limitation: отсутствие XLSX остаётся в Later и одновременно пишется в README.md как известная граница версии. Не каждое замечание заканчивается изменением кода — иногда достаточно честно оформить ограничение и не выдавать проект за то, чем он не является.

Когда замечания спокойно раскладываются по Must fix, Should fix и Later, capstone звучит иначе — не как демо, которому повезло довезти до защиты, а как проект, которым управляет разработчик. Feedback перестаёт быть формальностью и становится частью вашего инженерного почерка.

Но на этом review-loop не заканчивается. Вынести из него нужно не «проекту бы ещё доработки», а конкретные Review log, REMEDIATION.md и accepted limitations — и вернуть в артефакты: про запуск — в README.md и demo-path, про проверки — в TEST_PLAN.md и EVIDENCE.md, про границы — в limitations и карточку проекта.

1

Задача

Claude code, 32 уровень, 3 лекция

Недоступна

Исправление AI-generated remediation backlog

Исправление AI-generated remediation backlog

Открыть

1

Задача

Claude code, 32 уровень, 3 лекция

Недоступна

Создание remediation backlog

Создание remediation backlog

Открыть