dev-skills/av-dev/shared/axes.md

Оси процесса

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

Одну ось перечень уже терял, и терял молча. Метка задачи — small, medium, large — правила состав ревью кода, пока состав не стал постоянным; ось снята вместе с проходом, который её считал. Строка в журнале решений есть, а здесь от неё не осталось ничего — так и должно быть: перечень описывает то, что ветвится сегодня.

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

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

Перечень

Ось	Значения	Дом
стадия проекта	build support	task-track/SKILL.md, «Две стадии»
тип записи	feature fix chore research	task-track/SKILL.md, «Тип записи»
форма постановки	запись каталога · текст	code-resolve/SKILL.md, «Вход»
сценарий	решение · обслуживание · разведка	code-resolve/SKILL.md, «Развилка»
режим прогона	по change · без change	здесь, ниже
род правки документа	отражение · новое	doc-sync/SKILL.md, «Два рода правок»
глубина темы	сверка · разбор · доказательство	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
форма постановки	проверку готовности, кто называет тип, есть ли шаг закрытия	code-resolve/SKILL.md, «Постановка текстом»
форма постановки	сценарий и глубину ревью — не влияет, и это записано явно	там же: развилка у обеих форм общая
тип записи	сценарий — предлагает, подтверждает предмет работы	task-track/SKILL.md, «Тип записи»
тип записи	глубину ревью — не влияет, и это записано явно	там же
сценарий	режим прогона: обслуживание идёт без change	code-resolve/references/maintain.md
режим прогона	состав проходов и саму возможность запуска прохода	code-review/SKILL.md, «Прогон без change»
категория документа	заводит ли документ направление проверки	canon.md, «Три категории»
severity	что с находкой делают дальше	code-review/SKILL.md, «Что происходит с находками»
род правки	спрашивают ли человека перед письмом в документ	doc-sync/SKILL.md, «Два рода правок»
глубина темы	что проход делает с домом темы и какой потолок у находок	code-review/SKILL.md, таблица тем
разметка действия	чинится находка молча или уходит человеку вопросом	code-review/SKILL.md, «Что происходит с находками»
разметка действия	возвращается ли прогон на чекпоинт — не задаёт: возврат старше развилки и решается признаком «меняются ли дельта-спеки»	code-resolve/references/solve.md, шаг 5
сценарий	какова доля отражения в синке: обслуживание двигает факты и потому спрашивает редко	code-resolve/references/maintain.md, шаг 5

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

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

Род правки × severity и × режим прогона. Не влияет ни туда, ни обратно: род правки — свойство того, что пишется в документ, и с находкой ревью он не встречается. Находка, доехавшая до конвенции, меняет род не сама по себе, а тем, что становится новой нормой, — и спрашивается тогда как всякое новое.

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

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

Режим прогона × severity. Триаж обязателен всегда, в том числе без change. Но часть оснований critical — построенный путь к отказу, замер — добывается только скиллом av-dev:code-deep-review, а в цикле задачи не добывается ни на одном прогоне. Значит ли это, что critical там не бывает вовсе, или что его основания другие, не сказано.

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

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

• По change — обычный прогон цикла задачи: есть дифф и дельта-спеки, состав постоянный и живёт в конвейере.
• Без change — дельта-спек нет по построению, и вместе с ними нет темы requirements. План фиксирован и назван вызывающим; так идёт сценарий обслуживания.

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

Третьего режима у конвейера нет. Скилл av-dev:code-deep-review конвейер не зовёт вовсе: состав, глубина и вход у него свои, а общее с конвейером — уставы проходов и контракт находок.

Коды выхода

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

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

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

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