Files
dev-skills/decisions/67-goal-removed-project-stages.md
T
av 8d8c1656e5 журнал решений: тема 67 — цель упразднена, у проекта появилась стадия
Р237–Р243 и С228–С233: почему цель была зонтиком над параллельными
направлениями и почему у линейного списка работ его нет; почему «Готово»
удалена, а не перенесена; почему стадия объявляется явно и почему её
русское имя — «доработка», а не занятая «поддержка».
2026-08-13 14:26:32 +03:00

11 KiB
Raw Blame History

67. Цель упразднена, у проекта появилась стадия (2026-08-13)

Что было

Учёт работ вёлся двумя индексами. ROADMAP.md отвечал на «что приложение умеет и чего ещё не умеет» целями (тип goal), BACKLOG.md — на «что можно взять» задачами; связь шла тегом goal:<слаг>, обязательным у feature. Модель сложилась темой 19 и держалась до сих пор.

Владелец назвал наблюдение: у его проектов две стадии. Сперва активная разработка, где нужен один список от базы к деталям, чтобы построить приложение целиком; потом сопровождение и расширение, где правки точечные, а архитектура не меняется. Цель в обеих не понадобилась ни разу.

Разбор подтвердил, что это не вкус, а свойство: цель — зонтик над параллельными направлениями, она нужна там, где список работ нельзя выстроить в один порядок и очередь идёт поперёк направлений (это и записано в теме 19: «цель и приоритет — независимые оси»). У проекта на одного человека параллельных направлений не бывает, и зонтик не стоял ни над чем.

Заодно нашлось, что роадмап отвечал на свой вопрос наполовину: «чего ещё не умеет» — это «что осталось в беклоге», то есть пересказ второго индекса.

Решено

Р237. Тип goal и индекс ROADMAP.md упразднены. Индекс остался один. Вместе с целью ушли теги goal:<слаг> и decomposed, поле меты Секция, раздел Завершение, команды list --goal, edit --goal, edit --section и ключи [tasks] roadmap, [tasks] completion_heading. Тип [epic], упразднённый темой 19 в пользу цели, не вернулся: слишком крупный шаг дробится на шаги помельче, и они встают в списке подряд — соседство и есть тот ответ, ради которого заводили зонтик.

Р78 («цель — возможность приложения, задача — шаг к ней») и Р80 («цель обязательна не у всякой задачи») этим отменены, Р81 подтверждён.

Р238. Секция Готово удалена, а не перенесена. Р77 заводил её потому, что роадмап иначе показывал только «что осталось». Довод верен ровно для роадмапа: у самого факта «что приложение умеет» есть два дома и без него — нормативное поведение в openspec/specs/, а когда и в каком порядке оно появилось — git log индекса, где закрытие лежит отдельным коммитом учёта. Третий дом списком строк был бы дублем, который никто не сверяет.

Р239. Стадия проекта — новая ось: build и support. Решает она что значит порядок строк беклога: на стройке зависимость («раньше нельзя»), на доработке важность («раньше лучше»). Из этого выведено остальное — сколько у беклога секций, как его пополняют, что значит его опустошение и применим ли груминг.

Ось заведена потому, что стадии переворачивают два действующих правила скилла, а не украшают их. Правило 1 («беклог гниёт с той стороны, где его пополняют») оказалось правилом доработки: на стройке список пишется вперёд целиком, и фильтр «не заводи то, чего не делаешь сейчас» запретил бы написать план дальше первого шага. Правило 4 («приоритет назначает человек») на стройке половину порядка не назначает, а обнаруживает: зависимость видна, а не выбрана.

Р240. На стройке секция беклога ровно одна. Порядок там — зависимость, и разложенный по полкам список перестаёт быть планом: два шага из разных секций уже не сравнить. На доработке полки законны, потому что правки независимы. Проверяет check; слить секции сам он не берётся — в каком порядке пойдут строки слитых полок, знает только человек.

Р241. Стадия объявляется явно, молчание ответом не считается. init --stage обязателен, check без ключа [tasks] stage отказывает, check --fix его не подставляет. Это тот же довод, что у С145: необязательное значение, которое всё же решают, заводится парой «значение или явный отказ», иначе забытый ключ и осознанный выбор неотличимы. Здесь он сильнее обычного: без стадии нечем прочитать индекс — переставить строку значит на стройке сломать план, а на доработке принять решение о важности.

Р242. Переход стадии — команда, а не правка конфига. tasks.py stage support переносит остаток беклога в первую новую секцию, правит «Категорию» в файлах и говорит, что порядок с этого момента значит другое. Датой перехода служит коммит: отдельного журнала ради одной строки не заводится. Запретить переход раньше времени скрипт не берётся — «приложение построено» решает человек, а не счётчик строк; check лишь напоминает о пустом беклоге стройки.

Р243. Русское имя стадии — «доработка», а не «поддержка». Слово «поддержка» уже запрещено домом shared/operations.md как синоним «сопровождения»: в нём слышится помощь пользователю. Третье техническое значение сделало бы его окончательно нечитаемым. Английское имя осталось support — оно в идентификаторе, а идентификатор и есть дом.

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

С228. Груминг стал операцией одной стадии. На стройке оба его вопроса отвечены заранее: «что важно» — первая строка плана, назначенная зависимостью, а «что перестало быть важным» возникает не порциями, а разом, при смене замысла, — и тогда пересматривается план целиком. Порционный разбор там вреден: он вынимает шаги из списка, порядок которого и есть его содержание.

С229. Тест декомпозиции ослаб на одной стадии и только на ней. Условие «части мерджатся независимо, порядок между ними значит план реализации» было записано для беклога-очереди. Беклог стройки весь состоит из упорядоченных зависимостью шагов, и «сперва А, потом Б» там не повод не дробить. Осталось общее условие: каждая часть мерджится сама по себе.

С230. Залежалость считается только на доработке. На стройке долгое лежание — нормальное состояние шага, до которого не дошла очередь: он стоит там, где стоит, по зависимости, и переоценивать его нечем.

С231. Стадия не влияет на метку ревью, глубину и тип задачи. Клетка в перечне осей названа пустой явно: изменение на стройке ничем не проще того же изменения на доработке. Мысль «на стройке всё small, приложения ведь ещё нет» разбивается о первый же шаг, кладущий схему хранилища.

С232. Запись типа goal машина не переводит. check --fix снимает теги и переименовывает поля, но во что превращается сама цель — в задачу или в ничто, — решает человек, и она уезжает в НЕОДНОЗНАЧНО. Это то же правило, что у типа, которого неоткуда взять.

С233. adopt получил стадию входным параметром. Список пунктов одинаково выглядит и планом стройки, и очередью правок; вывести стадию из материала нельзя. Заодно нумерованные шаги источника перестали быть кандидатами в цели и стали порядком записей: номер источника — единственное место, где чужая раскладка называет зависимость.