@rt-tools/agent-kit 0.9.1 → 0.11.0

package/assets/rules/cargo-triage.md

@@ -0,0 +1,126 @@
+---
+name: cargo-triage
+kind: rule
+law: work-conduct
+description: Правило под «Закон о ведении работы». Брать, когда разбирается груз, приехавший в приём, — разборы происшествий и предложения от деревьев. Называет, чем груз читается, что значит взять отчёт в работу и когда у записи появляются отметки о починке и о выпуске. Готовые вызовы — в паттерне cargo-triage-mark.
+---
+
+# Разбор приехавшего груза — как это устроено здесь
+
+Правило под закон `docs/constitution/work-conduct.md`. Закон говорит, что работа ведётся так,
+чтобы её состояние переживало заход; здесь — как это держится для чужой работы, приехавшей
+грузом. Своя работа идёт правилом `task-flow` под тем же законом, и одно продолжает другое:
+взятие отчёта в работу заводит задачу, а с задачи начинается тот ход.
+
+## Как это называется здесь
+
+| В законе                               | Здесь                                                                       |
+| -------------------------------------- | --------------------------------------------------------------------------- |
+| работа, о которой сказал кто-то другой | груз: разбор происшествия и предложение, приехавшие в приём от дерева       |
+| состояние работы, пережившее заход     | состояние записи груза: новое, в работе, готово, выпущено                   |
+| отметка о сделанном                    | вызов команды отметки — она переводит записи и пишет приём починки и версию |
+| место, где состояние читают            | админка приёма: столбец состояния, отбор по нему и панель записи            |
+| ответ на «чем исправлено»              | приём починки: статья правила, гард, проверка, правка кода                  |
+| ответ на «где искать фикс»             | версия выпуска: строка, которой дерево назвало выпуск                       |
+
+## Где это лежит
+
+В этом дереве — таблица в `implementation.md` рядом: адрес приёма, чем зовётся команда отметки
+и как называются состояния в её доводах. Пути живут там, а не здесь: правило переносится между
+репозиториями, а адрес приёма и имя команды у каждого дерева свои.
+
+## Ход
+
+Ход одной записи груза от приезда до выпуска: где ставится каждая отметка и что делается
+раньше неё.
+
+```mermaid
+flowchart TD
+    A[Запись груза приехала в приём] --> B[Список сужается отбором по «новое» и идёт порядком приезда]
+    B --> C{Работа по записи будет}
+    C -->|Нет| D[Состояние не двигается: состояния отказа набором не заведено]
+    C -->|Да| E[Заводится задача, и тем же ходом запись переводится в «в работе»]
+    E --> F[Работа идёт обычным ходом: ветка, папка задачи, замысел]
+    F --> G{Правка влита в главную ветку}
+    G -->|Нет| F
+    G -->|Да| H[Запись переводится в «готово», и с переходом едет приём починки]
+    H --> I{Редакция с починкой опубликована}
+    I -->|Нет| I
+    I -->|Да| J[Публикующий переводит запись в «выпущено» и называет версию]
+```
+
+## Как закон применяется здесь
+
+- **Груз читается админкой приёма, а не очередью работ.** Сводка говорит о рабочих привычках
+  команды, и в открытой очереди работ это выложено всему свету. Записи, заведённые прежним
+  порядком, из очереди никуда не денутся, но новых там не заводят.
+- **Разбор начинается с неразобранного.** Список сужается отбором по состоянию «новое» и идёт
+  порядком приезда. Без отбора разобранное и нетронутое стоят вперемешку — то самое состояние,
+  ради ухода от которого состояния и заведены.
+- **Что уже разобрано, спрашивается у приёма, а не вспоминается.** Состояние переживает заход,
+  память исполнителя — нет: разобрав груз сегодня, завтра начинают с нуля.
+- **Взять отчёт в работу — значит завести по нему задачу.** Отметка «в работе» без задачи
+  говорит, что запись кто-то взял, и молчит о том, где эта работа идёт; задача без отметки
+  оставляет запись среди неразобранных, и следующий заход разбирает её заново.
+- **Задача и отметка идут одним ходом.** Отложенная отметка не ставится: между заведением
+  задачи и следующим шагом проходит день, и к этому дню исполнитель помнит задачу, а не запись
+  груза.
+- **Одна правка — одна задача, сколько бы записей груза её ни вызвало.** Записи, чинящиеся
+  вместе, отмечаются одной пачкой и одной задачей: делится то, что придётся откатывать порознь.
+- **«Готово» ставится, когда правка влита в главную ветку.** Не когда заявка открыта и не когда
+  прогон зелёный: до слияния правки в дереве нет, а отметка утверждает, что она есть.
+- **С переходом в «готово» едет приём починки.** Он отвечает на «чем», а не на «где»: статья
+  правила, гард, проверка, правка кода. Ссылка на задачу отвечает на «где», и приёмом починки
+  её не считают. Без текста переход отбивается построчно — список снова показал бы состояние,
+  у которого нет ответа на «чем».
+- **«Выпущено» ставится тем, кто публикует редакцию, и тем же движением, что и публикация.**
+  У него версия под рукой; отложенный до следующего захода выпуск отмечается по памяти или не
+  отмечается вовсе.
+- **Между «готово» и «выпущено» стоит редакция.** Потребитель получает фикс только после
+  раскладки у себя, и два состояния разведены ровно поэтому.
+- **Отметка ставится командой, а не рукой человека в админке.** Правка закрыта токеном дерева:
+  человек груз читает, а разбирает его тот, кто по нему работает.
+- **Записи всего разбора едут одной пачкой.** Команда принимает несколько записей за вызов, и
+  вызов на каждую стоил бы столько же, сколько сам разбор.
+- **Ответ команды читается, а не подразумевается.** Он называет, сколько записей переведено,
+  сколько уже стояло в названном состоянии и какие строки отбиты. Отбитая строка означает, что
+  запись осталась там, где была, и разбирается она причиной отбоя, а не повтором того же
+  вызова.
+- **Разбор груза и сведение предложений — два разных шага.** Сведение делит пришедшее на
+  повторившееся и разовое и решает, что становится правкой; разбор груза отмечает состояние
+  каждой записи. Сведение зовут раз в несколько дней по отрезку, разбор — всякий раз, когда
+  работу берут.
+
+## Чего из закона здесь нет
+
+Ничего из перечисленного не проверяет машина, и проверки на это не будет: разбор груза
+исполняет агент, и признака «прочитал и решил» у него нет. Гард видел бы только вызов команды,
+а вызов без разбора ничем не отличается от вызова после него.
+
+Держится правило двумя вещами, и обе видны в самом приёме. Первая — запись, у которой правка
+влита, а состояние прежнее: она называет пропущенный шаг сама, как только на список посмотрят
+отбором. Вторая — число записей в «новом»: растущее означает, что разбор не идёт вовсе.
+
+Запись, по которой работы не будет, отметить нечем: состояния отказа набор не знает. «Новое»
+оставляет её среди неразобранных навсегда, «в работе» лжёт. Это открытый вопрос договорённости,
+а не умолчание правила: разбирается такая запись каждый раз заново, пока владелец не решил.
+
+## Паттерны
+
+- `cargo-triage-mark` — готовые вызовы: сухой прогон, отметка пачкой, приём починки и версия
+  выпуска, разбор отбитой строки.
+
+## Ловушки
+
+- **Отметка, отложенная «на потом», не ставится.** Между решением и следующим ходом проходит
+  день, и запись груза к этому дню помнит только приём. Отмечают тем же ходом, которым решили.
+- **Сухой прогон отметкой не считается.** Он показывает, что уехало бы, и следа наружу не
+  оставляет: запись остаётся в прежнем состоянии, а исполнитель уходит с ощущением сделанного.
+- **«Готово» по открытой заявке — отметка о том, чего в дереве нет.** Между открытием и
+  слиянием проходит день и больше, а заявку ещё и закрывают без слияния.
+- **Приём починки, написанный пересказом разбора, отвечает не на тот вопрос.** Запись груза уже
+  несёт то, что было не так; отметка говорит, что с этим сделали, — и читают её как раз затем,
+  чтобы понять, стоит ли чинить у себя.
+- **Ответ команды с нулём переведённых читается как отказ, а не как успех.** Строка «переведено
+  0, уже стояло 3» означает, что этот разбор не двинул ничего: либо записи отмечены раньше,
+  либо ключи названы не те.

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

@@ -72,6 +72,22 @@ flowchart TD
   открытие, пока вершина главной ветки не стала предком текущей, и называет расхождение числом
   коммитов. PR с разошедшейся ветки показывает ревьюверу свою правку вперемешку с чужой, а всё,
   что автор проверил до публикации, он проверил от основания, которого в главной ветке уже нет.
+- **Несошедшиеся условия поставки называются одним отказом, а не по одному.** Гард копит их все
+  и печатает разом. Отбитый по первому промаху исполнитель правит основание, повторяет вызов,
+  упирается в заголовок, правит заголовок, упирается в рабочий элемент — и каждый круг стоит
+  ещё одного вызова, хотя всё несошедшееся было известно уже на первом.
+- **Условие, известное в начале работы, спрашивается в начале.** Заведение ветки отбивает
+  основание, в котором нет вершины главной ветки, и рабочую копию, подписывающую коммиты не той
+  почтой, что объявило дерево. На пуше и на открытии PR те же проверки остаются вторым рубежом,
+  но там они стоят дороже: основание чинится вливанием с разбором конфликта, подпись —
+  переписыванием всей ветки.
+- **Судится то основание, которое названо командой, а не вершина рабочей копии.** Ветку заводят
+  и от вершины главной ветки прямо — этой командой основание как раз и берут свежим, — и гард,
+  читающий только текущую вершину, отбивал бы её наравне с веткой от вчерашнего дерева.
+  Основание, о котором дерево ничего не знает, не судится вовсе.
+- **Ветка без номера рабочего элемента условий поставки не получает.** Локальная ветка под пробу
+  законна, и требовать от неё свежего основания значило бы отбивать работу, которая в главную
+  не поедет: PR с такой ветки не откроется.
 - **Правка кода отдаётся человеку открытым PR, а не запушенной веткой.** Ветка в списке ветвей
   ему не показывается, в его дела не приходит и обсуждения не имеет: до открытия PR правки для
   человека нет. Открывается он тем же ходом, которым исполнитель говорит, что работу отдаёт, и
@@ -100,6 +116,12 @@ flowchart TD
   элемент переводится в `Active`, PR открыт — в `Resolved`; делает это команда перевода, а не
   набор вызовов по памяти. Перевод идёт сразу за шагом, который его вызвал: очередь работ
   читают между шагами, а не после них.
+- **Рабочий элемент, оставшийся в начальном состоянии, PR не открывает.** Гард поставки называет
+  это состояние и команду перевода: по очереди работ такой элемент читается как невзятый, хотя
+  работа по нему сделана и выложена. На заведении ветки состояние не спрашивается — там его ещё
+  не двигали, и требование отбивало бы первую же команду работы вместе с той, которая его и
+  снимает. Имя начального состояния дерево называет само; не названо — состояние не судится
+  вовсе.
 - **На доске стоят рабочие элементы, а не PR о них.** Доска показывает, что сделано и что
   осталось; PR отвечает на другой вопрос — как именно сделано, — и открывается из элемента, где
   связь с ним стоит сама. Здесь эта связь ставится при создании PR, поэтому отдельная карточка
@@ -209,16 +231,21 @@ flowchart TD
 проверки под него не заводится: работа опознаётся заголовком рабочего элемента и PR, а это
 сверяется у всех. Сверка очереди имя ветки не судит вовсе: у открытого PR его не переименовать.
 
-Взятие задачи в работу не стережёт ничто: доска ветки не видит, а гард поставки её видит, но
-доску не правит — сетевой вызов в разборе команды падал бы вместе со связью и отбивал бы
-работу вместо промаха. Держится это памятью и подсказкой, которую печатает команда заведения
-задачи. Отставшее состояние находит сверка очереди — но уже после того, как PR открыт.
+Рабочий элемент в работу гард не переводит: доску он не правит — правка доски в разборе команды
+падала бы вместе со связью и отбивала бы работу вместо промаха. Перевод держится памятью и
+подсказкой, которую печатает команда заведения. Элемент, оставшийся в начальном состоянии, гард
+называет на открытии PR — то есть после того, как его должны были перевести; прочие расхождения
+состояния находит сверка очереди.
 
-Свежесть самой вершины главной ветки гард не проверяет: он судит по тому, что лежит в дереве, и
-вершину недельной давности от сегодняшней не отличает. Сетевой вызов сюда не заводится по той же
-причине, что и выше, — он падал бы вместе со связью. Поэтому гард ловит ветку, отставшую
-заведомо, а `git fetch` перед вливанием стоит первым пунктом чеклиста и держится тем же, чем
-держатся остальные его пункты.
+Ревьювера гард здесь не спрашивает: снятие черновика идёт правкой самого PR — тем же вызовом, что
+и остальные его поля, — и от прочих правок машине оно неотличимо. Держится это словарём выше, где
+разбор PR ведёт ревьювер, и памятью того, кто черновик снимает.
+
+Свежесть самой вершины главной ветки гард спрашивает вторым ярусом — тем же приёмом, что и
+состояние задачи: есть чем спросить, спрашивает; нет сети или доступа — пропускает молча. Первый
+ярус при этом остаётся, и работает он без сети: локальная ссылка отвечает на вопрос «отстало ли
+основание от того, что уже лежит в дереве», удалённая — на вопрос «не протухла ли сама ссылка».
+Без второго яруса молчание гарда значило лишь первое, а читалось как второе.
 
 ## Паттерны
 

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` перед вливанием стоит первым пунктом чеклиста и держится тем же, чем
-держатся остальные его пункты.
+Свежесть самой вершины главной ветки гард спрашивает вторым ярусом — тем же приёмом, что и
+состояние задачи: есть чем спросить, спрашивает; нет сети или доступа — пропускает молча. Первый
+ярус при этом остаётся, и работает он без сети: локальная ссылка отвечает на вопрос «отстало ли
+основание от того, что уже лежит в дереве», удалённая — на вопрос «не протухла ли сама ссылка».
+Без второго яруса молчание гарда значило лишь первое, а читалось как второе.
 
 ## Паттерны