Files

T

задачи: починена смена стадии, разобраны находки ревью плагина

Команда stage была дефектна по шести пунктам, и все шесть подтверждены
прогоном: не звала raw_last (переход оставлял каталог красным), не
переписывала шапку беклога (индекс продолжал объявлять прежнюю стадию),
шла в обход write_config, молча пропускала файлы с непересобираемой метой,
ломалась на беклоге без заголовков и схлопывала полки при первом
объявлении стадии.

Объявление и смена разведены: объявление беклога не трогает вовсе, смена
трогает состав секций только по явному --sections, а слить полки скрипт
не берётся ни в одном случае. Абзац шапки размечен парой «стадия», и
расхождение с конфигом стало обычным дрейфом.

Отказ по недостающей строке индекса запирал запись, пережившую упразднение
роадмапа: edit, close и reopen теперь заводят или пропускают строку сами.
Прочее: регистр stage нормализуется при чтении; --fix снимает мёртвые теги
и у неразобранных записей; move отказывает переставлять сырьё; adopt
держит место сырья; docs.py bump двигает одну запись журнала за раз;
tasks.py получил перечень упразднённых адресов, и гейт наконец видит
собственное упразднение ROADMAP.md.

Запись «Версия 3» переписана по прогону на игрушечном проекте: прежний
порядок шагов был неисполним. Закрыты дыры модели стадий (пересмотр плана
стройки стал сценарием, приёмка отвязана от груминга, from-review,
research и adopt получили развилку по стадии, перечень осей пересчитан) и
находки, старшие этой сессии: review-triage получил режим без метки, три
списка проектных копий сведены к дому с проверяемыми копиями, пять
пересказов правил стали помеченными копиями или ссылками, language.md
перестал объявлять юрисдикцию над чужим плагином.

2026-08-13 15:08:29 +03:00

11 KiB

Raw Blame History

Оси процесса

Это дом перечня, а не значений. Что означает каждое значение и как оно работает, знает владелец оси — здесь только сама ось, её дом и чего она не решает. Второй пересказ механики разошёлся бы с первым; перечень же нужен целиком и в одном месте, потому что вопрос «а не задаёт ли это метку» задают из скилла, который метку не ведёт.

Ось — это закрытый перечень значений, по которому что-то ветвится. Признак проверяемый, и он отсекает похожее: темы ревью и документы проекта — списки открытые, их пополняет проект, и перечень в плагине протух бы на первом же своём документе. Модель прохода — не ось, а цена прогона; её дом — «Модель по проходу» в code-review, механизация — frontmatter.py.

Перечень

Ось	Значения	Дом
стадия проекта	`build` `support`	`task-track/SKILL.md`, «Две стадии»
тип записи	`feature` `fix` `chore` `research`	`task-track/SKILL.md`, «Тип записи»
сценарий	решение · обслуживание · разведка	`code-resolve/SKILL.md`, «Развилка»
метка	`small` `medium` `large`	`code-review/SKILL.md`, «Метки»
режим прогона	с меткой · без метки	здесь, ниже
стадия ревью	дизайн · код	`code-review/SKILL.md`, «Ревью дизайна»
категория документа	тема · источник темы · процессный	`canon/references/canon.md`
severity находки	`critical` `major` `minor` `nit`	`code-review/references/finding-contract.md`
коды выхода	0 1 2 3 4	здесь, ниже

Две оси стоят домом здесь, и обе по одной причине: владельца у них нет. Коды выхода делят восемь скриптов и три скилла, режим прогона — конвейер, сценарий обслуживания и два устава.

Что на что влияет

Клетка называет место, где связка описана; сама связка живёт там.

Влияет	На что	Где описано
стадия проекта	что значит порядок строк беклога: зависимость или важность	`task-track/SKILL.md`, «Две стадии»
стадия проекта	сколько у беклога секций, как его пополняют, применим ли груминг	там же и `task-groom/SKILL.md`, «Груминг — операция доработки»
стадия проекта	метку и глубину — не влияет, и это записано явно	`task-track/SKILL.md`, «Тип записи»
стадия проекта	тип записи — не влияет, и это записано явно	`task-track/SKILL.md`, «Две стадии»
стадия проекта	как серьёзность находки ложится в список	`task-track/references/from-review.md`
стадия проекта	где сценарии кладут свой исход и чем закрывают переходное состояние	`code-resolve/references/research.md`, `task-track/references/adopt.md`
тип записи	сценарий — предлагает, подтверждает предмет работы	`task-track/SKILL.md`, «Тип записи»
тип записи	метку и глубину — не влияет, и это записано явно	там же
сценарий	режим прогона: обслуживание идёт без метки	`code-resolve/references/maintain.md`
метка	состав проходов обеих стадий	`code-review/SKILL.md`, «Метки»
метка	глубину темы: против чего смотрят и как	там же
режим прогона	состав проходов и саму возможность запуска прохода	`code-review/SKILL.md`, «Прогон без change»
категория документа	заводит ли документ направление проверки	`canon.md`, «Три категории»
severity	что с находкой делают дальше	`code-review/SKILL.md`, «Что происходит с находками»

Пять клеток пусты, и это сказано намеренно, а не забыто.

Категория документа × режим прогона. На прогоне с меткой своя тема проекта закрыта при любом значении: review-basics — приёмник проектных тем и при small, и при large, и при medium. На прогоне без метки план фиксирован сценарием — autotests, operations, conventions, — и своих тем проекта в нём нет. Значит, документ, заведённый проектом как тема, на обслуживании не смотрит никто, и строкой это нигде не называется.

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

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

Стадия проекта × категория документа и × коды выхода. Не влияет: категория — свойство документа, коды — общий словарь скриптов. Названо потому, что перечень объявлен полным, и клетка без ответа читается как забытая.

Режим прогона × severity. Триаж обязателен всегда, в том числе без метки. Но часть оснований critical — построенный путь к отказу, замер — добывается проходами, которые без метки не запускаются. Значит ли это, что critical на прогоне обслуживания не бывает, или что его основания там другие, не сказано.

Режим прогона

Прогон ревью идёт в одном из двух режимов, и режим — не глубина.

С меткой — обычный прогон по change: разметку сделал review-scope, состав обеих стадий выведен из метки.
Без метки — прогон сценария обслуживания: change нет, размечать нечего, план фиксирован и назван сценарием. Разметчик не запускается вовсе.

Без метки — не то же самое, что small. small — это суждение о размере и сложности, снятое с изменения; отсутствие метки — утверждение, что снимать её не с чего. Проход, подставивший себе small там, где метки нет, вывел бы глубину из ничего.

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

Коды выхода

Коды выхода — общий словарь всех скриптов av-dev. Ветвись на коде, а не на тексте вывода.

Код	Что случилось
0	сошлось
1	дрейф: рабочая ситуация, чинится
2	ошибка употребления: аргументы или нарушенное правило
3	окружение: не тот каталог, битый конфиг, нет инструмента
4	внутренний сбой — дефект скрипта, доложить

Различать 1 и 3 обязательно. «Дрейф» — рабочая ситуация, и чинится она правкой предмета; «окружение» — нерабочая, и повтор той же командой не поможет. Одинаковая реакция на них неверна в обоих случаях.

Словарь был объявлен «общим» в одиннадцати местах, и каждое объявление перечисляло свой набор соседей: «тот же, что у tasks.py», «тот же, что у tasks.py, docs.py и copies.py», «общий словарь скриптов av-dev». Ни одно из них не было домом, все — списки по памяти. Отсюда дом здесь: у словаря восемь скриптов-потребителей и ни одного владельца.

11 KiB Raw Blame History Unescape Escape