@rt-tools/agent-kit 0.1.0 → 0.3.0

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

@@ -0,0 +1,175 @@
+---
+name: git-workflow-commit
+kind: pattern
+rule: git-workflow
+description: Паттерн правила git-workflow. Брать на заведение задачи, ветки, коммит, пуш и создание PR — план до первой задачи, заведение задачи всеми шагами сразу, перевод по колонкам, слияние двух задач в одну, работа от учётной записи машинной работы, формат заголовка, строка связи с задачей, состав PR, чеклист проверок до публикации. Не брать для миграций и перезапуска прода — это паттерны git-workflow-migration и git-workflow-restart.
+---
+
+# Ветка, коммит и PR
+
+Паттерн правила `git-workflow`. Что при этом должно быть верно — закон `{{lawsDir}}/delivery.md`.
+
+## Когда брать
+
+- Заводится задача, с которой начинается правка.
+- Заводится ветка под задачу.
+- Готовится коммит или пуш.
+- Открывается PR.
+- Работа перешла на следующий шаг, и задача переставляется в другую колонку.
+
+## Сначала план, потом задачи
+
+Работа, из которой выходит больше одной задачи, начинается с плана, и план показывается
+владельцу до того, как заведена первая задача. Разбивка — решение о том, что делается и в каком
+порядке, и принимает его владелец, а не тот, кто заводит.
+
+Заведённые до согласования задачи стоят в очереди как решённое дело: они показывают работу,
+которую никто не заказывал, и убирать их потом дороже, чем не заводить.
+
+Признак тот же, что у деления на ветки, — раздельный откат. Один дефект планом не описывается:
+для него сразу заводится задача.
+
+Плана нет, а работа делится — сначала пишется план, показывается, и только после ответа
+владельца заводится первая задача. Ответ «делай» — тоже ответ; молчание им не является.
+
+## Сначала задача, потом ветка
+
+Заведение состоит из нескольких шагов: сама задача, номер в её заголовке, добавление в очередь,
+начальное состояние. Очередь к репозиторию обычно не привязана, поэтому добавление само не
+случается, и задача без него не видна ни в очереди, ни владельцу. Все шаги делает одна команда
+— не рука.
+
+Название задачи говорит, что не так, а не что сделать: PR потом переводит его в сделанное.
+Номер в заголовок руками не пишется — он известен только после создания.
+
+## Две задачи, которые чинятся одной правкой
+
+Если по ходу выяснилось, что правка закрывает и соседнюю задачу, — это одна задача, а не две.
+Слить их можно, пока правка не въехала в главную ветку: недостающее из поглощённой дописывается
+в тело первой, и только потом поглощённая закрывается и снимается с очереди. Порядок важен —
+удаление уносит с собой ссылки на неё из чужих тел.
+
+После слияния ветки поглощения нет: она въехала, и откатывается целиком.
+
+## Ветка заводится отдельным вызовом
+
+Гард главной ветки разбирает текст команды и смотрит ветку на момент запуска, поэтому составная
+команда отклоняется целиком — ветки в ней ещё нет:
+
+```bash
+✗ git checkout -b <ветка> && git commit -m '…'
+✓ git checkout -b <ветка>
+✓ git commit -F -
+```
+
+Имя ветки несёт номер задачи. Гард поставки разбирает его на месте и отбивает промах в форме до
+первого коммита, а по номеру спрашивает очередь: задача должна существовать, быть открытой,
+стоять в очереди и иметь исполнителя.
+
+Имя без номера законно, пока ветка живёт локально — под пробу и разбор. PR с неё не откроется:
+правка, доезжающая до главной ветки, начинается с задачи.
+
+## Колонка задачи двигается вместе с работой
+
+Ветка заведена — задача уже не в начальной колонке, а в работе. PR открыт — она ждёт разбора.
+Оба перевода делает одна команда, вторым вызовом сразу за тем, который его вызвал.
+
+Перевод не откладывается на потом: очередь читают между шагами, а не после них. Задача с
+открытым PR, простоявшая в начальной колонке, всё это время выглядела нетронутой — и разбора за
+неё никто не ждал.
+
+## Коммит подписывается учётной записью машинной работы
+
+Токен читается в переменную и не печатается; автор и коммиттер задаются переменными той же
+команды. Правка общей настройки здесь не годится — она переписала бы подпись владельцу:
+
+```bash
+TOKEN=$(tr -d '\n' < <файл с токеном>)
+
+GIT_AUTHOR_NAME="<бот>" GIT_AUTHOR_EMAIL="<адрес бота>" \
+GIT_COMMITTER_NAME="<бот>" GIT_COMMITTER_EMAIL="<адрес бота>" \
+    git commit -F -
+```
+
+Заголовок — `тип(область): описание`, без точки в конце. Набор типов и областей задан
+настройкой проверки заголовка.
+
+## Документ едет тем же коммитом
+
+Гард документов требует пару и называет её сам. Обход — строка в теле коммита, причина
+обязательна:
+
+```
+Docs-skip: правка только в сценариях хука, зеркала у него нет
+```
+
+## Номер задачи стоит в её заголовке и в заголовке PR
+
+Форма одна на оба. Номер стоит в самом заголовке, а не только в теле: в списке PR тела не
+видно. Тот же номер несёт и имя ветки — поэтому задача, ветка и PR читаются как одно.
+
+Задача говорит, что не так; PR тем же номером отчитывается, что сделано. Инфинитив из задачи в
+заголовок PR не переносится: «исправить» становится «исправлено».
+
+Тип и область коммита в заголовок PR не идут: род правки и область уже видны метками.
+
+## PR прикрепляется к задаче
+
+Тело начинается со строки связи с задачей — по ней в очереди заполняется поле связанных PR.
+Ревьювер, исполнитель и метки задаются той же командой, и PR без них не открывается.
+
+Ревьювер — всегда владелец: без запроса разбора PR не показывается ему в очереди. Метки берутся
+у задачи целиком — и род правки, и все её области; читаются они у задачи, а не выбираются по
+памяти.
+
+Строка связи обязательна: без неё PR не прикрепляется к задаче. Она же означает, что задача
+закрывается целиком — половину задачи одним PR не выкатывают: у задачи одна ветка, и работа,
+которая в неё не влезает, делится на задачи до того, как ветка заводится.
+
+Тело перечитывается всякий раз, когда в ветку что-то влилось после публикации: отчёт утверждает
+про дерево, а дерево с тех пор изменилось.
+
+## Что проверяется до публикации PR
+
+Проверок на самом PR нет: выкатка запускается пушем в главную ветку, и до слияния никто не
+гоняет ничего. Линтеры и юниты снимает гейт пуша — ниже то, чего он не знает.
+
+1. **В ветке только та правка, за которой её заводили** — сводка расхождения с главной веткой.
+   Чужой домен в списке файлов означает, что правка расползлась.
+2. **Ни мока, ни подменённого ответа, ни отладочной строки** — расхождение читается целиком, а
+   не по именам файлов. На прод они уезжают молча и портят настоящие данные.
+3. **Документ едет тем же коммитом.** Пару называет гард, но спек домена и правку его поведения
+   он не знает — это остаётся за автором.
+4. **Проверки текстов и раскладки зелёные.**
+5. **Все приложения собираются.** Гейт пуша сборку обычно не гоняет.
+6. **Видимый текст заведён во всех локалях.**
+7. **Правка вёрстки подтверждена замером**, а не взглядом, и снята при узком экране — паттерн
+   `browser-verification-measure`.
+8. **Правка публичной разметки проверена на прод-сборке по всем локалям** — паттерн
+   `seo-verify`.
+9. **Тело PR начинается строкой связи с задачей**, а метки, ревьювер и исполнитель стоят.
+10. **Заголовок PR несёт номер задачи и называет её сделанной** — тем же номером, что у задачи
+    и в имени ветки.
+11. **Очередь работ сходится.** Задача в очереди, с исполнителем и номером в заголовке; PR один
+    на задачу, и закрывает он её целиком.
+
+Сразу после публикации задача переставляется в разбор, и сверка очереди прогоняется ещё раз: до
+открытия PR колонку она не судит, а после открытия расхождение видит.
+
+Сделанное рассуждением и сделанное замером в теле PR разводятся прямо: непроверенное, названное
+проверенным, ревьювер принимает за проверенное.
+
+## Частые промахи
+
+- **Добавление в индекс нескольких путей не добавляет ничего, если хоть один путь не
+  существует.** Команда обрывается на первом промахе целиком, а следующая правка последнего
+  коммита уносит в него всё, что осталось в индексе. Состав коммита читается сразу после него,
+  а не на разборе PR.
+- **Задача, заведённая мимо команды, в очередь не попадает и гардом не отбивается** — он
+  смотрит команду, а не задачу. Ловится это только сверкой очереди.
+- **Исполнитель у задачи сам не проставляется** ни при заведении через веб, ни при добавлении в
+  очередь.
+- **Колонка сама не двигается** ни от заведения ветки, ни от открытия PR: очередь ветки не
+  видит вовсе, а связь с PR заполняет только поле связанных PR.
+- **Постраничный обход очереди через общий флаг уходит в повтор первой страницы** — курсор
+  берётся из ответа руками, а полнота сверяется с общим числом элементов.

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

@@ -0,0 +1,82 @@
+---
+name: git-workflow-merge
+kind: pattern
+rule: git-workflow
+description: Паттерн правила git-workflow. Брать, когда главная ветка вливается в ветку задачи и разрешается конфликт — порядок слияния, разбор конфликта по роду файла, сверка дописанного веткой с очередью работ, проверки после разрешения, перечитывание тела уже открытого PR. Не брать для заведения ветки, коммита и PR — это паттерн git-workflow-commit.
+---
+
+# Вливание главной ветки в ветку задачи
+
+Паттерн правила `git-workflow`. Что при этом должно быть верно — закон `{{lawsDir}}/delivery.md`.
+
+## Когда брать
+
+- PR отмечен конфликтующим, и его надо вернуть к сливаемому состоянию.
+- Главная ветка ушла вперёд, и ветку задачи надо подтянуть до проверок.
+- Коммит переносится отдельным выбором.
+
+## Порядок
+
+```bash
+git fetch origin
+git merge origin/<главная ветка> --no-edit
+git diff --name-only --diff-filter=U     # что встало конфликтом
+```
+
+Список конфликтов читается целиком до первого разрешения: род файла решает приём, и разные
+файлы одного слияния разрешаются по-разному.
+
+| Что встало конфликтом | Как разрешается                                                                |
+| --------------------- | ------------------------------------------------------------------------------ |
+| код                   | ловушка правила `git-workflow` про сторону-удаление; после — проверка повторов |
+| спек домена           | сохранением обеих сторон — правило `spec-driven`; после — проверка спеков      |
+| накопительный список  | признаком отбора — паттерн `doc-style-sweep`                                   |
+
+## Что дописала ветка, видно только от точки расхождения
+
+Конфликтный маркер показывает место, а не правку: сторона ветки в нём — её допись вместе со
+всем, что лежало в файле до неё.
+
+```bash
+git diff "$(git merge-base origin/<главная ветка> HEAD)" HEAD -- <файл>
+```
+
+## Дописанное веткой сверяется с очередью работ, а не переносится по умолчанию
+
+Раздел, который ветка дописала в накопительный список, к моменту слияния обычно уже стоит
+задачей: ветка живёт неделями, а замеченный по ходу дефект заводится задачей сразу. Перенести
+его второй раз — завести вторую запись об одной работе.
+
+Когда задача несёт то же содержание, сторона ветки не переносится:
+
+```bash
+git checkout --theirs <файл> && git add <файл>
+```
+
+При слиянии `--theirs` — влитая главная ветка, а `--ours` — ветка задачи; при перебазировании
+стороны меняются местами. Взятая не та сторона стирает работу молча.
+
+## Проверки после разрешения
+
+Конфликт в текстах кода не задевает, и зелёная сборка про него ничего не говорит:
+
+```bash
+grep -rn '^<<<<<<< \|^>>>>>>> ' --exclude-dir=node_modules --exclude-dir=.git .
+```
+
+Следом гоняются проверки текстов, раскладки, повторов и очереди работ, а если конфликт задел
+хуки — их сценарии. Коммит слияния подписывается так же, как любой другой, — паттерн
+`git-workflow-commit`. После пуша состояние читается у самого PR, а не по своему дереву.
+
+## Тело открытого PR перечитывается после слияния
+
+Отчёт описывал дерево на день, когда его написали. Вливание главной ветки меняет то, о чём он
+утверждает: тело говорит про записи, которые главная ветка к тому времени уже разобрала.
+
+## Частые промахи
+
+- «Сохранить обе стороны» применено ко всем файлам одинаково: в спеке это верно, в коде и в
+  накопительном списке — нет.
+- Сторона ветки перенесена без сверки с очередью работ: одна работа стала двумя записями.
+- После разрешения прогнана сборка, а проверки текстов — нет: конфликта в них сборке не видно.
+- Тело PR оставлено прежним: ревьювер читает утверждение о дереве, которого больше нет.

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

@@ -0,0 +1,58 @@
+---
+name: git-workflow-migration
+kind: pattern
+rule: git-workflow
+description: Паттерн правила git-workflow. Брать при правке схемы хранилища и каталога миграций — прогон цепочки на одноразовом хранилище, написание файла миграции разницей, догон локального хранилища. Не брать для коммита и PR — это паттерн git-workflow-commit.
+---
+
+# Миграция и прогон цепочки
+
+Паттерн правила `git-workflow`. Что при этом должно быть верно — закон `{{lawsDir}}/delivery.md`.
+
+## Когда брать
+
+- Правится схема хранилища.
+- Заводится или переименовывается каталог миграции.
+- Ветка с новой миграцией готовится к слиянию.
+
+## Цепочка гоняется на одноразовом хранилище
+
+Линтеры, тесты и сборки порядок миграций не трогают вовсе, а проверка соответствия схемы идёт
+уже после слияния. Поэтому ветка прогоняется до слияния на пустом хранилище:
+
+```bash
+docker run -d --rm --name <проба> -e <пароль> -p <порт>:<порт> <образ хранилища>
+docker exec <проба> <проверка готовности>   # накат до готовности падает на соединении
+<адрес хранилища> npx <инструмент> migrate deploy
+<адрес хранилища> npx <инструмент> migrate diff --from-config-datasource --to-schema <схема> --exit-code
+docker stop <проба>
+```
+
+Одноразовое хранилище, а не своё: гард запросов отбивает схемные команды, и завести базу под
+проверку иначе нечем. Адрес ставится префиксом самой команды — экспорт между вызовами не живёт.
+
+## Файл миграции пишется тем же хранилищем
+
+Команда разработчика для миграций не запускается: любое расхождение состояния она лечит
+предложением сбросить хранилище, а в локальном лежат данные владельца. Файл берётся разницей
+между накатанной цепочкой и схемой.
+
+Каталог заводится **после** наката цепочки: пустой каталог, попавший в накат, помечается
+применённым, и его содержимое на это хранилище уже не встанет.
+
+## Локальное хранилище догоняет ветку
+
+Переименованная миграция остаётся в нём под прежним именем, и накат падает на «объект уже
+существует». Состояние правится отметкой о применении, повторный накат его не чинит.
+
+## Частые промахи
+
+- Метку времени ставит момент создания, а порядок применения лексикографический: миграция из
+  ветки, начатой раньше, встаёт перед той, от которой зависит. На существующем хранилище это
+  незаметно — падает только накат с нуля.
+- Флаги инструмента не те, что в примерах из сети, и на неизвестный флаг он печатает справку, а
+  не строку ошибки. Какие флаги есть сейчас, смотрят в его собственной справке.
+- Запись в боевое хранилище запрещена совсем: схема меняется миграцией через выкатку, данные —
+  через интерфейс.
+- Строки адресуются по первичному ключу, а не по маске: удаление по маске уносит вместе с
+  пробными записями настоящие.

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

@@ -0,0 +1,49 @@
+---
+name: git-workflow-restart
+kind: pattern
+rule: git-workflow
+description: Паттерн правила git-workflow. Брать при ручном перезапуске прода — после правки окружения прода, при разборе выкатки, при подъёме контейнера на сервере. Команда с явным тегом образа по хешу коммита, способ узнать выкаченный хеш и чем сверять результат. Не брать для коммита и миграций — это паттерны git-workflow-commit и git-workflow-migration.
+---
+
+# Ручной перезапуск прода
+
+Паттерн правила `git-workflow`. Что при этом должно быть верно — закон `{{lawsDir}}/delivery.md`.
+
+## Когда брать
+
+- Правилось окружение прода, и контейнер надо поднять заново.
+- Разбирается, что именно сейчас выкачено.
+- Контейнер поднимается на сервере руками, мимо выкатки по слиянию.
+
+## Команда обязана нести хеш коммита
+
+Выкатка ставит образы по хешу коммита. Без явного тега подъём контейнера подставляет умолчание
+«последний», а оно в реестре отстаёт от главной ветки — прод молча откатывается на старый образ
+и при этом отвечает:
+
+```bash
+IMAGE_TAG='<хеш>' docker compose -f <состав прода> --env-file <окружение> pull <службы>
+IMAGE_TAG='<хеш>' docker compose -f <состав прода> --env-file <окружение> up -d --no-build --remove-orphans
+```
+
+## Хеш берётся до перезапуска
+
+У выкаченного контейнера или у последнего слияния в главную ветку:
+
+```bash
+docker inspect <контейнер> --format '{{.Config.Image}}'
+```
+
+## Сверка идёт по журналу, а не по коду ответа
+
+Подмена образа видна только по пропавшим строкам нового кода: сводка запуска из журнала
+исчезает, хотя строка «приложение поднялось» остаётся на месте. После перезапуска — тот же
+осмотр образа и наличие ожидаемых строк в журнале.
+
+## Частые промахи
+
+- Вывод «прод жив, значит выкатилось» — код ответа подмену образа не показывает.
+- Переменные окружения, секреты и записи имён ставятся **до** слияния: слияние выкатывает
+  сразу, и ветка, зависящая от новой переменной, встаёт на проде до того, как переменную
+  заведут.
+- Заход на сервер в автоматическом режиме режется правилом — нужен обычный.

package/assets/patterns/lib-layers-move.md

@@ -0,0 +1,77 @@
+---
+name: lib-layers-move
+kind: pattern
+rule: lib-layers
+description: Паттерн правила lib-layers. Брать при переносе кода или символа между либами — с чего начинать, в каком порядке двигать домены, куда кладётся общее, что делать с границами, импортами и README обеих либ, чем проверять. Заведение и удаление самой либы — паттерн lib-layers-new.
+---
+
+# Перенести код между либами
+
+Паттерн правила `lib-layers`. Что при этом должно быть верно — закон `{{lawsDir}}/lib-imports.md`.
+
+## Когда брать
+
+- Символ переезжает из одной либы в другую.
+- Домен переносится в новую раскладку.
+- Общий код собирается из копий в одно место.
+
+## Начинать с планов
+
+Решение о том, куда переезжает код, часто уже принято и записано, а принятое заново с ним
+расходится — и откатывать приходится целиком. Поиск по документам делается до первой правки:
+
+```bash
+grep -rn "<имя либы>" <каталог планов>/
+```
+
+## Порядок задаёт граф зависимостей, а не список в плане
+
+Домен переносится после всех, от кого он зависит. Списки доменов в планах отсортированы по
+важности, и следование им в лоб заставляет временно расширять границы — а каждая временная
+строка в границах и есть та механическая проверка, ради которой нарезка затевалась.
+
+```bash
+grep -rn "<алиас домена>" <каталоги кода> | sed 's/:.*//' | sort -u
+```
+
+Рёбра выписываются поиском по алиасам домена и сортируются топологически.
+
+## Куда именно кладётся общее
+
+Своя либа заводится тогда, когда ни одна существующая код не видит.
+
+| Кому нужно                                     | Куда                                                          |
+| ---------------------------------------------- | ------------------------------------------------------------- |
+| серверной стороне и фронту, без каркаса фронта | общая либа утилит                                             |
+| только фронтам, тянет каркас                   | либа платформы — служба и токен, либа общих компонентов — вид |
+| предмету, у которого уже есть либа             | в неё                                                         |
+| всем доменам одной семьи                       | основание семейства                                           |
+| всей серверной стороне                         | тот слой утилит, что уже перечислен у каждого домена          |
+
+Новых строк в границах при таком переезде не появляется — кроме права видеть контракт, если код
+его читает.
+
+## После переезда
+
+1. **README обеих либ.** У той, откуда файл ушёл, и у той, куда пришёл: README перечисляет, что
+   в либе лежит и кто её зовёт. Ни одна проверка эти тексты не читает.
+2. **Порядок импортов.** Переезд алиаса его ломает, и приходит это ошибкой линтера, а не
+   сборки. Автоправка есть только у линтера — в общий прогон с тестами и сборкой её флаг
+   передавать нельзя, падает весь вызов.
+3. **Линтер по всем затронутым проектам, а не по одному приложению.** Скрипт ошибается молча и
+   не так, как человек: строка импорта не переписывается, а исчезает целиком. Сборка одного
+   приложения до таких файлов не доходит — их находит только прогон по списку проектов.
+
+## Проверить
+
+Проверка раскладки — и обязательно проверка повторов: перенос и есть тот момент, когда копия
+остаётся на старом месте.
+
+## Частые промахи
+
+- Новый адрес выбран без чтения планов — расходится с уже принятым решением.
+- Порядок переноса взят из списка в плане — приходится временно расширять границы.
+- README поправлен только у одной либы.
+- Линтер прогнан по приложению, а не по списку затронутых проектов — пропавшие импорты не
+  видно.
+- Копия осталась на старом месте, а проверка повторов не гонялась.

package/assets/patterns/lib-layers-new.md

@@ -0,0 +1,70 @@
+---
+name: lib-layers-new
+kind: pattern
+rule: lib-layers
+description: Паттерн правила lib-layers. Брать при заведении, переименовании или удалении либы — нужна ли либа вообще, генератор вместо голого вызова каркаса, тег, алиас, барель, README, чем добивать удаление. Перенос кода между уже существующими либами — паттерн lib-layers-move.
+---
+
+# Завести или удалить либу
+
+Паттерн правила `lib-layers`. Что при этом должно быть верно — закон `{{lawsDir}}/lib-imports.md`.
+
+## Когда брать
+
+- Заводится новый домен или новый слой существующего домена.
+- Либа переименовывается.
+- Либа удаляется.
+
+## Сначала — нужна ли либа вообще
+
+У домена есть экраны, состояние и запросы. Механика, общая нескольким доменам, доменом не
+заводится: слои под неё останутся пустыми навсегда.
+
+Признак: если ни слой экранов, ни слой состояния, ни слой обращения к серверу наполнить не из
+чего — это утилиты, и им место в либе, которой они уже видны. У фронта такая либа есть всегда —
+основание семейства; у серверной стороны — тот слой утилит, что уже перечислен у каждого
+домена.
+
+Домен, заведённый под механику, живёт девятью либами на три файла кода: семь из них пустые, и у
+каждой свой манифест, свой конфиг прогонщика, барель, тег и алиас.
+
+## Заводится генератором, а не голым вызовом каркаса
+
+Генератор кладёт манифест, конфиг типов, конфиг прогонщика и барель разом. Голый вызов каркаса
+даёт конфиг прогонщика без настройки «успех при отсутствии тестов», и либа, у которой спек ещё
+нет, роняет общий прогон строкой «файлов тестов не найдено». Проверка раскладки смотрит на
+наличие файла, а не на его содержимое, поэтому такую либу она пропустит.
+
+## Что дописывается руками
+
+1. Тег в конфиге границ домена — один на либу, равный имени и пути.
+2. Алиас в конфиге путей.
+3. README либы: что в ней лежит и кто её зовёт.
+
+Права на чужие либы выписываются строками с комментарием, зачем. Импорт, который «просто
+заработал», означает, что тег ещё не сужен.
+
+## Удаление
+
+Удаление средствами гита оставляет за собой то, что гит не отслеживал, — кэш сборщика внутри
+удаляемого каталога, — и проверка раскладки продолжает видеть его как домен без слоёв.
+Добивается обычным удалением каталога.
+
+Следом снимаются тег, алиас и строки прав у тех, кто либу видел.
+
+## Проверить
+
+Проверка раскладки смотрит слои, единственный тег, равный имени и пути, алиас, наличие
+манифеста, конфига прогонщика и бареля, пустой список зависимостей у общей либы, границы
+основания семейства и реэкспорты. Она стоит секунды — гоняется после любого создания,
+переименования или удаления.
+
+## Частые промахи
+
+- **Либа заведена под механику:** слои пустые и заполнять их нечем.
+- **Голый вызов каркаса** — конфиг прогонщика без настройки «успех при отсутствии тестов», и
+  общий прогон краснеет.
+- **Удаление без добивания каталога** — проверка видит призрак домена без слоёв.
+- **Либа, которую никто не импортирует, не проверена ничем.** Линтер и тесты проверяют её саму,
+  а не договор с потребителем. Первый импортёр и есть первая проверка: слой моделей принимается
+  после сборки и живого прогона сценария, а не по зелёному линтеру с тестами.

package/assets/patterns/permissions-procedure.md

@@ -0,0 +1,69 @@
+---
+name: permissions-procedure
+kind: pattern
+rule: permissions
+description: Паттерн правила permissions. Брать при заведении обработчика серверной стороны и при закрытии раздела интерфейса — метки доступа, отбивка без входа и без права, декларация пункта меню с правом и признаком незавершённости.
+---
+
+# Объявление доступа
+
+Паттерн правила `permissions`. Что при этом должно быть верно — закон `{{lawsDir}}/access.md`.
+
+## Когда брать
+
+- Заводится обработчик серверной стороны.
+- Раздел интерфейса закрывается правом.
+- Обработчик должен отвечать гостю.
+
+## Метка на классе обработчика
+
+Объявление ровно одно; без него приложение не поднимается:
+
+```typescript
+@Injectable()
+@ConnectProcedure()
+@RequiresPermission('<ресурс>:<действие>')
+export class LinkEntityProcedure implements IConnectProcedure<typeof DomainService.method.linkEntity> {
+    public readonly method: typeof DomainService.method.linkEntity = DomainService.method.linkEntity;
+}
+```
+
+| Метка                            | Кому доступно                                     |
+| -------------------------------- | ------------------------------------------------- |
+| требование права                 | вошедшему с этим правом                           |
+| требование входа                 | любому вошедшему; так живут профиль и выбор языка |
+| публичный доступ                 | гостю без входа                                   |
+| публичный доступ с чтением входа | гостю, но токен читается, если он есть            |
+
+Аргумент — причина для читателя кода. Ни в ответ, ни в журнал она не уходит.
+
+## Отбивка
+
+Перехватчик отвечает до тела обработчика:
+
+- нет входа там, где вход нужен, — неаутентифицирован;
+- вход есть, права нет — отказ в доступе;
+- обработчик, о котором перехватчик ничего не знает, — тоже отказ, а не пропуск.
+
+Сам обработчик решения о допуске не принимает.
+
+## Раздел интерфейса
+
+Пункт меню и адрес закрываются одной декларацией: шапка берёт из неё подписи и адреса, страж —
+права. Второго объявления этой связи не заводится.
+
+Закрытие двухслойное: право пользователя и признак незавершённости раздела. Пункт с признаком
+объявляется без прав и без адреса — право открывает экран, а экрана нет. Появится экран —
+признак снимается, права добавляются.
+
+## Частые промахи
+
+- **Два объявления доступа на одном обработчике:** приложение не поднимется, и увидено это
+  будет только при запуске.
+- **Проверка права внутри тела:** право проверяется до тела.
+- **Своё объявление прав рядом с маршрутами:** оно разойдётся с декларацией меню, и получится
+  «пункта не видно, а страница открывается».
+- **Страж, повешенный на защищённую группу целиком:** он отрабатывает один раз за загрузку
+  страницы и переходов между разделами не видит.
+- **Ожидание прав, которое роняется на отказе запроса:** с неизвестными правами не закрывается
+  ничего, и пустая шапка выхода владельцу не оставляет.