---
type: JS Module
title: run-fix-check.mjs
resource: npm/scripts/lib/fix/run-fix-check.mjs
docgen:
  crc: 76874730
  model: omlx/gemma-4-e4b-it-OptiQ-4bit
  score: 100
---

Викликає конформність-фазу `lint` (read-only), движок (`orchestrator.mjs`, `t0.mjs`) та PostToolUse-хук. Перевірка конформності виконується як пряма функція, без зовнішньої обгортки через `subprocess`. Ізоляція на рівні кожного правила зберігається: кожен файл `rules/<id>/fix.mjs` все ще запускається окремим процесом `bun` (crash-isolation). Селекція активних правил — єдине джерело: `resolveCheckRuleIds` за `.n-cursor.json`; per-rule whitelist у спавнених процесах прибрано як дубль.

## Поведінка

1. Визначається наявність інструменту `conftest`.
2. Отримується список усіх доступних ідентифікаторів правил з каталогу правил.
3. Визначається список ідентифікаторів правил для прогону (`resolveCheckRuleIds`), де `.n-cursor.json` — єдине джерело правди:
    а. Якщо надано явний список правил — він валідується проти доступних і звужується до активних (вимкнене правило не вмикається навіть на явний запит).
    б. Якщо явного списку нема й конфіг є — беруться активні правила конфіга (`available ∩ enabled`); `.cursor/rules/*.mdc` ігнорується (фікс дрейфу «enabled, але .mdc нема»).
    в. Якщо конфіга нема (open-by-default debug) — fallback на скан `.cursor/rules/*.mdc`.
4. Якщо визначено ідентифікатори правил для прогону, для кожного ідентифікатора запускається окремий процес `bun` з файлом `fix.mjs` відповідного правила.
5. Захоплюється вивід кожного процесу.
6. Підраховується загальна кількість правил, що не пройшли перевірку.
7. Повертається результат, що містить загальну кількість перевірених правил, кількість невдалих перевірок та детальний список результатів для кожного правила.

## Публічний API

runFixCheck — Визначає відповідність коду заданим правилам, виконуючи перевірку без внесення змін.

## Гарантії поведінки

- Read-only: файл не виконує операцій запису у файлову систему.
- Не звертається до мережі.
