@nitra/cursor 12.8.4 → 12.8.5

package/CHANGELOG.md

@@ -1,5 +1,11 @@
 # Changelog
 
+## [12.8.5] - 2026-06-22
+
+### Changed
+
+- ♻️ refactor(npm): Перехід з `style-lint` на `style` у правил та конфігах
+
 ## [12.8.4] - 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.4",
+  "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

@@ -6,139 +6,13 @@ 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` поруч із 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
-```
-
-## 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
-```
-
-## 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/`)
+[k8s-hc-yaml](./js/hc_pairing.mdc)
 
-Якщо **Deployment** у YAML під **`k8s`** лежить у шляху з сегментом **`base`**, у **`spec.template.spec.nodeSelector`** має бути **`preem`** зі значенням **істинно** (**`true`** або рядок **`'true'`**); overlay **ua** підміняє селектор.
+[k8s-http-route-ua](./js/ua_http_route.mdc)
 
-```yaml title="…/base/deploy.yaml (фрагмент)"
-spec:
-  template:
-    spec:
-      nodeSelector:
-        preem: 'true' # буде замінено через kustomize
-```
-
-## Внутрішньокластерні 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`-файлами:
+[k8s-nodeselector](./js/ua_node_selector.mdc)
 
-| 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`.
+[env-dns](./js/env_dns.mdc)
 
 ## `@nitra/abie-shared` у `devDependencies`
 
@@ -148,9 +22,7 @@ KVCMS_URL=http://kvcms-hl.ua-apruv.svc.abie-ua.internal:8080
 bun add -d @nitra/abie-shared
 ```
 
-## Firebase Hosting
-
-У **кожному** підкаталозі, що лежить **безпосередньо** в корені репозиторію, не тримати конфіг і кеш **Firebase Hosting**: у таких каталогах не повинно бути **`.firebaserc`**, **`firebase.json`** та каталогу **`.firebase/`** (у **самому** корені репозиторію ці імена перевіркою abie **не** розглядаються; `node_modules` / `.git` зі скану вилучаються).
+[firebase](./js/firebase_hosting.mdc)
 
 ## Git branches
 

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/main.md

@@ -10,19 +10,19 @@ docgen:
 
 ## Огляд
 
-Дозволяє запускати повний аналіз проєкту за допомогою `run`, виконувати лінтинг за допомогою `lint` або фільтрувати файли з розширенням JavaScript за допомогою `filterJsFiles`.
+Модуль забезпечує виконання функцій `run`, `filterJsFiles` та `lint` для аналізу кодової бази. Він виконує стандартну перевірку проєкту, відбираючи файли з розширеннями JavaScript за допомогою `filterJsFiles` та запускаючи перевірку JS-коду за допомогою `lint`.
 
 ## Поведінка
 
 run виконує стандартну перевірку проєкту.
-filterJsFiles відбирає з наданого списку лише файли, що мають розширення, характерне для JavaScript.
-lint запускає перевірку проєкту: або повний аналіз усіх файлів, або класифікований аналіз лише змінених файлів.
+filterJsFiles відбирає з наданого списку лише файли з розширеннями, характерними для JavaScript.
+lint запускає перевірку JS-коду, виконуючи або повний аналіз проєкту, або класифіковану перевірку змінених файлів.
 
 ## Публічний API
 
-run — виконує повний цикл перевірки: аналіз конфігурації, перевірку логіки та посилання на метадані.
-filterJsFiles — відбирає лише файли з розширенням JavaScript.
-lint — запускає інструменти для форматування та стилізації коду (oxlint, eslint, jscpd, knip).
+run — основна точка входу для виконання правил, що включає перевірку логіки застосування, логіки політик та посилань на метадані.
+filterJsFiles — відбирає лише файли, схожі на JavaScript, з наданого списку.
+lint — запускає інструменти oxlint та eslint (для окремих файлів або всього проекту) та jscpd+knip (тільки для всього проекту), з можливістю автоматичного виправлення або лише виявлення проблем.
 
 ## Гарантії поведінки
 

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

@@ -5,23 +5,24 @@ resource: npm/rules/js/js/check.mjs
 docgen:
   crc: 7ad4aa59
   model: omlx/gemma-4-e4b-it-OptiQ-4bit
-  score: 90
+  score: 100
 ---
 
 ## Огляд
 
-Модуль перевіряє відповідність структури та конфігураційних файлів проєкту встановленим стандартам. Він валідує файли, такі як `package.json`, `.oxlintrc.json`, `.eslintrc.json` та файли робочих процесів GitHub, відповідно до вимог (js.mdc). Перевірка свідомо ігнорує шляхи `.github` та `.git`. Модуль забезпечує перехоплення помилок (fail-safe) під час виконання перевірок.
+Модуль виконує валідацію конфігураційних файлів, включаючи `package.json`, `.oxlintrc.json`, `knip.json`, `knip-canonical.json` та `.eslintrc.json`. Він перевіряє відповідність структури та конфігурацій встановленим стандартам. (js.mdc) (text.mdc)
 
 ## Поведінка
 
-1. Викликати `check` для запуску перевірок конфігурації проєкту.
-2. Перевірити наявність конфігурацій ESLint (flat config) та валідувати їх вміст відповідно до вимог (js.mdc).
-3. Перевірити `package.json` у корені та у всіх пакетах workspace на відповідність вимогам: наявність `"type": "module"` та мінімальні версії `engines.node` (>=24) та `engines.bun` (>=1.3) (js.mdc).
-4. Перевірити конфігураційний файл `.oxlintrc.json` на відповідність канонічному шаблону (js.mdc).
-5. Перевірити файли робочих процесів (`.github/workflows/lint-js.yml` та `.github/workflows/lint.yml`) на відповідність політикам лінтингу (js.mdc).
-6. Перевірити наявність конфігурацій Knip (`knip.json`). Якщо відсутній, створити його, скопіювавши канонічний шаблон (js.mdc).
-7. Перевірити наявність застарілих конфігурацій ESLint (наприклад, `.eslintrc.*`) та повідомити про їхнє використання.
-8. Ігнорувати перевірки у каталогах `.github` та `.git`.
+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
 

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

@@ -10,19 +10,19 @@ docgen:
 
 ## Огляд
 
-Модуль визначає шляхи до канонічних JSON-файлів для інструментів oxlint та knip через функції OXLINT_CANONICAL_JSON_PATH та KNIP_CANONICAL_JSON_PATH. Він також надає функцію verifyOxlintRcAgainstCanonical для валідації конфігурацій, перевіряючи, чи відповідає `.oxlintrc.json` правилам, визначеним у oxlint-canonical.json.
+Визначає шляхи до канонічних 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` з еталоном, перевіряючи, чи всі правила з еталону присутні, а інші поля збігаються з `oxlint-canonical.json`.
+OXLINT_CANONICAL_JSON_PATH — Вказує на файл з еталонними налаштуваннями oxlint для валідації.
+KNIP_CANONICAL_JSON_PATH — Шлях до еталонних налаштувань knip, які копіюються у корінь проєкту, якщо їх немає.
+verifyOxlintRcAgainstCanonical — Порівнює конфігураційний файл `.oxlintrc.json` з еталоном, перевіряючи, чи всі правила з еталону присутні, а інші поля збігаються з каноном.
 
 ## Гарантії поведінки
 

package/rules/js/js/docs/utils_imports.md

@@ -10,21 +10,22 @@ docgen:
 
 ## Огляд
 
-Модуль сканує файли у монорепозиторії. Він зчитує вміст JavaScript/TypeScript файлів та витягує всі рядкові імпорти. На основі конфігурації `.n-cursor.json` він перевіряє, чи не містять імпорти заборонених відносних шляхів, реєструючи відповідний статус у логіці (js.mdc). Публічна функція `check` виконує цю перевірку, свідомо пропускаючи шляхи `.git` та `node_modules`.
+Модуль сканує монорепозиторій для пошуку каталогів `utils` та аналізу їхнього вмісту. Аналіз файлів JS/TS у цих каталогах здійснюється на відповідність шаблону забороненого відносного імпорту, що базується на конфігурації, визначеній у `.n-cursor.json`. При виявленні порушень, система генерує повідомлення, позначене як (js.mdc).
 
 ## Поведінка
 
-1. Визначає корінь проекту.
-2. Зчитує список шляхів, які слід ігнорувати, на основі конфігурації .n-cursor.json.
-3. Визначає кореневі каталоги пакетів у монорепозиторії.
-4. Для кожного кореневого каталогу пакета рекурсивно шукає каталоги з назвою `utils`, ігноруючи типові артефакти (наприклад, node_modules, .git, dist).
-5. Якщо знайдено каталоги `utils`, для кожного з них рекурсивно збирає всі файли з розширеннями `.js`, `.jsx`, `.ts`, `.tsx`, які не є тестовими.
-6. Для кожного зібраного файлу зчитує його вміст.
-7. Витягує з вмісту файлу всі рядкові імпорти (статичні, динамічні та виклики `require`).
-8. Для кожного витягнутого імпорту перевіряє, чи відповідає він шаблону забороненого відносного шляху, що вказує на імпорт з іншого каталогу, який не є загальним.
-9. Якщо заборонений імпорт знайдено, реєструє помилку, посилаючись на файл та заборонений імпорт (js.mdc).
-10. Якщо жодних порушень не знайдено, реєструє успіх (js.mdc).
-11. Повертає код виходу, що відображає статус перевірки.
+1. Визначає кореневий каталог для аналізу.
+2. Зчитує шляхи, які слід ігнорувати, на основі конфігурації .n-cursor.json.
+3. Знаходить усі каталоги з назвою `utils` у межах кореневих каталогів пакетів монорепозиторію, ігноруючи типові артефакти (наприклад, node_modules, .git, dist).
+4. Якщо знайдено жодних каталогів `utils`, перевірка вважається успішною і завершується.
+5. Для кожного знайденого каталогу `utils` збирає всі джерела файлів, які відповідають шаблону JS/TS, виключаючи тестові файли та файли у каталогах `tests/` чи `__fixtures__/`.
+6. Для кожного зібраного файлу:
+   а. Зчитує вміст файлу.
+   б. Витягує всі рядкові імпорти (статичні, динамічні, `require`) з коду.
+   в. Перевіряє кожен витягнутий імпорт на відповідність шаблону забороненого відносного імпорту.
+   г. Якщо імпорт є забороненим, фіксує порушення, вказуючи повний шлях до файлу та сам імпорт.
+7. Після перевірки всіх файлів, якщо порушень не знайдено, перевірка вважається успішною (js.mdc).
+8. Повертає код завершення, що відображає успіх або виявлені порушення (js.mdc).
 
 ## Гарантії поведінки
 

package/rules/test/js/docs/stryker_config.md

@@ -10,22 +10,22 @@ docgen:
 
 ## Огляд
 
-Модуль ініціалізує та налаштовує середовище для покриття коду, перевіряючи конфігурації, зокрема `mutation.json` та `package.json`. Він створює або оновлює конфігураційні файли Stryker, Vue-макросів та Vitest для кожного знайденого кореневого каталогу JavaScript. Функція `check` виконує перевірку, ігноруючи каталоги `node_modules`. Поведінка модуля фіксується за маркером (test.mdc). Модуль перехоплює помилки (fail-safe) і не кидає винятків назовні.
+Модуль перевіряє готовність JavaScript-проєктів до виконання тестів. Він збирає кореневі каталоги проєктів, використовуючи публічну функцію `check` для валідації. Перевірка гарантує наявність необхідних конфігураційних файлів, зокрема `mutation.json` та `package.json`, у кожному знайденому проєкті. Модуль свідомо пропускає каталоги `node_modules`. Він також додає відповідні артефакти тестів до `.gitignore` у коренях проєктів. (test.mdc)
 
 ## Поведінка
 
 1. Викликається `check` для ініціалізації процесу перевірки.
-2. Перевіряється, чи у конфігурації дозволено перевірку JavaScript. Якщо ні, процес завершується успішно.
-3. Знаходяться всі кореневі каталоги JavaScript у робочому просторі. Якщо їх немає, процес завершується з помилкою.
-4. Перевіряється наявність усіх канонічних базових конфігураційних файлів. Якщо хоча б один відсутній, процес завершується з помилкою.
-5. Для кожного знайденого кореневого каталогу JavaScript:
-    а. Визначається, чи містить цей каталог файли Vue.
-    б. Створюється або оновлюється конфігураційний файл Stryker для цього каталогу. Якщо файл відсутній, він копіюється з канонічного базового файлу, замінюючи ім'я конфігурації Vitest на фактичне ім'я конфігу каталогу. Якщо файл існує, він залишається без змін.
-    в. Якщо каталог містить файли Vue і конфігураційний файл Stryker вже існував, виконується аугментація конфігурації. Це додає локальний плагін Vue-макросів до конфігурації Stryker, якщо він відсутній.
-    г. Створюється або оновлюється конфігураційний файл плагіна Vue-макросів.
-    д. Створюється або оновлюється конфігураційний файл Vitest для каталогу, використовуючи фактичне ім'я конфігу.
-6. Виконується гарантія, що файли з результатами тестів Stryker та покриття (lcov) не потрапляють у систему контролю версій. Якщо додаються нові патерни до `.gitignore`, це фіксується як успіх (test.mdc).
-7. Процес завершується з кодом виходу, що відображає успіх або помилку.
+2. Перевіряється, чи у конфігурації дозволено виконання перевірок для JavaScript. Якщо ні, процес завершується з кодом, що вказує на пропуск.
+3. Збираються всі кореневі каталоги, що містять JavaScript-проєкти. Якщо жоден не знайдено, процес завершується з повідомленням про помилку (test.mdc).
+4. Перевіряється наявність усіх канонічних файлів конфігурації (baseline) у системі. Якщо хоча б один відсутній, процес завершується з повідомленням про помилку.
+5. Для кожного знайденого кореневого каталогу проєкту виконується наступне:
+   а. Визначається, чи містить проєкт файли `.vue`.
+   б. Створюється або оновлюється файл `stryker.config.mjs` у корені проєкту, копіюючи відповідний канонічний baseline. У цьому файлі замінюється посилання на конфігурацію Vitest на фактичне ім'я конфігурації проєкту.
+   в. Якщо проєкт містить файли `.vue` і файл `stryker.config.mjs` вже існував, виконується аугментація цього файлу. Аугментація додає плагін `vue-macros` до конфігурації, якщо він відсутній, зберігаючи при цьому форматування користувача.
+   г. Створюється або оновлюється файл `stryker-vue-macros-ignorer.mjs` у корені проєкту.
+   д. Створюється або оновлюється файл конфігурації Vitest у корені проєкту, використовуючи відповідний канонічний baseline.
+6. Виконується гарантування, що файли, що містять артефакти тестів Stryker та покриття (наприклад, `**/reports/stryker/`, `**/coverage/`), додані до `.gitignore` у корені проєкту. Якщо додано нові записи, виводиться повідомлення (test.mdc).
+7. Процес завершується з кодом, що вказує на успішне виконання або на виявлені порушення.
 
 ## Гарантії поведінки
 

package/rules/test/js/docs/vitest-config-pool-forks.md

@@ -10,16 +10,22 @@ docgen:
 
 ## Огляд
 
-Модуль визначає, чи встановлено режим `pool: 'forks'` у конфігураційному файлі Vitest. Перевірка здійснюється у `vitest.config.mjs` або `vitest.config.js` кореневого репозиторію. Це забезпечує коректну поведінку при паралельному запуску тестових файлів. Результат перевірки фіксується у test.mdc.
+Визначає шлях до конфігураційного файлу Vitest. Перевіряє, чи встановлено в цьому файлі `pool: 'forks'`. (test.mdc)
+
+Поведінка:
+
+- Якщо конфігураційний файл не знайдено, завершує роботу з кодом, що вказує на помилку. (test.mdc)
+- Якщо конфігураційний файл знайдено, але в ньому відсутній ключ `pool: 'forks'`, завершує роботу з кодом, що вказує на помилку. (test.mdc)
+- Якщо конфігураційний файл знайдено і містить `pool: 'forks'`, завершує роботу з кодом 0. (test.mdc)
 
 ## Поведінка
 
-1. Визначається назва конфігураційного файлу Vitest, шукаючи спочатку `vitest.config.mjs`, а потім `vitest.config.js` у корені репозиторію.
-2. Якщо конфігураційний файл відсутній, виконується пропуск перевірки, і повертається код успіху.
-3. Якщо конфігураційний файл знайдено, його вміст зчитується.
-4. Перевіряється, чи містить вміст конфігураційного файлу рядок, що вказує на використання `pool: 'forks'`.
-5. Якщо рядок знайдено, фіксується успіх (test.mdc).
-6. Якщо рядок не знайдено, фіксується помилка (test.mdc), оскільки це необхідно для захисту від гонки у `process.cwd` між паралельними тестовими файлами.
+1. Визначається шлях до файлу конфігурації Vitest, шукаючи спочатку `vitest.config.mjs`, а потім `vitest.config.js` у корені репозиторію.
+2. Якщо конфігураційний файл відсутній, виконується пропуск перевірки, і повертається код виходу 0.
+3. Якщо файл знайдено, його вміст зчитується.
+4. Перевіряється, чи містить вміст конфігураційного файлу рядок, що вказує на встановлення `pool: 'forks'`.
+5. Якщо рядок знайдено, виконується успішне повідомлення (test.mdc).
+6. Якщо рядок не знайдено, виконується повідомлення про помилку (test.mdc), що вказує на необхідність додавання `pool: 'forks'` для захисту від гонки в умовах паралельного виконання тестів.
 7. Функція `check` повертає код виходу, що відображає результат перевірки (0 для успіху/пропуску, 1 для помилки).
 
 ## Публічний API

package/scripts/docs/sync-setup-bun-deps-action.md

@@ -10,19 +10,20 @@ docgen:
 
 ## Огляд
 
-Копіює composite GitHub Action `setup-bun-deps` з каталогу `github-actions/setup-bun-deps/` у цільовий репозиторій (`.github/actions/setup-bun-deps/`). Це забезпечує можливість робочим процесам з правил `ga`, `js` та `text` викликати локально розміщений action (`uses: ./.github/actions/setup-bun-deps`) одразу після виконання `actions/checkout@v6`, використовуючи CLI `npx \@nitra/cursor`.
+Копіює composite GitHub Action `setup-bun-deps` з каталогу `github-actions/setup-bun-deps/` у корені tarball пакету `@nitra/cursor` у цільовий репозиторій за шлях `.github/actions/setup-bun-deps/action.yml`. Це забезпечує можливість для workflow з правил `ga`, `js` або `text` викликати цей action для налаштування залежностей Bun одразу після виконання `actions/checkout@v6`.
 
 ## Поведінка
 
 1. Перевіряє наявність шаблону composite action у корені встановленого пакету `@nitra/cursor`.
-2. Створює необхідну директорію для composite action у корені цільового репозиторію, ігноруючи шляхи `.github` та `.git`.
-3. Зчитує вміст шаблону composite action.
-4. Записує вміст шаблону у цільовий шлях composite action у корені цільового репозиторію, гарантуючи наявність завершального символу нового рядка.
+2. Створює необхідну директорію у корені цільового репозиторію для розміщення composite action.
+3. Зчитує вміст шаблону composite action з кореня встановленого пакету.
+4. Записує вміст шаблону composite action у цільовий шлях у корені репозиторію.
 5. Повертає підтвердження успішного запису та повний шлях до файлу.
+6. Не перевіряє шляхи `.github` чи `.git`.
 
 ## Публічний API
 
-syncSetupBunDepsAction — фіксує в `projectRoot` композитну дію з коренем встановленого `@nitra/cursor`.
+syncSetupBunDepsAction — фіксує у `projectRoot` композитну дію, що вказує на корінь встановленого `@nitra/cursor`.
 
 ## Гарантії поведінки
 

package/scripts/lib/docs/inline-template-links.md

@@ -3,305 +3,25 @@ type: JS Module
 title: inline-template-links.mjs
 resource: npm/scripts/lib/inline-template-links.mjs
 docgen:
-  crc: 7726f0ef
+  crc: b659349c
+  model: omlx/gemma-4-e4b-it-OptiQ-4bit
+  score: 100
 ---
 
-Модуль `inline-template-links.mjs` — допоміжна утиліта для **build-кроку обробки `.mdc`-правил**. Її роль: у текстовому вмісті `.mdc`-документа знайти Markdown-посилання, які ведуть на template-файли (шлях містить сегмент `/template/` або `/templates/`), і **замінити** ці посилання на **інлайн fenced-блоки** з фактичним вмістом target-файлу.
+## Огляд
 
-Простими словами: замість того щоб у згенерованому правилі читач бачив посилання `[конфіг](./templates/package.json.snippet.json)`, він побачить безпосередньо назву реального файлу (`package.json`) і fenced-блок із його вмістом — це робить правило «самодостатнім», без потреби клікати по лінках.
+Цей модуль реалізує механізми вбудовування контенту в текстові документи, використовуючи конфігурації з `package.json.snippet.json` та `package.json`. Він замінює посилання в тексті на вміст файлів-шаблонів, розташованих у каталозі правил, а також на вміст файлів з розширенням .mdc, які не є шаблонами. Функції дозволяють вставляти посилання на шаблони (`inlineTemplateLinks`) та включати вміст Markdown (`inlineMarkdownIncludes`).
 
-Особливості:
+## Поведінка
 
-- Працює асинхронно (`async`), бо читає файли через `node:fs/promises`.
-- Робить **fail-loud** валідацію: якщо посилання вказує на неіснуючий файл — кидає `Error` (а не мовчки пропускає), щоб автор правила одразу побачив проблему.
-- «Розгортає» спеціальні суфікси `.snippet.<ext>` / `.deny.<ext>` / `.contains.<ext>` до імені реального target-файлу, який вони описують (наприклад `package.json.snippet.json` → `package.json`).
-- Безпечно щодо ReDoS: усі regexp — статичні літерали з обмеженням довжини, без `new RegExp(variable)` із користувацьких даних.
+inlineTemplateLinks замінює посилання в тексті на вбудовані блоки з вмістом файлів, що містять шаблони, якщо ці файли знаходяться в каталозі правил.
+inlineMarkdownIncludes замінює посилання в тексті на вміст файлів з розширенням .mdc, якщо ці файли не є шаблонами.
 
-Модуль експортує єдину функцію `inlineTemplateLinks(text, ruleDir)`.
+## Публічний API
 
-## Експорти / API
+inlineTemplateLinks — Замінює посилання у Markdown, що містять `/template/`, на вбудовані блокові конструкції, зчитуючи вміст з вказаного файлу. Викидає помилку, якщо цільове посилання не знайдено.
+inlineMarkdownIncludes — Замінює посилання у Markdown, що закінчуються на `.mdc` (і не є шляхом `/template/`), на сирий вміст відповідного файлу Markdown. Викидає помилку, якщо цільове посилання не знайдено.
 
-| Експорт               | Тип                                                              | Призначення                                                                                                         |
-| --------------------- | ---------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------- |
-| `inlineTemplateLinks` | `async function(text: string, ruleDir: string): Promise<string>` | Замінює Markdown-посилання на template-файли в `.mdc`-тексті на інлайн fenced-блоки з фактичним вмістом цих файлів. |
+## Гарантії поведінки
 
-Усі інші імена в модулі (`langFromExt`, `normalizeTargetName`, константи `MD_LINK_RE`, `TEMPLATE_SEGMENT_RE`, `SLOT_SUFFIX_RES`) — **внутрішні** (не експортуються).
-
-## Внутрішні константи
-
-### `MD_LINK_RE`
-
-```js
-;/\[([^\]]{1,200})\]\((\.\/[^)]{1,500})\)/g
-```
-
-Глобальний regexp, який ловить **Markdown-посилання вигляду `[label](./path)`** із обов'язковим префіксом `./` у href. Group 1 — текст посилання (до 200 символів), group 2 — шлях (до 500 символів, що починається з `./`). Обмеження довжин — захист від ReDoS / pathological input.
-
-### `TEMPLATE_SEGMENT_RE`
-
-```js
-;/\/templates?\//
-```
-
-Перевіряє, чи шлях містить сегмент `/template/` або `/templates/`. Тільки такі посилання вважаються «template-посиланнями» і підлягають заміні; інші Markdown-лінки залишаються недоторканими.
-
-### `SLOT_SUFFIX_RES`
-
-Масив із трьох **статичних** regexp:
-
-```js
-;[/^(.+)\.snippet\.[^.]+$/, /^(.+)\.deny\.[^.]+$/, /^(.+)\.contains\.[^.]+$/]
-```
-
-Кожен ловить ім'я файлу з суфіксом-«слотом»: `<name>.snippet.<ext>`, `<name>.deny.<ext>`, `<name>.contains.<ext>`. Group 1 — це ім'я реального target-файлу (без суфікса слоту і без власного розширення). Коментар у коді явно зазначає: regexp-літерали статичні, без `RegExp(variable)`.
-
-## Функції
-
-### `langFromExt(filePath)` — internal
-
-Сигнатура:
-
-```js
-function langFromExt(filePath: string): string
-```
-
-Параметри:
-
-- `filePath` — рядок зі шляхом до файлу (досить навіть базового імені, бо використовується лише розширення).
-
-Повертає:
-
-- Рядок-ідентифікатор мови для Markdown fenced-блока:
-  - `'json'` — якщо розширення `.json`;
-  - `'toml'` — якщо `.toml`;
-  - `'yaml'` — якщо `.yml` або `.yaml`;
-  - `''` (порожній рядок) — для будь-яких інших розширень.
-
-Side effects: жодних — чиста функція над рядком.
-
-Призначення: визначити, який мовний таг ставити після відкривального ` ``` ` у згенерованому fenced-блоці, щоб підсвічування синтаксису працювало коректно.
-
-### `normalizeTargetName(fileBasename)` — internal
-
-Сигнатура:
-
-```js
-function normalizeTargetName(fileBasename: string): string
-```
-
-Параметри:
-
-- `fileBasename` — базове ім'я файлу (без шляху), наприклад `package.json.snippet.json`.
-
-Повертає:
-
-- Якщо ім'я **збігається з одним із regexp у `SLOT_SUFFIX_RES`** (тобто має суфікс `.snippet.<ext>`, `.deny.<ext>` або `.contains.<ext>`) — повертається **group 1** першого збігу (ім'я без слоту). Приклади:
-  - `package.json.snippet.json` → `package.json`
-  - `eslint.config.js.deny.js` → `eslint.config.js`
-  - `Caddyfile.contains.txt` → `Caddyfile`
-- Якщо жоден з regexp не збігся — повертається оригінальне `fileBasename` без змін.
-
-Side effects: відсутні.
-
-Призначення: для template-файлу з суфіксом-слотом відновити **реальне ім'я target-файлу**, на який цей template посилається; саме це ім'я потім підставляється як заголовок перед fenced-блоком у згенерованому Markdown.
-
-Коментар над функцією у вихіднику прямо описує цю поведінку: «Strip `.<slot>.<ext>` suffix (slot ∈ snippet/deny/contains) to recover the real target file name».
-
-### `inlineTemplateLinks(text, ruleDir)` — **exported**
-
-Сигнатура:
-
-```js
-export async function inlineTemplateLinks(
-  text: string,
-  ruleDir: string,
-): Promise<string>
-```
-
-Параметри:
-
-- `text` — вміст `.mdc`-файлу (повний текст) як рядок.
-- `ruleDir` — **абсолютний** шлях до директорії правила (наприклад `.../npm/rules/security/`). Усі відносні href із `./` резолвляться **відносно цього каталогу**.
-
-Повертає:
-
-- `Promise<string>` — трансформований текст, у якому всі **template-посилання** замінено на блоки виду:
-
-  ````text
-  `<targetName>`:
-
-  ```<lang>
-  <contents>
-  ````
-
-  ```
-
-  де `targetName` — результат `normalizeTargetName(basename(absPath))`, `lang` — результат `langFromExt(absPath)`, а `contents` — вміст файлу після `.trim()`.
-
-  ```
-
-- Якщо у тексті немає жодного template-посилання — повертається **той самий `text` без змін** (early-exit).
-
-Алгоритм роботи:
-
-1. Знаходимо **всі** збіги `MD_LINK_RE` у `text` через `text.matchAll(...)`.
-2. Фільтруємо їх: залишаємо лише ті, у яких href (group 2) містить `/template/` або `/templates/` (через `TEMPLATE_SEGMENT_RE.test(m[2])`).
-3. Якщо після фільтрації збігів **немає** — повертаємо `text` як є.
-4. Кладемо стартовий результат `result = text`.
-5. Для кожного збігу послідовно (`for ... of`, з `await` на читанні файлу):
-   1. Деструктуруємо: `const [fullMatch, , href] = match` (label не використовується, тому позиція пропущена).
-   2. Будуємо відносний шлях: `relPath = href.slice(2)` — обрізаємо префікс `./` (його гарантує regexp).
-   3. Збираємо абсолютний шлях: `absPath = join(ruleDir, relPath)`.
-   4. Перевіряємо існування: `existsSync(absPath)`. Якщо файлу немає — **кидаємо** `Error`:
-
-      ```text
-      inlineTemplateLinks: file not found: <absPath> (referenced from .mdc)
-      ```
-
-      Жодного fallback / тихого пропуску — це fail-loud за дизайном.
-
-   5. Читаємо файл: `raw = await readFile(absPath, 'utf8')`, далі `contents = raw.trim()` (прибираємо хвостові пробіли / переноси).
-   6. Обчислюємо `lang = langFromExt(absPath)`.
-   7. Обчислюємо `targetName = normalizeTargetName(basename(absPath))`.
-   8. Формуємо `replacement` — backtick-екранований заголовок, порожній рядок і fenced-блок із `lang`:
-
-      ```js
-      ;`\`${targetName}\`:\n\n\`\`\`${lang}\n${contents}\n\`\`\``
-      ```
-
-   9. Робимо заміну: `result = result.replace(fullMatch, () => replacement)`. Передача **callback-форми** в `.replace` критично важлива: інакше спецсимволи у `replacement` (наприклад `$&`, `$1` із вмісту шаблону) трактувалися б як backreferences і зламали б вивід.
-
-6. Повертаємо `result`.
-
-Side effects:
-
-- **Читання** файлів із диска (синхронна перевірка `existsSync` + асинхронне `readFile`).
-- **Кидання `Error`** при відсутності target-файлу — це навмисна поведінка («fail loud — user must know»), а не баг.
-- Запису на диск або мережевих викликів **не робить**.
-
-Складність та обмеження:
-
-- Цикл лінійний за кількістю template-посилань у тексті; для кожного — один `existsSync` і один `readFile`.
-- Файли читаються **послідовно** (через `await` у тілі `for...of`), а не паралельно через `Promise.all`. Це осмислений вибір: правил, як правило, мало, а послідовність робить порядок помилок передбачуваним.
-- Заміна виконується через простий `result.replace(fullMatch, ...)` — перший збіг `fullMatch` у `result`. Якщо однакове Markdown-посилання трапляється кілька разів — модифікується лише перше входження (фактичний `matchAll` дасть і інші входження, але кожен з них має той самий `fullMatch`, і їх теж замінить — по одному за крок ітерації; для повних дублікатів це працює коректно).
-
-## Залежності
-
-### Стандартна бібліотека Node.js
-
-- `node:fs` → `existsSync` — синхронна перевірка наявності файлу перед читанням.
-- `node:fs/promises` → `readFile` — асинхронне читання вмісту target-файлу як UTF-8.
-- `node:path` → `basename`, `extname`, `join` — робота з шляхами:
-  - `extname` — у `langFromExt` для визначення мови;
-  - `basename` — для отримання базового імені файлу, з якого `normalizeTargetName` витягне target-ім'я;
-  - `join` — для побудови абсолютного шляху від `ruleDir` + `relPath`.
-
-### Зовнішні залежності
-
-Жодних npm-пакетів. Модуль працює лише на Node.js стандарті.
-
-### Споживачі модуля
-
-Файл лежить у `npm/scripts/lib/` поряд із іншими допоміжними утилітами для збірки правил, тому очікувані споживачі — build-скрипти у `npm/scripts/`, які генерують підсумкові `.mdc`-документи для cursor-rules / Claude-rules. Експортована функція `inlineTemplateLinks` викликається на проміжній стадії пайплайна обробки тексту `.mdc`-файлу разом із `ruleDir`, обчисленим від шляху до самого `.mdc`.
-
-## Потік виконання / Використання
-
-Типовий сценарій інтеграції в build-скрипт:
-
-```js
-import { readFile, writeFile } from 'node:fs/promises'
-import { dirname } from 'node:path'
-
-import { inlineTemplateLinks } from './lib/inline-template-links.mjs'
-
-const mdcPath = '/abs/path/to/npm/rules/security/n-security.mdc'
-const original = await readFile(mdcPath, 'utf8')
-
-const ruleDir = dirname(mdcPath) // важливо: каталог, де лежить .mdc
-const transformed = await inlineTemplateLinks(original, ruleDir)
-
-await writeFile(mdcPath, transformed, 'utf8')
-```
-
-Що відбувається крок-за-кроком на прикладі.
-
-Вхідний `.mdc`-фрагмент (`ruleDir = .../npm/rules/security/`):
-
-```text
-Snippet вимоги до `package.json` — див. [тут](./templates/package.json.snippet.json).
-```
-
-Файл `.../npm/rules/security/templates/package.json.snippet.json`:
-
-```json
-{
-  "scripts": {
-    "lint": "eslint ."
-  }
-}
-```
-
-Що зробить `inlineTemplateLinks`:
-
-1. `matchAll(MD_LINK_RE)` знайде один збіг із href `./templates/package.json.snippet.json`.
-2. `TEMPLATE_SEGMENT_RE` пропустить його (бо є `/templates/`).
-3. `relPath = 'templates/package.json.snippet.json'`, `absPath = '.../npm/rules/security/templates/package.json.snippet.json'`.
-4. `existsSync(absPath)` → `true`, файл читається.
-5. `langFromExt(absPath)` → `'json'`.
-6. `normalizeTargetName('package.json.snippet.json')` → `'package.json'` (спрацює regexp `/^(.+)\.snippet\.[^.]+$/`).
-7. `replacement` буде:
-
-   ````text
-   `package.json`:
-
-   ```json
-   {
-     "scripts": {
-       "lint": "eslint ."
-     }
-   }
-   ````
-
-   ```
-
-   ```
-
-8. Результат заміняє оригінальний Markdown-лінк у тексті.
-
-Випадки помилок:
-
-- Якщо `href` веде на неіснуючий файл — кидається `Error` із повним абсолютним шляхом у повідомленні; build-скрипт має право або впасти, або зловити цю помилку.
-- Якщо у `text` немає Markdown-посилань або жодне з них не містить `/template(s)/` — функція повертає `text` без модифікацій.
-- Якщо template-файл має нерозпізнаване розширення (наприклад `.txt` або `.conf`) — `langFromExt` поверне порожній рядок, і fenced-блок буде без мовного тегу (Markdown це допускає).
-- Якщо ім'я template-файлу **не** має одного з суфіксів `.snippet.<ext>` / `.deny.<ext>` / `.contains.<ext>` — `normalizeTargetName` поверне його як є; це нормальна поведінка для «звичайних» template-файлів, у яких саме ім'я і є target-ім'ям.
-
-## Rebuild Test
-
-Якщо видалити цей файл і відтворити його з нуля, мінімально достатній рецепт такий:
-
-1. Створи модуль `inline-template-links.mjs` у `npm/scripts/lib/`.
-2. Імпортуй з `node:fs` функцію `existsSync`, з `node:fs/promises` — `readFile`, з `node:path` — `basename`, `extname`, `join`.
-3. Оголоси константи:
-   - `MD_LINK_RE = /\[([^\]]{1,200})\]\((\.\/[^)]{1,500})\)/g` — глобальний regexp для Markdown-посилань `[label](./path)`.
-   - `TEMPLATE_SEGMENT_RE = /\/templates?\//` — фільтр шляхів, що містять `/template/` чи `/templates/`.
-   - `SLOT_SUFFIX_RES` — масив із трьох **статичних** regexp: `/^(.+)\.snippet\.[^.]+$/`, `/^(.+)\.deny\.[^.]+$/`, `/^(.+)\.contains\.[^.]+$/`. Принципово: жодного `new RegExp(variable)` — захист від ReDoS.
-4. Реалізуй `langFromExt(filePath)`:
-   - `extname(filePath)` → за вмістом повернути `'json' | 'toml' | 'yaml' | ''` (для `.yml` теж `'yaml'`).
-5. Реалізуй `normalizeTargetName(fileBasename)`:
-   - Пройди `SLOT_SUFFIX_RES` у заданому порядку; при першому збігу поверни `match[1]`. Інакше — оригінал.
-6. Експортуй `async function inlineTemplateLinks(text, ruleDir)`:
-   - `matchAll(MD_LINK_RE)` → відфільтруй за `TEMPLATE_SEGMENT_RE.test(href)`.
-   - Якщо нічого не залишилося — поверни `text`.
-   - Для кожного збігу: `relPath = href.slice(2)`, `absPath = join(ruleDir, relPath)`; якщо `!existsSync(absPath)` — `throw new Error('inlineTemplateLinks: file not found: <absPath> (referenced from .mdc)')`.
-   - Читай файл `utf8`, роби `.trim()`, обчисли `lang` і `targetName`, побудуй `replacement = \`\\\`${targetName}\\\`:\\n\\n\\\`\\\`\\\`${lang}\\n${contents}\\n\\\`\\\`\\\``.
-   - Заміни через `result = result.replace(fullMatch, () => replacement)` (саме callback-форма — щоб уникнути інтерпретації `$&`/`$1` у вмісті template-файлу).
-7. Поверни `result`.
-
-Контракт, який має зберегтися:
-
-- Чиста функція над текстом + читання файлів (без записів і без мережі).
-- **Fail-loud** на відсутній target.
-- Підтримка трьох слот-суфіксів: `snippet`, `deny`, `contains`.
-- Підтримка мов підсвічування: `json`, `toml`, `yaml`, інакше — без таргу.
-- Жодного `RegExp(variable)`.
-- Префікс href повинен починатися з `./`, інакше посилання ігнорується (це закладено в `MD_LINK_RE`).
+- Read-only: не виконує операцій запису (ФС/БД).

package/scripts/lib/docs/mirror-parity.md

@@ -3,31 +3,31 @@ type: JS Module
 title: mirror-parity.mjs
 resource: npm/scripts/lib/mirror-parity.mjs
 docgen:
-  crc: d2140a00
+  crc: 5e366df1
   model: omlx/gemma-4-e4b-it-OptiQ-4bit
-  score: 100
+  score: 90
 ---
 
 ## Огляд
 
-Модуль забезпечує паралельність (parity) дзеркал правил. Він порівнює вміст дзеркала `.cursor/rules/n-<id>.mdc` з канонічним вмістом `npm/rules/<id>/<id>.mdc`, який містить вбудовані шаблони (inlined-шаблони). Це гарантує, що локальні копії правил відповідають централізованим, трансформованим версіям, виявляючи дрейф, що виникає при зміні канонічного `.mdc` без регенерації дзеркала.
+Модуль порівнює вміст дзеркал правил (`.cursor/rules/n-<id>.mdc`) з канонічними версіями (`npm/rules/<id>/<id>.mdc`), які містять застосовані трансформації (трансформ, що застосовує `readBundledRuleContent` $\to$ `inlineTemplateLinks`). Він визначає список керованих дзеркал, формує очікуваний вміст для кожного дзеркала та виявляє дрейф — відхилення фактичного вмісту від очікуваного.
 
 ## Поведінка
 
 listManagedMirrors
-Визначає список керованих дзеркал правил, які мають канонічне джерело у `npm/rules`.
+Визначає список керованих дзеркал правил, які мають відповідне канонічне джерело у `npm/rules`.
 
 expectedMirrorContent
-Формує очікуваний вміст дзеркала, застосовуючи трансформацію до канонічного вмісту.
+Формує очікуваний вміст дзеркала, застосовуючи трансформації до канонічного файлу.
 
 findMirrorDrift
-Виявляє і повертає список ідентифікаторів дзеркал, вміст яких відрізняється від очікуваного канонічного.
+Виявляє ідентифікатори дзеркал, чий фактичний вміст відрізняється від очікуваного вмісту, отриманого з канону.
 
 ## Публічний API
 
-listManagedMirrors — перераховує дзеркала, які мають визначене основне джерело, і ігнорує зовнішні.
-expectedMirrorContent — визначає, яким має бути вміст дзеркала, використовуючи основне джерело з вбудованими шаблонами.
-findMirrorDrift — виявляє ідентифікатори дзеркал, чий фактичний вміст відрізняється від очікуваного.
+listManagedMirrors — перераховує керовані дзеркала, які мають визначене канонічне джерело.
+expectedMirrorContent — визначає бажаний вміст дзеркала, використовуючи канон із вбудованими шаблонами.
+findMirrorDrift — знаходить ідентифікатори дзеркал, у яких фактичний вміст відрізняється від очікуваного.
 
 ## Гарантії поведінки
 

package/scripts/lib/docs/timing-summary.md

@@ -5,22 +5,22 @@ resource: npm/scripts/lib/timing-summary.mjs
 docgen:
   crc: 47660e16
   model: omlx/gemma-4-e4b-it-OptiQ-4bit
-  score: 100
+  score: 95
 ---
 
 ## Огляд
 
-Формує рядок, що відображає тривалість у форматі `<ціла>.<десята>s`, забезпечуючи стабільну одиницю вимірювання для всіх інтервалів. Генерує звіт про час виконання для orchestrator `fix` / `lint`, який включає деталі кожного вимірювання та загальний час. Звіт містить маркер `❌` на рядку, якщо відповідний вимірник не пройшов успішно. Дані для звітів отримуються з `package.json` та використовуються у точках виклику `runFixCommand` у `bin/n-cursor.js` та `runLintCli` у `scripts/lib/run-lint-cli.mjs`. Функція є чистою, не виконує I/O, і повертає готовий рядок з фінальним `\n`, друк якого здійснюється на стороні виклику.
+Форматує тривалість у форматі `<ціла>.<десята>s`. Генерує таблицю-резюме часу виконання для оркестратора `fix` або `lint`, яка включає детальні записи та загальний час прогону. Таблиця містить маркер `❌` для позначення невдач. Функція повертає готовий рядок із фінальним `\n`; друк здійснюється на стороні виклику.
 
 ## Поведінка
 
-formatDurationMs форматує тривалість у мілісекундах як рядок у форматі `<ціла>.<десята>s`.
-formatTimingSummary генерує багаторядковий текстовий звіт про час виконання, включаючи деталі кожного запису та загальний час.
+formatDurationMs форматує тривалість у мілісекундах у рядок у форматі `<ціла>.<десята>s`.
+formatTimingSummary генерує багаторядковий рядок із таблицею-резюме часу виконання, включаючи окремі записи та загальний час.
 
 ## Публічний API
 
-⏱ formatDurationMs: Перетворює мілісекунди у формат `<sec>.<десята>s`, використовуючи округлення вниз.
-⏱ formatTimingSummary: Генерує багаторядковий вивід таблиці-резюме часу виконання.
+⏱ formatDurationMs: Перетворює мілісекунди у формат `<sec>.<десята>s`, використовуючи нижнє округлення для забезпечення консистентності виводу.
+⏱ formatTimingSummary: Генерує багаторядковий текстовий звіт про час виконання, структурований як таблиця з сумарними даними.
 
 ## Гарантії поведінки
 

package/scripts/lib/inline-template-links.mjs

@@ -4,6 +4,7 @@ import { basename, extname, join } from 'node:path'
 
 const MD_LINK_RE = /\[([^\]]{1,200})\]\((\.\/[^)]{1,500})\)/g
 const TEMPLATE_SEGMENT_RE = /\/templates?\//
+const MDC_EXT_RE = /\.mdc$/
 /** Статичні regexp-літерали `^(.+)\.<slot>\.<ext>$` — без `RegExp(variable)`. */
 const SLOT_SUFFIX_RES = [/^(.+)\.snippet\.[^.]+$/, /^(.+)\.deny\.[^.]+$/, /^(.+)\.contains\.[^.]+$/]
 
@@ -66,3 +67,33 @@ export async function inlineTemplateLinks(text, ruleDir) {
 
   return result
 }
+
+/**
+ * Finds markdown links whose href ends with `.mdc` (and is not a /template/ path) and
+ * replaces them with the raw markdown content of the linked file (no fencing).
+ * Intended for per-concern section files living alongside their .mjs implementations.
+ * Throws Error if a matched link target doesn't exist (fail loud).
+ * @param {string} text .mdc file contents (after inlineTemplateLinks)
+ * @param {string} ruleDir absolute path to the rule directory
+ * @returns {Promise<string>} transformed text
+ */
+export async function inlineMarkdownIncludes(text, ruleDir) {
+  const matches = [...text.matchAll(MD_LINK_RE)].filter(m => MDC_EXT_RE.test(m[2]) && !TEMPLATE_SEGMENT_RE.test(m[2]))
+  if (matches.length === 0) return text
+
+  let result = text
+  for (const match of matches) {
+    const [fullMatch, , href] = match
+    const relPath = href.slice(2) // strip leading ./
+    const absPath = join(ruleDir, relPath)
+
+    if (!existsSync(absPath)) {
+      throw new Error(`inlineMarkdownIncludes: file not found: ${absPath} (referenced from .mdc)`)
+    }
+
+    const raw = await readFile(absPath, 'utf8')
+    result = result.replace(fullMatch, () => raw.trim())
+  }
+
+  return result
+}

package/scripts/lib/mirror-parity.mjs

@@ -9,7 +9,7 @@
 import { existsSync, readdirSync, readFileSync } from 'node:fs'
 import { dirname, join } from 'node:path'
 
-import { inlineTemplateLinks } from './inline-template-links.mjs'
+import { inlineMarkdownIncludes, inlineTemplateLinks } from './inline-template-links.mjs'
 
 const MIRROR_PREFIX = 'n-'
 const MDC_EXT = '.mdc'
@@ -41,8 +41,10 @@ export function listManagedMirrors(repoRoot) {
  * @param {string} canonicalPath абсолютний шлях `npm/rules/<id>/<id>.mdc`
  * @returns {Promise<string>} очікуваний текст дзеркала
  */
-export function expectedMirrorContent(canonicalPath) {
-  return inlineTemplateLinks(readFileSync(canonicalPath, 'utf8'), dirname(canonicalPath))
+export async function expectedMirrorContent(canonicalPath) {
+  const dir = dirname(canonicalPath)
+  const withTemplates = await inlineTemplateLinks(readFileSync(canonicalPath, 'utf8'), dir)
+  return inlineMarkdownIncludes(withTemplates, dir)
 }
 
 /**

package/scripts/utils/docs/resolve-js-root.md

@@ -10,17 +10,17 @@ docgen:
 
 ## Огляд
 
-Визначає корінь JS-коду для проєктів, використовуючи `package.json` та `.n-cursor.json` як конфігураційні файли. Функція `resolveJsRoot` знаходить перший workspace (з підтримкою glob-патернів типу `cf/*`) для workspace-проєктів або корінь поточної директорії для single-package. Функція `resolveAllJsRoots` знаходить усі відповідні шляхи. Код свідомо ігнорує шляхи `.git` та `node_modules`. Ця утиліта є спільною для coverage-провайдера JS та test-концерну stryker_config (DRY).
+Визначає корінь JS-коду в проєкті, відповідно до логіки для workspace-projects (перший workspace з підтримкою glob-патернів `cf/*`) або single-package (корінь cwd). Ця утиліта є спільною для coverage-провайдера JS та test-концерну `stryker_config` (DRY). Публічні функції дозволяють отримати один або повний список шляхів до всіх JS-коренів, при цьому свідомо виключаються каталоги `.git` та `node_modules`. Код спирається на конфігураційні файли `package.json` та `.n-cursor.json`.
 
 ## Поведінка
 
-resolveJsRoot повертає абсолютний шлях до першого JS-кореня проєкту, якщо він існує, або null, якщо кореневий package.json відсутній.
-resolveAllJsRoots повертає масив абсолютних шляхів до всіх JS-коренів проєкту, враховуючи визначення `workspaces` у кореневому package.json, ігноруючи каталоги `.git` та `node_modules`.
+resolveJsRoot повертає абсолютний шлях до першого JS-кореня проєкту. Якщо кореневий `package.json` відсутній, повертає null.
+resolveAllJsRoots повертає масив абсолютних шляхів до всіх JS-коренів проєкту. Ігнорує каталоги `.git` та `node_modules`.
 
 ## Публічний API
 
 resolveJsRoot — знаходить кореневий каталог JavaScript-проєкту.
-resolveAllJsRoots — повертає шляхи до коренів усіх JavaScript-проєктів у робочому просторі.
+resolveAllJsRoots — повертає всі каталоги JavaScript-проєктів у робочому просторі.
 
 ## Гарантії поведінки
 

package/types/bin/n-cursor.d.ts

@@ -1,2 +1,2 @@
 #!/usr/bin/env node
-export {}
+export {};