@nitra/cursor 12.8.0 → 12.8.2

package/rules/test/js/stryker_config.mjs

@@ -18,7 +18,7 @@ const STRYKER_VUE_PLUGIN_PATH = join(HERE, 'data', 'stryker_config', 'stryker-vu
 const STRYKER_VUE_PLUGIN_FILENAME = 'stryker-vue-macros-ignorer.mjs'
 const VITEST_BASELINE_PATH = join(HERE, 'data', 'vitest_config', 'vitest.config.baseline.js')
 
-// Канонічна назва vitest-конфіга — `.mjs` (нові файли, js-lint.mdc); legacy
+// Канонічна назва vitest-конфіга — `.mjs` (нові файли, js.mdc); legacy
 // `.js` лишається валідним. Перший знайдений виграє (.mjs пріоритетніший).
 const VITEST_CONFIG_NAMES = ['vitest.config.mjs', 'vitest.config.js']
 // Заміна literal `configFile` у скопійованому stryker-baseline на фактичне
@@ -332,14 +332,14 @@ export async function check(cwd = process.cwd()) {
   const reporter = createCheckReporter()
   const config = await readNCursorConfigLite(cwd)
 
-  // Self-gate: js-lint має бути enabled
-  if (!config.rules.includes('js-lint') || config.disableRules.includes('js-lint')) {
+  // Self-gate: js має бути enabled
+  if (!config.rules.includes('js') || config.disableRules.includes('js')) {
     return reporter.getExitCode()
   }
 
   const jsRoots = await resolveAllJsRoots(cwd)
   if (jsRoots.length === 0) {
-    reporter.fail('test: js-lint enabled, але кореневий package.json не знайдено (test.mdc)')
+    reporter.fail('test: js enabled, але кореневий package.json не знайдено (test.mdc)')
     return reporter.getExitCode()
   }
 

package/rules/test/js/vitest-config-pool-forks.mjs

@@ -8,7 +8,7 @@ import { createCheckReporter } from '../../../scripts/lib/check-reporter.mjs'
 /** Subтring-pattern: `pool: 'forks'` або `pool: "forks"` (з опційним whitespace). */
 const POOL_FORKS_RE = /pool\s*:\s*['"]forks['"]/u
 
-// Канонічна назва — `.mjs` (нові файли, js-lint.mdc), але legacy `.js` лишається
+// Канонічна назва — `.mjs` (нові файли, js.mdc), але legacy `.js` лишається
 // валідним. Перший знайдений виграє: `.mjs` пріоритетніший.
 const VITEST_CONFIG_NAMES = ['vitest.config.mjs', 'vitest.config.js']
 

package/rules/test/test.mdc

@@ -1,5 +1,5 @@
 ---
-description: JS-тести (*.test.mjs) живуть у tests/. Правило `test` керує stryker.config.mjs + vitest.config.mjs (якщо js-lint enabled) і .cargo/mutants.toml (якщо rust enabled).
+description: JS-тести (*.test.mjs) живуть у tests/. Правило `test` керує stryker.config.mjs + vitest.config.mjs (якщо js enabled) і .cargo/mutants.toml (якщо rust enabled).
 version: '2.8'
 globs: "**/{.n-cursor.json,package.json,Cargo.toml,stryker.config.mjs,vitest.config.mjs,vitest.config.js,.cargo/mutants.toml},**/*.test.mjs"
 alwaysApply: false
@@ -132,7 +132,7 @@ test.skipIf(env.STRYKER_MUTATOR_WORKER)('узгоджені з поточним
 
 **Scoped-режим `--changed`:** `n-cursor coverage --changed` звужує scope до файлів, змінених від git merge-base поточної гілки з `main` або `origin/main`; якщо обидва refs відсутні — до робочого дерева vs HEAD. `git diff <base>` проти робочого дерева ловить committed і uncommitted однаково, тож результат не залежить від того, чи крок уже закомічено. Недосяжний `base` (rebase/force-update) — fail-closed (помилка, не тихий pass). JS-провайдер ганяє `vitest --changed <base>` (лише зачеплені тести) і Stryker `--mutate` по змінених production-файлах (тест-файли відкидаються); roots без змінених JS пропускаються. Rust-провайдер пропускається, якщо не змінено `.rs`/`Cargo.*` (інакше — повний crate-прогін; per-file scoping cargo-mutants — окремий крок). Порожній scope (нема релевантних змін) — pass. У changed-режимі `COVERAGE.md` **не** перезаписується (рішення гейту — лише exit-код) і LLM-класифікація не запускається. Швидкі gate-и викликають саме `coverage --changed`; повний coverage (увесь проєкт, запис `COVERAGE.md`) лишається для `bun run coverage` / `/n-coverage-fix`.
 
-Провайдери живуть у `npm/rules/<rule>/coverage/coverage.mjs` (постачаються правилами мови/рантайму: `js-lint`, `rust`, у майбутньому `python` тощо). Оркестратор — у `npm/rules/test/coverage/coverage.mjs`.
+Провайдери живуть у `npm/rules/<rule>/coverage/coverage.mjs` (постачаються правилами мови/рантайму: `js`, `rust`, у майбутньому `python` тощо). Оркестратор — у `npm/rules/test/coverage/coverage.mjs`.
 
 У `package.json` (корінь) має бути `scripts.coverage` із викликом `n-cursor coverage`:
 
@@ -144,7 +144,7 @@ test.skipIf(env.STRYKER_MUTATOR_WORKER)('узгоджені з поточним
 
 ## Налаштування mutation-testing
 
-Якщо у `.n-cursor.json#rules` присутнє правило `js-lint` — правило `test` створює canonical baseline `stryker.config.mjs` + `vitest.config.mjs` у **кожному** JS-root проєкту: у кожному workspace з власним `package.json` (або в корені для single-package). У monorepo з `workspaces: ['app', 'scripts']` отримаєте `app/stryker.config.mjs` + `app/vitest.config.mjs` і `scripts/stryker.config.mjs` + `scripts/vitest.config.mjs`. Якщо у JS-root уже лежить legacy `vitest.config.js` — він лишається валідним, новий `.mjs` поряд не створюється, а `vitest.configFile` у скопійованому `stryker.config.mjs` приводиться до фактичного імені.
+Якщо у `.n-cursor.json#rules` присутнє правило `js` — правило `test` створює canonical baseline `stryker.config.mjs` + `vitest.config.mjs` у **кожному** JS-root проєкту: у кожному workspace з власним `package.json` (або в корені для single-package). У monorepo з `workspaces: ['app', 'scripts']` отримаєте `app/stryker.config.mjs` + `app/vitest.config.mjs` і `scripts/stryker.config.mjs` + `scripts/vitest.config.mjs`. Якщо у JS-root уже лежить legacy `vitest.config.js` — він лишається валідним, новий `.mjs` поряд не створюється, а `vitest.configFile` у скопійованому `stryker.config.mjs` приводиться до фактичного імені.
 
 Канон Stryker config (Vitest runner + perTest): [stryker.config.baseline.mjs](./js/data/stryker_config/stryker.config.baseline.mjs)
 
@@ -202,7 +202,7 @@ Customization (mutate patterns, exclude rules, timeout) — відповідал
 
 Якщо інше правило спеціалізує mutation-behavior — воно зобов'язане **доповнювати** існуючий `.cargo/mutants.toml` без дублювання (додавати лише відсутні ключі) і **не перетирати** ручні налаштування. Послідовний запуск `npx @nitra/cursor fix test` після `fix tauri` не має скидати tauri-tuning, і навпаки — повторний `fix tauri` не дублює секції.
 
-Додатково: коли `js-lint` enabled, концерн `stryker_config` без дублювання додає у кореневий `.gitignore` тест-патерни:
+Додатково: коли `js` enabled, концерн `stryker_config` без дублювання додає у кореневий `.gitignore` тест-патерни:
 
 - `**/reports/stryker/` — увесь каталог Stryker-output-у (backup'и `tempDirName`, `mutation.json`, HTML/dashboard-репорти якщо додасте інші reporter-и).
 - `**/coverage/` — весь output vitest v8 coverage (`lcov.info` + HTML `lcov-report/`). Ефемерний: регенерується кожним прогоном, фінальні метрики живуть у `COVERAGE.md`. Gitignore не заважає `n-cursor coverage` читати `lcov.info` у тому ж прогоні.

package/rules/text/docs/main.md

@@ -3,26 +3,26 @@ type: JS Module
 title: main.mjs
 resource: npm/rules/text/main.mjs
 docgen:
-  crc: deba6201
+  crc: 8a0470de
   model: omlx/gemma-4-e4b-it-OptiQ-4bit
   score: 90
 ---
 
 ## Огляд
 
-CLI-обгортка над канонічним `lint-text` (text.mdc) забезпечує послідовний пайплайн перевірок для текстових файлів. Вона автоматично встановлює необхідні інструменти (`shellcheck`, `dotenv-linter`) через `ensureTool` (brew/scoop/GitHub Release per-platform) та перевіряє наявність `patch` для авто-фіксу. Пайплайн послідовно виконує: перевірку правопису (`cspell` з `@nitra/cspell-dict`), синтаксичну перевірку скриптів (`shellcheck` з авто-фіксом), перевірку конфігураційних файлів (`dotenv-linter` з авто-фіксом), форматування Markdown (`markdownlint-cli2` з авто-фіксом) та валідацію схем (`v8r`). Перший ненульовий код, отриманий у ланцюжку, повертається як код виходу, припиняючи подальші кроки. Функціональність експортується як `runLintTextCli` та викликається через `n-cursor lint text` (оркестраторний адаптер `lint`). Конфігурації, на які спирається код: meta.json.
+Цей модуль є CLI-обгорткою над канонічним `lint-text` (text.mdc) та викликається через `n-cursor lint text` (оркестраторний адаптер `lint`). Він автоматично встановлює необхідні інструменти (`shellcheck`, `dotenv-linter`) через `ensureTool` (brew/scoop/GitHub Release per-platform) та перевіряє наявність `patch` (для авто-фіксу shellcheck). Функція `runLintTextCli` послідовно виконує: 1) перевірку правопису з `@nitra/cspell-dict` (`cspell .`); 2) авто-фікс та фінальну перевірку `.sh` файлів (`shellcheck`); 3) авто-фікс та фінальну перевірку `.env*` файлів (`dotenv-linter`); 4) авто-фікс Markdown-документів (`markdownlint-cli2 --fix "**\/*.md" "**\/*.mdc"`); 5) schema-валідацію JSON/YAML/TOML через `v8r`. При першому ненульовому коді з ланцюжка повертається код виходу, і наступні кроки не запускаються. Конфігурації, на які спирається код: meta.json.
 
 ## Поведінка
 
-run: Викликається як check-поверхня, виконуючи стандартне правило.
-runLintTextCli: Виконує повний ланцюжок перевірок для тексту: `cspell`, `shellcheck`, `dotenv-linter`, `markdownlint-cli2` та валідацію схем через `v8r`. Автоматично встановлює `shellcheck` та `dotenv-linter` при першому прогоні. Повертає код першого кроку, що не пройшов.
-lint: Делегує виконання повного ланцюжка перевірок тексту через `runLintTextCli`, дозволяючи вказати режим лише детектування без авто-фіксу.
+run виконує стандартну перевірку, використовуючи контекст прогону.
+runLintTextCli виконує повний ланцюжок перевірок тексту (cspell, shellcheck, dotenv-linter, markdownlint, v8r), автоматично встановлюючи необхідні інструменти, і повертає код першого порушення.
+lint делегує виклик `runLintTextCli` для виконання повного ланцюжка перевірок тексту.
 
 ## Публічний API
 
-run — Точка входу правила, що виконує перевірку логіки (JS-занепокложення → політика → посилання text.mdc).
-runLintTextCli — Публічна команда для CLI, яка серіалізує завдання лінтування з блокуванням та усуває дублікати на основі стану репозиторію.
-lint — Адаптер, що керує запуском лінтування тексту через `n-cursor lint text`, делегуючи роботу `runLintTextCli`.
+run — Основна точка входу правила, що виконує перевірку логіки (JS-занепокоєння $\rightarrow$ політика $\rightarrow$ маркування повідомлень).
+runLintTextCli — Публічний інтерфейс командного рядка для лінтингу тексту, що серіалізує через блокування та усуває дублікати на основі стану Git.
+lint — Координатор, що передає завдання лінтингу тексту до `runLintTextCli`.
 
 ## Гарантії поведінки
 

package/rules/text/js/docs/cspell-fix.md

@@ -3,26 +3,26 @@ type: JS Module
 title: cspell-fix.mjs
 resource: npm/rules/text/js/cspell-fix.mjs
 docgen:
-  crc: 7b40e8f9
+  crc: e00c233e
   model: omlx/gemma-4-e4b-it-OptiQ-4bit
   score: 100
 ---
 
 ## Огляд
 
-Виявляє невідомі слова у тексті у ланцюжку lint-text із omlx-класифікацією (спека docs/specs/2026-06-15-opportunistic-llm-fix-tier.md), використовуючи конфігурації .cspell.json та meta.json. Класифікує знахідки за схемою omlx-класифікація, дописуючи валідні терміни до словника .cspell.json. Ймовірні одруки залишаються списком на рев'ю, оскільки fix-режим не переписує файли. Завершує процес повторною перевіркою, щоб визначити, чи залишилися нерозкласифіковані або ймовірні одруки. Перехоплює помилки (fail-safe), не кидаючи винятків назовні.
+Модуль інтегрує cspell у ланцюжку lint-text для класифікації невідомих слів згідно зі схемою docs/specs/2026-06-15-opportunistic-llm-fix-tier.md. Він виявляє невідомі слова, класифікує їх за допомогою LLM у межах omlx-класифікації. Валідні слова автоматично дописуються до `.cspell.json#words` (відповідно до конфігурацій .cspell.json та meta.json). Невалідні знахідки залишаються для ручного рев'ю. Процес є read-only (нуль мутацій), оскільки fix-режим не переписує файли, а лише класифікує знахідки. Після дописування словника виконується re-detect. Гейт-механізм гарантує, що cspell поверне ненульовий код, якщо нерозкласифіковані або потенційні одруки залишилися.
 
 ## Поведінка
 
-unknownWords витягує унікальні невідомі слова з виводу cspell.
-appendWordsToDict додає класифіковані валідні слова до файлу .cspell.json, оновлюючи його словник.
-runCspellText запускає cspell для виявлення невідомих слів, а при увімкненні omlx-класифікації класифікує їх та дописує валідні слова у словник, після чого повторно перевіряє наявність помилок.
+unknownWords витягує унікальні «Unknown word» з виводу cspell.
+appendWordsToDict дописує класифіковані валідні слова у `.cspell.json#words`, сортуючи та усуваючи дублікати.
+runCspellText запускає cspell, класифікує знахідки за допомогою LLM (якщо `llmFix` встановлено), дописує валідні слова у словник та повторно запускає cspell для перевірки, повертаючи код виходу.
 
 ## Публічний API
 
-unknownWords — Збирає унікальні слова, які не були знайдені у словнику cspell.
-appendWordsToDict — Додає зібрані слова до файлу `.cspell.json#words` у відсортованому та унікальному вигляді для перегляду у Git.
-runCspellText — Виконує перевірку тексту за допомогою cspell, класифікуючи слова та оновлюючи словник за новою схемою.
+unknownWords — Збирає унікальні слова, які не були знайдені у cspell.
+appendWordsToDict — Додає зібрані слова до словника `.cspell.json` у відсортованому та унікальному вигляді.
+runCspellText — Виконує перевірку тексту за допомогою cspell для формування словника за новою схемою.
 
 ## Гарантії поведінки
 

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

@@ -11,7 +11,6 @@ resource: npm/rules/text/js/
 | [cspell-fix.mjs](cspell-fix.md)                 | JS Module |
 | [forbidden-prettier.mjs](forbidden-prettier.md) | JS Module |
 | [formatting.mjs](formatting.md)                 | JS Module |
-| [lint.mjs](lint.md)                             | JS Module |
 | [run-dotenv-linter.mjs](run-dotenv-linter.md)   | JS Module |
 | [run-shellcheck.mjs](run-shellcheck.md)         | JS Module |
 | [run-v8r.mjs](run-v8r.md)                       | JS Module |

package/scripts/lib/docs/discover-checkable-rules.md

@@ -145,8 +145,8 @@ for (const rule of rules) {
 ```javascript
 import { discoverOneRule } from './discover-checkable-rules.mjs'
 
-const rule = await discoverOneRule('/abs/path/to/npm/rules/n-js-lint', 'n-js-lint')
-// rule.id === 'n-js-lint'
+const rule = await discoverOneRule('/abs/path/to/npm/rules/n-js', 'n-js')
+// rule.id === 'n-js'
 // rule.jsConcerns — список JS-концернів у js/
 // rule.policyConcerns — список policy-концернів у policy/
 ```

package/scripts/lib/docs/run-lint.md

@@ -3,27 +3,27 @@ type: JS Module
 title: run-lint.mjs
 resource: npm/scripts/lib/run-lint.mjs
 docgen:
-  crc: dd80d058
+  crc: 24827b04
   model: omlx/gemma-4-e4b-it-OptiQ-4bit
   score: 100
 ---
 
 ## Огляд
 
-Модуль керує вибором та виконанням правил лінтування. Він визначає набір правил для лінтування, спираючись на конфігурації `meta.json` та `.n-cursor.json`. Публічна функція `selectLintRules` вибирає та сортує ці правила на основі їхньої лінт-поверхні. Публічна функція `runLint` ініціює виконання визначеного набору правил, перевіряючи змінені файли або весь репозиторій.
+Модуль ініціалізує та керує процесом лінтування коду. Він вибирає та сортує набір правил для перевірки, використовуючи конфігурації `meta.json` та `.n-cursor.json`. Публічна функція `selectLintRules` виконує вибір правил. Публічна функція `runLint` ініціює повний цикл лінтування, який може включати перевірку змінених файлів або всього репозиторію.
 
 ## Поведінка
 
-selectLintRules вибирає і алфавітно сортує ідентифікатори правил для лінтування на основі їхньої лінт-поверхні та наявності в активних конфігураціях.
-runLint запускає лінт-оркестрацію, виконуючи перевірку змінених файлів або повний прогін репозиторію, залежно від наданих опцій.
+selectLintRules вибирає і алфавітно сортує ідентифікатори правил для лінтування, ґрунтуючись на наявності в конфігурації та заданому обсязі перевірки.
+runLint запускає повну оркестрацію лінтування, виконуючи перевірку змінених файлів або весь репозиторій, залежно від параметрів, і може включати фази конформності та форматування.
 
 ## Публічний API
 
 selectLintRules — обирає ідентифікатори правил для контексту, розташовуючи їх в алфавітному порядку.
 runLint — ініціює процес лінтування.
 full — сканує весь репозиторій, порівнюючи його з початковим станом.
-readOnly — лише виявляє проблеми без внесення змін.
-rules — виконує повне сканування репозиторію, застосовуючи лише вказаний набір правил.
+readOnly — лише виявляє проблеми, не вносячи змін, порівнюючи з початковим станом.
+rules — виконує повне сканування лише для вказаних правил у заданому обсязі.
 
 ## Гарантії поведінки
 

package/scripts/lib/fix/docs/analyze-escalation.md

@@ -3,31 +3,44 @@ type: JS Module
 title: analyze-escalation.mjs
 resource: npm/scripts/lib/fix/analyze-escalation.mjs
 docgen:
-  crc: 5a586df6
+  crc: f26cd4c7
   model: omlx/gemma-4-e4b-it-OptiQ-4bit
   score: 100
 ---
 
-Аналітика escalation-логу fix-конформності. Читає записи рунгів драбини (`escalation-log.mjs`) — весь лог або записи одного прогону (від байтового зсуву), — ділить на чанки за бюджетом символів і просить хмарну **avg**-модель запропонувати, як зменшити LLM-залежність: нові детерміновані T0-патерни, уточнення `.mdc`-інструкцій або зміни скриптів пакета. Результат — markdown-звіт у `.n-cursor/fix-escalation-analysis.md` (append із timestamp). Викликається CLI `n-cursor analyze-escalation` (весь лог) і наприкінці `lint --full` (записи прогону).
+## Огляд
+
+Аналізує записи рунгів драбини з `escalation-log.mjs` для виявлення шляхів зменшення LLM-залежності у fix-конформності. Лог обробляється за один прогін (від байтового зсуву) або повністю, ділячись на чанки для аналізу хмарною **avg**-моделлю. Мета аналізу — визначити конкретні правки пакета `@nitra/cursor`: (A) новий ДЕТЕРМІНОВАНИЙ T0-патерн (`t0.mjs`), (B) уточнення `.mdc`-інструкцій правила, або (C) зміна скрипта/чека. Результат зберігається у markdown-звіт `.n-cursor/fix-escalation-analysis.md` (append із timestamp) після виклику CLI `n-cursor analyze-escalation`.
 
 ## Поведінка
 
-`readEscalationRecords` читає JSONL від байтового зсуву (зсув на межі рядка — мультибайт не б'ється; биті рядки пропускаються); `escalationLogSize` дає зсув для scope «цей прогін». `chunkRecords` стискає записи й ділить на чанки, щоб JSON кожного не перевищив бюджет. `analyzeEscalations` (синхронний — callLlm spawnSync-based) робить виклик avg-моделі по кожному чанку, а за кількох чанків — фінальний синтез; помилки моделі ковтаються в `null` (аналіз не валить lint). `maybeAnalyzeEscalation` — хук lint: gated kill-switch `N_CURSOR_FIX_ANALYZE`, наявністю `CLOUD_AVG` і записів.
+analysisEnabled визначає, чи дозволено виконувати автоматичний аналіз ескалації наприкінці процесу `lint`.
+escalationLogSize повертає розмір файлу логу ескалації у байтах.
+readEscalationRecords читає записи логу ескалації, починаючи з заданого байтового зсуву, та повертає їх як масив об'єктів.
+summarizeCalls рахує кількість викликів моделей для різних рівнів (локальний, cloud-min, cloud-avg) у наданих записах.
+reportRunStats друкує резюме кількості викликів моделей для поточного прогону, використовуючи заданий байтовий зсув.
+chunkRecords ділить масив стиснених записів на менші чанки, щоб кожен чанк не перевищив заданий бюджет символів.
+analyzeEscalations аналізує надані записи, ділить їх на чанки, викликає модель для аналізу кожного чанка, а потім синтезує фінальний звіт.
+analysisReportPath повертає шлях до файлу, де зберігається звіт аналізу ескалації.
+writeAnalysisReport дописує згенерований звіт у markdown-файл у відповідному шляху, додаючи до нього мітку часу.
+runEscalationAnalysisCli виконує повний аналіз всього логу ескалації та записує звіт.
+maybeAnalyzeEscalation виконує аналіз ескалацій лише для записів поточного прогону, якщо дозволено та є необхідні умови.
 
 ## Публічний API
 
-- `summarizeCalls(records)` — лічильники фактичних викликів за тирами `{ local, cloudMin, cloudAvg }` (skip-записи avg-кепу не рахуються).
-- `reportRunStats(sinceOffset, log)` — друкує резюме викликів моделей за прогін (no-op, якщо викликів не було).
-- `analysisEnabled()` — чи дозволено авто-аналіз (kill-switch `N_CURSOR_FIX_ANALYZE`).
-- `escalationLogSize(path?)` — розмір логу в байтах (since-offset).
-- `readEscalationRecords(path, sinceOffset?)` — записи від зсуву.
-- `chunkRecords(records, maxChars?)` — чанки стиснених записів.
-- `analyzeEscalations(records, opts?)` — `{ report, chunks, reason }`; `opts.callLlm` інжектовний.
-- `analysisReportPath(cwd?)` / `writeAnalysisReport(report, cwd, ts)` — шлях/запис звіту.
-- `runEscalationAnalysisCli(args, cwd?)` — CLI: весь лог → звіт.
-- `maybeAnalyzeEscalation(cwd, sinceOffset, log)` — хук наприкінці `lint --full`.
+analysisEnabled — Вмикає автоматичний аналіз після завершення lint.
+escalationLogSize — Визначає максимальний розмір escalation-логу в байтах.
+readEscalationRecords — Зчитує записи з логу, починаючи з заданого байтового зсуву.
+summarizeCalls — Підраховує реальні виклики моделей за тирами, ігноруючи записи про середнє кешування.
+reportRunStats — Виводить підсумок викликів моделей за поточний запуск.
+chunkRecords — Розбиває записи на менші частини, щоб розмір JSON кожного чанку не перевищував заданий ліміт.
+analyzeEscalations — Обробляє записи: розбиває їх на чанки, викликає модель для кожного чанку та синтезує результат, якщо чанків більше одного.
+analysisReportPath — Вказує шлях для збереження markdown-звіту аналізу.
+writeAnalysisReport — Додає звіт до markdown-файлу, додаючи до нього мітку часу.
+runEscalationAnalysisCli — Виконує повний аналіз всього логу escalation через інтерфейс командного рядка.
+maybeAnalyzeEscalation — Запускає аналіз записів поточного прогону після `lint --full`, якщо це дозволено налаштуваннями.
 
 ## Гарантії поведінки
 
-- Звертається до мережі лише при виклику avg-моделі (через pi/omlx за префіксом model-id).
-- Помилки виклику моделі перехоплює (fail-safe): аналіз не впливає на exit-код lint.
+- Перехоплює помилки і не пропускає винятків назовні (fail-safe).
+- За певних помилок повертає порожнє значення (напр. `null`) замість винятку.

package/scripts/lib/fix/docs/orchestrator.md

@@ -3,38 +3,37 @@ type: JS Module
 title: orchestrator.mjs
 resource: npm/scripts/lib/fix/orchestrator.mjs
 docgen:
-  crc: fbc91330
+  crc: 3bb1b761
   model: omlx/gemma-4-e4b-it-OptiQ-4bit
   score: 100
 ---
 
 ## Огляд
 
-Модуль керує процесом вирішення порушень за допомогою багаторівневої системи ескалації. Він збирає послідовність рівнів моделей, починаючи з локальних і закінчуючи хмарними. Модуль парсить параметри запуску за допомогою `parseOrchestratorArgs` та виконує повний цикл фіксації, застосовуючи детермінований фікс. Для невирішених проблем застосовується ескалація правил через `escalateRule`, а фінальний запуск оркестратора здійснюється через `runOrchestratorCli`, який використовує структуру, побудовану за допомогою `buildLadder`.
+Модуль відповідає за управління процесом виправлення порушень. Він будує послідовність тирів ескалації за допомогою `buildLadder`, парсить аргументи командного рядка за допомогою `parseOrchestratorArgs` та запускає повний цикл виправлення за допомогою `runOrchestratorCli`. Цей цикл включає автоматичний фікс та ескалацію через LLM-моделі, що реалізується функцією `escalateRule`.
 
 ## Поведінка
 
 buildLadder будує послідовність тирів ескалації для вирішення порушень, від локальних мінімальних моделей до хмарних середніх моделей.
-escalateRule проводить один прохід по послідовності тирів, намагаючись вирішити порушення, і повертає статус вирішення та використаний бюджет хмарних викликів.
-parseOrchestratorArgs парсить аргументи командного рядка для визначення максимального бюджету хмарних викликів та фільтра правил.
-runOrchestratorCli виконує повний цикл фіксації: перевіряє правила, застосовує детермінований фікс (T0-auto), а потім використовує LLM-драбину ескалації для невирішених порушень.
+escalateRule виконує один прогін по послідовності тирів, намагаючись вирішити порушення, використовуючи LLM-моделі та фіксуючи результат.
+parseOrchestratorArgs парсить аргументи командного рядка для визначення максимального ліміту викликів хмарної моделі та фільтра правил.
+runOrchestratorCli керує повним процесом виправлення порушень: виконує початкову перевірку, застосовує детермінований фікс (T0-auto), а потім ініціює LLM-драбину ескалації для невирішених правил.
 
 ## Публічний API
 
-buildLadder — Створює послідовність моделей для ескалації, виходячи з доступних рівнів.
+buildLadder — Створює послідовність моделей для ескалації, обмежуючись лише тирами, які доступні.
 
-local-min — Запускає первинний прохід з найменшою локальною моделлю.
-local-min-retry — Повторює локальний прохід, використовуючи відгук від попереднього кроку.
-cloud-min — Запускає прохід з найменшою хмарною моделлю, використовуючи відгук.
-cloud-avg — Запускає прохід з середньою хмарною моделлю, використовуючи відгук та обмеження середнього.
+local-min — Виконує перший прохід з локальною мінімальною моделлю.
+local-min-retry — Повторює локальний прохід, використовуючи результати попереднього рунгу.
+cloud-min — Виконує прохід з хмарною мінімальною моделлю, використовуючи результати попереднього рунгу.
+cloud-avg — Виконує прохід з хмарною середньою моделлю, використовуючи результати попереднього рунгу та обмеження середнього.
 
-escalateRule — Виконує одне правило по драбині ескалації до першого успішного перевірки.
-Кожен рунг — Запускає роботу моделі з урахуванням попереднього відгуку, перевіряє правило, фіксує результат у лозі.
-Достроковий вихід — Зупиняє процес при певних умовах (відсутність ключа, пропуск моделі на системному рівні) або при досягненні ліміту середнього.
+escalateRule — Застосовує одне правило по драбині ескалації до першого позитивного результату.
+Кожен рунг — Викликає модель з попереднім відгуком, перевіряє правило, фіксує результат у лозі. Зупиняється при певних умовах (відсутність ключа, пропуск моделі, перевищення бюджету).
 
-parseOrchestratorArgs — Витягує максимальне значення середнього та збирає список правил для фільтрації з командного рядка.
+parseOrchestratorArgs — Витягує максимальне значення середнього та список фільтрів правил з командного рядка.
 
-runOrchestratorCli — Запускає основний процес оркестрації, обробляючи аргументи та виконуючи ескалацію правил.
+runOrchestratorCli — Запускає основну логіку оркестратора на основі аргументів командного рядка.
 
 ## Гарантії поведінки
 

package/scripts/lib/fix/docs/t0.md

@@ -3,26 +3,27 @@ type: JS Module
 title: t0.mjs
 resource: npm/scripts/lib/fix/t0.mjs
 docgen:
-  crc: 49c0669b
+  crc: cfb0d5c9
   model: omlx/gemma-4-e4b-it-OptiQ-4bit
   score: 100
 ---
 
 ## Огляд
 
-Модуль керує автоматичним застосуванням T0-auto паттернів до виводів порушень. Він визначає, які правила можуть бути оброблені автоматично, використовуючи конфігурації з `extensions.json` та `package-lock.json`. Функціонал реалізовано через публічні функції: `filterT0AutoRules` для визначення правил, `applyT0Auto` для автоматичного застосування паттернів до виводів, та `runT0AutoCli` для запуску процесу. Модуль працює у режимі fail-safe, перехоплюючи помилки та не кидаючи винятків назовні, надаючи звіт про застосовані автоматичні виправлення.
+Модуль керує автоматичним застосуванням паттернів T0-auto до виводів порушень. Він використовує конфігурації з `extensions.json` та `package-lock.json` для визначення правил. Модуль фільтрує правила, які можуть бути автоматично оброблені, застосовує паттерни за допомогою `applyT0Auto`, а потім запускає повний цикл перевірки для всіх провальних правил через `runT0AutoCli`. Усі операції виконуються з механізмом fail-safe, що запобігає виникненню винятків назовні.
 
 ## Поведінка
 
-applyT0Auto застосовує всі визначені T0-auto паттерни до одного виводу порушення, повертаючи результат застосування.
-filterT0AutoRules повертає список ID правил, для яких існує хоча б один T0-auto паттерн, виходячи з виводів порушень.
-runT0AutoCli запускає T0-auto для кожного провального правила, повторно перевіряє конформність та виводить підсумок.
+Поведінка
+applyT0Auto застосовує всі визначені T0-auto паттерни до одного виводу порушення, повертаючи результат застосування та список виконаних дій.
+filterT0AutoRules повертає список ID правил, для яких існує хоча б один T0-auto паттерн, виходячи з виводу порушення.
+runT0AutoCli запускає T0-auto для всіх провальних правил, повторно перевіряє конформність та виводить підсумок щодо закритого чи незакритого порушень.
 
 ## Публічний API
 
 applyT0Auto — вносить зміни до виводу порушень, використовуючи всі визначені T0-auto шаблони.
-filterT0AutoRules — визначає, які правила мають принаймні один T0-auto шаблон, ґрунтуючись на виводі порушень у форматі JSON.
-runT0AutoCli — виконує команду `n-cursor fix-t0 [rule...]`, яка застосовує T0-auto до кожного порушення, повторно перевіряє check-gate та надає звіт.
+filterT0AutoRules — визначає, які правила мають відповідні T0-auto шаблони, аналізуючи вивід порушень, отриманий з `fix --json`.
+runT0AutoCli — виконує команду `n-cursor fix-t0 [rule...]`, що включає застосування T0-auto до кожного порушення, повторну перевірку check-gate та виведення результату.
 
 ## Гарантії поведінки
 

package/scripts/lib/gha-workflow.mjs

@@ -1,7 +1,7 @@
 /**
  * Допоміжні функції для аналізу GitHub Actions workflow (`.yml`) після структурного розбору YAML.
  *
- * Використовується в check-ga, check-js-lint, check-text, check-style-lint, check-npm-module замість
+ * Використовується в check-ga, check-js, check-text, check-style-lint, check-npm-module замість
  * пошуку підрядків у сирому тексті там, де важливі лише значення `uses:` та `run:` кроків.
  *
  * Для `run:` також виявляється shell-продовження рядка через `\\` перед переносом (антипатерн у ga.mdc).

package/scripts/lib/timing-summary.mjs

@@ -41,7 +41,7 @@ export function formatDurationMs(ms) {
  * ```
  *
  * Ширина колонки id вирівнюється під найдовший id у списку. Мінімальна ширина risk — 14
- * (узгоджено з типовою довжиною заголовків `fix-js-lint` / `lint-security`).
+ * (узгоджено з типовою довжиною заголовків `fix-js` / `lint-security`).
  * @param {string} title заголовок таблиці (наприклад, `Fix timing` або `Lint timing`)
  * @param {TimingEntry[]} timings записи в порядку запуску — друкуються як є, не сортуються
  * @returns {string} готовий до stdout текст з кінцевим `\n`

package/scripts/sync-setup-bun-deps-action.mjs

@@ -2,7 +2,7 @@
  * Копіює composite GitHub Action `setup-bun-deps` з установленого пакету `@nitra/cursor`
  * у цільовий репозиторій (`.github/actions/setup-bun-deps/action.yml`).
  *
- * Використовується CLI `npx \@nitra/cursor`, щоб workflows з правил `ga` / `js-lint` / `text`
+ * Використовується CLI `npx \@nitra/cursor`, щоб workflows з правил `ga` / `js` / `text`
  * могли одразу викликати `uses: ./.github/actions/setup-bun-deps` після кроку `actions/checkout@v6` (без checkout runner не знайде action.yml).
  *
  * Джерело: каталог `github-actions/setup-bun-deps/` у корені tarball пакету (поруч із `mdc/`, `bin/`).

package/scripts/utils/resolve-js-root.mjs

@@ -1,7 +1,7 @@
 /**
  * Резолвить корінь JS-коду в проєкті: для workspace-projects — перший workspace
  * (з підтримкою glob-патернів типу `cf/*`), для single-package — корінь cwd.
- * Спільна утиліта для coverage-провайдера js-lint і test-концерну stryker_config (DRY).
+ * Спільна утиліта для coverage-провайдера js і test-концерну stryker_config (DRY).
  */
 import { existsSync } from 'node:fs'
 import { glob, readFile } from 'node:fs/promises'

package/skills/coverage-fix/meta.json

@@ -1 +1 @@
-{ "auto": ["js-lint"], "worktree": true }
+{ "auto": ["js"], "worktree": true }

package/skills/lint/SKILL.md

@@ -52,7 +52,7 @@ bun run lint
 | **oxlint / ESLint** | `.oxlintrc.json` → `ignorePatterns`; `eslint.config.js` → `ignores`; `eslint-disable` / `oxlint-disable` у коді |
 | **інше**            | `.v8rignore`, `.stylelintignore`, `.trufflehog-exclude`, розширення `ignores` у workflow-конфігах               |
 
-Політика узгоджена з **`.cursor/rules/`** (зокрема **n-js-lint**, **n-text**): виняток допустимий лише з **обґрунтованою** причиною, не як заміна рефакторингу для справжніх клонів / дублікатів.
+Політика узгоджена з **`.cursor/rules/`** (зокрема **n-js**, **n-text**): виняток допустимий лише з **обґрунтованою** причиною, не як заміна рефакторингу для справжніх клонів / дублікатів.
 
 ### Коли обовʼязково питати користувача
 
@@ -109,7 +109,7 @@ bun run lint
 - **oxlint**: **`--threads=1`**, якщо потрібно зменшити навантаження на CPU.
 - **ESLint cache**: **`--cache`** / **`--cache-location .eslintcache`** — менше повторного читання з диска.
 
-Канонічний рядок **`lint-js`** у репозиторіях з **`check js-lint`** фіксований; додаткові прапорці — з узгодженням канону або в споживацькому проєкті окремо.
+Канонічний рядок **`lint-js`** у репозиторіях з **`check js`** фіксований; додаткові прапорці — з узгодженням канону або в споживацькому проєкті окремо.
 
 ## Примітка
 

package/skills/llm-patch/SKILL.md

@@ -242,7 +242,7 @@ description: >-
 
 # Обмеження
 
-- Дотриматись `.cursor/rules/n-js-lint.mdc` і `.cursor/rules/n-changelog.mdc`
+- Дотриматись `.cursor/rules/n-js.mdc` і `.cursor/rules/n-changelog.mdc`
   (зміни у workspace = change-файл, не ручний CHANGELOG/version bump).
 - Якщо `eslint ^9` офіційно не підтримує Node 25 — підняти peer range.
 

package/rules/js-lint-ci/docs/fix.md

@@ -1,28 +0,0 @@
----
-type: JS Module
-title: fix.mjs
-resource: npm/rules/js-lint-ci/fix.mjs
-docgen:
-  crc: 38cf876b
-  score: 100
----
-
-Файл застосовує визначене правило до вхідного контексту прогону. Застосовує правило та повертає отриманий результат.
-
-## Поведінка
-
-1. Запуск правила.
-   - Приймає контекст прогону.
-   - Виконує правило.
-   - Повертає результат.
-
-## Публічний API
-
-run — запускає правило: applies → JS-concerns → policy → mdc-refs (через runStandardRule).
-Library mode — викликається CLI orchestration через `import + run`.
-
-## Гарантії поведінки
-
-- Read-only: файл не виконує операцій запису у файлову систему.
-- Кешує результати в межах одного прогону.
-- Не звертається до мережі.

package/rules/js-lint-ci/docs/index.md

@@ -1,12 +0,0 @@
----
-type: Directory Index
-title: npm/rules/js-lint-ci
-resource: npm/rules/js-lint-ci/
----
-
-# npm/rules/js-lint-ci
-
-| Файл                | Тип       |
-| ------------------- | --------- |
-| [fix.mjs](fix.md)   | JS Module |
-| [main.mjs](main.md) | JS Module |

package/rules/js-lint-ci/docs/main.md

@@ -1,27 +0,0 @@
----
-type: JS Module
-title: main.mjs
-resource: npm/rules/js-lint-ci/main.mjs
-docgen:
-  crc: 59cd2fd3
-  model: omlx/gemma-4-e4b-it-OptiQ-4bit
-  score: 100
----
-
-## Огляд
-
-Модуль надає інструменти для глибокого аналізу коду. Функція `run` виконує перевірку коду відповідно до заданого контексту прогону. Функція `lint` порівнює файли репозиторію для виявлення дублікатів та неіспользумого коду.
-
-## Поведінка
-
-run виконує перевірку на основі контексту прогону.
-lint виконує крос-файловий аналіз репозиторію на дублікати та мертвий код.
-
-## Публічний API
-
-run — точка входу для виконання правила, що включає перевірку логіки застосування (JS-занепокложення $\to$ політика $\to$ посилання MDC) та аналіз коду (jscpd + knip) по всьому репозиторію.
-lint — аналіз коду по всьому репозиторію на наявність дублікатів (jscpd) та мертвого коду (knip).
-
-## Гарантії поведінки
-
-- Read-only: не виконує операцій запису (ФС/БД).

package/rules/js-lint-ci/js/docs/index.md

@@ -1,11 +0,0 @@
----
-type: Directory Index
-title: npm/rules/js-lint-ci/js
-resource: npm/rules/js-lint-ci/js/
----
-
-# npm/rules/js-lint-ci/js
-
-| Файл                | Тип       |
-| ------------------- | --------- |
-| [lint.mjs](lint.md) | JS Module |