av
dd7aa22d02
«Пять ревью», «три capability», «десять проходов» читаются как сведение, а живут до ближайшего пополнения корпуса. Расхождение молчаливое вдвойне: фраза остаётся грамматически исправной, диффом не ловится — правят не её, а корпус, — и проверяется только пересчётом, которого никто не делает. Сослаться можно двумя способами, и оба не стареют: на конкретную запись именем, слагом или датой либо на корпус целиком. Величину называет сам каталог в момент чтения, а абзац её только запоминает. Две границы названы явно, иначе правило запретило бы форму, на которой держится половина процессных текстов. Число-заголовок к перечню, приведённому тут же, не задето: правят его в той же строке, что и список. Замер с провенансом не задет тоже — он про прошлое и не пополняется. Разделяет вопрос «изменится ли число само, без правки текста». Судит вычитка, пофразно: правило уехало помеченной копией в уставы doc-wording и task-wording, у обоих названы частое место находки и запрет пересчитывать корпус — находка в самом числе, а не в его неверности. Описания агентов дополнены, чтобы не отстать от механики. В карте домов канона стоит ссылка: счёт корпуса выглядит не копией, а собственным наблюдением документа. Собственная проза приведена к правилу: девять правил языка (их стало десять этим же коммитом), десять агентов-проходов и девять скиллов в README, восемь скриптов в перечне осей, шесть тем ядра в сценарии решения и в конвейере ревью, семь проходов в правилах нарезки.
135 lines
12 KiB
Markdown
135 lines
12 KiB
Markdown
# Оси процесса
|
||
|
||
**Это дом перечня, а не значений.** Что означает каждое значение и как оно
|
||
работает, знает владелец оси — здесь только сама ось, её дом и **чего она не
|
||
решает**. Второй пересказ механики разошёлся бы с первым; перечень же нужен
|
||
целиком и в одном месте, потому что вопрос «а не задаёт ли это метку» задают из
|
||
скилла, который метку не ведёт.
|
||
|
||
**Ось — это закрытый перечень значений, по которому что-то ветвится.** Признак
|
||
проверяемый, и он отсекает похожее: темы ревью и документы проекта — списки
|
||
**открытые**, их пополняет проект, и перечень в плагине протух бы на первом же
|
||
своём документе. Модель прохода — не ось, а цена прогона; её дом — «Модель по
|
||
проходу» в `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`, «Развилка» |
|
||
| метка | `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` |
|
||
| форма постановки | проверку готовности, кто называет тип, есть ли шаг закрытия | `code-resolve/SKILL.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». Ни одно из
|
||
них не было домом, все — списки по памяти. Отсюда дом здесь: у словаря восемь
|
||
скриптов-потребителей и ни одного владельца.
|