@nitra/cursor 12.6.0 → 12.7.0

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

@@ -3,27 +3,27 @@ type: JS Module
 title: run-lint-step.mjs
 resource: npm/scripts/lib/run-lint-step.mjs
 docgen:
-  crc: 5932fa98
+  crc: f37a61b9
+  model: omlx/gemma-4-e4b-it-OptiQ-4bit
+  score: 100
 ---
 
-Цей файл забезпечує спільний хелпер для запуску окремих кроків у ланцюжку linting, що використовується CLI-обгортками. Він імітує прямий виклик команд у shell, логуючи команди та перенаправляючи stdout/stderr на користувацькі stream-и. Це дозволяє уникнути дублювання обгорток у різних `rules/<id>/js/lint.mjs` файлах.
+Спільний хелпер для CLI-обгорток `lint-<rule>`. Він запускає один крок ланцюжка з логуванням команди та прокидає stdout/stderr на користувацькі stream-и (`stdio: 'inherit'`). Це дозволяє rule-адаптерам `n-cursor lint <rule>` уникнути дублювання логіки обгортки у файлах `rules/<id>/js/lint.mjs`. Функція не виконує операцій з файловою системою чи базою даних.
 
 ## Поведінка
 
-1.  Записує в лог повідомлення про початок виконання кроку ланцюжка з описом команди та її аргументів.
-2.  Визначає шлях до виконуваного файлу команди на основі її імені.
-3.  Якщо шлях не знайдено в системному PATH, записує повідомлення про помилку та повертає код 127.
-4.  Запускає визначену команду з заданими аргументами, передаючи стандартний потік введення/виведення (stdio) потокам користувача.
-5.  Якщо команда завершилася з помилкою, записує повідомлення про помилку та повертає код 1.
-6.  Якщо команда завершилася успішно, повертає код виходу дочірнього процесу, який дорівнює 0, якщо все добре, або 1, якщо виникла помилка.
+1. Викликається `runLintStep` для запуску одного кроку ланцюжка лінтування.
+2. Виводиться у консоль повідомлення про запуск команди з вказаним заголовком.
+3. Визначається повний шлях до команди.
+4. Якщо повний шлях до команди не знайдено в PATH, виводиться повідомлення про помилку, і функція повертає код 127.
+5. Запускається дочірній процес з успадкованими потоками виводу та помилки.
+6. Якщо виникає помилка при запуску процесу, виводиться повідомлення про помилку, і функція повертає код 1.
+7. Якщо процес успішно запущено, функція повертає код виходу дочірнього процесу.
 
 ## Публічний API
 
-runLintStep — запускає процес linting та перевіряє його успішність.
+runLintStep — запускає один етап перевірки коду, знаходячи відповідну команду в системному шляху та виконуючи її з передаченим вхідно-вихідним потоком.
 
 ## Гарантії поведінки
 
-- Запускає один крок ланцюжка linting.
-- Перенаправляє stdout та stderr на користувацькі stream-и (stdio: 'inherit').
-- Не використовує кешування.
-- Не має внутрішніх приватних імен.
+- Read-only: не виконує операцій запису (ФС/БД).

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

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

package/scripts/lib/docs/run-rule-cli.md

@@ -3,22 +3,26 @@ type: JS Module
 title: run-rule-cli.mjs
 resource: npm/scripts/lib/run-rule-cli.mjs
 docgen:
-  crc: 264e7ab0
-  score: 100
+  crc: 1251c4d0
+  model: omlx/gemma-4-e4b-it-OptiQ-4bit
+  score: 95
 ---
 
-Файл є автономним CLI-запускачем для одного правила. Він друкує звіт про перевірку та повертає агрегований код виходу. Whitelist-гейту тут немає: гейтинг активних правил живе виключно у `resolveCheckRuleIds` (селекція за `.n-cursor.json`), а прямий запуск файлу правила — свідома debug/override-дія, тож виконується беззастережно.
+## Огляд
+
+Standalone CLI runner для одного правила. Викликається з `rules/<id>/check.mjs` у блоці `if (import.meta.main)`, що робить його повним еквівалентом `bun rules/<id>/check.mjs` або `npx @nitra/cursor fix <id>`. Цей запуск є свідомим (debug / override) і виконується без whitelist-гейту. Ініціалізує кеш для проходження файлової системи та виконує стандартну перевірку, друкуючи summary результату та повертаючи aggregated exit-code.
 
 ## Поведінка
 
-1.  Викликається для запуску правила.
-2.  Друкує повідомлення про перевірку правила.
-3.  Використовує кеш для перевірки.
-4.  Викликає функцію для виконання стандартного правила з кешем.
-5.  Повертає агрегований код виходу.
+1. Викликається для виконання одного правила у режимі командного рядка.
+2. Визначається ідентифікатор правила на основі шляху до директорії правила.
+3. Виводиться повідомлення про початок перевірки для цього правила.
+4. Ініціалізується кеш для проходження файлової системи.
+5. Виконується стандартна перевірка для правила, використовуючи ініціалізований кеш.
+6. Виводиться підсумок результату перевірки.
+7. Повертається код виходу, що відображає успішність або наявність порушень.
 
 ## Гарантії поведінки
 
-- Read-only: файл не виконує операцій запису у файлову систему.
+- Read-only: не виконує операцій запису (ФС/БД).
 - Кешує результати в межах одного прогону.
-- Не звертається до мережі.

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

@@ -3,24 +3,41 @@ type: JS Module
 title: run-standard-lint.mjs
 resource: npm/scripts/lib/run-standard-lint.mjs
 docgen:
-  crc: e7e3f0ae
+  crc: 2b275963
+  model: omlx/gemma-4-e4b-it-OptiQ-4bit
+  score: 90
 ---
 
-Файл забезпечує централізовану точку запуску для підкоманд `lint-<rule>` у `@nitra/cursor`. Він серіалізує та дедублює запуски, використовуючи `withLock`, щоб гарантувати узгодженість та ефективність. Це дозволяє легко інтегрувати нові правила та обробляти крос-cutting концерни, не вносячи змін у окремі файли правил.
+## Огляд
+
+Спільна точка входу для канонічних `lint-<rule>` підкоманд `@nitra/cursor`. Файл серіалізує та дедуплікує запуски лінту через `withLock`. `ruleId` визначається зі шляху незалежно від глибини виклику (наприклад, `rules/<id>`). Це дозволяє уніфікувати крос-cutting концерни. Інтеграція з боку правила виглядає так:
+* import { runStandardLint } from '../../scripts/lib/run-standard-lint.mjs'
+ *
+ * async function runLintFooSteps { ... }
+ *
+ * export function lint { return runStandardLint }
 
 ## Поведінка
 
-runLintFooCli: Запускає лінт для правила, використовуючи `runStandardLint`.
-runStandardLint: Серіалізує та дедуплікує запуск лінту, використовуючи блокування. Визначає ідентифікатор правила з шляху.
+lint: Викликає стандартизований лінт, використовуючи шлях каталогу правила для визначення його ідентифікатора.
+runStandardLint: Серіалізує та дедуплікує запуск лінту для заданого правила, використовуючи ідентифікатор, виведений зі шляху каталогу правила.
 
 ## Публічний API
 
-- runLintFooCli — Перевіряє код на відповідність стандартам Foo CLI.
-- runStandardLint — Перевіряє код на відповідність загальним стандартам кодування.
+lint — є спільною точкою входу для канонічних `lint-<rule>` підкоманд `@nitra/cursor`. Він ініціює серіалізацію та дедуплікацію запусків лінтингу для вказаних файлів, забезпечуючи централізоване управління крос-cutting концернами.
+
+runStandardLint — виконує стандартний лінтинг у директорії, приймаючи контекст директорії та функцію, що описує кроки лінтингу.
+
+Приклад інтеграції:
+```js
+import { runStandardLint } from '../../scripts/lib/run-standard-lint.mjs'
+
+async function runLintFooSteps { ... }
+
+export function lint { return runStandardLint }
+```
 
 ## Гарантії поведінки
 
-- Приймає `ruleId` з шляху файлу.
-- Створює блокування з іменем `lint-<ruleId>`.
-- Використовує попередньо збережені результати для уникнення повторного виконання.
-- Повертає результат виконання.
+- Read-only: не виконує операцій запису (ФС/БД).
+- Кешує результати в межах одного прогону.

package/scripts/lib/docs/run-standard-rule.md

@@ -3,23 +3,24 @@ type: JS Module
 title: run-standard-rule.mjs
 resource: npm/scripts/lib/run-standard-rule.mjs
 docgen:
-  crc: c1ae8f0e
-  score: 90
+  crc: 0c3b2e60
+  model: omlx/gemma-4-e4b-it-OptiQ-4bit
+  score: 70
 ---
 
-Файл інкапсулює оркестрацію виконання правил. Він забезпечує запуск правила через визначений шлях, ізолюючи його виконання у блоці `withLock` для уникнення паралельних запусків.
+## Огляд
+
+Файл надає публічний API для оркестрації правил, який викликається з `rules/<id>/check.mjs`. Він інкапсулює логіку пошуку єдиного правила (`discoverOneRule`) та його виконання (`runRule`). Виконання обертається у `withLock` для дедуплікації паралельних запусків того самого правила на основі стану git-дерева. Локальна логіка в правилах заборонена; розширення поведінки відбувається через `ctx`-опції. Це централізована точка для запуску стандартних правил з кешуванням у межах одного прогону.
 
 ## Поведінка
 
-1.  Отримання шляху до правила
-2.  Визначення ідентифікатора правила
-3.  Охоплення виконання у блоці блокування
-4.  Пошук правила
-5.  Отримання кешу проходу
-6.  Запуск виконання правила
+1. Викликати `runStandardRule` для певного правила.
+2. Забезпечити унікальну блокування для виконання цього правила, використовуючи його ID.
+3. Виявити єдине правило, пов'язане з наданим шляхом.
+4. Отримати або створити кеш для прогону.
+5. Виконати правило, використовуючи виявлене правило, шлях до пакету та кеш прогону.
 
 ## Гарантії поведінки
 
-- Read-only: файл не виконує операцій запису у файлову систему.
+- Read-only: не виконує операцій запису (ФС/БД).
 - Кешує результати в межах одного прогону.
-- Не звертається до мережі.

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

@@ -3,26 +3,25 @@ type: JS Module
 title: timing-summary.mjs
 resource: npm/scripts/lib/timing-summary.mjs
 docgen:
-  crc: f21a9b91
+  crc: ee74c1cd
+  model: omlx/gemma-4-e4b-it-OptiQ-4bit
+  score: 100
 ---
 
-Цей файл генерує табличне резюме часу виконання для команд `fix` та `lint`, які використовуються в orchestrator. Він підсумовує час виконання окремих правил та скриптів linting, надаючи інформацію для аналізу продуктивності. Результат представлений у вигляді рядка, який можна вивести для відображення користувачеві.
+## Огляд
+
+Формує таблицю-резюме часу виконання для оркестратора `fix` або `lint`. Таблиця використовується після прогону всіх правил перевірки (`runFixCommand` у `bin/n-cursor.js`) або після прогону скриптів лінтингу (`runLintCli` у `scripts/lib/run-lint-cli.mjs`), які визначаються у `package.json`. Звіт містить деталі часу виконання для кожного елемента у форматі `<ціла>.<десята>s`, а маркер `❌` на рядку вказує на невдачу (`ok === false`).
 
 ## Поведінка
 
-formatDurationMs: Перетворює мілісекунди на рядок у форматі `<ціла>.<десята>s`.
-formatTimingSummary: Формує таблицю-резюме часу виконання з масиву записів, виводячи їх у текстовому форматі.
+formatDurationMs перетворює тривалість у мілісекундах у рядок формату `<ціла>.<десята>s`.
+formatTimingSummary генерує багаторядковий текст таблиці-резюме часу виконання на основі наданого заголовка та списку записів про час.
 
 ## Публічний API
 
-- formatDurationMs — Форматує значення тривалості в форматі `<сек>.<десята>с`. Округлення виконується вниз (floor), щоб забезпечити консистентність результатів незалежно від платформи.
-- formatTimingSummary — Створює багаторядковий текст у форматі таблиці-резюме для виведення в консоль (stdout).
+⏱ formatDurationMs: Перетворює мілісекунди на формат `<sec>.<десята>s`, використовуючи округлення вниз.
+⏱ formatTimingSummary: Генерує багаторядковий вивід у форматі таблиці-резюме для стандартного виводу.
 
 ## Гарантії поведінки
 
-❌ Якщо `ok` дорівнює `false`, повертає `null`.
-❌ Якщо час виконання перевищує 5 секунд, повертає `null`.
-Повертає рядок, що містить таблицю з часом виконання.
-Час виконання виражається у форматі `<ціла>.<десята>s`.
-Повертає рядок з символом `\n` в кінці.
-Не використовує кешування.
+- Read-only: не виконує операцій запису (ФС/БД).

package/scripts/lib/docs/worktree-notice.md

@@ -6,11 +6,8 @@ docgen:
   crc: 1f7d5e0d
   model: omlx/gemma-4-e4b-it-OptiQ-4bit
   score: 100
-  judgeModel: openai-codex/gpt-5.4-mini
 ---
 
-## Огляд
-
 Цей файл вшиває worktree-інструкцію у синкнутий `SKILL.md` (рішення D2 зі spec). Коли `meta.json.worktree === true`, скіл вставляє/замінює ідемпотентний ре-синкнутий блок, що містить маркери WORKTREE_START та WORKTREE_END, забезпечуючи виконання скілу в окремому git-worktree та запобігаючи паралелізації. Функція `injectWorktreeNotice` керує наявністю або відсутністю цього блоку в `SKILL.md` на основі конфігурації.
 
 ## Поведінка

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

@@ -14,5 +14,6 @@ resource: npm/scripts/lib/fix/
 | [llm-lint-fix.mjs](llm-lint-fix.md) | JS Module |
 | [llm-worker.mjs](llm-worker.md) | JS Module |
 | [orchestrator.mjs](orchestrator.md) | JS Module |
+| [run-conformance-check.mjs](run-conformance-check.md) | JS Module |
 | [run-fix-check.mjs](run-fix-check.md) | JS Module |
 | [t0.mjs](t0.md) | JS Module |

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

@@ -3,34 +3,39 @@ type: JS Module
 title: orchestrator.mjs
 resource: npm/scripts/lib/fix/orchestrator.mjs
 docgen:
-  crc: d327ab6d
+  crc: fbc91330
   model: omlx/gemma-4-e4b-it-OptiQ-4bit
   score: 100
 ---
 
-Модуль керує процесом валідації та виправлення конформності правил. Він перевіряє правила, застосовує детермінований механізм (T0), а нерозв'язані порушення проводить по **драбині ескалації моделей**: локальна min-модель → той самий локальний тир із feedback → хмарна min → хмарна avg. Кожен крок драбини логується для подальшого аналізу. Функція `runOrchestratorCli` запускає процес.
+## Огляд
+
+Модуль керує процесом вирішення порушень за допомогою багаторівневої системи ескалації. Він збирає послідовність рівнів моделей, починаючи з локальних і закінчуючи хмарними. Модуль парсить параметри запуску за допомогою `parseOrchestratorArgs` та виконує повний цикл фіксації, застосовуючи детермінований фікс. Для невирішених проблем застосовується ескалація правил через `escalateRule`, а фінальний запуск оркестратора здійснюється через `runOrchestratorCli`, який використовує структуру, побудовану за допомогою `buildLadder`.
 
 ## Поведінка
 
-1. `runOrchestratorCli` виконує початкову перевірку правил. Якщо порушень немає — успіх.
-2. Один прохід детермінованого фіксу (T0) зменшує набір порушень без LLM.
-3. `buildLadder` будує драбину з доступних тирів (`N_LOCAL_MIN_MODEL`, `N_CLOUD_MIN_MODEL`, `N_CLOUD_AVG_MODEL`); незадані тири відсіюються. Якщо драбина порожня — процес завершується з ознакою нерозв'язаних порушень.
-4. `escalateRule` проводить кожне правило по драбині до першого зеленого re-check:
-   - рунг `local-min` — перший прохід без feedback;
-   - рунг `local-min-retry` — той самий локальний тир, але з feedback попереднього рунга (попередні зміни + залишковий violation);
-   - рунги `cloud-min` / `cloud-avg` — хмарні моделі (через pi), теж із feedback.
-   Кожен рунг має per-tier `timeoutMs`: локальні **fail-fast** (`N_LOCAL_FIX_TIMEOUT_MS`, дефолт 45s — не палити стіну 120s на повільному локальному inference), хмарні — повний (`N_CLOUD_FIX_TIMEOUT_MS`, дефолт 120s).
-5. Достроковий вихід драбини: systemic-помилка локального тиру пропускає рунги тієї ж моделі; відсутній API-ключ на хмарному обриває драбину; хмарний транспортний збій (pi таймаут/spawn) обриває драбину, щоб не палити avg-бюджет на ту саму стіну; вичерпаний avg-кеп пропускає avg-рунг (із записом у лог).
-6. Після обробки всіх правил — фінальна перевірка. Усі чисті → успіх; інакше — ознака нерозв'язаних.
+buildLadder будує послідовність тирів ескалації для вирішення порушень, від локальних мінімальних моделей до хмарних середніх моделей.
+escalateRule проводить один прохід по послідовності тирів, намагаючись вирішити порушення, і повертає статус вирішення та використаний бюджет хмарних викликів.
+parseOrchestratorArgs парсить аргументи командного рядка для визначення максимального бюджету хмарних викликів та фільтра правил.
+runOrchestratorCli виконує повний цикл фіксації: перевіряє правила, застосовує детермінований фікс (T0-auto), а потім використовує LLM-драбину ескалації для невирішених порушень.
 
 ## Публічний API
 
-- `buildLadder({ localMin, cloudMin, cloudAvg })` — будує драбину рунгів із наявних тирів.
-- `escalateRule(rule, cwd, deps)` — проводить одне правило по драбині; повертає `{ resolved, avgUsed }`. Залежності (`worker`, `check`, `clock`) інжектовні для тестів.
-- `parseOrchestratorArgs(args)` — парсить `--max-avg N` (кеп на хмарні avg-виклики) і фільтр правил.
-- `runOrchestratorCli(args, cwd)` — точка входу; повертає `0` (усе чисто) або `1` (нерозв'язані).
+buildLadder — Створює послідовність моделей для ескалації, виходячи з доступних рівнів.
+
+local-min — Запускає первинний прохід з найменшою локальною моделлю.
+local-min-retry — Повторює локальний прохід, використовуючи відгук від попереднього кроку.
+cloud-min — Запускає прохід з найменшою хмарною моделлю, використовуючи відгук.
+cloud-avg — Запускає прохід з середньою хмарною моделлю, використовуючи відгук та обмеження середнього.
+
+escalateRule — Виконує одне правило по драбині ескалації до першого успішного перевірки.
+Кожен рунг — Запускає роботу моделі з урахуванням попереднього відгуку, перевіряє правило, фіксує результат у лозі.
+Достроковий вихід — Зупиняє процес при певних умовах (відсутність ключа, пропуск моделі на системному рівні) або при досягненні ліміту середнього.
+
+parseOrchestratorArgs — Витягує максимальне значення середнього та збирає список правил для фільтрації з командного рядка.
+
+runOrchestratorCli — Запускає основний процес оркестрації, обробляючи аргументи та виконуючи ескалацію правил.
 
 ## Гарантії поведінки
 
-- Кожен рунг драбини дописується в escalation-лог (`escalation-log.mjs`): модель, чи виклик удався, чи правило стало зеленим, залишковий violation і само-аналіз моделі.
-- Звертається до мережі лише на хмарних рунгах драбини (через pi).
+- Read-only: не виконує операцій запису (ФС/БД).

package/scripts/lib/fix/docs/run-conformance-check.md

@@ -0,0 +1,32 @@
+---
+type: JS Module
+title: run-conformance-check.mjs
+resource: npm/scripts/lib/fix/run-conformance-check.mjs
+docgen:
+  crc: 7a026c26
+  model: omlx/gemma-4-e4b-it-OptiQ-4bit
+  score: 90
+---
+
+## Огляд
+
+Модуль реалізує прямий механізм виконання конформності, викликаючи конформність-фазу `lint`, движок (`orchestrator.mjs`, `t0.mjs`) та PostToolUse-хук. Селекція активних правил здійснюється на основі конфігурації `.n-cursor.json`. Для забезпечення ізоляції, кожен обраний `entrypoint rules/<id>/main.mjs` запускається окремим процесом `bun`.
+
+## Поведінка
+
+resolveCheckRuleIds визначає набір ID правил для прогону, використовуючи `.n-cursor.json` як єдине джерело правди для селекції. Якщо запитані правила надані, вони фільтруються за активністю; інакше, він вибирає активні правила з конфігурації, або, за відсутності конфігурації, використовує зматеріалізовані файли `.cursor/rules/*.mdc` для режиму відладки.
+
+runConformanceCheck виконує перевірку конформності для кожного правила, яке було визначено як активне. Він запускає кожен `check.mjs` окремим процесом `bun` для ізоляції та повертає загальну кількість виконаних, успішних та невдалих перевірок.
+
+## Публічний API
+
+resolveCheckRuleIds — Визначає, які правила будуть застосовані для перевірки, використовуючи `.n-cursor.json` як основне джерело:
+*   Якщо вказані правила, вони фільтруються до активних у конфігурації.
+*   Якщо правила не вказані, беруться всі активні правила з конфігу.
+*   Якщо правила не вказані і конфіг відсутній, використовується список правил, що були збережені локально.
+
+runConformanceCheck — Виконує перевірку відповідності для кожного окремого правила без внесення змін.
+
+## Гарантії поведінки
+
+- Read-only: не виконує операцій запису (ФС/БД).

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: 524d91e2
+  crc: 49c0669b
   model: omlx/gemma-4-e4b-it-OptiQ-4bit
   score: 100
 ---
 
-Модуль керує детермінованим (без LLM) застосуванням паттернів до виводів порушень конформності. Паттерни: `vscode-ext-add` (дописати розширення), `rm-forbidden-file` (видалити заборонений файл), `changelog-create-change-file` (створити change-файл через канонічну `writeChange` для воркспейсів із «немає change-файлу» — прибирає ескалацію в LLM на цьому кейсі). `filterT0AutoRules` визначає, які правила мають придатний паттерн; `applyT0Auto`/`runT0AutoCli` застосовують. Паттерн може бути sync або async (await нормалізує). Fail-safe: помилки перехоплюються.
+## Огляд
+
+Модуль керує автоматичним застосуванням T0-auto паттернів до виводів порушень. Він визначає, які правила можуть бути оброблені автоматично, використовуючи конфігурації з `extensions.json` та `package-lock.json`. Функціонал реалізовано через публічні функції: `filterT0AutoRules` для визначення правил, `applyT0Auto` для автоматичного застосування паттернів до виводів, та `runT0AutoCli` для запуску процесу. Модуль працює у режимі fail-safe, перехоплюючи помилки та не кидаючи винятків назовні, надаючи звіт про застосовані автоматичні виправлення.
 
 ## Поведінка
 
-applyT0Auto застосовує придатні паттерни до одного виводу порушення (await на apply — паттерн може бути async, як `changelog-create-change-file`).
-filterT0AutoRules повертає id правил, для яких існує придатний паттерн.
-runT0AutoCli запускає T0-auto для всіх провальних правил, повторно перевіряє check-gate і виводить підсумок.
+applyT0Auto застосовує всі визначені T0-auto паттерни до одного виводу порушення, повертаючи результат застосування.
+filterT0AutoRules повертає список ID правил, для яких існує хоча б один T0-auto паттерн, виходячи з виводів порушень.
+runT0AutoCli запускає T0-auto для кожного провального правила, повторно перевіряє конформність та виводить підсумок.
 
 ## Публічний API
 
-applyT0Auto — Впроваджує всі шаблони T0-auto до одного результату виявлених проблем.
-filterT0AutoRules — Визначає, які правила мають хоча б один шаблон T0-auto, виходячи з результату `fix --json`.
-runT0AutoCli — Запускає команду `n-cursor fix-t0 [rule...]`, виконує `fix --json`, застосовує T0-auto до кожної проблеми, повторно перевіряє check-gate та надає звіт.
+applyT0Auto — вносить зміни до виводу порушень, використовуючи всі визначені T0-auto шаблони.
+filterT0AutoRules — визначає, які правила мають принаймні один T0-auto шаблон, ґрунтуючись на виводі порушень у форматі JSON.
+runT0AutoCli — виконує команду `n-cursor fix-t0 [rule...]`, яка застосовує T0-auto до кожного порушення, повторно перевіряє check-gate та надає звіт.
 
 ## Гарантії поведінки
 
 - Перехоплює помилки і не пропускає винятків назовні (fail-safe).
-- Не звертається до мережі.

package/scripts/lib/fix/orchestrator.mjs

@@ -1,7 +1,7 @@
 /** @see ./docs/orchestrator.md */
 
 import { env } from 'node:process'
-import { runFixCheck } from './run-fix-check.mjs'
+import { runConformanceCheck } from './run-conformance-check.mjs'
 import { runT0AutoCli } from './t0.mjs'
 import { logEscalation } from './escalation-log.mjs'
 import { runLlmWorker } from './llm-worker.mjs'
@@ -165,7 +165,7 @@ export function parseOrchestratorArgs(args) {
 async function runT0Step(cwd, ruleFilter, failed) {
   await runT0AutoCli([...ruleFilter], cwd)
 
-  const afterT0 = await runFixCheck(ruleFilter, cwd)
+  const afterT0 = await runConformanceCheck(ruleFilter, cwd)
   const failedAfterT0 = afterT0.rules.filter(r => !r.ok)
   const t0Fixed = failed.filter(r => !failedAfterT0.some(f => f.ruleId === r.ruleId))
 
@@ -186,7 +186,7 @@ export async function runOrchestratorCli(args, cwd) {
   const ladder = buildLadder({ localMin: LOCAL_MIN, cloudMin: CLOUD_MIN, cloudAvg: CLOUD_AVG })
 
   // ── Перша перевірка (тихо) ──
-  const initial = await runFixCheck(ruleFilter, cwd)
+  const initial = await runConformanceCheck(ruleFilter, cwd)
   let failed = initial.rules.filter(r => !r.ok)
   const total = initial.total
 
@@ -220,14 +220,14 @@ export async function runOrchestratorCli(args, cwd) {
     const { avgUsed } = await escalateRule(rule, cwd, {
       ladder,
       worker,
-      check: runFixCheck,
+      check: runConformanceCheck,
       avgBudget
     })
     avgBudget -= avgUsed
   }
 
   // ── Фінальна перевірка ──
-  const finalCheck = await runFixCheck(ruleFilter, cwd)
+  const finalCheck = await runConformanceCheck(ruleFilter, cwd)
   const stillFailed = finalCheck.rules.filter(r => !r.ok)
   if (stillFailed.length === 0) {
     console.log(`✅ fix: ${total} правил — все чисто`)

package/scripts/lib/fix/{run-fix-check.mjs → run-conformance-check.mjs}

@@ -1,11 +1,11 @@
 /**
- * Конформність-детект (колишній subcommand `_fix-check`) як ПРЯМА функція — без subprocess-обгортки
- * `bun n-cursor.js _fix-check`. Викликають конформність-фаза `lint` (read-only), движок
- * (`orchestrator.mjs`, `t0.mjs`) і PostToolUse-хук.
+ * Конформність-детект як ПРЯМА функція — без subprocess-обгортки.
+ * Викликають конформність-фаза `lint` (read-only), движок (`orchestrator.mjs`, `t0.mjs`)
+ * і PostToolUse-хук.
  *
- * Per-rule ізоляція зберігається: кожне `rules/<id>/fix.mjs` усе ще запускається окремим
- * процесом `bun` (crash-isolation). Прибрано лише зовнішній wrapper-subprocess, що його
- * раніше шелили оркестратор/хук.
+ * Per-rule ізоляція зберігається: entrypoint `rules/<id>/main.mjs` кожного правила
+ * запускається окремим процесом `bun` (crash-isolation). Канон — єдиний `main.mjs`
+ * (ADR 2026-06-21); його CLI-блок кличе `runRuleCli(import.meta.dirname)`.
  *
  * Селекція активних правил — виключно тут (`resolveCheckRuleIds` за `.n-cursor.json`);
  * per-rule whitelist у спавнених процесах прибрано як дубль (див. `runRuleCli`).
@@ -21,7 +21,7 @@ import { discoverCheckRulesFromCursorRules } from '../discover-check-rules-from-
 import { listProjectRulesMdcFiles } from '../list-project-rules-mdc.mjs'
 import { isRuleEnabled, readNCursorConfigLite } from '../read-n-cursor-config-lite.mjs'
 
-// Цей файл: npm/scripts/lib/fix/run-fix-check.mjs → npm/rules (чотири dirname угору + rules).
+// Цей файл: npm/scripts/lib/fix/run-conformance-check.mjs → npm/rules (чотири dirname угору + rules).
 const BUNDLED_RULES_DIR = join(dirname(dirname(dirname(dirname(fileURLToPath(import.meta.url))))), 'rules')
 
 /**
@@ -61,16 +61,16 @@ export async function resolveCheckRuleIds(requestedRules, available, cwd) {
 }
 
 /**
- * Прогоняє `fix.mjs` кожного правила окремим процесом, захоплюючи output.
+ * Прогоняє check-entrypoint кожного правила окремим процесом, захоплюючи output.
  * @param {string[]} idsToRun правила
  * @param {string} cwd корінь
  * @returns {{ totalFailed:number, rules:Array<{ruleId:string, ok:boolean, output:string}> }} результат
  */
-function runRuleFixProcesses(idsToRun, cwd) {
+function runRuleCheckProcesses(idsToRun, cwd) {
   let totalFailed = 0
   const rules = []
   for (const id of idsToRun) {
-    const r = spawnSync('bun', [join(BUNDLED_RULES_DIR, id, 'fix.mjs')], { cwd, encoding: 'utf8' })
+    const r = spawnSync('bun', [join(BUNDLED_RULES_DIR, id, 'main.mjs')], { cwd, encoding: 'utf8' })
     const ok = r.status === 0
     rules.push({ ruleId: id, ok, output: `${r.stdout ?? ''}${r.stderr ?? ''}`.trim() })
     if (!ok) totalFailed++
@@ -79,12 +79,12 @@ function runRuleFixProcesses(idsToRun, cwd) {
 }
 
 /**
- * Конформність-детект: per-rule `fix.mjs run()` (= перевірка, без мутацій).
+ * Конформність-детект: per-rule `check.mjs run()` (= перевірка, без мутацій).
  * @param {string[]} [requestedRules] фільтр (порожній → discovery з `.cursor/rules/`)
  * @param {string} [cwd] корінь
  * @returns {Promise<{ total:number, failed:number, rules:Array<{ruleId:string, ok:boolean, output:string}> }>} результат
  */
-export async function runFixCheck(requestedRules = [], cwd = processCwd()) {
+export async function runConformanceCheck(requestedRules = [], cwd = processCwd()) {
   ensureTool('conftest')
   const available = await listRuleIds(BUNDLED_RULES_DIR)
   if (available.length === 0) return { total: 0, failed: 0, rules: [] }
@@ -92,6 +92,6 @@ export async function runFixCheck(requestedRules = [], cwd = processCwd()) {
   const idsToRun = await resolveCheckRuleIds(requestedRules, available, cwd)
   if (idsToRun.length === 0) return { total: 0, failed: 0, rules: [] }
 
-  const { totalFailed, rules } = runRuleFixProcesses(idsToRun, cwd)
+  const { totalFailed, rules } = runRuleCheckProcesses(idsToRun, cwd)
   return { total: idsToRun.length, failed: totalFailed, rules }
 }

package/scripts/lib/fix/t0.mjs

@@ -3,7 +3,7 @@ import { spawnSync } from 'node:child_process'
 import { existsSync, readFileSync, rmSync, writeFileSync } from 'node:fs'
 import { join } from 'node:path'
 
-import { runFixCheck } from './run-fix-check.mjs'
+import { runConformanceCheck } from './run-conformance-check.mjs'
 import { writeChange } from '../../../rules/release/change.mjs'
 
 const REC_REQUIRE_RE = /recommendations має містити "[^"]+"/
@@ -188,7 +188,7 @@ export async function runT0AutoCli(args, cwd) {
   const verbose = args.includes('--verbose') || args.includes('-v')
 
   // 1. Конформність-детект (пряма функція, без subprocess)
-  const fixJson = await runFixCheck(ruleFilter, cwd)
+  const fixJson = await runConformanceCheck(ruleFilter, cwd)
   const failed = fixJson.rules.filter(r => !r.ok)
   if (failed.length === 0) {
     console.log(`✅ fix-t0: всі правила чисті — T0 не потрібен`)
@@ -210,7 +210,7 @@ export async function runT0AutoCli(args, cwd) {
   }
 
   // 4. Check-gate: перевірити лише ті правила, що ми чіпали
-  const recheckJson = await runFixCheck(applied.map(a => a.ruleId), cwd)
+  const recheckJson = await runConformanceCheck(applied.map(a => a.ruleId), cwd)
   const stillFailed = recheckJson.rules.filter(r => !r.ok)
 
   if (verbose) {

package/scripts/lib/gha-workflow.mjs

@@ -135,7 +135,7 @@ export function verifyLintJsWorkflowStructure(root) {
 }
 
 /**
- * Чи є в будь-якому `run` кроку підрядок (наприклад `bun run lint-text`).
+ * Чи є в будь-якому `run` кроку підрядок (наприклад `n-cursor lint text --read-only`).
  * @param {Record<string, unknown>} root корінь workflow
  * @param {string} needle підрядок для пошуку
  * @returns {boolean} `true`, якщо хоча б один `run` містить `needle`

package/scripts/lib/list-project-rules-mdc.mjs

@@ -1,6 +1,6 @@
 /**
  * Список `.mdc`-файлів правил у `.cursor/rules/` проєкту-споживача (відсортований).
- * Винесено зі `bin/n-cursor.js`, щоб ділити між CLI-dispatch і `run-fix-check` (конформність-детект).
+ * Винесено зі `bin/n-cursor.js`, щоб ділити між CLI-dispatch і `run-conformance-check` (конформність-детект).
  */
 import { existsSync } from 'node:fs'
 import { readdir } from 'node:fs/promises'

package/scripts/lib/list-rule-ids.mjs

@@ -1,12 +1,21 @@
 /**
- * Перебір `rules/<id>/` директорій з фільтром на наявність `fix.mjs`.
- * Після атомарної міграції `fix.mjs` обов'язковий у кожному правилі — каталог без нього
+ * Перебір `rules/<id>/` директорій з фільтром на наявність entrypoint-а.
+ * Канон (ADR 2026-06-21): єдиний entrypoint `rules/<id>/main.mjs`. Каталог без нього —
  * пропускається (це not-a-rule або заглушка).
  */
 import { existsSync } from 'node:fs'
 import { readdir } from 'node:fs/promises'
 import { join } from 'node:path'
 
+/**
+ * Чи має каталог правила entrypoint `main.mjs`.
+ * @param {string} ruleDir абсолютний шлях `rules/<id>/`
+ * @returns {boolean} true, якщо `main.mjs` існує
+ */
+function hasEntrypoint(ruleDir) {
+  return existsSync(join(ruleDir, 'main.mjs'))
+}
+
 /**
  * @param {string} bundledRulesDir абсолютний шлях до `npm/rules/`
  * @param {string} [filter] id одного правила (через `--rule abie`)
@@ -17,7 +26,7 @@ export async function listRuleIds(bundledRulesDir, filter) {
   const ids = entries
     .filter(e => e.isDirectory() && !e.name.startsWith('.'))
     .map(e => e.name)
-    .filter(id => existsSync(join(bundledRulesDir, id, 'fix.mjs')))
+    .filter(id => hasEntrypoint(join(bundledRulesDir, id)))
     .filter(id => filter === undefined || id === filter)
   return ids.toSorted((a, b) => a.localeCompare(b))
 }