av
3849f084be
Тип goal и индекс ROADMAP.md убраны: цель — зонтик над параллельными направлениями, а у проекта на одного человека список работ линеен. Роадмап при этом наполовину дублировал беклог, а «что уже умеет» отвечают спеки и git log индекса. Секция «Готово» удалена, а не перенесена. Вместо цели — ось «стадия проекта»: build (беклог это план стройки, порядок строк значит зависимость, секция одна) и support (очередь правок, порядок значит важность, секции — полки домена). Стадия объявляется ключом [tasks] stage, меняется командой stage, без неё check отказывает: порядок строк нечем прочитать. Ушли теги goal:/decomposed, поле «Секция», раздел «Завершение», флаги --goal и edit --section. Версия раскладки 2 → 3, перевод проекта расписан записью журнала.
118 lines
9.5 KiB
Markdown
118 lines
9.5 KiB
Markdown
# Оси процесса
|
||
|
||
**Это дом перечня, а не значений.** Что означает каждое значение и как оно
|
||
работает, знает владелец оси — здесь только сама ось, её дом и **чего она не
|
||
решает**. Второй пересказ механики разошёлся бы с первым; перечень же нужен
|
||
целиком и в одном месте, потому что вопрос «а не задаёт ли это метку» задают из
|
||
скилла, который метку не ведёт.
|
||
|
||
**Ось — это закрытый перечень значений, по которому что-то ветвится.** Признак
|
||
проверяемый, и он отсекает похожее: темы ревью и документы проекта — списки
|
||
**открытые**, их пополняет проект, и перечень в плагине протух бы на первом же
|
||
своём документе. Модель прохода — не ось, а цена прогона; её дом — «Модель по
|
||
проходу» в `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`, «Тип записи» |
|
||
| тип записи | метку и глубину — **не влияет, и это записано явно** | там же |
|
||
| сценарий | режим прогона: обслуживание идёт без метки | `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». Ни одно из
|
||
них не было домом, все — списки по памяти. Отсюда дом здесь: у словаря восемь
|
||
скриптов-потребителей и ни одного владельца.
|