# Оси процесса

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

**Одну ось перечень уже терял, и терял молча.** Метка задачи — `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 | здесь, ниже |
| категория документа | тема · источник темы · процессный | `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`, «Что происходит с находками» |

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

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

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

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

**Режим прогона × 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». Ни одно из
них не было домом, все — списки по памяти. Отсюда дом здесь: у словаря восемь
скриптов-потребителей и ни одного владельца.