@nitra/cursor 12.9.0 → 12.11.0

package/rules/style/main.mdc

@@ -5,26 +5,4 @@ globs: "**/*.{css,scss,vue}"
 alwaysApply: false
 ---
 
-Правило **style** для Vue-проєктів: Quasar як стильова система, SCSS-конвенції кольорів і відступів, фікси компонентів, stylelint через `@nitra/stylelint-config`.
-
-[style-quasar](./js/quasar.mdc)
-
-[style-colors](./js/colors.mdc)
-
-[style-gap](./js/gap.mdc)
-
-[style-quasar-fixes](./js/quasar-fixes.mdc)
-
-[style-tooling](./js/tooling.mdc)
-
-[style-admin-table](./js/admin-table.mdc)
-
-## Швидкий gate через conftest (Rego)
-
-[style-lint_style_yml](./policy/lint_style_yml/lint_style_yml.mdc)
-
-[style-package_json](./policy/package_json/package_json.mdc)
-
-[style-vscode_extensions](./policy/vscode_extensions/vscode_extensions.mdc)
-
-[style-vscode_settings](./policy/vscode_settings/vscode_settings.mdc)
+Правило **style** для Vue-проєктів: Quasar як стильова система, SCSS-конвенції кольорів і відступів, фікси компонентів, stylelint через `@nitra/stylelint-config`.

package/rules/tauri/docs/main.md

@@ -8,8 +8,6 @@ docgen:
   score: 100
 ---
 
-## Огляд
-
 Модуль обробляє JS-запити та взаємодіє з MDC для отримання даних. При запуску через публічну функцію `run` він оркеструє застосування правил, завантажуючи конфігурації з meta.json, застосовуючи білий список та надаючи підсумок. Модуль є read-only і не здійснює записів у ФС/БД.
 
 ## Поведінка

package/rules/tauri/main.mdc

@@ -5,14 +5,4 @@ alwaysApply: false
 version: '1.5'
 ---
 
-Правило встановлює канонічні вимоги для Tauri-проєктів: виявлення маркерів у монорепо, VS Code-розширення, налаштування mutation-testing для platform bridge та реалізацію Tool Surface поверх Tauri+Rust.
-
-## Швидкий gate через conftest
-
-[tauri-vscode_extensions](./policy/vscode_extensions/vscode_extensions.mdc)
-
-[tauri-tooling](./js/tooling.mdc)
-
-[tauri-cargo_mutants_config](./js/cargo_mutants_config.mdc)
-
-[tauri-tool_surface](./js/tool_surface.mdc)
+Правило встановлює канонічні вимоги для Tauri-проєктів: виявлення маркерів у монорепо, VS Code-розширення, налаштування mutation-testing для platform bridge та реалізацію Tool Surface поверх Tauri+Rust.

package/rules/test/docs/main.md

@@ -8,8 +8,6 @@ docgen:
   score: 100
 ---
 
-## Огляд
-
 Модуль виконує перевірку, обробляючи JS-запитання, політику та посилання на mdc. При запуску як окрема програма, він зчитує конфігурації з meta.json, застосовує білий список та підсумовує результати після застосування білого списку, визначаючи код виходу процесу. Функція run ініціює цей процес. Модуль є read-only і не пише у ФС/БД. Кешування відбувається у межах прогону.
 
 ## Поведінка

package/rules/test/js/docs/no-console-store-restore.md

@@ -8,8 +8,6 @@ docgen:
   score: 100
 ---
 
-## Огляд
-
 Модуль сканує репозиторій для пошуку файлів, що відповідають шаблону `*.test.{mjs,js}`. Він перевіряє вміст кожного такого файлу на наявність прямих присвоєнь методів консолі. Публічна функція `check` виявляє такі присвоєння. (test.mdc)
 
 ## Поведінка

package/rules/test/js/docs/sandbox-aware-test.md

@@ -8,8 +8,6 @@ docgen:
   score: 100
 ---
 
-## Огляд
-
 Модуль сканує тестові файли, що відповідають шаблону `*.test.{mjs,js}` у вказаному корені репозиторію. Він перевіряє, чи файли, що містять глибоку навігацію (визначену як використання `import.meta.dirname` або `import.meta.url` з чотирма або більше рівнями `..`), захищені викликом `withTmpDir` або `test.skipIf` з посиланням на змінну середовища `env.STRYKER_MUTATOR_WORKER`. Перевірка фіксує порушення (test.mdc) у разі відсутності необхідної ізоляції для тестових файлів з глибокою навігацією.
 
 ## Поведінка

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

@@ -8,8 +8,6 @@ docgen:
   score: 100
 ---
 
-## Огляд
-
 Модуль перевіряє готовність JavaScript-проєктів до виконання тестів. Він збирає кореневі каталоги проєктів, використовуючи публічну функцію `check` для валідації. Перевірка гарантує наявність необхідних конфігураційних файлів, зокрема `mutation.json` та `package.json`, у кожному знайденому проєкті. Модуль свідомо пропускає каталоги `node_modules`. Він також додає відповідні артефакти тестів до `.gitignore` у коренях проєктів. (test.mdc)
 
 ## Поведінка

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

@@ -8,8 +8,6 @@ docgen:
   score: 100
 ---
 
-## Огляд
-
 Визначає шлях до конфігураційного файлу Vitest. Перевіряє, чи встановлено в цьому файлі `pool: 'forks'`. (test.mdc)
 
 Поведінка:

package/rules/test/main.mdc

@@ -7,22 +7,6 @@ alwaysApply: false
 
 Правило **test** керує розміщенням тестових файлів, безпекою ізоляції тестів (заборона `process.chdir`, відносних шляхів у FS, ручного store/restore console), налаштуванням Vitest/Stryker baseline та конфігурацією cargo-mutants для Rust.
 
-[test-location](./js/location.mdc)
-
-[test-no-process-chdir](./js/no-process-chdir.mdc)
-
-[test-no-relative-fs-path](./js/no-relative-fs-path.mdc)
-
-[test-no-console-store-restore](./js/no-console-store-restore.mdc)
-
-[test-sandbox-aware-test](./js/sandbox-aware-test.mdc)
-
-[test-vitest-config-pool-forks](./js/vitest-config-pool-forks.mdc)
-
-[test-stryker-config](./js/stryker_config.mdc)
-
-[test-cargo-mutants-config](./js/cargo_mutants_config.mdc)
-
 ## Покриття + мутаційне тестування
 
 Канонічна команда — `n-cursor coverage`: збирає метрики покриття (`vitest run --coverage`, `cargo llvm-cov` тощо) і мутаційного тестування (Stryker з vitest-runner + `coverageAnalysis: 'perTest'`, `cargo-mutants`) з усіх активних провайдерів у `.n-cursor.json#rules` і пише `COVERAGE.md` у корінь проєкту.
@@ -35,8 +19,4 @@ alwaysApply: false
 
 ### Multi-workspace iteration
 
-У monorepo `n-cursor coverage` ітерує усі workspaces з власним `package.json` і агрегує метрики lcov + Stryker у єдиний `JS`-рядок `COVERAGE.md`. Workspace без тестів пропускається без помилки.
-
-## Швидкий gate через conftest
-
-[test-package_json](./policy/package_json/package_json.mdc)
+У monorepo `n-cursor coverage` ітерує усі workspaces з власним `package.json` і агрегує метрики lcov + Stryker у єдиний `JS`-рядок `COVERAGE.md`. Workspace без тестів пропускається без помилки.

package/rules/text/docs/main.md

@@ -8,8 +8,6 @@ docgen:
   score: 90
 ---
 
-## Огляд
-
 Цей модуль є 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.
 
 ## Поведінка

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

@@ -8,8 +8,6 @@ docgen:
   score: 100
 ---
 
-## Огляд
-
 Модуль інтегрує 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 поверне ненульовий код, якщо нерозкласифіковані або потенційні одруки залишилися.
 
 ## Поведінка

package/rules/text/js/docs/run-dotenv-linter.md

@@ -8,8 +8,6 @@ docgen:
   score: 100
 ---
 
-## Огляд
-
 Модуль запускає `dotenv-linter` для валідації конфігураційних файлів `.env*` відповідно до стандартів (наприклад, `LowercaseKey`). Процес включає два етапи: спочатку автоматичне виправлення порушень за допомогою `dotenv-linter fix`, а потім фінальну перевірку за допомогою `dotenv-linter check`. Інструмент очікується у системному PATH і не включається у залежності проєкту. Він рекурсивно шукає файли, виключаючи `node_modules` та `.envrc`. Якщо `dotenv-linter` відсутній, виводиться інструкція щодо його встановлення (наприклад, `brew install dotenv-linter`) та повертається код помилки. Усі деталі роботи можна знайти за посиланням https://git.io/JLbXn.
 
 ## Поведінка

package/rules/text/js/docs/run-shellcheck.md

@@ -8,8 +8,6 @@ docgen:
   score: 100
 ---
 
-## Огляд
-
 Скрипт забезпечує відповідність shell-скриптів стандартам, виконуючи дві послідовні дії: спочатку застосовує автоматичні виправлення для проблем, виявлених `shellcheck` за допомогою формату виводу `diff` та команди `patch -p1` у корені проєкту; потім проводить фінальну перевірку всіх зібраних файлів. Скрипт збирає всі відстежувані shell-скрипти у робочому дереві, ігноруючи директорії `node_modules`. Якщо скриптів не знайдено, процес завершується з кодом 0. Якщо `shellcheck` або `patch` відсутні у PATH, скрипт завершується з кодом 1, надаючи підказки для їх встановлення. Після циклу автовиправлень будь-яке попередження чи помилка від `shellcheck` призводить до ненульового коду виходу.
 
 ## Поведінка

package/rules/text/js/docs/run-v8r.md

@@ -8,8 +8,6 @@ docgen:
   score: 100
 ---
 
-## Огляд
-
 Скрипт виконує єдиний виклик `v8r` для перевірки відповідності всіх файлів, які підтримує `v8r` (json, json5, yaml, yml, toml), визначеним контрактам. Це замінює необхідність у кількох окремих викликах `v8r`. Скрипт автоматично використовує каталог схем `@nitra/cursor`, який визначається у `v8r-catalog.json`. Якщо не надано додаткових аргументів, він шукає файли за типовими шаблонами у дереві проєкту. Механізм гарантує, що перевірка всіх розширень відбувається, навіть якщо один із глобів не знаходить файлів, оскільки він обходить проблему падіння `v8r` з кодом 98.
 
 ## Поведінка

package/rules/text/main.mdc

@@ -6,40 +6,7 @@ version: '1.30'
 
 Правило охоплює весь текстовий стек проєкту: форматування (oxfmt), перевірку правопису (cspell), shell-скрипти (shellcheck), `.env`-файли (dotenv-linter), Markdown (markdownlint-cli2), JSON/YAML/TOML-схеми (v8r) та CI-workflow.
 
-[text-vscode](./js/vscode.mdc)
-
-[text-oxfmt](./js/oxfmt.mdc)
-
-[text-forbidden-prettier](./js/forbidden-prettier.mdc)
-
-[text-cspell](./js/cspell.mdc)
-
-[text-markdownlint](./js/markdownlint.mdc)
-
-[text-shellcheck](./js/shellcheck.mdc)
-
-[text-dotenv-linter](./js/dotenv-linter.mdc)
-
-[text-v8r](./js/v8r.mdc)
-
-[text-package-json](./js/package-json.mdc)
-
-[text-ci-lint-text](./js/ci-lint-text.mdc)
-
 ## Швидкий gate через conftest
 
 Rego-пакети, що перевіряються через conftest (auto-discovered за `target.json` поряд із `.rego`):
 
-[text-policy-cspell](./policy/cspell/cspell.mdc)
-
-[text-policy-lint_text](./policy/lint_text/lint_text.mdc)
-
-[text-policy-markdownlint](./policy/markdownlint/markdownlint.mdc)
-
-[text-policy-oxfmtrc](./policy/oxfmtrc/oxfmtrc.mdc)
-
-[text-policy-package_json](./policy/package_json/package_json.mdc)
-
-[text-policy-vscode_extensions](./policy/vscode_extensions/vscode_extensions.mdc)
-
-[text-policy-vscode_settings](./policy/vscode_settings/vscode_settings.mdc)

package/rules/tool-surface/docs/main.md

@@ -8,8 +8,6 @@ docgen:
   score: 100
 ---
 
-## Огляд
-
 Модуль виконує валідацію контенту, застосовуючи правила, визначені в конфігурації, що зчитується з meta.json. Він обробляє запити, пов'язані з JavaScript, та взаємодіє з MDC. При запуску як CLI, він ініціалізує та виконує повний цикл перевірки, надаючи фінальний звіт.
 
 ## Поведінка

package/rules/vue/docs/main.md

@@ -8,8 +8,6 @@ docgen:
   score: 100
 ---
 
-## Огляд
-
 Модуль виконує перевірку, застосовуючи політику та обробляючи логіку JavaScript. Він забезпечує повний запуск правила, завантажуючи конфігурації, такі як meta.json, застосовуючи білі списки та підбиваючи підсумки. При запуску як окрема утиліта командного рядка, виконується повний цикл перевірки через публічну функцію run. Модуль є Read-only і кешує дані у межах прогону.
 
 ## Поведінка

package/rules/vue/js/docs/packages.md

@@ -3,33 +3,28 @@ type: JS Module
 title: packages.mjs
 resource: npm/rules/vue/js/packages.mjs
 docgen:
-  crc: 6119ae9c
-  score: 85
+  crc: 8589151d
+  model: omlx/gemma-4-e4b-it-OptiQ-4bit
+  score: 100
 ---
 
-isVueComponentLibraryPkg
-Перевіряє, чи є пакет бібліотекою компонентів Vue шляхом перевірки `peerDependencies`.
+## Огляд
 
-check
-Перевіряє залежності та конфігурацію vite.config одного Vue-пакета.
+Модуль визначає, чи є пакет бібліотекою компонентів Vue, виходячи з даних у `package.json`, `jsconfig.json`, `package-lock.json`, `extensions.json`. Він також перевіряє відповідність усіх пакетів, що залежать від `vue`, критеріям, описаним у `vue.mdc`, і повертає код виходу.
 
 ## Поведінка
 
-isVueComponentLibraryPkg
-Визначає, чи є пакет бібліотекою компонентів Vue через peerDependencies
-
-check
-Перевіряє залежності та vite.config одного Vue-пакета
+isVueComponentLibraryPkg визначає, чи є пакет бібліотекою компонентів Vue, перевіряючи наявність `vue` у `peerDependencies` його `package.json`.
+check перевіряє відповідність проєкту правилам vue.mdc для всіх пакетів, що містять `vue` у `dependencies`, і повертає код виходу. При цьому ігноруються шляхи `.git` та `node_modules`.
 
 ## Публічний API
 
-isVueComponentLibraryPkg — забезпечує, що `+` використовується для підхоплення `vite-env.d.ts` та `.vue`.
-passFn — перевіряє наявність `prefixjsconfig.json`.
-check — перевіряє, чи є `vue` у `peerDependencies` пакету бібліотеки. Якщо `vue` є залежністю, то правило авто-імпорту (заборона value-імпортів з `'vue'`) не застосовується до цієї бібліотеки, оскільки імпорти з `'vue'` повинні бути явними.
+isVueComponentLibraryPkg — визначає, чи є пакет бібліотекою компонентів Vue, щоб IDE коректно обробляла файли `.vue` та `vite-env.d.ts`.
+passFn — підтверджує наявність файлу `jsconfig.json` у вказаній директорії.
+check — перевіряє, чи відповідає проєкт вимогам vue.mdc, а саме: чи є `vue` у залежностях кореневого та всіх workspace-пакетів.
 
 ## Гарантії поведінки
 
-- Read-only: файл не виконує операцій запису у файлову систему.
-- За невдачі повертає значення помилки (`false`/`null`/`Err`) замість генерування винятку чи паніки.
+- Read-only: не виконує операцій запису (ФС/БД).
+- Перехоплює помилки і не пропускає винятків назовні (fail-safe).
 - Свідомо пропускає шляхи: `.git`, `node_modules`.
-- Не звертається до мережі.

package/rules/vue/js/packages.mjs

@@ -1,5 +1,5 @@
 /** @see ./docs/packages.md */
-import { existsSync } from 'node:fs'
+import { existsSync, readFileSync } from 'node:fs'
 import { readFile } from 'node:fs/promises'
 import { join, relative } from 'node:path'
 
@@ -500,6 +500,45 @@ async function checkVueVolarRecommendation(pass, fail, cwd) {
   }
 }
 
+// Vitest-пакети мусять бути у кореневому devDependencies монорепо,
+// бо npm-module правило забороняє devDeps у published Vue workspace.
+const ROOT_VITEST_DEV_DEPS = ['vitest', '@vitest/coverage-v8', '@stryker-mutator/vitest-runner']
+
+/**
+ * Перевіряє, що кореневий `package.json` монорепо містить vitest-залежності
+ * у `devDependencies`. Викликається тільки коли є Vue-пакети у воркспейсі.
+ * @param {string} cwd корінь репозиторію
+ * @param {(msg: string) => void} pass pass callback
+ * @param {(msg: string) => void} fail fail callback
+ * @returns {void}
+ */
+function checkRootVitestDevDeps(cwd, pass, fail) {
+  const rootPkgPath = join(cwd, 'package.json')
+  if (!existsSync(rootPkgPath)) {
+    fail('vue: кореневий package.json не знайдено — неможливо перевірити vitest devDependencies')
+    return
+  }
+  let rootPkg
+  try {
+    rootPkg = JSON.parse(readFileSync(rootPkgPath, 'utf8'))
+  } catch {
+    fail('vue: кореневий package.json не вдалося розпарсити — неможливо перевірити vitest devDependencies')
+    return
+  }
+  const devDeps =
+    rootPkg.devDependencies && typeof rootPkg.devDependencies === 'object' ? Object.keys(rootPkg.devDependencies) : []
+  const missing = ROOT_VITEST_DEV_DEPS.filter(p => !devDeps.includes(p))
+  if (missing.length === 0) {
+    pass(`vue: кореневий devDependencies містить ${ROOT_VITEST_DEV_DEPS.join(', ')} (vue.mdc testing)`)
+  } else {
+    for (const pkg of missing) {
+      fail(
+        `vue: кореневий devDependencies не містить '${pkg}' — перенеси з Vue workspace у корінь монорепо (vue.mdc testing)`
+      )
+    }
+  }
+}
+
 /**
  * Перевіряє відповідність проєкту правилам vue.mdc (корінь і всі workspace-пакети з `vue` у dependencies).
  * @param {string} [cwd] корінь репозиторію
@@ -519,6 +558,7 @@ export async function check(cwd = process.cwd()) {
   }
 
   await checkVueVolarRecommendation(pass, fail, cwd)
+  checkRootVitestDevDeps(cwd, pass, fail)
 
   const ignorePaths = await loadCursorIgnorePaths(cwd)
   for (const { rootDir, isComponentLibrary } of vueRoots) {

package/rules/vue/main.mdc

@@ -9,32 +9,10 @@ alwaysApply: false
 
 Правило охоплює стандарти написання Vue 3 SFC з Composition API, конфігурацію Vite-проєкту, UI-бібліотеки, заборонені патерни та вимоги до тестування.
 
-[vue-composition-api](./js/composition-api.mdc)
-
-[vue-quasar-ui](./js/quasar-ui.mdc)
-
-[vue-structure](./js/structure.mdc)
-
-[vue-vite-config](./js/vite-config.mdc)
-
-[vue-vite-env](./js/vite-env.mdc)
-
-[vue-vue-imports](./js/vue-imports.mdc)
-
-[vue-node-imports](./js/node-imports.mdc)
-
-[vue-testing](./js/testing.mdc)
-
-[vue-nheader-layout](./js/nheader-layout.mdc)
-
-[vue-tfm-translations](./js/tfm-translations.mdc)
-
 ## Швидкий gate через conftest
 
 Rego-перевірки (запускаються через `npx @nitra/cursor fix vue`):
 
-[vue-package_json](./policy/package_json/package_json.mdc)
-
 ## Перевірка
 
 `npx @nitra/cursor fix vue` — перевіряє залежності, `vite.config`, наявність **`src/vite-env.d.ts`** з `/// <reference types="vite/client" />` та **`jsconfig.json`** у корені Vue-пакета; обходить джерела Vue-пакета (`.vue`, `.ts`, `.js` тощо) на заборонені value-імпорти з модуля `vue` (дозволені лише type-only та side-effect `import 'vue'`) і додатково сканує `.vue` SFC на імпорти Node-нативних модулів (`node:*` префікс або bare-ім'я вбудованого модуля Node — `fs`, `path`, `timers/promises` тощо). Імпорти аналізуються через **oxc-parser** (`module.staticImports`); для `.vue` вміст `<script>` витягується з SFC, далі той самий парсер (логіка в `npm/rules/vue/js/packages/vue-forbidden-imports.mjs`).

package/rules/worktree/docs/main.md

@@ -8,8 +8,6 @@ docgen:
   score: 100
 ---
 
-## Огляд
-
 Модуль виконує перевірку, застосовуючи політики, визначені в meta.json. Він обробляє JS-запити та звертається до MDC-ресурсів. Модуль є Read-only, тобто не здійснює записів у файлову систему чи бази даних. При запуску як окрема утиліта командного рядка, він виконує правила, використовуючи публічну функцію run. Дані кешуються у межах одного прогону.
 
 ## Поведінка

package/scripts/docs/auto-rules.md

@@ -8,8 +8,6 @@ docgen:
   score: 90
 ---
 
-## Огляд
-
 Автоматично визначає правила та скіли для конфігурації `.n-cursor.json`, скануючи мета-дані з `npm/rules/<id>/main.json` та аналізуючи структуру проєкту, зокрема `package.json`. Система виводить `AUTO_RULE_ORDER` (алфавітно) та `AUTO_RULE_DEPENDENCIES` для кожного правила. Для кожного правила обчислюється специфікація активації (`specMatches`), яка може бути безумовною (`always`), заснованою на шаблонах файлів (`glob`), або предикатною. Процес враховує винятки (`disable-rules`) та виконує транзитивне розгортання залежностей. Збираються контент-факти (GQL, bun-sql, hasura) для точного застосування правил. Також відбувається автоматичне виявлення скілів з `./auto-skills.mjs`, після чого всі виявлені правила та скіли зливаються у конфіг, враховуючи міграцію ID.
 
 ## Поведінка

package/scripts/docs/auto-skills.md

@@ -8,8 +8,6 @@ docgen:
   score: 100
 ---
 
-## Огляд
-
 Визначає, які скіли мають автоматично активуватися, скануючи `npm/skills/` та аналізуючи `main.json` кожного скілу. Логіка активації базується на конфігурації скілу: скіл може активуватися завжди (`auto: "завжди"`), якщо всі перелічені правила виявлені (`auto: ["rule", …]`), або бути opt-in, якщо поле `auto` відсутнє у `main.json`. Це забезпечує, що визначення автоматичної активації скілів є детермінованим, оскільки `main.json` є джерелом правди. Результати сканування використовуються для встановлення `AUTO_SKILL_ORDER` та `AUTO_SKILL_RULE_DEPENDENCIES`, що впливає на роботу з `.n-cursor.json`.
 
 ## Поведінка

package/scripts/docs/hook.md

@@ -3,27 +3,28 @@ type: JS Module
 title: hook.mjs
 resource: npm/scripts/hook.mjs
 docgen:
-  crc: 8a19fee4
-  model: omlx/gemma-4-e4b-it-OptiQ-4bit
-  score: 90
+  crc: 602cd023
+  model: claude-sonnet-4-6
+  score: 100
 ---
 
-## Огляд
-
-Модуль є точкою входу для хуків Claude Code. Він зчитує контекст, отримуючи шлях до файлу з вхідного потоку або визначаючи його через Git. У режимі `--post-tool-use` шлях до файлу зчитується з JSON, що надходить у stdin. У режимі `--stop` визначається робоче дерево проти HEAD (`git diff HEAD` + untracked). Після зчитування контексту, він делегує виконання перевірки за допомогою `runLint`. Код виходу, отриманий від перевірки, перекодовується у відповідний протокол хука (1 $\rightarrow$ 2).
+Точка входу для хуків Claude Code. У режимі `--post-tool-use` зчитує `file_path` зі stdin JSON (PostToolUse hook), запускає lint для цього файлу та перевіряє актуальність файлової документації (`doc-files`). У режимі `--stop` визначає змінені файли (`git diff HEAD` + untracked) і запускає lint по всьому робочому дереву. Повертає exit-код у hook-протоколі (ненуль → 2).
 
 ## Поведінка
 
-extractFilePath: Витягує шлях до файлу з JSON, отриманого з вхідного потоку.
-runHookCli: Виконує логіку хука, визначаючи файли для перевірки на основі аргументів командного рядка, запускає перевірку та повертає відповідний код виходу.
+`runHookCli` виконує відповідну логіку залежно від переданого режиму:
+
+- **`--post-tool-use`**: читає stdin JSON → витягує `tool_input.file_path` → запускає `runLint` для цього файлу (read-only, усі per-file правила включно з `doc-files`) → повертає 2 при порушеннях.
+- **`--stop`**: визначає всі змінені файли через `collectChangedFiles` → запускає `runLint` (read-only) → повертає 2 при порушеннях.
+
+Якщо `file_path` відсутній у stdin або stdin порожній — завершується з кодом 0 (нема що перевіряти).
 
 ## Публічний API
 
-extractFilePath — витягує шлях до файлу з вхідних даних JSON хука Claude Code PostToolUse.
-runHookCli — виконує команду для хука n-cursor.
+- `extractFilePath(json)` — витягує `tool_input.file_path` зі stdin JSON Claude Code PostToolUse hook; повертає `null` якщо JSON відсутній або поле не знайдено.
+- `runHookCli(argv)` — CLI-точка входу для `n-cursor hook`; повертає Promise<number> (0 — чисто, 1 — невідомий режим, 2 — є порушення).
 
 ## Гарантії поведінки
 
 - Read-only: не виконує операцій запису (ФС/БД).
-- Перехоплює помилки і не пропускає винятків назовні (fail-safe).
-- За певних помилок повертає порожнє значення (напр. `null`) замість винятку.
+- Не кидає винятків назовні: помилки stdin та parse-помилки повертають null/0.

package/scripts/docs/post-tool-use-check.md

@@ -8,8 +8,6 @@ docgen:
   score: 100
 ---
 
-## Огляд
-
 Цей модуль є PostToolUse hook, який виконує read-only детект конформності всіх активованих правил після кожного редагування файлу (`Edit` / `Write` / `MultiEdit`). Він отримує шлях до файлу з вхідного JSON. Якщо файл відсутній, модуль завершує роботу з кодом 0. Інакше, він запускає детект конформності по всіх правилах, не виконуючи жодних мутацій чи викликів LLM. Код виходу 1 інформує про наявність порушень конформності, хоча PostToolUse не блокує поточний обмін.
 
 ## Поведінка

package/scripts/docs/sync-claude-config.md

@@ -3,13 +3,11 @@ type: JS Module
 title: sync-claude-config.mjs
 resource: npm/scripts/sync-claude-config.mjs
 docgen:
-  crc: 88f4080d
+  crc: 553933fa
   model: omlx/gemma-4-e4b-it-OptiQ-4bit
   score: 85
 ---
 
-## Огляд
-
 Синхронізує конфігурацію Claude Code (`.claude/settings.json`, slash-команди з `commands/` темплейту, ADR Stop-hook) та Cursor hooks (`.cursor/hooks.json`) у поточний проєкт із темплейтів пакету `npm/.claude-template/`. Здійснює злиття конфігурацій: користувацькі поля зберігаються у `.claude/settings.json`, а дозволи (`permissions.allow`) зливаються через union. Керовані хуки, ідентифіковані командою-маркером `MANAGED_HOOK_COMMAND_MARKERS`, перезаписуються. Копіює ADR Stop-hook (`.claude/hooks/capture-decisions.sh`) та ADR normalize Stop-hook (`.claude/hooks/normalize-decisions.sh`) залежно від налаштувань у `.n-cursor.json`. Також зливає фрагмент `.gitignore` з канонічного шаблону, додаючи необхідні записи для ADR.
 
 ## Поведінка

package/scripts/docs/sync-setup-bun-deps-action.md

@@ -8,8 +8,6 @@ docgen:
   score: 100
 ---
 
-## Огляд
-
 Копіює composite GitHub Action `setup-bun-deps` з каталогу `github-actions/setup-bun-deps/` у корені tarball пакету `@nitra/cursor` у цільовий репозиторій за шлях `.github/actions/setup-bun-deps/action.yml`. Це забезпечує можливість для workflow з правил `ga`, `js` або `text` викликати цей action для налаштування залежностей Bun одразу після виконання `actions/checkout@v6`.
 
 ## Поведінка

package/scripts/hook.mjs

@@ -58,15 +58,14 @@ export async function runHookCli(argv) {
     return 1
   }
 
-  let files
   if (postToolUse) {
     const fp = extractFilePath(await readStdin())
     if (!fp) return 0
-    files = [fp]
-  } else {
-    files = collectChangedFiles(cwd)
+    const code = await runLint({ files: [fp], readOnly: true, cwd })
+    return code !== 0 ? 2 : 0
   }
 
+  const files = collectChangedFiles(cwd)
   const code = await runLint({ files, readOnly: true, cwd })
   return code !== 0 ? 2 : 0
 }

package/scripts/lib/docs/check-mdc-template-refs.md

@@ -8,8 +8,6 @@ docgen:
   score: 100
 ---
 
-## Огляд
-
 Визначає список файлів шаблонів, що знаходяться у каталогах `fix` та `policy`, які не є цільовими посиланнями у файлі `<id>.mdc` як markdown link targets. Це дозволяє ідентифікувати ресурси шаблонів, які не були згадані в контексті правила.
 
 ## Поведінка