@nitra/cursor 12.14.0 → 12.15.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.
package/CHANGELOG.md CHANGED
@@ -1,5 +1,17 @@
1
1
  # Changelog
2
2
 
3
+ ## [12.15.1] - 2026-06-26
4
+
5
+ ### Changed
6
+
7
+ - spec
8
+
9
+ ## [12.15.0] - 2026-06-26
10
+
11
+ ### Changed
12
+
13
+ - Видалено скіл start-check та пов'язані файли
14
+
3
15
  ## [12.14.0] - 2026-06-26
4
16
 
5
17
  ### Changed
@@ -5,7 +5,7 @@
5
5
  Файл `npm/bin/n-cursor.js` — це виконуваний скрипт (shebang `#!/usr/bin/env node`), що слугує єдиною точкою входу CLI пакета `@nitra/cursor`. Скрипт виконує дві ролі:
6
6
 
7
7
  1. **Синхронізатор пакетних артефактів у проєкті-споживачі** — без аргументів копіює `.mdc`-правила, скіли, slash-команди, генерує `AGENTS.md`, `CLAUDE.md`, синхронізує `.claude/settings.json`, `.cursor/hooks.json`, composite GitHub Action `setup-bun-deps`, `.pi/skills`, а також `.gitignore` для `.worktrees/`.
8
- 2. **Маршрутизатор підкоманд** — диспатчить `fix`, `check`, `rename-yaml-extensions`, `post-tool-use-fix`, `lint`, `lint-ci`, `lint-doc-files`, `fix-doc-files`, `coverage`, `coverage-fix`, `analyze-escalation`, `taze`, `start-check`, `change`, `release`, `skill`, `worktree`, `trace`, `doc-aggregate`, `adr-normalize-local` у відповідні внутрішні модулі пакета.
8
+ 2. **Маршрутизатор підкоманд** — диспатчить `rename-yaml-extensions`, `hook`, `lint`, `analyze-escalation`, `taze`, `release`, `skill`, `trace`, `adr-normalize-local`, `doc-aggregate` у відповідні внутрішні модулі пакета.
9
9
 
10
10
  Скрипт — ES-модуль (`import` синтаксис). Виконує реальні файлові операції в `cwd()` і у каталогах пакету (`BUNDLED_PACKAGE_ROOT`). Усі шляхи відносно поточної робочої директорії проєкту-споживача.
11
11
 
@@ -20,7 +20,6 @@
20
20
  - `npx @nitra/cursor lint` — data-driven оркестратор lint+конформності: `--full` (весь репо, включно з `full`-правилами), `--read-only` (CI, нуль мутацій); без прапорів — per-file дельта vs origin.
21
21
  - `npx @nitra/cursor lint-ci` — те саме у CI-режимі.
22
22
  - `npx @nitra/cursor coverage [--fix] [--changed]` — оркестратор покриття та мутаційного тестування.
23
- - `npx @nitra/cursor change` — створення change-файлу.
24
23
  - `npx @nitra/cursor release` — реліз-команда.
25
24
  - `npx @nitra/cursor skill list|taze|cursor|claude …` — керування скілами (промпт на stdout, виклик Cursor/Claude CLI).
26
25
  - `npx @nitra/cursor worktree …` — керування git-worktree.
@@ -462,7 +461,6 @@ try {
462
461
  - `'lint'` → `runLint({ full, readOnly, rules })` (прапори `--full`, `--read-only`; позиційні аргументи — фільтр правил конформності).
463
462
  - `'lint-ci'` → `runLint({ ci: true })`.
464
463
  - `'coverage'` → динамічний import `../rules/test/coverage/coverage.mjs`, виклик `runCoverageCli({ fix: args.includes('--fix'), changed: args.includes('--changed') })`.
465
- - `'change'` → динамічний import `../rules/release/change.mjs` → `runChangeCli(args)`.
466
464
  - `'release'` → динамічний import `../rules/release/release.mjs` → `runReleaseCli(args)`.
467
465
  - `'skill'` → `runSkillsCli(args)` (синхронний).
468
466
  - `'worktree'` → `runWorktreeCli(args)`.
@@ -519,7 +517,6 @@ try {
519
517
  ### Динамічні (lazy) залежності
520
518
 
521
519
  - `../rules/test/coverage/coverage.mjs` — `runCoverageCli`.
522
- - `../rules/release/change.mjs` — `runChangeCli`.
523
520
  - `../rules/release/release.mjs` — `runReleaseCli`.
524
521
  - `../scripts/dispatcher/trace.mjs` — `runTraceCli`.
525
522
  - `../skills/docgen/js/docgen-scan.mjs` — `runDocgenScanCli`, `runDocgenModulesCli`.
package/bin/n-cursor.js CHANGED
@@ -1528,15 +1528,6 @@ try {
1528
1528
 
1529
1529
  break
1530
1530
  }
1531
- case 'analyze-escalation': {
1532
- // n-cursor analyze-escalation — читає весь escalation-лог (.n-cursor/fix-escalation.jsonl),
1533
- // чанкує й просить хмарну avg-модель запропонувати, як зменшити LLM-залежність fix-
1534
- // конформності (нові T0-патерни / правки .mdc / зміни скриптів). Звіт → markdown.
1535
- const { runEscalationAnalysisCli } = await import('../scripts/lib/fix/analyze-escalation.mjs')
1536
- process.exitCode = await runEscalationAnalysisCli(args)
1537
-
1538
- break
1539
- }
1540
1531
  case 'taze': {
1541
1532
  // n-cursor taze diff — read-only semver-diff package.json ↔ package.json.taze-bak
1542
1533
  // (root + воркспейси) для скілу n-taze: скрипт класифікує major-оновлення,
@@ -1546,15 +1537,6 @@ try {
1546
1537
 
1547
1538
  break
1548
1539
  }
1549
- case 'start-check': {
1550
- // n-cursor start-check scan|run — детермінована частина smoke-перевірки для
1551
- // скілу n-start-check: scan виявляє воркспейси зі start і їх тип, run запускає
1552
- // один із grace-таймаутом і класифікує OK/FAIL. Агент лишається з діагностикою.
1553
- const { runStartCheckCli } = await import('../skills/start-check/js/check.mjs')
1554
- process.exitCode = await runStartCheckCli(args)
1555
-
1556
- break
1557
- }
1558
1540
  case 'release': {
1559
1541
  const { runReleaseCli } = await import('../rules/release/release.mjs')
1560
1542
  process.exitCode = await runReleaseCli(args)
@@ -1584,7 +1566,7 @@ try {
1584
1566
  default: {
1585
1567
  console.error(`❌ Невідома команда: ${command}`)
1586
1568
  console.error(
1587
- ` Очікується: (без аргументів) синхронізація правил, rename-yaml-extensions, hook, adr-normalize-local, lint (включно зі scope: lint ga|rego|k8s|docker|text), analyze-escalation, taze, start-check, release, skill, doc-aggregate`
1569
+ ` Очікується: (без аргументів) синхронізація правил, rename-yaml-extensions, hook, adr-normalize-local, lint (включно зі scope: lint ga|rego|k8s|docker|text), taze, release, skill, doc-aggregate`
1588
1570
  )
1589
1571
  process.exitCode = 1
1590
1572
  }
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@nitra/cursor",
3
- "version": "12.14.0",
3
+ "version": "12.15.1",
4
4
  "description": "CLI для завантаження cursor-правил (префікс n-) у локальний репозиторій",
5
5
  "keywords": [
6
6
  "cli",
@@ -3,24 +3,25 @@ type: JS Module
3
3
  title: main.mjs
4
4
  resource: npm/rules/bun/main.mjs
5
5
  docgen:
6
- crc: 18950415
6
+ crc: 7cca0901
7
7
  model: omlx/gemma-4-e4b-it-OptiQ-4bit
8
8
  score: 100
9
9
  ---
10
10
 
11
11
  ## Огляд
12
12
 
13
- Модуль застосовує політики до коду та перевіряє ліцензії залежностей (bun.mdc). Функція `run` застосовує політику до коду, використовуючи кешування у межах прогону для прискорення. Функція `lint` перевіряє ліцензії npm-залежностей, спираючись на конфігурацію в .licensee.json. У режимі `fix` вона створює .licensee.json, а в режимі `readOnly` блокує виконання.
13
+ Модуль виконує виконання політики доступу до коду проєкту та перевірку ліцензій залежностей. Функція `run` застосовує політику, що включає посилання на (bun.mdc), тоді як функція `lint` перевіряє ліцензії npm-залежностей відповідно до конфігурації, визначеної у .licensee.json. Кешування результатів відбувається у межах одного прогону.
14
14
 
15
15
  ## Поведінка
16
16
 
17
- run виконує перевірку, застосовуючи політику до коду, використовуючи кешування.
18
- lint виконує перевірку ліцензій npm-залежностей, генеруючи `.licensee.json` у fix-режимі або відмовляючись у readOnly режимі.
17
+ run виконує перевірку, застосовуючи політику до коду проєкту, включаючи посилання на mdc.
18
+
19
+ lint виконує перевірку ліцензій npm-залежностей через `.licensee.json`. У fix-режимі створює `.licensee.json` з дефолтним allowlist (blueOak: bronze), а у readOnly (CI) відсутність файлу призводить до невдачі.
19
20
 
20
21
  ## Публічний API
21
22
 
22
- run — Точка входу правила, що виконує перевірку: застосовує логіку, перевіряє відповідність політиці та посилання на маркери повідомлень (bun.mdc).
23
- lint — Інструмент для перевірки ліцензій npm-залежностей у всьому репозиторії. У режимі `--full` він працює повноцінно; у режимі виправлення автоматично створює файл .licensee.json, якщо його немає.
23
+ run — виконує основний потік правила: застосовує логіку, перевіряє відповідність політикам та посиланням (bun.mdc).
24
+ lint — проводить перевірку ліцензій npm-залежностей у всьому репозиторії. У режимі `--full` і `--fix` автоматично створює файл .licensee.json, якщо він відсутній.
24
25
 
25
26
  ## Гарантії поведінки
26
27
 
@@ -3,28 +3,28 @@ type: JS Module
3
3
  title: main.mjs
4
4
  resource: npm/rules/python/main.mjs
5
5
  docgen:
6
- crc: b072766d
6
+ crc: 2bdec93d
7
7
  model: omlx/gemma-4-e4b-it-OptiQ-4bit
8
- score: 90
8
+ score: 95
9
9
  ---
10
10
 
11
11
  ## Огляд
12
12
 
13
- Виконує послідовність кроків для валідації коду Python відповідно до правил, визначених у (python.mdc). Перед запуском інструментів перевіряє наявність `pyproject.toml` у корені; якщо він відсутній, завершує роботу з кодом 0. Якщо файл присутній, перевіряє наявність `uv` у PATH, оскільки він є єдиним пакет-менеджером. Обов'язково виконує `uv lock --check` для підтвердження актуальності lock-файлу та `uv sync --frozen` для синхронізації середовища з `uv.lock` (див. https://docs.astral.sh/uv/). Опційні лінтери запускаються лише за умови їх доступності через `uv run`. При використанні `ruff` застосовується автоматичне виправлення (`auto-fix`), що модифікує робоче дерево. Усі операції виконуються з механізмом перехоплення помилок (fail-safe), запобігаючи викиданню винятків назовні.
13
+ Цей модуль виконує послідовність кроків для забезпечення якості коду Python, використовуючи інструменти з екосистеми [uv](https://docs.astral.sh/uv/). Якщо файл `pyproject.toml` відсутній у корені, процес завершується з кодом 0 без запуску інструментів. Якщо файл присутній, але `uv` не знайдено в PATH, це розглядається як помилка. Модуль гарантує актуальність lock-файлу (`uv lock --check`) та збірку середовища (`uv sync --frozen`) перед запуском лінтерів. Опціональні лінтери запускаються лише за умови їх доступності через `uv run`.
14
14
 
15
15
  ## Поведінка
16
16
 
17
- run виконує стандартну перевірку на основі контексту.
18
- runLintPythonSteps виконує повний цикл лінтування Python, включаючи перевірку `uv lock --check`, `uv sync --frozen` та запуск лінтерів, якщо `pyproject.toml` присутній.
19
- runLintPython запускає кроки лінтування Python, використовуючи механізм серіалізації через `runStandardLint`.
20
- lint оркеструє запуск `runLintPython` з опцією `readOnly` для детектних перевірок.
17
+ run виконує стандартну перевірку проєкту, використовуючи контекст прогону.
18
+ runLintPythonSteps виконує повний набір кроків лінтування Python, включаючи перевірку `pyproject.toml`, виконання `uv lock --check` та `uv sync --frozen`, а також запуск опціональних лінтерів (`ruff`, `mypy`) та перевірку ліцензій.
19
+ runLintPython запускає повний процес лінтування Python, серіалізуючи його через стандартний механізм перевірки.
20
+ lint оркеструє запуск `runLintPython`, надаючи можливість вказати режим без мутацій (`readOnly`).
21
21
 
22
22
  ## Публічний API
23
23
 
24
- run — Точка входу для виконання правил, яка перевіряє аспекти застосування (JS-занепокложення $\rightarrow$ політика $\rightarrow$ mdc-посилання).
25
- runLintPythonSteps — Виконує внутрішні етапи перевірки коду Python без збереження результатів.
26
- runLintPython — Публічний інтерфейс командного рядка для запуску перевірки коду Python, що забезпечує унікальність завдяки блоку блокування та аналізу стану Git-дерева.
27
- lint — Адаптер, що керує запуском перевірки коду Python, делегуючи це `runLintPython`.
24
+ run — Основна точка входу правила, яка виконує перевірку (JS-занепокложення $\rightarrow$ політика $\rightarrow$ mdc-посилання) та викликає перевірку якості коду.
25
+ runLintPythonSteps — Виконує внутрішні етапи перевірки якості Python-коду без збереження логів.
26
+ runLintPython — Публічний інтерфейс для запуску перевірки якості Python-коду, який синхронізується з станом Git-дерева.
27
+ lint — Координатор, що ініціює запуск перевірки якості Python-коду, делегуючи цю роботу `runLintPython`.
28
28
 
29
29
  ## Гарантії поведінки
30
30
 
@@ -3,25 +3,25 @@ type: JS Module
3
3
  title: main.mjs
4
4
  resource: npm/rules/rust/main.mjs
5
5
  docgen:
6
- crc: bbddef51
6
+ crc: 93dfaee0
7
7
  model: omlx/gemma-4-e4b-it-OptiQ-4bit
8
8
  score: 100
9
9
  ---
10
10
 
11
11
  ## Огляд
12
12
 
13
- Модуль надає інструменти для забезпечення якості коду на Rust. Він дозволяє виконати перевірку стилю за допомогою функції `lint` або запустити повну оркестрацію, що включає форматування та аналіз, за допомогою функції `run`. (rust.mdc)
13
+ Модуль надає функції `run` та `lint` для аналізу коду на Rust. Функція `lint` виконує стандартну перевірку коду. Функція `run` запускає повну оркестрацію, яка включає форматування за допомогою `rustfmt` та статичний аналіз за допомогою `clippy` через `cargo` (rust.mdc).
14
14
 
15
15
  ## Поведінка
16
16
 
17
17
  run виконує стандартну перевірку для Rust-коду.
18
18
 
19
- lint запускає оркестрацію перевірки Rust-коду, включаючи форматування та аналіз.
19
+ lint запускає оркестрацію перевірки Rust-коду, виконуючи `rustfmt` та `clippy` через `cargo`.
20
20
 
21
21
  ## Публічний API
22
22
 
23
- run — виконує основну перевірку, що включає перевірку логіки, пов'язаної з JS, політики та посиланнями MDC (rust.mdc).
24
- lint — забезпечує фіксацію та виконання перевірок стилю коду (аналогічно cargo fmt/clippy) для `n-cursor lint rust`.
23
+ run — виконує основну логіку: перевіряє відповідність вимогам (JS-занепокложення $\rightarrow$ політика $\rightarrow$ mdc-посилання) (rust.mdc).
24
+ lint — забезпечує оркестрацію для статичного аналізу коду Rust.
25
25
 
26
26
  ## Гарантії поведінки
27
27
 
@@ -3,25 +3,25 @@ type: JS Module
3
3
  title: update-blue-oak.mjs
4
4
  resource: npm/scripts/update-blue-oak.mjs
5
5
  docgen:
6
- crc: f818f73b
6
+ crc: dac30fed
7
7
  model: omlx/gemma-4-e4b-it-OptiQ-4bit
8
8
  score: 95
9
9
  ---
10
10
 
11
11
  ## Огляд
12
12
 
13
- Оновлює вбудований список ліцензій Blue Oak Council, отримуючи дані з https://blueoakcouncil.org/list.json. Витягує SPDX-ідентифікатори ліцензій рівнів Model, Gold, Silver та Bronze і зберігає їх у npm/data/blue-oak.json. Цей процес запускається вручну у середовищі @nitra/cursor командою bun npm/scripts/update-blue-oak.mjs. Оновлення відбувається рідко, але нові permissive ліцензії з'являються раз на кілька місяців. Lead-рівень (найгірший, GPL-compatible) навмисно виключений.
13
+ Оновлює вбудований список ліцензій Blue Oak Council, звертаючись до мережі за даними з https://blueoakcouncil.org/list.json. Цей процес створює або оновлює файл npm/data/blue-oak.json, який містить SPDX-ідентифікатори ліцензій рівнів Model, Gold, Silver та Bronze. Запуск здійснюється вручну у `@nitra/cursor` за допомогою команди `bun npm/scripts/update-blue-oak.mjs`. Оновлення необхідне при апгрейді @nitra/cursor, оскільки нові permissive ліцензії з'являються рідко. Lead-рівень (найгірший, GPL-compatible) навмисно виключений.
14
14
 
15
15
  ## Поведінка
16
16
 
17
17
  1. Завантажує дані з https://blueoakcouncil.org/list.json.
18
- 2. Перевіряє успішність отримання даних. У разі невдачі зупиняє виконання.
19
- 3. Парсить отриманий JSON-відповідь.
18
+ 2. Перевіряє успішність отримання даних. У разі невдачі припиняє виконання.
19
+ 3. Парсить отримані дані.
20
20
  4. Ітерує по рейтингах у даних.
21
- 5. Для кожного рейтингу перевіряє, чи належить він до рівнів Model, Gold, Silver або Bronze.
22
- 6. Якщо рейтинг відповідає критеріям, витягує всі SPDX-ідентифікатори ліцензій, пов'язані з цим рейтингом, та додає їх до списку.
23
- 7. Формує об'єкт, що містить версію даних та зібраний список SPDX-ідентифікаторів.
24
- 8. Зберігає цей об'єкт у файл blue-oak.json у каталозі data.
21
+ 5. Вибирає лише рейтинги Model, Gold, Silver та Bronze.
22
+ 6. Збирає всі SPDX-ідентифікатори ліцензій, що належать до обраних рейтингів.
23
+ 7. Формує об'єкт, що містить версію та список зібраних SPDX-ідентифікаторів.
24
+ 8. Зберігає цей об'єкт у файл npm/data/blue-oak.json.
25
25
 
26
26
  ## Гарантії поведінки
27
27
 
@@ -3,24 +3,24 @@ type: JS Module
3
3
  title: discover-checkable-rules.mjs
4
4
  resource: npm/scripts/lib/discover-checkable-rules.mjs
5
5
  docgen:
6
- crc: 403ab2ee
6
+ crc: d06cd969
7
7
  model: omlx/gemma-4-e4b-it-OptiQ-4bit
8
8
  score: 100
9
9
  ---
10
10
 
11
11
  ## Огляд
12
12
 
13
- Шукає правила, для яких є щось «прогонне» у визначених структурах. Виявляє JS-концерни за шляхами `rules/<id>/js/<concern>.mjs` та Policy-концерни, які мають пару з `<concern>.rego` (зв'язану з конфігурацією `target.json`). Ігнорує файли з префіксом `_` та `*.test.mjs`, а також каталоги `_lib/`. Виконання є швидким скануванням структури (шляхи та назви) без парсингу вмісту.
13
+ Визначає наявність JS-концернів та policy-концернів у заданому каталозі правила. Сканує всі каталоги правил, шукаючи JS-концерни у файлах `rules/<id>/js/<concern>.mjs` та policy-концерни, що асоціюються з парою `<concern>.rego` та `target.json`. Повертає список правил, які містять такі прогонні частини. Файли з префіксом `_` або `*.test.mjs` ігноруються.
14
14
 
15
15
  ## Поведінка
16
16
 
17
- discoverOneRule описує набір JS-концернів та policy-концернів для одного каталогу правила, використовуючи шлях до цього каталогу та його ідентифікатор.
18
- discoverCheckableRules сканує каталог з усіма правилами та повертає список правил, які мають JS-концерни або policy-концерни, фільтруючи ті, що не містять прогонного контенту.
17
+ discoverOneRule описує правило, виявляючи JS-концерни та policy-концерни в заданому каталозі правила.
18
+ discoverCheckableRules сканує каталог правил і повертає список правил, які мають JS-концерни або policy-концерни, фільтруючи ті, що не мають прогонних частин.
19
19
 
20
20
  ## Публічний API
21
21
 
22
- discoverOneRule — створює об'єкт перевірки для одного каталогу правила.
23
- discoverCheckableRules — знаходити правила у каталозі `rules/`, які мають відповідні скрипти у `js/` або політики у `policy/`.
22
+ - discoverOneRule — Створює об'єкт для одного правила, що перевіряє конкретний каталог.
23
+ - discoverCheckableRules — Знаходить правила у каталозі `rules/`, які мають відповідні скрипти (у `js/`) або політики (у `policy/`). Ігнорує правила, що містять лише документацію.
24
24
 
25
25
  ## Гарантії поведінки
26
26
 
@@ -3,22 +3,24 @@ type: JS Module
3
3
  title: inline-template-links.mjs
4
4
  resource: npm/scripts/lib/inline-template-links.mjs
5
5
  docgen:
6
- crc: e1bed533
6
+ crc: 252fb1e1
7
7
  model: omlx/gemma-4-e4b-it-OptiQ-4bit
8
8
  score: 100
9
9
  ---
10
10
 
11
- Модуль інтегрує зовнішній контент у текстовий вивід, використовуючи конфігурації з `package.json.snippet.json` та `package.json`. Він замінює посилання на шаблони в тексті на їхній вміст за допомогою `inlineTemplateLinks` та доповнює текст вмістом усіх знайдених файлів `.mdc` з директорій `js/` та `policy/<concern>/` за допомогою `appendDiscoveredMdcFiles`.
11
+ ## Огляд
12
+
13
+ Модуль збагачує текстовий контент, використовуючи конфігурації з package.json.snippet.json та package.json. Функція inlineTemplateLinks замінює текстові посилання на шаблони вбудованими блоками, якщо відповідні файли знаходяться у директорії правил. Функція appendDiscoveredMdcFiles доповнює текст вмістом усіх знайдених файлів `.mdc` з піддиректорій `js/` та `policy/` у директорії правил.
12
14
 
13
15
  ## Поведінка
14
16
 
15
- inlineTemplateLinks замінює посилання на шаблони в тексті на вбудовані блоки з вмістом відповідних файлів.
16
- appendDiscoveredMdcFiles додає вміст усіх знайдених файлів \*.mdc з директорій js/ та policy/<concern>/ до наданого тексту.
17
+ inlineTemplateLinks замінює посилання на шаблони в тексті на вбудовані блоки з вмістом файлу, якщо ці файли існують у вказаній директорії правил.
18
+ appendDiscoveredMdcFiles додає до кінця тексту вміст усіх знайдених файлів `.mdc` з піддиректорій `js/` та `policy/` у директорії правил.
17
19
 
18
20
  ## Публічний API
19
21
 
20
- inlineTemplateLinks — Замінює посилання у Markdown, що містять `/template/`, на вбудовані блоки, зчитуючи вміст з вказаного файлу. Викидає помилку, якщо цільове посилання не знайдено.
21
- appendDiscoveredMdcFiles — Додає всі знайдені файли з розширенням `.mdc` з підкаталогів `js/` та `policy/<concern>/`. Спочатку додаються файли з `js/` алфавітному порядку), а потім файли з підкаталогів `policy/` (у алфавітному порядку за назвою `concern`, а потім за назвою файлу).
22
+ inlineTemplateLinks — Замінює посилання на шаблони в Markdown на вбудовані блоки, якщо шлях містить `/template/`. Помилка виникає, якщо цільовий файл посилання відсутній.
23
+ appendDiscoveredMdcFiles — Додає всі знайдені файли `.mdc` з папок `js/` та `policy/<concern>/`. Файли з `js/` йдуть першими, а потім файли з підпапок `policy/<concern>/` (у алфавітному порядку за `concern`, а потім за назвою файлу).
22
24
 
23
25
  ## Гарантії поведінки
24
26
 
@@ -3,17 +3,19 @@ type: JS Module
3
3
  title: list-project-rules-mdc.mjs
4
4
  resource: npm/scripts/lib/list-project-rules-mdc.mjs
5
5
  docgen:
6
- crc: 60cd4e83
6
+ crc: 59fe0e6e
7
7
  model: omlx/gemma-4-e4b-it-OptiQ-4bit
8
8
  score: 100
9
9
  ---
10
10
 
11
- Цей модуль визначає шлях до `.mdc`-файлів правил у проєкті-споживачі, що зберігаються у директорії, вказаній константою CURSOR_RULES_DIR. Він надає відсортований список імен цих файлів. Це винесення логіки з `bin/n-cursor.js` забезпечує розділення відповідальності між інструментом командного рядка та функцією перевірки конформності.
11
+ ## Огляд
12
+
13
+ Цей модуль визначає шлях до правил у проєкті-споживачі, що константою експортується як CURSOR_RULES_DIR=".cursor/rules". Він надає відсортований список імен файлів `.mdc` з каталогу правил. Це дозволяє розділити логіку диспетчеризації командного інтерфейсу та логіку перевірки конформності. Функція зчитує та повертає список файлів, якщо каталог правил існує.
12
14
 
13
15
  ## Поведінка
14
16
 
15
17
  CURSOR_RULES_DIR — Вказує на каталог правил у проєкті-споживачі.
16
- listProjectRulesMdcFiles — Повертає відсортований список імен файлів з розширенням `.mdc` у каталозі правил проєкту, або порожній масив, якщо каталог не існує.
18
+ listProjectRulesMdcFiles — Повертає відсортований список імен файлів `.mdc` з каталогу правил проєкту-споживача, якщо цей каталог існує.
17
19
 
18
20
  ## Публічний API
19
21
 
@@ -3,30 +3,27 @@ type: JS Module
3
3
  title: root-notice.mjs
4
4
  resource: npm/scripts/lib/root-notice.mjs
5
5
  docgen:
6
- crc: 5f3ca2bb
6
+ crc: 65db7d81
7
+ model: omlx/gemma-4-e4b-it-OptiQ-4bit
8
+ score: 100
7
9
  ---
8
10
 
9
- Цей файл вставляє root-guard preflight для скілів, які змінюють проєкт у поточному каталозі. Він забезпечує, що скіл виконується in-place, без ізоляції worktree, і використовується для випадків, коли не потрібна ізоляція worktree. Це гарантує коректне виконання скілу від імені проєкту.
11
+ ## Огляд
12
+
13
+ Цей модуль вшиває інструкцію для агента у файл `SKILL.md`. Інструкція вказує, що скіл мутує проєкт у поточному каталозі, але виконується in-place (без worktree-ізоляції), що відповідає конфігурації `meta.json` $\to$ `requireRoot: true` і `worktree: false`. Це застосовується до скілів, які змінюють `meta.json` або `package.json` безпосередньо, на відміну від worktree-скілів, які мають свій `root-assert` у `worktree-notice.mjs`. Блок є інструкцією агенту, що читає `SKILL.md`, і є ре-синк ідемпотентним: наявний блок замінюється, при `false` — видаляється. Програмний аналог для CLI-команд — `assertCwdIsProjectRoot`. Інструкція позначається маркерами `ROOT_START` ("<!-- n-cursor:root:start -->") та `ROOT_END` ("<!-- n-cursor:root:end -->").
10
14
 
11
15
  ## Поведінка
12
16
 
13
- ROOT_START: вставляє маркер початку root-блоку.
14
- ROOT_END: вставляє маркер кінця root-блоку.
15
- injectRootNotice: вставляє, оновлює або видаляє root-guard блок у вмісті `SKILL.md` на основі параметра `enabled`.
17
+ ROOT_START: Позначає початок блоку інструкції щодо перевірки кореня репозиторію.
18
+ ROOT_END: Позначає кінець блоку інструкції щодо перевірки кореня репозиторію.
19
+ injectRootNotice: Вставляє, оновлює або видаляє блок інструкції щодо перевірки кореня репозиторію у вмісті файлу `SKILL.md` на основі булевого прапорця.
16
20
 
17
21
  ## Публічний API
18
22
 
19
- - ROOT_START — Позначає початок блоку root.
20
- - ROOT_END — Позначає кінець блоку root.
21
- - injectRootNotice — Змінює вміст `SKILL.md` щодо root-guard блоку.
23
+ ROOT_START — маркер початку основного блоку документації.
24
+ ROOT_END — маркер завершення основного блоку документації.
25
+ injectRootNotice — додає, змінює або видаляє захисний блок у файлі `SKILL.md`.
22
26
 
23
27
  ## Гарантії поведінки
24
28
 
25
- - Якщо `requireRoot: true` у `meta.json`, то поточний робочий каталог є коренем проєкту.
26
- - Якщо `requireRoot: false`, то блок не вставляється.
27
- - Вставка відбувається лише між маркерами.
28
- - Вставка ре-синк ідемпотентно: наявний блок замінюється.
29
- - `ROOT_START` викликається перед вставкою блоку.
30
- - `ROOT_END` викликається після вставки блоку.
31
- - `injectRootNotice` викликається під час вставки блоку.
32
- - Немає кешування.
29
+ - Read-only: не виконує операцій запису (ФС/БД).
@@ -3,26 +3,28 @@ type: JS Module
3
3
  title: run-lint.mjs
4
4
  resource: npm/scripts/lib/run-lint.mjs
5
5
  docgen:
6
- crc: f574f097
6
+ crc: 3c7deca0
7
7
  model: omlx/gemma-4-e4b-it-OptiQ-4bit
8
8
  score: 100
9
9
  ---
10
10
 
11
- Модуль керує процесом лінтування коду. Він визначає набір активних правил лінтування, використовуючи конфігурації з `meta.json` та `.n-cursor.json`. Модуль надає можливість вибрати ці правила за допомогою `selectLintRules` та ініціювати запуск перевірки коду за допомогою `runLint`.
11
+ ## Огляд
12
+
13
+ Модуль визначає набір правил лінтування, спираючись на конфігурації `meta.json` та `.n-cursor.json`. Він використовує `selectLintRules` для вибору та сортування цих правил, а потім ініціалізує процес перевірки конформності та форматування за допомогою `runLint` у різних режимах (scoped, hook, delta, full).
12
14
 
13
15
  ## Поведінка
14
16
 
15
- selectLintRules визначає, які правила лінтуються на основі їхньої конфігурації та активності в `.n-cursor.json`, повертаючи відсортований список ID.
16
- runLint запускає лінтер-оркестрацію залежно від наданих опцій: виконує прогін для конкретних правил, перевіряє лише змінені файли, виконує повний прогін репозиторію або форматування.
17
+ selectLintRules вибирає і алфавітно сортує ідентифікатори правил для лінтування на основі їхньої метаінформації та стану активації в `.n-cursor.json`.
18
+ runLint запускає лінт-оркестрацію, виконуючи різні режими залежно від наданих опцій: scoped (за назвами правил), hook (за явним списком файлів), delta (зміна відносно origin) або full (весь репозиторій), включаючи конформність та форматування у fix-режимі.
17
19
 
18
20
  ## Публічний API
19
21
 
20
- selectLintRules — вибирає ідентифікатори правил для контексту в алфавітному порядку.
22
+ selectLintRules — обирає ідентифікатори правил для контексту, у алфавітному порядку.
21
23
  runLint — ініціює процес лінтування.
22
24
  full — аналізує весь репозиторій, порівнюючи поточний стан із початковим.
23
- readOnly — лише виявляє проблеми, не вносячи змін.
24
- rules — виконує повний прогін лише для заданого набору правил у вказаному контексті.
25
- files — виконує перевірку лише для перелічених файлів у режимі хука.
25
+ readOnly — лише виявляє проблеми без внесення змін.
26
+ rules — виконує повний прогін лише для заданого набору правил.
27
+ files — застосовує правила до конкретного переліку файлів у режимі хука.
26
28
 
27
29
  ## Гарантії поведінки
28
30
 
@@ -3,26 +3,28 @@ type: JS Module
3
3
  title: skill-meta.mjs
4
4
  resource: npm/scripts/lib/skill-meta.mjs
5
5
  docgen:
6
- crc: c1757867
6
+ crc: 9ff67388
7
7
  model: omlx/gemma-4-e4b-it-OptiQ-4bit
8
8
  score: 100
9
9
  ---
10
10
 
11
- Спільний парсер метаданих скіла, що зчитує інформацію з `main.json`. Цей файл є єдиним джерелом правди для скіла. Модуль дозволяє визначати умови автоактивації скіла (через поле `auto`), вказувати, чи виконувати скіл в окремому git-worktree (`worktree`), та чи вимагає він запуску з кореня репозиторію (`requireRoot`). Надає константу `SKILL_ALWAYS` для безумовної активації. Хелпер використовується іншими компонентами для уникнення дублювання парсингу. Функції забезпечують перехоплення помилок (fail-safe), повертаючи порожнє значення замість винятків.
11
+ ## Огляд
12
+
13
+ Спільний парсер метаданих скіла, що зчитує дані з `main.json`. `main.json` є єдиним джерелом правди для скіла, визначаючи його умови автоактивації (`auto`, де `SKILL_ALWAYS` означає "завжди"), чи виконувати скіл в окремому git-worktree (`worktree`), та чи вимагає він запуску з кореня репозиторію (`requireRoot`). Модуль надає функції для читання сирих метаданих та визначення умов, використовуючи механізм fail-safe, який перехоплює помилки, не кидаючи винятків. Цим хелпером користуються `auto-skills.mjs`, `n-cursor.js` та `npm-module/js/skill_meta.mjs`.
12
14
 
13
15
  ## Поведінка
14
16
 
15
17
  SKILL_ALWAYS — надає літерал для безумовної автоактивації скіла.
16
- parseSkillAutoSpec — перетворює значення поля `auto` з `main.json` у специфікацію автоактивації.
17
- skillRequiresRoot — визначає, чи вимагає скіл запуску з кореня репозиторію, базуючись на метаданих.
18
- readSkillMetaRaw — читає та парсить файл `main.json` для заданого каталогу скіла.
18
+ parseSkillAutoSpec — перетворює значення поля `auto` з `main.json` у специфікацію автоактивації скіла.
19
+ skillRequiresRoot — визначає, чи вимагає скіл запуску з кореня репозиторію, на основі метаданих.
20
+ readSkillMetaRaw — читає та парсить файл `main.json` з каталогу скіла, повертаючи його вміст або `null` у разі помилки.
19
21
 
20
22
  ## Публічний API
21
23
 
22
- SKILL_ALWAYS — позначка для безумовної активації.
23
- parseSkillAutoSpec — витягує налаштування автоматичного запуску з `main.json` у структуру `SkillAutoSpec`.
24
- skillRequiresRoot — визначає, чи потрібен запуск скіла з кореня репозиторію (активує захист від запуску з інших місць).
25
- readSkillMetaRaw — зчитує та розбирає метадані одного скіла з `main.json`.
24
+ SKILL_ALWAYS — позначка для безумовної активації
25
+ parseSkillAutoSpec — витягує налаштування автоматичного запуску зі `main.json`
26
+ skillRequiresRoot — визначає, чи потрібен запуск скіла з кореня репозиторію
27
+ readSkillMetaRaw — зчитує та аналізує метадані окремого скіла з `main.json`
26
28
 
27
29
  ## Гарантії поведінки
28
30
 
@@ -3,28 +3,25 @@ type: JS Module
3
3
  title: discover-t0-patterns.mjs
4
4
  resource: npm/scripts/lib/fix/discover-t0-patterns.mjs
5
5
  docgen:
6
- crc: f2a262bb
6
+ crc: 3f3b47e0
7
7
  model: omlx/gemma-4-e4b-it-OptiQ-4bit
8
8
  score: 100
9
9
  ---
10
10
 
11
11
  ## Огляд
12
12
 
13
- Модуль сканує директорію правил для пошуку файлів `fix-*.mjs`, що містять визначення T0-паттернів. Він динамічно імпортує ці файли з папок `js` та `policy/{concern}` для кожного правила. Ініціалізація результату відбувається за допомогою _top-level await_ у `t0.mjs`. Функція збирає масив об'єктів, що описують усі знайдені паттерни.
13
+ Сканує директорії `npm/rules/{rule}/js/fix-*.mjs` та `npm/rules/{rule}/policy/{concern}/fix-*.mjs` для всіх правил. Динамічно імпортує кожен знайдений файл `fix-*.mjs` та збирає масиви `patterns`. Результат ініціалізується через top-level await у `t0.mjs` і представляє унікальний список усіх виявлених T0-паттернів. Функція не виконує операцій запису та перехоплює помилки, повертаючи `null` у випадку збоїв замість викидання винятків.
14
14
 
15
15
  ## Поведінка
16
16
 
17
- 1. Перевіряє існування директорії, вказаної як `rulesDir`. Якщо директорія не існує, повертає порожній масив.
18
- 2. Зчитує список усіх елементів у директорії `rulesDir`.
19
- 3. Для кожного елемента, який є директорією та не починається з крапки, виконується наступне:
20
- а. Визначається повний шлях до директорії правила.
21
- б. Знаходяться всі файли `fix-*.mjs` у піддиректорії `js` цього правила.
22
- в. Знаходяться всі файли `fix-*.mjs` у піддиректоріях `policy/{concern}` цього правила.
23
- г. Для кожного знайденого файлу `fix-*.mjs` виконується динамічний імпорт.
24
- д. Якщо імпорт успішний, збирається масив `patterns` з імпортованого модуля та додається до загального списку паттернів.
25
- е. У разі помилки імпорту, помилка виводиться в консоль, але процес продовжується.
26
- 4. Після обробки всіх правил, виконується дедуплікація загального списку паттернів за їхніми ідентифікаторами.
27
- 5. Повертається фінальний, унікальний масив T0-паттернів.
17
+ 1. Перевіряє існування шляху `rulesDir`. Якщо шлях не існує, повертає порожній масив.
18
+ 2. Знаходить усі файли з шаблонами у шляхах `*/js/fix-*.mjs` та `*/policy/*/fix-*.mjs` у межах `rulesDir`.
19
+ 3. Для кожного знайденого файлу:
20
+ а. Намагається динамічно імпортувати вміст файлу.
21
+ б. Якщо імпорт успішний і вміст містить масив `patterns`, додає ці паттерни до загального списку.
22
+ в. Якщо імпорт не вдається, реєструє помилку, але продовжує роботу.
23
+ 4. Фільтрує загальний список паттернів, щоб уникнути дублікатів, зберігаючи лише перше входження кожного паттерна за його ідентифікатором.
24
+ 5. Повертає відфільтрований масив унікальних T0-паттернів.
28
25
 
29
26
  ## Публічний API
30
27
 
@@ -8,7 +8,6 @@ resource: npm/scripts/lib/fix/
8
8
 
9
9
  | Файл | Тип |
10
10
  | ----------------------------------------------------- | --------- |
11
- | [analyze-escalation.mjs](analyze-escalation.md) | JS Module |
12
11
  | [discover-t0-patterns.mjs](discover-t0-patterns.md) | JS Module |
13
12
  | [escalation-log.mjs](escalation-log.md) | JS Module |
14
13
  | [llm-fix-apply.mjs](llm-fix-apply.md) | JS Module |
@@ -3,31 +3,26 @@ type: JS Module
3
3
  title: llm-worker.mjs
4
4
  resource: npm/scripts/lib/fix/llm-worker.mjs
5
5
  docgen:
6
- crc: 5d019a98
6
+ crc: b5e54981
7
7
  model: omlx/gemma-4-e4b-it-OptiQ-4bit
8
8
  score: 100
9
9
  ---
10
10
 
11
11
  ## Огляд
12
12
 
13
- Модуль виділяє унікальні відносні шляхи файлів, пов'язаних із порушеннями, та виконує LLM-виклик для виправлення одного rule-порушення. Підтримує вибір sub-check `.mdc` за конкретним target-файлом — замість повного `n-{id}.mdc` передає моделі лише релевантну секцію правила (1–2 KB замість 20+ KB).
13
+ Модуль витягує унікальні відносні шляхи файлів з даних про порушення, використовуючи конфігурацію з target.json. Потім він викликає LLM для генерації змін, які виправляють кожне порушення.
14
14
 
15
15
  ## Поведінка
16
16
 
17
- `extractFilePaths` витягує унікальні відносні шляхи файлів із violation output, пріоритетно розбираючи рядки (файли що потребують фіксу), потім generic-regex для контексту. Розуміє workspace-prefix `[npm] path/file.ext → npm/path/file.ext`.
18
-
19
- `selectSubCheckMdc` читає `policy/<concern>/target.json` з каталогу `npm/rules/{ruleId}/` пакету, знаходить concerns із `files.single`, що відповідають failing-файлам із violation output, і повертає конкатенацію відповідних `.mdc`. Повертає `null` якщо правило не має policy-підкаталогу або жоден concern не збігається з ❌-файлами.
20
-
21
- `runLlmWorker` спочатку викликає `selectSubCheckMdc` — і якщо отримує match, передає моделі лише той sub-check `.mdc`. Якщо match немає — fallback на повний `n-{id}.mdc`. Далі читає файли з violation output, будує prompt, викликає LLM через `callLlmRich` і застосовує зміни.
17
+ extractFilePaths витягує унікальні відносні шляхи файлів з вихідних даних про порушення, розпізнаючи як явні помилки, так і контекст файлів.
18
+ runLlmWorker виправляє одне порушення правила, викликаючи LLM для генерації змін, парсить відповідь та застосовує зміни до файлової системи.
22
19
 
23
20
  ## Публічний API
24
21
 
25
- `extractFilePaths(output)`повертає унікальні відносні шляхи файлів з violation output (❌-рядки першими).
26
-
27
- `runLlmWorker(ruleId, violationOutput, projectRoot, opts)` — виправляє одне порушення правила через LLM. Повертає `{ ok, error?, changes, diagnosis, reasoning, reasoningSource, promptSummary }`. `promptSummary.subCheckMdc: boolean` вказує чи використано точковий sub-check замість повного mdc.
22
+ extractFilePaths — Визначає шляхи файлів, які потребують виправлення, використовуючи `target.json` як пріоритет, а у разі його відсутності — всі знайдені шляхи.
23
+ runLlmWorker — Виправляє одне порушення правила, використовуючи модель LLM. Повертає результати виправлення або діагностики, які використовуються для подальшої обробки.
28
24
 
29
25
  ## Гарантії поведінки
30
26
 
31
- - Читає `policy/` безпосередньо з пакету (`import.meta.dirname/../../../rules/`), без pre-generation файлів.
32
- - Fallback на повний `n-{id}.mdc` при: відсутності policy-підкаталогу, `walkGlob`-таргетах, відсутності ❌-файлів у violation, нульовому match.
33
- - Перехоплює всі помилки LLM і повертає структурований `{ ok: false, error }`.
27
+ - Read-only: не виконує операцій запису (ФС/БД).
28
+ - Перехоплює помилки і не пропускає винятків назовні (fail-safe).