# 17. Разбор заметок: ступень ревью, род работы, роадмап (2026-08-04) ## Что было Семь заметок из `NOTES.md`, накопленных по ходу работы: переименование `PLAN.md`, тип у каждой задачи, цвета сабагентов по модели, кавычки во фронтматтерах, уровни ревью для проекта, задачи в терминах функций и границ, язык задач без англицизмов. Разного размера и из разных мест, но три из них оказались об одном — **о том, можно ли оценить задачу, не открывая код**. ## Решено **Р60. Цвет charter'а кодирует модель, а не роль прохода.** Раскладка `sonnet` → green, `opus` → yellow, `fable` → red. Роль прохода видна из имени, а стоимость прогона — ниоткуда; цвет, розданный по ролям, не отвечает ни на один вопрос, который задают во время прогона. Дом раскладки — таблица «Модель по проходу» в `review-pipeline/SKILL.md`. **Р61. Фронтматтеры проверяются машиной, а не вниманием.** Три описания из четырнадцати содержали `: ` в незакавыченном значении — для YAML это вложенное отображение, то есть синтаксическая ошибка, которую **нельзя увидеть чтением**: текст читается правильно. Тот же класс, что у mermaid-диаграмм, и лечится тем же способом — `scripts/frontmatter.py`. Он же держит раскладку цветов (HHH) и сверку `name` с именем каталога. **Р62. Между `standard` и `deep` заведена ступень `wide`.** *(содержание триггеров пересмотрено темой 18, [Р72](18-tier-raises-pass-not-risk.md): миграция схемы и публичный контракт ступень не поднимают.)* Прыжок стоил самого дорогого прохода конвейера, а платить приходилось за одну архитектурную находку: изменений, которые трогают публичный контракт, но не вводят нового правила слияния, — большинство. `wide` — это `standard` плюс `architecture` (вход шире диффа, отсюда имя), семь проходов против восьми у `deep`. **Р63. Триггер независимой реализации стал триггером профиля.** Раньше условие «изменение вводит новое правило идентичности, слияния или разбора» стояло **внутри** `deep`, и профиль означал то семь проходов, то восемь. Реестр состава, который «сверяется взглядом до коммита», проверять было нечем: у профиля не было одного правильного ответа. Теперь условие выбирает профиль, а `reimpl` в `deep` безусловен — и он единственное, чем `deep` отличается от `wide`. **Р64. Барьер стоимости остался только в `deep`.** В `wide` за ним стоял бы один дешёвый проход с потолком в 3 находки, а барьер не бесплатен — он сериализует то, что могло идти разом. Вторая причина помельче: барьер спрашивает «выживает ли форма изменения», а `architecture` — как раз тот, кто на этот вопрос отвечает. **Р65. Род работы — вторая ось типа, и живёт тегом.** Тип записи (`goal`/`idea`/`epic`/`task`) отвечает «что это за запись», род (`feature`/`fix`/`chore`/`research`) — «какого рода работа». В один префикс их не свести: идея бывает *про* функцию, эпик функцией *и является*. Дом — тег `kind:<род>`, потому что теги здесь и есть единственный механизм разметки, а `list --kind` работает даром. Принятая цена: в строку индекса род не попадает (индексы производны), и состав набора по роду виден командой, а не глазами. Словарь **закрыт** — открытый разъехался бы на синонимах `bug`/`bugfix`/`fix`. **Р66. У `chore` тест готовности ослаблен честно.** Вопрос «что станет наблюдаемо иначе» для обслуживания отвечается разработчику, а не пользователю. Пока рода не было, такие задачи либо не заводились, либо придумывали себе пользовательскую пользу — и это второе хуже: оно проходит проверку. **Р67. Задача называет границы, а не намерения.** Раздел «Затрагивает» — эндпоинт, таблица и миграция, формат на диске, публичный тип пакета. Без него задача оценивается по объёму текста, а не по объёму поверхности, и оценка систематически занижена ровно там, где текст короткий, а границ много. Механизм проверяет **наличие** непустого раздела: полноту перечня машина не видит, и делать вид, что видит, хуже, чем не проверять. **Р68. Род и границы требуются к взятию в спринт, а не к заведению.** Тот же приём, что уже работает для критериев приёмки, и по той же причине: беклог пополняется чаще, чем разбирается, а требование на входе выгоняет в заметки то, что должно лежать задачей. `check` о пропаже напоминает замечанием — иначе два живых проекта покраснели бы на 98 задачах, заведённых до этого решения. **Р69. `PLAN.md` → `ROADMAP.md`, вместе с ключом конфига и токенами команд.** Слово «план» в репозитории значит три разных вещи — оглавление целей, план реализации внутри задачи и `PLAN.json` разовой адаптации. Переименовано всё: `tasks.plan` → `tasks.roadmap`, `--index plan` → `--index roadmap`, `--plan-sections` → `--roadmap-sections`. Старый ключ в `docs/.pm.json` не игнорируется молча — скрипт останавливается и называет переименование. ## Что из этого следует **С68. Версия канона 3 занята этим изменением.** Отложенное решение [темы 16](16-directory-instead-of-file.md) (каталог вместо файла в `docs/`) вводится теперь версией **4**, а не 3. **С69. Род работы ничего не предписывает конвейеру.** Профиль ревью выбирается по факту изменения: `chore` бывает миграцией схемы, `fix` — правкой публичного контракта. Правило «предписание процесса в теле задачи снимается» родом не отменяется, а подтверждается. **С70. Проверка фронтматтеров — третья проверка репозитория того же класса.** Копии, диаграммы, фронтматтеры: всё это ошибки, невидимые при чтении. Класс опознаётся по признаку «диff выглядит разумно, а результат ломается», и каждый его представитель получает скрипт, а не пункт чек-листа. **С71. Ступеней профиля четыре, и правило выбора читается сверху вниз.** Первое сработавшее условие и есть ответ: правило слияния → `deep`, контракт или схема → `wide`, видимое снаружи поведение → `standard`, иначе `quick`.