@nitra/cursor 12.8.3 → 12.8.5

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

@@ -3,210 +3,32 @@ type: JS Module
 title: utils_imports.mjs
 resource: npm/rules/js/js/utils_imports.mjs
 docgen:
-  crc: 7eaeaf96
+  crc: 3fc9bf1b
+  model: omlx/gemma-4-e4b-it-OptiQ-4bit
+  score: 100
 ---
 
-Модуль `npm/rules/js/js/utils_imports.mjs` реалізує одну з перевірок правила `js.mdc`: жоден файл усередині будь-якого каталогу з ім'ям `utils/` не має імпортувати щось за межами цього самого каталогу через відносні шляхи з префіксом `..`.
+## Огляд
 
-Філософія перевірки:
+Модуль сканує монорепозиторій для пошуку каталогів `utils` та аналізу їхнього вмісту. Аналіз файлів JS/TS у цих каталогах здійснюється на відповідність шаблону забороненого відносного імпорту, що базується на конфігурації, визначеній у `.n-cursor.json`. При виявленні порушень, система генерує повідомлення, позначене як (js.mdc).
 
-- Каталог `utils/` за конвенцією тримає **generic helpers** — функції без бізнес-логіки, без знання про домен, без залежностей від конфігів конкретного проєкту.
-- Якщо файлу треба сусідній модуль (наприклад, `lib/foo.mjs` чи cross-rule helper) — він мусить переїхати у `lib/`, а не отримувати доступ через `../lib/foo.mjs`.
-- Дозволені імпорт-джерела: `./X`, `./sub/X` (свій каталог чи глибше), bare-package (`oxc-parser`, `@scope/pkg`), Node-builtin (`node:fs`, `fs`).
-- Заборонено будь-який `..`-шлях (`../X`, `../../X`, ...).
+## Поведінка
 
-Перевірка проходить по всьому monorepo: знаходить package-roots, у кожному рекурсивно шукає каталоги `utils/`, з кожного збирає не-тестові джерела (без `tests/` і `__fixtures__/`), парсить їх через `oxc-parser`, витягає всі імпорти (статичні, динамічні, `require(...)`) і логує fail-репорт для кожного імпорту з `..`-префіксом.
+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).
 
-Файл є точкою входу check-runner-а (CI-чи-локальний прогон): експортує одну async-функцію `check()`, яка повертає exit-code.
+## Гарантії поведінки
 
-## Експорти / API
-
-| Експорт | Тип                     | Призначення                                                                                           |
-| ------- | ----------------------- | ----------------------------------------------------------------------------------------------------- |
-| `check` | `() => Promise<number>` | named export; запускає перевірку від `process.cwd()` і повертає `0` (OK) або `1` (знайдено порушення) |
-
-Усе інше — приватні helpers модуля без `export`.
-
-## Функції
-
-### `isIgnored(dir, ignorePaths)`
-
-Перевіряє, чи каталог входить у список ignore (точний збіг або префіксне співпадіння).
-
-- **Сигнатура:** `function isIgnored(dir: string, ignorePaths: string[]): boolean`
-- **Параметри:**
-  - `dir` — абсолютний posix-шлях каталогу.
-  - `ignorePaths` — масив абсолютних posix-шляхів, отриманих з `.n-cursor.json` через `loadCursorIgnorePaths`.
-- **Повертає:** `true`, якщо `dir` дорівнює якомусь елементу `ignorePaths` або починається з нього + `/`; інакше `false`.
-- **Side effects:** немає.
-
-### `findUtilsDirs(root, ignorePosix)`
-
-Рекурсивно шукає всі каталоги з ім'ям `utils` під `root`.
-
-- **Сигнатура:** `async function findUtilsDirs(root: string, ignorePosix: string[]): Promise<string[]>`
-- **Параметри:**
-  - `root` — абсолютний шлях кореня обходу (зазвичай корінь package).
-  - `ignorePosix` — список абсолютних posix-шляхів, які пропускати.
-- **Повертає:** масив абсолютних шляхів знайдених `utils/`-каталогів. Порядок — результат DFS у тому ж порядку, в якому повертає `readdir`.
-- **Алгоритм:**
-  - Вкладена рекурсивна функція `walk(dir)` читає `readdir(dir, { withFileTypes: true })`.
-  - Помилка `readdir` (наприклад, нема прав чи каталог зник) проглинається через `try/catch` і дає ранній `return`.
-  - Для кожного запису-каталогу:
-    - якщо ім'я входить у `SKIP_DIR_NAMES` (`node_modules`, `.git`, `dist`, `coverage`, `.turbo`, `.next`, `__fixtures__`) — скіп;
-    - повний шлях конвертується у posix і перевіряється через `isIgnored` — скіп якщо так;
-    - якщо ім'я — рівно `utils`, додається у `found` і **не** заходить глибше (вкладені `utils/utils/` не очікуються; навіть якщо є — внутрішній `utils/` усе одно під самим `utils/` і його файли все одно пройдуть як файли зовнішнього `utils/`);
-    - інакше — рекурсивно `walk(full)`.
-- **Side effects:** filesystem-чтення.
-
-### `collectUtilsSources(utilsDir)`
-
-Збирає всі не-тестові source-файли під `utilsDir`.
-
-- **Сигнатура:** `async function collectUtilsSources(utilsDir: string): Promise<string[]>`
-- **Параметри:** `utilsDir` — абсолютний шлях каталогу `utils/`.
-- **Повертає:** масив абсолютних шляхів файлів-джерел.
-- **Фільтри:**
-  - Каталоги `tests/`, `__fixtures__/` і будь-що з `SKIP_DIR_NAMES` — пропускаються (тести легально мають імпорти `../X` до свого модуля).
-  - Файли мають матчити `JS_SOURCE_RE` (`.mjs`, `.mts`, `.cjs`, `.cts`, `.js`, `.ts`, `.jsx`, `.tsx`).
-  - Файли, що матчать `TEST_FILE_RE` (`*.test.*`), — виключаються.
-- **Алгоритм:** аналогічний DFS через вкладену `walk(dir)` з тим самим проглинанням помилок `readdir`.
-- **Side effects:** filesystem-чтення.
-
-### `extractImportSources(source, filePath)`
-
-Витягає всі рядкові імпорт-source з тексту файлу.
-
-- **Сигнатура:** `function extractImportSources(source: string, filePath: string): string[]`
-- **Параметри:**
-  - `source` — текст файлу (UTF-8).
-  - `filePath` — шлях до файлу, потрібен для визначення мови парсингу через `langFromPath`.
-- **Повертає:** масив рядків — значення source кожного імпорту в тому вигляді, в якому вони записані в коді (`'./foo'`, `'../bar'`, `'oxc-parser'`, ...).
-- **Що збирає:**
-  - **Статичні імпорти** — з `parsed.module.staticImports[*].moduleRequest.value` (oxc-parser API).
-  - **Динамічні імпорти** (`import('...')`) — через `dynamicImportModule(node)` під час обходу AST.
-  - **CommonJS `require('...')`** — через `requireCallModule(node)`.
-- **Обробка помилок парсингу:** `try/catch` на `parseSync` повертає порожній масив і **не** падає, бо синтаксична помилка — окремий концерн іншої перевірки; ця має запуститись чисто і не блокувати решту.
-- **Side effects:** немає (виклик `parseSync` — CPU-only).
-
-### `check()` (named export)
-
-Точка входу. Виконує всю перевірку від поточного робочого каталогу.
-
-- **Сигнатура:** `export async function check(): Promise<number>`
-- **Параметри:** немає; використовує `process.cwd()` як корінь monorepo.
-- **Повертає:** `0` — порушень немає; `1` — є хоча б одне (реальний exit-code обчислює `reporter.getExitCode()`).
-- **Покроковий алгоритм:**
-  1. Створити `reporter` через `createCheckReporter()`.
-  2. `root = process.cwd()`.
-  3. Завантажити `ignorePaths` з `.n-cursor.json` (`loadCursorIgnorePaths`) і перевести у posix-варіант (`ignorePosix`).
-  4. Отримати relative-paths package-roots monorepo через `getMonorepoPackageRootDirs(root)`.
-  5. Для кожного package-root знайти всі `utils/`-каталоги (`findUtilsDirs`) і покласти у `Set` (`utilsDirSet`) для де-дуплікації.
-  6. Якщо `utils/`-каталогів немає взагалі — `reporter.pass(...)` з повідомленням про пропуск і повернути exit-code.
-  7. Інакше пройти кожен `utils/`-каталог:
-     - зібрати джерела (`collectUtilsSources`);
-     - для кожного файлу прочитати контент, витягти імпорти (`extractImportSources`);
-     - кожен import з префіксом `..` — `reporter.fail(...)` з relative-шляхом файлу та порушеним import-source, інкремент `violations`;
-     - `checkedFiles` рахує всі перевірені файли.
-  8. Якщо `violations === 0` — `reporter.pass(...)` зі статистикою (кількість utils-каталогів і файлів).
-  9. Повернути `reporter.getExitCode()`.
-- **Side effects:**
-  - filesystem-чтення (рекурсивне сканування + `readFile`);
-  - запис у `reporter` (виводить рядки у stdout/stderr, залежно від реалізації);
-  - читає `process.cwd()`.
-
-## Залежності
-
-### Node-builtin
-
-- `node:fs/promises` — `readdir`, `readFile`.
-- `node:path` — `join`, `relative`, `sep`.
-
-### npm-пакет
-
-- `oxc-parser` — `parseSync` для парсингу JS/TS у AST з достовірною підтримкою сучасних синтаксисів (zero-config).
-
-### Внутрішні модулі проєкту
-
-- `../../../scripts/lib/check-reporter.mjs` → `createCheckReporter` — фабрика репортера; має методи `pass`, `fail`, `getExitCode`. Уніфікований API для всіх check-функцій.
-- `../../../scripts/lib/load-cursor-config.mjs` → `loadCursorIgnorePaths` — читає `.n-cursor.json` (чи аналог) і повертає масив абсолютних шляхів, які треба пропустити.
-- `../../../scripts/lib/workspaces.mjs` → `getMonorepoPackageRootDirs` — повертає relative-paths коренів пакетів у monorepo (включно з `.`-коренем, якщо це теж пакет).
-- `../../../scripts/utils/ast-scan-utils.mjs`:
-  - `langFromPath(filePath)` — мапить розширення файлу у `lang`-параметр для `oxc-parser`.
-  - `walkAstWithAncestors(program, ancestors, visitor)` — обхід AST з трекінгом предків.
-  - `dynamicImportModule(node)` — повертає рядок source для `import('...')`, або `null`.
-  - `requireCallModule(node)` — повертає рядок source для `require('...')`, або `null`.
-
-### Константи модуля
-
-| Ім'я                 | Значення                                                                               | Призначення                                                          |
-| -------------------- | -------------------------------------------------------------------------------------- | -------------------------------------------------------------------- | ------------------------------------------------------------------------------------ |
-| `JS_SOURCE_RE`       | `/\.(?:[cm]?[jt]sx?)$/u`                                                               | матчить `.mjs`, `.mts`, `.cjs`, `.cts`, `.js`, `.ts`, `.jsx`, `.tsx` |
-| `TEST_FILE_RE`       | `/\.test\.[cm]?[jt]sx?$/u`                                                             | матчить `*.test.{js,ts,...}` для виключення тестів                   |
-| `PARENT_RELATIVE_RE` | `/^\.\.(?:\/                                                                           | $)/u`                                                                | матчить `..` як цілий сегмент (`..` або `../*`); відсіює false-positive типу `..foo` |
-| `SKIP_DIR_NAMES`     | `Set(['node_modules', '.git', 'dist', 'coverage', '.turbo', '.next', '__fixtures__'])` | каталоги, які скіпаємо при обходах                                   |
-
-## Потік виконання / Використання
-
-### Інтеграція в перевірочний рантайм
-
-Модуль викликається check-runner-ом правила `js.mdc` (зазвичай із `npm/rules/js/js/`). Runner імпортує named export `check` і чекає на її resolved-значення як на process exit-code. Сам файл **не** має top-level executable коду — лише визначення; це дозволяє безпечно імпортувати його у тестах.
-
-Типовий виклик (псевдокод):
-
-```mjs
-import { check } from './utils_imports.mjs'
-
-const exitCode = await check()
-process.exit(exitCode)
-```
-
-### Сценарій "усе чисто"
-
-1. Runner запускається з кореня monorepo.
-2. `check()` знаходить `utils/` каталоги в усіх package-roots.
-3. Для кожного non-test source файлу витягає імпорти.
-4. Жоден імпорт не починається з `..`.
-5. `reporter.pass('utils-каталогів: N, перевірено M файлів — domain-bound імпортів немає (js.mdc)')`.
-6. `getExitCode() → 0`.
-
-### Сценарій "є порушення"
-
-1. Знайдено файл `packages/foo/utils/helper.mjs`.
-2. У ньому є `import bar from '../lib/bar.mjs'`.
-3. `PARENT_RELATIVE_RE` матчить `../lib/bar.mjs`.
-4. `reporter.fail('packages/foo/utils/helper.mjs: заборонений імпорт \'../lib/bar.mjs\' — utils/-файли мають бути generic (js.mdc)')`.
-5. `violations` інкрементується.
-6. По завершенню `getExitCode() → 1`.
-
-### Сценарій "немає utils/"
-
-1. У жодному package немає каталогу `utils/`.
-2. `utilsDirSet.size === 0`.
-3. `reporter.pass('utils-каталогів немає — перевірку пропущено (js.mdc)')`.
-4. `getExitCode() → 0`.
-
-### Сценарій "файл із синтаксичною помилкою"
-
-1. `parseSync` кидає виключення.
-2. `extractImportSources` ловить його у `try/catch` і повертає `[]`.
-3. Цей файл не дає порушень. Проблему синтаксису ловить інша перевірка.
-
-### Сценарій "ignore-шлях"
-
-1. У `.n-cursor.json` зазначено абсолютний шлях, що покриває певний `utils/`-каталог.
-2. `findUtilsDirs` через `isIgnored` пропускає його ще на стадії обходу — той `utils/` навіть не потрапляє у `utilsDirSet`.
-
-### Особливості/edge cases
-
-- **Тести**: каталог `tests/` усередині `utils/` ігнорується повністю; також ігноруються файли `*.test.{js,ts,...}` будь-де всередині `utils/`. Це свідомо: тести легально імпортують свій модуль через `../X`.
-- **`__fixtures__/`**: ігнорується і в `findUtilsDirs`, і в `collectUtilsSources` — фікстури можуть бути будь-якими.
-- **Bare-imports** (`oxc-parser`, `node:fs`): не відсіюються спеціально, бо просто не матчать `PARENT_RELATIVE_RE`.
-- **Same-dir імпорти** (`./X`): дозволені автоматично з тієї ж причини.
-- **POSIX-шляхи для ignore**: під Windows `sep` — `\\`, тому шляхи нормалізуються у `/`-формат перед порівнянням з ignore-конфігом.
-- **De-duplication** через `Set`: якщо monorepo-структура повертає однаковий `utils/`-шлях двічі (наприклад, `.`-root і назва вкладеного пакета перетинаються), він обробиться лише раз.
-- **Помилки `readdir`** глушаться — недоступний каталог просто пропускається без падіння всієї перевірки.
-
-### Залежність від конвенцій правила `js.mdc`
-
-Файл є технічною реалізацією одного з пунктів правила `js.mdc`. Усі повідомлення `reporter.pass/fail` посилаються на `(js.mdc)`, щоб користувач знав, де читати про сам принцип розділу `utils/` ↔ `lib/`.
+- Read-only: не виконує операцій запису (ФС/БД).
+- Перехоплює помилки і не пропускає винятків назовні (fail-safe).
+- Свідомо пропускає шляхи: `.git`, `node_modules`.

package/rules/npm-module/js/docs/index.md

@@ -6,9 +6,9 @@ resource: npm/rules/npm-module/js/
 
 # npm/rules/npm-module/js
 
-| Файл                                            | Тип       |
-| ----------------------------------------------- | --------- |
+| Файл | Тип |
+|---|---|
 | [header_doc_pointer.mjs](header_doc_pointer.md) | JS Module |
-| [package_structure.mjs](package_structure.md)   | JS Module |
-| [rule_meta.mjs](rule_meta.md)                   | JS Module |
-| [skill_meta.mjs](skill_meta.md)                 | JS Module |
+| [package_structure.mjs](package_structure.md) | JS Module |
+| [rule_meta.mjs](rule_meta.md) | JS Module |
+| [skill_meta.mjs](skill_meta.md) | JS Module |

package/rules/npm-module/js/docs/rule_meta.md

@@ -3,31 +3,31 @@ type: JS Module
 title: rule_meta.mjs
 resource: npm/rules/npm-module/js/rule_meta.mjs
 docgen:
-  crc: 938ccd0a
+  crc: 84394694
   model: omlx/gemma-4-e4b-it-OptiQ-4bit
   score: 100
 ---
 
 ## Огляд
 
-Модуль перевіряє конфігурацію правил, розташованих у каталозі `npm/rules`. Він забезпечує наявність обов'язкового файлу `scripts.mdc` для кожного правила. Крім того, він валідує структуру метаданих у `meta.json`, перевіряючи відповідність полів, таких як `auto` та `lint`, визначеним контрактам. У процесі перевірки використовуються маркери повідомлень (scripts.mdc).
+Модуль перевіряє конфігурації правил, розташованих у каталозі `npm/rules`. Він гарантує, що кожен підкаталог правила містить необхідні файли, включаючи маркери повідомлень (`scripts.mdc`), та коректно структурований конфігураційний файл, що базується на `main.json` та `meta.json`. Перевірка включає валідацію визначених предикатів та експортованих функцій відповідно до очікуваного контракту.
 
 ## Поведінка
 
-1. Викликати `check` для початку валідації.
-2. Перевірити наявність каталогу `npm/rules` у корені репозиторію. Якщо каталог відсутній, валідація завершується успішно.
-3. Для кожного підкаталогу у `npm/rules` (який представляє правило):
-   а. Перевірити наявність файлу `auto.md`. Якщо він присутній, реєструється помилка, оскільки метадані тепер знаходяться у `meta.json`.
-   б. Перевірити наявність файлу `<id>.mdc` у каталозі правила. Якщо він відсутній, реєструється помилка, оскільки це обов'язковий файл (scripts.mdc).
-   в. Зчитати вміст `meta.json` правила. Якщо файл відсутній або невалідний, реєструється помилка, і перевірка цього правила припиняється.
-   г. Перевірити поле `auto` у `meta.json`. Якщо поле `auto` присутнє, воно повинно бути валідним (відповідати одному з визначених форматів, або бути відсутнім). Якщо поле `auto` містить невідомий предикат, реєструється помилка.
-   ґ. Перевірити поле `lint` у `meta.json`. Якщо поле `lint` присутнє, воно повинно бути валідним (відповідати "per-file" або "full"). Також перевіряється, чи експортує файл `main.mjs` у каталозі правила функцію `lint` відповідно до зазначеного значення `lint`.
-   і. Якщо всі перевірки для правила пройшли успішно, реєструється повідомлення про валідність `meta.json`.
-4. Після обробки всіх правил, повертається код виходу, що відображає загальний статус валідації.
+1. Перевіряє наявність каталогу `npm/rules` у корені репозиторію. Якщо каталог відсутній, завершує роботу, повідомляючи про відсутність правил для валідації.
+2. Ітерує по всім підкаталогах у `npm/rules`, ігноруючи приховані каталоги.
+3. Для кожного каталогу виконує перевірку правила:
+    а. Перевіряє відсутність файлу `auto.md`. Якщо знайдено, повідомляє про залишковий файл.
+    б. Перевіряє наявність файлу `main.mdc`. Якщо відсутній, повідомляє про відсутність обов'язкового файлу (scripts.mdc).
+    в. Зчитує вміст `main.json` каталогу правила. Якщо файл відсутній або невалідний, повідомляє про це та пропускає подальшу валідацію цього правила.
+    г. Перевіряє поле `auto` у `main.json`. Якщо поле присутнє, валідує його структуру та перевіряє, чи всі використані предикати визначені.
+    ґ. Перевіряє поле `lint` у `main.json`. Якщо поле присутнє, валідує його структуру та перевіряє, чи експортує файл `main.mjs` відповідну функцію `lint`.
+    і. Якщо всі перевірки для правила пройдені успішно, повідомляє про валідність `main.json`.
+4. Після обробки всіх правил повертає код виходу, що відображає загальний статус валідації.
 
 ## Публічний API
 
-check — перевіряє відповідність усіх файлів `npm/rules/<id>/meta.json` встановленим критеріям.
+check — перевіряє відповідність усіх `npm/rules/<id>/meta.json` вимогам.
 
 ## Гарантії поведінки
 

package/rules/npm-module/js/docs/skill_meta.md

@@ -3,24 +3,34 @@ type: JS Module
 title: skill_meta.mjs
 resource: npm/rules/npm-module/js/skill_meta.mjs
 docgen:
-  crc: a069397b
+  crc: d02dd00d
+  model: omlx/gemma-4-e4b-it-OptiQ-4bit
   score: 100
 ---
 
-Перевірка стану конфігурації. Файл перевіряє відповідність між полями worktree та requireRoot. Перевірка спирається на конфіги meta.json.
+## Огляд
+
+Перевіряє структуру та конфігурацію скілів у каталозі `npm/skills`, використовуючи правила, визначені в `meta.json`. Валідує, що кожен скіл не містить файлу `auto.md`. Перевіряє валідність полів `worktree`, `auto` та `requireRoot` у `main.json` кожного скіла.
 
 ## Поведінка
 
-1. Перевірка поля worktree
-2. Перевірка поля auto
-3. Перевірка поля requireRoot
-4. Перевірка суперечності between worktree та requireRoot
+1. Перевіряє наявність каталогу `npm/skills` у поточному робочому каталозі. Якщо каталог відсутній, операція завершується успішно.
+2. Ітерує по всіх підкаталогах у `npm/skills`.
+3. Для кожного підкаталогу виконується перевірка метаданих скіла:
+    а. Перевіряється наявність файлу `auto.md` у каталозі скіла. Якщо він присутній, це вважається порушенням.
+    б. Зчитується вміст `main.json` скіла. Якщо файл відсутній або невалідний, перевірка для цього скіла припиняється.
+    в. Виконується перевірка полів `main.json` скіла:
+        i. `worktree` має бути булевим значенням.
+        ii. Якщо поле `auto` визначене, його вміст має бути розпізнаним як "завжди" або непорожній масив правил.
+        iii. `requireRoot` має бути булевим значенням, якщо визначений.
+        iv. Якщо `worktree` встановлено як `true`, а `requireRoot` як `false`, це вважається порушенням.
+    г. Якщо всі поля `main.json` валідні, це вважається успішним результатом для скіла.
+4. Після перевірки всіх скілів повертається код виходу, що відображає загальний статус (0 — успіх, 1 — порушення).
 
 ## Публічний API
 
-check — Валідує всі `npm/skills/<id>/meta.json`.
+check — перевіряє відповідність усіх файлів `meta.json` у каталозі `npm/skills/<id>/` заданим критеріям.
 
 ## Гарантії поведінки
 
-- Read-only: файл не виконує операцій запису у файлову систему.
-- Не звертається до мережі.
+- Read-only: не виконує операцій запису (ФС/БД).

package/rules/npm-module/js/rule_meta.mjs

@@ -17,11 +17,11 @@ function checkAutoField(id, raw, reporter) {
   if (raw.auto === undefined) return true
   const spec = parseRuleAutoSpec(raw.auto)
   if (spec === null) {
-    reporter.fail(`rules/${id}: meta.json.auto нерозпізнане (очікується "завжди" / масив / {glob} / {predicate})`)
+    reporter.fail(`rules/${id}: main.json.auto нерозпізнане (очікується "завжди" / масив / {glob} / {predicate})`)
     return false
   }
   if ('predicate' in spec && !Object.hasOwn(RULE_PREDICATES, spec.predicate)) {
-    reporter.fail(`rules/${id}: невідомий predicate "${spec.predicate}" (немає в RULE_PREDICATES)`)
+    reporter.fail(`rules/${id}: main.json — невідомий predicate "${spec.predicate}" (немає в RULE_PREDICATES)`)
     return false
   }
   return true
@@ -38,7 +38,7 @@ function checkAutoField(id, raw, reporter) {
 function checkLintField(id, ruleDir, raw, reporter) {
   if (raw.lint === undefined) return true
   if (parseRuleLintSpec(raw.lint) === null) {
-    reporter.fail(`rules/${id}: meta.json.lint нерозпізнане (очікується "per-file"|"full")`)
+    reporter.fail(`rules/${id}: main.json.lint нерозпізнане (очікується "per-file"|"full")`)
     return false
   }
   const mainPath = join(ruleDir, 'main.mjs')
@@ -63,19 +63,19 @@ function checkRule(id, ruleDir, reporter) {
   let ruleOk = true
 
   if (existsSync(join(ruleDir, 'auto.md'))) {
-    reporter.fail(`rules/${id}: залишковий auto.md — видали (метадані тепер у meta.json)`)
+    reporter.fail(`rules/${id}: залишковий auto.md — видали (метадані тепер у main.json)`)
     ruleOk = false
   }
 
-  // Канон (scripts.mdc): {rule}.mdc — ОБОВ'ЯЗКОВИЙ у кожному npm/rules/<id>/.
-  if (!existsSync(join(ruleDir, `${id}.mdc`))) {
-    reporter.fail(`rules/${id}: відсутній ${id}.mdc — обов'язковий (scripts.mdc)`)
+  // Канон (scripts.mdc): main.mdc — ОБОВ'ЯЗКОВИЙ у кожному npm/rules/<id>/.
+  if (!existsSync(join(ruleDir, 'main.mdc'))) {
+    reporter.fail(`rules/${id}: відсутній main.mdc — обов'язковий (scripts.mdc)`)
     ruleOk = false
   }
 
   const raw = readRuleMetaRaw(ruleDir)
   if (!raw) {
-    reporter.fail(`rules/${id}: відсутній або невалідний meta.json`)
+    reporter.fail(`rules/${id}: відсутній або невалідний main.json`)
     return
   }
 
@@ -83,7 +83,7 @@ function checkRule(id, ruleDir, reporter) {
   if (!checkLintField(id, ruleDir, raw, reporter)) ruleOk = false
 
   if (ruleOk) {
-    reporter.pass(`rules/${id}: meta.json валідний`)
+    reporter.pass(`rules/${id}: main.json валідний`)
   }
 }
 

package/rules/npm-module/js/skill_meta.mjs

@@ -15,15 +15,15 @@ import { parseSkillAutoSpec, readSkillMetaRaw } from '../../../scripts/lib/skill
 function checkSkillFields(id, raw, reporter) {
   let ok = true
   if (typeof raw.worktree !== 'boolean') {
-    reporter.fail(`skills/${id}: meta.json.worktree має бути boolean`)
+    reporter.fail(`skills/${id}: main.json.worktree має бути boolean`)
     ok = false
   }
   if (raw.auto !== undefined && parseSkillAutoSpec(raw.auto) === null) {
-    reporter.fail(`skills/${id}: meta.json.auto нерозпізнане — очікується "завжди" або непорожній масив правил`)
+    reporter.fail(`skills/${id}: main.json.auto нерозпізнане — очікується "завжди" або непорожній масив правил`)
     ok = false
   }
   if (raw.requireRoot !== undefined && typeof raw.requireRoot !== 'boolean') {
-    reporter.fail(`skills/${id}: meta.json.requireRoot має бути boolean`)
+    reporter.fail(`skills/${id}: main.json.requireRoot має бути boolean`)
     ok = false
   }
   if (raw.worktree === true && raw.requireRoot === false) {
@@ -46,20 +46,20 @@ function checkSkill(id, skillDir, reporter) {
   let skillOk = true
 
   if (existsSync(join(skillDir, 'auto.md'))) {
-    reporter.fail(`skills/${id}: залишковий auto.md — видали (метадані тепер у meta.json)`)
+    reporter.fail(`skills/${id}: залишковий auto.md — видали (метадані тепер у main.json)`)
     skillOk = false
   }
 
   const raw = readSkillMetaRaw(skillDir)
   if (!raw) {
-    reporter.fail(`skills/${id}: відсутній або невалідний meta.json (очікується {"auto"?, "worktree": bool})`)
+    reporter.fail(`skills/${id}: відсутній або невалідний main.json (очікується {"auto"?, "worktree": bool})`)
     return
   }
 
   if (!checkSkillFields(id, raw, reporter)) skillOk = false
 
   if (skillOk) {
-    reporter.pass(`skills/${id}: meta.json валідний`)
+    reporter.pass(`skills/${id}: main.json валідний`)
   }
 }
 

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

@@ -6,11 +6,11 @@ resource: npm/rules/test/js/
 
 # npm/rules/test/js
 
-| Файл                                                        | Тип       |
-| ----------------------------------------------------------- | --------- |
-| [cargo_mutants_config.mjs](cargo_mutants_config.md)         | JS Module |
-| [location.mjs](location.md)                                 | JS Module |
-| [no-process-chdir.mjs](no-process-chdir.md)                 | JS Module |
-| [no-relative-fs-path.mjs](no-relative-fs-path.md)           | JS Module |
-| [stryker_config.mjs](stryker_config.md)                     | JS Module |
+| Файл | Тип |
+|---|---|
+| [cargo_mutants_config.mjs](cargo_mutants_config.md) | JS Module |
+| [location.mjs](location.md) | JS Module |
+| [no-process-chdir.mjs](no-process-chdir.md) | JS Module |
+| [no-relative-fs-path.mjs](no-relative-fs-path.md) | JS Module |
+| [stryker_config.mjs](stryker_config.md) | JS Module |
 | [vitest-config-pool-forks.mjs](vitest-config-pool-forks.md) | JS Module |

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

@@ -3,48 +3,31 @@ type: JS Module
 title: stryker_config.mjs
 resource: npm/rules/test/js/stryker_config.mjs
 docgen:
-  crc: 7ea109c6
-  score: 95
+  crc: be62c446
+  model: omlx/gemma-4-e4b-it-OptiQ-4bit
+  score: 100
 ---
 
-Цей файл виконує перевірку наявності певних файлів та конфігурацій у кореневих пакетах. Код працює з конфігами, визначеними у `mutation.json` та `package.json`, для забезпечення певних станів у системі.
+## Огляд
+
+Модуль перевіряє готовність JavaScript-проєктів до виконання тестів. Він збирає кореневі каталоги проєктів, використовуючи публічну функцію `check` для валідації. Перевірка гарантує наявність необхідних конфігураційних файлів, зокрема `mutation.json` та `package.json`, у кожному знайденому проєкті. Модуль свідомо пропускає каталоги `node_modules`. Він також додає відповідні артефакти тестів до `.gitignore` у коренях проєктів. (test.mdc)
 
 ## Поведінка
 
-1. Перевірити наявність `js` у конфігурації.
-2. Зібрати кореневі пакети.
-3. Перевірити наявність базових конфігурацій.
-4. Перевірити наявність базлайн-файлів.
-5. Для кожного кореневого пакета перевірити наявність `.vue` файлів.
-6. Для кожного кореневого пакета згенерувати ім'я конфігурації.
-7. Для кожного кореневого пакета перевірити наявність необхідних базлайн-файлів.
-8. Для кожного кореневого пакета перевірити наявність `stryker.config.mjs`.
-9. Для кожного кореневого пакета перевірити наявність `vitest.config.mjs` або `vitest.config.js`.
-10. Для кожного кореневого пакета перевірити наявність базових базлайн-файлів.
-11. Для кожного кореневого пакета перевірити наявність `stryker.config.mjs`.
-12. Для кожного кореневого пакета перевірити наявність `vitest.config.mjs` або `vitest.config.js`.
-13. Для кожного кореневого пакета перевірити наявність базових базлайн-файлів.
-14. Для кожного кореневого пакета перевірити наявність `stryker.config.mjs`.
-15. Для кожного кореневого пакета перевірити наявність `vitest.config.mjs` або `vitest.config.js`.
-16. Для кожного кореневого пакета перевірити наявність базових базлайн-файлів.
-17. Для кожного кореневого пакета перевірити наявність `stryker.config.mjs`.
-18. Для кожного кореневого пакета перевірити наявність `vitest.config.mjs` або `vitest.config.js`.
-19. Для кожного кореневого пакета перевірити наявність базових базлайн-файлів.
-20. Для кожного кореневого пакета перевірити наявність `stryker.config.mjs`.
-21. Для кожного кореневого пакета перевірити наявність `vitest.config.mjs` або `vitest.config.js`.
-22. Для кожного кореневого пакета перевірити наявність базових базлайн-файлів.
-23. Для кожного кореневого пакета перевірити наявність `stryker.config.mjs`.
-24. Для кожного кореневого пакета перевірити наявність `vitest.config.mjs` або `vitest.config.js`.
-25. Для кожного кореневого пакета перевірити наявність базових базлайн-файлів.
-26. Для кожного кореневого пакета перевірити наявність `stryker.config.mjs`.
-27. Для кожного кореневого пакета перевірити наявність `vitest.config.mjs` або `vitest.config.js`.
-28. Для кожного кореневого пакета перевірити наявність базових базлайн-файлів.
-29. Для кожного кореневого пакета перевірити наявність `stryker.config.mjs`.
-30. Для кожного кореневого пакета перевірити наявність `vitest.config.mjs` або `vitest.config.js`.
+1. Викликається `check` для ініціалізації процесу перевірки.
+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. Процес завершується з кодом, що вказує на успішне виконання або на виявлені порушення.
 
 ## Гарантії поведінки
 
 - Перехоплює помилки і не пропускає винятків назовні (fail-safe).
-- За невдачі повертає значення помилки (`false`/`null`/`Err`) замість генерування винятку чи паніки.
 - Свідомо пропускає шляхи: `node_modules`.
-- Не звертається до мережі.

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

@@ -3,27 +3,35 @@ type: JS Module
 title: vitest-config-pool-forks.mjs
 resource: npm/rules/test/js/vitest-config-pool-forks.mjs
 docgen:
-  crc: bb04a54b
+  crc: c8640fd7
+  model: omlx/gemma-4-e4b-it-OptiQ-4bit
   score: 100
 ---
 
-Огляд
-Файл виконує перевірку конфігураційного файлу для підтвердження наявності певного параметра. Це робиться для запобігання гонці у process.cwd між паралельними тестовими файлами (test.mdc).
+## Огляд
+
+Визначає шлях до конфігураційного файлу Vitest. Перевіряє, чи встановлено в цьому файлі `pool: 'forks'`. (test.mdc)
+
+Поведінка:
+
+- Якщо конфігураційний файл не знайдено, завершує роботу з кодом, що вказує на помилку. (test.mdc)
+- Якщо конфігураційний файл знайдено, але в ньому відсутній ключ `pool: 'forks'`, завершує роботу з кодом, що вказує на помилку. (test.mdc)
+- Якщо конфігураційний файл знайдено і містить `pool: 'forks'`, завершує роботу з кодом 0. (test.mdc)
 
 ## Поведінка
 
-1. Знайти файл конфігурації з назвою vitest.config.mjs або vitest.config.js у вказаному шляху.
-2. Якщо файл знайдено, прочитати його вміст.
-3. Перевірити вміст файлу на наявність патерну pool: 'forks'.
-4. Якщо патерн знайдено, повідомити про успішне виконання перевірки.
-5. Якщо патерн відсутній, повідомити про невдачу, вказуючи, що конфігурація повинна містити pool: 'forks' для захисту від гонки у process.cwd між паралельними test files (test.mdc).
-6. Якщо файл конфігурації не знайдено, повідомити, що перевірка пропущено.
+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
 
-check — перевіряє, чи налаштування `vitest.config.{mjs,js}` використовує `pool: 'forks'`. (test.mdc)
+check — перевіряє наявність конфігурації `pool: 'forks'` у файлі `vitest.config.{mjs,js}`. (test.mdc)
 
 ## Гарантії поведінки
 
-- Read-only: файл не виконує операцій запису у файлову систему.
-- Не звертається до мережі.
+- Read-only: не виконує операцій запису (ФС/БД).