Files
dev-skills/decisions/17-notes-tier-work-kind-roadmap.md
T
av bf6a173115 журнал решений: разложен по теме на файл, метки решений стали номерами
- DECISIONS.md (4040 строк, 65 тем) → decisions/, файл на тему плюс указатель;
- буквенные метки решений заменены сквозными Р1–Р234, следствия получили
  префикс С при прежних номерах: схема букв выродилась до пятибуквенных и
  сломалась — `АЕАКЛ` была занята и темой 53, и темой 65;
- 42 перекрёстные ссылки переписаны под новые номера и стали живыми; где номер
  означал тему, а слово стояло «решение», формулировка исправлена.
2026-08-13 12:40:56 +03:00

9.4 KiB
Raw Blame History

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: миграция схемы и публичный контракт ступень не поднимают.) Прыжок стоил самого дорогого прохода конвейера, а платить приходилось за одну архитектурную находку: изменений, которые трогают публичный контракт, но не вводят нового правила слияния, — большинство. 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.mdROADMAP.md, вместе с ключом конфига и токенами команд. Слово «план» в репозитории значит три разных вещи — оглавление целей, план реализации внутри задачи и PLAN.json разовой адаптации. Переименовано всё: tasks.plantasks.roadmap, --index plan--index roadmap, --plan-sections--roadmap-sections. Старый ключ в docs/.pm.json не игнорируется молча — скрипт останавливается и называет переименование.

Что из этого следует

С68. Версия канона 3 занята этим изменением. Отложенное решение темы 16 (каталог вместо файла в docs/) вводится теперь версией 4, а не 3.

С69. Род работы ничего не предписывает конвейеру. Профиль ревью выбирается по факту изменения: chore бывает миграцией схемы, fix — правкой публичного контракта. Правило «предписание процесса в теле задачи снимается» родом не отменяется, а подтверждается.

С70. Проверка фронтматтеров — третья проверка репозитория того же класса. Копии, диаграммы, фронтматтеры: всё это ошибки, невидимые при чтении. Класс опознаётся по признаку «диff выглядит разумно, а результат ломается», и каждый его представитель получает скрипт, а не пункт чек-листа.

С71. Ступеней профиля четыре, и правило выбора читается сверху вниз. Первое сработавшее условие и есть ответ: правило слияния → deep, контракт или схема → wide, видимое снаружи поведение → standard, иначе quick.