@rt-tools/agent-kit 0.9.1 → 0.10.0

package/assets/rules/git-workflow.github.md

@@ -72,6 +72,22 @@ flowchart TD
   вершина главной ветки не стала предком текущей, и называет расхождение числом коммитов. PR с
   разошедшейся ветки показывает ревьюверу свою правку вперемешку с чужой, а всё, что автор
   проверил до публикации, он проверил от основания, которого в главной ветке уже нет.
+- **Несошедшиеся условия поставки называются одним отказом, а не по одному.** Гард копит их все
+  и печатает разом. Отбитый по первому промаху исполнитель правит основание, повторяет вызов,
+  упирается в заголовок, правит заголовок, упирается в задачу — и каждый круг стоит ещё одного
+  вызова, хотя всё несошедшееся было известно уже на первом.
+- **Условие, известное в начале работы, спрашивается в начале.** Заведение ветки отбивает
+  основание, в котором нет вершины главной ветки, и рабочую копию, подписывающую коммиты не той
+  почтой, что объявило дерево. На пуше и на открытии PR те же проверки остаются вторым рубежом,
+  но там они стоят дороже: основание чинится вливанием с разбором конфликта, подпись —
+  переписыванием всей ветки.
+- **Судится то основание, которое названо командой, а не вершина рабочей копии.** Ветку заводят
+  и от `origin/main` прямо — этой командой основание как раз и берут свежим, — и гард, читающий
+  только текущую вершину, отбивал бы её наравне с веткой от вчерашнего дерева. Основание, о
+  котором дерево ничего не знает, не судится вовсе.
+- **Ветка без номера задачи условий поставки не получает.** Локальная ветка под пробу законна, и
+  требовать от неё свежего основания значило бы отбивать работу, которая в главную не поедет:
+  PR с такой ветки не откроется.
 - **Ключ задач задаётся один раз, и все три формы имени выводятся из него.** Заголовок задачи,
   имя ветки и заголовок PR строит один и тот же ключ: команда заведения задачи собирает по
   нему заголовок, гард поставки достаёт по нему номер из имени ветки, сверка очереди — из
@@ -89,13 +105,18 @@ flowchart TD
   ответ читается присутствием задачи на борде, её колонкой и исполнителем.
 - **Номер ветки и номер в заголовке PR сверяются на месте, а состояние задачи — по борде.**
   Формат читается из текста команды и работает без сети; существование задачи, её присутствие
-  на борде, исполнитель и то, что она ещё открыта, — только когда есть чем спросить. Нет сети
-  или нет токена — второй ярус молча пропускается: проверка, падающая в самолёте, перестаёт
-  что-либо значить.
+  на борде, её колонка, исполнитель, то, что она ещё открыта, и разбор у PR — только когда есть
+  чем спросить. Нет сети или нет токена — второй ярус молча пропускается: проверка, падающая в
+  самолёте, перестаёт что-либо значить.
 - **Колонка задачи двигается тем же движением, что и работа.** Ветка заведена — задача
   переставляется во взятые в работу, PR открыт — в ждущие разбора; делает это команда
   перевода, а не набор вызовов GraphQL по памяти. Перевод идёт сразу за шагом, который его
   вызвал: очередь работ читают между шагами, а не после них.
+- **Задача, оставшаяся в первой колонке, PR не открывает.** Гард поставки называет её колонку и
+  команду перевода: по очереди работ такая задача читается как невзятая, хотя работа по ней
+  сделана и выложена. На заведении ветки колонка не спрашивается — там её ещё не двигали, и
+  требование отбивало бы первую же команду работы вместе с той, которая его и снимает. Имя
+  первой колонки дерево называет само; не названо — колонка не судится вовсе.
 - **На борде стоят задачи, а не PR о них.** Борда показывает, что сделано и что осталось; PR
   отвечает на другой вопрос — как именно сделано, — и открывается из карточки задачи, где связь
   с ним заполняется сама полем «Linked pull requests». Карточка PR живёт своей жизнью: колонки
@@ -157,6 +178,13 @@ flowchart TD
   заблокирована самим хостингом: зелёная страница PR владельцу ничего не разрешает, а список, в
   котором всё серое, читается как «работа не сделана». Гард снятия черновика сюда не достаёт —
   он судит один ход и молчит, пока ветка везёт папку своей задачи.
+- **Конфликтующий открытый PR — расхождение сверки очереди работ.** Конфликт приезжает в
+  отданный PR чужим слиянием, без единого действия автора: основание, проверенное на открытии,
+  устаревает в ту минуту, когда владелец влил соседнюю работу. Гард снятия черновика сюда не
+  достаёт — он судит один ход, а PR стоит в очереди днями, и по списку конфликт не виден вовсе:
+  метку хостинг показывает только внутри самого PR. Непосчитанная сливаемость расхождением не
+  считается: хостинг считает её заново после каждой правки главной ветки, и строка на
+  «ещё не посчитано» краснела бы на каждой свежей вершине.
 - **Расхождение прода с главной веткой видно сверкой очереди работ.** Задача уходит из очереди
   мержем, но мерж — ещё не прод: отказавшая выкатка не трогает ни задачу, ни её колонку, и
   заметить её неоткуда. Сверка спрашивает последний прогон главной ветки и судит только
@@ -206,12 +234,44 @@ flowchart TD
 - **Черновик снимается отдельным вызовом — `gh pr ready <номер>`.** Им исполнитель отвечает за
   готовность: проверки пройдены, доработок не осталось, работа сходится с задачей. Снятие
   черновика и просьба влить — один ход, а не два разных дня.
+- **Черновик не снимается с ветки, которая не сливается.** Зелёный прогон говорит «не
+  сломано», сливаемость — «кнопку можно нажать», и владельцу нужно второе: снятый черновик он
+  читает как приглашение влить и идёт нажимать. Спрашивается это у хостинга тем же вызовом, что
+  автор и ревьювер, — `mergeable` приходит в том же ответе; выводить сливаемость из того, что
+  вливание прошло локально, нельзя: между локальным вливанием и взглядом владельца главная
+  ветка успевает уйти вперёд. За один заход так было снято три черновика подряд, и все три
+  заявки владелец увидел конфликтующими. Держится это гардом поставки, а не памятью: статья
+  стояла здесь и до того, и промах повторился в тот же день. Дерево, чей помощник очереди работ
+  о сливаемости не говорит вовсе, работает как прежде — поля нет, требования нет.
+- **Указателю, в который ветки только дописывают строки, объявляется сложение обеих сторон.**
+  Конфликт там не спор: обе допись нужны целиком, а зовёт он человека при каждом слиянии в
+  главную ветку — за один заход одна и та же строка разрешалась шесть раз в шести ветках.
+  Объявление снимает ручное разрешение: слияние проходит само. **Метку сливаемости на странице
+  заявки оно при этом не снимает** — хостинг считает её своим приёмом и настройки слияния не
+  читает. Гаснет метка только после того, как ветка вобрала главную и это уехало на хостинг.
+  Обещать по этому объявлению «конфликтов больше не будет» нельзя: не будет ручной работы, а
+  вливать главную в открытые ветки после каждого слияния придётся по-прежнему.
+- **Разрешённый конфликт, оставшийся незапушенным, хуже неразрешённого.** Владелец видит
+  прежнее состояние и читает его как «не сделано ничего», а сделанное лежит в рабочем дереве
+  исполнителя, где его не видит никто. Ветка, в которой разрешён конфликт, пушится тем же
+  ходом — либо конфликт не разрешается вовсе.
+- **Одно и то же вливание главной ветки, сделанное третий раз за заход, останавливает
+  работу.** Ветки, дописывающие строку в один и тот же список, роняют друг друга в конфликт при
+  каждом слиянии, и вливание главной по кругу — это починка проявления. На третьем круге
+  называется причина и спрашивается владелец, а не делается четвёртый круг.
+- **Черновик не снимается, пока у PR нет разбора.** Гард поставки смотрит запрошенного ревьювера
+  и оставленный отзыв: снятый черновик читается как «можно вливать», а вливать некому. Раньше
+  этого хода спросить негде — до открытия PR ревьювера нет вовсе. Судится и вызов без номера:
+  без него клиент берёт PR текущей ветки, и требование снималось бы одним пробелом. Возврат PR
+  в черновик — `gh pr ready --undo` — требования не получает: он делает то же, чего гард и
+  добивается.
 - **Мерж PR нажимает человек, а не исполнитель работы.** Кнопка и вызов слияния равны: запрет
   на них один. Исполнитель сливает свой PR только тогда, когда человек сказал это прямо и про
   этот PR; сказанное об одном PR на следующий не переносится, а молчание разрешением не
   бывает. Работа кончается PR, с которого снят черновик, и в ответе называется его номер.
 - **Автор PR не может быть его ревьювером.** Запрос разбора на самого себя GitHub принимает и
-  молча не создаёт — разбор при этом выглядит запрошенным.
+  молча не создаёт — разбор при этом выглядит запрошенным. Поэтому в разборе считаются только
+  запрос и отзыв не от автора: гард снятия черновика читает состояние PR именно так.
 - **Метки, исполнитель и ревьювер PR ставятся вызовами `gh api`, а не `gh pr edit`.** На
   репозитории со старой бордой `gh pr edit` отвечает отказом про Projects (classic) и до
   правки не доходит вовсе.
@@ -243,10 +303,11 @@ flowchart TD
 проверки под него не заводится: работа опознаётся заголовком задачи и PR, а это сверяется
 у всех. Сверка очереди имя ветки не судит вовсе: у открытого PR его не переименовать.
 
-Взятие задачи в работу не стережёт ничто: борда ветки не видит, а гард поставки её видит, но
-борду не правит — сетевой вызов в разборе команды падал бы вместе со связью и отбивал бы
-работу вместо промаха. Держится это памятью и подсказкой, которую печатает команда заведения
-задачи. Отставшую колонку находит сверка очереди — но уже после того, как PR открыт.
+Задачу в работу гард не переводит: борду он не правит — правка борды в разборе команды падала бы
+вместе со связью и отбивала бы работу вместо промаха. Перевод держится памятью и подсказкой,
+которую печатает команда заведения задачи. Задачу, оставшуюся в первой колонке, гард называет на
+открытии PR — то есть после того, как её должны были переставить; прочие расхождения колонки
+находит сверка очереди.
 
 Свежесть самой вершины главной ветки гард спрашивает вторым ярусом — тем же приёмом, что и
 состояние задачи: есть чем спросить, спрашивает; нет сети или доступа — пропускает молча.
@@ -284,7 +345,11 @@ flowchart TD
 - **Учётная запись для пуша и автор PR выбираются отдельно.** Если пушить пришлось из-под другой
   записи, на следующий вызов это не переносится: PR открывают токеном учётной записи машинной
   работы, и от того, чьей записью он открыт, зависит, кого можно назначить ревьювером. Однажды
-  смена записи ради пуша утекла в публикацию — PR вышел от владельца.
+  смена записи ради пуша утекла в публикацию — PR вышел от владельца. Разница между читающим и
+  пишущим вызовом в самом тексте команды не видна: личность приходит окружением, поэтому у
+  вызова на запись токен называется явно, а открытая заявка проверяется ответом хостинга о её
+  авторе — напечатанная ссылка говорит, что заявка создана, и молчит о том, кем. Чинится это
+  только переоткрытием: автора у заявки не сменить.
 - **Невалидный файл конвейера виден прогоном нулевой длительности сразу после пуша.** GitHub
   заводит такой прогон и на ветке, на которую ни один триггер не подписан: в списке он стоит
   отказом, а внутри у него нет ни задания, ни лога — читается только длительность. Поэтому

package/assets/rules/git-workflow.gitlab.md

@@ -71,6 +71,22 @@ flowchart TD
   вершина главной ветки не стала предком текущей, и называет расхождение числом коммитов. MR с
   разошедшейся ветки показывает ревьюверу свою правку вперемешку с чужой, а всё, что автор
   проверил до публикации, он проверил от основания, которого в главной ветке уже нет.
+- **Несошедшиеся условия поставки называются одним отказом, а не по одному.** Гард копит их все
+  и печатает разом. Отбитый по первому промаху исполнитель правит основание, повторяет вызов,
+  упирается в заголовок, правит заголовок, упирается в задачу — и каждый круг стоит ещё одного
+  вызова, хотя всё несошедшееся было известно уже на первом.
+- **Условие, известное в начале работы, спрашивается в начале.** Заведение ветки отбивает
+  основание, в котором нет вершины главной ветки, и рабочую копию, подписывающую коммиты не той
+  почтой, что объявило дерево. На пуше и на открытии MR те же проверки остаются вторым рубежом,
+  но там они стоят дороже: основание чинится вливанием с разбором конфликта, подпись —
+  переписыванием всей ветки.
+- **Судится то основание, которое названо командой, а не вершина рабочей копии.** Ветку заводят
+  и от вершины главной ветки прямо — этой командой основание как раз и берут свежим, — и гард,
+  читающий только текущую вершину, отбивал бы её наравне с веткой от вчерашнего дерева.
+  Основание, о котором дерево ничего не знает, не судится вовсе.
+- **Ветка без номера задачи условий поставки не получает.** Локальная ветка под пробу законна, и
+  требовать от неё свежего основания значило бы отбивать работу, которая в главную не поедет:
+  MR с такой ветки не откроется.
 - **Правка кода отдаётся человеку открытым MR, а не запушенной веткой.** Ветка в списке ветвей
   ему не показывается, в дела не приходит и обсуждения не имеет: до открытия MR правки для
   человека нет. Открывается он тем же ходом, которым исполнитель говорит, что работу отдаёт, и
@@ -83,6 +99,12 @@ flowchart TD
 - **Черновик снимается отдельным вызовом — `glab mr update <номер> --ready`.** Им исполнитель
   отвечает за готовность: проверки пройдены, доработок не осталось, работа сходится с задачей.
   Снятие черновика и просьба влить — один ход, а не два разных дня.
+- **Черновик не снимается, пока у MR нет разбора.** Гард поставки смотрит запрошенного ревьювера
+  и оставленный отзыв: снятый черновик читается как «можно вливать», а вливать некому. Раньше
+  этого хода спросить негде — до открытия MR ревьювера нет вовсе. В разборе считаются только
+  запрос и отзыв не от автора: разбор на самого себя разбором не бывает. Судится и вызов без
+  номера — без него клиент берёт MR текущей ветки, и требование снималось бы одним пробелом;
+  возврат MR в черновик требования не получает.
 - **Заведённая задача подтверждается ответом очереди работ, а не выводом команды заведения.**
   Команда отвечает за свои вызовы: она может завести задачу и не довести её до доски, и её
   собственный разбор ошибок этот случай называет. Напечатанный номер значит «вызов прошёл», а не
@@ -90,13 +112,18 @@ flowchart TD
   ответ читается присутствием задачи на доске, её списком и исполнителем.
 - **Номер ветки и номер в заголовке MR сверяются на месте, а состояние задачи — по доске.**
   Формат читается из текста команды и работает без сети; существование задачи, её метка
-  списка, исполнитель и то, что она ещё открыта, — только когда есть чем спросить. Нет сети
-  или нет токена — второй ярус молча пропускается: проверка, падающая в самолёте, перестаёт
-  что-либо значить.
+  списка, исполнитель, то, что она ещё открыта, и разбор у MR — только когда есть чем спросить.
+  Нет сети или нет токена — второй ярус молча пропускается: проверка, падающая в самолёте,
+  перестаёт что-либо значить.
 - **Список задачи двигается тем же движением, что и работа.** Ветка заведена — задача
   переставляется во взятые в работу, MR открыт — в ждущие разбора; делает это команда
   перевода, а не набор вызовов по памяти. Перевод идёт сразу за шагом, который его вызвал:
   очередь работ читают между шагами, а не после них.
+- **Задача, оставшаяся в первом списке, MR не открывает.** Гард поставки называет её список и
+  команду перевода: по очереди работ такая задача читается как невзятая, хотя работа по ней
+  сделана и выложена. На заведении ветки список не спрашивается — там его ещё не двигали, и
+  требование отбивало бы первую же команду работы вместе с той, которая его и снимает. Имя
+  первого списка дерево называет само; не названо — список не судится вовсе.
 - **На доске стоят задачи, а не MR о них.** Доска показывает, что сделано и что осталось; MR
   отвечает на другой вопрос — как именно сделано, — и открывается из задачи, где связь с ним
   стоит сама. Карточка MR живёт своей жизнью: метки списка у неё нет, из очереди она не уходит и
@@ -207,16 +234,17 @@ flowchart TD
 проверки под него не заводится: работа опознаётся заголовком задачи и PR, а это сверяется
 у всех. Сверка очереди имя ветки не судит вовсе: у открытого MR его не переименовать.
 
-Взятие задачи в работу не стережёт ничто: доска ветки не видит, а гард поставки её видит, но
-доску не правит — сетевой вызов в разборе команды падал бы вместе со связью и отбивал бы
-работу вместо промаха. Держится это памятью и подсказкой, которую печатает команда заведения
-задачи. Отставший список находит сверка очереди — но уже после того, как MR открыт.
+Задачу в работу гард не переводит: доску он не правит — правка доски в разборе команды падала бы
+вместе со связью и отбивала бы работу вместо промаха. Перевод держится памятью и подсказкой,
+которую печатает команда заведения задачи. Задачу, оставшуюся в первом списке, гард называет на
+открытии MR — то есть после того, как её должны были переставить; прочие расхождения списка
+находит сверка очереди.
 
-Свежесть самой вершины главной ветки гард не проверяет: он судит по тому, что лежит в дереве, и
-вершину недельной давности от сегодняшней не отличает. Сетевой вызов сюда не заводится по той же
-причине, что и выше, — он падал бы вместе со связью. Поэтому гард ловит ветку, отставшую
-заведомо, а `git fetch` перед вливанием стоит первым пунктом чеклиста и держится тем же, чем
-держатся остальные его пункты.
+Свежесть самой вершины главной ветки гард спрашивает вторым ярусом — тем же приёмом, что и
+состояние задачи: есть чем спросить, спрашивает; нет сети или доступа — пропускает молча. Первый
+ярус при этом остаётся, и работает он без сети: локальная ссылка отвечает на вопрос «отстало ли
+основание от того, что уже лежит в дереве», удалённая — на вопрос «не протухла ли сама ссылка».
+Без второго яруса молчание гарда значило лишь первое, а читалось как второе.
 
 ## Паттерны
 

package/assets/rules/task-flow.md

@@ -11,7 +11,7 @@ description: Правило под «Закон о ведении работы»
 про ход работы; здесь — чем это названо в этом дереве, где лежит и что из закона у нас не
 проверяется.
 
-**Требует:** `hooks/task-flow-guard.sh`, `hooks/task-context-load.sh`, `hooks/grill-gate.sh`, `hooks/window-fill-guard.sh`
+**Требует:** `hooks/task-flow-guard.sh`, `hooks/task-context-load.sh`, `hooks/grill-gate.sh`, `hooks/window-fill-guard.sh`, `hooks/turn-exit-guard.sh`
 
 ## Как это называется здесь
 
@@ -34,50 +34,65 @@ description: Правило под «Закон о ведении работы»
 переносится между репозиториями, раскладка — нет, и путь, названный в правиле, врёт в первом
 же дереве, которое держит код иначе.
 
-## Шаги работы
-
-Счёт сплошной: номер шага один на весь путь и не начинается заново в каждом паттерне. Шаг
-называют номером вслух, и два разных первых шага мешают разговору; а пропущенный шаг виден
-только по списку, из которого он выпал.
-
-| Шаг | Что происходит                                           | Ведёт паттерн       |
-| --- | -------------------------------------------------------- | ------------------- |
-| 1   | Разведка по дереву — до первого вопроса владельцу        | `task-flow-start`   |
-| 2   | Разбор просьбы с владельцем, шесть обязательных вопросов | `task-flow-start`   |
-| 3   | Конвейер ролей после разбора                             | `task-flow-start`   |
-| 4   | Серия задач объявляется эпиком — карточкой и замыслом    | `task-flow-start`   |
-| 5   | Задача, ветка, папка задачи                              | `task-flow-start`   |
-| 6   | Шапка замысла и сам замысел                              | `task-flow-start`   |
-| 7   | Возвращение к работе новым заходом                       | `task-flow-resume`  |
-| 8   | Этап замысла делается и отмечается в ходе работы         | `task-flow-resume`  |
-| 9   | Заход закрывается передачей                              | `task-flow-handoff` |
-| 10  | Работа отдаётся на разбор: PR открыт, ожидание названо   | `task-flow-close`   |
-| 11  | Следующая задача эпика берётся тем же движением          | `task-flow-resume`  |
-| 12  | Договорённость вливается в спек домена                   | `task-flow-close`   |
-| 13  | Тексты домена приводятся к сделанному                    | `task-flow-close`   |
-| 14  | Папка задачи разбирается                                 | `task-flow-close`   |
-| 15  | Сверка очереди работ                                     | `task-flow-close`   |
-| 16  | Работа разбирается правилами — фоном, следом за PR       | `task-flow-close`   |
-| 17  | Находки разбора принимаются одним ходом и ждут владельца | `task-flow-close`   |
-
-Шаги 7–9 повторяются, пока этапы замысла не кончатся: первый заход входит в работу шагом 1 и
-доходит до 8, дальше каждый следующий начинается шагом 7. Шаг 4 идёт только у работы, из которой
-видно серию задач. Шаги 10–17 идут один раз, когда работа кончена.
-
-Порядок в таблице — тот, в каком шаги случаются, а не тот, в каком о них удобно рассказывать.
-Следующая задача берётся раньше уборки за предыдущей: работа, отданная на разбор, ждёт владельца,
-и заход этим ожиданием не занимают. Список, в котором уборка стоит раньше, читается как
-разрешение сидеть над зелёным PR до ответа.
-
-Три шага идут не в очередь, а рядом с работой: прогон конвейера, разбор владельцем и разбор
-закрытой работы правилами. Ни один из них не спрашивает исполнителя, пока идёт, и ни один не
-ускоряется от того, что его ждут, — поэтому шаг 11 случается раньше, чем кончатся 10 и 16, а
-шаг 17 вклинивается в работу следующей задачи ровно на один ход. Порядок номеров говорит, что
-за чем следует, а не что чего дожидается.
-
-Список показывается владельцу в начале работы, и на нём же отмечается, где стоим: иначе после
+## Состояния работы
+
+Единица работы — состояние, а не шаг. У состояния есть вход, обязательное действие и выход, и
+пока действие не сделано, работа стоит в том же состоянии. Список шагов этого не давал: шаг
+кончался, а что делать дальше, выводилось из соседних строк.
+
+Состояние объявляется машиночитаемой строкой в разделе «Где стоим» хода работы и
+перезаписывается вместе с ним:
+
+```markdown
+- **Состояние:** `этап-идёт`
+```
+
+| Состояние                 | Вход в него                                     | Обязательное действие                                  | Ведёт паттерн      |
+| ------------------------- | ----------------------------------------------- | ------------------------------------------------------ | ------------------ |
+| `просьба-не-разобрана`    | реплика владельца о новой работе                | разведка по дереву, затем вопросы                      | `task-flow-start`  |
+| `разбор-закрыт`           | ответы владельца лежат на диске                 | договорённость о продукте либо причина её отсутствия   | `task-flow-start`  |
+| `договорённость-записана` | драфт лежит или причина названа                 | завести задачу, ветку и папку                          | `task-flow-start`  |
+| `задача-взята`            | задача в колонке работы, ветка по номеру, папка | написать замысел                                       | `task-flow-start`  |
+| `замысел-записан`         | замысел лежит и после записи не правится        | делать первый этап                                     | `task-flow-start`  |
+| `этап-идёт`               | этап начат                                      | доделать этап и отметить в ходе работы                 | `task-flow-resume` |
+| `этапы-кончились`         | все этапы отмечены                              | прогнать набор и открыть PR черновиком                 | `task-flow-close`  |
+| `работа-отдана`           | PR открыт черновиком                            | взять следующую задачу                                 | `task-flow-resume` |
+| `разбор-кончился`         | прогон зелёный, замечаний нет                   | влить договорённость, привести тексты, разобрать папку | `task-flow-close`  |
+| `папка-разобрана`         | папки в ветке нет, запись в архиве есть         | снять черновик и попросить влить                       | `task-flow-close`  |
+| `влито`                   | PR слит человеком                               | разбор работы правилами и сверка очереди               | `task-flow-close`  |
+
+Ни у одного состояния обязательное действие не звучит как «ждать»: ожидание чужого шага
+состоянием работы не является. Прогон, разбор владельцем и слияние идут без исполнителя, и от
+взгляда быстрее не становятся — поэтому в `работа-отдана` обязательное действие смотрит на
+следующую задачу, а не на открытый PR.
+
+Заполнение окна захода состоянием работы тоже не бывает: заход кончается передачей, работа
+остаётся в том состоянии, в каком стояла, а следующий заход читает строку и продолжает с неё.
+Ведёт закрытие захода паттерн `task-flow-handoff`.
+
+Перечень показывается владельцу в начале работы, и на нём же отмечается, где стоим: иначе после
 шести вопросов не видно ни того, что будет дальше, ни сколько всего впереди.
 
+## Выходы хода
+
+Ход кончается четырьмя способами, и других нет:
+
+| Выход                                              | Чем подтверждается                                              |
+| -------------------------------------------------- | --------------------------------------------------------------- |
+| вопрос владельцу, ответа на который в правилах нет | вопрос задан, и за тот же ход правила читались                  |
+| отказ гарда                                        | отказ назван владельцу, обход не искался                        |
+| заполненное окно захода                            | ход работы дописан, передача написана                           |
+| работа отдана, и следующая начата                  | PR открыт, и по следующей задаче сделано действие, а не сказано |
+
+Всё остальное — продолжение хода, а не его конец. Веха ходом не кончается: ни коммит, ни
+прочитанная договорённость, ни граница «прочитал — сейчас правлю», ни зелёная проверка. Слова
+«иду дальше» и «работаю дальше» владелец читает как совершающееся действие, и писать их вместо
+результата нельзя.
+
+Три способа кончить ход выглядят работой и ею не являются: сводка о чужом шаге, меню при
+назначенном порядке и объявление намерения. Что при этом должно быть верно — ниже, в статьях
+о применении закона.
+
 ## Ход
 
 Ход работы от просьбы владельца до закрытия: где стоит разбор, что требует гард и куда девается
@@ -113,8 +128,21 @@ flowchart TD
 
 ## Как закон применяется здесь
 
-- **Правка кода приложения отбивается, пока на диске нет замысла.** Гард требует папку задачи
-  по имени ветки, `plan.md` в ней и названную в его шапке договорённость о продукте.
+- **Правка кода приложения отбивается, пока работа не дошла до состояния, в котором код
+  правится.** Гард требует четыре вещи: папку задачи по имени ветки, замысел в ней, объявленное
+  в ходе работы состояние и названную в замысле договорённость о продукте.
+- **Гард судит объявленный переход, а не наличие файлов.** Артефакт на диске не говорит, дошла
+  ли работа до правки кода: пустой замысел, положенный ради снятия отказа, лежит так же, как
+  написанный. Отказ снимает объявленное состояние, и снимают его четыре — `этап-идёт`,
+  `этапы-кончились`, `работа-отдана` и `разбор-кончился`: прогон бывает красным, а разбор — с
+  замечаниями, и починка идёт в ту же ветку.
+- **Отказ по состоянию называет обязательное действие того состояния, которое объявлено.**
+  Исполнитель, которому сказано только «не в том состоянии», перепишет строку состояния вместо
+  того, чтобы сделать шаг.
+- **Именем состояния считается только слово из перечня.** Своё слово не говорит ни о входе, ни
+  о выходе, ни об обязательном действии, а перечень называет все три.
+- **Состояние судится раньше договорённости и её обхода.** Строка о неизменном поведении
+  снимает требование договорённости о продукте, а не требование дойти до правки кода.
 - **Влитая договорённость ветку не запирает.** После вливания директории «предложено» на диске
   нет, а замысел на неё ссылается до конца работы: гард отличает влитое от незаведённого по
   истории ветки и пропускает первое. Иначе последний коммит PR закрывал бы дорогу правкам
@@ -143,29 +171,50 @@ flowchart TD
   Открытый PR при этом читается как приглашение влить — поэтому незаконченная работа идёт
   черновиком, и владельцу не приходится спрашивать, кончилась ли она. Черновик снимается тем
   ходом, которым исполнитель говорит, что решение готово.
-- **Открытый PR остановкой не является.** Отданное на разбор ждёт владельца, а не исполнителя:
-  следующая задача берётся тем же движением, которым предыдущая ушла на разбор. Заход,
-  закрытый на готовой задаче, стоил владельцу целого захода на то, чтобы вернуть работу в
-  движение, — при том что порядок был назначен и лежал записанным в замысле эпика.
-- **Владельцу не предлагается выбор, чем заняться дальше, пока эпик не кончился.** Меню при
-  назначенном порядке — это просьба назначить его заново. Если работы в эпике не осталось, так
-  и говорится: эпик кончился, — а не «чем займёмся».
 - **Гард замысла — нижняя граница требования, а не его предел.** Он требует папку только под
   правку кода приложения, и работа, которая туда не доходит, проходит мимо него — но папку
   заводит всё равно: статья правила говорит «под любую работу, без исключений». Прочитанный
   как признак, гард становится разрешением работать без замысла везде, куда он не смотрит.
-- **Ход, сообщающий владельцу о чужом шаге, называет своё следующее действие и начинает его.**
-  Прогон, разбор владельцем и слияние идут без исполнителя и быстрее от взгляда не становятся,
-  поэтому сообщение о них — не работа, а сводка. Ход, кончившийся такой сводкой, владелец
-  читает как работу: она полна, в ней названы номера и состояния, и пустоты за ней не видно.
-  Открытый PR, красный прогон и ожидание слова владельца — случаи одного и того же, и правило
-  у них одно: о чужом шаге говорят вместе с начатым своим, а не вместо него. За один заход это
-  было нарушено четырежды, и готовая работа простояла в невлитом PR почти три часа, пока
-  исполнитель отвечал владельцу сводками о её состоянии.
-- **Пока PR ждёт разбора, исполнитель берёт следующую задачу.** Ожидание чужого шага заходом
-  не занимают: работа уходит на разбор, и тем же движением берётся следующая. Готовым к
-  слиянию прежний PR становится не сам — его доводит до готовности исполнитель, вернувшись к
-  нему тем же ходом, которым прочитал конец прогона.
+- **Сводка о чужом шаге.** Прогон, разбор владельцем и слияние идут без исполнителя и от взгляда
+  быстрее не становятся. Ход, кончившийся такой сводкой, владелец читает как работу: она полна,
+  в ней названы номера и состояния, и пустоты за ней не видно. О чужом шаге говорят вместе с
+  начатым своим, а не вместо него. За один заход это было нарушено четырежды, и готовая работа
+  простояла в невлитом PR почти три часа.
+- **Меню при назначенном порядке.** Выбор, предложенный владельцу, пока эпик не кончился, — это
+  просьба назначить порядок заново. Работы в эпике не осталось — так и говорится: эпик
+  кончился, — а не «чем займёмся».
+- **Объявление намерения.** «Беру следующую задачу» — не то же самое, что взять её: фраза живёт
+  до конца хода, а работа не двигается. Названо может быть только сделанное: номер заведённой
+  задачи, имя заведённой ветки, переведённая колонка.
+
+- **Прерывание работы владельцем называется вслух.** Пришло задание, останавливающее начатое, —
+  исполнитель говорит, что стоит, на чём остановлено и что будет с прежней работой, и только
+  потом берётся за новое. Молчание об этом владелец читает как «прежнее кончилось».
+- **Остановка называется отдельной репликой.** Не строкой в конце отчёта: там она тонет —
+  владелец читает отчёт как рассказ о сделанном. Называются три вещи: что стоит, чего оно ждёт
+  и что владелец может решить.
+- **Выходы хода стережёт страж, а не память исполнителя.** Он читает объявленное состояние
+  работы и то, что за ход по ней сделано: правку файла или команду, меняющую дерево. Ход, в
+  котором не было ни того ни другого, возвращается исполнителю вместе со следующим шагом из
+  хода работы. Отданную и влитую работу страж не судит: она уже дождалась чужого шага.
+- **Этап замысла объявляется закрытым только после того, как его команда проверки прошла.**
+  Строка «Чем проверяется» несёт команду обратными кавычками и то, что в её выводе означает
+  «сошлось». Страж читает прежний номер этапа из истории ветки и не выпускает ход, в котором
+  номер вырос, а команда не запускалась: через заход отмеченное по памяти неотличимо от
+  проверенного.
+- **Слово об остановке страж читает у владельца, а не у исполнителя.** Иначе остановку
+  объявляет тот, кому она в эту минуту удобна, и запрет держится ровно до первого неудобства.
+- **Утверждение о состоянии дерева стережёт гард утверждения, а не память исполнителя.** Всё,
+  что ответ владельцу говорит о дереве, несёт команду и её вывод: сказанное без команды
+  утверждением не считается — ни «проверено», ни «снято», ни «готово». Гард читает текст,
+  сказанный владельцу за ход, и ищет команду того же хода; у каждого слова назван свой род
+  команды, потому что общий признак «команда была» подтверждал бы одно другим. Прошлый ход не
+  годится: состояние дерева меняется, и вчерашний вывод о нынешнем молчит. Восемь разборов
+  подряд пришлись на этот промах, и каждый раз в правило дописывалась ещё одна статья —
+  держит его теперь машина.
+- **Слово-утверждение гард ловит, неверный вывод — нет.** Об образце, судимом по одному его
+  файлу, и о пути, которым человек не пойдёт, судить нечем: там нет ни слова, ни команды, с
+  которой сверять. Это известная граница гарда, и держат её статьи ниже, а не он.
 - **Ход о чужом шаге стережёт гард ожидания, а не память исполнителя.** Он отбивает завершение
   хода, в котором о чужом шаге сказано, а по следующей задаче не сделано ни одного действия —
   ни заведения задачи, ни ветки, ни папки, ни перевода колонки. Чужой шаг он узнаёт по двум
@@ -207,6 +256,10 @@ flowchart TD
   случился, и ловить раньше нечего. Признание ловится набором образцов, а не пониманием смысла;
   промах, признанный словами вне набора, гард пропускает, и это его известная граница, а не
   обещание.
+- **Заход, начатый с передачи, входит в работу тем же правилом, что и всякий другой.** Передача
+  лежит вне дерева, её не читает ни одна проверка, и написана она вчера: всё, что в ней стоит,
+  проверяется деревом. Порядок входа — четыре шага в паттерне возвращения; стережёт его гард, а
+  не память: порядок, записанный только словами, исполняется, пока о нём помнят.
 - **Состояние незаконченной работы приходит в контекст на запуске сессии.** Замысел и ход
   работы отдаются целиком, разбор просьбы — путём. Ветка вида `<КЛЮЧ>-*` без папки даёт
   предупреждение с готовой командой, но сессию не рвёт.
@@ -256,13 +309,6 @@ flowchart TD
   это заготовка правки чужого дерева, и часть заготовок отпадает при первом же чтении; уехавшая
   без разбора, она становится работой того, кто её не заказывал. Сводка наблюдений уезжает
   всегда: она говорит, чем пользовались и чем нет, и мнением не является.
-- **Ожидание прогона работой не занимают.** Прогон идёт на стороне и быстрее от взгляда на него
-  не становится. Пока он идёт, берётся следующая задача, а к прогону возвращаются тем ходом,
-  которым читают его конец. Это верно и для разбора владельцем: оба ожидания — не повод стоять.
-- **Остановка, если она всё-таки случилась, называется владельцу отдельной репликой.** Не
-  строкой в конце отчёта: там она тонет — владелец читает отчёт как рассказ о сделанном.
-  Называются три вещи: что стоит, чего оно ждёт и что владелец может решить — разобрать работу
-  первой или сказать, что прогона можно не ждать. Всё остальное идёт после.
 - **Договорённость вливается в спек домена последним коммитом PR.** К этому моменту код
   написан, привязки известны, и в главной ветке директория `proposed/` не появляется вовсе.
   Готовые к вливанию перечисляет `npm run check:specs`.
@@ -357,6 +403,12 @@ flowchart TD
   задаче так ушли две правки подряд: сначала подняли общее число у соседнего узла, потом
   перенесли узел в другое место разметки. Обе владелец отверг, а нужный способ назвал сам.
   Спрашивают до правки, а не показывают замер после.
+- **Путь, предложенный человеку, судится числом его шагов и тем, чем ему для этого надо
+  владеть.** Со стороны кода вариант выглядит дешёвым — «меньше путей», «строку запуска не
+  трогаем», — а человеку он стоит захода на сервер. Однажды рекомендуемым вариантом так стояла
+  выдача токена, за которой владельцу надо было идти по ssh в работающий контейнер; отбивал
+  этот вариант он сам. Цена называется со стороны того, кто пойдёт: сколько шагов и что ему для
+  них нужно. Пересказ действующего порядка без такой оценки владелец читает как одобрение.
 - **Эпик по теме читается до того, как решается раскладка.** Замысел эпика держит решения,
   которые пережили десяток задач, и разведка по коду их не находит: снятое решение следа в
   дереве не оставляет. Домен, заведённый генератором и снесённый через полчаса, стоял в замысле

package/assets/rules/testing.md

@@ -113,6 +113,20 @@ flowchart TD
   принятое остаётся навсегда, долг накоплен к заведению проверки и только сокращается, — либо
   столько ключей, сколько у записей родов. Причина обязательна: снятая проверка без причины
   через месяц неотличима от недосмотра.
+- **Запись принятого отличается от долга тем, заведена ли на неё работа.** Принятое — то, что
+  дерево делить не собирается; долг — то, на что заведена задача, и он только сокращается. Один
+  список на оба означал бы, что разбирать нечего: запись без задачи через месяц читается как
+  вечная, а запись с задачей — как недосмотр.
+- **У каждой записи стоят своя причина и номер задачи, которой она внесена.** Причина прозой на
+  весь список объясняет любую его строку и потому не объясняет ни одной, а запись без номера не
+  спросишь ни у кого: тот, кто её внёс, к этому дню не помнит ни повода, ни своего решения.
+  Запись без причины или без номера отбивает проверку — и заводится она словом владельца, а не
+  решением исполнителя, которому она в эту минуту мешает.
+- **У красного есть назначенное действие, и второй перезапуск в него не входит.** Красное бывает
+  двух родов, и в списке прогонов они выглядят одинаково: отказ хостинга на шаге подготовки
+  лечится перезапуском, дефект ветки — не лечится им вовсе. Назначенное действие одно: сперва
+  журнал этого задания, потом решение. Перезапуск, повторённый до чтения журнала, чинит не
+  причину, а её проявление, и в истории выглядит работой.
 - **Строка в список известного не заводится под красную проверку.** Список набран к дню
   заведения проверки и с тех пор только сокращается: дописанная строка гасит сигнал, а не
   причину, и в истории выглядит так же, как починка. Место, где проверка права по букве и не
@@ -187,7 +201,7 @@ flowchart TD
   чего в спеке домена нет и быть не должно: `qa-dataid` элементов, состояния разметки, ловушки
   стенда. Обещанное поведение остаётся сценарием в `scenarios.md`: если списать его во второе
   место, копии разойдутся молча — `npm run check:specs` этого не увидит.
-- `npx nx serve` проверкой не является: это шаг из правила `browser-verification`, а не тест.
+- `npx nx serve` проверкой не считается: это шаг из правила `browser-verification`, а не тест.
 - **Кадр, зависящий от загрузки машины, проверяет машину, а не вёрстку.** Ожидание отсчётом
   времени этим и кончается: на свободной машине набор зелен целиком, на занятой падает, и какой
   именно кадр не успел — дело случая. Лечится ожиданием события, а не удлинением отсчёта: шрифты

package/assets/samples/tasks/_template/plan.md

@@ -32,7 +32,10 @@
 
 - **Что делается:** <одной фразой>
 - **Признак готовности:** <что должно стать верным>
-- **Чем проверяется:** <команда или приём>
+- **Чем проверяется:** `<команда>` — <что в её выводе означает «сошлось»>
+
+Команда пишется обратными кавычками: страж выходов хода читает её и не выпускает ход, в котором
+этап объявлен закрытым, а команда не запускалась. Приём, записанный прозой, подтвердить нечем.
 
 ## Чего эта работа не делает
 

package/assets/samples/tasks/_template/progress.md

@@ -4,6 +4,7 @@
 
 Перезаписывается каждым заходом, а не дописывается.
 
+- **Состояние:** `<имя из перечня состояний правила task-flow>`
 - **Этап:** <номер> из <всего> — <название>
 - **Сделано:** <коротко>
 - **Следующий шаг:** <что делается первым в новом заходе>