@nitra/cursor 3.27.0 → 3.28.0
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 +11 -0
- package/package.json +1 -1
- package/rules/abie/js/applies.mjs +1 -5
- package/rules/abie/js/env_dns.mjs +1 -9
- package/rules/abie/js/firebase_hosting.mjs +1 -5
- package/rules/abie/js/hc_pairing.mjs +1 -8
- package/rules/abie/js/ua_http_route.mjs +1 -10
- package/rules/abie/js/ua_node_selector.mjs +1 -8
- package/rules/adr/js/hooks.mjs +1 -20
- package/rules/bun/js/layout.mjs +1 -19
- package/rules/capacitor/js/platforms.mjs +1 -23
- package/rules/changelog/js/consistency.mjs +1 -29
- package/rules/ci4/js/marksman_config.mjs +1 -19
- package/rules/docker/js/lint.mjs +1 -34
- package/rules/ga/docs/fix.md +4 -4
- package/rules/ga/js/docs/lint.md +3 -3
- package/rules/ga/js/docs/workflows.md +14 -14
- package/rules/ga/js/workflows.mjs +1 -16
- package/rules/ga/lint/docs/lint.md +9 -9
- package/rules/graphql/js/tooling.mjs +1 -9
- package/rules/hasura/js/internal_urls.mjs +1 -24
- package/rules/image-avif/js/avif_generation.mjs +1 -27
- package/rules/image-compress/js/package_setup.mjs +1 -18
- package/rules/js-bun-db/js/safety.mjs +1 -31
- package/rules/js-bun-redis/js/imports.mjs +1 -12
- package/rules/js-lint/js/docs/lint-findings.md +30 -0
- package/rules/js-lint/js/lint-findings.mjs +1 -7
- package/rules/js-lint/js/lint.mjs +1 -10
- package/rules/js-lint/js/tooling.mjs +1 -13
- package/rules/js-lint/js/utils_imports.mjs +1 -18
- package/rules/js-lint-ci/js/lint.mjs +1 -6
- package/rules/js-mssql/js/deps.mjs +1 -10
- package/rules/js-run/js/runtime.mjs +1 -37
- package/rules/js-run/lib/docs/temporal-scan.md +25 -0
- package/rules/k8s/js/manifests.mjs +1 -137
- package/rules/nginx-default-tpl/js/template.mjs +1 -18
- package/rules/npm-module/js/docs/header_doc_pointer.md +25 -0
- package/rules/npm-module/js/header_doc_pointer.mjs +82 -0
- package/rules/npm-module/js/package_structure.mjs +1 -28
- package/rules/npm-module/js/rule_meta.mjs +1 -10
- package/rules/npm-module/js/skill_meta.mjs +1 -13
- package/rules/php/js/tooling.mjs +1 -11
- package/rules/python/js/applies.mjs +1 -8
- package/rules/python/js/tooling.mjs +1 -21
- package/rules/rego/js/applies.mjs +1 -11
- package/rules/rust/js/applies.mjs +1 -7
- package/rules/security/js/sample_secret.mjs +1 -28
- package/rules/security/js/trufflehog.mjs +1 -8
- package/rules/style-lint/js/lint.mjs +1 -5
- package/rules/style-lint/js/tooling.mjs +1 -19
- package/rules/tauri/js/cargo_mutants_config.mjs +1 -20
- package/rules/tauri/js/tooling.mjs +1 -21
- package/rules/test/js/cargo_mutants_config.mjs +1 -12
- package/rules/test/js/location.mjs +1 -9
- package/rules/test/js/no-process-chdir.mjs +1 -21
- package/rules/test/js/no-relative-fs-path.mjs +1 -23
- package/rules/test/js/stryker_config.mjs +4 -25
- package/rules/test/js/vitest-config-pool-forks.mjs +1 -17
- package/rules/text/js/forbidden-prettier.mjs +1 -10
- package/rules/text/js/formatting.mjs +1 -31
- package/rules/vue/js/packages.mjs +1 -24
- package/scripts/docs/coverage-fix-extract.md +32 -0
- package/scripts/docs/lint-cli.md +25 -0
- package/scripts/docs/post-tool-use-fix.md +27 -0
- package/scripts/docs/rename-yaml-extensions.md +36 -0
- package/scripts/docs/skills-cli.md +35 -0
- package/scripts/docs/sync-claude-config.md +52 -0
- package/scripts/docs/sync-setup-bun-deps-action.md +26 -0
- package/scripts/docs/upgrade-nitra-cursor-and-install.md +29 -0
- package/scripts/docs/worktree-cli.md +46 -0
- package/scripts/lib/docs/assert-project-root.md +28 -0
- package/scripts/lib/docs/diff-added-lines.md +34 -0
- package/scripts/lib/docs/read-n-cursor-config-lite.md +28 -0
- package/scripts/lib/docs/resolve-target-files.md +34 -0
- package/scripts/lib/docs/root-notice.md +28 -0
- package/scripts/lib/docs/rule-meta-helpers.md +34 -0
- package/scripts/lib/docs/rule-meta.md +34 -0
- package/scripts/lib/docs/rule-predicates.md +30 -0
- package/scripts/lib/docs/run-conftest-batch.md +26 -0
- package/scripts/lib/docs/run-lint-step.md +25 -0
- package/scripts/lib/docs/run-rule-cli.md +27 -0
- package/scripts/lib/docs/run-rule.md +32 -0
- package/scripts/lib/docs/run-standard-lint.md +22 -0
- package/scripts/lib/docs/run-standard-rule.md +24 -0
- package/scripts/lib/docs/skill-meta.md +31 -0
- package/scripts/lib/docs/sync-gitignore-worktree.md +31 -0
- package/scripts/lib/docs/template.md +40 -0
- package/scripts/lib/docs/timing-summary.md +24 -0
- package/scripts/lib/docs/workspaces.md +30 -0
- package/scripts/lib/docs/worktree-notice.md +27 -0
- package/scripts/lib/docs/worktree.md +38 -0
- package/scripts/utils/docs/ast-scan-utils.md +50 -0
- package/scripts/utils/docs/ensure-gitignore-entries.md +28 -0
- package/scripts/utils/docs/find-package-json-paths.md +26 -0
- package/scripts/utils/docs/lock-cache-dir.md +25 -0
- package/scripts/utils/docs/pass.md +25 -0
- package/scripts/utils/docs/resolve-cargo-manifest.md +23 -0
- package/scripts/utils/docs/resolve-cmd.md +29 -0
- package/scripts/utils/docs/resolve-js-root.md +25 -0
- package/scripts/utils/docs/test-helpers.md +36 -0
- package/scripts/utils/docs/walk-cache.md +27 -0
- package/scripts/utils/docs/walkDir.md +32 -0
- package/scripts/utils/docs/with-lock.md +25 -0
- package/scripts/utils/docs/worktree-fingerprint.md +27 -0
- package/skills/docgen/js/docgen-batch.mjs +95 -0
- package/skills/docgen/js/docgen-extract.mjs +33 -18
- package/skills/docgen/js/docgen-gen.mjs +125 -98
- package/skills/docgen/js/docgen-ignore.mjs +1 -6
- package/skills/docgen/js/docgen-prompts.mjs +33 -22
- package/skills/docgen/js/docgen-scan.mjs +1 -8
- package/skills/docgen/js/docs/docgen-extract.md +28 -0
- package/skills/docgen/js/docs/docgen-gen.md +41 -0
- package/skills/docgen/js/docs/docgen-ignore.md +24 -0
- package/skills/docgen/js/docs/docgen-prompts.md +24 -0
- package/skills/docgen/js/docs/docgen-scan.md +48 -0
- package/skills/fix/js/docs/llm-worker.md +27 -0
- package/skills/fix/js/docs/orchestrator.md +32 -0
- package/skills/fix/js/docs/t0.md +29 -0
- package/skills/fix/js/llm-worker.mjs +64 -29
- package/skills/fix/js/orchestrator.mjs +45 -54
- package/skills/fix/js/t0.mjs +16 -32
- package/skills/start-check/js/check.mjs +1 -16
- package/skills/start-check/js/docs/check.md +34 -0
- package/skills/taze/js/diff.mjs +1 -15
- package/skills/taze/js/docs/diff.md +33 -0
|
@@ -0,0 +1,28 @@
|
|
|
1
|
+
# docgen-extract.mjs
|
|
2
|
+
|
|
3
|
+
## Огляд
|
|
4
|
+
|
|
5
|
+
Файл `extractFacts` витягує інформацію про поведінку коду, формуючи об'єкт "факт-лист". Цей факт-лист використовується Stage 1 docgen-конвеєра для створення точкових промптів. Функція є ключовою частиною детермінованого процесу генерації документації, виключаючи використання великих мовних моделей.
|
|
6
|
+
|
|
7
|
+
## Поведінка
|
|
8
|
+
|
|
9
|
+
1. **Обробка даних:** Система аналізує код, витягуючи інформацію про експортовані функції, імпорти та їхні описи.
|
|
10
|
+
2. **Ідентифікація відхилень:** Система визначає, чи використовується код для виконання операцій, які можуть призвести до помилок, наприклад, запис у файли, створення директорій, видалення файлів, обробка мережевих запитів або використання try/catch блоків.
|
|
11
|
+
3. **Виявлення пропущених шляхів:** Система виявляє, чи використовується код для обробки певних шляхів файлів, таких як `.github`, `.git`, `node_modules` або `base/`, `ua/`, `.firebase`.
|
|
12
|
+
4. **Визначення кешування:** Система визначає, чи використовується код для кешування даних, наприклад, за допомогою Map або Cache.
|
|
13
|
+
5. **Визначення відсутності обробки помилок:** Система визначає, чи використовується код для обробки помилок, наприклад, за допомогою try/catch блоків.
|
|
14
|
+
6. **Визначення мережевих операцій:** Система визначає, чи використовується код для виконання мережевих операцій, наприклад, за допомогою fetch або axios.
|
|
15
|
+
7. **Вихідні дані:** Система надає вихідні дані у вигляді об'єкта, що містить витягнуту інформацію про код, а також виявлені відхилення та пропущені шляхи.
|
|
16
|
+
|
|
17
|
+
## Публічний API
|
|
18
|
+
|
|
19
|
+
extractFacts — Витягує факти з коду файлу, представляючи їх у вигляді списку.
|
|
20
|
+
|
|
21
|
+
## Гарантії поведінки
|
|
22
|
+
|
|
23
|
+
- Екстрагує з коду список фактів.
|
|
24
|
+
- Повертає об'єкт з витягнутими фактами.
|
|
25
|
+
- Не викликає винятків при невдачі.
|
|
26
|
+
- Кешує результати для одного прогону.
|
|
27
|
+
- Не використовує мережу.
|
|
28
|
+
- Не обробляє файли/каталоги .github, .git, node_modules, base/, ua/, .firebase.
|
|
@@ -0,0 +1,41 @@
|
|
|
1
|
+
# docgen-gen.mjs
|
|
2
|
+
|
|
3
|
+
## Огляд
|
|
4
|
+
|
|
5
|
+
Цей файл генерує документацію на основі коду, використовуючи конвеєр обробки. Він автоматично створює Markdown-файли, що містять опис коду, використовуючи декілька етапів, включаючи вилучення фактів та створення текстових описів. Ця функція є ключовою частиною системи документування, забезпечуючи автоматизований та послідовний процес створення документації.
|
|
6
|
+
|
|
7
|
+
## Поведінка
|
|
8
|
+
|
|
9
|
+
1. Модуль визначає основну функцію `generateDoc`, яка приймає код джерела та налаштовує параметри для генерації документації.
|
|
10
|
+
2. Вхідний код обробляється для вилучення ключових фактів про функціональність модуля, включаючи назви функцій та їх призначення.
|
|
11
|
+
3. Вилучені факти використовуються для оцінки якості документації, зокрема, перевіряється, чи опис відповідає реальній поведінці модуля.
|
|
12
|
+
4. Оцінка якості здійснюється за допомогою декількох критеріїв: опис має бути чітким та описовим, а поведінка – узгодженою з кодом.
|
|
13
|
+
5. Якщо оцінка якості низька, використовується хмарний сервіс Claude для перевірки документації та надання рекомендацій щодо покращення.
|
|
14
|
+
6. У випадку, коли оцінка якості висока, генерується документ, який містить огляд модуля, його поведінку, API та гарантії поведінки.
|
|
15
|
+
7. Документація форматується у Markdown, з використанням фіксованого набору заголовків та розділів.
|
|
16
|
+
8. Під час генерації документації враховуються можливі пропуски в інформації про шляхи, що може вплинути на оцінку якості.
|
|
17
|
+
9. Використовується хмарний сервіс Claude для оцінки якості документації та надання рекомендацій щодо покращення.
|
|
18
|
+
10. Генерується документ, який містить огляд модуля, його поведінку, API та гарантії поведінки.
|
|
19
|
+
|
|
20
|
+
## Публічний API
|
|
21
|
+
|
|
22
|
+
- generateDoc — Генерує документацію з файлу, включаючи метадані, токени, оцінки, проблеми та рівень.
|
|
23
|
+
- Routing (sym-threshold) — Розподіляє обробку на основі значення символу, визначаючи рівень (Tier) та тип рефері (Haiku або без хмарного рефері).
|
|
24
|
+
- sym < BORDERLINE_SYM_LOW — Tier 1 без хмарного рефері.
|
|
25
|
+
- sym ∈ [BORDERLINE_SYM_LOW, symThreshold) — Tier 1 з хмарним рефері (Haiku).
|
|
26
|
+
- sym >= symThreshold — Відразу Tier 2.
|
|
27
|
+
- scoreCloud=true — Автоматично запускає хмарний рефері для всіх Tier 1.
|
|
28
|
+
|
|
29
|
+
## Гарантії поведінки
|
|
30
|
+
|
|
31
|
+
- Конвеєр завжди генерує .md-документацію на основі вхідного коду.
|
|
32
|
+
- Конвеєр використовує інверсію керування, де JS-код визначає весь процес.
|
|
33
|
+
- Stage 0 (extractFacts) не впливає на вихідну документацію.
|
|
34
|
+
- Stage 1 (sectionInstructions) генерує точкові промпти для кожної секції коду.
|
|
35
|
+
- Stage 2 (stripSignatures) завжди видаляє інформацію про сигнатури.
|
|
36
|
+
- Stage 2.5 (scoreDoc) оцінює документацію за фактами.
|
|
37
|
+
- Stage 3 (assemble) збирає документацію з фіксованими заголовками та порядком.
|
|
38
|
+
- При низькому балі скорингу (claudeOneShot) використовується хмарний сервіс для перефразування.
|
|
39
|
+
- При сим-значенні нижче BORDERLINE_SYM_LOW, документація генерується локально без використання хмарного рефері.
|
|
40
|
+
- При сим-значенні між BORDERLINE_SYM_LOW та DEFAULT_SYM_THRESHOLD, документація генерується локально та оцінюється за допомогою cloudScoreDoc (Haiku).
|
|
41
|
+
- При сим-значенні, що перевищує DEFAULT_SYM_THRESHOLD, документація генерується безпосередньо, без локальної оцінки
|
|
@@ -0,0 +1,24 @@
|
|
|
1
|
+
# docgen-ignore.mjs
|
|
2
|
+
|
|
3
|
+
## Огляд
|
|
4
|
+
|
|
5
|
+
Цей файл містить список глобальних файлів, які `docgen` ігнорує під час генерації документації. Він використовується для визначення, які файли не потрібно аналізувати, забезпечуючи ефективність процесу генерації та запобігаючи включенню нерелевантної інформації. Цей список є основою для predicate, який scanner використовує для визначення, чи потрібно читати певний файл.
|
|
6
|
+
|
|
7
|
+
## Поведінка
|
|
8
|
+
|
|
9
|
+
DOCGEN_IGNORE_GLOBS: визначає список глобів, які `docgen` ігнорує.
|
|
10
|
+
isDocgenIgnored: перевіряє, чи шлях має бути пропущений `docgen`, використовуючи глоби.
|
|
11
|
+
|
|
12
|
+
## Публічний API
|
|
13
|
+
|
|
14
|
+
- DOCGEN_IGNORE_GLOBS — Список glob-ів, які ігнорує `docgen`.
|
|
15
|
+
- isDocgenIgnored — Перевіряє, чи потрібно пропустити шлях під час генерації документації.
|
|
16
|
+
|
|
17
|
+
## Гарантії поведінки
|
|
18
|
+
|
|
19
|
+
- `DOCGEN_IGNORE_GLOBS` завжди ігнорує певний набір шляхів.
|
|
20
|
+
- `isDocgenIgnored` повертає `true` якщо шлях ігнорується.
|
|
21
|
+
- Шляхи `.git` та `node_modules` завжди ігноруються.
|
|
22
|
+
- Файл є read-only.
|
|
23
|
+
- У разі невдачі повертає `false` або `null`.
|
|
24
|
+
- Результат прогону кешується для подальшого використання.
|
|
@@ -0,0 +1,24 @@
|
|
|
1
|
+
# docgen-prompts.mjs
|
|
2
|
+
|
|
3
|
+
## Огляд
|
|
4
|
+
|
|
5
|
+
Цей файл містить опис коду для конвеєра docgen. Він визначає точкові промпти для кожної секції коду, що генерується. Це дозволяє ефективно генерувати документацію на основі коду.
|
|
6
|
+
|
|
7
|
+
## Поведінка
|
|
8
|
+
|
|
9
|
+
Напиши вміст секції «Поведінка»: для кожної публічної функції — один короткий пункт «що вона робить». Якщо у фактах є свідомі пропуски шляхів — згадай їх там, де доречно (не вигадуй інших «не перевіряє»). НЕ пиши аргументи функцій у дужках, без regex. Без заголовка.
|
|
10
|
+
|
|
11
|
+
## Публічний API
|
|
12
|
+
|
|
13
|
+
- STYLE — Підготовка документації на першому етапі генерації: створення факт-листа та коду, а потім генерація точкових промптів для кожної секції.
|
|
14
|
+
- v2 — Мінімальний контекст секції: код розміщується лише в `Поведінку`. `Огляд` містить лише заголовок, `API` – список експортів, `Гарантії` – маркери. Це дозволяє один раз обробити інсульт коду, а не секцію за секцією.
|
|
15
|
+
- sectionMessages — Набори повідомлень для кожної секції з мінімальним контекстом. Код розміщується лише в `Поведінку`, решта – на факт-листи.
|
|
16
|
+
- oneShotMessages — База повідомлень для порівняння.
|
|
17
|
+
- oneShotPromptText — Текст user-промпту для one-shot (для резервного копіювання в хмарі через Anthropic SDK).
|
|
18
|
+
|
|
19
|
+
## Гарантії поведінки
|
|
20
|
+
|
|
21
|
+
- `docgen-конвеєр` кешує результати генерації промптів для кожної секції.
|
|
22
|
+
- `Огляд` містить лише заголовок секції.
|
|
23
|
+
- `API` містить лише список експортів секції.
|
|
24
|
+
- `Гарантії` містять лише маркери.
|
|
@@ -0,0 +1,48 @@
|
|
|
1
|
+
# docgen-scan.mjs
|
|
2
|
+
|
|
3
|
+
## Огляд
|
|
4
|
+
|
|
5
|
+
`docgen scanner` обходить проєкт, щоб створити JSON-список кодових файлів, розташованих у теці `docs/` поряд із джерелом. Цей список використовується іншими скілами для генерації документації. Інструмент забезпечує детермінований обхід проєкту та відстежує наявність файлів, не використовуючи мережеві ресурси чи LLM.
|
|
6
|
+
|
|
7
|
+
## Поведінка
|
|
8
|
+
|
|
9
|
+
- `isSourceFile`: Перевіряє, чи файл є джерелом коду, враховуючи розширення та тестові файли.
|
|
10
|
+
- `docPathForSource`: Генерує шлях до файлу документації для заданого джерела, враховуючи відносні шляхи.
|
|
11
|
+
- `scanForDocgen`: Рекурсивно обходить дерево проєкту, визначаючи кодові файли, які потрібно документувати, та їх відповідні шляхи до документації.
|
|
12
|
+
- `slugForModule`: Генерує унікальний slug для модуля на основі його відносного шляху.
|
|
13
|
+
- `findModuleRoots`: Знаходить абсолютні шляхи коренів модулів проєкту.
|
|
14
|
+
- `nearestModuleRoot`: Знаходить найближчий модуль-предок для заданого файлу.
|
|
15
|
+
- `scanForModules`: Лістить модулі проєкту, визначаючи їхні члени (sourcePath-и) та шляхи до документації.
|
|
16
|
+
- `resolveRoot`: Визначає абсолютний корінь проєкту на основі аргументів командного рядка.
|
|
17
|
+
- `runDocgenScanCli`: Запускає сканування docgen як CLI, виводить JSON-масив у stdout та повертає код виходу.
|
|
18
|
+
- `runDocgenModulesCli`: Запускає сканування модулів docgen як CLI, виводить JSON-масив у stdout та повертає код виходу.
|
|
19
|
+
|
|
20
|
+
## Публічний API
|
|
21
|
+
|
|
22
|
+
- isSourceFile — Визначає, чи є файл кодовим джерелом для створення документації.
|
|
23
|
+
- docPathForSource — Генерує шлях до md-файлу, пов'язаний з кодовим файлом.
|
|
24
|
+
- scanForDocgen — Рекурсивно обстежує структуру проєкту, виявляючи файли для документування.
|
|
25
|
+
- slugForModule — Створює унікальний ідентифікатор (slug) для модуля на основі його шляху.
|
|
26
|
+
- findModuleRoots — Знаходить корені модулів, визначаючи директорії з файлом `package.json`.
|
|
27
|
+
- nearestModuleRoot — Визначає найближчий модуль-предок для заданого файлу.
|
|
28
|
+
- scanForModules — Створює список логічних модулів проєкту, включаючи файли та інформацію про них.
|
|
29
|
+
- resolveRoot — Встановлює базову директорію для сканування, використовуючи аргумент командного рядка або поточну директорію.
|
|
30
|
+
- runDocgenScanCli — Запускає сканування для виявлення файлів документації та виводить результат у форматі JSON.
|
|
31
|
+
- runDocgenModulesCli — Запускає сканування модулів та виводить результат у форматі JSON.
|
|
32
|
+
|
|
33
|
+
## Гарантії поведінки
|
|
34
|
+
|
|
35
|
+
- `isSourceFile` повертає `true`, якщо вказаний шлях до файлу є джерелом коду.
|
|
36
|
+
- `isSourceFile` повертає `false` в іншому випадку.
|
|
37
|
+
- `docPathForSource` повертає шлях до відповідної папки `docs/` для вказаного джерела.
|
|
38
|
+
- `scanForDocgen` повертає JSON-список шляхів до кодових файлів, які потрібно обробити.
|
|
39
|
+
- `scanForDocgen` встановлює прапор `exists` у випадку, якщо файл або папка вже існують.
|
|
40
|
+
- `slugForModule` повертає унікальний URL-шлях для модуля.
|
|
41
|
+
- `findModuleRoots` повертає список кореневих модулів проєкту.
|
|
42
|
+
- `nearestModuleRoot` повертає найближчий кореневий модуль до вказаного шляху.
|
|
43
|
+
- `scanForModules` повертає список модулів проєкту.
|
|
44
|
+
- `resolveRoot` повертає кореневу папку проєкту.
|
|
45
|
+
- `runDocgenScanCli` запускає процес сканування для `docgen`.
|
|
46
|
+
- `runDocgenModulesCli` запускає процес сканування для модулів.
|
|
47
|
+
- У разі невдачі повертається `false` та `null`.
|
|
48
|
+
-
|
|
@@ -0,0 +1,27 @@
|
|
|
1
|
+
# llm-worker.mjs
|
|
2
|
+
|
|
3
|
+
## Огляд
|
|
4
|
+
|
|
5
|
+
Цей файл є LLM-робітником, який збирає контекст для n-fix оркестратора, зокрема правила з файлів .mdc та звіти про порушення. Він передає цей контекст великій мовній моделі (LLM) для генерації JSON з пропозиціями змін. Після отримання змін, скрипт застосовує їх до відповідних ресурсів.
|
|
6
|
+
|
|
7
|
+
## Поведінка
|
|
8
|
+
|
|
9
|
+
runLlmWorker: Виправляє одне rule-порушення через pi (C1 pattern). Збирає контекст з rule .mdc, файлів з violation output, та передає його в pi для отримання JSON зі змінами. Застосовує зміни, якщо вони були отримані від pi. Якщо pi не повернув JSON, або не зміг застосувати зміни, повертає помилку. Використовує модель Claude HAIKU за замовчуванням, або модель, вказану в опціях.
|
|
10
|
+
|
|
11
|
+
## Публічний API
|
|
12
|
+
|
|
13
|
+
MODEL_HAIKU — Генерує короткі вірші.
|
|
14
|
+
MODEL_SONNET — Генерує вірші у форматі сонету.
|
|
15
|
+
runLlmWorker — Виправляє порушення правил, використовуючи pi (C1 pattern).
|
|
16
|
+
|
|
17
|
+
## Гарантії поведінки
|
|
18
|
+
|
|
19
|
+
- Приймає контекст з файлів `.mdc` та файлів з violation.
|
|
20
|
+
- Повертає JSON з пропозиціями змін.
|
|
21
|
+
- Застосовує зміни, отримані від `pi`.
|
|
22
|
+
- Використовує LLM для генерації змін.
|
|
23
|
+
- Викликає LLM через `pi`.
|
|
24
|
+
- Не використовує tool-use.
|
|
25
|
+
- Не кидає винятків.
|
|
26
|
+
- У разі невдачі повертає `false` та `null`.
|
|
27
|
+
- Не використовує кешування.
|
|
@@ -0,0 +1,32 @@
|
|
|
1
|
+
# orchestrator.mjs
|
|
2
|
+
|
|
3
|
+
## Огляд
|
|
4
|
+
|
|
5
|
+
Файл `convergence-loop` є автономним оркестратором для n-fix, який забезпечує перевірку та виправлення коду без участі LLM. Він ініціює детерміністичні перевірки, regex-парсинг та ітеративні процеси з використанням LLM для вирішення складних проблем. Цей компонент є ключовим елементом системи, що автоматизує процес забезпечення коректності коду n-fix.
|
|
6
|
+
|
|
7
|
+
## Поведінка
|
|
8
|
+
|
|
9
|
+
1. **Ініціалізація:** Запускається оркестратор, визначаються максимальна кількість ітерацій (за замовчуванням 3) та порогове значення для ескалації LLM (за замовчуванням 2 невдачі).
|
|
10
|
+
2. **Первинна перевірка:** Виконується детермінована перевірка (T0) на основі заданих правил, без залучення LLM. Результат перевірки записується.
|
|
11
|
+
3. **Автоматичний фікс (T0-auto):** Якщо перевірка виявила порушення, запускається автоматичний фікс, який використовує regex для виявлення та виправлення проблем.
|
|
12
|
+
4. **Ітерація:** Програма повторює наступні кроки до досягнення максимальної кількості ітерацій:
|
|
13
|
+
- **Перевірка (T0):** Виконується детермінована перевірка (T0) на основі поточного стану.
|
|
14
|
+
- **Автоматичний фікс (T0-auto):** Якщо перевірка виявила порушення, запускається автоматичний фікс.
|
|
15
|
+
- **Виклик LLM (T1):** Для кожного порушення, яке не було виправлено автоматичним фіксом, викликається LLM (haiku або sonnet, залежно від кількості попередніх невдач) для генерації рішення.
|
|
16
|
+
- **Оцінка рішення LLM:** LLM генерує рішення, яке оцінюється на предмет успіху.
|
|
17
|
+
- **Оновлення стану:** Якщо рішення LLM успішне, порушення виправляється, і кількість невдалих спроб LLM для цього правила встановлюється на нуль.
|
|
18
|
+
5. **Фінальна перевірка:** Після завершення всіх ітерацій виконується остаточна перевірка, щоб визначити, чи були виправлені всі порушення.
|
|
19
|
+
6. **Повернення результату:** Оркестратор повертає код 0, якщо всі правила були виправлені, і код 1, якщо хоча б одне правило залишилося не виправленим. У випадку помилки парсингу JSON, повертається null.
|
|
20
|
+
|
|
21
|
+
## Гарантії поведінки
|
|
22
|
+
|
|
23
|
+
- Оркестратор запускається при виклику `runOrchestratorCli`.
|
|
24
|
+
- Програма виконує цикл з перевірок, поки не буде досягнуто максимальну кількість ітерацій (`maxIter`).
|
|
25
|
+
- Після кожної ітерації (`T0`, `T0-auto`, `T1`) виконується перевірка.
|
|
26
|
+
- `T0` виконується детерміновано без використання LLM.
|
|
27
|
+
- `T0-auto` виконує regex-парсинг та застосовує програмний фікс у разі виявлення порушення.
|
|
28
|
+
- `T1` використовує LLM через `pi` (ескалація до `haiku` та `sonnet`).
|
|
29
|
+
- `check-gate` повторно запускає `T0` після кожної ітерації.
|
|
30
|
+
- У разі помилки програма повертає `false` або `null`.
|
|
31
|
+
- Програма кешує результати для оптимізації роботи в межах одного запуску.
|
|
32
|
+
- Програма не взаємодіє з мережею.
|
|
@@ -0,0 +1,29 @@
|
|
|
1
|
+
# t0.mjs
|
|
2
|
+
|
|
3
|
+
## Огляд
|
|
4
|
+
|
|
5
|
+
Файл `t0-auto` забезпечує детермінований рівень виправлень для n-fix оркестратора, автоматично застосовуючи програмні фікси на основі аналізу вихідних даних `n-cursor fix --json`. Він парсить повідомлення про порушення, видобуваючи з них інформацію про цільові файли або рядки для вставки, і застосовує відповідні фікси. Це дозволяє швидко та передбачувано виправляти помилки, не використовуючи LLM, і є першим етапом у конвергентному циклі виправлення.
|
|
6
|
+
|
|
7
|
+
## Поведінка
|
|
8
|
+
|
|
9
|
+
applyT0Auto: Застосовує всі T0-auto паттерни до вхідного `violationOutput` та повертає об'єкт, що вказує, чи застосовано фікс, та список виконаних дій.
|
|
10
|
+
filterT0AutoRules: Повертає список id правил, для яких є хоч один T0-auto паттерн, на основі `failedRules`.
|
|
11
|
+
runT0AutoCli: Запускає `n-cursor fix --json`, застосовує T0-auto, повторно перевіряє check-gate та виводить підсумок. Повертає 0 у разі успіху, 1 у разі помилки.
|
|
12
|
+
|
|
13
|
+
## Публічний API
|
|
14
|
+
|
|
15
|
+
- applyT0Auto — Застосовує автоматичні правила виправлення до виявлених проблем.
|
|
16
|
+
- filterT0AutoRules — Визначає ідентифікатори правил, які мають T0-auto паттерни.
|
|
17
|
+
- runT0AutoCli — Запускає CLI-інструмент для автоматичного виправлення, включаючи перевірку та звітність.
|
|
18
|
+
|
|
19
|
+
## Гарантії поведінки
|
|
20
|
+
|
|
21
|
+
- `applyT0Auto` застосовує програмний фікс, якщо `violationOutput` містить інформацію, яку можна видобути за допомогою регулярних виразів, і `violation-message` містить цільове значення, що відповідає одному з ідентифікаторів правил T0-auto. Результат: `applied` - boolean, `actions` - string[] (список виконаних дій).
|
|
22
|
+
- `listT0AutoRules` повертає список ідентифікаторів правил T0-auto, які мають хоча б один паттерн.
|
|
23
|
+
- `runT0AutoCli` повертає код виходу 0, якщо процес виконано успішно, і 1, якщо виявлено порушення.
|
|
24
|
+
- T0-auto запускається першим у конвергентному циклі.
|
|
25
|
+
- T1 запускається лише для решти.
|
|
26
|
+
- Система перехоплює помилки та не кидає винятки.
|
|
27
|
+
- В системі немає кешування.
|
|
28
|
+
- Вхідні дані `applyT0Auto` повинні відповідати формату JSON, вихідному від `n-cursor fix --json`.
|
|
29
|
+
- Якщо `violation-message` не містить інформації, яку можна видобути за допомогою регулярних виразів, `applyT0Auto` не виконує жод
|
|
@@ -1,36 +1,47 @@
|
|
|
1
|
-
/**
|
|
2
|
-
* LLM-worker для n-fix оркестратора — C1 pattern:
|
|
3
|
-
* script збирає контекст (rule .mdc + файли з violation) →
|
|
4
|
-
* pi повертає JSON зі змінами →
|
|
5
|
-
* script застосовує.
|
|
6
|
-
*
|
|
7
|
-
* Всі LLM-виклики через `pi` (користувач налаштовує ключі самостійно).
|
|
8
|
-
* Tool-use не використовується — LLM отримує повний контекст у промпті.
|
|
9
|
-
*/
|
|
1
|
+
/** @see ./docs/llm-worker.md */
|
|
10
2
|
|
|
11
3
|
import { existsSync, readFileSync, writeFileSync } from 'node:fs'
|
|
12
4
|
import { join } from 'node:path'
|
|
13
5
|
import { spawnSync } from 'node:child_process'
|
|
6
|
+
import { env } from 'node:process'
|
|
7
|
+
import { CLOUD_MIN, CLOUD_AVG } from '../../../lib/models.mjs'
|
|
14
8
|
|
|
15
|
-
|
|
16
|
-
|
|
9
|
+
// Тир за замовчуванням: CLOUD_MIN → CLOUD_AVG при ескалації.
|
|
10
|
+
// Перевизначення через N_CURSOR_FIX_MODEL / N_CURSOR_FIX_MODEL_HEAVY.
|
|
11
|
+
export const MODEL = env.N_CURSOR_FIX_MODEL ?? CLOUD_MIN
|
|
12
|
+
export const MODEL_HEAVY = env.N_CURSOR_FIX_MODEL_HEAVY ?? CLOUD_AVG
|
|
17
13
|
|
|
18
14
|
/**
|
|
19
15
|
* Витягує відносні шляхи файлів із violation output.
|
|
20
|
-
*
|
|
16
|
+
* Розуміє workspace-prefix: `[npm] skills/foo.mjs` → `npm/skills/foo.mjs`.
|
|
21
17
|
*
|
|
22
18
|
* @param {string} output violation output з fix check
|
|
23
|
-
* @returns {string[]} унікальні відносні шляхи
|
|
19
|
+
* @returns {string[]} унікальні відносні шляхи (від кореня проєкту)
|
|
24
20
|
*/
|
|
25
21
|
function extractFilePaths(output) {
|
|
26
22
|
const seen = new Set()
|
|
27
23
|
const results = []
|
|
28
|
-
|
|
29
|
-
|
|
24
|
+
|
|
25
|
+
// Патерн з workspace: [npm] skills/foo.mjs або [demo] src/bar.ts
|
|
26
|
+
const wsRe = /\[([\w-]+)\]\s+([\w./][\w./\-]*\.(?:json|js|mjs|ts|vue|yml|yaml|toml|mdc|md|sh|py))(?::\d+)?/gm
|
|
27
|
+
for (const m of output.matchAll(wsRe)) {
|
|
28
|
+
const p = `${m[1]}/${m[2]}`
|
|
29
|
+
if (!seen.has(p)) {
|
|
30
|
+
seen.add(p)
|
|
31
|
+
results.push(p)
|
|
32
|
+
}
|
|
33
|
+
}
|
|
34
|
+
|
|
35
|
+
// Патерн без workspace: просто path/to/file.ext або ./file.ext
|
|
36
|
+
const re = /(?:^|\s)(\.?[\w][\w./\-]*\.(?:json|js|mjs|ts|vue|yml|yaml|toml|mdc|md|sh|py))(?::\d+)?/gm
|
|
30
37
|
for (const m of output.matchAll(re)) {
|
|
31
38
|
const p = m[1]
|
|
32
|
-
if (!seen.has(p)) {
|
|
39
|
+
if (!seen.has(p)) {
|
|
40
|
+
seen.add(p)
|
|
41
|
+
results.push(p)
|
|
42
|
+
}
|
|
33
43
|
}
|
|
44
|
+
|
|
34
45
|
return results
|
|
35
46
|
}
|
|
36
47
|
|
|
@@ -44,9 +55,10 @@ function extractFilePaths(output) {
|
|
|
44
55
|
* @returns {string}
|
|
45
56
|
*/
|
|
46
57
|
function buildPrompt(ruleId, ruleMdc, output, files) {
|
|
47
|
-
const filesBlock =
|
|
48
|
-
|
|
49
|
-
|
|
58
|
+
const filesBlock =
|
|
59
|
+
files.length === 0
|
|
60
|
+
? '(no files identified)'
|
|
61
|
+
: files.map(f => `<file path="${f.path}">\n${f.content}\n</file>`).join('\n\n')
|
|
50
62
|
|
|
51
63
|
return [
|
|
52
64
|
`You fix project structure violations. Return ONLY valid JSON — no explanation, no markdown.`,
|
|
@@ -69,7 +81,7 @@ function buildPrompt(ruleId, ruleMdc, output, files) {
|
|
|
69
81
|
`- "path" is relative to the project root`,
|
|
70
82
|
`- "content" is the complete new file content (not a diff)`,
|
|
71
83
|
`- Only include files that actually need to change`,
|
|
72
|
-
`- If nothing can be fixed automatically, return {"changes":[],"error":"reason"}
|
|
84
|
+
`- If nothing can be fixed automatically, return {"changes":[],"error":"reason"}`
|
|
73
85
|
].join('\n')
|
|
74
86
|
}
|
|
75
87
|
|
|
@@ -81,14 +93,25 @@ function buildPrompt(ruleId, ruleMdc, output, files) {
|
|
|
81
93
|
* @returns {{ text: string, error?: string }}
|
|
82
94
|
*/
|
|
83
95
|
function callPi(prompt, model) {
|
|
84
|
-
const
|
|
85
|
-
|
|
86
|
-
|
|
87
|
-
|
|
88
|
-
)
|
|
96
|
+
const modelArgs = model ? ['--model', model] : []
|
|
97
|
+
const r = spawnSync('pi', ['-p', prompt, ...modelArgs, '--no-session', '--mode', 'text', '--no-tools'], {
|
|
98
|
+
encoding: 'utf8',
|
|
99
|
+
timeout: 120_000
|
|
100
|
+
})
|
|
89
101
|
if (r.error) return { text: '', error: r.error.message }
|
|
90
102
|
if (r.status !== 0) {
|
|
91
103
|
const stderr = r.stderr?.slice(0, 300) ?? ''
|
|
104
|
+
if (stderr.toLowerCase().includes('no api key') || stderr.toLowerCase().includes('api key')) {
|
|
105
|
+
const provider = model ? model.split('/')[0] : 'дефолтного провайдера'
|
|
106
|
+
return {
|
|
107
|
+
text: '',
|
|
108
|
+
error: [
|
|
109
|
+
`pi: немає ключа для ${provider}.`,
|
|
110
|
+
`Встановіть N_CLOUD_MIN_MODEL=provider/model-id`,
|
|
111
|
+
`(напр.: openai/gpt-5.4-mini, google/gemini-2.5-flash, ollama/gemma3:4b)`,
|
|
112
|
+
].join(' ')
|
|
113
|
+
}
|
|
114
|
+
}
|
|
92
115
|
return { text: '', error: `pi exit ${r.status}: ${stderr}` }
|
|
93
116
|
}
|
|
94
117
|
return { text: r.stdout?.trim() ?? '' }
|
|
@@ -103,19 +126,31 @@ function callPi(prompt, model) {
|
|
|
103
126
|
*/
|
|
104
127
|
function parseResponse(text) {
|
|
105
128
|
// Спроба 1: прямий JSON
|
|
106
|
-
try {
|
|
129
|
+
try {
|
|
130
|
+
return JSON.parse(text)
|
|
131
|
+
} catch {
|
|
132
|
+
/* fallthrough */
|
|
133
|
+
}
|
|
107
134
|
|
|
108
135
|
// Спроба 2: витягти з ```json ... ```
|
|
109
136
|
const m = text.match(/```(?:json)?\s*([\s\S]*?)```/)
|
|
110
137
|
if (m) {
|
|
111
|
-
try {
|
|
138
|
+
try {
|
|
139
|
+
return JSON.parse(m[1].trim())
|
|
140
|
+
} catch {
|
|
141
|
+
/* fallthrough */
|
|
142
|
+
}
|
|
112
143
|
}
|
|
113
144
|
|
|
114
145
|
// Спроба 3: перший { ... } блок
|
|
115
146
|
const start = text.indexOf('{')
|
|
116
147
|
const end = text.lastIndexOf('}')
|
|
117
148
|
if (start !== -1 && end > start) {
|
|
118
|
-
try {
|
|
149
|
+
try {
|
|
150
|
+
return JSON.parse(text.slice(start, end + 1))
|
|
151
|
+
} catch {
|
|
152
|
+
/* fallthrough */
|
|
153
|
+
}
|
|
119
154
|
}
|
|
120
155
|
|
|
121
156
|
return null
|
|
@@ -131,7 +166,7 @@ function parseResponse(text) {
|
|
|
131
166
|
* @returns {Promise<{ ok: boolean, error?: string }>}
|
|
132
167
|
*/
|
|
133
168
|
export async function runLlmWorker(ruleId, violationOutput, projectRoot, opts = {}) {
|
|
134
|
-
const model = opts.model ??
|
|
169
|
+
const model = opts.model ?? MODEL
|
|
135
170
|
|
|
136
171
|
// 1. Читаємо rule .mdc
|
|
137
172
|
const mdcPath = join(projectRoot, '.cursor', 'rules', `n-${ruleId}.mdc`)
|
|
@@ -1,14 +1,4 @@
|
|
|
1
|
-
/**
|
|
2
|
-
* Автономний оркестратор n-fix: convergence-loop без участі агента-LLM.
|
|
3
|
-
*
|
|
4
|
-
* Тири:
|
|
5
|
-
* T0 — детерміністична перевірка (runFixCheck, 0 LLM)
|
|
6
|
-
* T0-auto — regex-парсинг violation → програмний фікс (0 LLM)
|
|
7
|
-
* T1 — LLM через pi (haiku → sonnet ескалація)
|
|
8
|
-
* check-gate — re-run T0 після кожного тіру; loop до maxIter
|
|
9
|
-
*
|
|
10
|
-
* meta.json: { "orchestrator": true } — CLI маршрутизує `fix` сюди.
|
|
11
|
-
*/
|
|
1
|
+
/** @see ./docs/orchestrator.md */
|
|
12
2
|
|
|
13
3
|
import { spawnSync } from 'node:child_process'
|
|
14
4
|
import { fileURLToPath } from 'node:url'
|
|
@@ -26,81 +16,82 @@ const ESCALATE_AFTER = 2
|
|
|
26
16
|
* @returns {Promise<number>} 0 = all clean, 1 = unresolved
|
|
27
17
|
*/
|
|
28
18
|
export async function runOrchestratorCli(args, cwd) {
|
|
29
|
-
const { runLlmWorker,
|
|
19
|
+
const { runLlmWorker, MODEL, MODEL_HEAVY } = await import('./llm-worker.mjs')
|
|
30
20
|
|
|
31
21
|
const maxIterIdx = args.indexOf('--max-iter')
|
|
32
22
|
const maxIter =
|
|
33
|
-
maxIterIdx !== -1
|
|
34
|
-
? Number(args[maxIterIdx + 1] ?? DEFAULT_MAX_ITER) || DEFAULT_MAX_ITER
|
|
35
|
-
: DEFAULT_MAX_ITER
|
|
23
|
+
maxIterIdx !== -1 ? Number(args[maxIterIdx + 1] ?? DEFAULT_MAX_ITER) || DEFAULT_MAX_ITER : DEFAULT_MAX_ITER
|
|
36
24
|
const skipIdxs = new Set(maxIterIdx !== -1 ? [maxIterIdx, maxIterIdx + 1] : [])
|
|
37
25
|
const ruleFilter = args.filter((a, i) => !a.startsWith('-') && !skipIdxs.has(i))
|
|
38
26
|
|
|
39
|
-
console.log(`🔄 n-cursor fix`)
|
|
40
|
-
if (ruleFilter.length) console.log(` rules: ${ruleFilter.join(', ')}`)
|
|
41
|
-
|
|
42
27
|
/** @type {Map<string, number>} ruleId → кількість LLM-провалів підряд */
|
|
43
28
|
const failCount = new Map()
|
|
44
29
|
|
|
45
|
-
|
|
46
|
-
|
|
30
|
+
// ── Перша перевірка (тихо) ──
|
|
31
|
+
const initial = runFixCheck(cwd, ruleFilter)
|
|
32
|
+
if (!initial) {
|
|
33
|
+
console.error(`❌ fix: помилка перевірки`)
|
|
34
|
+
return 1
|
|
35
|
+
}
|
|
47
36
|
|
|
48
|
-
|
|
49
|
-
|
|
50
|
-
if (!state) {
|
|
51
|
-
console.error(`❌ fix: перевірка повернула помилку`)
|
|
52
|
-
return 1
|
|
53
|
-
}
|
|
37
|
+
let failed = initial.rules.filter(r => !r.ok)
|
|
38
|
+
const total = initial.total
|
|
54
39
|
|
|
55
|
-
|
|
56
|
-
|
|
57
|
-
|
|
58
|
-
|
|
59
|
-
|
|
40
|
+
// Нічого не зламано — коротка відповідь
|
|
41
|
+
if (failed.length === 0) {
|
|
42
|
+
console.log(`✅ fix: ${total} правил — все чисто`)
|
|
43
|
+
return 0
|
|
44
|
+
}
|
|
60
45
|
|
|
61
|
-
|
|
46
|
+
// Є порушення — показуємо прогрес
|
|
47
|
+
console.log(`🔄 fix: ${failed.length}/${total} порушень (${failed.map(r => r.ruleId).join(', ')})`)
|
|
48
|
+
if (ruleFilter.length) console.log(` filter: ${ruleFilter.join(', ')}`)
|
|
62
49
|
|
|
50
|
+
for (let iter = 1; iter <= maxIter; iter++) {
|
|
63
51
|
// ── T0-auto: детермінований фікс без LLM ──
|
|
64
|
-
spawnSync('bun', [N_CURSOR_BIN, 'fix-t0', ...ruleFilter], { cwd, stdio: '
|
|
52
|
+
spawnSync('bun', [N_CURSOR_BIN, 'fix-t0', ...ruleFilter], { cwd, stdio: 'pipe' })
|
|
53
|
+
|
|
54
|
+
const afterT0 = runFixCheck(cwd, ruleFilter)
|
|
55
|
+
const failedAfterT0 = afterT0?.rules.filter(r => !r.ok) ?? failed
|
|
56
|
+
const t0Fixed = failed.filter(r => !failedAfterT0.find(f => f.ruleId === r.ruleId))
|
|
65
57
|
|
|
66
|
-
|
|
67
|
-
|
|
68
|
-
if (failedAfterT0.length === 0) {
|
|
69
|
-
console.log(`✅ fix: всі правила закриті T0-auto`)
|
|
70
|
-
return 0
|
|
58
|
+
if (t0Fixed.length > 0) {
|
|
59
|
+
console.log(` ⚙️ T0-auto: ${t0Fixed.map(r => r.ruleId).join(', ')}`)
|
|
71
60
|
}
|
|
72
61
|
|
|
62
|
+
failed = failedAfterT0
|
|
63
|
+
if (failed.length === 0) break
|
|
64
|
+
|
|
73
65
|
// ── T1: LLM через pi ──
|
|
74
|
-
for (const rule of
|
|
66
|
+
for (const rule of failed) {
|
|
75
67
|
const prevFails = failCount.get(rule.ruleId) ?? 0
|
|
76
|
-
const model = prevFails >= ESCALATE_AFTER ?
|
|
77
|
-
const
|
|
78
|
-
|
|
79
|
-
console.log(`\n⚡ [${tier}] → ${rule.ruleId}`)
|
|
68
|
+
const model = prevFails >= ESCALATE_AFTER ? MODEL_HEAVY : MODEL
|
|
69
|
+
const label = model || 'pi'
|
|
80
70
|
|
|
81
71
|
const result = await runLlmWorker(rule.ruleId, rule.output, cwd, { model })
|
|
82
72
|
|
|
83
73
|
if (result.ok) {
|
|
84
|
-
console.log(`
|
|
74
|
+
console.log(` ⚡ LLM (${label}): ${rule.ruleId}`)
|
|
85
75
|
failCount.delete(rule.ruleId)
|
|
86
76
|
} else {
|
|
87
77
|
failCount.set(rule.ruleId, prevFails + 1)
|
|
88
|
-
|
|
78
|
+
const hint = (result.error ?? '').slice(0, 200)
|
|
79
|
+
console.log(` ⚡ LLM (${label}): ${rule.ruleId} ❌ ${hint}`)
|
|
89
80
|
}
|
|
90
81
|
}
|
|
91
|
-
}
|
|
92
82
|
|
|
93
|
-
|
|
94
|
-
|
|
95
|
-
|
|
83
|
+
// Перевірка після LLM
|
|
84
|
+
const afterLLM = runFixCheck(cwd, ruleFilter)
|
|
85
|
+
failed = afterLLM?.rules.filter(r => !r.ok) ?? failed
|
|
86
|
+
if (failed.length === 0) break
|
|
87
|
+
}
|
|
96
88
|
|
|
97
|
-
if (
|
|
98
|
-
console.log(
|
|
89
|
+
if (failed.length === 0) {
|
|
90
|
+
console.log(`✅ fix: ${total} правил — все чисто`)
|
|
99
91
|
return 0
|
|
100
92
|
}
|
|
101
93
|
|
|
102
|
-
console.log(
|
|
103
|
-
console.log(` ${finalFailed.map(r => r.ruleId).join(', ')}`)
|
|
94
|
+
console.log(`❌ fix: ${failed.length} невирішених — ${failed.map(r => r.ruleId).join(', ')}`)
|
|
104
95
|
return 1
|
|
105
96
|
}
|
|
106
97
|
|
|
@@ -116,7 +107,7 @@ function runFixCheck(cwd, ruleFilter = []) {
|
|
|
116
107
|
const r = spawnSync('bun', [N_CURSOR_BIN, '_fix-check', ...ruleFilter], {
|
|
117
108
|
cwd,
|
|
118
109
|
encoding: 'utf8',
|
|
119
|
-
timeout: 120_000
|
|
110
|
+
timeout: 120_000
|
|
120
111
|
})
|
|
121
112
|
const stdout = r.stdout?.trim()
|
|
122
113
|
if (!stdout) return null
|