@rt-tools/agent-kit 0.14.0 → 0.16.0

package/assets/rules/api-layer.md

@@ -2,7 +2,7 @@
 name: api-layer
 kind: rule
 law: frontend-application
-description: Правило под «Закон о фронтовом приложении». Брать при правке слоя api фронтового домена — *-api.facade.ts, *-api.service.ts и мапперов в его mappers/ под libs/admin и libs/site. Называет пару «фасад и сервис», один вход выборки у списка и общий конвертер страницы. Готовый код — в паттерне api-layer-pair.
+description: Правило под «Закон о фронтовом приложении». Брать при правке слоя api фронтового домена — фасада, сервиса и мапперов при них. Называет пару «фасад и сервис», один вход выборки у списка и общий конвертер страницы. Паттерн api-layer-pair.
 ---
 
 # Обращение к серверу — как это устроено здесь
@@ -90,7 +90,7 @@ flowchart TD
 - **Одна пара — одна сущность.** У объекта, его прежних адресов и подписок на календари свои
   пары, хотя процедуры лежат в одном proto-сервисе.
 - **Метод, которого у домена нет, не объявляется.** Список читают все, правят не все.
-- **Серверный стрим — исключение из правила про поток:** живой срез аналитики и лента тредов
-  приходят асинхронным итератором, и заворачивать его некуда.
+- **Серверный стрим — исключение из правила про поток:** живой срез показателей и лента входящих
+  записей приходят асинхронным итератором, и заворачивать его некуда.
 - Своей копии общих мапперов страницы, порядка и отбора домен не заводит — второй экземпляр
   ловит `npm run check:dupes`.

package/assets/rules/browser-verification.md

@@ -2,7 +2,7 @@
 name: browser-verification
 kind: rule
 law: verifiability
-description: Правило под «Закон о проверяемости». Брать при любой проверке через браузер и при запросах curl или wget к дев-серверу. Называет, где подняты приложения дерева, чему на дев-сервере верить нельзя и чем измерять вместо взгляда. Готовый код — в паттернах browser-verification-stand и browser-verification-measure.
+description: Правило под «Закон о проверяемости». Брать при любой проверке через браузер и при запросах к дев-серверу. Называет, где подняты приложения дерева, чему на дев-сервере верить нельзя и чем измерять вместо взгляда. Паттерны: browser-verification-stand, -measure.
 ---
 
 # Проверка работающего приложения — как это устроено здесь
@@ -71,6 +71,14 @@ flowchart TD
   сессии, не держится: после паузы следующий вызов открывает вкладку в другом профиле молча.
 - **Профиль не выбирается из списка и не спрашивается у владельца.** Список отдаёт неустойчивые
   имена, которые не опознают ничего, а выбор из него ведёт на профиль без входа.
+- **Замер делается на самом длинном значении, а не на образцовом.** Наезд, вылезание за край и
+  обрезка без признака видны только там, где содержимое в своё место не влезает; на коротком
+  значении всё три выглядят исправными. Значение для замера берётся предельное — то, какое узел
+  может получить у настоящего потребителя, а не то, какое стоит в примере.
+- **Готовое из набора, взятое под данные другого размера, меряется, а не разглядывается.**
+  Компонент, живший там, где значения короткие, в новом месте получает значение вчетверо
+  длиннее — и ведёт себя иначе, оставаясь тем же кодом. Спека этого не видит вовсе: обрезка
+  браузером в разметке не отражается, и текст приходит из неё целым.
 - **Прод-конфигурация проверяется только за настоящим прокси.** Голый сервер отдачи страниц
   про кэш, перенаправления и заголовки не знает ничего.
 - **Первый заход на публичный экран метится признаком служебного посещения.** Драйвер водит
@@ -79,6 +87,12 @@ flowchart TD
   дерева; признак, который живёт в хранилище браузера, дописывается один раз на профиль, а не
   к каждому адресу.
 
+- **Экран, данных для которого в базе разработки не бывает, меряется настоящими стилями
+  компонента.** Разметка вставляется в уже открытый экран со своим атрибутом области, и правила
+  оформления применяются к ней те же, что применились бы к живой строке. Это приём, а не обход:
+  замеряются те же вычисленные значения, а выдумывается только содержимое строки. Обходом было
+  бы измерить чужой экран и назвать это замером нужного.
+
 Вывод о вёрстке подкрепляется числом: «выглядит нормально» результатом проверки не является.
 Этого не стережёт ничто — как измерять, разобрано в паттерне `browser-verification-measure`.
 

package/assets/rules/dependencies.md

@@ -2,7 +2,7 @@
 name: dependencies
 kind: rule
 law: delivery
-description: Правило под «Закон о поставке». Брать при правке package.json, pnpm-lock.yaml и pnpm-workspace.yaml и при обновлении любого пакета. Называет точный номер версии вместо диапазона, снимок дерева, подмену чужих версий, выдержку новой версии и границу переформатирования после обновления форматтера. Готовый порядок — в паттерне dependencies-upgrade.
+description: Правило под «Закон о поставке». Брать при правке package.json, снимка дерева зависимостей и настроек рабочей области, а также при обновлении любого пакета. Называет точный номер версии вместо диапазона и выдержку новой версии. Паттерн dependencies-upgrade.
 ---
 
 # Зависимости — как это устроено здесь

package/assets/rules/deploy-flow.azure.md

@@ -2,7 +2,7 @@
 name: deploy-flow
 kind: rule
 law: delivery
-description: Правило под «Закон о поставке» для дерева в Azure DevOps — та его часть, что про выкатку. Брать, когда правка едет на прод: слияние в главную ветку, конвейер, образы и их метки, чистка реестра, описание прода, цепочка миграций хранилища. Называет признак режима в образе, выкатку по sha коммита, глубину отката и сверку прода с главной веткой. Готовый код — в паттернах git-workflow-migration, git-workflow-restart, git-workflow-docker и git-workflow-secrets. Не брать на заведение задачи, ветки, коммит и заявку — это правило git-workflow.
+description: Правило под «Закон о поставке» для дерева в Azure DevOps — та его часть, что про выкатку. Брать, когда правка едет на прод: слияние в главную ветку, конвейер, образы и метки, миграции хранилища. Паттерны: git-workflow-migration, -restart, -docker, -secrets.
 ---
 
 # Выкатка — как это устроено здесь

package/assets/rules/deploy-flow.github.md

@@ -2,7 +2,7 @@
 name: deploy-flow
 kind: rule
 law: delivery
-description: Правило под «Закон о поставке» для дерева на GitHub — та его часть, что про выкатку. Брать, когда правка едет на прод: мерж в главную ветку, конвейер, образы и их метки, чистка реестра, описание прода, цепочка миграций хранилища. Называет признак режима в образе, выкатку по sha коммита, глубину отката и сверку прода с главной веткой. Готовый код — в паттернах git-workflow-migration, git-workflow-restart, git-workflow-docker и git-workflow-secrets. Не брать на заведение задачи, ветки, коммит и заявку — это правило git-workflow.
+description: Правило под «Закон о поставке» для дерева на GitHub — та его часть, что про выкатку. Брать, когда правка едет на прод: мерж в главную ветку, конвейер, образы и метки, миграции хранилища. Паттерны: git-workflow-migration, -restart, -docker, -secrets. Задача и ветка — правило git-workflow.
 ---
 
 # Выкатка — как это устроено здесь

package/assets/rules/deploy-flow.gitlab.md

@@ -2,7 +2,7 @@
 name: deploy-flow
 kind: rule
 law: delivery
-description: Правило под «Закон о поставке» для дерева на GitLab — та его часть, что про выкатку. Брать, когда правка едет на прод: слияние в главную ветку, конвейер, образы и их метки, чистка реестра, описание прода, цепочка миграций хранилища. Называет признак режима в образе, выкатку по sha коммита, глубину отката и сверку прода с главной веткой. Готовый код — в паттернах git-workflow-migration, git-workflow-restart, git-workflow-docker и git-workflow-secrets. Не брать на заведение задачи, ветки, коммит и заявку — это правило git-workflow.
+description: Правило под «Закон о поставке» для дерева на GitLab — та его часть, что про выкатку. Брать, когда правка едет на прод: слияние в главную ветку, конвейер, образы и метки, миграции хранилища. Паттерны: git-workflow-migration, -restart, -docker, -secrets. Задача и ветка — правило git-workflow.
 ---
 
 # Выкатка — как это устроено здесь

package/assets/rules/doc-style.md

@@ -112,12 +112,30 @@ flowchart TD
   строка в шапке дешевле правки всех ссылающихся записей и прошлого не трогает.
   <!-- rt-when: *.md -->
 
+- **Словарь работы и язык экрана — два разных словаря.** Слово, которым слой правил зовёт своё
+  понятие, для человека за экраном ничего не значит: он не читал ни одного правила и читать не
+  будет. Термин словаря в подписи кнопки, колонки или пустого состояния — это внутреннее слово,
+  показанное наружу; слово для человека выбирает тот, кто с ним говорит, и берёт он его из языка
+  предметной области, а не из левой колонки словаря.
+  <!-- rt-when: *.md -->
+
 - **Текст, называющий состояние машины, устаревает без единой правки в дереве.** Ловушка о том,
   что на машине установлено, верна в день, когда её пишут, и становится неправдой сама собой —
   ни одна сверка этого не видит: они читают дерево, а состарилась машина. Утверждение о машине
   пишется способом её спросить: команда и то, с чем сверять ответ, вместо снимка ответа.
   <!-- rt-when: *.md -->
 
+- **У записи описания прошлого есть срок, и после него запись снимается.** Каталог набирает по
+  записи на каждую закрытую работу и не отдаёт обратно ничего. Снятая остаётся в истории —
+  достают её тем же именем файла, которым ищут живую. Срок называет дерево ключом настройки;
+  умолчания у него нет, потому что снимается там разбор просьбы, которого нет больше нигде.
+  <!-- rt-when: *.md -->
+
+- **Ссылка на запись описания прошлого в живом тексте живёт ровно до её срока.** Проверка
+  адресов архив не читает вовсе, поэтому мёртвая ссылка краснеет не в нём, а в том тексте,
+  который сослался. Живой текст называет решение словами, а не адресом записи.
+  <!-- rt-when: *.md -->
+
 ## Чего из закона здесь нет
 
 Ни одна из формулировочных договорённостей не проверяется: одна фраза на правило, простые

package/assets/rules/entity-conventions.needs-admin.md

@@ -2,7 +2,7 @@
 name: entity-conventions
 kind: rule
 law: entity-editing
-description: Правило под «Закон о правке сущности». Брать при правке любого стора админки (*.store.ts) и любой панели создания или правки записи. Называет общую основу асайда, общую основу списочного стора, устройство панели и то, что асайд открывается маршрутом в аутлете ro. Готовый код — в паттернах entity-aside и entity-store.
+description: Правило под «Закон о правке сущности». Брать при правке любого стора админки и любой панели создания или правки записи. Называет общую основу асайда и списочного стора и то, что асайд открывается своим маршрутом. Паттерны: entity-aside, entity-store.
 ---
 
 # Правка сущности — как это устроено здесь

package/assets/rules/entity-models.md

@@ -2,7 +2,7 @@
 name: entity-models
 kind: rule
 law: entity-models
-description: Правило под «Закон о моделях сущностей». Брать при объявлении или правке модели записи и её маппера в админке, при правке моделей и мапперов в libs/common/util и при правке .proto. Называет неймспейс I<Сущность>, уровни модели и что берётся из @rt-tools/utils. Готовый код — в паттерне entity-models-new.
+description: Правило под «Закон о моделях сущностей». Брать при объявлении или правке модели записи и её маппера, при правке общих моделей и при правке описания контракта. Называет неймспейс модели и её уровни. Паттерн entity-models-new.
 ---
 
 # Модели сущностей — как это устроено здесь

package/assets/rules/git-workflow.azure.md

@@ -2,7 +2,7 @@
 name: git-workflow
 kind: rule
 law: delivery
-description: Правило под «Закон о поставке» для дерева в Azure DevOps. Брать на заведение задачи, ветки, коммит, пуш, создание PR, слияние, а также на правку схемы хранилища, её миграций и вызовы миграций. Называет рабочий элемент как начало работы, его состояние как ход работы, соответствие задачи и ветки один к одному, имя ветки, формат коммита, учётную запись машинной работы, обязательный состав PR, гарды поставки и сверку очереди работ. Готовый код — в паттернах git-workflow-commit, git-workflow-pr, git-workflow-merge. Выкатка, образы и миграции — правило deploy-flow.
+description: Правило под «Закон о поставке» для дерева в Azure DevOps. Брать на заведение рабочего элемента, ветки, коммит, пуш, открытие PR и слияние. Называет соответствие элемента и ветки один к одному, имена, машинную учётную запись и гарды поставки. Паттерны: git-workflow-commit, -pr, -merge.
 ---
 
 # Поставка — как это устроено здесь