npm - @nitra/cursor - Versions diffs - 12.8.0 → 12.8.1 - Mend

@nitra/cursor 12.8.0 → 12.8.1

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.

Files changed (48) hide show

package/CHANGELOG.md CHANGED Viewed

@@ -1,5 +1,11 @@
 # Changelog
+## [12.8.1] - 2026-06-22
+### Changed
+- ♻️ refactor(docs): Оновлення логіки та формату в документації
 ## [12.8.0] - 2026-06-21
 ### Added

package/package.json CHANGED Viewed

@@ -1,6 +1,6 @@
 {
   "name": "@nitra/cursor",
-  "version": "12.8.0",
+  "version": "12.8.1",
   "description": "CLI для завантаження cursor-правил (префікс n-) у локальний репозиторій",
   "keywords": [
     "cli",

package/rules/doc-files/js/docgen-scan.mjs CHANGED Viewed

@@ -115,9 +115,11 @@ export function scanOrphanedDocs(root) {
     }
   }
-  /** Обходить дерево, шукаючи docs/-директорії для orphan-перевірки.
+  /**
+   * Обходить дерево, шукаючи docs/-директорії для orphan-перевірки.
    *  docs/ — входимо завжди (батьківська пройшла ignore-перевірку);
-   *  інші — перевіряємо через isDocgenIgnored. */
+   *  інші — перевіряємо через isDocgenIgnored.
+   */
   function walk(dir) {
     let entries
     try {

package/rules/doc-files/js/docs/docgen-extract.md CHANGED Viewed

@@ -17,17 +17,17 @@ docgen:
 1. Витягує факт-лист з вмісту файлу.
 2. Визначає мову файлу за розширенням.
 3. Якщо мова — Rust, виконує аналіз Rust-коду:
-    а. Витягує модульний заголовок (`//!`).
-    б. Визначає публічні експорти (структури, функції, класи), виходячи з префіксів `pub` та атрибутів експозиції.
-    в. Визначає локальні (приватні) символи, які не є публічними.
-    г. Класифікує імпорти (`use`) як стандартні, зовнішні чи внутрішні.
-    д. Визначає поведінкові маркери (наприклад, чи є код лише для читання, чи обробляє помилки).
+   а. Витягує модульний заголовок (`//!`).
+   б. Визначає публічні експорти (структури, функції, класи), виходячи з префіксів `pub` та атрибутів експозиції.
+   в. Визначає локальні (приватні) символи, які не є публічними.
+   г. Класифікує імпорти (`use`) як стандартні, зовнішні чи внутрішні.
+   д. Визначає поведінкові маркери (наприклад, чи є код лише для читання, чи обробляє помилки).
 4. Якщо мова — JavaScript/TypeScript/MJS, виконує аналіз JS-коду:
-    а. Витягує заголовок файлу.
-    б. Визначає публічні експорти з їхнім JSDoc.
-    в. Класифікує імпорти як стандартні, npm або внутрішні.
-    г. Визначає локальні символи (службові функції).
-    д. Визначає поведінкові маркери (наприклад, чи є код лише для читання, чи звертається до мережі).
+   а. Витягує заголовок файлу.
+   б. Визначає публічні експорти з їхнім JSDoc.
+   в. Класифікує імпорти як стандартні, npm або внутрішні.
+   г. Визначає локальні символи (службові функції).
+   д. Визначає поведінкові маркери (наприклад, чи є код лише для читання, чи звертається до мережі).
 5. Усі аналізи свідомо ігнорують шляхи: `.github`, `.git`, `node_modules`, `base/`, `ua/`, `.firebase`.
 6. Повертає структуру фактів, що містить інформацію про файл.

package/rules/doc-files/js/docs/docgen-judge-measure.md CHANGED Viewed

@@ -10,21 +10,21 @@ docgen:
 ## Огляд
-Модуль обробляє файли, витягуючи їхній зміст для генерації документації. Він порівнює цю документацію з оцінками сильної модільної системи. Під час роботи відбувається кешування у межах прогону. Модуль збирає метрики якості згенерованої документації та зберігає фінальний звіт у `report.json`, який спирається на конфігурації, визначені в `report.json`.
+Файл аналізує надані файли коду, створюючи документацію та оцінюючи її якість відповідно до конфігурації, що міститься у report.json. Процес збирає результати для кожного файлу, використовуючи кешування у межах прогону на основі вмісту джерела та вже згенерованої документації. У кінці процес агрегує дані та зберігає повний звіт у report.json, а також виводить його у консоль.
 ## Поведінка
 1. Зчитує список файлів для аналізу з аргументів командного рядка.
 2. Для кожного файлу зчитує його вміст.
-3. Генерує документацію для файлу, використовуючи кеш за вмістом джерела.
-4. Якщо документація згенерована, перевіряє її якість за встановленим порогом.
-5. Якщо якість документації відповідає порогу, передає вміст джерела та згенеровану документацію для оцінки сильною моделлю.
-6. Оцінювач повертає вердикт (точний, загальний, неточний) з обґрунтуванням.
-7. Зберігає результати для кожного файлу.
-8. Агрегує результати: підраховує загальну кількість файлів, успішно згенерованих, пройшли перевірку, а також розподіл вердиктів серед тих, що пройшли перевірку.
-9. Формує звіт, який включає конфігурацію, підрахунки та відсотки помилкових спрацьовувань.
-10. Зберігає фінальний звіт у файл `report.json` у каталозі кешу.
-11. Виводить консольний звіт про результати вимірювання.
+3. Генерує документацію для файлу, використовуючи кешування за вмістом джерела.
+4. Якщо генерація документації успішна і отриманий бал перевищує встановлений поріг, переходить до етапу оцінки.
+5. Якщо бал не перевищує порогу, файл вважається "degraded" (зниженою якістю) і не підлягає подальшій оцінці.
+6. Якщо бал перевищує поріг, документація передається для оцінки потужній моделі, використовуючи кешування за вмістом джерела та згенерованою документацією.
+7. Оцінка повертає вердикт ("accurate", "generic" або "inaccurate"), впевненість та причину.
+8. Збираються результати для кожного файлу.
+9. Після обробки всіх файлів агрегуються результати: підраховуються загальні показники (кількість файлів, помилки генерації, кількість пройшлих тестів, розподіл вердиктів).
+10. Зберігається звіт у файл `report.json` у каталозі кешу.
+11. Виводиться консольний звіт про результати вимірювання.
 ## Гарантії поведінки

package/rules/doc-files/js/docs/docgen-judge.md CHANGED Viewed

@@ -3,30 +3,32 @@ type: JS Module
 title: docgen-judge.mjs
 resource: npm/rules/doc-files/js/docgen-judge.mjs
 docgen:
-  crc: c6ab093a
+  crc: fcbf72fa
   model: omlx/gemma-4-e4b-it-OptiQ-4bit
   score: 100
 ---
-Модуль оцінює згенеровану документацію, порівнюючи її з вихідним файлом за допомогою великої мовної моделі. Це дозволяє визначити відповідність та якість документації. Модуль надає функції для запуску оцінки (`judgeDoc`, `judgeFailsDoc`), отримання результатів (`parseDocVerdict`), визначення моделі (`JUDGE_MODEL`), перевірки статусу оцінювача (`JUDGE_ENABLED`) та отримання рівня впевненості (`JUDGE_CONFIDENCE`).
+## Огляд
+Модуль реалізує механізм оцінки якості документації. Він визначає модель для оцінки за допомогою `JUDGE_MODEL`, перевіряє статус активності гейту через `JUDGE_ENABLED` та встановлює поріг впевненості за допомогою `JUDGE_CONFIDENCE`. Модуль отримує, парсить та визначає фінальний статус документації, викликаючи `judgeDoc` для отримання висновків, а також може використовувати `judgeFailsDoc` для визначення провалу.
 ## Поведінка
 JUDGE_MODEL — Вказує модель, яку використовує суддя для оцінки документації.
-JUDGE_ENABLED — Позначає, чи активна функціональність судді.
-JUDGE_CONFIDENCE — Визначає мінімальний рівень впевненості, необхідний для позначення документації як деградованої.
-parseDocVerdict — Витягує та валідує об'єкт з оцінкою документації з сирого текстового виводу судді.
-judgeDoc — Виконує оцінку згенерованої документації проти вмісту вихідного файлу за допомогою великої мовної моделі.
+JUDGE_ENABLED — Позначає, чи активний семантичний гейт судді.
+JUDGE_CONFIDENCE — Визначає мінімальну впевненість, необхідну для позначення документації як деградованої.
+parseDocVerdict — Витягує та валідує об'єкт оцінки з сирого текстового виводу судді.
+judgeDoc — Зіставляє вміст вихідного файлу та згенеровану документацію, щоб отримати оцінку від судді.
 judgeFailsDoc — Визначає, чи слід вважати документацію деградованою на основі оцінки судді.
 ## Публічний API
 JUDGE_MODEL — Визначає модель-суддю як `N_CLOUD_MIN_MODEL` (хмарний мінімальний рівень).
-JUDGE_ENABLED — Автоматично вмикає механізм судді, якщо обрано `N_CLOUD_MIN_MODEL`.
-JUDGE_CONFIDENCE — Встановлює мінімальний рівень впевненості, необхідний для позначення документа як погіршеного (degraded) за неточним вердиктом.
-parseDocVerdict — Витягує та перевіряє структуру вердикту у форматі JSON із сирих даних від великої мовної моделі.
-judgeDoc — Оцінює згенерований документ потужною моделлю, порівнюючи його з вихідним джерелом.
-judgeFailsDoc — Визначає, чи повинен документ бути позначений як погіршений (degraded) на підставі вердикту, якщо він неточний і має достатню впевненість.
+JUDGE_ENABLED — Автоматично вмикає механізм суддівства, якщо обрано `N_CLOUD_MIN_MODEL`.
+JUDGE_CONFIDENCE — Встановлює мінімальний рівень впевненості для позначення документа як погіршеного (degraded) через неточність.
+parseDocVerdict — Витягує та перевіряє JSON-вердикт із відповіді великої мовної моделі.
+judgeDoc — Оцінює згенерований документ потужною моделлю порівняно з оригінальним джерелом.
+judgeFailsDoc — Визначає, чи повинен документ бути позначений як погіршений, якщо вердикт є `inaccurate` і впевненість достатня.
 ## Гарантії поведінки

package/rules/doc-files/js/docs/docgen-scan.md CHANGED Viewed

@@ -3,47 +3,48 @@ type: JS Module
 title: docgen-scan.mjs
 resource: npm/rules/doc-files/js/docgen-scan.mjs
 docgen:
-  crc: f01465d8
+  crc: 563b7722
   model: omlx/gemma-4-e4b-it-OptiQ-4bit
   score: 100
 ---
 ## Огляд
-Модуль аналізує кодову базу та пов'язану з нею документацію. Він визначає, які файли є джерелами за допомогою `isSourceFile` та знаходить відповідні шляхи документації за допомогою `docPathForSource`. Модуль перевіряє, чи не залишилися без зв'язку (сиротами) документи, використовуючи `scanOrphanedDocs`, та сканує файли документації за допомогою `scanForDocFiles`. Для роботи з кореневими каталогами використовується `resolveRoot`. Усі операції виконуються з механізмом перехоплення помилок (fail-safe), при цьому при певних збоях повертається `null` замість викидання винятків.
+Модуль визначає, які файли є кодовим джерелом за допомогою `isSourceFile`. Він обчислює відповідні шляхи до Markdown-документів для коду за допомогою `docPathForSource`. Модуль ідентифікує потенційні кандидати для документування за допомогою `isDocCandidate` та надає опис файлу за допомогою `describeFile`. Для аналізу файлової системи використовуються `scanOrphanedDocs` для пошуку "сирітських" документів та `scanForDocFiles` для сканування файлів. Модуль також може визначати кореневий каталог за допомогою `resolveRoot` та виконувати сканування файлів документації через `runDocFilesScanCli` або перевірку через `runDocFilesCheckCli`.
 ## Поведінка
 isSourceFile визначає, чи є ім'я файлу кодовим джерелом для документування.
-docPathForSource обчислює шлях до відповідного MD-документа для заданого кодового файлу.
-isDocCandidate визначає, чи підлягає певний файл документуванню, враховуючи розширення, статус тесту та ігнорування.
-describeFile описує кодовий файл, надаючи його шлях, шлях до документації та стан застарілості.
-scanOrphanedDocs знаходить MD-документи, які посилаються на кодові файли, що більше не існують.
-scanForDocFiles рекурсивно обходить дерево і повертає список кодових файлів із їхнім станом застарілості, відфільтрований за ігноруванням Git.
-resolveRoot парсить аргументи для визначення абсолютного кореня обходу, використовуючи поточну робочу директорію за замовчуванням.
+docPathForSource обчислює шлях до відповідного md-документа для заданого кодового файлу.
+isDocCandidate визначає, чи є файл кандидатом на документування, враховуючи розширення, статус тесту та ігнорування.
+describeFile описує кодовий файл, надаючи шлях джерела, шлях доки та стан застарілості.
+scanOrphanedDocs знаходить md-документи, які посилаються на джерела, що більше не існують.
+scanForDocFiles рекурсивно сканує дерево і повертає список кодових файлів зі станом застарілості, відфільтрований за ігноруванням Git.
+resolveRoot визначає абсолютний корінь обходу, використовуючи аргументи або поточний робочий каталог.
 runDocFilesScanCli сканує дерево і друкує JSON-масив усіх кодових файлів зі станом застарілості.
-runDocFilesCheckCli виконує перевірку застарілості, підтримуючи режими для перевірки одного файлу, Git-гейту або звітів про знижену якість.
+runDocFilesCheckCli виконує перевірку застарілості, що може бути використана для хуків, Git-гейтів або ручного переліку шляхів.
 ## Публічний API
-isSourceFile — визначає, чи є файл кодовим джерелом для створення документації.
-docPathForSource — визначає шлях до відповідного MD-документа, розміщений у теці `docs/` відносно коду.
-isDocCandidate — вирішує, чи повинен кодовий файл бути документований: має правильне розширення, не є тестом, не ігнорується та не є системним документом.
-describeFile — надає опис кодового файлу, включаючи його шлях, шлях до документації та статус застарілості.
-scanOrphanedDocs — шукає документи, які посилаються на кодові файли, що більше не існують, перевіряючи лише згенеровані файли.
-scanForDocFiles — рекурсивно збирає всі кодові файли з дерева, визначаючи їхній статус застарілості, і відсіюючи ті, що ігноруються через `.gitignore`.
-resolveRoot — встановлює кореневу директорію для сканування, використовуючи аргумент командного рядка або поточну робочу директорію.
-runDocFilesScanCli — сканує дерево та виводить JSON-масив усіх кодових файлів зі статусом застарілості, дозволяючи фільтрувати лише застарілі або всі файли.
-runDocFilesCheckCli — виконує перевірку застарілості для використання у хуках та командному інтерфейсі.
-Режими:
---hook — перевіряє один файл, отриманий з JSON через стандартний ввід.
---git — порівнює файли у `git diff` та блокує процес, якщо знайдено більше за встановлений поріг застарілих файлів.
---degraded — виводить звіт про документи з низьким показником якості.
-<paths…> — обробляє лише вказані шляхи-джерела.
-Вихідний код 2 — вказує на знаходження застарілих файлів (для блокування хука).
-Вихідний код 0 — вказує на відсутність застарілих файлів або проходження перевірки згідно з порогом.
+isSourceFile — визначає, чи є файл вихідним кодом для створення документації.
+docPathForSource — визначає шлях до файлу документації, розміщений у теці `docs/` відносно коду.
+isDocCandidate — вирішує, чи повинен кодовий файл бути документований (правильне розширення, не тест, не ігнорується, не системний).
+describeFile — надає опис кодового файлу, включаючи його шлях та статус застарілості.
+scanOrphanedDocs — знаходить файли документації, які посилаються на вихідний код, що більше не існує.
+scanForDocFiles — рекурсивно шукає всі кодові файли у заданому дереві та визначає їхній статус застарілості.
+resolveRoot — встановлює кореневу директорію для сканування, використовуючи аргумент командного рядка або поточну директорію.
+runDocFilesScanCli — сканує дерево та виводить JSON-масив усіх кодових файлів зі статусом застарілості.
+runDocFilesCheckCli — виконує перевірку застарілості файлів для хуків та командного інтерфейсу.
+**Режими роботи:**
+`--hook` — перевіряє один файл, отриманий із вхідного JSON, у контексті хука.
+`--git` — порівнює файли у `git diff` та блокує виконання, якщо знайдено застарілі файли, перевищуючи встановлений ліміт.
+`--degraded` — генерує звіт про файли документації, які не відповідають встановленому рівню якості.
+`<paths…>` — обробляє лише вказані явно шляхи-джерела.
+**Коди виходу:**
+Вихід 2 — вказує на знаходження застарілих файлів (для блокування хука).
+Вихід 0 — вказує на відсутність застарілих файлів або проходження перевірки згідно з лімітом.
 ## Гарантії поведінки

package/rules/doc-files/js/docs/index.md CHANGED Viewed

@@ -6,20 +6,19 @@ resource: npm/rules/doc-files/js/
 # npm/rules/doc-files/js
-| Файл                                                    | Тип       |
-| ------------------------------------------------------- | --------- |
-| [docgen-crc.mjs](docgen-crc.md)                         | JS Module |
+| Файл | Тип |
+|---|---|
+| [docgen-crc.mjs](docgen-crc.md) | JS Module |
 | [docgen-extract-anchors.mjs](docgen-extract-anchors.md) | JS Module |
-| [docgen-extract.mjs](docgen-extract.md)                 | JS Module |
-| [docgen-files-batch.mjs](docgen-files-batch.md)         | JS Module |
-| [docgen-gen.mjs](docgen-gen.md)                         | JS Module |
-| [docgen-ignore.mjs](docgen-ignore.md)                   | JS Module |
-| [docgen-judge-measure.mjs](docgen-judge-measure.md)     | JS Module |
-| [docgen-judge.mjs](docgen-judge.md)                     | JS Module |
-| [docgen-prompts.mjs](docgen-prompts.md)                 | JS Module |
-| [docgen-scan.mjs](docgen-scan.md)                       | JS Module |
-| [lint.mjs](lint.md)                                     | JS Module |
-| [run-lint.mjs](run-lint.md)                             | JS Module |
-| [units-js.mjs](units-js.md)                             | JS Module |
-| [units-rs.mjs](units-rs.md)                             | JS Module |
-| [units.mjs](units.md)                                   | JS Module |
+| [docgen-extract.mjs](docgen-extract.md) | JS Module |
+| [docgen-files-batch.mjs](docgen-files-batch.md) | JS Module |
+| [docgen-gen.mjs](docgen-gen.md) | JS Module |
+| [docgen-ignore.mjs](docgen-ignore.md) | JS Module |
+| [docgen-judge-measure.mjs](docgen-judge-measure.md) | JS Module |
+| [docgen-judge.mjs](docgen-judge.md) | JS Module |
+| [docgen-prompts.mjs](docgen-prompts.md) | JS Module |
+| [docgen-scan.mjs](docgen-scan.md) | JS Module |
+| [run-lint.mjs](run-lint.md) | JS Module |
+| [units-js.mjs](units-js.md) | JS Module |
+| [units-rs.mjs](units-rs.md) | JS Module |
+| [units.mjs](units.md) | JS Module |

package/rules/npm-module/js/docs/header_doc_pointer.md CHANGED Viewed

@@ -3,28 +3,38 @@ type: JS Module
 title: header_doc_pointer.mjs
 resource: npm/rules/npm-module/js/header_doc_pointer.mjs
 docgen:
-  crc: d96a2957
+  crc: 90fc46dc
+  model: omlx/gemma-4-e4b-it-OptiQ-4bit
   score: 100
 ---
-Файл виконує перевірку документації для модулів. Сканує директорії npm/rules та npm/skills. Перевіряє наявність файлів docs/<stem>.md у піддиректоріях правил/скілів. Перевіряє, чи містить відповідні js-файли не більше одного рядка JSDoc. У разі перевищення ліміту, генерує звіт про порушення.
+## Огляд
+Модуль валідує відповідність контракту документації для файлів `.mjs` у сегментах `npm/rules` та `npm/skills`. Він виявляє порушення, якщо для файлу `.mjs` існує відповідний файл `docs/<ім'я>.md`, а його JSDoc-блок містить більше одного непорожнього рядка.
 ## Поведінка
-1. Сканувати директорії npm/rules та npm/skills.
-2. Для кожної директорії перевіряти піддиректорії правил/скілів.
-3. Для кожного знайденого js-файлу перевіряти наявність файлу docs/<stem>.md.
-4. Якщо файл docs/<stem>.md існує, перевіряти, чи містить module-level JSDoc не більше одного непорожного рядка.
-5. У разі перевищення ліміту, зарепортувати порушення.
-6. Повертати код виходу репортера.
+1. Викликається функція check з корінням репозиторію як аргументом.
+2. Ініціалізується репортер для фіксації порушень.
+3. Для кожного з сегментів 'npm/rules' та 'npm/skills' виконується наступне:
+   а. Перевіряється існування відповідного базового сегмента.
+   б. Для кожного підсегмента (правила/скіла) у базовому сегменті:
+   i. Перевіряється існування каталогу `js/` у підсегменті.
+   ii. Для кожного файлу `.mjs` у каталозі `js/`:
+   а. Перевіряється, чи є файл звичайним вихідним файлом (не тест).
+   б. Визначається ім'я без розширення файлу.
+   в. Перевіряється існування файлу `docs/<ім'я>.md` у каталозі `js/docs/`.
+   г. Якщо файл `docs/<ім'я>.md` існує:
+   i. Зчитується вміст файлу `.mjs`.
+   ii. Визначається перша не-жадібна JSDoc-блока в файлі.
+   iii. Підраховується кількість непорожніх рядків у тілі цього JSDoc-блока.
+   iv. Якщо кількість непорожніх рядків перевищує 1, фіксується порушення, оскільки `docs/<ім'я>.md` вже описує поведінку, а JSDoc має бути лише вказівником.
+4. Повертається код виходу репортера.
 ## Публічний API
-- check — сканує файли `npm/rules/*/js/*.mjs` та `npm/skills/*/js/*.mjs`.
-  - Якщо існує `docs/<stem>.md`, модуль повинен мати посилання на JSDoc (не наратив).
-  - Якщо `docs` відсутній, обмеження не застосовуються.
+check — перевіряє файли `.mjs` у директоріях `npm/rules/*\/js/` та `npm/skills/*\/js/`. Якщо поруч є відповідний файл `docs/<stem>.md`, вимагає, щоб JSDoc на рівні модуля був посиланням (не описом); якщо `docs` відсутній, обмежень немає.
 ## Гарантії поведінки
-- Read-only: файл не виконує операцій запису у файлову систему.
-- Не звертається до мережі.
+- Read-only: не виконує операцій запису (ФС/БД).

package/rules/python/docs/main.md CHANGED Viewed

@@ -3,28 +3,28 @@ type: JS Module
 title: main.mjs
 resource: npm/rules/python/main.mjs
 docgen:
-  crc: 8ceba96a
+  crc: d8a3aa1f
   model: omlx/gemma-4-e4b-it-OptiQ-4bit
   score: 90
 ---
 ## Огляд
-Виконує логіку `lint-python` за правилом `python.mdc` для забезпечення якості коду Python. Якщо файл `pyproject.toml` відсутній у корені, виконання завершується з кодом 0. Якщо файл присутній, але `uv` не знайдено у системному шляху, це вважається помилкою, оскільки `uv` є єдиним дозволеним пакет-менеджером (без Poetry). Для роботи необхідно виконати `uv lock --check` для підтвердження актуальності файлу блокування та `uv sync --frozen` для створення середовища, що відповідає `uv.lock` (детальніше про `uv` на https://docs.astral.sh/uv/). Опціональні лінтери запускаються лише за умови їх доступності через `uv run`. Запускаються `ruff` у режимі автоматичного виправлення (`--fix`) та форматування, а також `mypy` для статичного аналізу коду, використовуючи канонічний патерн серіалізації через `runStandardLint`.
+Реалізує логіку запуску `lint-python` за правилом `python.mdc` на базі [uv](https://docs.astral.sh/uv/). Якщо `pyproject.toml` у корені відсутній, процес завершується з кодом виходу 0. Якщо файл присутній, але інструмент `uv` не знайдено в PATH, це розглядається як помилка. Обов'язкові кроки включають перевірку актуальності lock-файлу (`uv lock --check`) та синхронізацію середовища (`uv sync --frozen`). Опційні лінтери (`ruff`, `mypy`) запускаються лише за умови їх доступності через `uv run`. `ruff` виконується у режимі автоматичного виправлення (`--fix`) для мутації робочого дерева та для форматування. Цей підхід відповідає канону патерну `lint-*` (серіалізація через `runStandardLint`, без прямого `withLock`).
 ## Поведінка
-run виконує стандартну перевірку на основі контексту.
-runLintPythonSteps виконує послідовність кроків лінтування Python, включаючи перевірку `pyproject.toml`, виконання `uv lock --check` та `uv sync --frozen`, а також запуск опціональних лінтерів (`ruff`, `mypy`) через `uv run`.
-runLintPython запускає послідовність кроків лінтування Python, використовуючи механізм стандартного лінтування.
-lint оркеструє запуск `runLintPython` для аналізу всього проєкту.
+run виконує стандартну перевірку для правила, використовуючи контекст прогону.
+runLintPythonSteps виконує послідовність кроків лінтування Python, перевіряючи наявність `pyproject.toml` та виконуючи команди `uv lock --check` та `uv sync --frozen`, а також запускаючи опціональні лінтери (`ruff`, `mypy`) через `uv run` на базі https://docs.astral.sh/uv/.
+runLintPython запускає послідовність кроків лінтування Python, серіалізуючи її через стандартний механізм перевірки.
+lint делегує виклик до `runLintPython`, забезпечуючи можливість запуску в режимі, що не мутує робоче дерево.
 ## Публічний API
-run — Основна точка входу для виконання правил, що включає перевірку логіки застосування (JS-concerns → policy → mdc-refs) та виконання лінтингу.
-runLintPythonSteps — Виконує внутрішні етапи лінтингу для Python без збереження логів.
-runLintPython — Публічний інтерфейс для запуску лінтингу Python, що забезпечує унікальність виконання через блокування та аналіз стану репозиторію.
-lint — Координатор, який ініціює запуск лінтингу Python, делегуючи це `runLintPython`.
+run — Основна точка входу для виконання правил, яка перевіряє логіку застосування (JS-занепокложення $\rightarrow$ політика $\rightarrow$ mdc-посилання) та запускає перевірку коду (uv/ruff/mypy).
+runLintPythonSteps — Виконує внутрішні етапи перевірки Python-коду без збереження логу.
+runLintPython — Публічний інтерфейс для запуску перевірки Python-коду, який гарантує унікальність виконання через блокування та аналіз стану Git-дерева.
+lint — Адаптер, що керує запуском перевірки Python-коду, делегуючи цю роботу `runLintPython`.
 ## Гарантії поведінки

package/rules/rust/docs/main.md CHANGED Viewed

@@ -3,24 +3,24 @@ type: JS Module
 title: main.mjs
 resource: npm/rules/rust/main.mjs
 docgen:
-  crc: a3060168
+  crc: 93c44fd7
   model: omlx/gemma-4-e4b-it-OptiQ-4bit
-  score: 90
+  score: 100
 ---
 ## Огляд
-Модуль надає функції для роботи з кодом Rust. Функція `run` виконує повний аналіз коду, включаючи перевірку відповідності політиці MDC. Функція `lint` здійснює статичний аналіз коду. Обидві функції можуть ініціювати форматування та аналіз за допомогою `cargo`.
+Модуль надає інструменти для забезпечення якості коду Rust. Він дозволяє виконати перевірку коду на відповідність заданим Lint-правилам або запустити повну оркестрацію форматування та аналізу коду через `cargo`. Функціонал реалізується через публічні функції `run` та `lint`.
 ## Поведінка
-run виконує перевірку коду Rust, застосовуючи політику та посилання MDC.
-lint запускає оркестрацію перевірки Rust, виконуючи `rustfmt` та `clippy` через `cargo`.
+run виконує перевірку коду Rust відповідно до політик.
+lint запускає оркестрацію перевірки коду Rust, використовуючи `cargo` для виконання `rustfmt` та `clippy`.
 ## Публічний API
-run — точка входу для виконання правила, що перевіряє логіку, пов'язану з JS-зацікавленостями, політикою та посиланнями MDC.
-lint — точка входу для запуску лінтера Rust-коду.
+run — виконує основну логіку правила, включаючи перевірку аспектів застосування, логіки та посилань.
+lint — забезпечує точку входу для статичного аналізу коду Rust.
 ## Гарантії поведінки

package/rules/text/docs/main.md CHANGED Viewed

@@ -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 CHANGED Viewed

@@ -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 CHANGED Viewed

@@ -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/run-lint.md CHANGED Viewed

@@ -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 CHANGED Viewed

@@ -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 CHANGED Viewed

@@ -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 CHANGED Viewed

@@ -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 та виведення результату.
 ## Гарантії поведінки