@rt-tools/agent-kit 0.3.0 → 0.5.0

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

@@ -2,35 +2,36 @@
 name: git-workflow-merge
 kind: pattern
 rule: git-workflow
-description: Паттерн правила git-workflow. Брать, когда главная ветка вливается в ветку задачи и разрешается конфликт — порядок слияния, разбор конфликта по роду файла, сверка дописанного веткой с очередью работ, проверки после разрешения, перечитывание тела уже открытого PR. Не брать для заведения ветки, коммита и PR — это паттерн git-workflow-commit.
+description: Паттерн правила git-workflow. Брать, когда главная ветка вливается в ветку задачи и разрешается конфликт — порядок мержа, разбор конфликта по роду файла, сверка дописанного веткой с очередью работ, проверки после разрешения, перечитывание тела уже открытого PR. Не брать для заведения ветки, коммита и PR — это паттерн git-workflow-commit.
 ---
 
-# Вливание главной ветки в ветку задачи
+# Мерж главной ветки в ветку задачи
 
-Паттерн правила `git-workflow`. Что при этом должно быть верно — закон `{{lawsDir}}/delivery.md`.
+Паттерн правила `git-workflow`. Что при этом должно быть верно — закон
+`docs/constitution/delivery.md`.
 
 ## Когда брать
 
 - PR отмечен конфликтующим, и его надо вернуть к сливаемому состоянию.
 - Главная ветка ушла вперёд, и ветку задачи надо подтянуть до проверок.
-- Коммит переносится отдельным выбором.
+- Коммит переносится черри-пиком.
 
 ## Порядок
 
 ```bash
 git fetch origin
-git merge origin/<главная ветка> --no-edit
+git merge origin/main --no-edit
 git diff --name-only --diff-filter=U     # что встало конфликтом
 ```
 
 Список конфликтов читается целиком до первого разрешения: род файла решает приём, и разные
-файлы одного слияния разрешаются по-разному.
+файлы одного мержа разрешаются по-разному.
 
-| Что встало конфликтом | Как разрешается                                                                |
-| --------------------- | ------------------------------------------------------------------------------ |
-| код                   | ловушка правила `git-workflow` про сторону-удаление; после — проверка повторов |
-| спек домена           | сохранением обеих сторон — правило `spec-driven`; после — проверка спеков      |
-| накопительный список  | признаком отбора — паттерн `doc-style-sweep`                                   |
+| Что встало конфликтом            | Как разрешается                                                                    |
+| -------------------------------- | ---------------------------------------------------------------------------------- |
+| код                              | ловушка правила `git-workflow` про сторону-удаление; после — `npm run check:dupes` |
+| спек в `docs/specs/`             | сохранением обеих сторон — правило `spec-driven`; после — `npm run check:specs`    |
+| список работ (`docs/BACKLOG.md`) | признаком отбора — паттерн `doc-style-sweep`                                       |
 
 ## Что дописала ветка, видно только от точки расхождения
 
@@ -38,22 +39,27 @@ git diff --name-only --diff-filter=U     # что встало конфликт
 всем, что лежало в файле до неё.
 
 ```bash
-git diff "$(git merge-base origin/<главная ветка> HEAD)" HEAD -- <файл>
+git diff "$(git merge-base origin/main HEAD)" HEAD -- docs/BACKLOG.md
 ```
 
 ## Дописанное веткой сверяется с очередью работ, а не переносится по умолчанию
 
-Раздел, который ветка дописала в накопительный список, к моменту слияния обычно уже стоит
-задачей: ветка живёт неделями, а замеченный по ходу дефект заводится задачей сразу. Перенести
-его второй раз — завести вторую запись об одной работе.
+Раздел, который ветка дописала в список работ, к моменту мержа обычно уже стоит задачей:
+ветка живёт неделями, а замеченный по ходу дефект заводится задачей сразу. Перенести его
+второй раз — завести вторую запись об одной работе.
 
-Когда задача несёт то же содержание, сторона ветки не переносится:
+```bash
+/opt/homebrew/bin/gh issue list --state all --limit 400 --search '<слова из раздела>' \
+    --json number,title,state
+```
+
+Задача несёт то же содержание — сторона ветки не переносится:
 
 ```bash
-git checkout --theirs <файл> && git add <файл>
+git checkout --theirs docs/BACKLOG.md && git add docs/BACKLOG.md
 ```
 
-При слиянии `--theirs` — влитая главная ветка, а `--ours` — ветка задачи; при перебазировании
+В мерже `--theirs` — влитая главная ветка, а `--ours` — ветка задачи; при перебазировании
 стороны меняются местами. Взятая не та сторона стирает работу молча.
 
 ## Проверки после разрешения
@@ -62,21 +68,32 @@ git checkout --theirs <файл> && git add <файл>
 
 ```bash
 grep -rn '^<<<<<<< \|^>>>>>>> ' --exclude-dir=node_modules --exclude-dir=.git .
+npm run check:docs && npm run check:specs && npm run check:dupes && npm run check:board
+bash .claude/hooks/tests/run.sh       # если конфликт задел хуки
 ```
 
-Следом гоняются проверки текстов, раскладки, повторов и очереди работ, а если конфликт задел
-хуки — их сценарии. Коммит слияния подписывается так же, как любой другой, — паттерн
-`git-workflow-commit`. После пуша состояние читается у самого PR, а не по своему дереву.
+Коммит мержа подписывается ботом тем же способом, что и любой другой, — паттерн
+`git-workflow-commit`. После пуша состояние читается у самого PR, а не по своему дереву:
 
-## Тело открытого PR перечитывается после слияния
+```bash
+/opt/homebrew/bin/gh pr view <номер> --json mergeable,mergeStateStatus
+```
 
-Отчёт описывал дерево на день, когда его написали. Вливание главной ветки меняет то, о чём он
-утверждает: тело говорит про записи, которые главная ветка к тому времени уже разобрала.
+## Тело открытого PR перечитывается после мержа
+
+Отчёт описывал дерево на день, когда его написали. Мерж главной ветки меняет то, о чём он
+утверждает: тело говорило, что оба дефекта заведены в `docs/BACKLOG.md`, а главная ветка этот
+список к тому времени разобрала. Правится тело вызовом REST — `gh pr edit` в этом репозитории
+отвечает отказом про Projects (classic) и до правки не доходит:
+
+```bash
+/opt/homebrew/bin/gh api -X PATCH repos/<владелец>/<репозиторий>/pulls/<номер> -f body="$(cat тело.md)"
+```
 
 ## Частые промахи
 
 - «Сохранить обе стороны» применено ко всем файлам одинаково: в спеке это верно, в коде и в
-  накопительном списке — нет.
+  списке работ — нет.
 - Сторона ветки перенесена без сверки с очередью работ: одна работа стала двумя записями.
 - После разрешения прогнана сборка, а проверки текстов — нет: конфликта в них сборке не видно.
 - Тело PR оставлено прежним: ревьювер читает утверждение о дереве, которого больше нет.

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

@@ -2,57 +2,87 @@
 name: git-workflow-migration
 kind: pattern
 rule: git-workflow
-description: Паттерн правила git-workflow. Брать при правке схемы хранилища и каталога миграций — прогон цепочки на одноразовом хранилище, написание файла миграции разницей, догон локального хранилища. Не брать для коммита и PR — это паттерн git-workflow-commit.
+description: Паттерн правила git-workflow. Брать при правке prisma/schema.prisma и prisma/migrations/** — готовые команды одноразового контейнера, написание файла миграции через migrate diff, накат локальной базы. Не брать для коммита и PR — это паттерн git-workflow-commit.
 ---
 
 # Миграция и прогон цепочки
 
-Паттерн правила `git-workflow`. Что при этом должно быть верно — закон `{{lawsDir}}/delivery.md`.
+Паттерн правила `git-workflow`. Что при этом должно быть верно — закон
+`docs/constitution/delivery.md`.
 
 ## Когда брать
 
-- Правится схема хранилища.
-- Заводится или переименовывается каталог миграции.
-- Ветка с новой миграцией готовится к слиянию.
+- Правится `prisma/schema.prisma`.
+- Заводится или переименовывается каталог в `prisma/migrations/`.
+- Ветка с новой миграцией готовится к мержу.
 
-## Цепочка гоняется на одноразовом хранилище
+## Цепочка гоняется одной командой
 
-Линтеры, тесты и сборки порядок миграций не трогают вовсе, а проверка соответствия схемы идёт
-уже после слияния. Поэтому ветка прогоняется до слияния на пустом хранилище:
+Локальные `lint`, `test`, `check:all` и сборки порядок миграций не трогают вовсе, а шаг
+`Migrations match schema` в `.github/workflows/deploy.yml` идёт уже после мержа. Проверка
+стоит гейтом пуша и зовётся руками:
 
 ```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 <проба>
+npm run check:schema
 ```
 
-Одноразовое хранилище, а не своё: гард запросов отбивает схемные команды, и завести базу под
-проверку иначе нечем. Адрес ставится префиксом самой команды — экспорт между вызовами не живёт.
+Она накатывает цепочку на теневую базу — ту же, что рабочая, с суффиксом `_gate_shadow`, —
+сравнивает её со схемой и сносит. Своя база при этом не трогается: сверка с ней судила бы о
+состоянии машины, а не репозитория. Погашенный докер и боевой адрес проверка пропускает
+молча.
 
-## Файл миграции пишется тем же хранилищем
+Когда базы под рукой нет вовсе, та же цепочка гоняется на одноразовом контейнере:
 
-Команда разработчика для миграций не запускается: любое расхождение состояния она лечит
-предложением сбросить хранилище, а в локальном лежат данные владельца. Файл берётся разницей
-между накатанной цепочкой и схемой.
+```bash
+docker run -d --rm --name <префикс>-migcheck -e POSTGRES_PASSWORD=migcheck -p 55432:5432 postgres:16-alpine
+docker exec <префикс>-migcheck pg_isready -U postgres          # накат до готовности падает на соединении
+DATABASE_URL=postgresql://postgres:migcheck@localhost:55432/postgres npx prisma migrate deploy
+DATABASE_URL=postgresql://postgres:migcheck@localhost:55432/postgres npx prisma migrate diff \
+    --from-config-datasource --to-schema prisma/schema.prisma --exit-code
+docker stop <префикс>-migcheck
+```
+
+Адрес ставится префиксом самой команды — `export` между вызовами не живёт.
+
+## Файл миграции пишется тем же контейнером
+
+`prisma migrate dev` не запускается ни командой, ни через `npm run prisma:migrate`: любое
+расхождение состояния он лечит предложением сбросить базу, а в локальной базе лежат объекты и
+брони владельца. Файл берётся разницей между накатанной цепочкой и схемой:
+
+```bash
+DATABASE_URL=postgresql://postgres:migcheck@localhost:55432/postgres npx prisma migrate diff \
+    --from-config-datasource --to-schema prisma/schema.prisma --script \
+    > prisma/migrations/<метка>_<имя>/migration.sql
+```
+
+Каталог заводится **после** наката цепочки: пустой каталог, попавший в `migrate deploy`,
+помечается применённым, и его содержимое на этот контейнер уже не встанет.
 
-Каталог заводится **после** наката цепочки: пустой каталог, попавший в накат, помечается
-применённым, и его содержимое на это хранилище уже не встанет.
+## Локальная база догоняет ветку
 
-## Локальное хранилище догоняет ветку
+```bash
+npx prisma migrate deploy
+```
 
-Переименованная миграция остаётся в нём под прежним именем, и накат падает на «объект уже
-существует». Состояние правится отметкой о применении, повторный накат его не чинит.
+Переименованная миграция остаётся в ней под прежним именем, и накат падает на
+`relation … already exists`. Состояние правится, повторный накат его не чинит:
+
+```bash
+npx prisma migrate resolve --applied <новое имя>
+```
 
 ## Частые промахи
 
 - Метку времени ставит момент создания, а порядок применения лексикографический: миграция из
-  ветки, начатой раньше, встаёт перед той, от которой зависит. На существующем хранилище это
+  ветки, начатой раньше, встаёт перед той, от которой зависит. На существующей базе это
   незаметно — падает только накат с нуля.
-- Флаги инструмента не те, что в примерах из сети, и на неизвестный флаг он печатает справку, а
-  не строку ошибки. Какие флаги есть сейчас, смотрят в его собственной справке.
-- Запись в боевое хранилище запрещена совсем: схема меняется миграцией через выкатку, данные —
-  через интерфейс.
-- Строки адресуются по первичному ключу, а не по маске: удаление по маске уносит вместе с
-  пробными записями настоящие.
+- Флаги `prisma migrate diff` не те, что в примерах из сети: `--from-url`, `--to-url`,
+  `--shadow-database-url` и `--to-schema-datamodel` сняты, а `prisma db execute` адреса
+  базы не принимает вовсе и берёт его из `prisma.config.ts`. На неизвестный флаг обе команды
+  печатают справку, и промах виден только в ней. Какие флаги есть сейчас, смотрят в
+  `prisma migrate diff --help`, а не в этом тексте.
+- Запись в боевую базу (порт 15432, прод-хост) запрещена совсем: схема меняется миграцией
+  через деплой, данные — через админку.
+- Строки адресуются по первичному ключу, а не по маске: удаление по маске почты однажды унесло
+  вместе с тестовыми записями демонстрационные брони владельца.

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

@@ -2,48 +2,48 @@
 name: git-workflow-restart
 kind: pattern
 rule: git-workflow
-description: Паттерн правила git-workflow. Брать при ручном перезапуске прода — после правки окружения прода, при разборе выкатки, при подъёме контейнера на сервере. Команда с явным тегом образа по хешу коммита, способ узнать выкаченный хеш и чем сверять результат. Не брать для коммита и миграций — это паттерны git-workflow-commit и git-workflow-migration.
+description: Паттерн правила git-workflow. Брать при ручном перезапуске прода — после правки .env.prod, при разборе выкатки, при подъёме контейнера на сервере. Готовые команды с IMAGE_TAG по sha, способ узнать выкаченный sha и чем сверять результат. Не брать для коммита и миграций — это паттерны git-workflow-commit и git-workflow-migration.
 ---
 
 # Ручной перезапуск прода
 
-Паттерн правила `git-workflow`. Что при этом должно быть верно — закон `{{lawsDir}}/delivery.md`.
+Паттерн правила `git-workflow`. Что при этом должно быть верно — закон
+`docs/constitution/delivery.md`.
 
 ## Когда брать
 
-- Правилось окружение прода, и контейнер надо поднять заново.
+- Правился `.env.prod` и контейнер надо поднять заново.
 - Разбирается, что именно сейчас выкачено.
-- Контейнер поднимается на сервере руками, мимо выкатки по слиянию.
+- Контейнер поднимается на сервере руками, мимо выкатки по мержу.
 
-## Команда обязана нести хеш коммита
+## Команда обязана нести sha
 
-Выкатка ставит образы по хешу коммита. Без явного тега подъём контейнера подставляет умолчание
-«последний», а оно в реестре отстаёт от главной ветки — прод молча откатывается на старый образ
-и при этом отвечает:
+`.github/workflows/deploy.yml` выкатывает образы по sha коммита. Без переменной `docker
+compose` подставляет умолчание `latest`, а `latest` в реестре отстаёт от главной ветки — прод
+молча откатывается на старый образ и при этом отвечает:
 
 ```bash
-IMAGE_TAG='<хеш>' docker compose -f <состав прода> --env-file <окружение> pull <службы>
-IMAGE_TAG='<хеш>' docker compose -f <состав прода> --env-file <окружение> up -d --no-build --remove-orphans
+IMAGE_TAG='<sha>' docker compose -f docker-compose.prod.yml --env-file .env.prod pull migrate api ssr web
+IMAGE_TAG='<sha>' docker compose -f docker-compose.prod.yml --env-file .env.prod up -d --no-build --remove-orphans
 ```
 
-## Хеш берётся до перезапуска
+## Sha берётся до перезапуска
 
-У выкаченного контейнера или у последнего слияния в главную ветку:
+У выкаченного контейнера или у последнего мержа в главную ветку:
 
 ```bash
 docker inspect <контейнер> --format '{{.Config.Image}}'
 ```
 
-## Сверка идёт по журналу, а не по коду ответа
+## Сверка идёт по логу, а не по коду ответа
 
-Подмена образа видна только по пропавшим строкам нового кода: сводка запуска из журнала
-исчезает, хотя строка «приложение поднялось» остаётся на месте. После перезапуска — тот же
-осмотр образа и наличие ожидаемых строк в журнале.
+Подмена образа видна только по пропавшим строкам нового кода: сводка `startup` с
+`integrations` из логов исчезает, хотя `API is running` остаётся на месте. После перезапуска —
+тот же `inspect` и наличие ожидаемых строк в логе.
 
 ## Частые промахи
 
 - Вывод «прод жив, значит выкатилось» — код ответа подмену образа не показывает.
-- Переменные окружения, секреты и записи имён ставятся **до** слияния: слияние выкатывает
-  сразу, и ветка, зависящая от новой переменной, встаёт на проде до того, как переменную
-  заведут.
-- Заход на сервер в автоматическом режиме режется правилом — нужен обычный.
+- Переменные окружения, секреты и записи имён ставятся **до** мержа: мерж выкатывает сразу,
+  и ветка, зависящая от новой переменной, встаёт на проде до того, как переменную заведут.
+- Заход на сервер по ssh в автоматическом режиме режется правилом — нужен обычный режим.

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

@@ -2,12 +2,13 @@
 name: lib-layers-move
 kind: pattern
 rule: lib-layers
-description: Паттерн правила lib-layers. Брать при переносе кода или символа между либами — с чего начинать, в каком порядке двигать домены, куда кладётся общее, что делать с границами, импортами и README обеих либ, чем проверять. Заведение и удаление самой либы — паттерн lib-layers-new.
+description: Паттерн правила lib-layers. Брать при переносе кода или символа между либами — с чего начинать, в каком порядке двигать домены, что делать с границами, импортами и README обеих либ, и чем проверять. Заведение и удаление самой либы — паттерн lib-layers-new.
 ---
 
 # Перенести код между либами
 
-Паттерн правила `lib-layers`. Что при этом должно быть верно — закон `{{lawsDir}}/lib-imports.md`.
+Паттерн правила `lib-layers`. Что при этом должно быть верно — закон
+`docs/constitution/lib-imports.md`.
 
 ## Когда брать
 
@@ -15,63 +16,80 @@ description: Паттерн правила lib-layers. Брать при пер
 - Домен переносится в новую раскладку.
 - Общий код собирается из копий в одно место.
 
-## Начинать с планов
-
-Решение о том, куда переезжает код, часто уже принято и записано, а принятое заново с ним
-расходится — и откатывать приходится целиком. Поиск по документам делается до первой правки:
+## Начинать с `docs/plans/`
 
 ```bash
-grep -rn "<имя либы>" <каталог планов>/
+grep -rn "<имя либы>" docs/
 ```
 
+Решение о том, куда переезжает код, часто уже принято и записано, а принятое заново с ним
+расходится. Перенос утилит списка из-за этого делался дважды: первая редакция положила их в
+`libs/common/util`, что запрещено первым же пунктом того самого плана, и её пришлось
+откатывать целиком.
+
 ## Порядок задаёт граф зависимостей, а не список в плане
 
 Домен переносится после всех, от кого он зависит. Списки доменов в планах отсортированы по
-важности, и следование им в лоб заставляет временно расширять границы — а каждая временная
-строка в границах и есть та механическая проверка, ради которой нарезка затевалась.
+важности, и следование им в лоб заставляет временно расширять границы.
 
 ```bash
-grep -rn "<алиас домена>" <каталоги кода> | sed 's/:.*//' | sort -u
+grep -rn "@<область>/<семья>/<домен>" libs/ apps/ | sed 's/:.*//' | sort -u
 ```
 
-Рёбра выписываются поиском по алиасам домена и сортируются топологически.
+Рёбра выписываются грепом по алиасам домена и сортируются топологически. Каждая временная
+строка в границах — это ослабленная механическая проверка, ради которой нарезка и затевалась.
 
 ## Куда именно кладётся общее
 
 Своя либа заводится тогда, когда ни одна существующая код не видит.
 
-| Кому нужно                                     | Куда                                                          |
-| ---------------------------------------------- | ------------------------------------------------------------- |
-| серверной стороне и фронту, без каркаса фронта | общая либа утилит                                             |
-| только фронтам, тянет каркас                   | либа платформы — служба и токен, либа общих компонентов — вид |
-| предмету, у которого уже есть либа             | в неё                                                         |
-| всем доменам одной семьи                       | основание семейства                                           |
-| всей серверной стороне                         | тот слой утилит, что уже перечислен у каждого домена          |
+| Кому нужно                             | Куда                                                        |
+| -------------------------------------- | ----------------------------------------------------------- |
+| бэкенду или обоим фронтам, без Angular | `libs/common/util`                                          |
+| только фронтам, тянет Angular          | `common/platform` — сервис и токен, `common/ui` — компонент |
+| предмету, у которого уже есть либа     | в неё: `site-routing`, `i18n`, `photo`, `captcha`           |
+| всем доменам одной семьи               | основание семейства `<семья>/core`                          |
+| всему бэкенду                          | тот слой `util`, что уже перечислен у каждого домена        |
 
-Новых строк в границах при таком переезде не появляется — кроме права видеть контракт, если код
-его читает.
+Новых строк в границах при таком переезде не появляется — кроме права видеть контракт, если
+код его читает.
 
 ## После переезда
 
 1. **README обеих либ.** У той, откуда файл ушёл, и у той, куда пришёл: README перечисляет, что
    в либе лежит и кто её зовёт. Ни одна проверка эти тексты не читает.
-2. **Порядок импортов.** Переезд алиаса его ломает, и приходит это ошибкой линтера, а не
-   сборки. Автоправка есть только у линтера — в общий прогон с тестами и сборкой её флаг
-   передавать нельзя, падает весь вызов.
-3. **Линтер по всем затронутым проектам, а не по одному приложению.** Скрипт ошибается молча и
-   не так, как человек: строка импорта не переписывается, а исчезает целиком. Сборка одного
-   приложения до таких файлов не доходит — их находит только прогон по списку проектов.
+2. **Порядок импортов.** Переезд алиаса его ломает, и приходит это ошибкой `prettier/prettier`
+   из линта, а не из сборки:
+
+    ```bash
+    npx nx lint <project> --fix
+    ```
+
+    Флага `--fix` нет у `test` и `build`, поэтому в `run-many -t lint test` его передавать
+    нельзя — падает весь вызов.
+
+3. **Линт по всем затронутым проектам, а не по одному приложению.** Скрипт ошибается молча и не
+   так, как человек: строка импорта не переписывается, а исчезает целиком. При переносе утилит
+   списка так пропали импорты в шести файлах из восьми, и нашёл их прогон по списку проектов —
+   сборка одного приложения до этих файлов не дошла.
+
+    ```bash
+    npx nx run-many -t lint --projects=<список по изменённым файлам>
+    ```
 
 ## Проверить
 
-Проверка раскладки — и обязательно проверка повторов: перенос и есть тот момент, когда копия
-остаётся на старом месте.
+```bash
+npm run check:layers
+npm run check:dupes
+```
+
+Второе обязательно: перенос и есть тот момент, когда копия остаётся на старом месте.
 
 ## Частые промахи
 
-- Новый адрес выбран без чтения планов — расходится с уже принятым решением.
+- Новый адрес выбран без чтения `docs/plans/` — расходится с уже принятым решением.
 - Порядок переноса взят из списка в плане — приходится временно расширять границы.
 - README поправлен только у одной либы.
-- Линтер прогнан по приложению, а не по списку затронутых проектов — пропавшие импорты не
-  видно.
-- Копия осталась на старом месте, а проверка повторов не гонялась.
+- Линт прогнан по приложению, а не по списку затронутых проектов — пропавшие импорты не видно.
+- Копия осталась на старом месте, а `check:dupes` не гонялся.

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

@@ -2,12 +2,13 @@
 name: lib-layers-new
 kind: pattern
 rule: lib-layers
-description: Паттерн правила lib-layers. Брать при заведении, переименовании или удалении либы — нужна ли либа вообще, генератор вместо голого вызова каркаса, тег, алиас, барель, README, чем добивать удаление. Перенос кода между уже существующими либами — паттерн lib-layers-move.
+description: Паттерн правила lib-layers. Брать при заведении, переименовании или удалении либы — генератор вместо голого nx g, тег, алиас, барель, README, и чем добивать удаление. Перенос кода между уже существующими либами — паттерн lib-layers-move.
 ---
 
 # Завести или удалить либу
 
-Паттерн правила `lib-layers`. Что при этом должно быть верно — закон `{{lawsDir}}/lib-imports.md`.
+Паттерн правила `lib-layers`. Что при этом должно быть верно — закон
+`docs/constitution/lib-imports.md`.
 
 ## Когда брать
 
@@ -20,25 +21,29 @@ description: Паттерн правила lib-layers. Брать при зав
 У домена есть экраны, состояние и запросы. Механика, общая нескольким доменам, доменом не
 заводится: слои под неё останутся пустыми навсегда.
 
-Признак: если ни слой экранов, ни слой состояния, ни слой обращения к серверу наполнить не из
-чего — это утилиты, и им место в либе, которой они уже видны. У фронта такая либа есть всегда —
-основание семейства; у серверной стороны — тот слой утилит, что уже перечислен у каждого
-домена.
+Признак: если ни `feature`, ни `data-access`, ни `api` наполнить не из чего — это утилиты, и
+им место в либе, которой они уже видны. У фронта такая либа есть всегда — основание семейства;
+у бэкенда — тот слой `util`, что уже перечислен у каждого домена.
 
-Домен, заведённый под механику, живёт девятью либами на три файла кода: семь из них пустые, и у
-каждой свой манифест, свой конфиг прогонщика, барель, тег и алиас.
+Так домен `list` жил девятью либами на три файла кода: семь либ пустых, и у каждой свои
+`project.json`, `vitest.config.mts`, барель, тег и алиас.
 
-## Заводится генератором, а не голым вызовом каркаса
+## Заводится генератором, а не голым `nx g`
 
-Генератор кладёт манифест, конфиг типов, конфиг прогонщика и барель разом. Голый вызов каркаса
-даёт конфиг прогонщика без настройки «успех при отсутствии тестов», и либа, у которой спек ещё
-нет, роняет общий прогон строкой «файлов тестов не найдено». Проверка раскладки смотрит на
-наличие файла, а не на его содержимое, поэтому такую либу она пропустит.
+```bash
+node tools/generate-domain-lib.mjs
+```
+
+Генератор кладёт `project.json`, `tsconfig.json`, `vitest.config.mts` и барель. Голый `nx g`
+даёт конфиг vitest без `passWithNoTests`, и либа, у которой спек ещё нет, роняет
+`nx run-many -t test` строкой «No test files found». Проверка раскладки смотрит на наличие
+файла, а не на его содержимое, поэтому такую либу она пропустит.
 
 ## Что дописывается руками
 
-1. Тег в конфиге границ домена — один на либу, равный имени и пути.
-2. Алиас в конфиге путей.
+1. Тег в `eslint/boundaries/domains/<семья>-<домен>.config.mjs` — один на либу, равный имени и
+   пути.
+2. Алиас в `tsconfig.base.json`.
 3. README либы: что в ней лежит и кто её зовёт.
 
 Права на чужие либы выписываются строками с комментарием, зачем. Импорт, который «просто
@@ -46,25 +51,32 @@ description: Паттерн правила lib-layers. Брать при зав
 
 ## Удаление
 
-Удаление средствами гита оставляет за собой то, что гит не отслеживал, — кэш сборщика внутри
-удаляемого каталога, — и проверка раскладки продолжает видеть его как домен без слоёв.
-Добивается обычным удалением каталога.
+```bash
+git rm -r libs/<семья>/<домен>/<слой>
+rm -rf libs/<семья>/<домен>/<слой>
+```
+
+`git rm -r` оставляет за собой `node_modules/.vite` внутри удаляемого каталога, и проверка
+раскладки продолжает видеть его как домен без слоёв. Добивать `rm -rf`.
 
 Следом снимаются тег, алиас и строки прав у тех, кто либу видел.
 
 ## Проверить
 
-Проверка раскладки смотрит слои, единственный тег, равный имени и пути, алиас, наличие
-манифеста, конфига прогонщика и бареля, пустой список зависимостей у общей либы, границы
-основания семейства и реэкспорты. Она стоит секунды — гоняется после любого создания,
-переименования или удаления.
+```bash
+npm run check:layers
+```
+
+Проверка смотрит слои, единственный тег = имя = путь, алиас, наличие `project.json`,
+`vitest.config.mts` и `src/index.ts`, пустой список зависимостей у `common/util`, границы
+основания семейства и реэкспорты. Секунды — гонять после любого создания, переименования или
+удаления.
 
 ## Частые промахи
 
-- **Либа заведена под механику:** слои пустые и заполнять их нечем.
-- **Голый вызов каркаса** — конфиг прогонщика без настройки «успех при отсутствии тестов», и
-  общий прогон краснеет.
-- **Удаление без добивания каталога** — проверка видит призрак домена без слоёв.
-- **Либа, которую никто не импортирует, не проверена ничем.** Линтер и тесты проверяют её саму,
-  а не договор с потребителем. Первый импортёр и есть первая проверка: слой моделей принимается
-  после сборки и живого прогона сценария, а не по зелёному линтеру с тестами.
+- Либа заведена под механику: слои пустые и заполнять их нечем.
+- Голый `nx g` — конфиг vitest без `passWithNoTests`, и общий прогон тестов краснеет.
+- Удаление без `rm -rf` — проверка видит призрак домена без слоёв.
+- **Либа, которую никто не импортирует, не проверена ничем.** `nx lint` и `nx test` проверяют
+  её саму, а не договор с потребителем. Первый импортёр и есть первая проверка: слой моделей
+  принимается после `nx build` и живого прогона сценария, а не по зелёному `lint test`.