@nitra/cursor 5.3.3 → 5.4.0

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

@@ -1,152 +1,52 @@
+---
+docgen:
+  source: npm/rules/test/js/stryker_config.mjs
+  crc: 7ea109c6
+  score: 95
+---
+
 # stryker_config.mjs
 
 ## Огляд
 
-Модуль `stryker_config` — це концерн (check) правила `test` (відповідає правилу `test.mdc` із набору `.cursor/rules/`). Його роль — гарантувати, що в усіх JS-roots проєкту присутні canonical baseline-файли конфігурації для mutation testing (Stryker) і unit-test runner-а (Vitest), а також що тестові артефакти не потрапляють у git.
-
-Концерн виконує такі задачі:
-
-- Self-gating: якщо в `.n-cursor.json` правило `js-lint` не включене або явно вимкнене (`disable-rules`), концерн нічого не робить і тихо повертає успіх.
-- Визначення всіх JS-roots проєкту — кожен workspace із `package.json` у monorepo, або сам `cwd` у single-package режимі.
-- Для кожного JS-root перевіряє наявність файлу `stryker.config.mjs`; якщо його немає — копіює canonical baseline з пакета. Для roots із Vue 3 SFC-файлами (`<script setup>`) використовує спеціальний vue-варіант baseline і додатково копіює локальний Stryker-плагін `stryker-vue-macros-ignorer.mjs`.
-- Аналогічно для `vitest.config.js`.
-- Додає в кореневий `.gitignore` патерни `**/reports/stryker/` і `**/coverage/`, щоб тестові артефакти не комітилися.
-
-Файл є idempotent: повторні запуски на тому ж дереві не змінюють вже існуючі конфіги і не дублюють `.gitignore`-патерни.
-
-## Експорти / API
-
-Модуль експортує одну іменовану асинхронну функцію:
-
-- `check(cwd?: string): Promise<number>` — entry-point концерна. Повертає exit code: `0` (успіх або silently skipped), `1` (порушення).
-
-Інші функції модуля (`hasVueFiles`, `ensureBaselineFile`) є внутрішніми і не експортуються.
-
-## Функції
-
-### `hasVueFiles(jsRoot)`
-
-```js
-async function hasVueFiles(jsRoot)
-```
-
-- **Параметри:**
-  - `jsRoot` (`string`) — абсолютний шлях до workspace-каталогу (JS-root).
-- **Повертає:** `Promise<boolean>` — `true`, якщо в межах `<jsRoot>/src/**/*.vue` (виключаючи `node_modules`, `dist`, `reports`) знайдено хоча б один `.vue`-файл; інакше `false`.
-- **Поведінка:** використовує `node:fs/promises#glob` із patterns `VUE_GLOB_PATTERN = 'src/**/*.vue'` і ignore-списком `VUE_GLOB_IGNORE = ['**/node_modules/**', '**/dist/**', '**/reports/**']`. Як тільки знаходить перший збіг — миттєво повертає `true` через `return` у тілі циклу `for await…of`, тому повний обхід директорії не виконується.
-- **Side effects:** немає (read-only filesystem операція).
-
-### `ensureBaselineFile(reporter, cwd, baselinePath, target, label)`
-
-```js
-async function ensureBaselineFile(reporter, cwd, baselinePath, target, label)
-```
-
-- **Параметри:**
-  - `reporter` (`ReturnType<typeof createCheckReporter>`) — check-reporter для логування статусів pass/fail.
-  - `cwd` (`string`) — корінь проєкту, використовується для побудови relative-шляхів у повідомленнях.
-  - `baselinePath` (`string`) — абсолютний шлях до canonical baseline-файла у пакеті.
-  - `target` (`string`) — абсолютний шлях, куди копіювати baseline.
-  - `label` (`string`) — людиночитна мітка для логу (наприклад, `"stryker.config.mjs"` чи `"vitest.config.js"`).
-- **Повертає:** `Promise<void>`.
-- **Поведінка:** якщо `target` вже існує (`existsSync`) — логує `reporter.pass` із позначкою "існує" і виходить. Якщо ні — копіює `baselinePath` у `target` через `copyFile` і логує `reporter.pass` із поміткою "створено з canonical baseline ... (test.mdc)".
-- **Side effects:** запис файлу через `copyFile` (тільки якщо target був відсутній); запис у reporter.
-- **Idempotent:** так — повторний виклик на існуючому target не перезаписує файл.
-
-### `check(cwd = process.cwd())`
-
-```js
-export async function check(cwd = process.cwd())
-```
-
-- **Параметри:**
-  - `cwd` (`string`, опціональний) — корінь проєкту. За замовчуванням `process.cwd()` для CLI-сумісності.
-- **Повертає:** `Promise<number>` — exit code (`0` — OK або silently skipped, `1` — порушення).
-- **Side effects:**
-  - Читає `.n-cursor.json` через `readNCursorConfigLite`.
-  - Викликає `resolveAllJsRoots` для отримання списку JS-roots.
-  - Перевіряє існування canonical baseline-файлів у самому пакеті.
-  - Копіює `stryker.config.mjs` (canonical або vue-варіант), `vitest.config.js`, а для Vue-roots — `stryker-vue-macros-ignorer.mjs` у кожен JS-root, де відповідний файл відсутній.
-  - Додає у кореневий `.gitignore` патерни `**/reports/stryker/` і `**/coverage/`, якщо їх там немає, через `ensureGitignoreEntries` із коментарем-секцією `"Test artifacts: Stryker + coverage (test.mdc)"`.
-  - Накопичує статуси у reporter і повертає його exit code.
-
-## Залежності
-
-Стандартні модулі Node.js:
-
-- `node:fs` — `existsSync` (синхронна перевірка наявності файла).
-- `node:fs/promises` — `copyFile` (копіювання baseline у target), `glob` (пошук `.vue` файлів).
-- `node:path` — `dirname`, `join`, `relative` (побудова абсолютних і relative шляхів).
-- `node:url` — `fileURLToPath` (конвертація `import.meta.url` у POSIX-шлях для `dirname`).
-
-Внутрішні залежності пакета:
-
-- `../../../scripts/lib/check-reporter.mjs` → `createCheckReporter` — фабрика reporter-а з API `pass(msg)`, `fail(msg)`, `getExitCode()`.
-- `../../../scripts/lib/read-n-cursor-config-lite.mjs` → `readNCursorConfigLite` — читання `.n-cursor.json`, повертає об'єкт із полями `rules: string[]`, `disableRules: string[]`.
-- `../../../scripts/utils/ensure-gitignore-entries.mjs` → `ensureGitignoreEntries(cwd, entries, sectionLabel)` — idempotent додавання патернів у кореневий `.gitignore`. Повертає `{ added: string[] }`.
-- `../../../scripts/utils/resolve-js-root.mjs` → `resolveAllJsRoots(cwd)` — повертає масив абсолютних шляхів до всіх JS-roots: усі workspaces із `package.json` у monorepo, або `[cwd]` у single-package.
-
-Зовнішні дані-файли (canonical baseline у пакеті `@nitra/cursor`):
-
-- `data/stryker_config/stryker.config.baseline.mjs` — стандартний baseline Stryker (vitest-runner + perTest, mutate-патерни на Stryker defaults `src/**/*.{js,mjs,ts,jsx,tsx,cjs}`).
-- `data/stryker_config/stryker.config.vue.baseline.mjs` — vue-варіант baseline; реєструє локальний Ignore-плагін `vue-macros`, щоб Stryker не загортав `defineProps`/`defineEmits`/... у coverage-тернарник (інакше `@vue/compiler-sfc` падає при компіляції SFC).
-- `data/stryker_config/stryker-vue-macros-ignorer.mjs` — сам Stryker-плагін, який копіюється поруч із vue-варіантом baseline і реєструється з нього.
-- `data/vitest_config/vitest.config.baseline.js` — мінімальний baseline Vitest для runner-а.
-
-## Константи модуля
-
-- `HERE` — каталог самого `stryker_config.mjs` (`dirname(fileURLToPath(import.meta.url))`).
-- `STRYKER_BASELINE_PATH` — абсолютний шлях до стандартного `stryker.config.baseline.mjs`.
-- `STRYKER_VUE_BASELINE_PATH` — абсолютний шлях до vue-варіанта baseline.
-- `STRYKER_VUE_PLUGIN_PATH` — абсолютний шлях до `stryker-vue-macros-ignorer.mjs` у пакеті.
-- `STRYKER_VUE_PLUGIN_FILENAME = 'stryker-vue-macros-ignorer.mjs'` — ім'я файлу, під яким плагін копіюється у jsRoot.
-- `VITEST_BASELINE_PATH` — абсолютний шлях до canonical `vitest.config.baseline.js`.
-- `TEST_GITIGNORE_ENTRIES = ['**/reports/stryker/', '**/coverage/']` — патерни, які додаються в корений `.gitignore`. Подвійний-зірочка-префікс `**/` забезпечує покриття всіх workspaces у monorepo (єдиний root `.gitignore`).
-- `VUE_GLOB_PATTERN = 'src/**/*.vue'` — scope пошуку `.vue` файлів (відповідає Stryker mutate defaults для `src/`).
-- `VUE_GLOB_IGNORE = ['**/node_modules/**', '**/dist/**', '**/reports/**']` — пропускаються build-артефакти і чужі `node_modules`, щоб не активувати vue-варіант через transitive-deps.
-
-## Потік виконання / Використання
-
-Концерн запускається або через CLI пакета `@nitra/cursor` (як один із checks правила `test`), або імпортно з іншого скрипта.
-
-Алгоритм `check(cwd)` крок за кроком:
-
-1. Створює `reporter` через `createCheckReporter()`.
-2. Читає конфіг `.n-cursor.json` через `readNCursorConfigLite(cwd)`.
-3. **Self-gate:** якщо `js-lint` відсутнє в `config.rules`, або присутнє в `config.disableRules` — повертає `reporter.getExitCode()` без жодних повідомлень (silently skipped). Це навмисна поведінка, щоб не шуміти у проєктах без JS coverage tooling.
-4. Викликає `resolveAllJsRoots(cwd)`. Якщо повернувся порожній масив — це аномалія (`js-lint` enabled, але немає `package.json`); `reporter.fail` із повідомленням `'test: js-lint enabled, але кореневий package.json не знайдено (test.mdc)'` і повернення exit code.
-5. Перевіряє існування всіх чотирьох canonical baseline-файлів у пакеті (`STRYKER_BASELINE_PATH`, `STRYKER_VUE_BASELINE_PATH`, `STRYKER_VUE_PLUGIN_PATH`, `VITEST_BASELINE_PATH`). Якщо будь-якого з них немає — `reporter.fail` із вимогою перевстановити `@nitra/cursor` і early-return.
-6. Для кожного `jsRoot` із `jsRoots`:
-   - Визначає `isVueRoot = await hasVueFiles(jsRoot)`.
-   - Обирає `strykerBaseline = isVueRoot ? STRYKER_VUE_BASELINE_PATH : STRYKER_BASELINE_PATH`.
-   - Через `ensureBaselineFile` копіює `strykerBaseline` у `<jsRoot>/stryker.config.mjs` (якщо відсутній).
-   - Якщо `isVueRoot` — додатково через `ensureBaselineFile` копіює `STRYKER_VUE_PLUGIN_PATH` у `<jsRoot>/stryker-vue-macros-ignorer.mjs`.
-   - Через `ensureBaselineFile` копіює `VITEST_BASELINE_PATH` у `<jsRoot>/vitest.config.js`.
-7. Викликає `ensureGitignoreEntries(cwd, TEST_GITIGNORE_ENTRIES, 'Test artifacts: Stryker + coverage (test.mdc)')` — додає в кореневий `.gitignore` патерни `**/reports/stryker/` і `**/coverage/` (якщо їх там немає). Якщо щось дійсно було додане (`added.length > 0`) — `reporter.pass` із перелічуванням доданих патернів.
-8. Повертає `reporter.getExitCode()` — `0`, якщо жодного `fail` не було, інакше `1`.
-
-### Приклад використання
-
-```js
-import { check } from '@nitra/cursor/rules/test/js/stryker_config.mjs'
-
-const exitCode = await check(process.cwd())
-process.exit(exitCode)
-```
-
-Зазвичай безпосередній виклик не потрібен — концерн запускається диспетчером правила `test` (`test.mdc`) у складі команди `n-cursor fix` / `n-cursor check`.
-
-### Спостережувані ефекти у файловій системі
-
-Після успішного прогону в кожному JS-root з'являються:
-
-- `stryker.config.mjs` (стандартний або vue-варіант, залежно від наявності `.vue` у `src/`).
-- `vitest.config.js`.
-- `stryker-vue-macros-ignorer.mjs` — тільки для Vue-roots.
-
-У кореневому `.gitignore` гарантовано присутні:
-
-- `**/reports/stryker/`
-- `**/coverage/`
-
-Якщо файл уже існував — він не перезаписується, що дозволяє користувачу безпечно кастомізувати baseline під специфіку проєкту.
+Цей файл виконує перевірку наявності певних файлів та конфігурацій у кореневих пакетах. Код працює з конфігами, визначеними у `mutation.json` та `package.json`, для забезпечення певних станів у системі.
+
+## Поведінка
+
+1. Перевірити наявність `js-lint` у конфігурації.
+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`.
+
+## Гарантії поведінки
+
+- Перехоплює помилки і не пропускає винятків назовні (fail-safe).
+- За невдачі повертає значення помилки (`false`/`null`/`Err`) замість генерування винятку чи паніки.
+- Свідомо пропускає шляхи: `node_modules`.
+- Не звертається до мережі.

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

@@ -1,174 +1,31 @@
+---
+docgen:
+  source: npm/rules/test/js/vitest-config-pool-forks.mjs
+  crc: bb04a54b
+  score: 100
+---
+
 # vitest-config-pool-forks.mjs
 
 ## Огляд
 
-Модуль реалізує статичну перевірку конфігураційного файлу `vitest.config.js` у корені репозиторію: цей файл, якщо він присутній, повинен містити налаштування `pool: 'forks'`. Перевірка є частиною групи правил `test` (див. `test.mdc`, секція «Заборона `process.chdir` у тестах») і виконує роль **defense-in-depth** проти race-conditions у `process.cwd()` між паралельними test-файлами.
-
-Контекст і мотивація:
-
-- У `vitest` за замовчуванням використовується `pool: 'threads'`, де всі workers ділять один процес (Node.js worker_threads). Усі такі workers мають **спільний** `process.cwd()`. Якщо хоч один тест (або стороння залежність всередині нього) викликає `process.chdir(...)`, це впливає на всі інші тести, що виконуються паралельно — типовий race-bug.
-- Простої заборони `process.chdir(` у тестах недостатньо: third-party код у залежностях може робити `chdir` всередині vitest worker'а непомітно.
-- `pool: 'forks'` ізолює кожен test-файл у власному child-процесі, тож `process.cwd()` стає локальним для тесту.
-
-Алгоритм перевірки — навмисно простий: substring/regex-пошук у сирому тексті `vitest.config.js`. AST-парсинг свідомо не використовується, бо конфіг може бути в довільному форматі експорту (ESM default, named export, CommonJS, factory-функція тощо), а сам ключ `pool: 'forks'` достатньо унікальний, щоб ідентифікувати його без парсера.
-
-Скіп-семантика: якщо `vitest.config.js` відсутній — це означає, що в репозиторії немає налаштованого vitest, і правило **пропускається** (pass, не fail). Якщо файл є — `pool: 'forks'` обов'язковий.
-
-## Експорти / API
-
-| Експорт | Тип                             | Призначення                                                                              |
-| ------- | ------------------------------- | ---------------------------------------------------------------------------------------- |
-| `check` | `async function` (named export) | Точка входу для виконання перевірки конфігу. Повертає exit-code сумісний з CI-runner'ом. |
-
-Модуль не має default export. Регулярний вираз `POOL_FORKS_RE` оголошений на рівні модуля, але **не** експортується — це внутрішня деталь реалізації.
-
-## Функції
-
-### `check(cwdParam?)`
-
-Асинхронна перевірка наявності `pool: 'forks'` у `vitest.config.js`.
-
-**Сигнатура:**
-
-```js
-export async function check(cwdParam = process.cwd()): Promise<number>
-```
-
-**Параметри:**
-
-| Ім'я       | Тип      | За замовчуванням | Опис                                                                                                                                                    |
-| ---------- | -------- | ---------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| `cwdParam` | `string` | `process.cwd()`  | Абсолютний шлях до кореня репозиторію, в якому шукається `vitest.config.js`. Призначений насамперед для тестів (можна підставити фікстурну директорію). |
-
-**Повертає:** `Promise<number>` — exit-code з `reporter.getExitCode()`:
-
-- `0` — успіх (`pool: 'forks'` знайдено) **або** skip (`vitest.config.js` відсутній);
-- `1` — помилка (файл є, але не містить `pool: 'forks'`).
-
-**Side effects:**
-
-- Створює локальний reporter через `createCheckReporter()`. Reporter виводить повідомлення `pass(...)` / `fail(...)` у консоль (формат залежить від реалізації reporter'а).
-- Синхронно перевіряє існування файлу через `existsSync` (звернення до файлової системи).
-- Якщо файл існує — асинхронно читає його повністю в пам'ять через `readFile(..., 'utf8')`.
-- **Не** модифікує файлову систему та **не** мутує глобальний стан.
-
-**Сценарії виконання:**
-
-1. **`vitest.config.js` не існує** → `pass('vitest.config.js відсутній — pool-перевірку пропущено')` → повертає `0`.
-2. **Файл існує, regex `/pool\s*:\s*['"]forks['"]/u` матчить** → `pass("vitest.config.js містить pool: 'forks' (test.mdc)")` → повертає `0`.
-3. **Файл існує, але regex не матчить** → `fail("vitest.config.js має містити pool: 'forks' — defense-in-depth для race у process.cwd() між паралельними test files (test.mdc)")` → повертає `1`.
-
-**Деталі регексу `POOL_FORKS_RE`:**
-
-```js
-const POOL_FORKS_RE = /pool\s*:\s*['"]forks['"]/u
-```
-
-Регекс:
-
-- `pool` — буквальний ключ;
-- `\s*:\s*` — двокрапка з довільним whitespace навколо;
-- `['"]forks['"]` — значення `forks` у одинарних або подвійних лапках;
-- Прапор `u` — Unicode-мода для коректної семантики escape-послідовностей.
-
-Регекс свідомо **не** перевіряє, що лапки парні (`'forks"` теоретично матчить). На практиці це не проблема, бо у валідному JS такі змішані лапки не зустрінуться (parse-error до того). Whitespace між токенами дозволений, але переноси рядка між `pool` і двокрапкою — лише ті, що покриваються `\s*`.
-
-## Залежності
-
-**Стандартна бібліотека Node.js:**
-
-| Модуль             | Імпортовані символи | Використання                                                    |
-| ------------------ | ------------------- | --------------------------------------------------------------- |
-| `node:fs`          | `existsSync`        | Синхронна перевірка існування `vitest.config.js`.               |
-| `node:fs/promises` | `readFile`          | Асинхронне читання вмісту конфігу у utf-8.                      |
-| `node:path`        | `join`              | Побудова шляху `${cwdParam}/vitest.config.js` крос-платформово. |
-
-**Внутрішні модулі проєкту:**
-
-| Шлях                                      | Імпортовані символи   | Використання                                                                                                                          |
-| ----------------------------------------- | --------------------- | ------------------------------------------------------------------------------------------------------------------------------------- |
-| `../../../scripts/lib/check-reporter.mjs` | `createCheckReporter` | Фабрика репортера з методами `pass(msg)`, `fail(msg)` та `getExitCode()`. Уніфікує вивід для всіх `check-*.mjs` правил у репозиторії. |
-
-**Зовнішніх npm-залежностей не має.**
-
-## Потік виконання / Використання
-
-### Типовий потік виконання `check()`
-
-1. Створюється reporter: `const reporter = createCheckReporter()`.
-2. Деструктуризація методів: `const { pass, fail } = reporter`.
-3. Будується шлях до конфігу: `configPath = join(cwdParam, 'vitest.config.js')`.
-4. Перевіряється існування файлу через `existsSync(configPath)`:
-   - Якщо файла **немає** — викликається `pass(...)` з повідомленням про skip, і функція негайно повертає `reporter.getExitCode()`.
-5. Якщо файл є — він читається повністю: `body = await readFile(configPath, 'utf8')`.
-6. Виконується `POOL_FORKS_RE.test(body)`:
-   - `true` → `pass(...)` з підтвердженням;
-   - `false` → `fail(...)` з поясненням і покликанням на `test.mdc`.
-7. Повертається `reporter.getExitCode()` — `0` або `1` залежно від того, чи був хоч один `fail`.
-
-### Використання як npm/CI-перевірки
-
-Модуль слідує конвенції rule-checker'ів проєкту (правила в `npm/rules/<group>/<lang>/check-*.mjs` або тематичних файлах). Запускається або:
-
-- безпосередньо `node` як CLI-входу (якщо обгорнуто скриптом-раннером);
-- з агрегованого runner'а, який послідовно викликає `check()` для кожного правила і збирає exit-коди.
-
-Приклад прямого виклику з іншого модуля:
-
-```js
-import { check } from './vitest-config-pool-forks.mjs'
-
-const exitCode = await check(process.cwd())
-process.exit(exitCode)
-```
-
-Приклад виклику для нестандартного кореня (наприклад, у тесті):
-
-```js
-import { check } from './vitest-config-pool-forks.mjs'
-
-const exitCode = await check('/tmp/fixture-repo-with-vitest')
-// exitCode === 0 якщо у фікстурі є vitest.config.js з pool: 'forks',
-// 1 якщо файл є без потрібного pool, 0 якщо файла нема взагалі
-```
-
-### Приклад валідного `vitest.config.js`
-
-```js
-import { defineConfig } from 'vitest/config'
-
-export default defineConfig({
-  test: {
-    pool: 'forks'
-    // ... інші опції
-  }
-})
-```
-
-### Приклад невалідного `vitest.config.js`
-
-```js
-import { defineConfig } from 'vitest/config'
+Огляд
+Файл виконує перевірку конфігураційного файлу для підтвердження наявності певного параметра. Це робиться для запобігання гонці у process.cwd між паралельними тестовими файлами (test.mdc).
 
-export default defineConfig({
-  test: {
-    // pool не вказано → effective pool: 'threads' (default vitest) → race на process.cwd()
-  }
-})
-```
+## Поведінка
 
-або
+1. Знайти файл конфігурації з назвою vitest.config.mjs або vitest.config.js у вказаному шляху.
+2. Якщо файл знайдено, прочитати його вміст.
+3. Перевірити вміст файлу на наявність патерну pool: 'forks'.
+4. Якщо патерн знайдено, повідомити про успішне виконання перевірки.
+5. Якщо патерн відсутній, повідомити про невдачу, вказуючи, що конфігурація повинна містити pool: 'forks' для захисту від гонки у process.cwd між паралельними test files (test.mdc).
+6. Якщо файл конфігурації не знайдено, повідомити, що перевірка пропущено.
 
-```js
-export default {
-  test: { pool: 'threads' } // явно threads — те саме, що default
-}
-```
+## Публічний API
 
-Обидва варіанти призведуть до `fail` і exit-code `1`.
+check — перевіряє, чи налаштування `vitest.config.{mjs,js}` використовує `pool: 'forks'`. (test.mdc)
 
-### Межі застосовності
+## Гарантії поведінки
 
-- Перевірка **не** валідовує JS-синтаксис конфігу. Якщо `vitest.config.js` синтаксично битий, але містить рядок `pool: 'forks'` у коментарі чи рядковому літералі, перевірка пройде. Це усвідомлений trade-off на користь простоти — реальні false-positive у проєкті малоймовірні.
-- Перевірка дивиться **тільки** на `vitest.config.js` у корені, переданому через `cwdParam`. Альтернативні імена (`vitest.config.ts`, `vitest.config.mjs`, `vite.config.js` зі вбудованою `test`-секцією) **не** обробляються — це окремі правила, якщо знадобляться.
-- Skip при відсутності файлу — поведінка дизайну: правило не «обов'язково додай vitest», а «якщо ти вже маєш vitest, налаштуй pool правильно».
+- Read-only: файл не виконує операцій запису у файлову систему.
+- Не звертається до мережі.

package/rules/text/docs/fix.md

@@ -1,127 +1,39 @@
 ---
 docgen:
   source: npm/rules/text/fix.mjs
-  crc: 12fc1644
+  crc: 38cf876b
+  score: 100
 ---
 
-# fix.mjs — entry-point правила `text`
+# fix.mjs
 
 ## Огляд
 
-Файл `npm/rules/text/fix.mjs` — це **подвійний entry-point** для правила `text` із пакета `@nitra/cursor`. Він виконує дві ролі одночасно:
+Виконує застосування JS-занепокоєних на наданому контексті прогону, застосовує визначену політику, генерує посилання MDC та повертає результат. У режимі CLI виконується як автономний скрипт, який імітує команду `npx @nitra/cursor fix <id>`, завантажує конфігурацію, перевіряє дозволені записи, генерує зведену інформацію та визначає код виходу процесу.
 
-1. **Library mode** — експортує функцію `run(ctx)`, яку імпортує зовнішня CLI-оркестрація (`npx @nitra/cursor fix text` або агрегований прогон усіх правил) для запуску стандартного fix-pipeline саме цього правила.
-2. **Standalone mode** — якщо модуль виконується безпосередньо (`bun npm/rules/text/fix.mjs`), він самостійно піднімає повний CLI-оркестратор (`runRuleCli`) із завантаженням конфігурації, whitelist-фільтрацією та підсумковим виводом, повертаючи коректний `exit-code` для CI/IDE.
+## Поведінка
 
-Сам файл не містить бізнес-логіки правила: він є **тонким адаптером** над двома утилітами (`runStandardRule` та `runRuleCli`) і покладається на конвенцію `import.meta.dirname` — тобто на те, що сусідні теки `lint/`, `policy/`, `js/` та файл `text.mdc` дають усю фактичну реалізацію (applies → JS-concerns → policy → mdc-refs).
+1. Запуск правила.
+    *   Приймає контекст прогону.
+    *   Виконує застосування JS-занепокоєних.
+    *   Застосовує політику.
+    *   Генерує посилання MDC.
+    *   Повертає результат прогону.
+2. Виконання у режимі CLI.
+    *   Виконується як автономний скрипт.
+    *   Виконує повний еквівалент команди `npx @nitra/cursor fix <id>`.
+    *   Виконує завантаження конфігурації.
+    *   Виконує перевірку дозволених записів.
+    *   Генерує зведену інформацію.
+    *   Визначає код виходу процесу.
 
-Шлях фізично розміщений у директорії конкретного правила `text`, але код **повністю однаковий** для всіх правил репозиторію — `import.meta.dirname` робить його контекстно-залежним без жодних хардкодів `id` правила.
+## Публічний API
 
-## Експорти / API
+run — запускає правило: applies → JS-concerns → policy → mdc-refs (через runStandardRule).
+Library mode — викликається CLI orchestration через `import + run`.
 
-| Експорт | Тип                                             | Призначення                                                                                                                        |
-| ------- | ----------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------- |
-| `run`   | `function (ctx?: RuleContext): Promise<number>` | Іменований експорт для library mode. Викликається зовнішньою оркестрацією, повертає exit-code правила (`0` — OK, `1` — порушення). |
+## Гарантії поведінки
 
-Файл **не має** default-експорту. Усі інші конструкції модуля (`if (isRunAsCli(...))`) виконуються при імпорті як side-effect, але активуються лише коли модуль є entry-point процесу — для звичайного `import` standalone-блок не спрацьовує.
-
-## Функції
-
-### `run(ctx)`
-
-```js
-/**
- *
- */
-export function run(ctx) {
-  return runStandardRule(import.meta.dirname, ctx)
-}
-```
-
-- **Сигнатура**: `function run(ctx?: RuleContext): Promise<number>`
-- **Параметри**:
-  - `ctx` _(необов'язковий)_ — об'єкт контексту прогону типу `RuleContext`, описаний у JSDoc-import у `../../scripts/lib/run-standard-rule.mjs`. Передається оркестратором і зазвичай містить кешовані результати walk'у файлової системи (`walkCache`) та інші спільні для пакетного прогону структури, щоб уникнути повторного сканування репозиторію кожним правилом.
-- **Повертає**: `Promise<number>` — exit-code, який повертає `runStandardRule`. За конвенцією репозиторію:
-  - `0` — порушень не знайдено (правило пройшло);
-  - `1` — знайдено хоча б одне порушення (правило впало).
-- **Side effects**: усі побічні ефекти делеговані в `runStandardRule`. Це включає:
-  - читання файлів проєкту (без модифікацій);
-  - виконання сабмодулів `applies`, `JS-concerns`, `policy`, `mdc-refs` із сусідніх тек;
-  - друк діагностики у stdout/stderr (залежить від реалізації стандартного pipeline та `RuleContext`).
-- **Передача `import.meta.dirname`**: ключова деталь — як перший аргумент передається **директорія цього файлу** (`npm/rules/text/`). Саме за нею `runStandardRule` ідентифікує правило (`id = basename(dirname)`) та знаходить його артефакти (mdc, applies, policy).
-
-### Standalone-блок (top-level, не функція)
-
-```js
-if (isRunAsCli(import.meta.url)) {
-  process.exit(await runRuleCli(import.meta.dirname))
-}
-```
-
-- **Призначення**: дозволяє запускати модуль як автономний скрипт — `bun npm/rules/text/fix.mjs`. У такому режимі він має дати **повний еквівалент** виклику `npx @nitra/cursor fix text`, включно з:
-  - завантаженням конфігурації проєкту;
-  - застосуванням whitelist (відсіюванням файлів, що не підпадають під правило);
-  - друком підсумку (summary) виконання.
-- **Параметри**: немає (CLI-аргументи парсяться всередині `runRuleCli`).
-- **Повертає / завершує**: `process.exit(n)` із `n`, який повернув `runRuleCli`. Це необхідно, щоб CI або IDE-інтеграція могли визначати успіх/невдачу за стандартним exit-code'ом.
-- **Side effects**:
-  - читання конфігурації пакета та проєкту;
-  - читання й аналіз файлів проєкту;
-  - вивід summary у stdout/stderr;
-  - **завершення процесу** через `process.exit` (це окремо помічено `eslint-disable` коментарем `n/no-process-exit, unicorn/no-process-exit`, оскільки правила лінтера за замовчуванням забороняють `process.exit` поза entry-point файлами).
-- **Перевірка `isRunAsCli`**: функція приймає `import.meta.url` і повертає `true` лише якщо саме цей файл — entry-point Node/Bun-процесу. Це класичний ідіоматичний еквівалент `if __name__ == "__main__"` із Python для ESM.
-
-## Залежності
-
-### Внутрішні (relative)
-
-| Імпорт            | Модуль                                    | Що дає                                                                                                                                              |
-| ----------------- | ----------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------- |
-| `isRunAsCli`      | `../../scripts/lib/run-rule-cli.mjs`      | Предикат: чи запущений модуль як CLI entry-point (порівняння `import.meta.url` з `process.argv[1]`).                                                |
-| `runRuleCli`      | `../../scripts/lib/run-rule-cli.mjs`      | Повний CLI-оркестратор одного правила: завантаження конфігурації, whitelist, виклик `run`, друк summary, повернення exit-code.                      |
-| `runStandardRule` | `../../scripts/lib/run-standard-rule.mjs` | Стандартний fix-pipeline правила: послідовно виконує етапи **applies → JS-concerns → policy → mdc-refs**. Знаходить артефакти за `dirname` правила. |
-
-Усі три імпорти — це shared-утиліти рівня `scripts/lib/`, спроєктовані саме для подвійного entry-point'у правил. Жодних зовнішніх npm-залежностей файл не імпортує напряму.
-
-### Неявні (контекст виконання)
-
-- **`import.meta.dirname`** — стандартне поле ESM (Node ≥ 20 / Bun): абсолютний шлях до директорії, що містить модуль. Використовується **двічі** і є ключовим для ідентифікації правила.
-- **`import.meta.url`** — стандартне поле ESM: URL-форма шляху до модуля; передається в `isRunAsCli` для порівняння з `process.argv[1]`.
-- **`process.exit`** — глобальний Node/Bun API; викликається лише у standalone-режимі.
-- **Сусідні теки правила** (`./lint`, `./policy`, `./js`, `./text.mdc`, `./meta.json`) — фактичні артефакти, які `runStandardRule` знаходить через переданий `import.meta.dirname`. Файл `fix.mjs` сам їх не імпортує, але pipeline без них не запрацює.
-
-## Потік виконання / Використання
-
-### Сценарій 1 — Library mode (typical)
-
-1. Зовнішній код (наприклад, агрегатор `npx @nitra/cursor fix`) робить `await import('npm/rules/text/fix.mjs')`.
-2. Перевірка `isRunAsCli(import.meta.url)` повертає `false` (бо entry-point процесу — інший файл), standalone-блок **не виконується**.
-3. Агрегатор викликає експортовану `run(ctx)`, передаючи спільний `ctx` (наприклад, з прогрітим `walkCache`).
-4. `run` делегує виклик у `runStandardRule(import.meta.dirname, ctx)`.
-5. `runStandardRule` ідентифікує правило за `basename(dirname)` = `text`, послідовно виконує етапи pipeline (applies → JS-concerns → policy → mdc-refs), читає сусідні артефакти, повертає exit-code.
-6. Агрегатор отримує `Promise<number>` і інтегрує його в загальний підсумок (наприклад, агрегує максимум по всіх правилах).
-
-### Сценарій 2 — Standalone mode
-
-1. Розробник або CI виконує `bun npm/rules/text/fix.mjs` (або через npm-script).
-2. Імпорти `isRunAsCli`, `runRuleCli`, `runStandardRule` зчитуються.
-3. Експорт `run` стає доступним, але **ніким не використовується** в цьому сценарії.
-4. `isRunAsCli(import.meta.url)` повертає `true`.
-5. Виконується `await runRuleCli(import.meta.dirname)` — повний CLI-цикл: парсинг аргументів, завантаження конфігурації, whitelist, виклик внутрішнього еквівалента `run`, друк summary.
-6. Результат передається в `process.exit(...)` — процес завершується із належним exit-code'ом для CI.
-
-### Чому саме така архітектура
-
-- **Однаковий код для всіх правил** — `fix.mjs` кожного правила в `npm/rules/<id>/` ідентичний; диференціація — виключно через директорію (`import.meta.dirname`) та артефакти в ній. Це усуває дублювання логіки entry-point'у та робить додавання нового правила механічним (скопіювати теку, поправити mdc/policy).
-- **Подвійна роль (library + standalone)** — дозволяє з одного файлу і дебажити правило локально (швидкий feedback `bun rules/text/fix.mjs`), і інтегрувати його у пакетний прогон агрегатора без зміни вихідного коду.
-- **`process.exit` лише в standalone-гілці** — у library-режимі повернення exit-code'у через `Promise<number>` дає агрегатору можливість зібрати всі результати й завершитися одним викликом, не давши окремому правилу обірвати процес передчасно.
-
-### Rebuild Test (інваріанти, які має зберегти будь-яка перебудова файлу)
-
-- Файл **має експортувати** функцію `run(ctx)`, що повертає `Promise<number>`.
-- `run` **має** передавати `import.meta.dirname` як перший аргумент у `runStandardRule` (без хардкоду шляху або `id`).
-- `run` **не повинна** викликати `process.exit` — лише повертати exit-code.
-- Standalone-гілка **має** бути захищена `isRunAsCli(import.meta.url)`, щоб не спрацьовувати при `import` із зовнішнього коду.
-- Standalone-гілка **має** використовувати `runRuleCli` (а не `runStandardRule` напряму), бо саме `runRuleCli` додає config-loading, whitelist та summary.
-- Standalone-гілка **має** завершуватися `process.exit(await runRuleCli(import.meta.dirname))` із поверненням коректного exit-code'у — інакше CI не зможе зловити порушення.
-- Файл **не повинен** містити власної логіки правила: вся специфіка `text` живе в сусідніх теках (`lint/`, `policy/`, `js/`) та `text.mdc`.
+- Read-only: файл не виконує операцій запису у файлову систему.
+- Кешує результати в межах одного прогону.
+- Не звертається до мережі.