@nitra/cursor 12.8.3 → 12.8.5

package/CHANGELOG.md

@@ -1,5 +1,17 @@
 # Changelog
 
+## [12.8.5] - 2026-06-22
+
+### Changed
+
+- ♻️ refactor(npm): Перехід з `style-lint` на `style` у правил та конфігах
+
+## [12.8.4] - 2026-06-22
+
+### Changed
+
+- ♻️ refactor(npm): Перехід з `style-lint` на `style` у правил та конфігах
+
 ## [12.8.3] - 2026-06-22
 
 ### Changed

package/bin/n-cursor.js

@@ -74,7 +74,7 @@ import { fileURLToPath } from 'node:url'
 
 import { buildAgentsCommandBulletItems } from '../scripts/build-agents-commands.mjs'
 import { formatGeneratedMarkdownLines, renderAgentsTemplate } from '../scripts/lib/generated-markdown.mjs'
-import { inlineTemplateLinks } from '../scripts/lib/inline-template-links.mjs'
+import { inlineMarkdownIncludes, inlineTemplateLinks } from '../scripts/lib/inline-template-links.mjs'
 import {
   detectAutoRules,
   detectLegacyRuleIds,
@@ -422,7 +422,8 @@ async function readBundledRuleContent(rule, bundledRulesDir = BUNDLED_RULES_DIR)
     )
   }
   const text = await readFile(bundledPath, 'utf8')
-  return inlineTemplateLinks(text, dirname(bundledPath))
+  const withTemplates = await inlineTemplateLinks(text, dirname(bundledPath))
+  return inlineMarkdownIncludes(withTemplates, dirname(bundledPath))
 }
 
 /**

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@nitra/cursor",
-  "version": "12.8.3",
+  "version": "12.8.5",
   "description": "CLI для завантаження cursor-правил (префікс n-) у локальний репозиторій",
   "keywords": [
     "cli",

package/rules/abie/js/env_dns.mdc

@@ -0,0 +1,33 @@
+## Внутрішньокластерні URL у env-файлах (dev / ua)
+
+Правило стосується **будь-якого** внутрішньокластерного URL у env-файлах abie-проєкту, а не лише `HASURA_GRAPHQL_ENDPOINT`. Це може бути URL до Hasura, KVCMS, `auth-run-hl`, `file-link-hl` чи будь-якого іншого Service у кластері — у всіх випадках DNS-суфікс і namespace-префікс мають відповідати **середовищу** з імені env-файлу.
+
+abie-проєкти живуть у **двох GKE-кластерах** (dev / ua), тож DNS-суфікс і namespace у URL відрізняються між `*.env`-файлами:
+
+| env-файл (basename) | namespace-префікс у URL | DNS-суфікс кластера | примітка |
+| --- | --- | --- | --- |
+| `dev.env`, `.dev.env` | `dev-…` | `abie-dev.internal` | GKE-кластер dev |
+| `ua.env`, `.ua.env` | `ua-…` | `abie-ua.internal` | GKE-кластер ua |
+
+Канонічна форма URL — `http://<service>.<namespace>.svc.<cluster-dns-suffix>:<port>`. Суфікс — `<cluster>.internal`.
+
+Приклади для одного env-файлу з двома сервісами (Hasura + KVCMS):
+
+```env title="hasura/.dev.env"
+HASURA_GRAPHQL_ENDPOINT=http://apruv-h-hl.dev-apruv.svc.abie-dev.internal:8080
+KVCMS_URL=http://kvcms-hl.dev-apruv.svc.abie-dev.internal:8080
+```
+
+```env title="hasura/.ua.env"
+HASURA_GRAPHQL_ENDPOINT=http://apruv-h-hl.ua-apruv.svc.abie-ua.internal:8080
+KVCMS_URL=http://kvcms-hl.ua-apruv.svc.abie-ua.internal:8080
+```
+
+`<namespace>` (наприклад `dev-apruv` / `ua-apruv`) — `metadata.name` цільового namespace після kustomize-overlay для відповідного середовища; `<service>` — `metadata.name` headless Service (`-hl`) того сервісу, до якого йде URL.
+
+**Перевірка `js/env_dns.mjs`** сканує всі `*.env` файли, basename яких збігається з `dev.env` / `ua.env` (з провідною крапкою чи без), знаходить **усі** internal URL (`http://<svc>.<ns>.svc.<dns>` — як для Hasura-ендпоінта, так і для KVCMS чи будь-якого іншого) і вимагає, щоб для кожного:
+
+- DNS-суфікс відповідав env: `abie-dev.internal` / `abie-ua.internal`;
+- namespace починався з `dev-` / `ua-` відповідно.
+
+Загальне правило про **внутрішній** URL (не публічний домен) для `HASURA_GRAPHQL_ENDPOINT` лишається у **`hasura.mdc`** (для nitra і abie) — `rules/hasura/fix.mjs` приймає кластерний DNS-формат `<cluster>.internal`.

package/rules/abie/js/firebase_hosting.mdc

@@ -0,0 +1,3 @@
+## Firebase Hosting
+
+У **кожному** підкаталозі, що лежить **безпосередньо** в корені репозиторію, не тримати конфіг і кеш **Firebase Hosting**: у таких каталогах не повинно бути **`.firebaserc`**, **`firebase.json`** та каталогу **`.firebase/`** (у **самому** корені репозиторію ці імена перевіркою abie **не** розглядаються; `node_modules` / `.git` зі скану вилучаються).

package/rules/abie/js/hc_pairing.mdc

@@ -0,0 +1,23 @@
+## k8s: `hc.yaml` поруч із Deployment
+
+Якщо під **`k8s`** є **Deployment**, у **тій самій директорії** має бути **`hc.yaml`** з **HealthCheckPolicy** (**`networking.gke.io/v1`**): коректний modeline **`$schema`**, **`httpHealthCheck.requestPath`** — непорожній шлях від кореня (рядок, що починається з **`/`**: канонічно **`/healthz`**, але також допустимі **`/IsAlive`**, **`/api/live`** тощо — узгоджується з реальним endpoint сервісу), порт **8080**, **`targetRef.name`** — **headless** **Service** з суфіксом **`-hl`** (узгоджено з парою **`svc.yaml`** / **`svc-hl.yaml`** у **k8s.mdc**): або **`${metadata.name}-hl`**, або те саме ім'я, якщо **`metadata.name`** уже з **`-hl`**.
+
+```yaml title="hc.yaml"
+# yaml-language-server: $schema=https://datreeio.github.io/CRDs-catalog/networking.gke.io/healthcheckpolicy_v1.json
+apiVersion: networking.gke.io/v1
+kind: HealthCheckPolicy
+metadata:
+  name: СЕРВІС
+  namespace: dev # kustomize overlay
+spec:
+  default:
+    config:
+      type: HTTP
+      httpHealthCheck:
+        requestPath: /healthz
+        port: 8080
+  targetRef:
+    group: ''
+    kind: Service
+    name: СЕРВІС-hl
+```

package/rules/abie/js/ua_http_route.mdc

@@ -0,0 +1,47 @@
+## k8s: overlay **HTTPRoute** (**ua**)
+
+За наявності **Deployment** під **k8s** і наявності **Vite** (**`vite.config.js`**, **`vite.config.mjs`** або **`vite.config.ts`** у каталозі пакета) у **`ua/kustomization.yaml`** цього пакета потрібні **inline JSON6902** у **`patches`**: **target** **`kind: HTTPRoute`**, **непорожній `name`** (як у маніфесті маршруту). Мають бути зміни **`/spec/hostnames`** (домени abie — у скрипті) та **`/spec/parentRefs/0/namespace`** (**`ua`**, також дозволені префікси **`ua-*`**, наприклад **`ua-b2b`**). Як обирати **`op`** (**add** / **replace** тощо) у patch — **k8s.mdc** (розділ про JSON patch у kustomization).
+
+### HTTPRoute: спільні сервіси **`auth-run-hl`**, **`file-link-hl`**
+
+У **HTTPRoute** у шляху з **`…/k8s/base/…`** у **`spec.hostnames`** дозволені лише **`aiml.live`**, **`*.aiml.live`** та інші піддомени **aiml.live** (перевірка — Rego-пакет **`abie.http_route_base`**, див. розділ нижче).
+
+Ці **Service** (headless **`-hl`**) живуть у **базовому** неймспейсі **`dev`**. У маніфесті **HTTPRoute** під **`k8s`** (шар без **`ua/`** — наприклад **`…/k8s/base/hr.yaml`**) для кожного **`backendRefs`** до такого сервісу явно вкажи **`namespace: dev`** і порт **8080**:
+
+```yaml title="…/k8s/base/hr.yaml (фрагмент)"
+spec:
+  rules:
+    - matches:
+        - path:
+            type: PathPrefix
+            value: /
+      backendRefs:
+        - name: auth-run-hl
+          namespace: dev
+          port: 8080
+        - name: file-link-hl
+          namespace: dev
+          port: 8080
+```
+
+У **`ua/kustomization.yaml`** додай до того самого **inline** patch на **`HTTPRoute`** (той самий **`target.name`**) операції **JSON6902** з **`path`**: **`/spec/rules/<i>/backendRefs/<j>/namespace`**, де **`<i>`** / **`<j>`** — індекси відповідно до порядку **`spec.rules`** та **`backendRefs`** у base-файлі; **`value`**: **`ua`** (також дозволені **`ua-*`**). Якщо кілька таких **`backendRefs`**, потрібна окрема операція для кожного.
+
+```yaml title="…/ua/kustomization.yaml (фрагмент)"
+  - target:
+      kind: HTTPRoute
+      name: my-httproute
+    patch: |-
+      - op: replace
+        path: /spec/hostnames
+        value:
+          - "abie.app" # зокрема vybeerai.com.ua, *.vybeerai.com.ua, *.abie.app
+      - op: replace
+        path: /spec/parentRefs/0/namespace
+        value: ua
+      - op: replace
+        path: /spec/rules/0/backendRefs/0/namespace
+        value: ua
+      - op: replace
+        path: /spec/rules/0/backendRefs/1/namespace
+        value: ua
+```

package/rules/abie/js/ua_node_selector.mdc

@@ -0,0 +1,27 @@
+## k8s: overlay **ua** і nodeSelector
+
+У **`…/ua/kustomization.yaml`** того пакета, у дереві **`k8s`** якого є **Deployment**, потрібен patch на **`kind: Deployment`**: **`spec.template.spec.nodeSelector`** з **`preem: false`**. Форму **JSON6902** (шлях **`/spec/template/spec/nodeSelector`**, **`op`**) див. **k8s.mdc**.
+
+```yaml title="…/ua/kustomization.yaml (фрагмент)"
+patches:
+  - target:
+      kind: Deployment
+      name: my-app
+    patch: |-
+      - op: add
+        path: /spec/template/spec/nodeSelector
+        value:
+          preem: 'false'
+```
+
+### Базовий Deployment (`…/base/`)
+
+Якщо **Deployment** у YAML під **`k8s`** лежить у шляху з сегментом **`base`**, у **`spec.template.spec.nodeSelector`** має бути **`preem`** зі значенням **істинно** (**`true`** або рядок **`'true'`**); overlay **ua** підміняє селектор.
+
+```yaml title="…/base/deploy.yaml (фрагмент)"
+spec:
+  template:
+    spec:
+      nodeSelector:
+        preem: 'true' # буде замінено через kustomize
+```

package/rules/abie/main.mdc

@@ -0,0 +1,53 @@
+---
+description: Правила для проєктів AbInBev Efes
+alwaysApply: true
+version: '1.22'
+---
+
+Правило **abie** для споживачів **@nitra/cursor**: **k8s** (Deployment + **HealthCheckPolicy** у **`hc.yaml`**, overlay **ua** — **nodeSelector**, **HTTPRoute** (будь-який непорожній **`target.name`**, для спільних сервісів **`auth-run-hl`** / **`file-link-hl`** — **`namespace: dev`** у base та patch **`…/backendRefs/…/namespace`** у **ua**)), гілки **dev**, **ua** у **clean-merged-branch**, а також заборона тримати артефакти **Firebase Hosting** у **підкаталогах першого рівня** (безпосередні діти кореня репозиторію; у самому корені ці імена не вимагаються до видалення).
+
+[k8s-hc-yaml](./js/hc_pairing.mdc)
+
+[k8s-http-route-ua](./js/ua_http_route.mdc)
+
+[k8s-nodeselector](./js/ua_node_selector.mdc)
+
+[env-dns](./js/env_dns.mdc)
+
+## `@nitra/abie-shared` у `devDependencies`
+
+У кореневому **`package.json`** abie-проєкту в **`devDependencies`** має бути **`@nitra/abie-shared`** — пакет зі спільними abie-ресурсами: канонічні GraphQL-схеми, скіли, типи (наприклад, шляхи `node_modules/@nitra/abie-shared/schema/...` для імпорту схем). Версію правило не фіксує — лише presence. Додати:
+
+```bash
+bun add -d @nitra/abie-shared
+```
+
+[firebase](./js/firebase_hosting.mdc)
+
+## Git branches
+
+У **`.github/workflows/clean-merged-branch.yml`** у кроці **`phpdocker-io/github-actions-delete-abandoned-branches`** значення **`with.ignore_branches`** має містити **dev** та **ua** (разом з іншими гілками, якщо потрібно):
+
+- abie-specific канон (action marker + required ignore_branches tokens): [clean-merged-branch.yml.snippet.yml](./policy/clean_merged_ignore_branches/template/clean-merged-branch.yml.snippet.yml)
+
+## Швидкий gate через conftest (Rego)
+
+Підмножину пер-документних правил продубльовано як rego-полісі у **`npm/rules/abie/policy/`** (запускається через **`bun run lint-rego`** для `*_test.rego` юніт-тестів і через **`npx @nitra/cursor fix abie`** для прогону по реальних YAML — деталі в **conftest.mdc** / **n-rego.mdc**). JS у **`js/<concern>.mjs`** authoritative — rego тільки швидкий gate для одиничного маніфеста (зокрема через IDE-розширення `tsandall.opa`).
+
+Пакети (директорія в **`npm/policy/abie/`** → namespace → що перевіряє):
+
+- **`http_route_base/`** → `abie.http_route_base` — у HTTPRoute під `…/k8s/.../base/...` усі `spec.hostnames` мають бути в домені `aiml.live` (включно з `*.aiml.live` та піддоменами). **Цільові файли:** `…/k8s/.../base/.../hr.yaml`.
+- **`health_check_policy/`** → `abie.health_check_policy` — структура HealthCheckPolicy: `apiVersion: networking.gke.io/v1`, `metadata.name`, `spec.default.config.type: HTTP`, `httpHealthCheck.requestPath` починається з `/`, `port: 8080`, `targetRef.kind: Service`, `targetRef.name` має суфікс `-hl`. **Цільові файли:** `…/k8s/.../hc.yaml`.
+- **`base_deployment_preem/`** → `abie.base_deployment_preem` — Deployment у base/ має `spec.template.spec.nodeSelector.preem` зі значенням `true` (boolean або рядок). **Цільові файли:** ресурсні YAML під `…/k8s/.../base/...`.
+- **`clean_merged_ignore_branches/`** → `abie.clean_merged_ignore_branches` — у workflow `.github/workflows/clean-merged-branch.yml` крок з `uses: phpdocker-io/github-actions-delete-abandoned-branches` має `with.ignore_branches`, що містить токени `dev,ua` (case-insensitive). **Цільові файли:** `.github/workflows/clean-merged-branch.yml`.
+- **`package_json_shared/`** → `abie.package_json_shared` — у кореневому `package.json` `devDependencies` має містити `@nitra/abie-shared` (presence-only, версію не фіксуємо). **Цільові файли:** `package.json`.
+
+Cross-file / FS-логіка лишається у JS-частинах (`js/<concern>.mjs`) — Rego не читає файлову систему й не робить cross-document резолюцію:
+
+- парність HCP↔Deployment у каталозі та modeline `hc.yaml` — `js/hc_pairing.mjs`;
+- валідація ua-overlay JSON6902 patches на HTTPRoute + аналіз cross-namespace `backendRefs` у пакетах — `js/ua_http_route.mjs`;
+- ua-overlay JSON6902 patch на `Deployment.nodeSelector` (`preem: false`) — `js/ua_node_selector.mjs`;
+- env→cluster DNS (`*.dev.env` / `*.ua.env`) — `js/env_dns.mjs`;
+- скан артефактів Firebase Hosting у підкаталогах першого рівня — `js/firebase_hosting.mjs`.
+
+Точна звірка `targetRef.name` HealthCheckPolicy з суфіксом `-hl` обчислюється з `hcp.metadata.name` і живе у Rego (`abie.health_check_policy`); за конвенцією `hcp.metadata.name` дорівнює `<deployment.name>`, тому окремий cross-file lookup до маніфесту Deployment не потрібен.

package/rules/doc-files/js/docs/index.md

@@ -6,19 +6,19 @@ resource: npm/rules/doc-files/js/
 
 # npm/rules/doc-files/js
 
-| Файл | Тип |
-|---|---|
-| [docgen-crc.mjs](docgen-crc.md) | JS Module |
+| Файл                                                    | Тип       |
+| ------------------------------------------------------- | --------- |
+| [docgen-crc.mjs](docgen-crc.md)                         | JS Module |
 | [docgen-extract-anchors.mjs](docgen-extract-anchors.md) | JS Module |
-| [docgen-extract.mjs](docgen-extract.md) | JS Module |
-| [docgen-files-batch.mjs](docgen-files-batch.md) | JS Module |
-| [docgen-gen.mjs](docgen-gen.md) | JS Module |
-| [docgen-ignore.mjs](docgen-ignore.md) | JS Module |
-| [docgen-judge-measure.mjs](docgen-judge-measure.md) | JS Module |
-| [docgen-judge.mjs](docgen-judge.md) | JS Module |
-| [docgen-prompts.mjs](docgen-prompts.md) | JS Module |
-| [docgen-scan.mjs](docgen-scan.md) | JS Module |
-| [run-lint.mjs](run-lint.md) | JS Module |
-| [units-js.mjs](units-js.md) | JS Module |
-| [units-rs.mjs](units-rs.md) | JS Module |
-| [units.mjs](units.md) | JS Module |
+| [docgen-extract.mjs](docgen-extract.md)                 | JS Module |
+| [docgen-files-batch.mjs](docgen-files-batch.md)         | JS Module |
+| [docgen-gen.mjs](docgen-gen.md)                         | JS Module |
+| [docgen-ignore.mjs](docgen-ignore.md)                   | JS Module |
+| [docgen-judge-measure.mjs](docgen-judge-measure.md)     | JS Module |
+| [docgen-judge.mjs](docgen-judge.md)                     | JS Module |
+| [docgen-prompts.mjs](docgen-prompts.md)                 | JS Module |
+| [docgen-scan.mjs](docgen-scan.md)                       | JS Module |
+| [run-lint.mjs](run-lint.md)                             | JS Module |
+| [units-js.mjs](units-js.md)                             | JS Module |
+| [units-rs.mjs](units-rs.md)                             | JS Module |
+| [units.mjs](units.md)                                   | JS Module |

package/rules/js/docs/index.md

@@ -6,7 +6,7 @@ resource: npm/rules/js/
 
 # npm/rules/js
 
-| Файл                | Тип       |
-| ------------------- | --------- |
-| [fix.mjs](fix.md)   | JS Module |
+| Файл | Тип |
+|---|---|
+| [fix.mjs](fix.md) | JS Module |
 | [main.mjs](main.md) | JS Module |

package/rules/js/docs/main.md

@@ -3,26 +3,26 @@ type: JS Module
 title: main.mjs
 resource: npm/rules/js/main.mjs
 docgen:
-  crc: 4f68b557
+  crc: 00294e8e
   model: omlx/gemma-4-e4b-it-OptiQ-4bit
   score: 100
 ---
 
 ## Огляд
 
-Модуль надає інструменти для аналізу кодової бази. Функція `run` ініціює повну перевірку проєкту. Функція `filterJsFiles` відбирає файли з розширенням JavaScript. Функція `lint` запускає лінтинг для виявлення порушень у коді.
+Модуль забезпечує виконання функцій `run`, `filterJsFiles` та `lint` для аналізу кодової бази. Він виконує стандартну перевірку проєкту, відбираючи файли з розширеннями JavaScript за допомогою `filterJsFiles` та запускаючи перевірку JS-коду за допомогою `lint`.
 
 ## Поведінка
 
 run виконує стандартну перевірку проєкту.
-filterJsFiles відбирає з наданого списку лише файли, що мають розширення, характерне для JavaScript.
-lint запускає лінтинг для вказаних файлів або всього проєкту, залежно від аргументів, і класифікує знайдені порушення.
+filterJsFiles відбирає з наданого списку лише файли з розширеннями, характерними для JavaScript.
+lint запускає перевірку JS-коду, виконуючи або повний аналіз проєкту, або класифіковану перевірку змінених файлів.
 
 ## Публічний API
 
-run — головна точка входу для виконання правил, що включає перевірку логіки (JS-завдання → політика → посилання MDC) та запуск лінтера.
-filterJsFiles — відбирає лише файли, що відповідають формату JavaScript.
-lint — виконує аналіз коду за допомогою oxlint та eslint, з можливістю автоматичного виправлення або лише виявлення проблем.
+run — основна точка входу для виконання правил, що включає перевірку логіки застосування, логіки політик та посилань на метадані.
+filterJsFiles — відбирає лише файли, схожі на JavaScript, з наданого списку.
+lint — запускає інструменти oxlint та eslint (для окремих файлів або всього проекту) та jscpd+knip (тільки для всього проекту), з можливістю автоматичного виправлення або лише виявлення проблем.
 
 ## Гарантії поведінки
 

package/rules/js/js/docs/check.md

@@ -3,34 +3,30 @@ type: JS Module
 title: check.mjs
 resource: npm/rules/js/js/check.mjs
 docgen:
-  crc: f61768f2
+  crc: 7ad4aa59
   model: omlx/gemma-4-e4b-it-OptiQ-4bit
   score: 100
 ---
 
 ## Огляд
 
-Модуль виконує перевірку конфігураційних файлів проєкту, забезпечуючи їхню відповідність встановленим стандартам. Він читає та аналізує конфігураційні файли, включаючи `package.json`, `.oxlintrc.json`, `knip.json`, `knip-canonical.json` та `.eslintrc.json`. Перевірка ґрунтується на логіці, визначеній у (js.mdc) та (text.mdc). Функціонал реалізований у режимі лише читання, що означає відсутність змін у файловій системі чи базах даних. При виявленні проблем, система перехоплює помилки, працюючи у режимі fail-safe. Свідомо ігноруються шляхи `.github` та `.git`.
+Модуль виконує валідацію конфігураційних файлів, включаючи `package.json`, `.oxlintrc.json`, `knip.json`, `knip-canonical.json` та `.eslintrc.json`. Він перевіряє відповідність структури та конфігурацій встановленим стандартам. (js.mdc) (text.mdc)
 
 ## Поведінка
 
-1. Викликає `check` для початку перевірки.
-2. Перевіряє наявність та відповідність конфігурації ESLint.
-3. Перевіряє конфігурацію `package.json` для всіх робочих просторів:
-   а. Перевіряє, чи має `package.json` `"type": "module"`.
-   б. Перевіряє, чи містить `package.json` `engines.node` з версією не менше 24.
-   в. Перевіряє, чи містить `package.json` `engines.bun` з версією не менше 1.3.
-4. Перевіряє конфігураційний файл `.oxlintrc.json` на відповідність канонічному шаблону.
-5. Перевіряє файли робочих процесів у `.github/workflows/`:
-   а. Перевіряє наявність `lint-js.yml`.
-   б. Перевіряє, чи не дублює `lint.yml` кроки лінтінгу JS.
-6. Перевіряє наявність файлу `knip.json` у корені проєкту. Якщо він відсутній, копіює канонічний шаблон.
-7. Перевіряє наявність застарілих конфігурацій ESLint (`.eslintrc`, `.eslintrc.js`, `.eslintrc.json`, `.eslintrc.yml`) та повідомляє про їхнє існування.
-8. Повертає код виходу, що відображає загальний статус перевірки.
+1. Викликається функція check.
+2. Ініціалізується механізм збору результатів перевірок.
+3. Перевіряється конфігураційний файл ESLint.
+4. Перевіряється структура пакетів у workspace'ах, включаючи наявність `"type": "module"` та вимоги до версій Node та Bun у `package.json` кожного пакета.
+5. Перевіряється конфігураційний файл `.oxlintrc.json` на відповідність канонічному шаблону.
+6. Перевіряється структура файлів у робочих процесах GitHub, зокрема наявність `lint-js.yml` та відсутність дублювання кроків лінтингу в `lint.yml`.
+7. Перевіряється наявність `knip.json` у корені проєкту. Якщо відсутній, він створюється з канонічного шаблону.
+8. Після виконання всіх перевірок, сканується проєкт на наявність застарілих конфігураційних файлів ESLint.
+9. Повертається код виходу, що відображає загальний статус виконання перевірок.
 
 ## Публічний API
 
-check — забезпечує відповідність проєкту вимогам, описаним у js.mdc.
+check — перевіряє відповідність проєкту стандартам js.mdc
 
 ## Гарантії поведінки
 

package/rules/js/js/docs/index.md

@@ -6,9 +6,9 @@ resource: npm/rules/js/js/
 
 # npm/rules/js/js
 
-| Файл                                  | Тип       |
-| ------------------------------------- | --------- |
-| [check.mjs](check.md)                 | JS Module |
+| Файл | Тип |
+|---|---|
+| [check.mjs](check.md) | JS Module |
 | [lint-findings.mjs](lint-findings.md) | JS Module |
-| [tooling.mjs](tooling.md)             | JS Module |
+| [tooling.mjs](tooling.md) | JS Module |
 | [utils_imports.mjs](utils_imports.md) | JS Module |

package/rules/js/js/docs/tooling.md

@@ -3,26 +3,26 @@ type: JS Module
 title: tooling.mjs
 resource: npm/rules/js/js/tooling.mjs
 docgen:
-  crc: 7ead48ee
+  crc: 101a5230
   model: omlx/gemma-4-e4b-it-OptiQ-4bit
   score: 95
 ---
 
 ## Огляд
 
-Визначає шляхи до канонічних конфігураційних файлів для oxlint та knip за допомогою OXLINT_CANONICAL_JSON_PATH та KNIP_CANONICAL_JSON_PATH. Дозволяє перевіряти відповідність конфігураційного файлу .oxlintrc.json до канонічного файлу oxlint-canonical.json за допомогою verifyOxlintRcAgainstCanonical.
+Визначає шляхи до канонічних JSON-файлів для інструментів oxlint та knip через OXLINT_CANONICAL_JSON_PATH та KNIP_CANONICAL_JSON_PATH. Також перевіряє відповідність конфігураційного файлу .oxlintrc.json значенням, встановленим у oxlint-canonical.json, за допомогою verifyOxlintRcAgainstCanonical.
 
 ## Поведінка
 
-OXLINT_CANONICAL_JSON_PATH — Вказує шлях до канонічного JSON-файлу oxlint у цьому пакеті.
-KNIP_CANONICAL_JSON_PATH — Вказує шлях до канонічного JSON-файлу knip у цьому пакеті.
-verifyOxlintRcAgainstCanonical — Перевіряє конфігураційний файл `.oxlintrc.json` на відповідність канонічному файлу oxlint-canonical.json, виявляючи відхилення у правилах та інших полях.
+OXLINT_CANONICAL_JSON_PATH — Вказує шлях до канонічного JSON-файлу для oxlint у цьому пакеті.
+KNIP_CANONICAL_JSON_PATH — Вказує шлях до канонічного JSON-файлу для knip у цьому пакеті.
+verifyOxlintRcAgainstCanonical — Перевіряє конфігураційний файл `.oxlintrc.json` на відповідність канонічним значенням, визначеним у `oxlint-canonical.json`.
 
 ## Публічний API
 
-OXLINT_CANONICAL_JSON_PATH — Вказує розташування стандартного конфігураційного файлу oxlint для валідації.
-KNIP_CANONICAL_JSON_PATH — Вказує розташування стандартного конфігураційного файлу knip, який копіюється у кореневий каталог проєкту, якщо його там немає.
-verifyOxlintRcAgainstCanonical — Порівнює конфігураційний файл `.oxlintrc.json` з канонічним файлом пакета, вимагаючи збігу всіх полів, крім додаткових ключів у секції `rules`.
+OXLINT_CANONICAL_JSON_PATH — Вказує на файл з еталонними налаштуваннями oxlint для валідації.
+KNIP_CANONICAL_JSON_PATH — Шлях до еталонних налаштувань knip, які копіюються у корінь проєкту, якщо їх немає.
+verifyOxlintRcAgainstCanonical — Порівнює конфігураційний файл `.oxlintrc.json` з еталоном, перевіряючи, чи всі правила з еталону присутні, а інші поля збігаються з каноном.
 
 ## Гарантії поведінки