@rt-tools/agent-kit 0.8.0 → 0.8.2

package/assets/patterns/git-workflow-merge.md

@@ -81,7 +81,7 @@ bash .claude/hooks/tests/run.sh       # если конфликт задел х
 
 ## Тело открытого PR перечитывается после мержа
 
-Отчёт описывал дерево на день, когда его написали. Мерж главной ветки меняет то, о чём он
+PR описывал дерево на день, когда его написали. Мерж главной ветки меняет то, о чём он
 утверждает: тело говорило, что оба дефекта заведены в `docs/BACKLOG.md`, а главная ветка этот
 список к тому времени разобрала. Правится тело вызовом REST — `gh pr edit` в этом репозитории
 отвечает отказом про Projects (classic) и до правки не доходит:

package/assets/patterns/reuse-first-extend.md

@@ -82,9 +82,18 @@ grep -rn "<похожий приём>" libs/admin libs/site --include='*.html' |
 <input type="tel" qa-dataid="phone-input" />
 ```
 
-Маркер `native-ok` ставится в той же строке и объясняет, **чего именно нет в ките**. «Эти
-строки были здесь раньше» причиной не считается: гард вычёркивает из проверяемого текста то,
-что уже лежит в файле, поэтому отказ означает новый текст.
+Маркер `native-ok` объясняет, **чего именно нет в ките**. «Эти строки были здесь раньше»
+причиной не считается: гард вычёркивает из проверяемого текста то, что уже лежит в файле,
+поэтому отказ означает новый текст.
+
+Стоит он комментарием строкой выше кода или в самой строке — снимаются обе. В разметке годится
+только первое: форматировщик разносит тег, у которого атрибуты не влезли в предел ширины, по
+строкам, и первый атрибут всегда уезжает на строку ниже имени тега. Признак считает имя тега,
+то есть первую строку, а маркер, поставленный атрибутом, оказывается на второй и не снимает
+ничего. Короткий тег форматировщик не трогает — и маркер работает ровно до тех пор, пока к тегу
+не добавили ещё один атрибут.
+
+Дальше следующей строки маркер не достаёт: он снимает свой случай, а не блок вокруг себя.
 
 Сверка идёт без отступов — при переезде блок меняет отступ, оставаясь тем же кодом.
 

package/assets/patterns/spec-driven-domain.md

@@ -43,6 +43,12 @@ docs/specs/<домен>/
 
 Текст заголовка сверяется дословно. «Не применимо» — законный ответ, отсутствие раздела — нет.
 
+`## Решения` — временное место. Решение живёт в нём, пока не найден слой, которому оно
+принадлежит; найденный слой забирает его пунктом, а в спеке не остаётся ничего. Разросшийся
+раздел читается как признак незаведённого правила, а не как свойство сложного домена: делить
+такой спек по строкам бесполезно, потому что делится в нём не описание домена, а ненаписанное
+правило.
+
 Шапка несёт статус, дату ревизии, префикс сценариев, зависимости от других доменов, строку
 `**Законы:**` — законы, которые домен применяет, — и строку `**Процедуры:**` — корни либ, чьи
 процедуры домен обслуживает.
@@ -129,7 +135,7 @@ docs/specs/<домен>/
 - Пометка «Не покрыто» при существующем тесте — отказ: долг закрыли, а отметку не сняли.
 - Пометка «Не покрыто» читается дословно и с начала строки. Любое слово между ней и двоеточием
   — «Не покрыто, и прогоном не покрывается вовсе: …» — и сценарий считается непомеченным вовсе,
-  а причина, ради которой пометку и писали, до отчёта не доезжает.
+  а причина, ради которой пометку и писали, до PR не доезжает.
 - Закон, названный в тексте, но забытый в строке `**Законы:**`: по закону тогда не узнать,
   какие домены на нём стоят.
 - Правка `.proto` без спеков задетых доменов: `docs-guard` отбивает такой коммит.

package/assets/patterns/spec-driven-rule.md

@@ -123,6 +123,12 @@ description: Паттерн правила git-workflow. Брать … Не б
   правку сущности оказались привязаны к механике, которую не зовёт ни один экран.
 - Утверждение переформулировали, а строку в привязке не тронули: связь идёт по тексту, и
   проверка перестанет её находить.
+- Строка привязки дописана в конец компаньона, а не вставлена в таблицу. После таблицы там идут
+  ещё разделы — «Чем это проверяется», «Что ещё стоит знать при чтении кода», — и приписанная в
+  конец строка в таблицу не попадает вовсе: утверждение читается непривязанным, а сверка спеков
+  на это молчит, потому что ищет строку в таблице. Место строки то же, что у её утверждения в
+  правиле: порядок обеих сторон держится одинаковым, иначе утверждение и его привязка перестают
+  находиться друг по другу.
 - В `description` не сказано, когда паттерн **не** брать, — соседний паттерн того же правила
   становится неотличимым.
 - Блок готового кода принят по виду, а не сверкой с объявлением. Вызов в примере повторяет имя,

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 вышел от владельца.
 - **Невалидный файл конвейера виден прогоном нулевой длительности сразу после пуша.** Прогон
   заводится и кончается на разборе файла, не начав ни одного задания: в списке он стоит
   отказом, а внутри нет ни задания, ни лога — читается только длительность. Поэтому список