@nitra/cursor 3.25.1 → 3.27.0

package/CHANGELOG.md

@@ -1,5 +1,22 @@
 # Changelog
 
+## [3.27.0] - 2026-06-06
+
+### Added
+
+- add fix-t0 CLI command: T0-auto pattern library for n-fix orchestrator (deterministic vscode-ext-add and rm-forbidden-file fixes, 0 LLM tokens)
+- add fix-run: autonomous n-fix orchestrator (convergence-loop fix-t0+LLM, haiku→sonnet escalation, no agent needed)
+
+## [3.26.0] - 2026-06-06
+
+### Added
+
+- Root-guard для всіх деструктивних точок: CLI-команди fix/lint/coverage/change/release + дефолтний sync хардом перевіряють cwd===git-toplevel (assertCwdIsProjectRoot); worktree-preflight підсилено root-assert (pwd vs toplevel); новий meta.json-флаг requireRoot + injectRootNotice для in-place root-only скілів (n-start-check); skillRequiresRoot як явна похідна ознака захисту; валідація requireRoot у npm-module
+
+### Fixed
+
+- n-changelog: directional version-drift — лише version ВПЕРЕД (> опублікованої/git-бази) валить як ручний bump; version ПОЗАДУ (локаль відстала від CI-релізу, ще не git pull) більше не блокує коміт (compareSemverCore/versionIsAhead)
+
 ## [3.25.1] - 2026-06-06
 
 ### Fixed

package/bin/n-cursor.js

@@ -5,14 +5,15 @@
  *
  * Використання:
  *   `npx \@nitra/cursor`             — завантажити cursor-правила
- *   `npx \@nitra/cursor fix`         — перевірити правила з `.cursor/rules/*.mdc`, для яких у пакеті є `fix.mjs`/policy;
+ *   `npx \@nitra/cursor fix`         — автономний оркестратор: T0-auto + LLM (haiku→sonnet); convergence-loop до чистого стану [--max-iter N] [rules]
  *                                     якщо в корені вже є `.n-cursor.json`, спочатку зчитується конфіг і за потреби дописується `$schema`
- *   `npx \@nitra/cursor fix bun`     — перевірити лише вказані правила (ігнорує `.cursor/rules/`)
+ *   `npx \@nitra/cursor fix bun`     — оркестратор лише для вказаних правил; `--json` = check-only (structured output для CI)
  *   `npx \@nitra/cursor rename-yaml-extensions` — k8s `*.yml` → `*.yaml`, `.github` `*.yaml` → `*.yml` (опції: `--dry-run`, `--root=…`; див. bin/rename-yaml-extensions.mjs)
  *   `npx \@nitra/cursor post-tool-use-fix` — точка входу PostToolUse hook Claude Code: читає stdin JSON,
  *                                     дістає `tool_input.file_path`, маршрутизує його у відповідні правила
  *                                     (`*.mjs` → `js-lint`, `*.vue` → `js-lint style-lint vue` тощо) і викликає
  *                                     `fix` лише з ними. Прописується автоматично в `.claude/settings.json`.
+ *   `npx \@nitra/cursor fix`         — автономний оркестратор (meta.json: orchestrator:true): T0-auto → LLM via pi (haiku→sonnet) → check-gate → loop; [--max-iter N] [rules]
  *   `npx \@nitra/cursor lint`        — оркестратор lint-ланцюжка з кореневого `package.json` з вимірюванням часу
  *                                     кожного `lint-*` / `oxfmt` скрипта (fail-fast); канонічна заміна
  *                                     раніше ручного `lint-ga && lint-js && …` агрегатора.
@@ -1596,12 +1597,14 @@ try {
   await ensureNitraCursorInRootDevDependencies(cwd())
   switch (command) {
     case 'fix': {
-      // --json: компактний {total, failed, rules:[{ruleId, ok, output}]} у stdout для скілу n-fix.
-      await runFixCommand(
-        args.filter(a => a !== '--json'),
-        { json: args.includes('--json') }
-      )
-
+      const { runOrchestratorCli } = await import('../skills/fix/js/orchestrator.mjs')
+      process.exitCode = await runOrchestratorCli(args, cwd())
+      break
+    }
+    case '_fix-check': {
+      // Внутрішня команда оркестратора — не є публічним API.
+      // Повертає JSON {total, failed, rules:[{ruleId, ok, output}]} у stdout.
+      await runFixCommand(args, { json: true })
       break
     }
     case 'check': {
@@ -1709,6 +1712,23 @@ try {
 
       break
     }
+    case 'fix-run': {
+      // Backward-compatibility alias → перенаправляємо на `fix`.
+      console.warn(`⚠️  \`fix-run\` deprecated — використовуйте \`fix\``)
+      const { runOrchestratorCli } = await import('../skills/fix/js/orchestrator.mjs')
+      process.exitCode = await runOrchestratorCli(args, cwd())
+      break
+    }
+    case 'fix-t0': {
+      // n-cursor fix-t0 [rule...] — T0-auto рівень n-fix оркестратора.
+      // Запускає fix --json, знаходить violation-output із детермінованим паттерном
+      // (vscode-ext-add, rm-forbidden-file тощо), застосовує програмний фікс (0 LLM),
+      // перевіряє check-gate. Exit 0 = усі T0-паттерни закриті; 1 = є решта для LLM.
+      const { runT0AutoCli } = await import('../skills/fix/js/t0.mjs')
+      process.exitCode = await runT0AutoCli(args, cwd())
+
+      break
+    }
     case 'change': {
       const { runChangeCli } = await import('../rules/release/change.mjs')
       process.exitCode = await runChangeCli(args)
@@ -1780,7 +1800,7 @@ try {
     default: {
       console.error(`❌ Невідома команда: ${command}`)
       console.error(
-        `   Очікується: (без аргументів) синхронізація правил, check, rename-yaml-extensions, post-tool-use-fix, lint, lint-ga, lint-rego, lint-k8s, lint-docker, lint-text, coverage, coverage-fix, taze, start-check, change, release, skill, worktree, lint-ci, flow, trace, graph, docgen`
+        `   Очікується: (без аргументів) синхронізація правил, fix, check, rename-yaml-extensions, post-tool-use-fix, lint, lint-ga, lint-rego, lint-k8s, lint-docker, lint-text, coverage, coverage-fix, taze, start-check, fix-t0, change, release, skill, worktree, lint-ci, flow, trace, graph, docgen`
       )
       process.exitCode = 1
     }

package/package.json

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

package/rules/ga/docs/fix.md

@@ -1,158 +1,25 @@
-# fix.mjs — точка входу правила `ga`
+# fix.mjs
 
 ## Огляд
 
-Файл `npm/rules/ga/fix.mjs` — це **подвійна точка входу** (dual-mode entry-point) для правила з ідентифікатором `ga` (Google Analytics) у проєкті `@nitra/cursor`. Файл реалізує дві ролі одночасно:
+Цей файл запускає процес перевірки наявності та стану необхідних системних ресурсів. Він забезпечує швидку оцінку готовності системи до подальшої роботи, використовуючи кешовані дані для прискорення процесу. Результати перевірки використовуються для прийняття рішень щодо подальших дій.
 
-1. **Library mode** — експортує функцію `run(ctx)`, яку імпортує оркестратор CLI (`bin/cursor.mjs` або інші правила) для запуску прогону у складі сукупної команди (наприклад, `npx @nitra/cursor fix`).
-2. **Standalone mode** — якщо файл запущено напряму через `bun npm/rules/ga/fix.mjs` (або `node ...`), він самостійно ініціалізує CLI-обгортку (`runRuleCli`) і завершує процес із кодом виходу, придатним для CI/IDE.
+## Поведінка
 
-Логіка самого правила інкапсульована в утиліті `runStandardRule`, яка послідовно виконує стандартний пайплайн усіх «standard»-правил репозиторію:
+1.  Ініціалізує контекст прогону.
+2.  Викликає стандартне правило, використовуючи контекст.
+3.  Якщо код виконується як окремий CLI-скрипт, то:
+    1.  Викликає оркестрацію правил.
+    2.  Повертає код завершення процесу.
 
-- **applies** — перевірка, що правило застосовне до поточного workspace/файлів (за патернами з `meta.json`);
-- **JS-concerns** — запуск перевірок (`check-*.mjs`) і авто-фіксерів (`fix-*.mjs`) із підтек `js/`, `lint/`;
-- **policy** — застосування policy-перевірок із підтеки `policy/`;
-- **mdc-refs** — валідація посилань всередині `ga.mdc` (cross-link integrity).
+## Публічний API
 
-Файл свідомо мінімалістичний: він **не містить власної бізнес-логіки**, лише делегує виконання у спільні бібліотеки `scripts/lib/*`. Це гарантує однакову поведінку для всіх правил пакету.
+- run — Запускає стандартне правило, враховуючи контекст та перетворюючи його на JS-коду, політику та посилання на MDC.
+- Library mode — Викликається через CLI-оркестрацію за допомогою імпорту та функції `run`.
 
-## Експорти / API
+## Гарантії поведінки
 
-| Експорт | Тип                               | Опис                                                                                                                               |
-| ------- | --------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------- |
-| `run`   | `function(ctx?): Promise<number>` | Бібліотечний вхід; запускає стандартний пайплайн правила в контексті переданого `ctx`. Повертає exit-code (0 — OK, 1 — порушення). |
-
-Default-експорту немає. Файл не реекспортує жодних інших символів.
-
-## Функції
-
-### `run(ctx)`
-
-Бібліотечний інтерфейс правила. Дозволяє оркестратору CLI або іншим правилам запустити перевірку `ga` без створення нового процесу.
-
-**Сигнатура:**
-
-```js
-export function run(ctx)
-```
-
-**Параметри:**
-
-- `ctx` (`RuleContext`, опційний) — контекст прогону, типізований через JSDoc-імпорт з `../../scripts/lib/run-standard-rule.mjs`. Типово містить:
-  - `walkCache` — кеш обходу файлів (щоб уникнути повторного `readdir` між правилами в одній сесії);
-  - інші поля, передбачені реалізацією `runStandardRule` (репорти, прапорці dry-run тощо).
-
-**Повертає:**
-
-- `Promise<number>` — числовий код виходу:
-  - `0` — правило не знайшло порушень або всі знайдені були автоматично виправлені;
-  - `1` — залишилися порушення, які потребують ручного втручання.
-
-**Side effects:**
-
-- Може читати файли проєкту (через walkCache і внутрішні `check-*.mjs`/`fix-*.mjs`);
-- Може **писати** файли (auto-fix у режимі за замовчуванням; `fix-*.mjs` із підтек `js/`, `lint/`, `policy/`);
-- Може писати в `stdout`/`stderr` (репорти, попередження, summary), залежно від конфігурації `runStandardRule`;
-- Не викликає `process.exit` напряму — повертає код виходу як значення Promise.
-
-**Внутрішня реалізація:**
-
-```js
-return runStandardRule(import.meta.dirname, ctx)
-```
-
-Передає **абсолютний шлях до директорії правила** (`import.meta.dirname` — Node/Bun-нативний спосіб отримати `__dirname` в ESM) і контекст. `runStandardRule` сам визначить ID правила за назвою теки (`ga`), завантажить `meta.json`, `ga.mdc` і виконає пайплайн.
-
-### Standalone-блок (top-level `if`)
-
-Не є експортованою функцією, але є важливою частиною API файлу.
-
-**Логіка:**
-
-```js
-if (isRunAsCli(import.meta.url)) {
-  process.exit(await runRuleCli(import.meta.dirname))
-}
-```
-
-**Поведінка:**
-
-- `isRunAsCli(import.meta.url)` повертає `true`, якщо файл був запущений як основний модуль (а не імпортований). Це Bun/Node-сумісна заміна звичайного для CommonJS `require.main === module`.
-- У такому разі викликається `runRuleCli(import.meta.dirname)` — обгортка, що додає до простого `run(ctx)`:
-  - парсинг аргументів командного рядка (наприклад, `--dry-run`, `--scope`);
-  - завантаження користувацького конфігу (`.cursorrc`, whitelist-файлів);
-  - друк фінального summary з кодом виходу.
-- Результат (`number`) передається у `process.exit(...)`, тож виклик `bun npm/rules/ga/fix.mjs` повертає shell-у точний exit-code для CI/IDE-інтеграції.
-
-**ESLint-винятки** (інлайн-коментар):
-
-- `n/no-process-exit` (плагін `eslint-plugin-n`) і `unicorn/no-process-exit` — обидва зазвичай забороняють `process.exit`, оскільки він обриває async-операції без cleanup. Тут виняток виправданий: це **єдиний standalone entry-point**, який мусить повернути exit-code саме через `process.exit`, інакше CI не зможе розрізнити успіх/провал.
-
-**Top-level `await`:**
-
-- Використовується `await runRuleCli(...)` на верхньому рівні модуля — це валідно для ESM (`.mjs`) у сучасних Node.js (≥14.8) і Bun. Без `await` `process.exit` отримав би `Promise` замість числа.
-
-## Залежності
-
-### Внутрішні (workspace)
-
-| Модуль              | Шлях                                      | Експорти, що використовуються                                       |
-| ------------------- | ----------------------------------------- | ------------------------------------------------------------------- |
-| `run-rule-cli`      | `../../scripts/lib/run-rule-cli.mjs`      | `isRunAsCli`, `runRuleCli`                                          |
-| `run-standard-rule` | `../../scripts/lib/run-standard-rule.mjs` | `runStandardRule`; також імпортується тип `RuleContext` через JSDoc |
-
-Шляхи відносні до `npm/rules/ga/fix.mjs`, тобто `../../scripts/lib/` → `npm/scripts/lib/`.
-
-### Зовнішні / runtime
-
-- **Node.js / Bun ESM API**: `import.meta.url`, `import.meta.dirname` (вимагає Node ≥20.11 або Bun, де `dirname` доступний нативно).
-- **`process`**: глобальний об'єкт (`process.exit`).
-
-Жодних npm-залежностей файл напряму не імпортує — всі стороні пакети підтягуються транзитивно через `scripts/lib/*`.
-
-## Потік виконання / Використання
-
-### Сценарій 1: запуск через `@nitra/cursor` (library mode)
-
-1. Користувач виконує `npx @nitra/cursor fix ga` або `npx @nitra/cursor fix` (усі правила).
-2. CLI-бінарник пакету (`bin/cursor.mjs` або аналог) динамічно імпортує `npm/rules/ga/fix.mjs`.
-3. Оскільки модуль імпортовано (а не запущено), `isRunAsCli(import.meta.url)` → `false`, standalone-блок не виконується.
-4. CLI викликає експортовану `run(ctx)` із заздалегідь підготованим контекстом (`walkCache`, прапорці).
-5. `run` повертає `Promise<number>` — CLI агрегує його з результатами інших правил у фінальний exit-code.
-
-### Сценарій 2: прямий запуск файлу (standalone)
-
-1. Розробник або CI виконує `bun npm/rules/ga/fix.mjs` (зручно для дебагу одного правила).
-2. Модуль завантажується як основний; `isRunAsCli(import.meta.url)` → `true`.
-3. Виконується `await runRuleCli(import.meta.dirname)`:
-   - парсяться CLI-аргументи;
-   - завантажується конфіг/whitelist;
-   - всередині також викликається `runStandardRule` (так само як у library-режимі), але з повним «end-to-end» обрамленням;
-   - виводиться summary.
-4. `process.exit(<code>)` завершує процес із отриманим exit-code (0/1).
-
-### Стандартний пайплайн `runStandardRule` (у обох сценаріях)
-
-Послідовність (детальніше — в документації `runStandardRule`):
-
-1. **applies** — `meta.json` визначає, чи треба запускати правило в поточному workspace; якщо ні — ранній вихід з кодом 0.
-2. **JS-concerns** — обходяться підтеки правила (`js/`, `lint/`), виконуються пари `check-*.mjs` + `fix-*.mjs`. Якщо `check` повернув порушення, відповідний `fix` пробує їх прибрати.
-3. **policy** — з підтеки `policy/` запускаються policy-чекери (зазвичай це декларативні правила, без auto-fix або з обмеженим fix).
-4. **mdc-refs** — валідація, що в `ga.mdc` (markdown-документ із описом правила) посилання на `js/`, `lint/`, `policy/` коректні (немає «битих» референсів).
-5. Агрегується фінальний exit-code: `0`, якщо всі стадії чисті; `1` — інакше.
-
-### Як додати/змінити поведінку правила `ga`
-
-Файл `fix.mjs` змінювати **не треба** — він універсальний. Щоб модифікувати поведінку правила:
-
-- додайте/змініть `check-*.mjs` і `fix-*.mjs` у підтеках `js/`, `lint/` теки `ga/`;
-- оновіть `policy/`-чекери для декларативних обмежень;
-- актуалізуйте `ga.mdc` (опис для людини/LLM) і `meta.json` (applies, scope, прапорці);
-- запустіть `bun npm/rules/ga/fix.mjs` для локальної перевірки.
-
-### Обмеження та інваріанти
-
-- Файл **повинен** залишатися мінімалістичним — будь-яка бізнес-логіка в `fix.mjs` правила вважається порушенням архітектури «standard rule» (див. `n-ci4.mdc`).
-- Не можна вилучати `if (isRunAsCli(...))`-блок: інакше прямий запуск файлу не поверне CI exit-code.
-- Не можна замінювати `process.exit` на `return` у standalone-блоці: top-level `return` у ESM-модулі недопустимий, а без `process.exit` процес не отримає правильний код.
-- ESLint-винятки (`n/no-process-exit`, `unicorn/no-process-exit`) застосовуються **лише** до рядка з `process.exit` — їх не слід розширювати на інші місця.
+*   Запускає процес.
+*   Кеш зберігає результати попередніх прогонів.
+*   Результат залежить від попередніх прогонів.
+*   Немає взаємодії з мережею.

package/rules/ga/js/docs/lint.md

@@ -1,100 +1,19 @@
-# `npm/rules/ga/js/lint.mjs`
+# lint.mjs
 
 ## Огляд
 
-Файл `lint.mjs` у теці `npm/rules/ga/js/` є тонкою адаптерною ланкою (CI-кроком) правила `ga` (GitHub Actions). Він не реалізує жодної самостійної логіки лінтингу — натомість делегує виклик у канонічну CLI-обгортку правила, яка живе у сусідньому модулі `npm/rules/ga/lint/lint.mjs` (експортує `runLintGaCli`).
+Файл `lint` делегує перевірку коду інструменту, який запускається з командного рядка. Він використовується для автоматизованої перевірки коду на відповідність певним правилам. Це забезпечує консистентність та якість коду в проєкті.
 
-Призначення модуля — надати уніфікований lint-entry для правила `ga`, який відповідає інтерфейсному контракту «JS-частини правила» (експорт `async function lint(files)`), і одночасно явно зафіксувати, що правило `ga` працює **тільки в whole-repo режимі**: per-file-аналіз не підтримується, а вхідний аргумент `files` ігнорується.
+## Поведінка
 
-Контекст:
+1.  Запускає наявний CLI для перевірки правил.
+2.  Проводить аналіз всього репозиторію, ігноруючи вказаний список файлів.
+3.  Повертає код завершення процесу.
+4.  Не використовує кеш результатів.
+5.  Не здійснює взаємодії з мережею.
 
-- Правило `ga` перевіряє конфіги GitHub Actions (`.github/workflows/*.{yml,yaml}`) — як через Rego (conftest), так і через JS cross-file-перевірки в `npm/rules/ga/js/workflows.mjs`.
-- Канонічний CLI правила (`runLintGaCli`) у `npm/rules/ga/lint/lint.mjs` додатково запускає preflight для зовнішніх інструментів (`shellcheck`, `conftest`, `uv`/`uvx`), а потім послідовно — `bunx github-actionlint`, `uvx zizmor --offline --collect=workflows .` і делегує далі.
-- Сам адаптер `npm/rules/ga/js/lint.mjs` лише викликає цей CLI і повертає його exit code.
+## Гарантії поведінки
 
-## Експорти / API
-
-Модуль є ES-модулем (`.mjs`) з одним публічним експортом.
-
-| Експорт | Тип                                                    | Призначення                                                                                                               |
-| ------- | ------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------- |
-| `lint`  | `async function (files?: string[]) => Promise<number>` | CI-крок (whole-repo lint) для правила `ga`. Параметр `files` ігнорується. Повертає exit code від канонічного CLI правила. |
-
-Інших експортів (`default`, named) у файлі немає.
-
-## Функції
-
-### `lint(_files)`
-
-Єдина функція файлу. Адаптер навколо `runLintGaCli`.
-
-- **Сигнатура:**
-  ```
-  async function lint(_files: string[] | undefined): Promise<number>
-  ```
-- **Параметри:**
-  - `_files` — `string[] | undefined`. **Ігнорується.** Префікс `_` у назві параметра — конвенційний маркер «не використовується». Документація в JSDoc явно вказує: «whole-repo аналіз», per-file режиму немає. Аргумент усе одно приймається, щоб задовольнити загальний контракт «JS-частини правила» (інші правила можуть мати per-file lint, який отримує список змінених файлів).
-- **Повертає:** `Promise<number>` — exit code, отриманий від `runLintGaCli()`. Семантика стандартна для CLI: `0` — успіх, ненульове — помилка/порушення.
-- **Виключення:** функція сама не кидає винятків і не обгортає `runLintGaCli` у `try/catch`. Будь-яка нерозвʼязана `Promise` чи синхронний `throw` всередині `runLintGaCli` пробʼється назовні без модифікації.
-- **Side effects:** прямих side effects сам адаптер не виконує. Усі side effects (preflight installs через `ensureTool`, запуск зовнішніх процесів `bunx github-actionlint`, `uvx zizmor`, `conftest`, друк у stdout/stderr, можливі мутації CWD) — на стороні `runLintGaCli` та модулів, до яких він делегує далі (`rules/ga/fix.mjs::check()`, Rego-полісі `npm/policy/ga/`, JS-перевірки `workflows.mjs`).
-
-## Залежності
-
-### Імпорти
-
-| Імпорт         | Шлях                 | Тип                                                                          | Призначення                                                                                                           |
-| -------------- | -------------------- | ---------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------- |
-| `runLintGaCli` | `'../lint/lint.mjs'` | Іменований імпорт із сусіднього модуля (відносний шлях у межах правила `ga`) | Канонічний CLI правила `ga`: робить preflight, виконує `actionlint`, `zizmor`, делегує в `rules/ga/fix.mjs::check()`. |
-
-Інших імпортів немає — ані вбудованих модулів Node, ані сторонніх npm-пакетів.
-
-### Транзитивні залежності (інформативно)
-
-Через `runLintGaCli` адаптер опосередковано залежить від:
-
-- `node:process` (платформа);
-- внутрішніх хелперів `npm/scripts/lib/`: `ensureTool`, `runLintStep`, `runStandardLint`;
-- утиліти `npm/scripts/utils/resolve-cmd.mjs`;
-- JS-перевірок правила `ga` у `npm/rules/ga/js/workflows.mjs` (експорт `check`);
-- Rego-полісі `npm/policy/ga/` (через `runConftestBatch` у `rules/ga/fix.mjs`);
-- зовнішніх бінарників: `bunx`, `github-actionlint`, `shellcheck`, `uv`/`uvx`, `zizmor`, `conftest`.
-
-Прямого знання про ці транзитивні залежності адаптер не має — для нього існує тільки контракт «`runLintGaCli` повертає `Promise<number>` з exit code».
-
-## Потік виконання / Використання
-
-### Внутрішній потік
-
-1. Викликається `lint(_files)`.
-2. Параметр `_files` приймається й ігнорується (whole-repo режим).
-3. Викликається `runLintGaCli()` без аргументів.
-4. Результат (`Promise<number>`) повертається безпосередньо викликачу через `return runLintGaCli()`. Жодного `await` тут немає — функція позначена `async`, тому повернутий проміс автоматично «розтекстується» у проміс async-функції; виклик семантично еквівалентний `return await runLintGaCli()`.
-
-### Як використовується
-
-Модуль є JS-точкою входу правила `ga` для уніфікованих lint-pipelin-ів проєкту. Типові викликачі:
-
-- **Загальний lint-оркестратор** (наприклад, кореневий `bun run lint` або `npx @nitra/cursor lint`), який обходить активні правила й для кожного, що має JS-частину, викликає експортовану функцію `lint`. Передає список файлів (зі staged/змінених) — для правила `ga` цей список буде проігноровано.
-- **CI workflows** — через ту саму lint-команду, але з повним списком файлів репо або без нього.
-
-Те, що адаптер ігнорує `files`, — свідома архітектурна декларація: лінт `ga` не вміє швидко перевіряти одинокі workflow-файли, бо правила `ga.mdc` мають cross-file семантику (узгодженість назв джоб, повторювані workflows, спільний `workflow_common` тощо), плюс зовнішні інструменти (`actionlint`, `zizmor`) самі обходять директорію `.github/workflows/` цілком.
-
-### Звʼязок з канонічним CLI
-
-Існує **дві** окремі точки входу до лінтингу правила `ga`:
-
-1. `bin/n-cursor.js` → підкоманда `lint-ga` → `runLintGaCli` напряму (CLI-користувач, дзвонить руками або в скриптах).
-2. Загальний lint pipeline → `npm/rules/ga/js/lint.mjs::lint(files)` → `runLintGaCli` (програмний шлях для обхідника правил).
-
-Обидві дороги ведуть у одну й ту саму функцію `runLintGaCli`, що гарантує ідентичну поведінку, exit code і побічні ефекти незалежно від точки входу.
-
-### Контракт повернення
-
-- Викликач має право трактувати результат як стандартний POSIX exit code: `0` — лінт пройшов, інше — є порушення або інфраструктурна помилка (наприклад, відсутній `uv` без можливості auto-install).
-- Адаптер не нормалізує код помилки й не маскує його — якщо `runLintGaCli` повернув `2`, `lint` поверне `2`.
-
-### Обмеження та крайні випадки
-
-- **Per-file режиму немає.** Передача `files` нічого не змінює; для оптимізації CI краще запускати правило `ga` тільки коли реально змінилися файли в `.github/workflows/` (це — рішення викликача, а не адаптера).
-- **Жодного захисту від конкурентного запуску** на рівні цього адаптера: серіалізація важких CLI-команд (по конвенції `scripts.mdc`) реалізована всередині `runLintGaCli` через `runStandardLint`.
-- **Жодного preflight тут не виконується** — увесь preflight (ensureTool для `shellcheck`/`conftest`, перевірка `uv`) живе всередині `runLintGaCli`.
+*   Делегує правила до існуючого CLI.
+*   Не враховує `files` в режимі per-file.
+*   Не має кешування.