---
type: JS Module
title: types.mjs
resource: npm/scripts/lib/lint-surface/types.mjs
docgen:
  crc: 5f1d3eca
  model: omlx/gemma-4-e4b-it-OptiQ-4bit
---

## Огляд

Цей модуль фіксує контракти `unified lint surface` (spec: docs/specs/2026-06-29-unified-lint-surface.md). Він описує спільні типи даних, необхідні для взаємодії між компонентами системи, які базуються на конфігурації `concern.json`. Контракт передбачає два основні ролі: функція `lint -> LintResult`, яка лише виявляє порушення (read-only), та централізований конвеєр виправлення (T0 + tier ladder). Всі типи визначені як `@typedef {import}` та слугують спільними для runner-а, detector-ів, T0-патернів та fix-worker-ів.

## Поведінка

1. Контекст для перевірки визначається через абсолютний шлях до коріня репозиторію, унікальний ідентифікатор правила та ідентифікатор concern-а. Додатково може вказуватися абсолютний шлях до каталогу concern-а або відносний перелік файлів для пофайлового запуску, а також опційний `AbortSignal` — заповнюється лише в parallel lane `detectAll()` (`N_RULES_LINT_CONCURRENCY>1`), async-детектори прокидають його у свої `spawnAsync`-виклики, щоб перерватись при infrastructure-помилці іншого concern-а.
2. Detector створює результат перевірки, який містить перелік виявлених порушень або технічних діагностик.
3. Кожне порушення фіксується за унікальною комбінацією `ruleId`, `concernId` та стабільного коду причини. Для порушення вказується описовий текст, а також опціональні метадані, специфічні для concern-а.
4. T0-патерн визначає, чи застосовний для групи порушень. Якщо патерн ідемпотентний та самодостатній, він може автоматично ініціювати виправлення без детального аналізу кожного порушення.
5. Застосування T0-патерну генерує змінені файли. Ці зміни фіксуються через механізм `recordWrite` у контексті worker-а, який реєструється в центральному runner'і для забезпечення можливості відкату. Для записів, що є самодостатніми кінцевими станами (файлові доки зі свіжим CRC), контекст додатково надає опційний `recordDurableWrite` — такі файли переживають rollback провального rung-а й не входять у semantic-collateral veto.
6. Fix-worker виконує виправлення на заданому рівні складності (tier). Контекст rung-а несе per-tier `timeoutMs` (ADR 260620-0556), який worker зобовʼязаний прокинути у свій LLM-виклик, щоб зависла сесія переривалась зсередини. Контекст також несе опційний evidence-гейт (Фаза A1 run-harness): `verify` — item-scoped canonical re-detect для петлі всередині рунга (НЕ заміна зовнішнього вердикту runner-а), та `verifyMax` — ліміт додаткових verify-ітерацій. Результатом є перелік абсолютних шляхів змінених файлів.
7. Параметри перевірки можуть визначатися через `concern.json`, який вказує, чи повинна перевірка здійснюватися через виконуваний код (template) або через рего-інтерпретатор (rego).
8. Режим запуску concern-а може бути встановлений як пофайловий для обробки кожного файлу окремо, або як повний для аналізу всього дерева.

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

- Read-only: не виконує операцій запису (ФС/БД).