@nitra/cursor 5.3.4 → 5.4.0

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

@@ -1,228 +1,31 @@
-# tooling.mjs — перевірка інструментарію Tauri
-
-## Огляд
-
-Модуль `npm/rules/tauri/js/tooling.mjs` реалізує JS-orchestrator для правила `tauri.mdc`. Його єдина мета — перевірити, чи правильно налаштовано VSCode-конфіг `.vscode/extensions.json` у проєктах, де є Tauri.
-
-Особливості:
-
-- **Cross-file gating**. Перевірка вмикається лише за наявності маркера Tauri у проєкті. Якщо проєкт не використовує Tauri — модуль одразу повертає успіх і нічого не валідує.
-- **Маркер Tauri** шукається в усіх workspace-пакетах монорепо (включно з кореневим) через `getMonorepoPackageRootDirs()` за п'ятьма ознаками: наявність каталогу `src-tauri/`, файлів `src-tauri/Cargo.toml`, `src-tauri/tauri.conf.json`, `tauri.conf.json` (legacy flat-layout) або префікса `@tauri-apps/` у `dependencies`/`devDependencies` файла `package.json`.
-- **Plan B архітектура**. Це conditional-правило: Rego-полісі лежить глобально без `target.json` поруч і **не** є auto-discoverable через `n-cursor fix`. Тому JS-orchestrator робить FS-існування файла самостійно, а content-валідацію делегує в Rego через `runConftestBatch` (namespace `tauri.vscode_extensions`).
-- **Звітування** іде через `createCheckReporter` — стандартний reporter з `pass`/`fail` повідомленнями та `getExitCode()` (0 — OK, 1 — є порушення).
-
-## Експорти / API
-
-| Символ  | Тип                     | Опис                                                                                                                                                       |
-| ------- | ----------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| `check` | `() => Promise<number>` | **Єдиний публічний експорт.** Запускає перевірку правил `tauri.mdc` і повертає exit-код процесу: `0` — все добре або Tauri-маркера немає, `1` — порушення. |
-
-Внутрішні (не експортовані) функції модуля:
-
-- `packageHasTauriDep(pkg)` — детектор `@tauri-apps/*` залежностей у `package.json`.
-- `workspaceHasTauriMarker(cwd, ws)` — перевірка одного workspace-пакета на ознаки Tauri.
-- `projectHasTauriMarker()` — обхід усіх workspaces для агрегованого результату.
-
-## Функції
-
-### `packageHasTauriDep(pkg)`
-
-**Сигнатура.**
-
-```js
-function packageHasTauriDep(pkg: Record<string, unknown> | null | undefined): boolean
-```
-
-**Параметри.**
-
-- `pkg` — розпарсений вміст `package.json`. Допускає `null`, `undefined` або не-об'єктне значення — у цих випадках повертається `false`.
-
-**Повертає.**
-
-- `boolean` — `true`, якщо серед ключів `pkg.dependencies` або `pkg.devDependencies` знайдено хоча б один ключ із префіксом `@tauri-apps/`. Інакше — `false`.
-
-**Логіка.**
-
-1. Якщо `pkg` falsy або не object — `false`.
-2. Перебирає два поля: `'dependencies'` і `'devDependencies'`.
-3. Для кожного, якщо поле є object — ітерує `Object.keys()` і перевіряє `name.startsWith('@tauri-apps/')`.
-4. Перший збіг → негайне `true` (early return).
-
-**Side effects.** Немає — чиста функція. Працює лише з вхідним об'єктом.
-
----
-
-### `workspaceHasTauriMarker(cwd, ws)`
-
-**Сигнатура.**
-
-```js
-async function workspaceHasTauriMarker(cwd: string, ws: string): Promise<boolean>
-```
-
-**Параметри.**
-
-- `cwd` — абсолютний шлях до кореня репо (зазвичай `process.cwd()`).
-- `ws` — відносний шлях workspace-пакета від кореня. Спеціальне значення `'.'` означає сам корінь (тоді `base = cwd`); для решти — `base = join(cwd, ws)`.
-
-**Повертає.**
-
-- `Promise<boolean>` — `true`, якщо в зазначеному workspace знайдено будь-який з маркерів Tauri:
-  1. Існує каталог `<base>/src-tauri/` (`existsSync` + `statSync(...).isDirectory()`).
-  2. Існує файл `<base>/src-tauri/Cargo.toml`.
-  3. Існує файл `<base>/src-tauri/tauri.conf.json`.
-  4. Існує файл `<base>/tauri.conf.json` (legacy flat-layout).
-  5. `<base>/package.json` існує, парситься як JSON і `packageHasTauriDep(pkg)` повертає `true`.
-
-Якщо `package.json` не існує — повертає `false` (умова `if (!existsSync(pkgPath)) return false`).
-
-**Side effects.**
-
-- Синхронні FS-виклики `existsSync`, `statSync` для каталогів і файлів.
-- Асинхронне читання файла `readFile(pkgPath, 'utf8')`.
-- `JSON.parse` — кидає виключення на некоректному JSON у `package.json` (без явного `try/catch` всередині). Викидається вгору як rejected promise.
-
 ---
-
-### `projectHasTauriMarker()`
-
-**Сигнатура.**
-
-```js
-async function projectHasTauriMarker(): Promise<boolean>
-```
-
-**Параметри.** Немає.
-
-**Повертає.**
-
-- `Promise<boolean>` — `true`, якщо хоча б один workspace (включаючи корінь) має маркер Tauri.
-
-**Логіка.**
-
-1. Бере `cwd = process.cwd()`.
-2. Викликає `getMonorepoPackageRootDirs(cwd)` — отримує масив workspace-шляхів (корінь `'.'` + всі workspaces з `package.json#workspaces`).
-3. Послідовно (через `for...of`) перевіряє кожен workspace через `workspaceHasTauriMarker`. На першому `true` — короткозамикає й повертає `true`.
-4. Якщо жоден workspace не має маркера — повертає `false`.
-
-**Side effects.** Опосередковано — через FS-виклики у `workspaceHasTauriMarker` та `getMonorepoPackageRootDirs`.
-
+docgen:
+  source: npm/rules/tauri/js/tooling.mjs
+  crc: 8f7bbb45
+  score: 90
 ---
 
-### `check()` — публічний експорт
-
-**Сигнатура.**
-
-```js
-export async function check(): Promise<number>
-```
-
-**Параметри.** Немає.
-
-**Повертає.**
-
-- `Promise<number>` — exit-код перевірки, отриманий через `reporter.getExitCode()`:
-  - `0` — успіх (немає маркера Tauri, або всі канонічні конфіги відповідають правилам).
-  - `1` — є помилки (наприклад, `.vscode/extensions.json` не існує або не пройшов Rego-валідацію).
+# tooling.mjs
 
-**Логіка покроково.**
-
-1. Створює reporter: `const reporter = createCheckReporter()` і виймає шорткати `{ pass, fail }`.
-2. Викликає `projectHasTauriMarker()`. Якщо маркера немає:
-   - Записує `pass('Немає маркера Tauri (src-tauri/, tauri.conf.json, @tauri-apps/*) — tauri-tooling не вимагається')`.
-   - Повертає `reporter.getExitCode()` — зазвичай `0` (бо тільки `pass`).
-3. Якщо маркер є — записує `pass('Знайдено маркер Tauri — перевіряємо канонічні конфіги tauri.mdc')` і починає валідацію `.vscode/extensions.json`.
-4. Перевіряє існування файла `.vscode/extensions.json` (відносний шлях від CWD):
-   - Якщо файла немає — `fail(...)` з повідомленням, що треба створити з `recommendations "tauri-apps.tauri-vscode"`, і повертає `reporter.getExitCode()` (тут уже буде `1`).
-5. Якщо файл існує — викликає `runConftestBatch({ policyDirRel: 'tauri/vscode_extensions', namespace: 'tauri.vscode_extensions', files: ['.vscode/extensions.json'] })`. Отримує масив `violations`.
-6. Залежно від результату:
-   - `violations.length === 0` → `pass(`${extPath} відповідає tauri.vscode_extensions (rego)`)`.
-   - Інакше — для кожного `v` із `violations` викликає `fail(v.message)`.
-7. Повертає `reporter.getExitCode()` — `0` або `1` залежно від накопичених `fail`-викликів.
-
-**Side effects.**
-
-- Читає `process.cwd()` (через залежні функції).
-- FS-доступ: `existsSync`, `statSync`, `readFile` (через детектори маркера) і `existsSync` для `.vscode/extensions.json`.
-- Запускає зовнішній двійковий процес `conftest` (опосередковано через `runConftestBatch`).
-- Накопичує повідомлення в reporter (stdout / накопичувач залежить від реалізації `createCheckReporter`).
-
-## Залежності
-
-Імпорти модуля:
-
-- **Стандартна бібліотека Node.js:**
-  - `existsSync`, `statSync` із `node:fs` — синхронні FS-перевірки існування файлів/каталогів і типу запису.
-  - `readFile` із `node:fs/promises` — асинхронне читання `package.json`.
-  - `join` із `node:path` — побудова шляхів.
-- **Локальні утиліти (з `../../../scripts/lib/`):**
-  - `createCheckReporter` із `check-reporter.mjs` — фабрика звітувача з `pass`/`fail`/`getExitCode`.
-  - `runConftestBatch` із `run-conftest-batch.mjs` — синхронний (за використанням у коді) виклик `conftest` для batch-валідації набору файлів проти Rego-полісі.
-  - `getMonorepoPackageRootDirs` із `workspaces.mjs` — асинхронне отримання шляхів усіх workspace-пакетів монорепо (включаючи корінь `'.'`).
-
-Зовнішні runtime-передумови:
-
-- Виконуваний `conftest` має бути доступний у `PATH` (інакше `runConftestBatch` зафейлиться).
-- Rego-полісі для namespace `tauri.vscode_extensions` має бути зареєстрований у глобальній теці полісі (без `target.json` поруч — це conditional-правило).
-
-## Потік виконання / Використання
-
-**Типове призначення.** Модуль викликається CLI-агрегатором правил (наприклад, `n-cursor` чи аналогом) у режимі перевірки. Він — один із багатьох `check()`-модулів, кожен з яких відповідає одному `.mdc`-правилу. `tooling.mjs` відповідає за частину `tauri.mdc`, що стосується VSCode tooling.
-
-**Приклад прямого виклику:**
-
-```js
-import { check } from './npm/rules/tauri/js/tooling.mjs'
-
-const code = await check()
-process.exit(code)
-```
-
-**Послідовність виконання `check()`:**
-
-1. **Ініціалізація reporter** → готовий до накопичення `pass`/`fail`.
-2. **Gating (cross-file)** → `projectHasTauriMarker()`:
-   - `getMonorepoPackageRootDirs(cwd)` повертає шляхи всіх workspaces.
-   - Для кожного workspace перевіряємо 5 ознак (каталог `src-tauri/`, `Cargo.toml`, `tauri.conf.json` у двох локаціях, `@tauri-apps/*` у `package.json`).
-   - Перший знайдений маркер → переходимо до валідації; інакше — `pass` + exit `0`.
-3. **FS-існування** `.vscode/extensions.json` — якщо немає, `fail` з підказкою про канонічний контент і exit `1`.
-4. **Делегування в Rego** через `runConftestBatch`:
-   - `policyDirRel: 'tauri/vscode_extensions'` — відносний шлях до полісі.
-   - `namespace: 'tauri.vscode_extensions'` — Rego-namespace для оцінки.
-   - `files: ['.vscode/extensions.json']` — вхідні файли для batch-валідації.
-5. **Звіт** — `pass` за нуль порушень, `fail(v.message)` для кожного `violation`.
-6. **Повернення exit-коду** через `reporter.getExitCode()`.
+## Огляд
 
-**Поведінка при помилках.**
+Огляд
+Файл виконує перевірку наявності залежностей Tauri у `package.json`, одиничного workspace-пакета Tauri, маркера Tauri та конфігурації `extensions.json`. Перевірка проводиться відповідно до правил, визначених у `tauri.mdc`.
 
-- Якщо `package.json` у якомусь workspace містить невалідний JSON — `JSON.parse` кине виключення; `projectHasTauriMarker` (і відповідно `check`) поверне rejected promise. Обробку покладено на викликальника.
-- Якщо `conftest` не встановлено — помилку викине `runConftestBatch` (поведінка залежить від його реалізації).
+## Поведінка
 
-**Інтеграційні зв'язки.**
+1. Перевіряє наявність залежностей Tauri у `package.json`
+2. Перевіряє наявність одиничного workspace-пакета Tauri
+3. Перевіряє наявність маркера Tauri у проєкті
+4. Перевіряє наявність файлу `.vscode/extensions.json`
+5. Перевіряє відповідність `extensions.json` правилам `tauri.mdc`
 
-- Правило в `.mdc`-форматі (зміст для людини) — `npm/rules/tauri/tauri.mdc` (або аналог; шукати в репо).
-- Rego-полісі — десь у глобальній теці полісі під `tauri/vscode_extensions/` (адресовано через `policyDirRel`).
-- Це conditional-правило: воно **не** реєструється автоматично в `n-cursor fix` як target-discoverable; орchestrator `tooling.mjs` сам гейтить виконання й сам викликає `conftest`.
+## Публічний API
 
-## Rebuild Test
+check — Перевіряє відповідність проєкту правилам tauri.mdc.
 
-Опис достатній, щоб відтворити модуль з нуля:
+## Гарантії поведінки
 
-1. Створити файл `tooling.mjs` з JSDoc-преамбулою, що описує мету та cross-file gating (5 ознак Tauri-маркера).
-2. Імпортувати:
-   - `existsSync`, `statSync` із `node:fs`;
-   - `readFile` із `node:fs/promises`;
-   - `join` із `node:path`;
-   - `createCheckReporter` з `../../../scripts/lib/check-reporter.mjs`;
-   - `runConftestBatch` з `../../../scripts/lib/run-conftest-batch.mjs`;
-   - `getMonorepoPackageRootDirs` з `../../../scripts/lib/workspaces.mjs`.
-3. Реалізувати `packageHasTauriDep(pkg)` — defensive guard + цикл по `['dependencies', 'devDependencies']` + перевірка `name.startsWith('@tauri-apps/')`.
-4. Реалізувати `workspaceHasTauriMarker(cwd, ws)` — `base = ws === '.' ? cwd : join(cwd, ws)`, послідовні `existsSync`/`statSync` для каталогу `src-tauri/`, файлів `src-tauri/Cargo.toml`, `src-tauri/tauri.conf.json`, `tauri.conf.json`; fallback на `readFile(<base>/package.json)` + `JSON.parse` + `packageHasTauriDep`.
-5. Реалізувати `projectHasTauriMarker()` — `process.cwd()`, `await getMonorepoPackageRootDirs(cwd)`, `for...of` з раннім `return true`.
-6. Експортувати `async function check()`:
-   - Створити reporter, дістати `pass`/`fail`.
-   - Перевірити маркер; якщо немає — `pass(...)` + `return reporter.getExitCode()`.
-   - Якщо є — `pass(...)`, потім гейт `.vscode/extensions.json`: відсутній → `fail(...)` + return.
-   - Викликати `runConftestBatch({ policyDirRel: 'tauri/vscode_extensions', namespace: 'tauri.vscode_extensions', files: [extPath] })`.
-   - На порожньому масиві порушень — `pass(...)`; інакше — цикл `fail(v.message)`.
-   - Повернути `reporter.getExitCode()`.
+- Read-only: файл не виконує операцій запису у файлову систему.
+- За невдачі повертає значення помилки (`false`/`null`/`Err`) замість генерування винятку чи паніки.
+- Не звертається до мережі.

package/rules/test/docs/fix.md

@@ -1,141 +1,33 @@
 ---
 docgen:
   source: npm/rules/test/fix.mjs
-  crc: 12fc1644
+  crc: 38cf876b
+  score: 80
 ---
 
-# fix.mjs — правило `test`
+# fix.mjs
 
 ## Огляд
 
-Файл `npm/rules/test/fix.mjs` — це точка входу правила з ідентифікатором `test` у системі правил `@nitra/cursor`. Файл одночасно виконує дві ролі:
+Файл ініціює виконання визначеного правила. Він передає контекст прогону і викликає `runStandardRule` для отримання результату.
 
-1. **Library mode** — експортує функцію `run(ctx)`, яку викликає CLI-оркестратор `@nitra/cursor` коли пакет використовується як бібліотека (наприклад, через `npx @nitra/cursor fix test` або через композицію з іншими правилами).
-2. **Standalone mode** — якщо файл запущено напряму (`bun npm/rules/test/fix.mjs`), він самостійно виконує повний еквівалент CLI-команди `npx @nitra/cursor fix test`: підвантажує конфіг, застосовує whitelist, друкує підсумок і повертає коректний exit-code для CI/IDE.
+## Поведінка
 
-Обидва режими делегують усю важку роботу спільному оркестратору `runStandardRule`, який реалізує стандартизований пайплайн правила: **applies → JS-concerns → policy → mdc-refs**. Тобто конкретно цей файл не містить власної бізнес-логіки правила — він є лише декларативним «шаблонним» entry-point, який «прив'язує» директорію правила (`import.meta.dirname`) до стандартного процесу виконання.
+1. Запуск правила.
+    *   Передача контексту прогону.
+    *   Виклик `runStandardRule` з використанням шляху до модуля.
+    *   Повернення результату.
+2. Запуск у режимі CLI.
+    *   Виклик `runRuleCli` з використанням шляху до модуля.
+    *   Встановлення коду виходу процесу на результат.
 
-Такий патерн (тонкий `fix.mjs` + важка логіка в `scripts/lib/`) — конвенція проєкту: кожне правило має ідентичний скелет, а конкретна перевірка зберігається в `check-{id}.mjs` / `mdc-refs.json` / supporting файлах у тій же директорії.
+## Публічний API
 
-## Експорти / API
+run — запускає правило: applies → JS-concerns → policy → mdc-refs (через runStandardRule).
+Library mode — викликається CLI orchestration через `import + run`.
 
-| Експорт | Тип                                      | Опис                                                                                          |
-| ------- | ---------------------------------------- | --------------------------------------------------------------------------------------------- |
-| `run`   | `(ctx?: RuleContext) => Promise<number>` | Library-функція запуску правила. Повертає exit-code: `0` — порушень немає, `1` — є порушення. |
+## Гарантії поведінки
 
-Файл **не має default-експорту**. Іменований експорт `run` — це публічний контракт, який CLI-оркестратор `@nitra/cursor` очікує знайти у кожному `fix.mjs`.
-
-### Тип `RuleContext`
-
-Декларується у `../../scripts/lib/run-standard-rule.mjs` і реекспортується через JSDoc. Найважливіше поле:
-
-- `walkCache` — спільний кеш обходу файлової системи, який орекстратор передає між правилами в одному прогоні, щоб не сканувати дерево повторно.
-
-Контекст є **необов'язковим**: при standalone-запуску `runRuleCli` сам створює свіжий контекст; при library-запуску ctx підставляє зовнішній orchestrator.
-
-## Функції
-
-### `run(ctx)`
-
-```js
-/**
- *
- */
-export function run(ctx) {
-  return runStandardRule(import.meta.dirname, ctx)
-}
-```
-
-- **Сигнатура:** `run(ctx?: RuleContext): Promise<number>`
-- **Параметри:**
-  - `ctx` _(опціональний)_ — `RuleContext`, контекст прогону. Може містити `walkCache` та інші поля, які стандартний пайплайн використовує для оптимізацій і передачі стану між правилами в межах однієї CLI-сесії.
-- **Повертає:** `Promise<number>` — exit-code:
-  - `0` — правило відпрацювало без порушень;
-  - `1` — виявлено порушення (хоча б на одному з кроків applies/JS-concerns/policy/mdc-refs).
-- **Side effects:** усі побічні ефекти делеговані `runStandardRule`. Зокрема: читання файлової системи (через walker), друк звіту в stdout/stderr, можливі правки файлів (якщо правило підтримує auto-fix), оновлення `walkCache`.
-- **Ідентифікація правила:** правило ідентифікується **директорією** через `import.meta.dirname` — тобто абсолютним шляхом до теки `npm/rules/test/`. Зміна шляху чи переіменування директорії змінить ідентичність правила.
-
-### Top-level standalone-блок
-
-```js
-if (isRunAsCli(import.meta.url)) {
-  process.exit(await runRuleCli(import.meta.dirname))
-}
-```
-
-- **Тип:** не функція, а top-level `if`-блок із top-level `await`.
-- **Умова входу:** `isRunAsCli(import.meta.url)` — повертає `true`, лише якщо цей модуль запущено як головний скрипт (а не імпортовано як залежність). Реалізація утиліти живе в `../../scripts/lib/run-rule-cli.mjs`.
-- **Дія:** викликає `runRuleCli(import.meta.dirname)` — повний CLI-флоу одного правила (config-loading, whitelist, summary), очікує його `Promise<number>` і передає результат у `process.exit(...)`.
-- **Side effects:** **завершує процес** через `process.exit(...)`. Тому інклюди коментарі-disable для ESLint-правил `n/no-process-exit` та `unicorn/no-process-exit` — це свідомий виняток для standalone entry-point.
-- **Чому `await` дозволено на top-level:** файл є ESM-модулем (`.mjs`), а ESM підтримує top-level `await` нативно.
-
-## Залежності
-
-### Внутрішні модулі (relative imports)
-
-| Шлях                                      | Імпортовані сутності       | Призначення                                                                                                                             |
-| ----------------------------------------- | -------------------------- | --------------------------------------------------------------------------------------------------------------------------------------- |
-| `../../scripts/lib/run-rule-cli.mjs`      | `isRunAsCli`, `runRuleCli` | Standalone CLI-обгортка: детект `import.meta.url === entry` і запуск повного CLI-флоу з config/whitelist/summary.                       |
-| `../../scripts/lib/run-standard-rule.mjs` | `runStandardRule`          | Стандартний пайплайн правила: послідовно прогоняє кроки `applies` → `JS-concerns` → `policy` → `mdc-refs`. Експортує тип `RuleContext`. |
-
-Шляхи `../../scripts/lib/...` ведуть із `npm/rules/test/` у `npm/scripts/lib/` — тобто до **спільної інфраструктури правил** усередині пакета `@nitra/cursor`.
-
-### Зовнішні залежності
-
-Прямих імпортів зовнішніх npm-пакетів немає. Усі зовнішні залежності (наприклад, file-walker, glob-matcher, ESLint-utils) інкапсульовані всередині `runStandardRule` / `runRuleCli`.
-
-### Платформенні API
-
-- `import.meta.dirname` — Node.js/Bun-фіча ESM, що повертає абсолютний шлях до теки поточного модуля. Доступна в Node.js ≥ 20.11 та сучасних версіях Bun.
-- `import.meta.url` — стандартний ESM-атрибут, URL поточного модуля (використовується для CLI-детекту).
-- `process.exit(code)` — глобальний Node.js/Bun API.
-- Top-level `await` — стандарт ESM (ES2022).
-
-## Потік виконання / Використання
-
-### Сценарій 1: Library mode (виклик з оркестратора)
-
-1. Зовнішній CLI (`npx @nitra/cursor fix` або композитний прогон) визначає список активних правил.
-2. Для правила `test` він `import`-ить `npm/rules/test/fix.mjs`.
-3. Top-level `if (isRunAsCli(...))` повертає `false` (бо модуль імпортовано, а не запущено напряму) — standalone-гілка пропускається, процес не завершується.
-4. Оркестратор викликає `run(ctx)` із підготовленим контекстом (`walkCache` тощо).
-5. `run` делегує виклик `runStandardRule(import.meta.dirname, ctx)`.
-6. `runStandardRule` послідовно виконує кроки пайплайна правила, читаючи допоміжні файли з директорії правила.
-7. Результат (`Promise<number>`) повертається в оркестратор, який агрегує exit-коди усіх правил.
-
-### Сценарій 2: Standalone mode (пряме виконання)
-
-Команда: `bun npm/rules/test/fix.mjs` (або `node npm/rules/test/fix.mjs` за умови підтримки `import.meta.dirname`).
-
-1. Bun/Node запускає модуль як головний.
-2. Виконується top-level код: `isRunAsCli(import.meta.url)` → `true`.
-3. Викликається `runRuleCli(import.meta.dirname)`:
-   - підвантажується конфіг проєкту,
-   - застосовується whitelist (якщо є),
-   - запускається пайплайн правила (фактично — той самий `runStandardRule` під капотом, але обгорнутий у CLI-логіку: парсинг прапорців, друк summary, обробка помилок),
-   - повертається `Promise<number>` із exit-code.
-4. `await` чекає завершення Promise.
-5. `process.exit(code)` завершує процес із отриманим кодом — це робить файл придатним для CI/pre-commit/IDE-інтеграцій, які покладаються саме на exit-code.
-
-### Сценарій 3: Через `npx @nitra/cursor fix test`
-
-Це **гібридний** сценарій:
-
-1. CLI пакета `@nitra/cursor` запускається користувачем.
-2. Він знаходить директорію правила за id (`test`) і динамічно імпортує `fix.mjs`.
-3. CLI викликає експортовану функцію `run(ctx)` — тобто це Library mode (Сценарій 1), просто ініційований CLI-командою верхнього рівня. Standalone-гілка в самому `fix.mjs` при цьому **не активується**.
-
-### Інваріанти та контракти
-
-- `run` **мусить** повертати `Promise<number>` із значенням `0` або `1` — інакше CLI-оркестратор може некоректно агрегувати результати.
-- Файл **не повинен** містити власної логіки правила: усе делегується `runStandardRule`. Конкретна перевірка живе у супутніх файлах директорії (`check-test.mjs`, `mdc-refs.json`, тощо — згідно конвенції проєкту).
-- Top-level `await` дозволено лише в standalone-блоці й лише тому, що модуль ESM (`.mjs`).
-- `process.exit` викликається **лише** в standalone-режимі — у library-режимі (Сценарій 1) виклик `process.exit` був би порушенням (тому існує `isRunAsCli`-guard і ESLint-disable коментар із обґрунтуванням).
-
-### Розширення та модифікація
-
-Файл є **темплейтним** і свідомо мінімальним. Щоб змінити поведінку правила `test`, **не редагуйте `fix.mjs`** — замість цього:
-
-- логіку перевірок змінюйте у `check-*.mjs` тієї ж директорії;
-- посилання на правила Cursor оновлюйте в `mdc-refs.json`;
-- спільні зміни пайплайна вносьте в `npm/scripts/lib/run-standard-rule.mjs` (тоді вони застосуються до **всіх** правил одночасно).
+- Read-only: файл не виконує операцій запису у файлову систему.
+- Кешує результати в межах одного прогону.
+- Не звертається до мережі.

package/rules/test/js/data/stryker_config/docs/stryker.config.baseline.md

@@ -1,140 +1,28 @@
 ---
 docgen:
   source: npm/rules/test/js/data/stryker_config/stryker.config.baseline.mjs
-  crc: 6271a5ad
+  crc: 2c7c9c37
+  score: 90
 ---
 
 # stryker.config.baseline.mjs
 
 ## Огляд
 
-Файл `stryker.config.baseline.mjs` — це еталонна (baseline) конфігурація для інструмента mutation testing **Stryker Mutator** (`@stryker-mutator/core`). Він являє собою тестову/довідкову фікстуру, розміщену в директорії з даними для перевірочного правила (`npm/rules/test/js/data/stryker_config/`), і слугує канонічним зразком того, як має виглядати «правильна» Stryker-конфігурація у проєкті.
+Файл ініціює процес тестування. Він визначає конфігурацію, область покриття, директорію для тимчасових файлів та формує ім'я файлу для JSON-звіту. Він керує збереженням результатів між запусками.
 
-Файл написаний у форматі ES Module (`.mjs`) і експортує єдиний дефолтний об'єкт із набором опцій, що повністю задають поведінку Stryker-у:
+## Поведінка
 
-- запуск через **Vitest** test-runner (замість commandRunner);
-- `perTest` coverage analysis для максимального прискорення;
-- ввімкнений **incremental** режим зі збереженням стану між запусками;
-- два репортери (`json` для машинного парсингу та `clear-text` для людиночитного виводу в консоль);
-- усі артефакти (тимчасові файли, JSON-репорт, incremental-state) розміщуються під теками `reports/stryker/...`.
+1. Запуск тестування.
+2. Вибір конфігурації для тестового раннера.
+3. Визначення області покриття тестування.
+4. Визначення директорії для тимчасових файлів.
+5. Вибір методів звітування.
+6. Формування імені файлу для JSON-звіту.
+7. Увімкнення можливості збереження результатів між запусками.
+8. Визначення файлу для збереження результатів між запусками.
 
-Об'єкт типізовано через JSDoc-анотацію `@type {import('@stryker-mutator/core').PartialStrykerOptions}`, що дає TypeScript-сумісну валідацію в IDE без переходу на `.ts`.
+## Гарантії поведінки
 
-## Експорти / API
-
-Файл має один експорт — **default export**.
-
-| Експорт   | Тип                                                 | Опис                         |
-| --------- | --------------------------------------------------- | ---------------------------- |
-| `default` | `PartialStrykerOptions` (з `@stryker-mutator/core`) | Об'єкт конфігурації Stryker. |
-
-### Структура експортованого об'єкта
-
-| Ключ               | Тип        | Значення                                        | Призначення                                                                                                                |
-| ------------------ | ---------- | ----------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------- |
-| `testRunner`       | `string`   | `'vitest'`                                      | Test-runner-плагін, через який Stryker виконує тести проти мутантів.                                                       |
-| `vitest`           | `object`   | `{ configFile: 'vitest.config.js' }`            | Налаштування Vitest-runner-а. Поле `configFile` вказує шлях до конфігурації Vitest, яку Stryker реюзає.                    |
-| `coverageAnalysis` | `string`   | `'perTest'`                                     | Режим аналізу покриття. `perTest` — Stryker для кожного мутанта запускає лише ті тести, що покривають мутовану лінію коду. |
-| `tempDirName`      | `string`   | `'reports/stryker/.tmp'`                        | Тимчасова директорія для проміжних файлів Stryker під час прогону.                                                         |
-| `reporters`        | `string[]` | `['json', 'clear-text']`                        | Список увімкнених репортерів. `json` пише машинно-читний звіт, `clear-text` виводить у термінал.                           |
-| `jsonReporter`     | `object`   | `{ fileName: 'reports/stryker/mutation.json' }` | Налаштування JSON-репортера; `fileName` — шлях для запису підсумкового звіту.                                              |
-| `incremental`      | `boolean`  | `true`                                          | Вмикає incremental-режим: Stryker зберігає результати між запусками й перевикористовує їх.                                 |
-| `incrementalFile`  | `string`   | `'reports/stryker/incremental.json'`            | Шлях до файлу зі станом incremental-режиму (попередні результати мутацій).                                                 |
-
-## Функції
-
-Файл **не містить функцій, класів чи виконуваного коду** — це чисто декларативний конфігураційний модуль. Він лише експортує літерал-об'єкт.
-
-### Side effects
-
-Side effects на рівні модуля **відсутні**:
-
-- немає звернень до файлової системи в момент імпорту;
-- немає викликів зовнішніх API;
-- немає мутацій глобальних об'єктів;
-- немає динамічних `import()` чи `require`.
-
-Усі ефекти виникають **пізніше** — коли Stryker CLI читає цей модуль і застосовує його опції під час запуску mutation-тестування.
-
-## Залежності
-
-### Runtime-залежності
-
-Файл **не імпортує** жодних модулів і не має runtime-залежностей.
-
-### Type-only залежності (через JSDoc)
-
-| Пакет                   | Імпортований символ     | Призначення                                                                                        |
-| ----------------------- | ----------------------- | -------------------------------------------------------------------------------------------------- |
-| `@stryker-mutator/core` | `PartialStrykerOptions` | Тип для type-checking структури об'єкта конфігурації в IDE/TypeScript. На runtime не підтягується. |
-
-### Опосередковані залежності (потрібні Stryker-у під час прогону)
-
-Хоча файл їх не імпортує, для виконання конфігурації в робочому проєкті мають бути встановлені:
-
-| Пакет                            | Роль                                                                                   |
-| -------------------------------- | -------------------------------------------------------------------------------------- |
-| `@stryker-mutator/core`          | Ядро Stryker.                                                                          |
-| `@stryker-mutator/vitest-runner` | Плагін test-runner-а для Vitest (підвантажується за значенням `testRunner: 'vitest'`). |
-| `vitest`                         | Сам Vitest з конфігом `vitest.config.js` у корені проєкту.                             |
-
-### Файлові залежності
-
-- `vitest.config.js` (відносний шлях від робочого каталогу запуску Stryker-у) — Vitest-конфіг, який Stryker реюзає.
-
-### Вихідні артефакти (створюються Stryker-ом)
-
-| Шлях                               | Що містить                                                     |
-| ---------------------------------- | -------------------------------------------------------------- |
-| `reports/stryker/.tmp/`            | Тимчасові файли під час прогону (видаляються/перезаписуються). |
-| `reports/stryker/mutation.json`    | Підсумковий JSON-звіт із результатами всіх мутантів.           |
-| `reports/stryker/incremental.json` | Стан incremental-режиму для прискорення наступних прогонів.    |
-
-## Потік виконання / Використання
-
-### Як файл використовується
-
-Файл розміщений у тестовій директорії `npm/rules/test/js/data/stryker_config/` і призначений як **тестова фікстура / еталон** для перевірочних правил (rule-checks), що валідують Stryker-конфіги в реальних воркспейсах монорепо. Тобто rule-checker може:
-
-1. читати цей файл як «known good» приклад;
-2. порівнювати з ним конфіги воркспейсів;
-3. виявляти відхилення (відсутність `incremental`, неправильний `coverageAnalysis`, неправильний `testRunner` тощо).
-
-### Якби файл застосовувався як справжній Stryker-конфіг
-
-Якщо покласти його в корінь воркспейсу під ім'ям `stryker.config.mjs`, Stryker CLI підхопить його автоматично. Запуск:
-
-```bash
-bunx stryker run
-```
-
-Потік виконання:
-
-1. **Завантаження конфігу.** Stryker CLI читає `stryker.config.mjs`, бере дефолтний експорт як `PartialStrykerOptions`.
-2. **Розв'язання test-runner-а.** За значенням `testRunner: 'vitest'` Stryker динамічно підвантажує `@stryker-mutator/vitest-runner`.
-3. **Ініціалізація Vitest.** Vitest-runner читає `vitest.config.js` (поле `vitest.configFile`) і налаштовує Vitest-інстанс.
-4. **Перевірка incremental-стану.** Якщо файл `reports/stryker/incremental.json` існує (`incremental: true`), Stryker завантажує попередні результати й пропускає ті мутанти, що не змінилися (дає **~262×** прискорення на noop-прогонах згідно коментаря в коді, з посиланням на `benchmarks/runner-comparison/SPIKE.md`).
-5. **Coverage analysis.** Stryker генерує coverage-карту й для кожного мутанта (`perTest`) обирає лише підмножину тестів, що покривають мутовану лінію, замість прогону всього test-suite.
-6. **Прогон мутантів.** Concurrency за замовчуванням — `os.cpus().length - 1` (як зазначено в коментарях; явно в конфізі не задано). vitest-runner ізолює мутантів **у пам'яті через AST-patching** — не копіює `node_modules` у sandbox, що було проблемою command-runner-а в Bun-монорепо.
-7. **Тимчасові артефакти.** Усе проміжне пишеться у `reports/stryker/.tmp/`.
-8. **Звітування.** Після завершення:
-   - `clear-text` репортер друкує підсумок у термінал;
-   - `jsonReporter` пише машинний звіт у `reports/stryker/mutation.json`;
-   - оновлюється `reports/stryker/incremental.json` для майбутніх прогонів.
-
-### Ключові архітектурні рішення (з коментарів у файлі)
-
-- **`perTest` замість `all` / `off`** — головний приріст швидкості проти `commandRunner`, де треба ганяти весь test-suite на кожного мутанта.
-- **Без `inPlace`** — vitest-runner ізолює мутантів через AST-patching у пам'яті, тому копіювання робочої директорії не потрібне (стара проблема command-runner-а у Bun monorepo).
-- **`incremental: true`** — критично для CI/локальних повторних прогонів: відновлює стан після крашу/kill і дає ~262× прискорення на noop-прогонах.
-
-### Передумови запуску (контракт середовища)
-
-- існує `vitest.config.js` у CWD;
-- встановлені `@stryker-mutator/core`, `@stryker-mutator/vitest-runner`, `vitest`;
-- тека `reports/stryker/` доступна для запису (Stryker створює її автоматично);
-- наявні тести під Vitest, що покривають кодову базу, яку планується мутувати.
-
-### Інтеграція з правилами проєкту
-
-Через шлях `npm/rules/test/js/data/...` файл є вхідними даними для тестів rule-чекерів (див. `.cursor/rules/n-test.mdc`, `.cursor/rules/n-bun.mdc`). Ці чекери, ймовірно, валідують Stryker-конфіги воркспейсів на відповідність цьому baseline (наприклад, що `testRunner === 'vitest'`, `coverageAnalysis === 'perTest'`, `incremental === true`).
+- Read-only: файл не виконує операцій запису у файлову систему.
+- Не звертається до мережі.