@nitra/cursor 1.13.82 → 1.13.84

package/scripts/utils/ast-scan-utils.mjs

@@ -5,9 +5,9 @@
  * розпізнавання типових вузлів (функцій, `*.join(...)`),
  * робота з `TemplateLiteral` (текст quasis, контекст SQL-списку).
  *
- * Використовується сканерами у `rules/<rule>/fix/...` (наприклад,
- * `rules/js-bun-db/fix/safety/bun-sql-scan.mjs`, `rules/js-mssql/fix/deps/mssql-pool-scan.mjs`,
- * `rules/js-run/fix/runtime/*-scan.mjs`) для уникнення дублювання boilerplate.
+ * Використовується сканерами у `rules/<rule>/js/...` (наприклад,
+ * `rules/js-bun-db/js/safety/bun-sql-scan.mjs`, `rules/js-mssql/js/deps/mssql-pool-scan.mjs`,
+ * `rules/js-run/js/runtime/*-scan.mjs`) для уникнення дублювання boilerplate.
  */
 import { parseSync } from 'oxc-parser'
 

package/scripts/utils/discover-check-rules-from-cursor.mjs

@@ -1,5 +1,5 @@
 /**
- * Визначає список id правил для `npx @nitra/cursor check` без аргументів:
+ * Визначає список id правил для `npx @nitra/cursor fix` без аргументів:
  * зчитує базові імена `*.mdc` у `.cursor/rules/` і залишає лише ті id,
  * для яких у пакеті є programmatic перевірка (JS-концерн або policy з target.json).
  */

package/scripts/utils/discover-checkable-rules.mjs

@@ -1,17 +1,17 @@
 /**
  * Discovery rules для CLI `check`. Шукає правила, для яких є щось «прогонне»:
- *   - JS concerns:   `rules/<id>/fix/<concern>/<check.mjs | check-*.mjs>` — кожен concern окремий вузол.
+ *   - JS concerns:   `rules/<id>/js/<concern>/<check.mjs | check-*.mjs>` — кожен concern окремий вузол.
  *   - Policy concerns: `rules/<id>/policy/<concern>/target.json` — пара з `<concern>.rego`.
  *
- * Каталог `fix/utils/` свідомо пропускається — це хелпери, не концерни.
+ * Каталог `js/utils/` свідомо пропускається — це хелпери, не концерни.
  * Файли `*.test.mjs` фільтруються regex (`^check(?:-.+)?\.mjs$`).
  *
  * Намеренно НЕ парсимо `target.json` тут (це робить runner). Discovery — швидкий скан структури:
  * шляхи + назви, без I/O вмісту.
  *
- * Історичний контекст: до 1.11.12 існувала dual-mode підтримка `js/` (legacy) і `fix/` (новий),
- * де концерн мав поле `rootDir`. Після переїзду всіх 26 правил у `fix/` (CHANGELOG 1.11.10)
- * legacy-канал прибрано (CHANGELOG 1.11.12) — одне джерело правди.
+ * Історичний контекст: convention пройшла еволюцію `js/` (до 1.11.12) → `fix/` (1.11.10–1.13.79)
+ * → знову `js/` (1.13.80+, після появи кореневого `fix.mjs` як entry-point правила, щоб не плутати
+ * з папкою `fix/`). Convention тепер за технологією: `js/` ↔ `policy/`.
  */
 import { existsSync } from 'node:fs'
 import { readdir } from 'node:fs/promises'
@@ -22,7 +22,7 @@ const TEST_SUFFIX = '.test.mjs'
 
 /**
  * @typedef {object} JsConcern
- * @property {string} name імʼя концерну (`<name>` у `fix/<name>/`)
+ * @property {string} name імʼя концерну (`<name>` у `js/<name>/`)
  * @property {string[]} files імена `check*.mjs` у концерні (відсортовані алфавітно)
  */
 
@@ -39,21 +39,21 @@ const TEST_SUFFIX = '.test.mjs'
  */
 
 /**
- * Перелічує JS-концерни одного правила: підкаталоги `fix/<name>/` з принаймні одним `check*.mjs`.
+ * Перелічує JS-концерни одного правила: підкаталоги `js/<name>/` з принаймні одним `check*.mjs`.
  *
- * `fix/utils/` свідомо пропускається — це хелпери, а не концерни.
- * @param {string} fixDir абсолютний шлях `rules/<id>/fix/`
+ * `js/utils/` свідомо пропускається — це хелпери, а не концерни.
+ * @param {string} jsDir абсолютний шлях `rules/<id>/js/`
  * @returns {Promise<JsConcern[]>} концерни в алфавітному порядку
  */
-async function listJsConcerns(fixDir) {
-  if (!existsSync(fixDir)) return []
-  const topLevel = await readdir(fixDir, { withFileTypes: true })
+async function listJsConcerns(jsDir) {
+  if (!existsSync(jsDir)) return []
+  const topLevel = await readdir(jsDir, { withFileTypes: true })
 
   /** @type {JsConcern[]} */
   const concerns = []
   for (const entry of topLevel) {
     if (!entry.isDirectory() || entry.name === 'utils' || entry.name.startsWith('.')) continue
-    const concernDir = join(fixDir, entry.name)
+    const concernDir = join(jsDir, entry.name)
     const dirContents = await readdir(concernDir)
     const files = dirContents
       .filter(n => CHECK_FILENAME_RE.test(n) && !n.endsWith(TEST_SUFFIX))
@@ -86,7 +86,20 @@ async function listPolicyConcerns(policyDir) {
 }
 
 /**
- * Сканує `rules/` і повертає правила, для яких є JS-концерни (у `fix/`) або policy-концерни
+ * Будує `CheckableRule` для одного каталогу правила (без enumeration по `rules/`).
+ * Використовується `runStandardRule` для per-rule entry-point flow.
+ * @param {string} ruleDir абсолютний шлях `rules/<id>/`
+ * @param {string} ruleId id правила (= basename(ruleDir))
+ * @returns {Promise<CheckableRule>} опис правила (jsConcerns + policyConcerns)
+ */
+export async function discoverOneRule(ruleDir, ruleId) {
+  const jsConcerns = await listJsConcerns(join(ruleDir, 'js'))
+  const policyConcerns = await listPolicyConcerns(join(ruleDir, 'policy'))
+  return { id: ruleId, jsConcerns, policyConcerns }
+}
+
+/**
+ * Сканує `rules/` і повертає правила, для яких є JS-концерни (у `js/`) або policy-концерни
  * (у `policy/`). Правила без жодної прогонної частини (тільки `.mdc` + `auto.md`) фільтруються.
  * @param {string} bundledRulesDir абсолютний шлях до `npm/rules/`
  * @returns {Promise<CheckableRule[]>} відсортовані за id
@@ -99,10 +112,9 @@ export async function discoverCheckableRules(bundledRulesDir) {
   for (const entry of entries) {
     if (!entry.isDirectory() || entry.name.startsWith('.')) continue
     const ruleDir = join(bundledRulesDir, entry.name)
-    const jsConcerns = await listJsConcerns(join(ruleDir, 'fix'))
-    const policyConcerns = await listPolicyConcerns(join(ruleDir, 'policy'))
-    if (jsConcerns.length > 0 || policyConcerns.length > 0) {
-      out.push({ id: entry.name, jsConcerns, policyConcerns })
+    const rule = await discoverOneRule(ruleDir, entry.name)
+    if (rule.jsConcerns.length > 0 || rule.policyConcerns.length > 0) {
+      out.push(rule)
     }
   }
   return out.toSorted((a, b) => a.id.localeCompare(b.id))

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

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

package/scripts/utils/read-n-cursor-config-lite.mjs

@@ -0,0 +1,59 @@
+/**
+ * Light read-only `.n-cursor.json` reader для standalone `fix.mjs` invocation.
+ *
+ * НЕ робить auto-rules detection, merge, schema sync — це справа повного `readConfig` у CLI.
+ * Тут лише: прочитати файл (якщо є), повернути `{ rules: string[], disableRules: string[] }`.
+ *
+ * Спостереження whitelist:
+ *   - якщо `.n-cursor.json` НЕМАЄ → правило вважається enabled (поведінка "open by default"),
+ *     щоб `bun rules/<id>/fix.mjs` з будь-якої тимчасової директорії працювало для debug.
+ *   - якщо файл є з `rules:[…]`, але правила там немає → правило не enabled.
+ *   - якщо правило в `disable-rules` → не enabled, навіть якщо у `rules:[…]`.
+ */
+import { existsSync } from 'node:fs'
+import { readFile } from 'node:fs/promises'
+import { join } from 'node:path'
+
+const CONFIG_FILE = '.n-cursor.json'
+
+/**
+ * @typedef {object} LiteConfig
+ * @property {boolean} exists чи існує .n-cursor.json у поточному каталозі
+ * @property {string[]} rules id правил з whitelist (порожній якщо файл відсутній)
+ * @property {string[]} disableRules id правил, явно вимкнених у `disable-rules`
+ */
+
+/**
+ * @param {string} [cwd] корінь, у якому шукати .n-cursor.json (default — `process.cwd()`)
+ * @returns {Promise<LiteConfig>} стан конфігу
+ */
+export async function readNCursorConfigLite(cwd = process.cwd()) {
+  const configPath = join(cwd, CONFIG_FILE)
+  if (!existsSync(configPath)) {
+    return { exists: false, rules: [], disableRules: [] }
+  }
+  const raw = await readFile(configPath, 'utf8')
+  /** @type {{ rules?: unknown, ['disable-rules']?: unknown }} */
+  const parsed = JSON.parse(raw)
+  const rules = Array.isArray(parsed.rules) ? parsed.rules.filter(r => typeof r === 'string') : []
+  const disableRules = Array.isArray(parsed['disable-rules'])
+    ? parsed['disable-rules'].filter(r => typeof r === 'string')
+    : []
+  return { exists: true, rules, disableRules }
+}
+
+/**
+ * Чи активне правило згідно з конфігом.
+ *   - файл відсутній → true (open by default для debug);
+ *   - правило явно в `disable-rules` → false;
+ *   - правило у `rules` → true;
+ *   - інакше → false.
+ * @param {LiteConfig} config розпарсений lite-конфіг
+ * @param {string} ruleId id правила (= basename каталогу)
+ * @returns {boolean} чи запускати правило
+ */
+export function isRuleEnabled(config, ruleId) {
+  if (!config.exists) return true
+  if (config.disableRules.includes(ruleId)) return false
+  return config.rules.includes(ruleId)
+}

package/scripts/utils/run-rule-cli.mjs

@@ -0,0 +1,37 @@
+/**
+ * Standalone CLI runner для одного правила. Викликається з `rules/<id>/fix.mjs`
+ * у блоці `if (import.meta.main)` — це робить `bun rules/<id>/fix.mjs` повним
+ * еквівалентом старого `npx @nitra/cursor fix <id>`: читає `.n-cursor.json`,
+ * перевіряє whitelist, друкує summary, повертає aggregated exit-code.
+ *
+ * Library-mode виклик з CLI orchestration — інше: див. `runStandardRule` + `fix.mjs::run(ctx)`.
+ */
+import { basename } from 'node:path'
+
+import { isRuleEnabled, readNCursorConfigLite } from './read-n-cursor-config-lite.mjs'
+import { runStandardRule } from './run-standard-rule.mjs'
+import { getOrCreateWalkCache } from './walk-cache.mjs'
+
+const PACKAGE_NAME = '@nitra/cursor'
+
+/**
+ * @param {string} ruleDir абсолютний шлях до `rules/<id>/`
+ * @returns {Promise<number>} 0 — OK або правило не enabled; 1 — порушення
+ */
+export async function runRuleCli(ruleDir) {
+  const ruleId = basename(ruleDir)
+  const config = await readNCursorConfigLite()
+
+  if (!isRuleEnabled(config, ruleId)) {
+    console.log(`\n🔍 ${PACKAGE_NAME} fix ${ruleId} — правило не в \`.n-cursor.json:rules\`. Пропущено.\n`)
+    return 0
+  }
+
+  console.log(`\n🔍 ${PACKAGE_NAME} fix ${ruleId} — перевірка правила\n`)
+
+  const walkCache = getOrCreateWalkCache()
+  const exitCode = await runStandardRule(ruleDir, { walkCache })
+  const ok = exitCode === 0
+  console.log(`\n✨ Результат: ${ok ? 1 : 0}/1 правил без зауважень\n`)
+  return exitCode
+}

package/scripts/utils/run-rule.mjs

@@ -2,9 +2,9 @@
  * Оркестратор одного правила під CLI `check`.
  *
  * Послідовність (concerns у межах правила — алфавітно):
- *   1. **applies-гейт** з `fix/applies/check.mjs`. Якщо модуль експортує `applies()` і вона повертає
+ *   1. **applies-гейт** з `js/applies/check.mjs`. Якщо модуль експортує `applies()` і вона повертає
  *      false — друкуємо `✅ правило не застосовне` і завершуємо без подальших викликів.
- *   2. **JS-концерни** — кожен `check*.mjs` у `fix/<concern>/`. Concern `applies` теж може мати
+ *   2. **JS-концерни** — кожен `check*.mjs` у `js/<concern>/`. Concern `applies` теж може мати
  *      `check()` для друку контексту (його `applies()` уже відпрацював на кроці 1, він не повторюється).
  *   3. **Policy-концерни** — кожен `policy/<concern>/target.json` через `runConftestBatch`.
  *      Резолвер `resolveTargetFiles` ділить cache (`walkCache`) між концернами.
@@ -24,9 +24,9 @@ import { resolveConcernTemplateData } from './template.mjs'
 const APPLIES_CONCERN_NAME = 'applies'
 
 /**
- * Обчислює абсолютний шлях до файла-check у JS-концерні: `rules/<id>/fix/<concern>/<file>`.
- * Legacy `js/` корінь і поле `concern.rootDir` прибрані у 1.11.12 — усі правила переїхали
- * у `fix/` ще у 1.11.10.
+ * Обчислює абсолютний шлях до файла-check у JS-концерні: `rules/<id>/js/<concern>/<file>`.
+ * Convention `js/` (за технологією) повернулась у 1.13.80 після короткої епохи `fix/`
+ * (1.11.10–1.13.79) — щоб не плутати з кореневим `fix.mjs` entry-point'ом.
  * @param {string} bundledRulesDir абсолютний `rules/`
  * @param {string} ruleId id правила
  * @param {import('./discover-checkable-rules.mjs').JsConcern} concern опис концерну
@@ -34,11 +34,11 @@ const APPLIES_CONCERN_NAME = 'applies'
  * @returns {string} абсолютний шлях
  */
 function resolveJsCheckPath(bundledRulesDir, ruleId, concern, fileName) {
-  return join(bundledRulesDir, ruleId, 'fix', concern.name, fileName)
+  return join(bundledRulesDir, ruleId, 'js', concern.name, fileName)
 }
 
 /**
- * Спробувати викликати applies() гейт з `fix/applies/check.mjs` правила.
+ * Спробувати викликати applies() гейт з `js/applies/check.mjs` правила.
  * Гейт активний лише за наявності концерну з імʼям `applies` і експортом-функцією `applies` у його
  * першому check-файлі (алфавіт).
  * @param {string} bundledRulesDir абсолютний `rules/`

package/scripts/utils/run-standard-rule.mjs

@@ -0,0 +1,34 @@
+/**
+ * Public API per-rule orchestration. Викликається з `rules/<id>/fix.mjs`.
+ *
+ * Інкапсулює: `discoverOneRule` → `runRule(applies → JS → policy → mdc-refs)`.
+ * Локальна логіка в правилах заборонена; розширення поведінки — через `ctx`-опції.
+ */
+import { basename, dirname } from 'node:path'
+
+import { discoverOneRule } from './discover-checkable-rules.mjs'
+import { runRule } from './run-rule.mjs'
+import { getOrCreateWalkCache } from './walk-cache.mjs'
+
+/**
+ * @typedef {object} RuleContext
+ * @property {Map<string, Promise<string[]>>} [walkCache] FS-walk cache між concerns одного прогону
+ *
+ * Зарезервовано на майбутнє (поки не реалізовано — додається, коли з'явиться потреба):
+ *   - `skipMdcRefs`, `skipApplies`, `onlyConcerns`.
+ * Розширення поведінки правила робиться лише через нові поля тут, не через локальну
+ * логіку в `rules/<id>/fix.mjs`.
+ */
+
+/**
+ * @param {string} ruleDir абсолютний шлях до `rules/<id>/`
+ * @param {RuleContext} [ctx] контекст прогону (walkCache тощо)
+ * @returns {Promise<number>} 0 OK, 1 violations
+ */
+export async function runStandardRule(ruleDir, ctx = {}) {
+  const ruleId = basename(ruleDir)
+  const bundledRulesDir = dirname(ruleDir)
+  const rule = await discoverOneRule(ruleDir, ruleId)
+  const walkCache = ctx.walkCache ?? getOrCreateWalkCache()
+  return runRule(rule, bundledRulesDir, walkCache)
+}

package/scripts/utils/walk-cache.mjs

@@ -0,0 +1,24 @@
+/**
+ * Module-singleton FS-walk cache, спільний для всіх concerns одного `check`-прогону.
+ * Ключі — рядкові glob/regex дескриптори; значення — `Promise<string[]>` зі списком файлів.
+ * Кеш живий у межах одного процесу (Node/Bun module-instance). Тести скидають через `resetWalkCache()`.
+ */
+
+/** @type {Map<string, Promise<string[]>> | null} */
+let cache = null
+
+/**
+ * Повертає поточний cache; lazy-ініціалізує при першому виклику.
+ * @returns {Map<string, Promise<string[]>>} module-singleton walk cache
+ */
+export function getOrCreateWalkCache() {
+  if (cache === null) cache = new Map()
+  return cache
+}
+
+/**
+ * Скидає cache (для тестів між кейсами).
+ */
+export function resetWalkCache() {
+  cache = new Map()
+}

package/scripts/utils/workspaces.mjs

@@ -11,7 +11,7 @@ import { dirname, join, relative } from 'node:path'
 const TRAILING_SLASH_RE = /\/$/
 const LEADING_DOTSLASH_RE = /^\.\//
 
-/** Glob-ігнор для workspace-патернів із `*` (узгоджено з `rules/changelog/fix/consistency/package-manifest.mjs`). */
+/** Glob-ігнор для workspace-патернів із `*` (узгоджено з `rules/changelog/js/consistency/package-manifest.mjs`). */
 export const WORKSPACE_GLOB_IGNORE = Object.freeze(['**/node_modules/**', '**/.git/**', '**/.venv/**', '**/venv/**'])
 
 /**

package/skills/fix/SKILL.md

@@ -8,14 +8,14 @@ description: >-
 
 ## Scope
 
-Цей скіл відповідає **лише за структуру** проєкту: щоб `.cursor/rules/` + `npx @nitra/cursor check` були задоволені (наявність конфігів, залежностей, скриптів, GitHub workflows, відсутність заборонених файлів). **Лінт-порушення у самому коді** (ESLint, oxlint, jscpd, cspell, knip, sonarjs, stylelint тощо) — **поза скоупом**; їх діагностує й виправляє **`/n-lint`** (`bun run lint`). Не запускай `bun run lint` із цього скілу і не намагайся виправляти його порушення тут — це задача `/n-lint`. Якщо `npx @nitra/cursor check` чистий, а `bun run lint` лишився червоним — запусти `/n-lint` окремо.
+Цей скіл відповідає **лише за структуру** проєкту: щоб `.cursor/rules/` + `npx @nitra/cursor fix` були задоволені (наявність конфігів, залежностей, скриптів, GitHub workflows, відсутність заборонених файлів). **Лінт-порушення у самому коді** (ESLint, oxlint, jscpd, cspell, knip, sonarjs, stylelint тощо) — **поза скоупом**; їх діагностує й виправляє **`/n-lint`** (`bun run lint`). Не запускай `bun run lint` із цього скілу і не намагайся виправляти його порушення тут — це задача `/n-lint`. Якщо `npx @nitra/cursor fix` чистий, а `bun run lint` лишився червоним — запусти `/n-lint` окремо.
 
 ## Workflow
 
-1. **Діагностика** — запусти перевірку (за замовчуванням лише правила з `.cursor/rules/*.mdc`, для яких у пакеті є programmatic check; повний набір — явні аргументи: `npx @nitra/cursor check bun ga …`):
+1. **Діагностика** — запусти перевірку (за замовчуванням лише правила з `.cursor/rules/*.mdc`, для яких у пакеті є programmatic check; повний набір — явні аргументи: `npx @nitra/cursor fix bun ga …`):
 
 ```bash
-npx @nitra/cursor check
+npx @nitra/cursor fix
 ```
 
 2. **Аналіз** — зчитай вивід, знайди всі `❌` та визнач які правила порушено
@@ -43,7 +43,7 @@ oxfmt .
 6. **Верифікація** — перевір що все виправлено:
 
 ```bash
-npx @nitra/cursor check
+npx @nitra/cursor fix
 ```
 
-7. **Результат** — всі `❌` від `npx @nitra/cursor check` мають стати `✅`. Якщо залишились `❌` — повтори кроки 3-6. Лінт-помилки від `bun run lint` тут **не виправляй** — вони на скіл `/n-lint`.
+7. **Результат** — всі `❌` від `npx @nitra/cursor fix` мають стати `✅`. Якщо залишились `❌` — повтори кроки 3-6. Лінт-помилки від `bun run lint` тут **не виправляй** — вони на скіл `/n-lint`.

package/skills/lint/SKILL.md

@@ -114,4 +114,4 @@ bun run lint
 
 ## Примітка
 
-Цей скіл **не** замінює **`npx @nitra/cursor check`**: **`lint`** перевіряє лінтери/формат у **`package.json`**, а **`check`** — програмні правила пакета **`@nitra/cursor`**. За потреби запускай обидва.
+Цей скіл **не** замінює **`npx @nitra/cursor fix`**: **`lint`** перевіряє лінтери/формат у **`package.json`**, а **`check`** — програмні правила пакета **`@nitra/cursor`**. За потреби запускай обидва.