@rt-tools/agent-kit 0.11.0 → 0.12.0

package/assets/patterns/git-workflow-commit.github.md

@@ -2,10 +2,10 @@
 name: git-workflow-commit
 kind: pattern
 rule: git-workflow
-description: Паттерн правила git-workflow. Брать на заведение задачи, ветки, коммит, пуш и создание PR — готовая команда заведения задачи со всеми четырьмя шагами, перевод задачи в колонку работы и в колонку разбора, слияние двух задач в одну, сверка очереди работ, работа от учётной записи бота, формат заголовка, строка связи с задачей, ревьювер, исполнитель и метки PR, образец тела PR с разделом об оставшемся шаге, чеклист проверок до публикации, обход требования документа. Не брать для миграций и перезапуска прода — это паттерны git-workflow-migration и git-workflow-restart.
+description: Паттерн правила git-workflow. Брать на заведение задачи, ветки, коммит и пуш — готовая команда заведения задачи со всеми четырьмя шагами, перевод задачи в колонку работы, слияние двух задач в одну, работа от учётной записи бота, обход требования документа. Не брать на открытие PR — это паттерн git-workflow-pr; не брать для миграций и перезапуска прода — это паттерны git-workflow-migration и git-workflow-restart.
 ---
 
-# Ветка, коммит и PR
+# Задача, ветка и коммит
 
 Паттерн правила `git-workflow`. Что при этом должно быть верно — закон
 `docs/constitution/delivery.md`.
@@ -15,7 +15,6 @@ description: Паттерн правила git-workflow. Брать на зав
 - Заводится задача, с которой начинается правка.
 - Заводится ветка под задачу.
 - Готовится коммит или пуш.
-- Открывается PR.
 - Работа перешла на следующий шаг, и задача переставляется в другую колонку борды.
 
 ## Сначала задача на борде, потом ветка
@@ -161,250 +160,6 @@ chore(deploy): docker-compose for vps
 Docs-skip: правка только в тестах хука, зеркала у него нет
 ```
 
-## Номер задачи стоит в её заголовке и в заголовке PR
-
-Форма одна на оба — `[<КЛЮЧ>-<номер>] <текст>`. Номер стоит в самом заголовке, а не только в
-теле: в списке PR тела не видно, а в списке задач номер иначе приходится искать глазами по
-колонке слева. Тот же номер несёт и имя ветки — `<КЛЮЧ>-<номер>-<короткий-slug>`, — поэтому
-задача, ветка и PR читаются как одно.
-
-Задача говорит, что не так; PR тем же номером отчитывается, что сделано:
-
-```
-задача  [<КЛЮЧ>-86] Пустой MAIL_OWNER — письма владельцу не уходят молча
-PR      [<КЛЮЧ>-86] Письмо владельцу с незаполненным адресом попадает в логи
-
-задача  [<КЛЮЧ>-101] Вернуть оверлей загрузки таблицы и включить stylelint гейтом
-PR      [<КЛЮЧ>-101] Stylelint включён гейтом
-
-задача  [<КЛЮЧ>-212] Сайт не собирается: компонентам кита проставлен префикс приложения вместо своего
-PR      [<КЛЮЧ>-212] Виджет переписки зовёт кит его собственными именами
-```
-
-Инфинитив из задачи в заголовок PR не переносится: «исправить» становится «исправлено»,
-«вернуть» — «возвращено», «добавить» — «добавлено».
-
-Номер в заголовке обязан совпасть с номером ветки: гард поставки сверяет их до отправки
-команды, а сверка очереди — у каждого открытого PR.
-
-Тип и область — `fix(site):`, `docs(common):` — в заголовок PR не идут: это формат заголовка
-коммита, и там его сверяет `commitlint`. В списке PR он занимает место, ничего не добавляя:
-род правки и область уже видны метками.
-
-## Не готовое к слиянию открывается черновиком
-
-Правка кода отдаётся человеку открытым PR: запушенная ветка ему не показывается нигде. Открытый
-PR при этом читается как приглашение влить, поэтому у незаконченной работы он открывается
-черновиком — кнопку слияния у черновика хостинг блокирует сам:
-
-```bash
-GH_TOKEN="$TOKEN" gh pr create --draft --title '[<КЛЮЧ>-86] …' --body-file тело.md
-```
-
-Черновиком идёт всё, что ждёт прогона конвейера, доработки или ответа на вопрос. Вопрос
-задаётся в самом PR, а не остаётся в голове исполнителя: человек читает PR, а не переписку
-захода.
-
-Снимается черновик отдельным вызовом, и это тот самый ход, которым исполнитель говорит, что
-решение готово:
-
-```bash
-GH_TOKEN="$TOKEN" gh pr ready 86
-```
-
-До снятия молчание исполнителя значит «ещё не готово», после — «можно вливать». Снятие
-черновика и просьба влить идут одним ходом: снятый черновик, о котором человеку не сказали,
-ждёт разбора ровно так же, как не снятый.
-
-## PR прикрепляется к задаче
-
-Тело начинается со строки связи — по ней на борде заполняется поле «Linked pull requests».
-Ревьювер, исполнитель и метки задаются той же командой, и PR без них не открывается:
-
-```bash
-GH_TOKEN="$TOKEN" gh pr create --title '[<КЛЮЧ>-86] Письмо владельцу с незаполненным адресом попадает в логи' \
-    --reviewer <владелец> --assignee <бот> --label bug --label area:api \
-    --body 'Closes #86
-
-…'
-```
-
-Ревьювер — всегда владелец: без запроса разбора PR не показывается ему в очереди. Исполнитель —
-та же учётная запись, от которой идёт машинная работа. Метки берутся у задачи целиком — и род
-правки, и все её области; читаются они у задачи, а не выбираются по памяти:
-
-```bash
-/opt/homebrew/bin/gh issue view 86 --json labels --jq '.labels | map(.name) | join(",")'
-```
-
-Строка `Closes #<номер>` обязательна: без неё PR не прикрепляется к задаче, и сверка очереди
-это находит. Она же и означает, что задача закрывается целиком — половину задачи одним PR не
-выкатывают: у задачи одна ветка, и работа, которая в неё не влезает, делится на задачи до
-того, как ветка заводится.
-
-У уже открытого PR то же ставится тремя вызовами REST. `gh pr edit` здесь не годится: он
-запрашивает карточки Projects (classic), получает отказ о снятом API и до правки не доходит.
-
-```bash
-GH=/opt/homebrew/bin/gh
-REPO=<владелец>/<репозиторий>
-
-$GH api -X POST "repos/$REPO/issues/205/labels" -f 'labels[]=bug' -f 'labels[]=area:api'
-$GH api -X POST "repos/$REPO/issues/205/assignees" -f 'assignees[]=<бот>'
-$GH api -X POST "repos/$REPO/pulls/205/requested_reviewers" -f 'reviewers[]=<владелец>'
-```
-
-Тем же вызовом правится и само тело: `-f body=` переписывает его целиком, поэтому строка
-`Closes #<номер>` пишется заново вместе с остальным текстом.
-
-```bash
-$GH api -X PATCH "repos/$REPO/pulls/205" -f body="$(cat тело.md)"
-```
-
-Тело перечитывается всякий раз, когда в ветку что-то влилось после публикации: PR
-утверждает про дерево, а дерево с тех пор изменилось.
-
-## Образец тела PR
-
-Четыре раздела, и порядок между ними один: строка связи, что сделано, чем подтверждено,
-оставшийся шаг. Раздел, которому нечего сказать, пишется словами — пустой заголовок и снятый
-заголовок читаются одинаково, а значат разное.
-
-```markdown
-Closes #86
-
-## Что сделано
-
-- <правка, названная тем, что она меняет для читателя, а не тем, какие файлы задела>
-
-## Чем подтверждено
-
-- <проверка>: <её вывод одной строкой>
-- Не гонялось: <что в набор не вошло и почему>
-
-## Оставшийся шаг
-
-После одобрения ветка получает ещё один коммит — разбор папки задачи, — и только потом
-вливается. До этого коммита вливать рано: папка уедет в главную ветку неразобранной.
-```
-
-Раздел «Оставшийся шаг» стоит последним и переписывается тем же вызовом, что и остальное тело,
-— в тот ход, которым папка разбирается и снимается черновик:
-
-```markdown
-## Оставшийся шаг
-
-Не осталось: папка задачи разобрана коммитом `<sha>`, черновик снят. Можно вливать.
-```
-
-Стоит он там потому, что решение о слиянии принимается на этой странице, а не в переписке:
-сказанное владельцу вслух живёт до следующей реплики, а тело лежит у самой кнопки. Одно другого
-не отменяет — порядок обоих сообщений владельцу описывает паттерн закрытия работы.
-
-Проверить тело машиной нечем: ни одна сверка его не читает, а хостинг спрашивает только про
-заголовок. Держится образец тем, кто пишет тело, — как и слова вслух.
-
-## Состояние PR читается, а не додумывается
-
-Вызовы, которыми ставятся ревьювер, метки и исполнитель, отвечают нулевым кодом и тогда, когда
-ничего не сделали: запрос разбора на автора PR GitHub молча выбрасывает. Поэтому после них PR
-перечитывают:
-
-```bash
-# Ключи латиницей: кириллический ключ без кавычек `jq` не разбирает и падает на нём
-$GH api "repos/$REPO/pulls/321" \
-    --jq '{author: .user.login, reviewers: [.requested_reviewers[].login], labels: [.labels[].name]}'
-```
-
-Автор здесь — `<бот>`. Если им оказался владелец, ревьювера у PR не будет вовсе:
-назначить автора ревьювером нельзя, а отказа на такой запрос не приходит. Владельцу называют
-то, что прочитали, а не то, что заказывали.
-
-Учётная запись, из-под которой пришлось пушить, в этот вызов не переносится: пуш и авторство
-PR выбираются отдельно, и `GH_TOKEN` для публикации — всегда токен бота.
-
-Перечитывают его и по времени, а не только после вызовов, которые молча ничего не сделали:
-состояние PR читается перед тем, как что-либо о нём сказать. Между «прогон зелёный» и следующей
-фразой владелец успевает влить PR, и всё сказанное о нём после этого — про вчерашний день. Так
-владельцу и было предложено влить то, что он влил часом раньше.
-
-Открытый PR означает, что задача ждёт разбора, — колонка переставляется тем же движением:
-
-```bash
-npm run task:move -- 86 in-review
-```
-
-Голым GraphQL по идентификаторам проекта, элемента и варианта поля это не пишется: команда
-знает их сама, а собранный по памяти запрос молча ставит не ту колонку — отказа у борды на
-это нет.
-
-## Что проверяется до публикации PR
-
-Проверок на самом PR нет: выкатка запускается пушем в главную ветку, и до мержа никто не
-гоняет ничего. Линтеры, юниты и сценарии хуков снимает гейт пуша — ниже то, чего он не знает.
-
-1. **Главная ветка влита в эту ветку** — `git fetch origin && git merge origin/main`.
-   Свежесть основания между ветками одного захода не наследуется: вторая и третья ветка
-   отводятся после своего `fetch`, а не от ссылки, подтянутой под первую. Пока идёт работа,
-   главная уходит вперёд — чаще всего собственным PR того же исполнителя, влитым час
-   назад.
-   Всё, что проверяется ниже, проверяется от этого основания: PR с разошедшейся ветки
-   показывает ревьюверу правку вперемешку с чужой. Порядок и разбор конфликта — паттерн
-   `git-workflow-merge`.
-2. **В ветке только та правка, за которой её заводили** — `git diff main...HEAD --stat`. Чужой
-   домен в списке файлов означает, что правка расползлась, и её надо вернуть в свои границы.
-3. **Ни мока, ни подменённого ответа, ни отладочной строки** — `git diff main...HEAD` читается
-   целиком, а не по именам файлов. На прод они уезжают молча и портят настоящие данные.
-4. **Документ едет тем же коммитом.** Пару называет `docs-guard`, но спек домена и правку его
-   поведения он не знает — это остаётся за автором.
-5. **Проверки текстов и раскладки зелёные** — те, что дерево завело в `tools/`: сверка
-   сценариев с тестами, путей в документах, раскладки либ, повторов и классов без правила.
-   Какие именно есть здесь — `implementation.md` правила.
-6. **Все приложения дерева собираются** — `nx build` по каждому. Гейт пуша сборку не гоняет:
-   она длиннее всего, что он успевает сделать между командой и пушем.
-7. **Видимый текст заведён во всех локалях перевода** — тестом полноты словарей, если дерево
-   переводится.
-8. **Правка вёрстки подтверждена замером**, а не взглядом, и снята при узком экране — паттерн
-   `browser-verification-measure`.
-9. **Правка разметки публичного сайта проверена на прод-сборке по всем локалям перевода** — паттерн
-   `seo-verify`.
-10. **Тело PR собрано по образцу** — начинается строкой `Closes #<номер>`, несёт разделы «Что
-    сделано», «Чем подтверждено» и «Оставшийся шаг», а метки, ревьювер и исполнитель стоят.
-    Раздел оставшегося шага к этому моменту говорит, что шагов не осталось: черновик снимается
-    после разбора папки, а не до него.
-11. **Заголовок PR несёт номер задачи и называет её сделанной:** `[<КЛЮЧ>-<номер>] <Что сделано>`,
-    тем же номером, что стоит у задачи и в имени ветки. Инфинитив из задачи в него не
-    переносится, тип и область коммита — тоже.
-12. **Очередь работ сходится** — `npm run check:board`. Задача на борде, с исполнителем и
-    номером в заголовке; PR один на задачу, и закрывает он её целиком.
-13. **Состояние PR прочитано, а не выведено из кодов возврата** — автор `<бот>`,
-    ревьювер — владелец, метки те же, что у задачи. Владельцу называют прочитанное.
-14. **Набор взят из файла конвейера, а не собран по памяти.** Гейт пуша заведомо уже: он стоит
-    между командой и пушем, и всё, что дольше секунд, из него вынесено. Что гоняет конвейер,
-    написано в его файле — этот список и повторяется локально; зелёный гейт полнотой набора не
-    является.
-15. **Набор пересмотрен после вливания главной ветки.** Он выбирается по тому, что ветка везёт
-    теперь, а не по тому, что правил автор. Ветка, не тронувшая ни строки показа, прогоняет
-    снимки витрин: с момента вливания их гоняет конвейер на её коде, и красное придёт на её
-    PR.
-
-Список этот — про снятие черновика, а не про его открытие. Черновиком PR открывается раньше:
-пока работа идёт, человеку показывают то, что уже есть, вместе с тем, чего ещё нет. Пункты 1–15
-проходятся перед `gh pr ready`, и невыполненный пункт означает, что черновик не снимается, — а
-не то, что PR не открывается.
-
-Сразу после публикации задача переставляется в разбор — `npm run task:move -- <номер>
-in-review`, — и `npm run check:board` прогоняется ещё раз: до открытия PR колонку он не судит,
-а после открытия расхождение видит.
-
-Сделанное рассуждением и сделанное замером в теле PR разводятся прямо: непроверенное,
-названное проверенным, ревьювер принимает за проверенное.
-
-**Раздел «Чем подтверждено» называет и то, что не гонялось.** Список одного прогнанного
-неотличим от полного набора, и ревьювер по нему решает, что можно не перепроверять. Цена ошибки
-здесь не красный конвейер, а доверие к разделу: однажды прочитанный как полнота, дальше он
-перепроверяется весь.
-
 ## Частые промахи
 
 - `gh` в оболочке пользователя подменён — звать `/opt/homebrew/bin/gh` напрямую.
@@ -431,15 +186,4 @@ in-review`, — и `npm run check:board` прогоняется ещё раз:
   ловит и сверка — ей ветка тоже не видна.
 - `gh api graphql --paginate` на запросе элементов борды уходит в повтор первой страницы:
   курсор берётся из ответа руками, а полнота сверяется с `items(first: 1) { totalCount }`.
-- Второй строкой `Closes` в одном PR задача больше не закрывается: две задачи в одной ветке
-  откатываются только вместе. Либо это одна задача — и вторая поглощается, — либо две ветки.
-- Половина задачи, уехавшая своим PR, тоже промах: тело такого PR начинается со слов «Часть
-  #<номер>» вместо `Closes`, задача остаётся открытой, и после отката видно её целой. Работа,
-  которая в одну ветку не влезает, делится на задачи до того, как ветка заводится.
-- PR открыт без ревьювера: он не попадает во входящие владельца вовсе, и очередь стоит,
-  выглядя работающей. Так шестнадцать PR ждали разбора, которого никто не запрашивал.
-- Метки поставлены по названию PR, а не прочитаны у задачи: область теряется, и по борде не
-  видно, что правка задела ещё и сайт.
-- Задача закрыта не полностью, а метки перенесены целиком: тикет остаётся открытым, и это
-  говорится в теле PR, а не подразумевается строкой `Closes`.
 - Правка владельца ни токена, ни переменных не берёт — они только для машинной работы.

package/assets/patterns/git-workflow-commit.gitlab.md

@@ -2,7 +2,7 @@
 name: git-workflow-commit
 kind: pattern
 rule: git-workflow
-description: Паттерн правила git-workflow для дерева на GitLab. Брать на заведение задачи, ветки, коммит, пуш и создание MR — заведение задачи со всеми шагами, перевод по спискам доски, слияние двух задач в одну, сверка очереди работ, работа от учётной записи машинной работы, формат заголовка, строка связи с задачей, ревьювер, исполнитель и метки MR, образец описания MR с разделом об оставшемся шаге, чеклист проверок до публикации, обход требования документа. Не брать для миграций и перезапуска прода — это паттерны git-workflow-migration и git-workflow-restart.
+description: Паттерн правила git-workflow. Брать на заведение задачи, ветки, коммит и пуш — заведение задачи с меткой списка, перевод по спискам доски, слияние двух задач в одну, работа от учётной записи машинной работы, обход требования документа. Не брать на открытие MR — это паттерн git-workflow-pr; не брать для миграций и перезапуска прода — это паттерны git-workflow-migration и git-workflow-restart.
 ---
 
 # Ветка, коммит и MR
@@ -15,7 +15,6 @@ description: Паттерн правила git-workflow для дерева на
 - Заводится задача, с которой начинается правка.
 - Заводится ветка под задачу.
 - Готовится коммит или пуш.
-- Открывается MR.
 - Работа перешла на следующий шаг, и задача переставляется в другой список доски.
 
 ## Сначала задача на доске, потом ветка
@@ -155,211 +154,6 @@ chore(deploy): docker-compose for vps
 Docs-skip: правка только в тестах хука, зеркала у него нет
 ```
 
-## Номер задачи стоит в её заголовке и в заголовке MR
-
-Форма одна на оба — `[<КЛЮЧ>-<номер>] <текст>`. Номер стоит в самом заголовке, а не только в
-теле: в списке MR тела не видно, а в списке задач номер иначе приходится искать глазами. Тот же
-номер несёт и имя ветки, поэтому задача, ветка и MR читаются как одно.
-
-Задача говорит, что не так; MR тем же номером отчитывается, что сделано:
-
-```
-задача  [<КЛЮЧ>-86] Пустой адрес владельца — письма не уходят молча
-MR      [<КЛЮЧ>-86] Письмо владельцу с незаполненным адресом попадает в логи
-```
-
-Инфинитив из задачи в заголовок MR не переносится: «исправить» становится «исправлено»,
-«вернуть» — «возвращено», «добавить» — «добавлено».
-
-Тип и область — `fix(site):`, `docs(common):` — в заголовок MR не идут: это формат заголовка
-коммита, и там его сверяет `commitlint`. В списке MR он занимает место, ничего не добавляя:
-род правки и область уже видны метками.
-
-## Не готовое к слиянию открывается черновиком
-
-Правка кода отдаётся человеку открытым MR: запушенная ветка ему не показывается нигде. Открытый
-MR при этом читается как приглашение влить, поэтому у незаконченной работы он открывается
-черновиком — кнопку слияния у черновика хостинг блокирует сам:
-
-```bash
-GITLAB_TOKEN="$TOKEN" glab mr create --draft --title '[<КЛЮЧ>-86] …' --description "$(cat тело.md)"
-```
-
-Признак черновика здесь — приставка `Draft:` в заголовке MR, и правится он вместе с ним:
-переписав заголовок вручную, черновик снимают, не заметив этого.
-
-Черновиком идёт всё, что ждёт прогона конвейера, доработки или ответа на вопрос. Вопрос
-задаётся в самом MR, а не остаётся в голове исполнителя: человек читает MR, а не переписку
-захода.
-
-Снимается черновик отдельным вызовом, и это тот самый ход, которым исполнитель говорит, что
-решение готово:
-
-```bash
-GITLAB_TOKEN="$TOKEN" glab mr update 86 --ready
-```
-
-До снятия молчание исполнителя значит «ещё не готово», после — «можно вливать». Снятие
-черновика и просьба влить идут одним ходом: снятый черновик, о котором человеку не сказали,
-ждёт разбора ровно так же, как не снятый.
-
-## MR прикрепляется к задаче
-
-Описание начинается со строки связи. Ревьювер, исполнитель и метки задаются той же командой, и
-MR без них не открывается:
-
-```bash
-GITLAB_TOKEN="$TOKEN" glab mr create \
-    --title '[<КЛЮЧ>-86] Письмо владельцу с незаполненным адресом попадает в логи' \
-    --assignee <бот> --reviewer <владелец> --label bug --label area:api \
-    --target-branch main --remove-source-branch \
-    --description 'Closes #86
-
-…'
-```
-
-Ревьювер — всегда владелец: без запроса разбора MR не показывается ему в очереди. Исполнитель —
-та же учётная запись, от которой идёт машинная работа. Метки читаются у задачи, а не выбираются
-по памяти:
-
-```bash
-glab issue view 86 --output json | jq -r '[.labels[]] | join(",")'
-```
-
-Строка `Closes #<номер>` обязательна: без неё MR не прикрепляется к задаче, и сверка очереди
-это находит. Она же означает, что задача закрывается целиком — половину задачи одним MR не
-выкатывают: у задачи одна ветка, и работа, которая в неё не влезает, делится на задачи до того,
-как ветка заводится.
-
-У уже открытого MR то же ставится правкой:
-
-```bash
-glab mr update 205 --label bug --label area:api --assignee <бот> --reviewer <владелец>
-glab mr update 205 --description "$(cat тело.md)"
-```
-
-Правка описания переписывает его целиком, поэтому строка `Closes #<номер>` пишется заново
-вместе с остальным текстом. Описание перечитывается всякий раз, когда в ветку что-то влилось
-после публикации: MR утверждает про дерево, а дерево с тех пор изменилось.
-
-## Образец описания MR
-
-Четыре раздела, и порядок между ними один: строка связи, что сделано, чем подтверждено,
-оставшийся шаг. Раздел, которому нечего сказать, пишется словами — пустой заголовок и снятый
-заголовок читаются одинаково, а значат разное.
-
-```markdown
-Closes #86
-
-## Что сделано
-
-- <правка, названная тем, что она меняет для читателя, а не тем, какие файлы задела>
-
-## Чем подтверждено
-
-- <проверка>: <её вывод одной строкой>
-- Не гонялось: <что в набор не вошло и почему>
-
-## Оставшийся шаг
-
-После одобрения ветка получает ещё один коммит — разбор папки задачи, — и только потом
-вливается. До этого коммита вливать рано: папка уедет в главную ветку неразобранной.
-```
-
-Раздел «Оставшийся шаг» стоит последним и переписывается тем же вызовом, что и остальное
-описание, — в тот ход, которым папка разбирается и снимается черновик:
-
-```markdown
-## Оставшийся шаг
-
-Не осталось: папка задачи разобрана коммитом `<sha>`, черновик снят. Можно вливать.
-```
-
-Стоит он там потому, что решение о слиянии принимается на этой странице, а не в переписке:
-сказанное владельцу вслух живёт до следующей реплики, а описание лежит у самой кнопки. Одно
-другого не отменяет — порядок обоих сообщений владельцу описывает паттерн закрытия работы.
-
-Проверить описание машиной нечем: ни одна сверка его не читает, а хостинг спрашивает только про
-заголовок. Держится образец тем, кто пишет описание, — как и слова вслух.
-
-## Состояние MR читается, а не додумывается
-
-Команды правки отвечают нулевым кодом и тогда, когда ничего не сделали: токен без права на
-проект молча не ставит ни метку, ни ревьювера. Поэтому после них MR перечитывают:
-
-```bash
-glab mr view 205 --output json \
-    | jq '{author: .author.username, reviewers: [.reviewers[].username], labels: .labels}'
-```
-
-Владельцу называют то, что прочитали, а не то, что заказывали.
-
-Учётная запись, из-под которой пришлось пушить, в этот вызов не переносится: пуш и авторство
-MR выбираются отдельно, и токен для публикации — всегда токен машинной работы.
-
-Перечитывают его и по времени, а не только после вызовов, которые молча ничего не сделали:
-состояние MR читается перед тем, как что-либо о нём сказать. Между «прогон зелёный» и следующей
-фразой владелец успевает влить MR, и всё сказанное о нём после этого — про вчерашний день. Так
-владельцу и было предложено влить то, что он влил часом раньше.
-
-Открытый MR означает, что задача ждёт разбора, — список переставляется тем же движением:
-
-```bash
-npm run task:move -- 86 in-review
-```
-
-## Что проверяется до публикации MR
-
-Проверок на самом MR нет ровно до тех пор, пока конвейер не запущен, а запускается он пушем.
-Линтеры, юниты и сценарии хуков снимает гейт пуша — ниже то, чего он не знает.
-
-1. **Главная ветка влита в эту ветку** — `git fetch origin && git merge origin/main`.
-   Всё, что проверяется ниже, проверяется от этого основания: MR с разошедшейся ветки
-   показывает ревьюверу правку вперемешку с чужой. Порядок и разбор конфликта — паттерн
-   `git-workflow-merge`.
-2. **В ветке только та правка, за которой её заводили** — `git diff main...HEAD --stat`. Чужой
-   домен в списке файлов означает, что правка расползлась, и её надо вернуть в свои границы.
-3. **Ни мока, ни подменённого ответа, ни отладочной строки** — `git diff main...HEAD` читается
-   целиком, а не по именам файлов. На прод они уезжают молча и портят настоящие данные.
-4. **Документ едет тем же коммитом.** Пару называет `docs-guard`, но спек домена и правку его
-   поведения он не знает — это остаётся за автором.
-5. **Проверки текстов и раскладки зелёные** — те, что дерево завело в `tools/`. Какие именно
-   есть здесь — `implementation.md` правила.
-6. **Все приложения дерева собираются** — `nx build` по каждому. Гейт пуша сборку не гоняет.
-7. **Видимый текст заведён во всех локалях перевода** — тестом полноты словарей, если дерево
-   переводится.
-8. **Правка вёрстки подтверждена замером**, а не взглядом, и снята при узком экране — паттерн
-   `browser-verification-measure`.
-9. **Правка разметки публичного сайта проверена на прод-сборке по всем локалям перевода** —
-   паттерн `seo-verify`.
-10. **Описание MR собрано по образцу** — начинается строкой `Closes #<номер>`, несёт разделы
-    «Что сделано», «Чем подтверждено» и «Оставшийся шаг», а метки, ревьювер и исполнитель
-    стоят. Раздел оставшегося шага к этому моменту говорит, что шагов не осталось: черновик
-    снимается после разбора папки, а не до него.
-11. **Заголовок MR несёт номер задачи и называет её сделанной:** `[<КЛЮЧ>-<номер>] <Что
-сделано>`, тем же номером, что стоит у задачи и в имени ветки.
-12. **Очередь работ сходится** — `npm run check:board`.
-13. **Состояние MR прочитано, а не выведено из кодов возврата.**
-14. **Набор взят из файла конвейера, а не собран по памяти.** Гейт пуша заведомо уже: он стоит
-    между командой и пушем, и всё, что дольше секунд, из него вынесено. Что гоняет конвейер,
-    написано в его файле — этот список и повторяется локально; зелёный гейт полнотой набора не
-    является.
-15. **Набор пересмотрен после вливания главной ветки.** Он выбирается по тому, что ветка везёт
-    теперь, а не по тому, что правил автор. Ветка, не тронувшая ни строки показа, прогоняет
-    снимки витрин: с момента вливания их гоняет конвейер на её коде, и красное придёт на её
-    PR.
-
-Сразу после публикации задача переставляется в разбор, и сверка очереди прогоняется ещё раз: до
-открытия MR список она не судит, а после открытия расхождение видит.
-
-Сделанное рассуждением и сделанное замером в теле MR разводятся прямо: непроверенное,
-названное проверенным, ревьювер принимает за проверенное.
-
-**Раздел «Чем подтверждено» называет и то, что не гонялось.** Список одного прогнанного
-неотличим от полного набора, и ревьювер по нему решает, что можно не перепроверять. Цена ошибки
-здесь не красный конвейер, а доверие к разделу: однажды прочитанный как полнота, дальше он
-перепроверяется весь.
-
 ## Частые промахи
 
 - Метка списка не поставлена при заведении: задача есть, а на доске её нет. Доска показывает
@@ -371,14 +165,4 @@ npm run task:move -- 86 in-review
   команда обрывается на первом промахе целиком. Следующий `git commit --amend` при этом уносит
   в коммит всё, что осталось в индексе. Состав коммита читается `git show --stat` сразу после
   него, а не на разборе MR.
-- MR открыт без ревьювера: он не попадает во входящие владельца, и очередь стоит, выглядя
-  работающей.
-- Метки поставлены по названию MR, а не прочитаны у задачи: область теряется, и по доске не
-  видно, что правка задела ещё и соседний домен.
-- Вторая строка `Closes` в одном MR: две задачи в одной ветке откатываются только вместе. Либо
-  это одна задача — и вторая поглощается, — либо две ветки.
-- Половина задачи, уехавшая своим MR: описание такого MR начинается со слов «Часть #<номер>»
-  вместо `Closes`, задача остаётся открытой, и после отката видно её целой.
-- `--remove-source-branch` забыт: ветки задач копятся в репозитории, и по списку веток больше
-  не видно, какая работа идёт сейчас.
 - Правка владельца ни токена, ни переменных не берёт — они только для машинной работы.

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

@@ -1,13 +1,13 @@
 ---
 name: git-workflow-docker
 kind: pattern
-rule: git-workflow
-description: Паттерн правила git-workflow. Брать при работе с образами на своей машине — подъём и перезапуск демона, диагностика «висящей» команды, сборка под платформу прод-сервера, одноразовый контейнер рядом с чужими, вход в реестр из службы. Не брать для команд прод-сервера и выбора образа — это паттерн git-workflow-restart, и не для наката миграций — это git-workflow-migration.
+rule: deploy-flow
+description: Паттерн правила deploy-flow. Брать при работе с образами на своей машине — подъём и перезапуск демона, диагностика «висящей» команды, сборка под платформу прод-сервера, одноразовый контейнер рядом с чужими, вход в реестр из службы. Не брать для команд прод-сервера и выбора образа — это паттерн git-workflow-restart, и не для наката миграций — это git-workflow-migration.
 ---
 
 # Образы на своей машине
 
-Паттерн правила `git-workflow`. Что при этом должно быть верно — закон
+Паттерн правила `deploy-flow`. Что при этом должно быть верно — закон
 `docs/constitution/delivery.md`.
 
 Демон здесь чужой: на машине владельца в нём живут его хранилище разработки, его стенд и

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

@@ -2,7 +2,7 @@
 name: git-workflow-merge
 kind: pattern
 rule: git-workflow
-description: Паттерн правила git-workflow. Брать, когда главная ветка вливается в ветку задачи и разрешается конфликт — порядок мержа, разбор конфликта по роду файла, сверка дописанного веткой с очередью работ, проверки после разрешения, перечитывание тела уже открытого PR. Не брать для заведения ветки, коммита и PR — это паттерн git-workflow-commit.
+description: Паттерн правила git-workflow. Брать, когда главная ветка вливается в ветку задачи и разрешается конфликт — порядок мержа, разбор конфликта по роду файла, сверка дописанного веткой с очередью работ, проверки после разрешения, перечитывание тела уже открытого PR. Не брать для заведения ветки и коммита — это паттерн git-workflow-commit, для PR — git-workflow-pr.
 ---
 
 # Мерж главной ветки в ветку задачи
@@ -73,7 +73,8 @@ bash .claude/hooks/tests/run.sh       # если конфликт задел х
 ```
 
 Коммит мержа подписывается ботом тем же способом, что и любой другой, — паттерн
-`git-workflow-commit`. После пуша состояние читается у самого PR, а не по своему дереву:
+`git-workflow-commit`. После пуша состояние читается у самого PR, а не по своему дереву, —
+подробнее об этом паттерн `git-workflow-pr`:
 
 ```bash
 /opt/homebrew/bin/gh pr view <номер> --json mergeable,mergeStateStatus

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

@@ -1,13 +1,13 @@
 ---
 name: git-workflow-migration
 kind: pattern
-rule: git-workflow
-description: Паттерн правила git-workflow. Брать при правке prisma/schema.prisma и prisma/migrations/** — готовые команды одноразового контейнера, написание файла миграции через migrate diff, накат локальной базы. Не брать для коммита и PR — это паттерн git-workflow-commit.
+rule: deploy-flow
+description: Паттерн правила deploy-flow. Брать при правке prisma/schema.prisma и prisma/migrations/** — готовые команды одноразового контейнера, написание файла миграции через migrate diff, накат локальной базы. Не брать для коммита — это паттерн git-workflow-commit, для PR — git-workflow-pr.
 ---
 
 # Миграция и прогон цепочки
 
-Паттерн правила `git-workflow`. Что при этом должно быть верно — закон
+Паттерн правила `deploy-flow`. Что при этом должно быть верно — закон
 `docs/constitution/delivery.md`.
 
 ## Когда брать