dev-skills/decisions/17-notes-tier-work-kind-roadmap.md

# 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`.