@rt-tools/agent-kit 0.11.0 → 0.12.0

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

@@ -0,0 +1,240 @@
+---
+name: git-workflow-pr
+kind: pattern
+rule: git-workflow
+description: Паттерн правила git-workflow. Брать на открытие MR и всё, что с ним связано, — формат заголовка, черновик и его снятие, строка связи с задачей, ревьювер и метки, образец описания с разделом об оставшемся шаге, чтение состояния MR, перевод задачи в список разбора, чеклист проверок до снятия черновика. Не брать на заведение задачи, ветки и коммит — это паттерн git-workflow-commit.
+---
+
+# Заявка на слияние
+
+Паттерн правила `git-workflow`. Что при этом должно быть верно — закон
+`docs/constitution/delivery.md`. Заведение задачи, ветки и коммит — паттерн
+`git-workflow-commit`.
+
+## Когда брать
+
+- Открывается MR по готовой ветке.
+- Правится заголовок, тело или метки уже открытого MR.
+- Снимается черновик, и работа отдаётся на разбор.
+- Читается состояние MR перед тем, как что-либо о нём сказать владельцу.
+
+## Номер задачи стоит в её заголовке и в заголовке 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 разводятся прямо: непроверенное,
+названное проверенным, ревьювер принимает за проверенное.
+
+**Раздел «Чем подтверждено» называет и то, что не гонялось.** Список одного прогнанного
+неотличим от полного набора, и ревьювер по нему решает, что можно не перепроверять. Цена ошибки
+здесь не красный конвейер, а доверие к разделу: однажды прочитанный как полнота, дальше он
+перепроверяется весь.
+
+## Частые промахи
+
+Промахи про заведение задачи, ветку и коммит — паттерн
+`git-workflow-commit`.
+
+- MR открыт без ревьювера: он не попадает во входящие владельца, и очередь стоит, выглядя
+  работающей.
+- Метки поставлены по названию MR, а не прочитаны у задачи: область теряется, и по доске не
+  видно, что правка задела ещё и соседний домен.
+- Вторая строка `Closes` в одном MR: две задачи в одной ветке откатываются только вместе. Либо
+  это одна задача — и вторая поглощается, — либо две ветки.
+- Половина задачи, уехавшая своим MR: описание такого MR начинается со слов «Часть #<номер>»
+  вместо `Closes`, задача остаётся открытой, и после отката видно её целой.
+- `--remove-source-branch` забыт: ветки задач копятся в репозитории, и по списку веток больше
+  не видно, какая работа идёт сейчас.

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

@@ -1,13 +1,13 @@
 ---
 name: git-workflow-restart
 kind: pattern
-rule: git-workflow
-description: Паттерн правила git-workflow. Брать при ручном перезапуске прода — после правки .env.prod, при разборе выкатки, при подъёме контейнера на сервере. Готовые команды с IMAGE_TAG по sha, способ узнать выкаченный sha и чем сверять результат. Не брать для коммита и миграций — это паттерны git-workflow-commit и git-workflow-migration.
+rule: deploy-flow
+description: Паттерн правила deploy-flow. Брать при ручном перезапуске прода — после правки .env.prod, при разборе выкатки, при подъёме контейнера на сервере. Готовые команды с IMAGE_TAG по sha, способ узнать выкаченный sha и чем сверять результат. Не брать для коммита и миграций — это паттерны git-workflow-commit и git-workflow-migration.
 ---
 
 # Ручной перезапуск прода
 
-Паттерн правила `git-workflow`. Что при этом должно быть верно — закон
+Паттерн правила `deploy-flow`. Что при этом должно быть верно — закон
 `docs/constitution/delivery.md`.
 
 ## Когда брать

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

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

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

@@ -0,0 +1,193 @@
+---
+name: task-flow-archive
+kind: pattern
+rule: task-flow
+description: Паттерн правила task-flow. Брать, когда работа доведена до готовности: разбор папки задачи последним коммитом, переезд в описание прошлого, сверка очереди работ, разбор закрытой работы правилами и то, что делать с его находками. Не брать для вливания договорённости и приведения текстов — это паттерн task-flow-close.
+---
+
+# Разбор папки задачи и разбор работы правилами
+
+Паттерн правила `task-flow`. Что при этом должно быть верно — закон
+`docs/constitution/work-conduct.md`. Что делается до этого — снятие черновика, вливание
+договорённости и приведение текстов — паттерн `task-flow-close`.
+
+## Когда брать
+
+- Договорённость влита, тексты домена приведены, и папка задачи разбирается последним
+  коммитом ветки.
+- Работа слита человеком, и её разбирают правилами.
+- Разбор вернул находки, и их надо куда-то положить.
+
+## Состояние `разбор-кончился`: папка задачи разбирается
+
+Разбор идёт по трём исходам, а не по двум.
+
+**Первым отбирается действующее требование.** Всё, что останется верным и завтра, становится
+статьёй закона, пунктом правила или разделом паттерна — по тому, о чём оно говорит. Признак
+отбора один и записан здесь заранее: перестанет ли текст быть верным, если завтра всё
+переделать. Перестанет — это рассказ о состоявшемся; не перестанет — требование, и место ему в
+слое правил. Закон при этом в ветке не правится — его статья приносится владельцу текстом.
+
+**Вторым отбирается рассказ о состоявшемся переезде.** Он уезжает в описание прошлого и
+называет для каждого перенесённого решения, куда оно ушло: иначе решение, ставшее правилом, и
+решение, потерянное при переносе, выглядят одинаково — записью, на которую никто не ссылается.
+
+**Третьим удаляется остальное.**
+
+Порядок именно такой: начав с переезда, исполнитель увозит вместе с ним и действующее — под
+конец работы это дешевле, чем разбирать.
+
+Целиком в архив не переносится: `docs/archive/` — место для записей о состоявшемся, которые
+кто-то читает, а не свалка ходов работы. Таблица ниже говорит о том, что осталось после
+первого отбора.
+
+| Файл            | Куда                                                                                                               |
+| --------------- | ------------------------------------------------------------------------------------------------------------------ |
+| `grill.md`      | в `docs/archive/` — ответы владельца невосстановимы, и это единственная запись о том, почему задача поставлена так |
+| `progress.md`   | в `docs/archive/`, если в нём есть решения по ходу с причинами; иначе удаляется                                    |
+| `plan.md`       | удаляется — после выкатки на его вопрос отвечает код, а на «как работает» отвечает спек домена                     |
+| находки разбора | переезжают к замыслу эпика — их читает владелец, когда эпик кончится; работа вне эпика показывает их сразу         |
+
+Уезжающее складывается одним файлом с говорящим именем, а не папкой из трёх:
+
+```bash
+cat docs/tasks/<КЛЮЧ>-<номер>-<slug>/grill.md > docs/archive/<ЧТО_РЕШАЛИ>.md
+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/<своя>
+```
+
+Две записи в архиве, а не одна: работы разные, и решения в них разные. Сверка очереди работ
+после этого не называет ни одной папки — этим и проверяется, что разобраны обе.
+
+**Следующее движение:** разобранная папка уезжает в ветку тем же коммитом, и следом за ним
+сверяется очередь работ.
+
+## Состояние `папка-разобрана`: сверка очереди работ
+
+```bash
+npm run check:board   # папка закрытой задачи среди текущих, брошенные черновики
+npm run check:specs   # договорённость влита, привязки на месте
+npm run check:docs    # пути, названные в текстах, существуют
+```
+
+**Следующее движение:** расхождения, названные сверками, чинятся тем же ходом; чинить нечего —
+тот же ход снимает черновик и просит владельца влить, называя номер.
+
+## Состояние `влито`: работа разбирается правилами — фоном, следом за PR
+
+Шаг о слое правил, а не о продукте: что за эту работу грузилось, что помогло, чего не хватило и
+где текст правила разошёлся с деревом. Знает это только тот заход, который работу вёл, — через
+сутки не знает никто.
+
+Ведёт разбор роль разбора закрытой задачи, если дерево её разложило; не разложившее ведёт его
+само, теми же вопросами. Файлов роль не правит — приносит готовые формулировки, а вставлять их
+решает владелец.
+
+**Запускается разбор в фоне, сразу за открытием PR, и ход на нём не кончается.** Роль ничего не
+спрашивает, пока работает, и быстрее от ожидания не идёт: следующая задача берётся тем же ходом,
+которым запущен разбор.
+
+Порядок один и переставлять его нельзя:
+
+1. **Сводка собирается до запуска** — пока задача ещё в голове. Что делали, что пошло не так,
+   что грузилось и что каждое правило дало, на какие грабли окружения наткнулись. Собранная
+   через две задачи, она пересказывает историю ветки вместо того, что было на самом деле.
+2. **Роль уходит в фон** — инструментом запуска роли, с путём к списку загруженного и сводкой
+   целиком. Ход продолжается следующей задачей.
+3. **Вернувшиеся находки принимают одним ходом** — записать и вернуться к прежнему. Разбор,
+   отложенный «до удобного момента», не случается вовсе: заход кончается раньше.
+
+**Следующее движение:** пока роль разбирает, тот же ход занят следующей задачей; вернувшиеся
+находки принимаются одним ходом — записать и продолжить прежнее.
+
+## Состояние `влито`: находки разбора ложатся в папку задачи и ждут владельца
+
+Ответ роли живёт в переписке и умирает вместе с ней, поэтому он сразу ложится на диск — в папку
+задачи, файлом рядом с ходом работы. Пишет его исполнитель: роль файлов не пишет.
+
+Папка задачи умирает со слиянием, а находки должны пережить весь эпик — владелец читает их
+разом, когда эпик кончился. Поэтому при разборе папки файл находок не удаляется вместе
+с остальным, а **переезжает к замыслу эпика**: там его найдут и после того, как ветка въехала.
+Работа вне эпика показывает находки владельцу сразу, тем же ходом.
+
+**Наружу без слова владельца уезжает только сводка наблюдений.** Она говорит, чем пользовались
+и чем не пользовались ни разу, — это факт, и мнением он не станет. Предложение — другое дело:
+это заготовка правки чужого дерева, и часть заготовок отпадает при первом же чтении. Уехавшая
+без разбора, она становится работой того, кто её не заказывал.
+
+Порядок такой: находки копятся у замысла эпика → эпик кончился → владелец читает их разом и
+говорит, что из них верно → названное им оформляется предложением и уезжает. Чем отправляют —
+скил слоя правил, если дерево его разложило.
+
+У каждой находки называется адрес, и адресов три:
+
+| Куда                       | Что туда идёт                                                            |
+| -------------------------- | ------------------------------------------------------------------------ |
+| слой правил — предложением | то, что верно любому дереву этого класса: статья, пункт правила, паттерн |
+| имена этого дерева         | то, что верно здесь: компаньон правила, профиль, карта гейта             |
+| надстройка над разложенным | то, что здесь звучит иначе, чем в пакете                                 |
+
+Без адреса правка ложится туда, где её видит автор, — то есть в своё дерево, — и общее оседает
+в одном месте, оставаясь неизвестным всем остальным.
+
+**Разбор без правки закрытым не считается.** Из него выходит либо правка слоя правил, либо
+предложение наружу; не вышло ни того ни другого — это жалоба, и она повторится. Предложение, о
+котором владелец сказал вслух, уходит наружу в тот же ход: написанное и не отправленное лежит в
+дереве неотличимо от отправленного.
+
+**Следующее движение:** записанные находки работу не держат — следующая задача уже идёт, а
+владельцу о них говорится, когда кончился эпик.
+
+## Ловушки
+
+- **Папку разбирают до слияния — потом о ней уже никто не вспомнит.** Сверка очереди считает
+  задачу закрытой по слиянию: до него папка среди текущих законна, а после за неё никто не
+  отвечает — работа перешла к следующей задаче, и находка достанется чужому заходу. Три раза
+  подряд папка закрытой задачи так и уехала в главную ветку, в последний раз их набралось
+  пять. Теперь это держит гард поставки: слияние отбивается, пока папка лежит в ветке.
+- **Разбирают последним коммитом, а не перед открытием PR.** Пока идёт ревью, замысел
+  нужен на диске: без него правку по замечаниям не пропустит гард хода работы. Порядок такой:
+  правки по ревью, потом разбор папки, потом слияние.
+- **Разбор папки идёт последним, после того как гейт пуша прошёл целиком.** Гард хода работы
+  не пускает правку кода приложения без замысла на диске, а после разбора замысла нет: чужое
+  замечание линтера, приехавшее мержем из главной ветки, чинить уже нечем, и гейт пуша стоит.
+  Порядок один: мерж главной ветки, все линтеры и проверки зелёные, вливание договорённости,
+  приведение текстов домена, разбор папки. Понадобилась правка кода после разбора — замысел
+  восстанавливается на диске на время правки, и разбор повторяется тем же коммитом.
+- **Если папку просто удалить, первым пропадёт `grill.md`.** Удалить проще, чем разобрать, а
+  слова владельца записаны только там, и восстановить их неоткуда. Поэтому гард требует, чтобы
+  ветка добавила запись в архив. Что именно перенесли, он не проверяет — это смотрит владелец
+  на ревью.
+- **Шаги закрытия с владельцем не согласуются — они перечислены здесь.** Разбор работы
+  правилами входит в закрытие так же, как вливание договорённости и разбор папки; владелец
+  решает не то, запускать ли его, а что делать с находками. Ход, кончившийся таким вопросом,
+  отбивает гард разговора: за ход правила не читались, а ответ стоит в них. Спрашивается только
+  то, чего в правилах нет.
+- **Блок готового кода в паттерне стареет от чужой правки.** Он не привязан ни к чему: сверка
+  спеков читает утверждения правила, а пример под ними не читает вовсе. Два поля, ставших
+  обязательными в чужой работе, сделали пример в соседнем паттерне несобираемым — сам он при
+  этом не изменился ни на знак и в след задачи не попал, потому что ни одного слова той работы
+  в нём нет. Паттерн находится по имени правленого символа, а не по теме работы.
+- **Замысел эпика правят только там, где вписывают «чем кончился».** Границы эпика и
+  порядок задач в нём при этом остаются прежними, а работа их уже нарушила: задача, решившая
+  читать спеки, оставила над собой границу «спеки — вторая очередь», и следующий исполнитель
+  прочитает её как действующую. Границы эпика перечитываются целиком тем же заходом, что и
+  итог работы.
+- **Архив не обновляется после выкатки.** Уехавшее туда описывает день переезда, и правится
+  оно только вместе с признанием, что описывало неверно.