@rt-tools/agent-kit 0.8.1 → 0.8.2

package/assets/patterns/task-flow-close.md

@@ -2,7 +2,7 @@
 name: task-flow-close
 kind: pattern
 rule: task-flow
-description: Паттерн правила task-flow. Брать при закрытии работы — вливание договорённости в спек домена последним коммитом отчёта, разбор папки задачи, переезд в архив, сверка очереди работ. Не брать для хода работы — это паттерн task-flow-resume.
+description: Паттерн правила task-flow. Брать при закрытии работы — вливание договорённости в спек домена последним коммитом PR, разбор папки задачи, переезд в архив, сверка очереди работ. Не брать для хода работы — это паттерн task-flow-resume.
 ---
 
 # Закрытие работы
@@ -12,12 +12,12 @@ description: Паттерн правила task-flow. Брать при закр
 
 ## Когда брать
 
-- Этапы замысла закрыты, проверки зелёные, отчёт готовится к публикации.
+- Этапы замысла закрыты, проверки зелёные, PR готовится к публикации.
 - `npm run check:specs` перечислил договорённость в разделе «Пора вливать».
 
 ## 9. Договорённость вливается в спек домена
 
-Последним коммитом отчёта, до слияния. Код к этому моменту написан, поэтому привязки
+Последним коммитом PR, до слияния. Код к этому моменту написан, поэтому привязки
 `файл:символ` известны — правило въезжает в спек домена сразу проверяемым.
 
 ```bash
@@ -78,17 +78,69 @@ grep -rn -A3 "Чего из закона здесь нет" <каталог пр
 ```
 
 **Закон в ветке не правится.** Статья закона — договорённость с владельцем, и меняет её он.
-Работа с ней разошлась — пишется готовый текст статьи: в ход работы и в тело отчёта. Файл
+Работа с ней разошлась — пишется готовый текст статьи: в ход работы и в тело PR. Файл
 закона правится после ответа. С законами приложения так же: деньги, локали и доступ — та же
 договорённость, только про это приложение.
 
-Что сделали на этом шаге, пишется в тело отчёта: что перечитали, что изменили, а если ничего
+Что сделали на этом шаге, пишется в тело PR: что перечитали, что изменили, а если ничего
 не изменили — почему. Форма раздела — паттерн `git-workflow-commit`.
 
 ## 11. Папка задачи разбирается
 
+**Заход, открывший PR, называет владельцу оставшийся шаг вслух:** после одобрения ветка
+получает ещё один коммит — разбор папки, — и только потом вливается. Порядок этот записан
+здесь, а читает его исполнитель; вливает же владелец, и молчание он читает как «работа
+кончена» — видит зелёный PR и мержит его тем же ходом. Промах случается ровно в шов между
+двумя ходами, и стоит он отдельной задачи: после слияния папку разбирать уже некому.
+
+### Два сообщения владельцу, и между ними — прогон
+
+Оба обязательны, и порядок между ними один. Ни одно не заменяется другим: первое говорит, что
+работа отдана и чего она ждёт, второе — что она готова.
+
+Сразу после открытия PR:
+
+```
+PR #<номер> открыт. Жду прогона: пока он идёт, о работе известно только то, что она
+запушена. Как закончится — разберу папку задачи последним коммитом и попрошу тебя влить.
+Пока жду, беру задачу #<номер следующей>.
+```
+
+Прогон зелёный, папка разобрана и запушена:
+
+```
+PR #<номер> готов к слиянию: прогон зелёный, папка задачи разобрана, за работой убрано.
+Влей его, пожалуйста.
+```
+
+Прогон красный — сообщение то же по форме, но говорит о красном и о том, что с ним делается;
+просьбы влить в нём нет. Просьба звучит один раз и только тогда, когда работа готова целиком:
+сказанная заранее, она перестаёт что-либо значить, и владелец возвращается к прежнему —
+вливать по зелёной странице.
+
+Между двумя сообщениями исполнитель не ждёт: работа отдана на разбор, и тем же движением
+берётся следующая задача. Возвращается он к PR тем ходом, которым читает конец прогона.
+
+Разбор идёт по трём исходам, а не по двум.
+
+**Первым отбирается действующее требование.** Всё, что останется верным и завтра, становится
+статьёй закона, пунктом правила или разделом паттерна — по тому, о чём оно говорит. Признак
+отбора один и записан здесь заранее: перестанет ли текст быть верным, если завтра всё
+переделать. Перестанет — это рассказ о состоявшемся; не перестанет — требование, и место ему в
+слое правил. Закон при этом в ветке не правится — его статья приносится владельцу текстом.
+
+**Вторым отбирается рассказ о состоявшемся переезде.** Он уезжает в описание прошлого и
+называет для каждого перенесённого решения, куда оно ушло: иначе решение, ставшее правилом, и
+решение, потерянное при переносе, выглядят одинаково — записью, на которую никто не ссылается.
+
+**Третьим удаляется остальное.**
+
+Порядок именно такой: начав с переезда, исполнитель увозит вместе с ним и действующее — под
+конец работы это дешевле, чем разбирать.
+
 Целиком в архив не переносится: `docs/archive/` — место для записей о состоявшемся, которые
-кто-то читает, а не свалка ходов работы.
+кто-то читает, а не свалка ходов работы. Таблица ниже говорит о том, что осталось после
+первого отбора.
 
 | Файл          | Куда                                                                                                               |
 | ------------- | ------------------------------------------------------------------------------------------------------------------ |
@@ -103,9 +155,26 @@ cat docs/tasks/<КЛЮЧ>-<номер>-<slug>/grill.md > docs/archive/<ЧТО_Р
 rm -r docs/tasks/<КЛЮЧ>-<номер>-<slug>
 ```
 
-Разбор идёт в том же отчёте, что и работа: папка, оставленная до мержа, попадает в главную
+Разбор идёт в том же PR, что и работа: папка, оставленная до мержа, попадает в главную
 ветку и читается там как текущая.
 
+### Работа, разбирающая чужую папку, разбирает две
+
+Своя папка у такой работы есть — она заводится наравне со всеми, исключения из этого нет. Обе
+снимаются последним коммитом, и порядок между ними один: сперва чужая, потом своя. Начав со
+своей, исполнитель теряет замысел на диске, а он ещё нужен — гард отбивает правку без него, а
+правка по замечаниям разбора идёт в ту же ветку.
+
+```bash
+cat docs/tasks/<чужая>/grill.md > docs/archive/<ЧТО_РЕШАЛИ_ТАМ>.md
+rm -r docs/tasks/<чужая>
+cat docs/tasks/<своя>/grill.md > docs/archive/<ЧТО_РЕШАЛИ_ЗДЕСЬ>.md
+rm -r docs/tasks/<своя>
+```
+
+Две записи в архиве, а не одна: работы разные, и решения в них разные. Сверка очереди работ
+после этого не называет ни одной папки — этим и проверяется, что разобраны обе.
+
 ## 12. Сверка
 
 ```bash
@@ -121,7 +190,7 @@ npm run check:docs    # пути, названные в текстах, суще
   отвечает — работа перешла к следующей задаче, и находка достанется чужому заходу. Три раза
   подряд папка закрытой задачи так и уехала в главную ветку, в последний раз их набралось
   пять. Теперь это держит гард поставки: слияние отбивается, пока папка лежит в ветке.
-- **Разбирают последним коммитом, а не перед открытием отчёта.** Пока идёт ревью, замысел
+- **Разбирают последним коммитом, а не перед открытием PR.** Пока идёт ревью, замысел
   нужен на диске: без него правку по замечаниям не пропустит гард хода работы. Порядок такой:
   правки по ревью, потом разбор папки, потом слияние.
 - **Разбор папки идёт последним, после того как гейт пуша прошёл целиком.** Гард хода работы
@@ -165,7 +234,7 @@ npm run check:docs    # пути, названные в текстах, суще
   в нём нет. Паттерн находится по имени правленого символа, а не по теме работы.
 - **Правило без привязки в спек домена не въезжает.** Кода, который его исполняет, нет —
   значит это намерение, и место ему в открытых вопросах домена, а не в правилах.
-- **Замысел линии работ правят только там, где вписывают «чем кончилась».** Границы линии и
+- **Замысел эпика правят только там, где вписывают «чем кончился».** Границы эпика и
   порядок задач в ней при этом остаются прежними, а работа их уже нарушила: задача, решившая
   читать спеки, оставила над собой границу «спеки — вторая очередь», и следующий исполнитель
   прочитает её как действующую. Границы линии перечитываются целиком тем же заходом, что и

package/assets/patterns/task-flow-handoff.md

@@ -26,7 +26,7 @@ description: Паттерн правила task-flow. Брать, когда з
 
 Пороги сторожит гард заполнения окна; размер окна он берёт из настройки дерева — из записи
 захода тот не выводится. Место между порогами и есть то, на что заход закрывается: дописать ход
-работы, написать передачу, закоммитить и открыть отчёт, если работа кончена.
+работы, написать передачу, закоммитить и открыть PR, если работа кончена.
 
 ## Точка остановки
 
@@ -54,7 +54,7 @@ description: Паттерн правила task-flow. Брать, когда з
 
 ### Коммит
 
-Проверенное коммитится сразу, а не копится до конца задачи. Работа кончена — открывается отчёт:
+Проверенное коммитится сразу, а не копится до конца задачи. Работа кончена — открывается PR:
 паттерн `git-workflow-commit`.
 
 ### Передача
@@ -86,12 +86,35 @@ mkdir -p <каталог передачи>
 - <прочее, чего нет ни в правилах, ни в ходе работы>.
 ```
 
+Третьим разделом идёт «Эпик» — таблица положения. Работа вне эпика этого раздела не несёт:
+таблица из одной строки повторяет раздел «Работа» и читается как эпик из одной задачи.
+
+```markdown
+### Эпик <номер> — <возможность, названная замыслом>
+
+| №   | Задача                            | Состояние |
+| --- | --------------------------------- | --------- |
+| 1   | <КЛЮЧ>-<номер> — <что делает>     | закрыта   |
+| 2   | **<КЛЮЧ>-<номер> — <что делает>** | в работе  |
+| 3   | <КЛЮЧ>-<номер> — <что делает>     | впереди   |
+```
+
+Три колонки, строка на задачу. Заголовок называет номер эпика и возможность — ту, что записана в
+замысле, а не пересказанную заново. `№` — место по порядку: фактическое у закрытых, назначенное
+замыслом у будущих. `Задача` — номер и что она делает, теми же словами, что в замысле.
+`Состояние` — «закрыта», «в работе» или «впереди»; строка текущей задачи выделяется целиком.
+
+Состав берётся из замысла эпика, а состояние — из очереди работ: замысел о том, что закрыто, не
+знает, а очередь не знает порядка. Задача, дописанная в эпик после планирования, стоит в очереди
+и в таблице, а в замысле её нет — расхождение называется вслух, а не заглаживается.
+
 Разделы фиксированы, и порядок у них тот же:
 
 1. **Работа** — номер задачи, её название, рабочее дерево полным путём, ветка и её состояние.
 2. **Где искать** — что придёт хуком само, а что читается по надобности.
-3. **Сделано и следующий шаг** — одной строкой каждое; подробности уже в ходе работы.
-4. **Что учесть** — особенности этого захода, которых нет ни в правилах, ни в ходе работы:
+3. **Эпик** — таблица положения; у работы вне эпика раздела нет.
+4. **Сделано и следующий шаг** — одной строкой каждое; подробности уже в ходе работы.
+5. **Что учесть** — особенности этого захода, которых нет ни в правилах, ни в ходе работы:
    поднятые стенды, отставшие зависимости, чужие процессы на портах, незакрытые вопросы к
    владельцу.
 

package/assets/patterns/task-flow-resume.md

@@ -59,16 +59,16 @@ git log --oneline origin/main..HEAD
 - **Следующий шаг:** сценарии обоих хуков, затем подключение в настройках
 - **Незакоммиченное:** всё, ветка пока без коммитов
 - **Ждём владельца:** нет
-- **Отчёт:** ещё не открыт
+- **PR:** ещё не открыт
 ```
 
-Строка про отчёт обязательна с той минуты, как этапы кончились: между открытием отчёта и
+Строка про PR обязательна с той минуты, как этапы кончились: между открытием PR и
 слиянием проходит день и больше, и заход обрывается там чаще всего. Без неё следующий заход
-читает «этап последний, всё зелено» и об открытом отчёте узнаёт только из истории ветки или у
+читает «этап последний, всё зелено» и об открытом PR узнаёт только из истории ветки или у
 владельца — то есть ровно тем пересказом, ради отмены которого всё и заведено:
 
 ```markdown
-- **Отчёт:** #1396, ждёт разбора · отвечено 3 замечания из 5 · не сделано: разбор папки задачи
+- **PR:** #1396, ждёт разбора · отвечено 3 замечания из 5 · не сделано: разбор папки задачи
 ```
 
 Решение, принятое по ходу, — вместе с причиной и с тем, что было альтернативой:
@@ -94,12 +94,30 @@ git log --oneline origin/main..HEAD
 - Доэтапное, не этой работы: сверка очереди перечисляет шесть закрытых задач вне борды.
 ```
 
+## 13. Следующая задача эпика берётся тем же движением
+
+Задача закрыта, PR открыт и ждёт владельца — заход на этом не кончается. Отданное на разбор
+ждёт человека, а не машину: пока эпик не кончился, следующая его задача берётся сразу, тем же
+движением, которым предыдущая ушла на разбор.
+
+Берётся, а не выбирается: порядок назначен на планировании и лежит в замысле эпика. Выбор,
+предложенный владельцу при назначенном порядке, — просьба назначить его заново.
+
+```bash
+# что назначено следующим — читается в замысле эпика, а не спрашивается
+# состояние задач — в очереди работ: замысел о закрытом не знает
+```
+
+Останавливает заход только предел заполнения окна — тогда идёт передача, паттерн
+`task-flow-handoff`. Эпик кончился — заход закрывается тем же порядком, и владельцу называется,
+что кончился именно эпик, а не одна его задача.
+
 ## Ловушки
 
 - **Заход, кончившийся ничем, тоже записывается.** Иначе следующий пойдёт той же дорогой:
   «пробовали так — не вышло, потому что» стоит одной строки и экономит целый заход.
 - **Незакоммиченное называется явно.** Работа живёт в дереве неделями; строка «что лежит
-  несохранённым и почему» — единственное, по чему это видно, пока отчёта нет.
+  несохранённым и почему» — единственное, по чему это видно, пока PR нет.
 - **Подтверждение — вывод команды или замер, а не пересказ.** «Проверил, работает» через
   заход неотличимо от «казалось, что работает».
 - **Число из передачи пересчитывается до того, как на нём что-то делят.** Передача описывает

package/assets/patterns/task-flow-start.md

@@ -73,6 +73,10 @@ Agent(subagent_type: "Explore", prompt: "<тема просьбы>: что по
 <Вопрос>
 ```
 
+Под вопросом идёт таблица положения эпика — та же, что в передаче. Под, а не над: остановка
+называется первой строкой, и положение эпика — то, из чего владелец решает, а не то, о чём его
+спрашивают. Работа вне эпика таблицы не несёт.
+
 Замеры, находки ролей и список решений к этому моменту уже записаны в ход работы, и в
 сообщении владельцу они лишние. Отчёт, в конце которого стоит вопрос, выглядит добросовестно
 ровно настолько, насколько надёжно вопрос в нём тонет: владелец трижды переспрашивал, почему
@@ -163,5 +167,5 @@ cp docs/tasks/_template/progress.md docs/tasks/<КЛЮЧ>-<номер>-<slug>/pr
 - **Slug ветки берётся из терминологии договорённости, а не из слов просьбы.** Договорённость
   пишется раньше ветки и как раз там отказывается от слова владельца: спек завёл своё имя
   предмету и прямо сказал, каким словом его не называть, — а ветка и папка задачи остались с
-  отвергнутым. Заголовок задачи и отчёта поправить можно, имя ветки после открытия отчёта —
+  отвергнутым. Заголовок задачи и PR поправить можно, имя ветки после открытия PR —
   уже нет.

package/assets/rules/browser-verification.md

@@ -30,7 +30,9 @@ description: Правило под «Закон о проверяемости».
 
 - **Второй экземпляр уже поднятого приложения не поднимается.** До первого запроса выясняется,
   кто отвечает на порту: поднятый заново экземпляр отвечает своей сборкой, а не той, которую
-  проверяют. Кто поднимает стенд — владелец или агент, — сказано в именах дерева.
+  проверяют. Кто поднимает стенд — владелец или агент, — сказано в именах дерева. Занятый порт,
+  обнаруженный поздно, означает, что стенд уже есть: запущенное поверх него останавливается по
+  идентификатору процесса, а не по имени команды — у обоих экземпляров оно одно.
 - **Браузер водится одним драйвером на закреплённом профиле.** Остальные двери — второй
   драйвер, `open`, `osascript`, запуск бинарника — закреплённый профиль не спрашивают вовсе.
 - **Выбор браузера протухает и требует повторного вызова.** Выбор, сделанный в начале
@@ -66,6 +68,13 @@ description: Правило под «Закон о проверяемости».
   отвечает 200 старым кодом, а заведённого в ветке обработчика у него нет вовсе, и 404 читается
   как дефект регистрации. Таких процессов бывает несколько; снятие по шаблону команды не
   попадает ни в один — убивать по PID из `lsof`, каждый.
+- **Шаблон имени команды не годится ни чтобы попасть, ни чтобы не задеть.** Два экземпляра
+  одного стенда — уже поднятый и только что запущенный — по тексту команды неотличимы: она у них
+  одна и та же. Снятие по шаблону уносит оба, и разобрать это потом нечем: снятым оказывается
+  ровно тот стенд, ради которого всё затевалось. Своё и чужое различает только идентификатор
+  процесса, снятый разбором порта; им и останавливают, поштучно. Обратный промах тот же по
+  природе — оболочка запускает процесс под именем, которого в шаблоне нет, и снятие не попадает
+  ни во что.
 - Инкрементальная сборка протухает поштучно: разметка бывает уже новая, а клиентский чанк — от
   компиляции до правки. Признак дев-сборки — имена бандла без хеша (`main.js`). Расхождение
   между `curl` и страницей после гидратации — повод пересобрать, а не искать дефект в коде.

package/assets/rules/doc-style.md

@@ -115,7 +115,7 @@ description: Правило под «Закон о документации пр
   паттерн `doc-style-sweep`.
 - **Словарь действует и на разговор с владельцем, не только на файлы.** Он приходит в контекст
   на запуске сессии, поэтому «не читал» основанием не бывает. Слово из левой колонки «Так не
-  пишем» всплывало именно в ответах: в дереве его уже вычистили, а в отчёте о сделанном оно
+  пишем» всплывало именно в ответах: в дереве его уже вычистили, а в PR о сделанном оно
   оставалось, и владелец читал ровно то слово, от которого отказались.
 - **Термин берётся из `docs/GLOSSARY.md`, а не придумывается на месте.** Слова, которого там
   нет, у читателя нет тоже: «журнал приложения» простоял в спеке почты, пока владелец не
@@ -131,19 +131,27 @@ description: Правило под «Закон о документации пр
 - **Снятое имя вычищается одним грепом по всему дереву:** правила, их зеркала в скилах,
   документы и комментарии. Описание того, чего в коде уже нет, читается как действующее
   указание.
+- **У снятого слова второе значение возвращается после сплошной замены, а не обходится до
+  неё.** Слово снимают ровно потому, что оно стояло над двумя вещами, и второе значение при
+  этом остаётся законным. Отобрать его заранее нечем: какое из двух значений в строке, видно
+  только по соседнему тексту, а строк бывают сотни. Порядок обратный — сплошная замена, затем
+  сплошной просмотр самой правки, и найденное второе значение возвращается поимённо. Из 353
+  замен так вернулись шесть, и две первые были поломкой: сверка печатала новое имя дважды
+  подряд, а комментарий обещал «поломку вместо PR о том, что долгов нет». Просматривается
+  правка, а не дерево после неё: в дереве обе стороны выглядят одинаково верными.
 - **Поиск по дереву не покрывает того, что уже уехало наружу.** Заголовок задачи и её тело,
-  заголовок отчёта и его тело, заголовки коммитов лежат вне файлов, и проверки текстов их не
+  заголовок PR и его тело, заголовки коммитов лежат вне файлов, и проверки текстов их не
   читают вовсе. Вычистив слово в дереве, обходят те же места в очереди работ и в истории:
 
     ```bash
-    <клиент хостинга> api "<путь к отчёту>" --jq '.title, .body' | grep -i '<слово>'
+    <клиент хостинга> api "<путь к PR>" --jq '.title, .body' | grep -i '<слово>'
     <клиент хостинга> api "<путь к задаче>" --jq '.title, .body' | grep -i '<слово>'
     git log --format='%s%n%b' <база>..HEAD | grep -i '<слово>'
     ```
 
-    Заголовок отчёта правится вызовом хостинга, заголовок коммита — только переписыванием ветки,
+    Заголовок PR правится вызовом хостинга, заголовок коммита — только переписыванием ветки,
     поэтому его проверяют до пуша. Выдуманное слово было вычищено из трёх файлов и объявлено
-    снятым, а в заголовке отчёта и в заголовке коммита осталось — владелец прочитал именно его.
+    снятым, а в заголовке PR и в заголовке коммита осталось — владелец прочитал именно его.
 
 - **Число в тексте пересчитывается командой в том же коммите, где пишется.** Оно стареет
   внутри одной ветки: «шестнадцать пар» стало неправдой через два коммита после того, как

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

@@ -21,7 +21,7 @@ description: Правило под «Закон о поставке» для д
 | задача                           | рабочий элемент (work item) рода `Task` или `Bug`, заголовок `[<номер>] <Что не так>`, исполнитель — учётная запись машинной работы; PR прикрепляется к нему при создании флагом `--work-items`, а коммит — строкой `AB#<номер>`       |
 | очередь работ                    | Azure Boards проекта. Рабочий элемент попадает на доску тем, что заведён: доска показывает элементы своей области и итерации                                                                                                           |
 | состояние задачи в очереди работ | поле `State` рабочего элемента: `New` у заведённого, `Active` у взятого в работу, `Resolved` у ждущего разбора. Набор состояний зависит от процесса проекта и назван в `implementation.md`; закрытая задача уходит из очереди слиянием |
-| отчёт о задаче                   | заголовок PR `[<номер>] <Что сделано>` — тот же номер, что у рабочего элемента, и его название, переведённое в сделанное; тип и область коммита сюда не идут                                                                           |
+| PR о задаче                      | заголовок PR `[<номер>] <Что сделано>` — тот же номер, что у рабочего элемента, и его название, переведённое в сделанное; тип и область коммита сюда не идут                                                                           |
 | обсуждение правки                | разбор PR: ревьювер — владелец репозитория, исполнитель — учётная запись машинной работы, метки — те же, что у рабочего элемента                                                                                                       |
 | попадание правки в главную ветку | слияние PR; оно же запускает выкатку — `azure-pipelines.yml`                                                                                                                                                                           |
 | образ того коммита               | `IMAGE_TAG=<sha>` в командах `docker compose` на сервере                                                                                                                                                                               |
@@ -48,6 +48,11 @@ description: Правило под «Закон о поставке» для д
   открытие, пока вершина главной ветки не стала предком текущей, и называет расхождение числом
   коммитов. PR с разошедшейся ветки показывает ревьюверу свою правку вперемешку с чужой, а всё,
   что автор проверил до публикации, он проверил от основания, которого в главной ветке уже нет.
+- **Заведённый рабочий элемент подтверждается ответом очереди работ, а не выводом команды
+  заведения.** Команда отвечает за свои вызовы: она может завести элемент и не довести его до
+  доски, и её собственный разбор ошибок этот случай называет. Напечатанный номер значит «вызов
+  прошёл», а не «работа видна тому, кто по ней придёт». Спрашивается очередь — по номеру, одним
+  вызовом, — и ответ читается присутствием элемента на доске, его состоянием и исполнителем.
 - **Номер ветки и номер в заголовке PR сверяются на месте, а состояние — по доске.** Формат
   читается из текста команды и работает без сети; существование рабочего элемента, его
   состояние, исполнитель и то, что он ещё открыт, — только когда есть чем спросить. Нет сети
@@ -58,13 +63,13 @@ description: Правило под «Закон о поставке» для д
   набор вызовов по памяти. Перевод идёт сразу за шагом, который его вызвал: очередь работ
   читают между шагами, а не после них.
 - **Отставшее состояние находится сверкой очереди, а не глазами.** Сверка судит состояние по
-  отчёту в обе стороны: открытый PR при элементе не в разборе и разбор без открытого PR — оба
+  PR в обе стороны: открытый PR при элементе не в разборе и разбор без открытого PR — оба
   расхождения. Момента, когда задачу берут в работу, ей не видно: ветки на доске нет.
 - **Задачи, чинящиеся одной правкой, сливаются до слияния ветки.** Вторая закрывается как
   дубликат, а недостающее из неё дописывается в первую. После слияния слить уже нельзя: ветка
   въехала, и откатывается она целиком.
 - **Работа, которую одним заходом не закрыть, помечена в двух местах, и они сверяются.** Метка
-  на доске и строка о заходах с передачей в линии работ говорят одно и то же двум читателям:
+  на доске и строка о заходах с передачей в замысле эпика говорят одно и то же двум читателям:
   исполнитель открывает карточку раньше, чем линию, а планирует по линии. Одна пометка без
   другой лжёт молча, поэтому сверка очереди судит пару в обе стороны. Помечается только то, что
   законно не делится: пометка объёма правом делить не становится.
@@ -88,9 +93,9 @@ description: Правило под «Закон о поставке» для д
   ветке, а задание выкатки прибито условием к главной: прогон ради проверки доходит до сборок и
   там кончается. Прогон команд задания на своей машине его не покрывает: он проверяет команды,
   а не файл конвейера, — верность самого файла читается только по списку прогонов после пуша.
-- **Отчёт проверяется до слияния тем же конвейером, что и главная ветка.** Проверки и сборки
+- **PR проверяется до слияния тем же конвейером, что и главная ветка.** Проверки и сборки
   образов идут на конвейере проверки PR, выкатка — нет: её держит условие по главной ветке у
-  своего задания, а образ отчёта в реестр не уезжает.
+  своего задания, а образ PR в реестр не уезжает.
 - **Расхождение прода с главной веткой видно сверкой очереди работ.** Рабочий элемент уходит из
   очереди слиянием, но слияние — ещё не прод: отказавшая выкатка не трогает ни элемент, ни его
   состояние, и заметить её неоткуда. Сверка спрашивает последний прогон главной ветки и судит
@@ -145,7 +150,7 @@ description: Правило под «Закон о поставке» для д
 
 Гард поставки стоит на командах агента, поэтому ветку, заведённую руками в редакторе, он не
 видит: имя такой ветки держится памятью. Требование от этого не слабеет — просто отдельной
-проверки под него не заводится: работа опознаётся заголовком рабочего элемента и отчёта, а это
+проверки под него не заводится: работа опознаётся заголовком рабочего элемента и PR, а это
 сверяется у всех. Сверка очереди имя ветки не судит вовсе: у открытого PR его не переименовать.
 
 Взятие задачи в работу не стережёт ничто: доска ветки не видит, а гард поставки её видит, но
@@ -191,7 +196,7 @@ description: Правило под «Закон о поставке» для д
 - **Учётная запись для пуша и автор PR выбираются отдельно.** Если пушить пришлось из-под другой
   записи, на следующий вызов это не переносится: PR открывают токеном учётной записи машинной
   работы, и от того, чьей записью он открыт, зависит, кого можно назначить ревьювером. Однажды
-  смена записи ради пуша утекла в публикацию — отчёт вышел от владельца.
+  смена записи ради пуша утекла в публикацию — PR вышел от владельца.
 - **Невалидный файл конвейера виден прогоном нулевой длительности сразу после пуша.** Прогон
   заводится и кончается на разборе файла, не начав ни одного задания: в списке он стоит
   отказом, а внутри нет ни задания, ни лога — читается только длительность. Поэтому список

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

@@ -22,7 +22,7 @@ description: Правило под «Закон о поставке» для д
 | задача                           | issue репозитория, заголовок `[<КЛЮЧ>-<номер>] <Что не так>`, исполнитель — учётная запись машинной работы; PR прикрепляется к нему строкой `Closes #<номер>` в теле                            |
 | очередь работ                    | борда GitHub Projects. К репозиторию она не привязана: `projectsV2` у него пуст, и задача попадает на борду только явным добавлением                                                            |
 | состояние задачи в очереди работ | колонка борды — поле «Status»: заведённая, взятая в работу, ждущая разбора. Имена колонок — в `implementation.md`; закрытая задача уходит из очереди мержем, а не переводом в последнюю колонку |
-| отчёт о задаче                   | заголовок PR `[<КЛЮЧ>-<номер>] <Что сделано>` — тот же номер, что у задачи, и её название, переведённое в сделанное; тип и область коммита сюда не идут                                         |
+| PR о задаче                      | заголовок PR `[<КЛЮЧ>-<номер>] <Что сделано>` — тот же номер, что у задачи, и её название, переведённое в сделанное; тип и область коммита сюда не идут                                         |
 | обсуждение правки                | разбор PR: ревьювер — владелец репозитория, исполнитель — учётная запись машинной работы, метки — те же, что у задачи                                                                           |
 | попадание правки в главную ветку | мерж PR; он же запускает выкатку — `.github/workflows/deploy.yml`                                                                                                                               |
 | образ того коммита               | `IMAGE_TAG=<sha>` в командах `docker compose` на сервере                                                                                                                                        |
@@ -49,7 +49,7 @@ description: Правило под «Закон о поставке» для д
   разошедшейся ветки показывает ревьюверу свою правку вперемешку с чужой, а всё, что автор
   проверил до публикации, он проверил от основания, которого в главной ветке уже нет.
 - **Ключ задач задаётся один раз, и все три формы имени выводятся из него.** Заголовок задачи,
-  имя ветки и заголовок отчёта строит один и тот же ключ: команда заведения задачи собирает по
+  имя ветки и заголовок PR строит один и тот же ключ: команда заведения задачи собирает по
   нему заголовок, гард поставки достаёт по нему номер из имени ветки, сверка очереди — из
   заголовка. Форма ветки в профиле дерева пишется той же парой `<КЛЮЧ>-<номер>`, а не своей
   похожей: разойдясь, они не отказывают, а перестают узнавать номер, и проверка, искавшая
@@ -58,6 +58,11 @@ description: Правило под «Закон о поставке» для д
   же вызове и называет, где ключ задаётся. Умолчания у ключа нет намеренно: собранный из
   пустого значения заголовок `[-317]` не совпадает ни с чем, и сверка очереди помечает
   неправильно названной каждую задачу — настоящее расхождение тонет среди этих строк.
+- **Заведённая задача подтверждается ответом очереди работ, а не выводом команды заведения.**
+  Команда отвечает за свои вызовы: она может завести задачу и не довести её до борды, и её
+  собственный разбор ошибок этот случай называет. Напечатанный номер значит «вызов прошёл», а не
+  «задача видна тому, кто по ней работает». Спрашивается очередь — по номеру, одним вызовом, — и
+  ответ читается присутствием задачи на борде, её колонкой и исполнителем.
 - **Номер ветки и номер в заголовке PR сверяются на месте, а состояние задачи — по борде.**
   Формат читается из текста команды и работает без сети; существование задачи, её присутствие
   на борде, исполнитель и то, что она ещё открыта, — только когда есть чем спросить. Нет сети
@@ -68,13 +73,13 @@ description: Правило под «Закон о поставке» для д
   перевода, а не набор вызовов GraphQL по памяти. Перевод идёт сразу за шагом, который его
   вызвал: очередь работ читают между шагами, а не после них.
 - **Отставшая колонка находится сверкой очереди, а не глазами.** Сверка судит колонку по
-  отчёту в обе стороны: открытый PR при задаче не в разборе и разбор без открытого PR — оба
+  PR в обе стороны: открытый PR при задаче не в разборе и разбор без открытого PR — оба
   расхождения. Момента, когда задачу берут в работу, ей не видно: ветки на борде нет.
 - **Задачи, чинящиеся одной правкой, сливаются до мержа.** Вторая стирается вместе с номером,
   а недостающее из неё дописывается в первую. После мержа слить уже нельзя: ветка въехала, и
   откатывается она целиком.
 - **Работа, которую одним заходом не закрыть, помечена в двух местах, и они сверяются.** Метка
-  на борде и строка о заходах с передачей в линии работ говорят одно и то же двум читателям:
+  на борде и строка о заходах с передачей в замысле эпика говорят одно и то же двум читателям:
   исполнитель открывает карточку раньше, чем линию, а планирует по линии. Одна пометка без
   другой лжёт молча, поэтому сверка очереди судит пару в обе стороны. Помечается только то, что
   законно не делится: пометка объёма правом делить не становится.
@@ -99,9 +104,9 @@ description: Правило под «Закон о поставке» для д
   которая его заводит или переносит, ручной запуск не покрывает. Прогон команд задания на своей
   машине не покрывает её тоже: он проверяет команды, а не файл конвейера, — верность самого
   файла читается только по списку прогонов после пуша.
-- **Отчёт проверяется до мержа тем же конвейером, что и главная ветка.** Проверки и сборки
+- **PR проверяется до мержа тем же конвейером, что и главная ветка.** Проверки и сборки
   образов идут на событии `pull_request`, выкатка — нет: её держит условие по главной ветке у
-  своего задания, а образ отчёта в реестр не уезжает.
+  своего задания, а образ PR в реестр не уезжает.
 - **Расхождение прода с главной веткой видно сверкой очереди работ.** Задача уходит из очереди
   мержем, но мерж — ещё не прод: отказавшая выкатка не трогает ни задачу, ни её колонку, и
   заметить её неоткуда. Сверка спрашивает последний прогон главной ветки и судит только
@@ -133,6 +138,10 @@ description: Правило под «Закон о поставке» для д
   сломана, она описывает вчерашний день. Сравнение веток пишется от `origin/main` целиком —
   смешав в одной команде удалённую ссылку для одной стороны и локальную для другой, промах
   изнутри выглядит правильным.
+- **Мерж PR нажимает человек, а не исполнитель работы.** Кнопка и вызов слияния равны: запрет
+  на них один. Исполнитель сливает свой PR только тогда, когда человек сказал это прямо и про
+  этот PR; сказанное об одном PR на следующий не переносится, а молчание разрешением не
+  бывает. Работа кончается открытым и зелёным PR, и в ответе называется его номер.
 - **Автор PR не может быть его ревьювером.** Запрос разбора на самого себя GitHub принимает и
   молча не создаёт — разбор при этом выглядит запрошенным.
 - **Метки, исполнитель и ревьювер PR ставятся вызовами `gh api`, а не `gh pr edit`.** На
@@ -141,6 +150,15 @@ description: Правило под «Закон о поставке» для д
 - **Борда правится запросом GraphQL по идентификатору проекта.** `gh project` с `--owner`
   отвечает `unknown owner type`, когда владелец борды — не та учётная запись, под которой
   идёт вызов.
+- **Почта машинного коммита копируется из компаньона, а не набирается по памяти.** Служебный
+  адрес GitHub — `<число>+<логин>@users.noreply.github.com`, и сопоставляется он по числу: логин
+  рядом с ним не сверяет никто. Коммит с чужим числом уезжает подписанным посторонним человеком,
+  а изнутри промах не виден — имя учётной записи в истории то самое. Ту же строку держит профиль
+  дерева, и гард поставки отбивает пуш при расхождении.
+- **Личность машинной записи подтверждается ответом хостинга, а не узнаванием строки.** Знакомый
+  вид строки подтверждением не бывает — промах выглядел знакомо. Спрашивается токеном самой
+  записи, ответом о себе: логин и число приходят вместе. Поиск по числу для ограниченной записи
+  отвечает «не найдено» и её собственным токеном, поэтому годится только ответ о себе.
 - **Сценарии гардов задают настройки git сами, а не берут их с машины.** Коммит во временном
   репозитории сценария наследует общий конфиг: если включена подпись, git идёт в агент ключей,
   а заблокированный агент роняет весь набор — со стороны это выглядит сломанным гардом. Автор,
@@ -154,7 +172,7 @@ description: Правило под «Закон о поставке» для д
 
 Гард поставки стоит на командах агента, поэтому ветку, заведённую руками в редакторе, он не
 видит: имя такой ветки держится памятью. Требование от этого не слабеет — просто отдельной
-проверки под него не заводится: работа опознаётся заголовком задачи и отчёта, а это сверяется
+проверки под него не заводится: работа опознаётся заголовком задачи и PR, а это сверяется
 у всех. Сверка очереди имя ветки не судит вовсе: у открытого PR его не переименовать.
 
 Взятие задачи в работу не стережёт ничто: борда ветки не видит, а гард поставки её видит, но
@@ -162,11 +180,11 @@ description: Правило под «Закон о поставке» для д
 работу вместо промаха. Держится это памятью и подсказкой, которую печатает команда заведения
 задачи. Отставшую колонку находит сверка очереди — но уже после того, как PR открыт.
 
-Свежесть самой вершины главной ветки гард не проверяет: он судит по тому, что лежит в дереве, и
-вершину недельной давности от сегодняшней не отличает. Сетевой вызов сюда не заводится по той же
-причине, что и выше, — он падал бы вместе со связью. Поэтому гард ловит ветку, отставшую
-заведомо, а `git fetch` перед вливанием стоит первым пунктом чеклиста и держится тем же, чем
-держатся остальные его пункты.
+Свежесть самой вершины главной ветки гард спрашивает вторым ярусом — тем же приёмом, что и
+состояние задачи: есть чем спросить, спрашивает; нет сети или доступа — пропускает молча.
+Первый ярус при этом остаётся, и работает он без сети: локальная ссылка отвечает на вопрос
+«отстала ли ветка от того, что уже лежит в дереве», удалённая — на вопрос «не протухла ли сама
+ссылка». Без второго яруса молчание гарда значило лишь первое, а читалось как второе.
 
 ## Паттерны
 
@@ -198,7 +216,7 @@ description: Правило под «Закон о поставке» для д
 - **Учётная запись для пуша и автор PR выбираются отдельно.** Если пушить пришлось из-под другой
   записи, на следующий вызов это не переносится: PR открывают токеном учётной записи машинной
   работы, и от того, чьей записью он открыт, зависит, кого можно назначить ревьювером. Однажды
-  смена записи ради пуша утекла в публикацию — отчёт вышел от владельца.
+  смена записи ради пуша утекла в публикацию — PR вышел от владельца.
 - **Невалидный файл конвейера виден прогоном нулевой длительности сразу после пуша.** GitHub
   заводит такой прогон и на ветке, на которую ни один триггер не подписан: в списке он стоит
   отказом, а внутри у него нет ни задания, ни лога — читается только длительность. Поэтому